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

21–30 of 38 posts

Re: WTFWG

#21

Post by btipling »

armandososa wrote: post #20
JoachimSchipper wrote: post #18

Earlier quoted context omitted.

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.

Re: WTFWG

#22

Post by hoppipolla »

Udo wrote: post #19
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…

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

Re: WTFWG

#23

Post by Udo »

hoppipolla wrote: post #22
Udo wrote: post #19

Earlier quoted context omitted.

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…

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…

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

Re: WTFWG

#24

Post by youngtaff »

Udo wrote: post #19
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…

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.

Re: WTFWG

#25

Post by wycats »

youngtaff wrote: post #24
Udo wrote: post #19

Earlier quoted context omitted.

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…

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 tags with CSS. That's essentially what this is doing.

Re: WTFWG

#26

Post by blahedo »

sjs382 wrote: post #17

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.

Re: WTFWG

#27

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

Re: WTFWG

#28

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

Re: WTFWG

#29

Post by othermaciej »

dmethvin wrote: post #6
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.

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 f…

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.

Re: WTFWG

#30

Post by othermaciej »

revelation wrote: post #9

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