Live data from Hacker News

WTFWG

timkadlec.com

31–38 of 38 posts

Re: WTFWG

#31
What about mixing both proposals:

    
      
    
Inner content should not be rendered by clients supporting the picture tag. This allows for a natural fallback without using , like we already have for canvas.

I'm not a great fan of "picture" either. We already have . Why not ?

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.

Re: WTFWG

#32

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.

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.

Re: WTFWG

#33
post #11

Earlier quoted context omitted.

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.

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.

Re: WTFWG

#34
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…

There is no "Apple conspiracy angle". Nobody has suggested Apple were forcing their implementation.

They aren't even angry that they spent months for the proposal to be rejected.

They're angry that they go through the standard processes for months, when vendors seem to just throw an idea out there and it's in the spec within days.

Nobody's blaming Apple. It just appears from the outside that there is a rule for vendors, and a rule for everyone else.

Re: WTFWG

#35

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…

Trolls Kill HN.

Re: WTFWG

#36
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?

Re: WTFWG

#37

What about mixing both proposals: Inner content should not be rendered by clients supporting the picture tag. This allows for a natural fallback without using , like we already have for canvas. I'm not a great fan of "picture" either. We already have . Why not ? 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 mu…

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

Re: WTFWG

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