3 ms·
It's also a total mischaracterisation of what happened here. This was not a case where someone implemented the feature and we were forced to go with they syntax
by jgraham 13y ago
It's also a total mischaracterisation of what happened here. This was not a case where someone implemented the feature and we were forced to go with they syntax for compatibility reasons. There was extensive discussion about the use cases, best approach, and so on. It turns out to be a much harder problem than you might have thought. For just one example of a subtlety, browser vendors find <picture><source> type syntaxes harder because they can't be processed atomically; for example:
<picture>
<source src="foo">
<script>document.getElementsByTagname("source")[0].src = "bar"</script>
[...]
is complexity that simply can't happen with srcset. Similarly one needs to consider the behaviour of preloaders in extant UAs; if existing browsers will start to download all the images that will create a much worse user experience in the short term.
I don't remember what all the considerations were here, but this is a much harder problem than many people give credit for, and certainly isn't a case where a single vendor controlled the whole process.
- grey-area 13y agoWith respect, making life easier for browser makers is the worst possible reason to choose a feature which will be used by millions of documents (or not, in the case of srcset) over another with a better syntax. I'm not even clear why onload on an img tag would not also invalidate your img example above, but that doesn't even matter. Hacks for performance may be fine in browser or server code in some circumstances, but are absolutely not fine in a public document format like HTML. Is the picture element containing source elements (like video and audio) still under consideration, or is srcset supposed to replace it somehow?