Re: [whatwg] scrap the srcset attribute
On Mon, 02 Mar 2015 22:08:09 +0100, Michael A. Peters
wrote:
On 03/02/2015 09:47 AM, Tab Atkins Jr. wrote:
This is much easier to write and to maintain
Is it really?
With a simple key=value pair, I can:
$src = trim($node->getAttribute('src');
Then I can check it - if it is relative, I can change it to reference
the cdn. If it is not local, I can check to make the domain is valid,
check the domain is not in our black list, etc. and then replace the src
node with the cleaned version.
With srcset - I can still do that but then becomes more complex as there
is an initial array that then has to be exploded into secondary arrays
etc. and more complicated code is more prone to bugs.
We can add an API to expose the parsed candidates, or some such, but we
need to understand the use cases that it would solve. As Tab said, your
use case seems better solved on the server. Are there other use cases?
--
Simon Pieters
Opera Software
Re: [whatwg] scrap the srcset attribute
On Mon, Mar 2, 2015 at 1:08 PM, Michael A. Peters
wrote:
> On 03/02/2015 09:47 AM, Tab Atkins Jr. wrote:
>> This is much easier to write and to maintain
>
> Is it really?
>
> With a simple key=value pair, I can:
>
> $src = trim($node->getAttribute('src');
>
> Then I can check it - if it is relative, I can change it to reference the
> cdn. If it is not local, I can check to make the domain is valid, check the
> domain is not in our black list, etc. and then replace the src node with the
> cleaned version.
>
> With srcset - I can still do that but then becomes more complex as there is
> an initial array that then has to be exploded into secondary arrays etc. and
> more complicated code is more prone to bugs.
When designing the syntax, we optimized for authoring and updating by
hand, not for JS-based manipulation. That's a far lesser use-case.
You shouldn't be sending pages with that you intend to
change in ways that could be done server-side (all of the things you
mention qualify), as it defeats the preloader and causes users to send
multiple requests, degrading the user-experience significantly for no
real benefit.
> What happens if one of the sources has a typo involving a space, e.g.
>
> Big Image.jpg 2x
>
> instead of
>
> Big%20Image 2x
>
> With key=value that's easy to fix, but it is more complicated when a space
> is a delimiter in an array that is a sub-array.
>
> key=value is kiss and kiss has a lot of benefits.
Then you have an authoring error. The HTML validator will catch that.
Spaces in filenames are rare, luckily, as are commas, which is part of
why the syntax uses those.
We did consider "simpler" solutions like you're suggesting; they end
up sufficiently verbose and frustrating to write out that it's worth
the added complexity that we settled on.
~TJ
Re: [whatwg] scrap the srcset attribute
On 03/02/2015 09:47 AM, Tab Atkins Jr. wrote:
This is much easier to write and to maintain
Is it really?
With a simple key=value pair, I can:
$src = trim($node->getAttribute('src');
Then I can check it - if it is relative, I can change it to reference
the cdn. If it is not local, I can check to make the domain is valid,
check the domain is not in our black list, etc. and then replace the src
node with the cleaned version.
With srcset - I can still do that but then becomes more complex as there
is an initial array that then has to be exploded into secondary arrays
etc. and more complicated code is more prone to bugs.
What happens if one of the sources has a typo involving a space, e.g.
Big Image.jpg 2x
instead of
Big%20Image 2x
With key=value that's easy to fix, but it is more complicated when a
space is a delimiter in an array that is a sub-array.
key=value is kiss and kiss has a lot of benefits.
Re: [whatwg] scrap the srcset attribute
On Mon, Mar 2, 2015 at 8:46 AM, Michael A. Peters 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. , 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 use a *different* child element than and .) > 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: (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
[whatwg] scrap the srcset attribute
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. -=- 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. 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.
