Hi David,
Welcome to the group! :)
On Tuesday, October 16, 2012 at 4:11 PM, David Demaree wrote:
> I'm coming in late to this discussion and am new to the group, so forgive me if I'm off base. In my opinion, while it's silly to try to solve specific problems that don't exist yet, if there could be an elegant way for <picture> to allow developers to choose newer image formats (raster or vector) without sacrificing backward compatibility, that can only be a win. I'd love to experiment with WebP, or to have a more reliable way to start using SVG without breaking IE 8/Android < 3.0 compatibility. A type attribute could be a good vehicle for this kind of forward-looking experimentation.
Agreed. The discussion is centered around if this is a MUST, SHOULD, or MAY requirement in the UC&R document; or if it's even too early to be throwing RFC2119 keywords around (!).
Having said that, as a group, we cannot fixate solely on <picture>. It may be <picture> is the right solution, but maybe img@srcset is… or maybe there is another solution that we haven't even thought out yet!
We need to be open to new ideas as we try to understand the problem space (otherwise, we have a solution looking for a problem, which is bad). Furthermore, if we get too precious about <picture>, we will take it personally every time someone points out issues with it - in other words, everyone should embrace img@srcset as tightly as you do <picture>, or potentially any other solution that comes along (so long as the solution meets our use cases and requirements).
> For me, the SVG use case is even more compelling than WebP. Many developers, myself included, are forced to move images that rightly should be part of their HTML content into CSS background images because CSS's cascading fallback support is robust, while HTML's is nonexistent.
Agreed. This, along with art direction, is at the heart of our UC&R document.
> WebP vs. PNG vs. Microsoft's JPEG-whatever is interesting, but ultimately could result in unnecessary fragmentation in an area of web technology that's been stable for years. (And I will allow, one fear I have about a type specifier is that then we'll all be expected to produce "bulletproof" responsive images markup. I certainly don't want images to turn into Web Fonts 2: Responsive Boogaloo.)
Oh, we so need to trademark that! that's so going on a t-shirt! :D
> But the ability to start using vector formats, or for vendors to introduce new ones without a huge adoption curve, could be transformative.
>
Agreed. But lets again try not to speculate too much and stick to the problems of the here and now - we don't need to solve all of the world's problems with adopting new image formats (though we might do so as a side effect of our good work!), we just want "responsive images" now.
--
Marcos Caceres