WTFWG

http://timkadlec.com/2012/05/wtfwg/

by jacobr • 14 years ago

205 36 14 years ago

timkadlec.com

eslachance• 14 years ago

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

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

tptacek• 14 years ago

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.

dmethvin2• 14 years ago

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.

othermaciej2• 14 years ago

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.

_ajm• 14 years ago

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.

dmethvin2• 14 years ago

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?

shaggyfrog2• 14 years ago

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.

phillmv2• 14 years ago

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.

shaggyfrog2• 14 years ago

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.

WiseWeasel• 14 years ago

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.

revelation• 14 years ago

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.

othermaciej2• 14 years ago

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.

officialchicken• 14 years ago

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?

dredmorbius• 14 years ago

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.

modeless• 14 years ago

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

JoachimSchipper• 14 years ago

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.

armandososa• 14 years ago

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.

mst• 14 years ago

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.

Udo2• 14 years ago

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.

hoppipolla• 14 years ago

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

youngtaff• 14 years ago

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.

drostie• 14 years ago

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 .

sjs382• 14 years ago

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

blahedo• 14 years ago

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.

DannyBee• 14 years ago

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.

rabidsnail• 14 years ago

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.

ricardobeat• 14 years ago

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.

danbee• 14 years ago

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

yaix• 14 years ago

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?

adaml_623• 14 years ago

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.

WTFWG

Related Stories