
How a new HTML element will make the Web faster - wfjackson
http://arstechnica.com/information-technology/2014/09/how-a-new-html-element-will-make-the-web-faster/
======
xenomachina
This element reminds me of the ill-fated FIG element
([https://www.cmrr.umn.edu/~strupp/elements.html#FIG](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.

------
ardemue
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
I 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
file 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.

~~~
possibilistic
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.

~~~
iopq
this is why attributes are really a stupid ass way to do things

    
    
      <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>

~~~
est
<imgset w1024="large.jpg" w640="medium.jpg" />

~~~
palakchokshi
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 :)

------
Illniyar
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.

~~~
bambax
And, ironically, ArsTechnica isn't responsive and uses stock images that
contribute nothing to the article (blurry hands on a laptop keyboard!)

~~~
Tepix
Agreed. Quite annoying. The top rated comment post here was just 5 lines or so
and told me more than 4 pages of that click bait article.

~~~
Natsu
I used to love Ars, but they've started this kind of nonsense and I no longer
bother to read them :/

~~~
glitchdout
What do you read nowadays?

~~~
Natsu
HN.

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.

------
latch
Recently, a HN job post brought me to a career page. It served up a 1MB css
file, a 650K [mostly red] png image, and a 300K black and white png.

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.

~~~
iamben
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.

~~~
rangibaby
Your point is valid, but using imagealpha allows you to have alpha channel in
8bit pngs. www.pngmini.com

~~~
iamben
That's fantastic, thank you. I've been using TinyPNG.com - will give this a go
:-)

------
ollysb
A simpler solution might be

    
    
        <img src="image.jpg" sizes="640,800,1024"/>
    

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.

~~~
Steuard
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.

~~~
ollysb
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.

~~~
eurleif
Arguably, <img> was already a form of presentation logic present in HTML. This
just makes it more capable.

------
TheAceOfHearts
tl;dr: <picture> tag. It contains an <img> tag inside for backwards
compatibility, and allows you to define multiple <source> tags for different
sizes.

~~~
est
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.

~~~
rrouse
Doesn't that mean I would be downloading all of the image data and only using
part of it?

~~~
Sanddancer
No. Part of the http spec is the ability to download only a specific range of
bytes in a file.

------
thomasfoster96
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).

------
bambax
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.

~~~
dkyc
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.

~~~
bambax
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.

~~~
eldelshell
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.

------
c23gooey
[http://caniuse.com/#feat=picture](http://caniuse.com/#feat=picture)

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.

~~~
thomasfoster96
There's always a polyfill:
[https://github.com/scottjehl/picturefill](https://github.com/scottjehl/picturefill)

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).

------
laurisvan
While the <picture> and <img srcset="..."> are a step towards responsive
images, but I personally see them as too complicated for developers that just
want to get things done fast. The complexity of the new standards will slow
down their adoption even more than the browser support.

For an example, we solve the adaptive images server-side problem with our SaaS
image compression service [http://www.slender.io/](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. :)

------
asher_
I was neck deep in this very issue for most of today. It is surprising that
there is no usable solution to this issue without resorting to what seem like
pretty awful methods. If I am wrong about this please do let me know.

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?

------
mccr8
The work to get the picture element implemented in Firefox is going on in the
bugs in the "Depends on" field in this bug, if people are interested:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1017875](https://bugzilla.mozilla.org/show_bug.cgi?id=1017875)

------
superzamp
For people interested in on the fly image processing, there's a nice article
here [http://abhishek-tiwari.com/post/responsive-image-as-
service-...](http://abhishek-tiwari.com/post/responsive-image-as-service-rias)

~~~
hisyam
Some more alternatives: [http://www.imgix.com/](http://www.imgix.com/)
[http://www.thumbr.io/](http://www.thumbr.io/)

------
hrjet
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.

~~~
eurleif
<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:

    
    
        <script>
        if (blah) {
            document.write('<script src="a.js">');
        } else {
            document.write('<script src="b.js">');
        }
        </script>
    

And there's also already a way dynamically load CSS (using media queries,
even):

    
    
        <style>
        @import url(a.css) (max-width: 800px);
        @import url(b.css) (min-width: 801px);
        </style>

~~~
hrjet
Good point about JS.

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.

~~~
eurleif
>html via frames

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.

------
Pxtl
Or we could _finally_ stop futzing around with scaling raster graphics and
find a way to make vector formats not terrible.

Serioulsy, fast vector graphics were a solved problem back in the late '90s.
How is this _still_ a problem today on the Web?

~~~
steveax
Not that I'm against improving vector graphics, but The majority of images on
the web today are not suited for vector formats (photos).

~~~
Pxtl
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.

~~~
steveax
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.

------
ptbello
I found this article on the subject to be more informative and useful:

[http://ericportis.com/posts/2014/srcset-
sizes/](http://ericportis.com/posts/2014/srcset-sizes/)

------
NoMoreNicksLeft
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.

~~~
wtetzner
The problem is if you want different images for different screen sizes, not
just different sizes of the same image.

------
ndreckshage
This article is pretty naive.

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.

------
exo_duz
I love this idea of the <picture> element which hopefully most browsers will
adopt soon but how will this support on the older iPhones that cannot upgrade
to iOS7 (iOS8 soon). Especially with Apple not supporting these devices
anymore.

------
adad95
HTTP Client Hints - New draft imp. of Client Hints for <img> and <picture> for
Ruby. [https://github.com/igrigorik/http-client-
hints](https://github.com/igrigorik/http-client-hints)

------
igl
Someone from the HTML standard body is going to make the web better?
Riiiiiiight...

------
NicoJuicy
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...

~~~
idlewords
It's also horrible for anyone trying to archive your page.

~~~
NicoJuicy
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

Then again, what's your preference?

------
Thiz
Polluting the HTML with extraneous information not intended as markup is never
a solution.

As someone already said, use headers, css, etc.

------
dredmorbius
TL;DR: <picture> element.

arstechnica: you can do better than linkbait titles.

------
ethana
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.

------
blencdr
I don't understand why so much question as this problem should be easily
solved with wavelet type images (jpeg2000 for instance).

the low resolution devices could load the first bytes of the image and the
high resolution one the full image.

------
aianus
This doesn't seem too useful in the first world anymore now that we have 4G
connections and higher resolution screens on our phones than our desktops.

~~~
joosters
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?

------
jbb555
Ah, it might make the web faster _on mobile_. Not very interesting.

~~~
joezydeco
Mobile is getting worse, IMO.

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.

~~~
Pxtl
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.

~~~
nfoz
The web used to provide text, and allow the user-agent to render it as
appropriate for that display/user.

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.

------
swehner
If mobile browsers struggle to download images, change the mobile browsers.
Let the browser wait for some javascript to manipulate the src's ...

------
sixQuarks
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.

~~~
coldtea
> _Virtual reality should bring inexpensive, full-peripheral "monitors" that
> we can interact with naturally, anywhere._

Yeah, I don't see that happening any time soon, because ergonomics.

~~~
sixQuarks
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.

------
ihsanyounes90
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.

