The Tyranny Of Web Standards(kendoui.com)
kendoui.com
The Tyranny Of Web Standards
http://www.kendoui.com/blogs/teamblog/posts/12-05-24/responsive_images_and_the_tyranny_of_web_standards.aspx
7 comments
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.
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?
"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.
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.
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?
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.
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.
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!
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!
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.
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."
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.
Very true.
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="[email protected] 1600w 1200h" width=800 height=600 />
That is a ton cleaner than dealing with <picture> which completely breaks most browsers.
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="[email protected] 1600w 1200h" width=800 height=600 />
That is a ton cleaner than dealing with <picture> which completely breaks most browsers.
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">
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">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).
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).
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.
[deleted](1)
Update: 45 minutes later, top comment, no replies; is the answer "none of the major browser vendors vocally supported <picture>"?