Hacker News new | past | comments | ask | show | jobs | submit login

As an author, I think the quoted W3C design principles are wrong, and putting implementors before authors is, counterintuitively, right. According to the "worse is better" philosophy, "It is more important for the implementation to be simple than the interface"[1], and I believe that's correct. Complex implementations invite bugs and compatibility problems, which ultimately hurt implementors and authors alike.

[1] http://www.jwz.org/doc/worse-is-better.html




In this case, a complex interface will force thousands or millions of sites to handle that particular bad design, while a complex implementation will force a handful of browser makers to properly implement it - something with which they have quite a bit of experience. There is no doubt that the feature could be shipped either way. Worse is not always better.


History says that if the implementation is complex the browser makers will all implement it differently.

I'll take "deficient, but identically deficient on every browser I support" over "brilliant but only works correctly in Chrome v432.654+" any day.


Web developers have quite a bit of experience coping with shitty implementations as well. I prefer a shitty implementation now, that a perfect one sometime circa 2021.


No doubt, the hasLayout IE issue comes to mind whenever I think of implementation bugs. Implementation bugs are the worst.


Both proposals are horrible in their current form.

The <picture> element is overly complex with its media query mechanism, and perhaps even worse than that, features an obnoxious piece of redundancy by requiring the legacy <img> tag AND a separate way to declare the default image at the same time. The srcset attribute has a highly questionable syntax and ridiculously expresses resolution hints in terms of multiples of the main image.

None of them are really elegant and simple, not even in a better-is-worse kind of way; none of them should have made it into the spec.


Do you have a better proposal?

The use cases it needs to address are mostly documented at [1] although there are some missing (people are currently putting together a wiki page [2]) e.g. in order for image prefetching to work the decision on which image to choose can't depend on layout (i.e. it can only depend on things that are likely to be known when the markup is first parsed and before any CSS is applied). There is further discussion at [3].

[1] http://www.w3.org/community/respimg/2012/04/16/summary-of-us... [2] http://www.w3.org/wiki/Images [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May...


There is a reason why every one of those decisions needs to be discussed by a lot of experts for an extended amount of time, which apparently hasn't happened in this case.

But for what it's worth I strongly believe the <picture> concept has a core worth iterating on, the kinks I mentioned could be ironed out easily. Simplify the media query mechanism (there is room for extending it later) and get rid of the duplicate default declarations.

srcset on the other hand is a grossly misguided attempt by Apple to copy an iOS programming mechanism over to the web, it doesn't really have any merits by itself.


This is a very elegant proposal that needs work but has some merit and I'd like to see it built on http://nicolasgallagher.com/responsive-images-using-css3/

The current srcset proposal has terse syntax and just seems to be recreating media queries in another form.

Surely we should adopt a media-queries based approach and fixing media-queries where they are broken.


Moving images to CSS works in some cases, but the ability to specify an inline img in HTML is very useful in general. As a thought experiment, imagine replacing all <img> tags with CSS. That's essentially what this is doing.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: