5 ms·

WTFWG

205 points by jacobr 14y ago

eslachance 14y ago
The result of the "Grep the Web" that was requested somewhere in that is available: http://blekko.com/webgrep?page=view&id=8638947e26c2cf16e32d3487fc187ac5 http://blekko.com/webgrep?page=view&id=8638947e26c2cf16e...
tptacek 14y 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.
- dmethvin 14y 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.
  - othermaciej 14y 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 14y 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.
dmethvin 14y 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?
shaggyfrog 14y 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.
- phillmv 14y 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.
  - shaggyfrog 14y 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 14y 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 14y 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.
- othermaciej 14y 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 14y 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 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 14y 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 14y 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 http://www.jwz.org/doc/worse-is-better.html
- JoachimSchipper 14y 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 14y 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.
    - btipling 14y ago
      No doubt, the hasLayout IE issue comes to mind whenever I think of implementation bugs. Implementation bugs are the worst.
  - mst 14y 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.
- Udo 14y 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.
drostie 14y 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 http://www.alphabetclock.com/fulldatetime.html .
sjs382 14y ago
Another take: http://news.ycombinator.com/item?id=3978488 http://news.ycombinator.com/item?id=3978488
- blahedo 14y 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 14y 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 14y 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 14y 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 14y 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 14y 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 14y 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.

205 points by jacobr 14y ago

The result of the "Grep the Web" that was requested somewhere in that is available: http://blekko.com/webgrep?page=view&id=8638947e26c2cf16e32d3487fc187ac5 http://blekko.com/webgrep?page=view&id=8638947e26c2cf16e...

tptacek 14y 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.

dmethvin 14y 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.
- othermaciej 14y 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 14y 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.

dmethvin 14y 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?

shaggyfrog 14y 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.

phillmv 14y 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.
- shaggyfrog 14y 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 14y 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 14y 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.

othermaciej 14y 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 14y 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 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 14y 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 14y 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 http://www.jwz.org/doc/worse-is-better.html

JoachimSchipper 14y 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 14y 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.
  - btipling 14y ago
    No doubt, the hasLayout IE issue comes to mind whenever I think of implementation bugs. Implementation bugs are the worst.
- mst 14y 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.
Udo 14y 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.

drostie 14y 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 http://www.alphabetclock.com/fulldatetime.html .

sjs382 14y ago

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

blahedo 14y 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 14y 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 14y 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 14y 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 14y 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 14y 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 14y 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.