WTFWG | Hacker News Reader

WTFWG

timkadlec.com

205 pointsjacobr36 comments

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.

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.

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.

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.

Is the issue here that a worse idea got accepted, or that a better idea got accepted over one that took much longer to develop?

If the proposed idea from this "single Apple employee" is obviously inferior, then that does indeed sound like a problem. But apparently the idea was discussed for a few days. So it doesn't sound like it's conclusively worse.

When it comes to programming -- especially creating the spec for something this fundamental -- then the best idea should win, irrespective of how long that idea took to be born. If you're cheesed because months of discussion and (semi-)consensus was bumped by a better solution that took days to be discussed, then that's not a problem, that sounds like exactly what should happen.

The point of TFA is that there was a long debated solution in the works that got tossed aside in favour of something a vendor representative chucked in.

How can you determine if it's technically superior if you discriminate on the basis of the source of the feature? Choosing between death-by-committee or trusted-auto-approval is not hard.

i.e. the vendors, and not the community of people interested, are in effect (if not necessarily intentionally) dictating the process. The upshot is we'll see features that benefit browser vendors (whether in ease of implementation or insert-conspiratorial-nefarious-Apple-vertical-integration) rather than features that benefit web developers.

Yes, but the long-debated solution settled on a solution that obviously wasn't very strong, if it can't withhold an external suggestion like this.

Mostly what I get from the article is the sense that people are put off not because of how the Apple proposal was put up for discussion, but that they spent months of their time discussing something, and feel like they got nothing for it. And that rings false to me; either that discussion was useful and helped them identify something superior Apple proposal, or the discussion was a waste of time and resulted in nothing useful, in which case they should just be mad at themselves (or the process).

I don't get the Apple conspiracy angle here. They want something that works better with WebKit? So that means that all of iOS, Android, Chrome and Safari browsers benefit.

>Yes, but the long-debated solution settled on a solution that obviously wasn't very strong, if it can't withhold an external suggestion like this.

The implication is that the long-debated solution lost out not because it was inferior but because it didn't come from a browser vendor. After all, the difference in timescale and hoop jumping is stark.

And the implication of that is that no browser vendors were involved in the months-long discussion. If that's true, then that seems like a huge mistake on the part of the committee.

There is no "Apple conspiracy angle". Nobody has suggested Apple were forcing their implementation.

They aren't even angry that they spent months for the proposal to be rejected.

They're angry that they go through the standard processes for months, when vendors seem to just throw an idea out there and it's in the spec within days.

Nobody's blaming Apple. It just appears from the outside that there is a rule for vendors, and a rule for everyone else.

How many mainstream browser developers were involved in the group working on the PICTURE element? Isn't it a little backwards to have the standards group dictate to the browsers how new features should work? I thought these things were supposed to start with working code.

Who do you think is in the standards groups? The browser makers. There isn't enough representation from the people who actually will be using these features, and it seems that even when those people can get a word in edgewise it is ignored.

> The developer community did everything asked of them. They followed procedure, they thoroughly discussed the options available. They were careful enough to consider what to do for browsers that wouldn’t support the element—a working polyfill is readily available. Their solution even emulates the existing standardized audio and video elements. Meanwhile an Apple representative writes one email about a new attribute that only partially solves the problem and the 5 days later it’s in the spec.

So yes, it appears that not only does the standards discussion start with working code, it ends with it.

In this case, the community group that was created did not include browser implementors or people who actively contribute to mainline HTML standards, and was not advertised on forums that they frequent. In light of this, their expectation that their proposal would be taken up wholesale was somewhat misguided.

Actually, that's one of the guiding design principles for the WHATWG: ease of implementation for a developer is supposed to trump ease of implementation for a vendor every single time. How hard a specific piece of the spec is to implement in a browser is supposed to matter less than how hard it is for a developer to implement that part of the spec in code and on down the line.

Unfortunately, the WHATWG seems to do whatever the heck it wants to most of the time and having an idea collaborated on by the development community (the <picture> element) or working code (the <time> element from that whole fiasco a few months back) doesn't seem to amount to much.

