Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WTFWG

timkadlec.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: WTFWG

#11

Post by phillmv »

shaggyfrog wrote: post #10
phillmv wrote: post #7

Earlier quoted context omitted.

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…

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…

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

Re: WTFWG

#12

Post by 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?

Re: WTFWG

#13

Post by _ajm »

tptacek wrote: post #3

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.

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 element) or working code (the element from that whole fiasco a few months back) doesn't seem to amount to much.

Re: WTFWG

#14

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

Re: WTFWG

#15

Post by 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

Re: WTFWG

#18

Post by JoachimSchipper »

modeless wrote: post #15

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] ht…

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.

Re: WTFWG

#19

Post by Udo »

modeless wrote: post #15

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] ht…

Both proposals are horrible in their current form.

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

Re: WTFWG

#20

Post by armandososa »

JoachimSchipper wrote: post #18
modeless wrote: post #15

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] ht…

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.
Post reply on HN