

WTFWG - jacobr
http://timkadlec.com/2012/05/wtfwg/

======
modeless
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
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
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
No doubt, the hasLayout IE issue comes to mind whenever I think of
implementation bugs. Implementation bugs are the worst.

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

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

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

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

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

------
sjs382
Another take: <http://news.ycombinator.com/item?id=3978488>

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

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

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

------
officialchicken
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?

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

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

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

[http://blekko.com/webgrep?page=view&id=8638947e26c2cf16e...](http://blekko.com/webgrep?page=view&id=8638947e26c2cf16e32d3487fc187ac5)

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

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

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

