Hacker News Reader

Comment by joebolte | Hacker News Reader

Is srcset really the clearest name they could come up with?

What bothers me isn't the name, but how the syntax looks like nothing else in HTML. At the time the idea was floated, there were a few alternatives talked about that mimicked the <video> and <audio> tags that made way more sense, and opened up for adding webp alternatives with png/jpeg fallbacks etc. It's a real shame they NIH'ed those.

That part in the article felt strained: Mat was clearly trying extremely hard not to be rude while showing how much cleaner <picture> is. Hopefully this is an opening salvo rather than the end of the discussion…

The problem with picture is that it doesn't poly fill nicely. You can add srcset attributes and it will still work on IE6. I have been using srcset for over a year, and there is is only a minor issue of retina MBPs double downloading. There is no problem with high res tablets.

I don't remember any issues polyfilling video, does anything make picture different? This is one of those things one person has to write once and then everyone can reuse it.

A polyfill of <picture> much more expensive. First you have to shiv IE to accept it as a DOM node. Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>. Polyfilling "srcset" is trivial as in:

    if browser is modern and high-res, 
        replace the value of src.
    else 
        pass

Doing a flash video polyfill of a video tag is okay because there is probably only one video on the page. Polyfilling <picture> would produce some seriously janky page rendering, and would be a pain in the ass to maintain.

> First you have to shiv IE to accept it as a DOM node

I find this an increasingly weak argument as it's applying to <10% of the market and falling fairly rapidly ahead of the 2014 Windows XP end of life and is true of everything else in the HTML5 spec.

> Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>.

This is a reasonable complaint - I'm not sure I'd consider it a big deal since the work of manipulating the DOM is a lot faster than doing anything like downloading an image or rendering it but for anyone trying to do a wall of images it'd be worth benchmarking at the very least.

In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning for anyone who isn't strict about pure semantic HTML, they could just stick an img in there for older browsers.

Polyfilling is an issue, although a manageable one if you're willing to use noscript:

  <picture>
    <noscript><img src="old-browser.jpg"></noscript>
  </picture>

(<noscript> should keep browsers from loading the image tag, so you could do things like have JavaScript evaluate your image candidates and generate an img accordingly)

I'd prefer an extra tag during the migration stage to make the long-term goal more readable, particularly if we start wanting to extend it to do things like offer different image formats rather than just resolutions.

In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning you could use it as a fallback for legacy browsers.

"Polyfill", now that's a real train wreck of a name. In comparison, "srcset" is a beacon of clarity.

Experience with the <video> and <audio> tags has shown that their pattern isn't a great pattern to continue using.

[0]: http://lists.w3.org/Archives/Public/public-whatwg-archive/20...

[1]: http://html5doctor.com/interview-with-ian-hickson-html-edito...

Apparently? I'm also not a fan of the value format, let alone the attribute name. Beggers can't be choosers though. Glad we're getting somewhere.

"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton

http://martinfowler.com/bliki/TwoHardThings.html

And off by one errors.

It matches the CSS equivalent feature, image-set().

Reply on news.ycombinator.com