

The Tyranny Of Web Standards - burke_holland
http://www.kendoui.com/blogs/teamblog/posts/12-05-24/responsive_images_and_the_tyranny_of_web_standards.aspx

======
tptacek
Which of the major browser vendors among Apple, Google, Mozilla, and Microsoft
supported <picture>? And by "support", I merely mean "vocal support on any
mailing list or standards document"; I don't mean "actually took the time to
implement".

 _Update: 45 minutes later, top comment, no replies; is the answer "none of
the major browser vendors vocally supported <picture>"?_

~~~
bsatrom
sorry for the delay. As far as I am aware, none of the browsers expressed
vocal and specific support for <picture>. In fact, as I understand it, a few
had reservations about the element, but these were not expressed to the
members of the Responsive Images Community Group either.

~~~
tptacek
So when we say "developers", we mean "web content developers", and when we say
things like "the expectation is that WHATWG (or whatever) will prioritize the
needs of developers over everything else", we're saying "we expect the browser
vendors to take dictation from the content developers"? And we think that's
reasonable?

~~~
bsatrom
"the expectation is that WHATWG (or whatever) will prioritize the needs of
developers over everything else"

Nope, not saying that at all.

"we expect the browser vendors to take dictation from the content developers"

Dictation no, participation yes.

And that is reasonable.

~~~
tptacek
Fair enough. But let me ask: what's your expectation as to "participation"?
How much more priority do you think a standards group decision, unimplemented
in any major browser, should get over a "feature request" bug filed in one of
their bug trackers?

~~~
othermaciej
Most of the browser vendors care about standards groups and are highly
influenced by what they say. Certainly that's true for WebKit-based browsers,
where I have some first-hand knowledge.

One dysfunction in this case is that the <picture> proposal was developed in a
splinter group that didn't include browser vendor representatives and thus was
somewhat disconnected from the larger conversation.

I will also add that both browser vendors and standards groups care more about
people's use cases than their concrete syntax ideas, and ideally people making
proposals should learn to think that way as well.

------
kibwen
Was afraid this was going to be one of those "damn it why doesn't everyone
just use webkit already?!??!" posts, and was happily surprised. The points are
good and well-reasoned.

There are problems with the web standards process, to be sure. But in my mind,
the most interesting part of the whole affair is that _developers get any
input whatsoever_. I don't recall MS ever asking for input on the Windows API,
nor Apple on Cocoa (if I'm wrong, links are appreciated). We're helping to
build a major platform here, in real time. That's really neat!

------
burke_holland
Standards are a necessary tax, just like process. If everyone could just get
in a room and do the right thing, we wouldn't have any issues. Any time you
throw a governing body at anything, you are going to have a certain amount of
inefficiency.

------
codgercoder
However bad instances turn out, we should view the standards process the way
Churchill viewed democracy: "Democracy is the worst form of government, except
for all those other forms that have been tried from time to time."

------
toddanglin
Good quote from the blog: "The truth is this: web standards are often a
tyranny to developers and designers alike. By themselves, they constrain just
as much as they free, and they are designed not for our benefit, but primarily
for the benefit of platforms and software on which our solutions run."

Very true.

------
jcampbell1
I just learned about this, but srcset seems better than <picture> for
backwards compatibility reasons.

To make images on the ipad3 look great, all we have to do is change:

<img src="photo.jpg" width=800 height=600 />

to:

<img src="photo.jpg" srcset="photo@2x.jpg 1600w 1200h" width=800 height=600 />

That is a ton cleaner than dealing with <picture> which completely breaks most
browsers.

~~~
bsatrom
I agree that srcset has its advantages, and like I said in the post, I expect
that it will make a fine solution in the long-run, and I'm glad this problem
is being addressed.

One minor point, however, is that the strawman <picture> proposal was meant to
be equally backward compatible through the use of a child <img> tag that would
only display in unsupported browsers, as <video> works today:

<picture alt="cool-image">

    
    
      <source src=hires.png media="max-width:1920px">
      <source src=midres.png media="min-width:800px">
      <source src=lores.png>
    
      <!-- fallback for browsers without support -->
      <img src=midres.png alt="cool-image">

</picture>

~~~
jcampbell1
That is not nearly as backwards compatible because you are adding markup. Will
the picture element inherit it's style from the inner img element? I don't
think so. Now you have to go mess around with the CSS and have two different
pathways for the style to be applied based on the browser.

Also, <video> fallback doesn't really work. If you have an h264 video, there
is no good way to make it play in all browsers with markup alone (Firefox
won't fallback to flash).

~~~
bsatrom
I don't disagree at all. Like I said in the post, srcset will one day make a
fine solution and given the right input, might even end up being developer-
friendly. I hope that ends up being the case, because the current syntax is
cryptic and vague.

