Support <picture> element + some things relating to it

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
zcorpan

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

Unread post by zcorpan » 2014-09-17, 05:57

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

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35597
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

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

Unread post by Moonchild » 2014-09-17, 11:34

So, in other words, it's to counter bad web design. I don't see how that is going to be priority.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

zcorpan

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

Unread post by zcorpan » 2014-09-18, 07:29

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.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35597
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

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

Unread post by Moonchild » 2014-09-18, 08:08

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?
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Locked