Neven Mrgan

Do you have a mailing list discussion you can link to on this, that might be illuminating?

The reason webkit implemented srcset is because of the performance it allows.

I wonder what HTML would look like if browser performance was the primary concern? Is this truly the best argument for srcset, that browsers can parse the page quicker?

Probably the fastest HTML to render would be something like this:

<img src="foo" border="2px solid red" margin="10px" width="100px" height="100px" align="left">

There are good reasons we've moved away from that, even though it hits performance. It just seems wrong to be tying image resolutions to particular screen resolutions and trying to specify sources in a comma separated list with arbitrary resolution scales included, that's pretty nasty and not at all like other parts of HTML (which generally has been kept surprisingly clean if spartan in terms of features). I'd rather use js to load hires than use this or just serve everyone hires.

It reminds me of the horrible multiple resolution handling on iOS, which is probably what inspired it (@2x etc). I think there are now 15 different icon sizes for iOS [1] because of this insistence on tying resolutions to device specs. I can imagine issues with devices lying about resolution or ending up between x1 and x2 and not getting bigger images just because their resolution isn't quite x2 etc.

[1] http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes

I see the concern on loading - if…

> Like all rules, once you understand them and know what you are doing, then it may make sense to break them.

I actually agree with this whole heartedly. I think we're on the same wavelength here. Just like all good literature violates supposed rules of good form for the language.

But I think that following OS conventions is the wrong set of rules to learn and target. There are already good interface guidelines. It just so happens that some OSs (OSX) do a particularly good job at following those guidelines.

It reminds me of this http://catb.org/esr/writings/cups-horror.html

The meta-problem here is that the configuration wizard does all the approved rituals (GUI with standardized clicky buttons, help popping up in a browser, etc. etc.) but doesn't have the central attribute these are supposed to achieve: discoverability. That is, the quality that every point in the interface has prompts and actions attached to it from which you can learn what to do next. Does your project have this quality?

A good interface can look like anything so long as it follows good GUI conventions. And fortunately most OSs follow pretty good GUI conventions so targeting the conventions of that platform are in a way following good GUI conventions transitively. I just wouldn't limit myself as to say that the measure of important should be following OS conventions when it should really be following interface conventions. The CUPS story I linked to brings that problem directly to the forefront.…

I think you missed that the App Store is an iPhone afterthought -- the original, still supported, intent was to support HTML5 apps installed to your home screen.

You can write your own software, run it on any iOS device, share it with others, even sell it without anyone's permission.

Here is a PacMan style game, for example:

http://mrgan.tumblr.com/post/257187093/pie-guy

If that's not "hobbyist" friendly, I don't know what is.