How a new HTML element will make the Web faster
arstechnica.com
arstechnica.com
FIG was intended to be an alternative to IMG, and unlike IMG it wasn't self-closing. It could have children, and the way it was supposed to work was that the outermost one the browser thought was "good enough" would get rendered. One possible usage at the time was to have a png in your outer FIG, a gif on the next one in (png was new at the time, so not well supported), then an IMG for browsers that didn't understand FIG. Once FIG was well supported then you'd leave out the IMG, and instead just have the "alt" text -- except it could have real markup instead of just the plain text of the alt attribute.
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> <img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w">
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).
If I understood your question correctly.
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.
But the browser vendors failed to make a stand against bad HTML.
<img>
<srcset>
<source><width>1024</width><src>large-image.jpg</source>
<source><width>512</width><src>small-image.jpg</source>
</srcset>
<src>image.jpg</src> <*>fallback</*>
<alt>My image</alt>
</img>I dislike XML, the confusion between attributes and sub elements is one of the worst bits.
That is what your code would look like to browsers that didn't know about the new elements. HTML is defined such that browsers can ignore unknown elements for compatibility and still display the text. Using contents for the metadata means that browsers need to know about the elements to at least hide the text.
This is why *ML is a stupid-ass way to do things. "the problem it solves is not hard, and it does not solve the problem well."
JSON is great as an interchange format, but there are many reasons editing it by hand is painful, lack of comments and lack of newlines in strings not being the least of them.
HTML5 got one thing right though: standardization of the DOM failure behavior. As an implementation detail of their design, they went with "sensible recovery" for failures over stricter failure modes.
In going with the WHATWG over the W3C, we ultimately chose "easy to author, (slow to evolve) living standard" over "strictly typed yet developer extensible". I was disappointed, but it's good for some parties I suppose. (It certainly keeps the browser vendors in charge of the core tech...)
The W3C over-engineered to a fault. They had a lot of the right ideas, but were too enamored by XML and RDF.
No browser vendor was going to ship new features only in XML parsing mode, because that was author-hostile enough that it would lose them authors, and thus users. (Browser game theory.) The choice of HTML over XML syntax was purely practical, in this sense.
It was browsers that did that in the first place. HTML5 just standardized the exact behavior on failures.
I want to know more...
HTML 4 - vendors implemented the spec incongruently and failed in their own special ways. XHTML strict - standard parsing rules with strict failure mode. HTML 5 - standard parsing rules, suggested (but not required) rendering behavior for browser uniformity, and well-defined failure behavior.
There's something you're overlooking in the above. If a compiler was smart enough to know what to do with your erroneous code and compile in spite of the errors, that would be the end of programming and programmers.
I love it when my code doesn't compile (i.e. if I've made a mistake). Much worse if when something tries to be "intelligent" and makes my code do something I never asked for - then I spend hours trying to figure out what the issue is (assuming I've noticed) rather than seeing that I made a mistake and fixing it.
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...
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.
<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>
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?
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...
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.
The rest is the story of how the "picture" element came to be, which is a very interesting story but has nothing to do with how it'll make the web faster.
Even when it publishes stuff from Ars or wherever, I often skip the article and just read the comments here because they're much more insightful and if there's anything good, the commentators here know better.
The demand at news sites that they keep churning out news no matter what is what lowers their quality. Sometimes there just isn't anything worthwhile to read at the moment about a topic.
It's the rest of the story that needs to be told.
I don't know whether it's incompetence or indifference, but for most sites, slow loads is a developer, not a tool or design, issue.
In some ways, this almost feels like spacer.gif all over again.
That said, when the only way to get the design to work is using alpha transparency, and you know you need a massive 24bit PNG you're caught between a rock and a hard place. Especially when you then have to think about creating the same image at double size to serve to retina displays (because the client asks "why is it fuzzy on my ipad/mac/phone?") - page sizes start to get out of control.
Making it easier to optimize web resources with a `<picture>` tag may help some developers take the steps to actually optimize where they didn't before (even with existing tools).
<img src="image.jpg" sizes="640,800,1024"/>
Is your thought here that not one of the dozens of people involved considered this sort of syntax during those months or years or work? (That seems unlikely.) Or do you think their reasons for rejecting it were unsound? (You don't seem to have said why.) I'm just not understanding what you're aiming for here.
<img id="cats" src="fallback_for_old_browser.png" />
@media (max-width: 600px) {
#cats {
src: url('http://cats.com/cats-600.png');
}
}One file, one URL, different offset for different dimensions, done.
http://setup.googleapps.com/Home/user-resources/google-icons...
You'll note the 16px icon uses square corners, while the other sizes have rounded corners.
There are other considerations as well, such as causing unintentional Moiré effects, and scaling DPIs in not-quite-powers-of-two (basically all of Android).
Either way, the article makes it pretty clear that the current method for drafting and implementing standards for the web is not working brilliantly (having both W3C and WHATWG around exemplifies this).
Shouldn't the solution come from the server side? You can serve different image sizes to different devices, whereas if you need the browser to do the work you'll wait forever.
There is even a simpler solution, which is to use just one image of average-to-small size, and size it in the page dynamically. If the image is of good quality in the first place (noise free), most users won't notice.
Another option would be to "guess" the right size to serve based on the User Agent String (maybe you meant this and I misunderstood?). This could work, although the server may very well guess wrong.
But I also maintain that a single image of relatively small size can be used for all form factors if its quality is good enough (resized by the browser based on CSS instructions); you can at least double the size of a "good" image before you begin to see problems.
This probably wont be used on any major sites for the time being, considering the devices that the element has been designed for dont support it.
Considering many HTML5 features and related JavaScript APIs can easily be made to work in older browsers using polyfills, many relatively larger sites have been doing this for lots of things (HTML5 block elements in IE<9, for example).
For an example, we solve the adaptive images server-side problem with our SaaS image compression service http://www.slender.io/ with smart recompression & a few content negotiation tricks. Some of our customers would like to use <picture> and related polyfills for their sites, but their designers struggle defining the target image sizes relative to viewport dimensions, not the size that the image is/would be layouted. As a result, adoption on both smart browser and server-side solutions are slowed down.
The article mentioned element queries, that will hopefully solve this problem, but make the browser implementation much more complex. While the browser could resolve the normal media queries already when preparsing (e.g. it knows the viewport dimensions all the time), I understood it would know the element queries only after layout, partially defeating the whole purpose of preparsers.
It seems web standards are making things as simple as layouting insanely complex. While I am sad about all that artificial complexity, I am happy that no WYSIWYG editor will automate my job any time soon. :)
Based on what I found today, there are a couple of ways to handle the problem of variable sized images. If anyone knows others please do tell.
1. Use picture and srcset with a polyfill (Picturefill). With this you end up with verbose markup as well as needing stuff like "<!--[if IE 9]><video style="display: none;"><![endif]-->" to make it work. It also results in requests to multiple images for browsers that support srcset but not picture, meaning twice as many images are downloaded. Many browsers are in this group with the current or next versions.
2. Use javascript. This is the method employed by various saas solutions that I looked at, and there are of course libraries that you can use yourself. Waiting for javascript to execute before the images can start being pulled down has obvious problems.
3. User agent sniffing. This method requires server side logic to implement, and relies on data that in many cases will not result in an appropriately sized image being rendered.
Is there another way? Has anyone got a workable solution to this and could give a recommendation?
Of course, you could limit the media queries that could be used with JavaScript, but then your general solution isn't really so general anymore. And there's already a way to dynamically load scripts, so we don't really need another way to do that:
<script>
if (blah) {
document.write('<script src="a.js">');
} else {
document.write('<script src="b.js">');
}
</script>
<style>
@import url(a.css) (max-width: 800px);
@import url(b.css) (min-width: 801px);
</style>But there are potentially more types of media (audio, video, html via frames, etc).
Even if a general solution isn't applicable to JS, it can have lots of other uses.
That has the same problem as JS, especially when you realize that framed pages on the same domain can interact with the parent's DOM.
Serioulsy, fast vector graphics were a solved problem back in the late '90s. How is this still a problem today on the Web?
Source: I'm an artist who works primarily in Illustrator and checks to see how horrible the svg performance on her more complicated images is every few years.
SVG just happens to be a very slow implementation of vector graphics.
And my point isn't that they're better than a 300 dpi image, it's that they're better than an infinite list of high-DPI images for every twisted combination of DPI and screen-size.
Moreover: a lot of the images people would like to serve in multiple sizes are presumably photos. Photos and vectors don't go together well; vectors are a lot better at simple images.
And finally. [Here](http://egypt.urnash.com/rita/chapter/01/) is the graphic novel I'm drawing entirely in Illustrator. The 72dpi bitmaps range from 15 to 212 kb. Printable 300dpi bitmaps range from 1.75 to 2.3 mb. They're CMYK rather than RGB, let's guesstimate they'd be 3/4 of the size -- 1.3 to 1.7 mb. Illustrator files? 948-34 MB. And that's with 'create PDF compatible file' turned off, which generally halves the size of an .AI file.
I'm going to pause here to let that sink in. Even distributing a CD full of 300DPI images of a nearly 200 page graphic novel is less data than the source Illustrator files. And converting them to SVG/SVGZ/PDF makes little in the way of size gain, either. A modest list of high-DPI images sounds like a hell of a lot less stuff to upload to your server, never mind that you'd only be sending the single bitmap that best fits the display at hand.
3D games have a lot of tooling to make things Render Fast. There are a ton of ways people have figured out to fake more complex images - LOD, bump maps, baked luminosity, lots more stuff I don't know offhand because I'm not a 3D person. Nobody has put anywhere near the same kind of effort into getting 2D vector images to render fast.
I would love to see someone build tools for doing the 2D equivalent of things like "turning a super hi res mesh into a simpler one plus bump maps" and rendering them quickly. Maybe I could finally stop rendering my stuff into bitmaps for the web. But I don't see anyone doing that any time soon.
anyway.
TL;DR: 2D vector rendering is sluggish and I don't see that changing any time soon, and the file sizes for interestingly complex images is a couple orders of magnitude larger than a 300dpi bitmap. Only the most trivial images are more efficiently served as vector files than as multiple bitmaps.
1. m dot sites are not a thing of the past. Many sites benefit from a pure mobile experience.
2. The Boston Globe (while impressive) does not show that 'that responsive design worked for more than developer portfolios and blogs'. The globe is largely text / image based, and that does not translate to a site like Amazon / Facebook.
When i read the title, i thought media-queries would get the functionality to load external stylesheets, which seems like a better option to me (especially if css could fill the img src, then stylesheets reduce in size, but also images. Only this option uses to much back-and-fort communication. Perhaps a default naming would be appropriate (eg. img-1024.jpg => for browsers with a max-width of 1024 px, same could be used with stylesheets). Even a syntax like <img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w"> could be used.
PS. If you downvote me, at least do it with the decency of giving arguments...
1. This breaks caching, which is a big deal for most sites.
2. This also has the problem of needing a separate fallback to handle window resizing.
3. This requires a separate approach to handle format detection, although you could set a cookie for that as well.
Then again, what's your preference?
As someone already said, use headers, css, etc.
arstechnica: you can do better than linkbait titles.
the low resolution devices could load the first bytes of the image and the high resolution one the full image.
But your point about high res screens is definitely true. Hell, we first had 'retina' hacks and bigger images specifically for our phones! Why is a site going to want to serve up smaller files for screens with more pixels?
Laptops and desktop monitors are slowly catching up. We're just living in this part of history where it was easier to manufacture small high-DPI screens than large ones. It's not going to last. Heck, I'm typing this on a 13" Yoga Pro laptop with a near 4K resolution.
So the sizes needed for larger displays will bump up over the next few years and we're still going to have the same issue of having to serve massively larger images to large screens than small ones.
Also, the first world is just a subset of internet users.
Maybe it's because I have an older iOS device running 6.1, but the insane size of some of these sites combined with all the side-loaded javascript and CSS rendering (and re-rendering) is just making sites completely unusable.
How come I can load Metafilter in 3 seconds, but Wired takes over a minute, if it works at all? And Medium? Even worse.
Now the web is a (bad) application platform, where the content designers demand full control of interactivity.
As a user you are not well-served by the modern web. It's not the devices per se it's also the content that is different than ~10 years ago.
Virtual reality should bring inexpensive, full-peripheral "monitors" that we can interact with naturally, anywhere. No more having to bend over backwards to fit all our info on mobile devices.
Yeah, I don't see that happening any time soon, because ergonomics.