On Mon, Mar 2, 2015 at 8:46 AM, Michael A. Peters <mpet...@domblogger.net> wrote: > Dear WHATWG, > > Scrap the srcset attribute. > > Traditionally in HTML, and in every instance of XML I have personally worked > with, an element's attribute is a key=value pair. > Okay the type attribute for source node in audio and video, sometimes it has > codecs specified there too - but that's the only example I can think of, and > even there, it is rarely actually used. Usually it is just simply used as a > key=value pair with the mime type, even by me and I know how to specify the > codec. > > But srcset is a multi-level array. The first array is a , delimited string - > and each element between the commas is itself a space delimited array. > > When has that kind of attribute ever been previously used in HTML ?? > I suppose the type attribute with audio and video where you can optionally > specify codec, but that's all I can think of, and there it isn't > multi-dimensional. > > srcset is a mistake. A mistake that will result in errors on the web because > it is much more difficult to understand than the traditional key=value pair > that is traditional in HTML and XML. > > key='multi level array of values' is just plain conceptually wrong.
srcset may be on the high end of complexity for HTML, but it's square in the middle for CSS. CSS doesn't seem to confuse and confound people (at least, its syntax generally doesn't). > -=- > > Secondly, you are doing the source child of the picture element wrong. > > Who the hell am I to tell you that you are doing it wrong? > > I'm a user that thinks what you currently have is over-complicated and > ridiculous. > > When in the history of HTML has an element's legal attributes been dependant > upon what the parent element is? > > I can't think of a case until the picture element. <meta>, for instance. But just because something is the first doesn't mean it's a bad thing. (We didn't particularly like it when designing, either, but it was better than breaking precedent and having <picture> use a *different* child element than <audio> and <video>.) > The picture element should have the source element as a child, and this is > how it should be done: > > [picture] > [source src="ImageHD.webp" type="image/webp" media="(min-width: 1024px)" > /] > [source src="ImageHD.jpg" type="image/jpeg" media="(min-width: 1024px)" > /] > [source src="ImageHD.webp" type="image/webp" media="(min-width: 800px)" > res="2x" /] > [source src="ImageHD.jpg" type="image/jpeg" media="(min-width: 800px)" > res="2x" /] > [source src="Image.webp" type="image/webp" media="(min-width: 800px)" /] > [source src="Image.jpg type="image/jpg" media="(min-width: 800px)" /] > [source src="Image.webp" type="image/webp" res="2x" /] > [source src="Image.jpg" type="image/jpg" res="2x" /] > [source src="ImageMobile.webp" type="image/webp" /] > [source src="ImageMobile.jpg" type="image/jpg" /] > [img src="Image.jpg" alt="[cow patty in field]" /] > [/picture] > > The client selects the first image where it matches all type, media query, > and resolution attributes that are specified. > > Notice that it keeps the simple to understand key=value pair for the > attributes, and it keeps compatability with source tag as it has already > been used with audio and video for years now. As it turns out, this kind of syntax is extremely verbose for common cases, and doesn't even work all that well when you get down to it. Your example can be boiled down to the following: <picture> <source type="image/webp" sizes="50%" srcset="ImageMobile.webp 400w, Image.webp 800w, ImageHD.webp 1600w"> <source sizes="50%" srcset="ImageMobile.jpg 400w, Image.jpg 800w, ImageHD.jpg 1600w"> <img src="image.jpg" alt="cow patty in field"> </picture> (I'm making some assumptions about your image size and how it'll be displayed. Obviously you can tweak that.) This is much easier to write and to maintain, and responds better - it lets the client make the decision of which version it wants based on more than just screen size, and it handles 3x and higher screens automatically. ~TJ
