tl;dr: <picture> tag. It contains an <img> tag inside for backwards compatibility, and allows you to define multiple <source> tags for different sizes.
Which is kinda lame IMHO. Why can't we use progressive JPEG, with offsets? The first rough scan for small size image, a second scan for normal image, a third scan for retina sized image?
One file, one URL, different offset for different dimensions, done.
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).
There are many browsers out there, not just Chrome and Firefox, esp. on mobile. Android Chrome is fairly out of sync with desktop Chrome. Kindle devices use their own browser and won't let you install another one, etc. Plus, mobile users update their apps or their OS rarely, if ever.
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.
Noise has nothing to do with good quality in this case. Pixels are the enemy, and they show up all too quickly when you scale a small image to a large size.
The article mentioned the problem with this approach: Your browser loads the HTML, CSS, JS simultaneously with the images on the start of the page load - so when you find out what size you need at runtime (via JS), and then put in the right img-src, it will be slower than loading a higher-res version right from the start.
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.
Yes, I meant "guessing" the right size based on the user-agent string as the best approach (since it doesn't rely on the browser doing the work, it will work with any browser, including old ones).
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.
The user-agent is the biggest cluster fuck in the history of the web and has nothing to do with HTML. Once you understand this, you'll learn to ignore it.
The user-agent is the biggest cluster fuck in the history of the web and has nothing to do with HTML. Once you understand this, you'll learn to ignore it.
This is a bit of a linkbait. There are maybe two lines on how the new "picture" element makes the web faster.
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.
How is it ironic? Article claims a new element to improve things. They can say that they are not responsive because such improvements are needed and they were waiting for it.
It is ironic because the article claims images slow the web; before extending HTML with special elements and DSLs it would seem a simpler step to get rid of useless and meaningless stock images.
You are not thinking far enough: some of those stock images could easily benefit from a unified CDN. And why stop there, a number of "office girl on phone" might even be included in the browser distribution. Now _that_ would be an html tag to speed up the web!
I'm wondering how factually accurate the story is, considering that it says "Apple's Tab Atkins" while both Tab Atkin's homepage and Google+ profile say he works at Google.
Perhaps because "how the web will be made faster" by the new element is obvious: by downloding less and more targeted image content. What's more to explain?
Why stop at images only? A more general solution using CSS-like media queries would be much preferable; with a general solution it would be possible to serve all sorts of assets (CSS, JS, Images, Video, etc) tailored to the display device and network connection.
<picture> is responsive; when you change the viewport's width, the browser can load a differently-sized version of the image. How would JS be made responsive like that? Once one version of a script is loaded, you can't magically replace it with a difference version.
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:
the <picture> tag is set up very similarly to the audio and video tags, so I think that even if this specific solution isn't general, the pattern can be applied generally to other types of media.
If you want people to do more of something, make it easier for them to do.
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).
I'd say it is a bit of a design issue too - I remember when the majority of images on sites were actually "contentful" (for lack of a better term), and not just something like a gradient or glittering button. The practice of providing a thumbnail/preview that links to the full-sized version was common, so you wouldn't be unnecessarily loading images you didn't want to see at full resolution.
In some ways, this almost feels like spacer.gif all over again.
I agree to a point - I think it's maybe thought about a bit more by those who were building sites when a 1mb page meant a 5 minute download. For those that grew up taking high speed Internet for granted it's thought about a lot less.
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.
Spaces 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).
Quite, 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...
The 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?
Verbosity 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.
This 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.
I'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...
> 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.
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.
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.
It was browsers that did that in the first place. HTML5 just standardized the exact behavior on failures.
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.
Incorrect. HTML5 synthesized the exact behavior that was closest to the majority of browsers. But not all browsers agreed (e.g. Mozilla would change its HTML parsing behavior depending on network packet boundaries), so there was still effort aligning with the newly-specced common parsing algorithm. At the time there was much skepticism that such alignment was even possible.
It wasn't really a choice in favor of "easier to author." It was a choice in favor of "will this actually get implemented, or just be fancy theorycraft?"
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.
> I really hate when my code doesn't compile. If my code is wrong, the compiler should just figure out what to do.
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'm pretty sure that comment was sarcasm. It's a complaint about how HTML5 isn't just specified to fail on bad input, but instead gives rules on how to recover.
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.
The problem has nothing to do with web devs but rather that no one wants to use a browser that spits out "error 5" on malformed HTML, which is necessarily what you're implying. The other option is to do your best with the bad HTML, and now we're right back where we started, regardless of how "strict" you make the rules.
'bad HTML' could easily have just been an ego clash and pissing contest between developers of competing browsers. It was arguably more difficult to implement than just well-structured syntax.
But now it's a PITA properly handle and escape for any toolset that don't have good xml support. Imagine people starting to put <![CDATA[ ]] blocks into this.
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.
JsonML is pretty efficient when auto-generated from HTML source. I use it as an intermediate form for client side templates ( http://duelengine.org ) but I don't write it by hand. Its regularity makes it a perfect candidate for output from a parser/compiler.
not practical since you'd have to define attributes for every conceivable size in the spec and that's just asking for trouble. e.g. w2048, h1024, w320, w240,h320, wPleaseShootMe :)
"1024 large-image.jpg 512 small-image.jpg image.jpg fallback My Image"
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.
The 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).
I knew about this tag 2 months ago, when I was Implementing a responsive website. I came accross the picture element but Unfortunatlly, most of modern browser is not supporting it yet. So I decided to do it via javascript.
So I don't see the "news" here, I thought the article was about a compression algoritm or somthing, but nothing special.
I don't agree with your 4G comment, as its coverage is poor, performance is patchy and smaller files will still download quicker regardless of your max speed.
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?
I would presume that the higher resolutions of mobile devices over laptops and desktops is just a transient thing.
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.
I think the current mobile browser is long overdue for disruption. In 10 years, I can see us looking back and chuckling at the fact that we had such tiny spaces for all the information we interact with.
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.
I can see it evolve into a normal pair of glasses in 10 to 15 years. We need another Steve Jobs-type character to speed things up a bit, but I think we can get there.
This element reminds me of the ill-fated FIG element (https://www.cmrr.umn.edu/~strupp/elements.html#FIG) which was proposed in HTML 3.x, but never made it in. (I think it was replaced by EMBED which then transmogrified into OBJECT).
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.
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).
To resize images, i create a cookie with javascript that gives the browsers current width and height. (mostly for full image front pages -> the function for choosing the image width is based on bootstrap)
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...
Then the archiving functionality saves all additional stylesheets and images, so it can be appropriately used later on. But not much people "save" a page as html, they bookmark/favorite it, if it's interesting or print it to pdf (or your favorite document type)- eg. on a checkout
I think <picture> will (hopefully) ultimately win out because it quite nicely makes all the main three forms of embedded media (pictures, video and audio) work pretty much the same way. Plus, if only use of <figure> and <figcaption> was a bit more widespread...
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).
As the border between mobile/portable devices and dektops/workstations keeps getting blurrier, this "on mobile" concept will probably just lose any sense in the near future.
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.
OMG this. It's insanely frustrating that 90% of the time we're just reading text and it's so painful on older mobile devices that still should run circles around computers that happily consumed internet content ~10 years ago.
I think this should just be a server side issue. Querying for images with size information and the server spit out lower res images on the fly. This way, the web design guys have less to do when creating graphics assets for a site.
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.
Then then the browser can choose the most appropriate size based on the screen size. The filenames would simply follow the convention, image-640.jpg, image-800.jpg etc. older browsers would simply use the original src.
We'll need a solution in CSS for properties like background-image and border-image. (Indeed, there have been multiple proposed solutions already.) It would be nice to use the same mechanism for both CSS and content images instead of introducing yet another case in the web platform where we have multiple slightly-incompatible mechanisms that do the same thing.
To my eye, it's a little odd to read an article about multiple groups of experts who spent months or years hashing out a difficult problem, and then to see a comment like this one that proposes its own much simpler solution.
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.
Their proposed solution offers more flexibility in that you can use media queries to specify the upper/lower bounds and also specify the filenames. This feels over-engineered though, firstly because the above solution provides enough information to switch between images (we're not changing the layout here) and secondly because a filename convention is adequate for referencing them. The third reason that I dislike their solution is that it introduces presentation logic(media queries) into html.
Seriously, I thought this was what request headers were for. Have the goddamned browser request the most appropriate size, don't hardcode it into the markup.
I would disagree that the majority of images on the web are photos. Yes, there are many photos on the web, but I'd wager the vast majority of images (or at least the vast majority of image requests) are tiny bits of connective tissue of web layout - little rounded corners, gradient backgrounds, icons, etc.
Rounded corners and gradients can both be handled without images these days, but even if you use images for things like that, that bandwidth (certainly) and number (probably) of photos dwarfs them.
Vector formats can replace simple images, sure. They can't replace photos. And vector art complicated enough to be interesting can be a huge CPU load to draw... and can often be a LARGER file than a bitmap made at a resolution appropriate for the screen. It's not a more efficient representation for complex images until you start getting to 300+ dpi images that fill a whole printed page.
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.
Every game company ever disagrees that vector graphics are inherently slow. They just need to be designed to work fast.
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.
Rendering my art takes noticeable amounts of time whether it's a PDF renderer, an SVG renderer, or Illustrator's internal renderers. Even after a recent Illustrator update's main bullet point was "we rebuilt a significant chunk of AI's internals to make it tons faster". It may be theoretically possible to render vector images much faster than this, but ain't nobody stepping up to do this.
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.
146 comments
[ 2.8 ms ] story [ 100 ms ] threadOne 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).
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.
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.
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:
And there's also already a way dynamically load CSS (using media queries, even):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.
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.
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).
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.
An example from the homepage:
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...
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?
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.
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.
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.
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.
It was browsers that did that in the first place. HTML5 just standardized the exact behavior on failures.
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.
I want to know more...
https://blog.mozilla.org/mrbkap/2013/08/12/the-old-html-pars...
http://ln.hixie.ch/?start=1138169545&count=1
https://bugzilla.mozilla.org/show_bug.cgi?id=324875
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.
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.
But the browser vendors failed to make a stand against bad HTML.
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.
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."
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.
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.
Also, the first world is just a subset of internet users.
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.
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.
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.
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).
the low resolution devices could load the first bytes of the image and the high resolution one the full image.
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...
Then again, what's your preference?
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.
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).
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.
http://ericportis.com/posts/2014/srcset-sizes/
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.
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.
arstechnica: you can do better than linkbait titles.
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.