Page 1 of 1

Re: Support <picture> element + some things relating to it

Posted: 2014-09-17, 05:57
by zcorpan
The arstechnica article does a terrible job at describing what actually happens. It was never true that browsers first downloaded everything and then started parsing. It is also not really true that images are downloaded before the markup is parsed.

What used to happen is that images are downloaded as soon as the HTML parses creates the <img> element (subject to download priorities of course). That could well be before the browser has completely fetched the CSS and hence, before it knows the layout.

What happens now is pretty much the same thing, except if there is a <script src> that blocks the HTML parser from continuing (it has to wait in case the script uses document.write), browsers now continue parsing the rest of the page with a lightweight speculative tokenizer in order to find further URLs to start fetching while the blocking script is downloaded. This includes images and it can happen before the browser knows the layout.

It was a requirement that responsive images do not break this optimization. Hence <picture>. If it was not important, you could use JS instead.

HTH

Re: Support <picture> element + some things relating to it

Posted: 2014-09-17, 11:34
by Moonchild
So, in other words, it's to counter bad web design. I don't see how that is going to be priority.

Re: Support <picture> element + some things relating to it

Posted: 2014-09-18, 07:29
by zcorpan
Actually even if you don't use any blocking <script src>s, including the critical resources in the markup is still a good idea to let the browser properly prioritize its network resources.

Re: Support <picture> element + some things relating to it

Posted: 2014-09-18, 08:08
by Moonchild
If web designers would actually follow the few simple design rules there are, this wouldn't be a problem to begin with. e.g. put CSS in the <head>, don't use blocking javascripts above the fold, load js asynchronously when you can, and use a lazy loading system on websites that have a very large content and lots of images. Simple rules, easy to follow, and no need for arbitrary elements. It's like this is an ongoing war between "camp scripting" and "camp markup". Of course the W3C is going to be solidly in "camp markup". We have advanced scripting, and modern web browsers who are exceedingly good at it, so why jump through hoops to avoid it?