It's human nature for browser makers to value ease of implementation over ease of use. But to basically tell developers to move the discussion elsewhere and then ignore that discussion is not right. There will only be about a half-dozen implementations but potentially millions of uses in the future, so which side should get more consideration?

Another take: http://news.ycombinator.com/item?id=3978488

Thanks for posting this---this is a much better rundown of the full background for those of us who haven't been following very closely.

I read this, and i don't take away "our proposal was better", I take away "i'm upset they didn't do what we wanted, despite the fact that we wanted it".

Reading the community group, i don't see some "broad support", i see a few web developers saying "this sucks, this thing is better", and on the other side, a few browser vendors saying "no that sucks, this is better".

Someone has to make a real decision, and that seems to be what happened here (from what i understand, the W3C process usually ended up in everyone talking about their feelings for 6-10 years)

BTW, nowhere in the discussion, do i see anyone on the "picture is better" side describe any of the arguments against it, and it seems to hard to believe it is so amazingly perfect that nobody had any issues to with.

TL;DR If this article is representative of the attitude and arguments put forth in favor of the suggested proposal, it is completely understandable that something else was done.

What about mixing both proposals:

    <picture alt="A giant stone" src="stone.jpg, stone@2x.jpg, stone@600w.jpg">
      <img src="stone.jpg" />
    </picture>

Inner content should not be rendered by clients supporting the picture tag. This allows for a natural fallback without using <noscript>, like we already have for canvas.

I'm not a great fan of "picture" either. We already have <figure>. Why not <image>?

The ideal solution IMO would be something like Progressive JPEG (with less artifacts): you serve a single high-quality image, and the browser downloads as much of it as it sees fit for the situation. Smaller images would be created from a large, lower quality download.

> The ideal solution IMO would be something like Progressive JPEG (with less artifacts): you serve a single high-quality image, and the browser downloads as much of it as it sees fit for the situation. Smaller images would be created from a large, lower quality download.

I thought about that as a solution as well. The issue though is that taking the half resolution portion of a progressive JPEG or PNG will result in significant aliasing.

The browser vendors are the only group with power here. I'd rather have a spec that isn't perfect but actually gets implemented than a spec that is perfect but doesn't.

What "Standards" committee today actually represents the persons they suppose to represent, and not the interests of their sponsors? See "membership" (http://www.w3.org/Consortium/membership-faq) info, if you'd like to join.

I mean, it's not at all like the situation MS was in with OOXML and ECMA, right?

Short of convincing principal browser developers that your idea is the best way to go, I don't see how individuals not associated with a browser project can have any impact in these decisions. It felt mostly useless when I tried to offer feedback and suggestions as an individual.

Maybe now we know to talk to Ian if we want to get things fixed.

Dude, it's called democracy! First, people talk about and discuss all proposed solutions. Then they vote and one solution get a majority. Then, the guy who controlls the money (in this case Apple) comes along and decides for you.

Or did I misunderstand something about how democracy works?

I think this article is timely in the sense that it calls attention to an issue that is (hopefully) being debated right now. And that means that developers seeing this referenced on HN and other sites will realize that now is an opportunity to engage their brains and give feedback on this issue which will affect lots of us.

The result of the "Grep the Web" that was requested somewhere in that is available:

http://blekko.com/webgrep?page=view&id=8638947e26c2cf16e...

Aww, when I saw the title of the link I thought that the World Time Format[1] was going to solicit some sort of public advice on adding time zones and other things which need streamlining.

[1] see e.g. http://www.alphabetclock.com/fulldatetime.html .

Context: WHATWG: Web Hypertext Application Technology Working Group WTFWG: Wiskey Tango Foxtrot

Regarding the issue: rough consensus, working code.

And beware of monopolists bearing Web standards.

The comments are pure gold. From Paul Irish:

Mike Taylor (at Opera) offered this advice, which I think is smart and on point:

“1) don’t get your feelings hurt 2) respond to srcset on WHATWG and list technical objections that <picture> solves”

Yes, please have a discussion on this on the list now, after it has been added. Ugh.

Why not? Specs can change, and the WHATWG HTML spec in particular has a history of changing initially poorly designed features based on additional feedback.

Reply on news.ycombinator.com