8 ms·
For the technical side, instead of the historical one: http://responsiveimages.org/ http://responsiveimages.org/ An example from the homepage: <picture>
by ardemue 12y ago
For the technical side, instead of the historical one: http://responsiveimages.org/ http://responsiveimages.org/
An example from the homepage:
<picture>
<source media="(min-width: 40em)" srcset="big.jpg 1x, big-hd.jpg 2x">
<source srcset="small.jpg 1x, small-hd.jpg 2x">
<img src="fallback.jpg" alt="">
</picture>
- hliyan 12y agoI understand from the article that the img srcset was somehow horrible, but the following (presumably the WHATWG proposal) looks more intuitive to me: <img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w"> Can someone explain the drawbacks?
- est 12y agofile names can have spaces and JPEG can end with "640w" in URL. It's really weird to see a tiny DSL invented in a DOM attribute.
- TheCoreh 12y agoSpaces can be escaped as %20 in URLs. I do agree that the domain specific language is weird though, and would even require new DOM APIs to manipulate it directly (like the style attribute does).
- bshimmin 12y agoSurely the way one would represent this in XML, rather than `srcset="foo 1x, bar 2x"`, which strikes me as odd, would be: <picture> <srcset media="(min-width: 40em)"> <source size="1x" src="big.jpg" /> <source size="2x" src="big-hd.jpg" /> </srcset> ...another srcset... <img src="fallback.jpg" /> </picture> Fractionally more verbose, but really a lot less fiddly.
- kolektiv 12y agoQuite, and it has the enormous advantage that I can extract all data using nothing more than an XML parser, rather than having a two stage [parse XML -> parse embedded DSL] parser for special cases. Even the media aspects of the srcset could probably be better expressed (with more verbosity though) as a standard XML structure. I really wish it was - though I'm far from a fan of XML for most cases, it does work rather well for this when used as intended...
- xoraxax 12y agoThe article states that the final problem on the Boston globe redesign (meant as a proof of concept for responsiveness) was that image prefetching feature to speed up rendering which happens before html parsing. Thus they needed a way for browsers to parse that information separately ahead of time. I guess that it should be possible though for browser to parse a html fragment rooted on the picture tag, and then plug that tree back later on in the full document tree when it is constructed. Or is it simpler to search for picture/img attributes? Oh, there's this whole implicit tag closing business in html though...How do we know where to stop parsing a fragment? At least attributes values stops at the end of a string literal, or on a tag end. Perhaps that's the reason why they went for a dsl in attributes. I agree with you though, it's cleaner your way, and perhaps xhtml could use that approach in the future?
- pornel 12y agoVerbosity was a huge argument against <picture>. People were ridiculing it with complex use cases that required awful amounts of markup. Hixie was against using elements, as it's harder to spec (attribute change is atomic). Eventually <picture> got a simplified algorithm that avoids tricky cases of elements, but at that point srcset was a done deal. At least we've got separate media, sizes and srcset instead of one massive "micro"syntax.
- possibilistic 12y agoThis all seems horrific. Why can't HTML be properly extended to support attribute arrays or dictionaries as values? Having a value encode a DSL is so messed up. This is yet more to parse... HTML keeps getting pulled in so many directions. I wish XHTML had won. It was modular, pluggable, extensible, and semantic. The last bit might have eventually made entering the search space easy for new competitors, too.
- yuhong 12y agoHere, don't confuse what was XHTML1 with XHTML2.
- possibilistic 12y agoI'm speaking more in terms of the goals the markup dialects had, irrespective of the ultimate implementation. I think we can all agree that those suffered from misguided engineering choices (bloaty XML culture). Responsive images could have been an XHTML module with a javascript implementation. The browser vendors could catch up and provide native implementations in their own time, but that would not postpone immediate usage. If it were done right, anyone could have defined a markup module/schema with parsing rules and scripting. The evolution of those extensions would have been pretty damned fast due to forking, quick vetting/optimization, etc. It would have been well timed with the recent javascript renaissance, if it had happened. It might have meant browser vendor independence at the level of the developer. HTML should really have been modular with an efficient, lightweight core spec. It should have also paid lots of attention to being semantic so that others could compete with Google on search. I am still curious if that's why Google got involved in the WHATWG. I'm rambling about things I don't know about though...
- domenicd 12y ago> Responsive images could have been an XHTML module with a javascript implementation. The browser vendors could catch up and provide native implementations in their own time, but that would not postpone immediate usage. This is exactly what happened, except without the XHTML nonsense. JavaScript polyfills of the picture element were created and in use before native implementations eventually caught up. (And native implementations are very necessary, in this case, because they need to hook in to the preload scanner, which is not JS-exposed.) More generally, custom elements and extensible web principles in general enable all of this. Again, without XML being involved.
- pjmlp 12y agoWhy, it is just the web being the hack upon hack, of this bending into application framework story.
- pornel 12y agoThe syntax was confusing, but still didn't cover all use cases. To authors it wasn't clear whether "w" declared width of the image, or min-width or max-width media query. It's a media query, but doesn't look like one. Values look like CSS units, but aren't. On top of that interaction between "w", "h" and "x" was arbitrary with many gotchas, and everybody assumed it works differently. With <picture> we have full power of media queries using proper media query syntax. srcset is still there in a simplified form with just 1x/2x, and that's great, because it is orthogonal to media queries ("art direction" case) and processed differently (UA must obey MQ to avoid breaking layouts, but can override srcset to save bandwidth).
- Siecje 12y agoHow does the browser know to grab the 1x version or the 2x version?
- garethadams 12y agoThe browser knows about the device it's running on, and specifically its display density.
- kaoD 12y agoI assumed 2x was for Retina-like screens. The browser already knows it and it's exposed via devicePixelRatio. If I understood your question correctly.
- carsonreinke 12y agoWould this be the first element that actually varies based on media size? Seems like a strange precedent.