Intent to implement - img srcN attribute

409 views
Skip to first unread message

Yoav Weiss

unread,
Oct 13, 2013, 6:38:10 PM10/13/13
to blink-dev
Primary eng email
yo...@yoav.ws

Spec

http://tabatkins.github.io/specs/respimg/Overview.html

Public standard discussion
http://lists.w3.org/Archives/Public/public-respimg/2013Sep/0087.html

Summary

SrcN is a responsive images solution which addresses all 3 major use-cases within a single syntax. It addresses DPR switching (like srcset), art-direction (like picture) and viewport dimensions based switching is a way that is superior to previous proposals.

Motivation
New device form factors and screen DPRs are added to the market on a regular basis. Serving the same image resources to all devices (which may display them in differing dimensions and at different DPRs) is wasteful, and hurts Web performance. It often also results in images that
are presented to the user in a sub-optimal manner.

This feature will give authors the tools to address this issue, and serve the image resources most appropriate to their user's DPR, viewport size or various Layout breakpoints, without resorting to hacks that have their own performance trade-offs.

Compatibility Risk

Unknown.
Mozilla are looking into the feature.
Other browser vendors haven't yet expressed public opinion regarding the feature.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?
crbug.com/306893

Link to entry on the feature dashboard
http://www.chromestatus.com/features/4582090154704896

Requesting approval to ship?
No.

Elliott Sprehn

unread,
Oct 13, 2013, 7:40:11 PM10/13/13
to Yoav Weiss, blink-dev
Can we remove srcset then? The spec says this replaces that feature, and it seems bad to have so many different ways to do the same thing (and maintain).

Adam Barth

unread,
Oct 13, 2013, 8:21:40 PM10/13/13
to Elliott Sprehn, Yoav Weiss, blink-dev
Given the history of this working group, I would like to hear public feedback from other browser vendors before implementing this feature at this time.  In particular, is Apple interested in implementing this feature in Mobile Safari?

Adam

Philip Rogers

unread,
Oct 14, 2013, 4:22:45 PM10/14/13
to Adam Barth, Elliott Sprehn, Yoav Weiss, blink-dev
I would like to avoid implementing both srcset and srcN simultaneously, even though the spec allows for it. I think doing so would hurt web compatibility, and the conflict resolution between srcset and srcN doesn't seem easy on authors.

I agree with Adam here about waiting for feedback from other vendors.

Tab Atkins Jr.

unread,
Oct 31, 2013, 5:30:43 PM10/31/13
to Adam Barth, Elliott Sprehn, Yoav Weiss, blink-dev
On Sun, Oct 13, 2013 at 5:21 PM, Adam Barth <aba...@chromium.org> wrote:
> Given the history of this working group, I would like to hear public
> feedback from other browser vendors before implementing this feature at this
> time. In particular, is Apple interested in implementing this feature in
> Mobile Safari?

Marcos Caceres is implementing this in Firefox.

~TJ

mar...@marcosc.com

unread,
Nov 1, 2013, 2:13:27 PM11/1/13
to blin...@chromium.org, Adam Barth, Elliott Sprehn, Yoav Weiss

The person who is going to lead the implementation of src-n at Moz will be John Schoenick; I'll help out where I can. 

Yoav Weiss

unread,
Nov 1, 2013, 3:23:47 PM11/1/13
to Marcos Caceres, blink-dev, Adam Barth, Elliott Sprehn
Regarding feedback from the WebKit project, I've started a thread on webkit-dev and asked some questions on #webkit.

On the bright side, they seemed receptive to the extra use-cases the syntax handles. Quoting rniwa on #webkit: "i think the feature addresses a very important use case"
On the other hand, they're not very fond of the multi-attribute syntax and would prefer if it was limited to a small finite number of attributes (e.g src-1 till src-9), or replaced by a list of lists.

Feedback I gathered on the RICG suggests that authors don't particularly mind the limitation on the number of attributes, but consider a huge "list of lists" attribute to be difficult to read and write.

Adam Barth

unread,
Nov 1, 2013, 3:37:31 PM11/1/13
to Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn
My perspective on this topic is that we've been bikeshedding this topic for a long time.  We should just ship srcset and be done with it.  Having every browser ship srcset is much better for authors than waiting around for the best possible shade of blue.

Adam

Message has been deleted

Ilya Grigorik

unread,
Nov 1, 2013, 5:40:32 PM11/1/13
to Adam Barth, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn

On Fri, Nov 1, 2013 at 12:37 PM, Adam Barth <aba...@chromium.org> wrote:
My perspective on this topic is that we've been bikeshedding this topic for a long time.  We should just ship srcset and be done with it.  Having every browser ship srcset is much better for authors than waiting around for the best possible shade of blue.

I'm 100% behind the "we've been bikeshedding this topic for long enough, let's ship something". That said, one thing to keep in mind is that if we ship srcset, the bikeshedding will continue, as it does not address all of the required use cases, and may end up much harder to extend. In that regard, src-N offers a *much* better story.

Adam Barth

unread,
Nov 1, 2013, 5:51:30 PM11/1/13
to Ilya Grigorik, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn
src-N is wacky and is going to take time before folks agree that it's a good idea.  If srcset addresses 80% of the use cases, then I think we should just ship srcset and worry about the rest of the use cases in the future.  Honestly, the primary use case here is supplying two images: one for device-pixel-ratio 1 and one for device-pixel-ratio 2.  Everything else is of marginal benefit.

Adam

Alexandre Elias

unread,
Nov 1, 2013, 9:36:15 PM11/1/13
to Adam Barth, Ilya Grigorik, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn
I'm not sure I agree that devicePixelRatio 2 is overwhelmingly more important than the others (even though it is the most common). Take a look at the variety of ratios documented on http://bjango.com/articles/min-device-pixel-ratio/ .  3 is already the typical ratio of high-end phones like the Galaxy S4 and Nexus 5, and will probably become increasingly prevalent in the next few years.

Yoav Weiss

unread,
Nov 4, 2013, 6:24:10 AM11/4/13
to Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
I've discussed srcN with WebKit's kling on #webkit: http://pastebin.com/c5smGv6Q

He (as well as rniwa in a previous discussion) seems supportive of the use cases. He will support the feature if it is limited to a small number of possible attributes, e.g. src1-src9.
The RICG will be supportive of such a limitation, if it speeds up adoption, as it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)

Marcos Caceres

unread,
Nov 4, 2013, 7:21:11 AM11/4/13
to Yoav Weiss, Adam Barth, Ilya Grigorik, blink-dev, Elliott Sprehn, Tab Atkins Jr.



On Monday, November 4, 2013 at 11:24 AM, Yoav Weiss wrote:

> I've discussed srcN with WebKit's kling on #webkit: http://pastebin.com/c5smGv6Q
>
> He (as well as rniwa in a previous discussion) seems supportive of the use cases. He will support the feature if it is limited to a small number of possible attributes, e.g. src1-src9.
> The RICG will be supportive of such a limitation, if it speeds up adoption, as it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)

Here is a small sample of the number of sources being used by a small range of sites (not exclusively looking at art direction):
http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0019.html

The range in this very small study is from 2-6. *A larger study would obviously be needed as the sample is way to small to draw any conclusions from, but thought I would add it to the discussion as a data point*.

Would be happy to expand the sample to make is a bit more statistically significant, if people think it would help.


--
Marcos Caceres





Tab Atkins Jr.

unread,
Nov 4, 2013, 3:38:16 PM11/4/13
to Adam Barth, Ilya Grigorik, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn
On Fri, Nov 1, 2013 at 2:51 PM, Adam Barth <aba...@chromium.org> wrote:
> On Fri, Nov 1, 2013 at 2:40 PM, Ilya Grigorik <igri...@chromium.org>
> wrote:
>> On Fri, Nov 1, 2013 at 12:37 PM, Adam Barth <aba...@chromium.org> wrote:
>>> My perspective on this topic is that we've been bikeshedding this topic
>>> for a long time. We should just ship srcset and be done with it. Having
>>> every browser ship srcset is much better for authors than waiting around for
>>> the best possible shade of blue.
>>
>> I'm 100% behind the "we've been bikeshedding this topic for long enough,
>> let's ship something". That said, one thing to keep in mind is that if we
>> ship srcset, the bikeshedding will continue, as it does not address all of
>> the required use cases, and may end up much harder to extend. In that
>> regard, src-N offers a *much* better story.
>
> src-N is wacky

I'd love to discuss why you think it's wacky, either here or in a
private conversation.

> and is going to take time before folks agree that it's a good
> idea. If srcset addresses 80% of the use cases, then I think we should just
> ship srcset and worry about the rest of the use cases in the future.
> Honestly, the primary use case here is supplying two images: one for
> device-pixel-ratio 1 and one for device-pixel-ratio 2. Everything else is
> of marginal benefit.

As Alexandre says, 3x is already a thing to start worrying about. The
art-direction cases are reasonable, and very clumsy in srcset. The
variable-width images cases is even clumsier in srcset.

On Fri, Nov 1, 2013 at 12:23 PM, Yoav Weiss <yo...@yoav.ws> wrote:
> On the bright side, they seemed receptive to the extra use-cases the syntax
> handles. Quoting rniwa on #webkit: "i think the feature addresses a very
> important use case"
> On the other hand, they're not very fond of the multi-attribute syntax and
> would prefer if it was limited to a small finite number of attributes (e.g
> src-1 till src-9), or replaced by a list of lists.
>
> Feedback I gathered on the RICG suggests that authors don't particularly
> mind the limitation on the number of attributes, but consider a huge "list
> of lists" attribute to be difficult to read and write.

I'm curious as to *why* WebKit folk want a finite set of attributes so bad.

~TJ

Rik Cabanier

unread,
Nov 4, 2013, 4:08:20 PM11/4/13
to Tab Atkins Jr., Adam Barth, Ilya Grigorik, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn
From Ryosuke Niwa:
If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10.
so that we can enumerate all parsed attributes statically at the compilation time.
 
So it seems performance related.

John Mellor

unread,
Nov 4, 2013, 4:52:46 PM11/4/13
to Adam Barth, Ilya Grigorik, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn

Adam wrote:
> If srcset addresses 80% of the use cases, then I think we should just ship srcset and worry about the rest of the use cases in the future.

The problem is srcset addresses only a small fraction of the use cases. I just looked through 40 random responsive designs on http://mediaqueri.es, and 88% of them featured images that were shown at different sizes depending on the viewport width. That's something the current DPR-switching-only srcset is incapable of handling; and the proposed 'w' unit for srcset, which is intended to address that use case, doesn't actually work for the subtle reasons I explained in http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/

Yoav wrote:
> it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)

I can imagine, that in a 12-column responsive grid, you might possibly end up needing 12 breakpoints. I don't feel particularly strongly about this; but if we must have a limit, would 99 still satisfy Ryosuke's performance goals?

Ryosuke Niwa

unread,
Nov 4, 2013, 5:39:21 PM11/4/13
to Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
On Mon, Nov 4, 2013 at 3:24 AM, Yoav Weiss <yo...@yoav.ws> wrote:
I've discussed srcN with WebKit's kling on #webkit: http://pastebin.com/c5smGv6Q

He (as well as rniwa in a previous discussion) seems supportive of the use cases. He will support the feature if it is limited to a small number of possible attributes, e.g. src1-src9.
The RICG will be supportive of such a limitation, if it speeds up adoption, as it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)

That's not what I intended to say.  The minimum requirement for this feature to be ever implemented in WebKit (i.e. the condition under which I would not vigorously object) is to have an upper limit on the number.  I'm, however, of the opinion that we should have exactly one attribute to address this use case.

Picture element proposal had its own complexity but at least web developers are already familiar with the pattern due to video and audio elements.  src-N is worse in that neither browser vendors nor web developers have had to deal with content attributes that had priorities based on their suffix numbers.

- R. Niwa

Tab Atkins Jr.

unread,
Nov 4, 2013, 8:07:26 PM11/4/13
to Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
On Mon, Nov 4, 2013 at 2:39 PM, Ryosuke Niwa <rn...@chromium.org> wrote:
> On Mon, Nov 4, 2013 at 3:24 AM, Yoav Weiss <yo...@yoav.ws> wrote:
>> I've discussed srcN with WebKit's kling on #webkit:
>> http://pastebin.com/c5smGv6Q
>>
>> He (as well as rniwa in a previous discussion) seems supportive of the use
>> cases. He will support the feature if it is limited to a small number of
>> possible attributes, e.g. src1-src9.
>> The RICG will be supportive of such a limitation, if it speeds up
>> adoption, as it's not likely that the number of art-direction breakpoints
>> exceeds 9 in the near future. (2-3 is a typical number today)
>
> That's not what I intended to say. The minimum requirement for this feature
> to be ever implemented in WebKit (i.e. the condition under which I would not
> vigorously object) is to have an upper limit on the number. I'm, however,
> of the opinion that we should have exactly one attribute to address this use
> case.

Why, though? Rik quoted you as saying:

> If we're supporting src-N attributes in WebKit, I'd like to see N to have a
> small upper bound; e.g. 10. so that we can enumerate all parsed attributes
> statically at the compilation time.

Why do you want to do this?

Would a limit of 99 work for this case?

~TJ

Yoav Weiss

unread,
Nov 4, 2013, 10:44:23 PM11/4/13
to Ryosuke Niwa, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
On Mon, Nov 4, 2013 at 11:39 PM, Ryosuke Niwa <rn...@chromium.org> wrote:
On Mon, Nov 4, 2013 at 3:24 AM, Yoav Weiss <yo...@yoav.ws> wrote:
I've discussed srcN with WebKit's kling on #webkit: http://pastebin.com/c5smGv6Q

He (as well as rniwa in a previous discussion) seems supportive of the use cases. He will support the feature if it is limited to a small number of possible attributes, e.g. src1-src9.
The RICG will be supportive of such a limitation, if it speeds up adoption, as it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)

That's not what I intended to say.  
 
I meant to say you are supportive of the use cases. I didn't mean to imply you're supportive of the feature as is. Andreas Kling is the one that is supportive of it (as long as the number of attributes is upper bound). I apologize if i wasn't clear enough.

Andreas Kling

unread,
Nov 5, 2013, 6:47:29 AM11/5/13
to blin...@chromium.org, Ryosuke Niwa, Adam Barth, Ilya Grigorik, Marcos Caceres, Elliott Sprehn
On Tuesday, November 5, 2013 4:44:23 AM UTC+1, Yoav Weiss wrote:

On Mon, Nov 4, 2013 at 11:39 PM, Ryosuke Niwa <rn...@chromium.org> wrote:
On Mon, Nov 4, 2013 at 3:24 AM, Yoav Weiss <yo...@yoav.ws> wrote:
I've discussed srcN with WebKit's kling on #webkit: http://pastebin.com/c5smGv6Q

He (as well as rniwa in a previous discussion) seems supportive of the use cases. He will support the feature if it is limited to a small number of possible attributes, e.g. src1-src9.
The RICG will be supportive of such a limitation, if it speeds up adoption, as it's not likely that the number of art-direction breakpoints exceeds 9 in the near future. (2-3 is a typical number today)

That's not what I intended to say.  
 
I meant to say you are supportive of the use cases. I didn't mean to imply you're supportive of the feature as is. Andreas Kling is the one that is supportive of it (as long as the number of attributes is upper bound). I apologize if i wasn't clear enough.

I expressed some support for this feature because I was under the impression that other engines (you mentioned Mozilla) were already implementing it, and that WebKit was straggling.

From reading the discussions since then, it's clear that I spoke too soon. The people who are expressing concern have far more insight about this feature than I do. I apologize for leading you on.

-Kling

Tab Atkins Jr.

unread,
Nov 5, 2013, 2:02:02 PM11/5/13
to Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
On Mon, Nov 4, 2013 at 5:07 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:
> On Mon, Nov 4, 2013 at 2:39 PM, Ryosuke Niwa <rn...@chromium.org> wrote:
>> On Mon, Nov 4, 2013 at 3:24 AM, Yoav Weiss <yo...@yoav.ws> wrote:
>>> I've discussed srcN with WebKit's kling on #webkit:
>>> http://pastebin.com/c5smGv6Q
>>>
>>> He (as well as rniwa in a previous discussion) seems supportive of the use
>>> cases. He will support the feature if it is limited to a small number of
>>> possible attributes, e.g. src1-src9.
>>> The RICG will be supportive of such a limitation, if it speeds up
>>> adoption, as it's not likely that the number of art-direction breakpoints
>>> exceeds 9 in the near future. (2-3 is a typical number today)
>>
>> That's not what I intended to say. The minimum requirement for this feature
>> to be ever implemented in WebKit (i.e. the condition under which I would not
>> vigorously object) is to have an upper limit on the number. I'm, however,
>> of the opinion that we should have exactly one attribute to address this use
>> case.
>
> Why, though?

Sorry, I know it's not even been a full day since I sent this email,
but I'm *really* curious about why. I've talked with a bunch of other
nearby Blinkers, and we can't come up with a single technical reason
that unlimited src-n attrs are bad that doesn't also apply to data-*.
That is, even if this is some performance argument, like wanting to
produce a bitfield identifying which attributes are on an element (to
speed up attribute selectors, perhaps?), there's going to be an escape
hatch *anyway* for data-* attributes, and src-N can just use the same
mechanism. Whatever tax would be paid has already been paid.

~TJ

Eric Seidel

unread,
Nov 5, 2013, 2:12:41 PM11/5/13
to Tab Atkins Jr., Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
It looks like data-* attributes are not presentational. Reading the
spec just now they seem to be mostly reserving a namespace for "never
display this" attributes and providing some fancy query apis for them:
http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes

Eric Seidel

unread,
Nov 5, 2013, 2:52:25 PM11/5/13
to Tab Atkins Jr., Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
Tab points out that my wording was confusing.

I meant "attributes which the engine would need to have special
handling for at parse/load time".

You can specify any attribute in your HTML page <foo bar=baz> and we
don't have custom handling for bar, but we can query for it
document.querySelectorAll("foo[bar=baz]"), etc. but all that is done
on-demand/post-parse.

This is in contrast to something like "width" which we have to
understand and map into the render objects, etc. as we parse/render
the page.

This is entirely speculation on my part, but I could imagine doing
various optimizations in ones engine to support this (both storage and
time). I could also see how having an unbounded number of "the engine
must have special code for this at parse/render time" attributes could
defeat optimizations like this.

But if I were WebKit, I would just explain my concerns in plain
English to the working group. I can't imagine that such an
optimization has more value being kept speculatively secret than being
explained as a justification as to why working groups should never add
unbounded attribute patterns.

Eric Seidel

unread,
Nov 5, 2013, 2:57:39 PM11/5/13
to Adam Barth, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn, Ryosuke Niwa
I agree with Adam, we've bikeshedded a long time.

srcset="... || ..." was thrown out as a possible extension on
webkit.org. Was that a serious answer to this problem? Is HTML
attribute parsing defined in such a way so that content with || could
be backwards compatible with engines which don't yet support it?

If so, it seems like a reasonable path forward which keeps webkit
happy and lets Blink move closer to shipping this which sounds like a
win-win to me.

Elliott Sprehn

unread,
Nov 5, 2013, 3:02:39 PM11/5/13
to Eric Seidel, Adam Barth, Yoav Weiss, Marcos Caceres, blink-dev, Ryosuke Niwa
On Tue, Nov 5, 2013 at 11:57 AM, Eric Seidel <ese...@chromium.org> wrote:
I agree with Adam, we've bikeshedded a long time.

srcset="... || ..." was thrown out as a possible extension on
webkit.org.  Was that a serious answer to this problem?  Is HTML
attribute parsing defined in such a way so that content with || could
be backwards compatible with engines which don't yet support it?

I don't support adding || as _another_ delimiter. Embedding an entire csv file into a single attribute is crazy. The web has lots of ways to represent structured data (elements, attributes, css space delimited lists), having a new multi dimensional file format embedded in a single attribute is really sad.

- E

Tab Atkins Jr.

unread,
Nov 5, 2013, 3:13:21 PM11/5/13
to Eric Seidel, Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
On Tue, Nov 5, 2013 at 11:12 AM, Eric Seidel <ese...@chromium.org> wrote:
> It looks like data-* attributes are not presentational. Reading the
> spec just now they seem to be mostly reserving a namespace for "never
> display this" attributes and providing some fancy query apis for them:
> http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes

Discussion in #blink revealed that Eric is somewhat confused. There
may be something that distinguishes src-n from data-* in terms of
optimization opportunities, but without an explanation from Ryosuke,
no one has any idea what it might be.

~TJ

Tab Atkins Jr.

unread,
Nov 5, 2013, 3:14:12 PM11/5/13
to Eric Seidel, Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
Ugh, sorry, Gmail didn't inform me that there were replies over lunch.
Sorry for the noise. :/

Tab Atkins Jr.

unread,
Nov 5, 2013, 3:16:48 PM11/5/13
to Eric Seidel, Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
On Tue, Nov 5, 2013 at 11:52 AM, Eric Seidel <ese...@chromium.org> wrote:
> But if I were WebKit, I would just explain my concerns in plain
> English to the working group. I can't imagine that such an
> optimization has more value being kept speculatively secret than being
> explained as a justification as to why working groups should never add
> unbounded attribute patterns.

In particular, since FF and Blink don't seem to have any technical
problems with the unbounded attributes, I'm prepared to simply ignore
secret feedback and let WebKit deal with webdev pressure to implement.
I can't make decisions without information, and I'm not willing to
reward use of secretive pressure in a forum that's supposed to be
open.

~TJ

Tab Atkins Jr.

unread,
Nov 5, 2013, 3:28:32 PM11/5/13
to Eric Seidel, Adam Barth, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn, Ryosuke Niwa
On Tue, Nov 5, 2013 at 11:57 AM, Eric Seidel <ese...@chromium.org> wrote:
> I agree with Adam, we've bikeshedded a long time.
>
> srcset="... || ..." was thrown out as a possible extension on
> webkit.org. Was that a serious answer to this problem? Is HTML
> attribute parsing defined in such a way so that content with || could
> be backwards compatible with engines which don't yet support it?
>
> If so, it seems like a reasonable path forward which keeps webkit
> happy and lets Blink move closer to shipping this which sounds like a
> win-win to me.

No, || is not backwards-compatible with srcset. The two candidates
surrounding the || will be parsed as a single candidate. At best, the
candidate preceding the || will be parsed correctly (the || and the
url from the following candidate are dropped as unrecognized
descriptors, and any other descriptors in the second candidate will be
merged into the first candidate), at worse the candidates on either
side will be dropped as invalid. Regardless, further candidates will
be parsed as normal and added to the result set.

That is, for srcset="foo 1x, bar 2x || baz 1x, qux 2x", it'll parse it
into three candidates: "foo 1x", "bar 2x || baz 1x", and "qux 2x". The
second candidate is invalid due to the duplicated x descriptor, and
the third is treated as a sibling of the first and processed at the
same time.

Plus, as Elliot says, embedding a multi-level sub-language into an
attribute is crazytimes. The syntax is already complex enough, but
that complexity is necessary to solve the presented use-cases in a
compact and authorable way. Adding more would just make it an
unreadable, unwriteable mess.

~TJ

Dirk Schulze

unread,
Nov 5, 2013, 4:15:55 PM11/5/13
to Tab Atkins Jr., Eric Seidel, Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn

On Nov 5, 2013, at 9:16 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

> On Tue, Nov 5, 2013 at 11:52 AM, Eric Seidel <ese...@chromium.org> wrote:
>> But if I were WebKit, I would just explain my concerns in plain
>> English to the working group. I can't imagine that such an
>> optimization has more value being kept speculatively secret than being
>> explained as a justification as to why working groups should never add
>> unbounded attribute patterns.
>
> In particular, since FF and Blink don't seem to have any technical
> problems with the unbounded attributes, I'm prepared to simply ignore
> secret feedback and let WebKit deal with webdev pressure to implement.

Just as a reminder: Apple is shipping with this attribute for several weeks. So people are going to use it while people are tying to optimize the feature itself. Until srcN has any chance to get used in the wild it will take 3 months. Since it will be implemented behind a flag until the spec is settled and approved it will take even more months. In the meantime more and more people (at least them who care) will adapt to srcset. To say there will be pressure from webdevs on Apple is a big bet IMO.

Greetings,
Dirk

Tab Atkins Jr.

unread,
Nov 5, 2013, 4:29:37 PM11/5/13
to Adam Barth, Ilya Grigorik, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn
Jumping back a little bit:

On Fri, Nov 1, 2013 at 2:51 PM, Adam Barth <aba...@chromium.org> wrote:
> src-N is wacky and is going to take time before folks agree that it's a good
> idea. If srcset addresses 80% of the use cases, then I think we should just
> ship srcset and worry about the rest of the use cases in the future.
> Honestly, the primary use case here is supplying two images: one for
> device-pixel-ratio 1 and one for device-pixel-ratio 2. Everything else is
> of marginal benefit.

I'm assuming that the apparent wackiness is from the "variable-width
image" branch in the grammar. (The other two bits are just MQs and
simple srcset, so they're presumably not wacky.)

Here's a simple example of why that branch of the grammar is necessary.

Say you've got a page design with two breakpoints (three different
layouts). On small screens, it's a one-column layout, so the images
fill the viewport. On larger (tablet) devices, it's a two-column
layout, while on larger (desktop) screens it's a 3-column design. You
want to deliver the correct image to each device, regardless of screen
size. Here's how you write it in src-N:

<img src1="100% (640px) 50% (960px) 33%; xxs.jpg 160, xs.jpg 320,
s.jpg 480, m.jpg 640, l.jpg 960, xl.jpg 1280, xxl.jpg 1920">

The first part before the semicolon sets up a continuum - you've got
two screen breakpoints at 640px and 960px, and a declaration of how
wide the image is (percentages are relative to the viewport width)
between/around these breakpoints. The second part lists all your
candidate images along with their width in image pixels.

That's it. Interpreting the first part takes a little bit of
knowledge, but this is literally as complicated as it gets. There's
nothing more to it. If you need to add more breakpoints, or want to
add more images, you just append a single entry per to the appropriate
half of the value. Importantly, the author doesn't have to do any
math, as the browser calculates the relevant density ratios itself.
Also, this automatically handles higher densities up to the limit of
the images you provide - if you end up with a 6x iPhone, the
browser'll know that it can download the 1920 image for perfect
clarity if it wants, without the author having to think of this or
plan for the 6x future at all.

Here's the same example using srcset:

<img srcset="
160.jpg .44x 400w, 320.jpg .89x 400w, 480.jpg 1.33x 400w, 640.jpg
1.78x 400w, 960.jpg 2.67x 400w,
160.jpg 0.35x 520w, 320.jpg 0.7x 520w, 480.jpg 1.04x 520w, 640.jpg
1.39x 520w, 960.jpg 2.09x 520w, 1280.jpg 2.78x 520w,
320.jpg 0.55x 639w, 480.jpg 0.83x 639w, 640.jpg 1.1x 639w, 960.jpg
1.66x 639w, 1280 2.2x 639w, 1920 3.31x 639w,
160.jpg 0.44x 800w, 320.jpg 0.89x 800w, 480.jpg 1.33x 800w, 640.jpg
1.78x 800w, 960.jpg 2.67x 800w,
160.jpg 0.36x 959w, 320.jpg 0.73x 959w, 480.jpg 1.09x 959w, 640.jpg
1.45x 959w, 960.jpg 2.18x 959w, 1280.jpg 2.91x 959w,
160.jpg 0.44x 1200w, 320.jpg 0.89x 1200w, 480.jpg 1.33x 1200w,
640.jpg 1.78x 1200w, 960.jpg 2.67x 1200w,
160.jpg 0.36x 1440w, 320.jpg 0.73x 1440w, 480.jpg 1.09x 1440w,
640.jpg 1.45x 1440w, 960.jpg 2.18x 1440w, 1280.jpg 2.91x 1440w,
320.jpg 0.57x 1920w, 480.jpg 0.86x 1920w, 640.jpg 1.14x 1920w,
960.jpg 1.71x 1920w, 1280 2.29x 1920w, 1920 3.43x 1920w,
320.jpg 0.43x, 480.jpg 0.64x, 640.jpg 0.86x, 960.jpg 1.29x, 1280
1.71x, 1920 2.57x
">

(The example using <picture> at
<http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/>
is even more verbose, but at least there the width descriptors are
only stated once per line, and you can use comments to explain the
breakpoint groups.)

This example gains some extra verbosity by trying to cover the range
.5x to 3x in each case, but these are *useful ranges* for the near
future, and removing that extra support doesn't materially reduce the
verbosity of the example. Generally, it just drops the first and last
entry from each line, still leaving 2-3 entries per line.

I shouldn't have to describe the maintenance burden of code like this,
or the ridiculousness of the math that needs to be done at each
breakpoint to figure out the right densities. Note, for example, the
fourth line, which drops the densities back down, as the images
suddenly drop to half the viewport width rather than the full viewport
width. Nothing about this is something that we want an author to try
and do themselves.

This use-case is *not* unusual or niche, but it will be completely
avoided by authors if we stick with just srcset (or rather, it'll
probably be handled by script, which defeats much of our
optimizations).

~TJ

Tab Atkins Jr.

unread,
Nov 5, 2013, 4:31:33 PM11/5/13
to Dirk Schulze, Eric Seidel, Ryosuke Niwa, Yoav Weiss, Adam Barth, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
On Tue, Nov 5, 2013 at 1:15 PM, Dirk Schulze <dsch...@chromium.org> wrote:
> On Nov 5, 2013, at 9:16 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:
>> On Tue, Nov 5, 2013 at 11:52 AM, Eric Seidel <ese...@chromium.org> wrote:
>>> But if I were WebKit, I would just explain my concerns in plain
>>> English to the working group. I can't imagine that such an
>>> optimization has more value being kept speculatively secret than being
>>> explained as a justification as to why working groups should never add
>>> unbounded attribute patterns.
>>
>> In particular, since FF and Blink don't seem to have any technical
>> problems with the unbounded attributes, I'm prepared to simply ignore
>> secret feedback and let WebKit deal with webdev pressure to implement.
>
> Just as a reminder: Apple is shipping with this attribute for several weeks. So people are going to use it while people are tying to optimize the feature itself. Until srcN has any chance to get used in the wild it will take 3 months. Since it will be implemented behind a flag until the spec is settled and approved it will take even more months. In the meantime more and more people (at least them who care) will adapt to srcset. To say there will be pressure from webdevs on Apple is a big bet IMO.

Yup, this was anticipated when I was writing the spec. The algorithm
can use srcset as a fallback source just like it does with src. (This
is currently a note next to the src fallback, but it's trivial to see
how it would be integrated officially.) Apple has a migration path
from srcset to src-n.

~TJ

Ian Hickson

unread,
Nov 5, 2013, 4:49:01 PM11/5/13
to John Mellor, Adam Barth, Ilya Grigorik, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn
On Mon, 4 Nov 2013, John Mellor wrote:
>
> The problem is srcset addresses only a small fraction of the use cases.
> I just looked through 40 random responsive designs on
> http://mediaqueri.es, and 88% of them featured images that were shown at
> different sizes depending on the viewport width. That's something the
> current DPR-switching-only srcset is incapable of handling; and the
> proposed 'w' unit for srcset, which is intended to address that use
> case, doesn't actually work for the subtle reasons I explained in
> http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/

The only reason I see there is something to do with bandwidth constraints,
which srcset="" doesn't even attempt to address, intentionally, for the
reasons described here:

http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html

I think not supporting bandwidth constraints is the right call here.

The post goes on to say that src-* is "simpler" and illustrates it like
this:

<img src1="100% 640 50% 960 33%; xxs.jpg 160, xs.jpg 320, s.jpg 480,
m.jpg 640, l.jpg 960, xl.jpg 1280, xxl.jpg 1920">

It might be terser, but terse doesn't mean simple.

Anyway. If you've got that many images, on a layout that changes image
dimensions non-linearly as the user changes his window size, and you want
to support multiple densities, I don't think _any_ solution is going to be
simple enough that it matters _what_ we pick. Not to mention that really
if you're going to go with three columns at 960px, you really should also
go to four, five, six, etc, as the window width gets even bigger. Once
you're talking about that, with many images, and so on, just do the whole
thing in JavaScript and forget about trying to describe it in markup.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Adam Barth

unread,
Nov 5, 2013, 5:20:50 PM11/5/13
to Dirk Schulze, Tab Atkins Jr., Eric Seidel, Ryosuke Niwa, Yoav Weiss, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
On Tue, Nov 5, 2013 at 1:15 PM, Dirk Schulze <dsch...@chromium.org> wrote:
On Nov 5, 2013, at 9:16 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:
> In particular, since FF and Blink don't seem to have any technical
> problems with the unbounded attributes, I'm prepared to simply ignore
> secret feedback and let WebKit deal with webdev pressure to implement.

Just as a reminder: Apple is shipping with this attribute for several weeks.

Do you mean shipped in a nightly build or in a production release of Safari?  My understanding is that Apple has not shipped srcset in a production release.  We usually regard including a feature in a nightly build as having implemented the feature rather than having shipped it.  For what it's worth, we've also implemented srcset but have not yet shipped it.

Adam

Yoav Weiss

unread,
Nov 5, 2013, 5:35:22 PM11/5/13
to Adam Barth, Dirk Schulze, Tab Atkins Jr., Eric Seidel, Ryosuke Niwa, Ilya Grigorik, Marcos Caceres, blink-dev, Elliott Sprehn
As far as I know (per testing done by RICG members following the Mavericks update), srcset did not ship in the latest Safari 7 update.

Tab Atkins Jr.

unread,
Nov 5, 2013, 6:51:28 PM11/5/13
to Ian Hickson, John Mellor, Adam Barth, Ilya Grigorik, Yoav Weiss, Marcos Caceres, blink-dev, Elliott Sprehn
On Tue, Nov 5, 2013 at 1:49 PM, Ian Hickson <i...@hixie.ch> wrote:
> The post goes on to say that src-* is "simpler" and illustrates it like
> this:
>
> <img src1="100% 640 50% 960 33%; xxs.jpg 160, xs.jpg 320, s.jpg 480,
> m.jpg 640, l.jpg 960, xl.jpg 1280, xxl.jpg 1920">
>
> It might be terser, but terse doesn't mean simple.

Did you reply before I sent my message showing how to implement the
simple case in both src-n and srcset, or otherwise miss it?

You're correct that terse doesn't necessarily mean simple, but
verbosity comes with a complexity cost as well. It's not hard to show
that srcset gets *way* more verbose than src-n pretty quickly in the
variable-sized images case. Even the simplest possible example, of an
image that's always 100% of the viewport in width, suffers from
excessive verbosity in srcset.

Plus, srcset doesn't just cost you in typing, there's non-trivial
thought that has to go into figuring out the breakpoints and the
resultant densities. Authors simply *won't* write a good srcset in
these cases, because doing so is ridiculous. Instead, they'll do the
minimum srcset that works on their phone and desktop, and devices far
off of that or in the future won't be handled well.

> Anyway. If you've got that many images, on a layout that changes image
> dimensions non-linearly as the user changes his window size, and you want
> to support multiple densities, I don't think _any_ solution is going to be
> simple enough that it matters _what_ we pick. Not to mention that really
> if you're going to go with three columns at 960px, you really should also
> go to four, five, six, etc, as the window width gets even bigger. Once
> you're talking about that, with many images, and so on, just do the whole
> thing in JavaScript and forget about trying to describe it in markup.

You certainly *can* respond with more columns. Doing so in src-n is
trivial, doing so in srcset is decidedly not. However, many layouts
don't want to take the full screen width - on larger screens, it's
better to just start growing the page margins and such, so you don't
exceed readable line limits. Alternately, above 3 columns you may be
able to just approximate the image size as a static number, which is
nice and simple to do as well.

~TJ

Christian Biesinger

unread,
Nov 7, 2013, 2:43:44 PM11/7/13
to Yoav Weiss, blink-dev
So here's my opinion. I like a lot of the spec, but I can't get over
the fact that it requires many attributes. What is the advantage of
that over srcset="... || ... || ..."? I don't know that we need to set
a precedent here for using N attributes for a single purpose. It is
not clear that implementation will be as fast/easy... don't we do
AtomicString comparisons for attributes in various places? I also
suspect that it will be harder to get all dynamic changes correct
(removing attributes, changing an attribute, etc.)

As for readability: People can just format a single attribute the same
way they would multiple attributes. That's not a real problem.

-christian

On Sun, Oct 13, 2013 at 6:38 PM, Yoav Weiss <yo...@yoav.ws> wrote:
> Primary eng email
> yo...@yoav.ws
>
> Spec
> http://tabatkins.github.io/specs/respimg/Overview.html
>
> Public standard discussion
> http://lists.w3.org/Archives/Public/public-respimg/2013Sep/0087.html
>
> Summary
> SrcN is a responsive images solution which addresses all 3 major use-cases
> within a single syntax. It addresses DPR switching (like srcset),
> art-direction (like picture) and viewport dimensions based switching is a
> way that is superior to previous proposals.
>
> Motivation
> New device form factors and screen DPRs are added to the market on a regular
> basis. Serving the same image resources to all devices (which may display
> them in differing dimensions and at different DPRs) is wasteful, and hurts
> Web performance. It often also results in images that
> are presented to the user in a sub-optimal manner.
>
> This feature will give authors the tools to address this issue, and serve
> the image resources most appropriate to their user's DPR, viewport size or
> various Layout breakpoints, without resorting to hacks that have their own
> performance trade-offs.
>
> Compatibility Risk
> Unknown.
> Mozilla are looking into the feature.
> Other browser vendors haven't yet expressed public opinion regarding the
> feature.
>
> Ongoing technical constraints
> None.
>
> Will this feature be supported on all five Blink platforms (Windows, Mac,
> Linux, Chrome OS and Android)?
> Yes.
>
> OWP launch tracking bug?
> crbug.com/306893
>
> Link to entry on the feature dashboard
> http://www.chromestatus.com/features/4582090154704896
>
> Requesting approval to ship?
> No.

Tab Atkins Jr.

unread,
Nov 7, 2013, 5:07:43 PM11/7/13
to Christian Biesinger, Yoav Weiss, blink-dev
On Thu, Nov 7, 2013 at 11:43 AM, Christian Biesinger
<cbies...@chromium.org> wrote:
> So here's my opinion. I like a lot of the spec, but I can't get over
> the fact that it requires many attributes. What is the advantage of
> that over srcset="... || ... || ..."?

Aesthetics/usability. Unless there's a really good reason to do
otherwise, creating a syntax that *requires* authors to specially
format the value to be readable is a bad idea. Microsyntaxes should
stay micro, dammit. ^_^ Formatting attributes by wrapping to new
lines when necessary is normal and expected.

Note that this is relevant to more than just hand-authoring. Looking
at an element in the Inspector, for example, src-N would be *far* more
readable, as you lose the formatting information in a single
attribute.

It's also simply less readable. Each src-N attribute is a distinct
group of fallbacks*. Having them in separate attrs gives a distinct,
easy-to-see separation. It's very easy to scan. || as a separator is
much less obvious.

* To be specific, you only use multiple attributes when you're hitting
the "Art Direction" case, where you have multiple versions of an
image, perhaps cropped differently, to highlight the relevant sections
as the size of the image changes. All of the sources within a given
attribute should be identical save for density. This grouping, then,
is very easy to understand.

> I don't know that we need to set
> a precedent here for using N attributes for a single purpose. It is
> not clear that implementation will be as fast/easy... don't we do
> AtomicString comparisons for attributes in various places? I also
> suspect that it will be harder to get all dynamic changes correct
> (removing attributes, changing an attribute, etc.)

I don't believe there's a serious issue with correctness. The
handling isn't that complicated.

~TJ

Christian Biesinger

unread,
Nov 8, 2013, 9:16:12 PM11/8/13
to Tab Atkins Jr., Yoav Weiss, blink-dev
I guess this should move to the WHATWG thread, but since it started
here I'll respond here...

On Thu, Nov 7, 2013 at 5:07 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:
> On Thu, Nov 7, 2013 at 11:43 AM, Christian Biesinger
> <cbies...@chromium.org> wrote:
>> So here's my opinion. I like a lot of the spec, but I can't get over
>> the fact that it requires many attributes. What is the advantage of
>> that over srcset="... || ... || ..."?
>
> Aesthetics/usability. Unless there's a really good reason to do
> otherwise, creating a syntax that *requires* authors to specially
> format the value to be readable is a bad idea. Microsyntaxes should
> stay micro, dammit. ^_^ Formatting attributes by wrapping to new
> lines when necessary is normal and expected.

Oh c'mon. CSS is not readable unless you specially format it
(linebreaks, indentation). In fact, src-* is not readable unless you
format it either - you still have to do the linewrapping.

> Note that this is relevant to more than just hand-authoring. Looking
> at an element in the Inspector, for example, src-N would be *far* more
> readable, as you lose the formatting information in a single
> attribute.

inspector can prettyprint it, like it already does for some CSS
properties (e.g. you can expand shorthands to see which longhands they
correspond to).

> It's also simply less readable. Each src-N attribute is a distinct
> group of fallbacks*. Having them in separate attrs gives a distinct,
> easy-to-see separation. It's very easy to scan. || as a separator is
> much less obvious.
>
> * To be specific, you only use multiple attributes when you're hitting
> the "Art Direction" case, where you have multiple versions of an
> image, perhaps cropped differently, to highlight the relevant sections
> as the size of the image changes. All of the sources within a given
> attribute should be identical save for density. This grouping, then,
> is very easy to understand.

I think the implication from this is that requiring multiple
attributes is relatively rare. So it doesn't matter too much which one
we pick, and a single attribute is simpler.

-christian

Tab Atkins Jr.

unread,
Nov 10, 2013, 2:44:42 PM11/10/13
to Christian Biesinger, Yoav Weiss, blink-dev
On Fri, Nov 8, 2013 at 6:16 PM, Christian Biesinger
<cbies...@chromium.org> wrote:
> I guess this should move to the WHATWG thread, but since it started
> here I'll respond here...
>
> On Thu, Nov 7, 2013 at 5:07 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:
>> On Thu, Nov 7, 2013 at 11:43 AM, Christian Biesinger
>> <cbies...@chromium.org> wrote:
>>> So here's my opinion. I like a lot of the spec, but I can't get over
>>> the fact that it requires many attributes. What is the advantage of
>>> that over srcset="... || ... || ..."?
>>
>> Aesthetics/usability. Unless there's a really good reason to do
>> otherwise, creating a syntax that *requires* authors to specially
>> format the value to be readable is a bad idea. Microsyntaxes should
>> stay micro, dammit. ^_^ Formatting attributes by wrapping to new
>> lines when necessary is normal and expected.
>
> Oh c'mon. CSS is not readable unless you specially format it
> (linebreaks, indentation). In fact, src-* is not readable unless you
> format it either - you still have to do the linewrapping.

CSS isn't a microsyntax, it's a whole language.

Linebreaking between long attributes is already an established and
common practice, and one that many editors (including DevTools) do
automatically.

>> Note that this is relevant to more than just hand-authoring. Looking
>> at an element in the Inspector, for example, src-N would be *far* more
>> readable, as you lose the formatting information in a single
>> attribute.
>
> inspector can prettyprint it, like it already does for some CSS
> properties (e.g. you can expand shorthands to see which longhands they
> correspond to).

CSS properties are pretty-printed because they have a whole panel to
themselves. style='' attributes are not (except when they're
reflected into the CSS panel).

I suppose it's possible that we could have a panel that only shows up
for images, to help visualize source selection. That would probably
be useful, actually. That doesn't excuse an ugly attribute too much,
though, any more than the presence of the CSS property panel excuses
overuse of style=''.

>> It's also simply less readable. Each src-N attribute is a distinct
>> group of fallbacks*. Having them in separate attrs gives a distinct,
>> easy-to-see separation. It's very easy to scan. || as a separator is
>> much less obvious.
>>
>> * To be specific, you only use multiple attributes when you're hitting
>> the "Art Direction" case, where you have multiple versions of an
>> image, perhaps cropped differently, to highlight the relevant sections
>> as the size of the image changes. All of the sources within a given
>> attribute should be identical save for density. This grouping, then,
>> is very easy to understand.
>
> I think the implication from this is that requiring multiple
> attributes is relatively rare. So it doesn't matter too much which one
> we pick, and a single attribute is simpler.

No, that's not an implication you can draw from that. I said that
grouping/splitting is *natural*, not that it's rare; the RICG research
on responsive images in the wild shows that "art direction" is
relatively common among solutions that allow it.

~TJ

Christian Biesinger

unread,
Nov 12, 2013, 8:38:25 PM11/12/13
to Tab Atkins Jr., Yoav Weiss, blink-dev
On Sun, Nov 10, 2013 at 2:44 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:
> On Fri, Nov 8, 2013 at 6:16 PM, Christian Biesinger
> <cbies...@chromium.org> wrote:
>> I guess this should move to the WHATWG thread, but since it started
>> here I'll respond here...
>>
>> On Thu, Nov 7, 2013 at 5:07 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:
>>> On Thu, Nov 7, 2013 at 11:43 AM, Christian Biesinger
>>> <cbies...@chromium.org> wrote:
>>>> So here's my opinion. I like a lot of the spec, but I can't get over
>>>> the fact that it requires many attributes. What is the advantage of
>>>> that over srcset="... || ... || ..."?
>>>
>>> Aesthetics/usability. Unless there's a really good reason to do
>>> otherwise, creating a syntax that *requires* authors to specially
>>> format the value to be readable is a bad idea. Microsyntaxes should
>>> stay micro, dammit. ^_^ Formatting attributes by wrapping to new
>>> lines when necessary is normal and expected.
>>
>> Oh c'mon. CSS is not readable unless you specially format it
>> (linebreaks, indentation). In fact, src-* is not readable unless you
>> format it either - you still have to do the linewrapping.
>
> CSS isn't a microsyntax, it's a whole language.
>
> Linebreaking between long attributes is already an established and
> common practice, and one that many editors (including DevTools) do
> automatically.

I've seen plenty of websites that don't do much linewrapping at all :)

Anyway... I guess we are not going to agree on this point.

>>> Note that this is relevant to more than just hand-authoring. Looking
>>> at an element in the Inspector, for example, src-N would be *far* more
>>> readable, as you lose the formatting information in a single
>>> attribute.
>>
>> inspector can prettyprint it, like it already does for some CSS
>> properties (e.g. you can expand shorthands to see which longhands they
>> correspond to).
>
> CSS properties are pretty-printed because they have a whole panel to
> themselves. style='' attributes are not (except when they're
> reflected into the CSS panel).
>
> I suppose it's possible that we could have a panel that only shows up
> for images, to help visualize source selection. That would probably
> be useful, actually. That doesn't excuse an ugly attribute too much,
> though, any more than the presence of the CSS property panel excuses
> overuse of style=''.

That would be great to have, indeed.

>>> It's also simply less readable. Each src-N attribute is a distinct
>>> group of fallbacks*. Having them in separate attrs gives a distinct,
>>> easy-to-see separation. It's very easy to scan. || as a separator is
>>> much less obvious.
>>>
>>> * To be specific, you only use multiple attributes when you're hitting
>>> the "Art Direction" case, where you have multiple versions of an
>>> image, perhaps cropped differently, to highlight the relevant sections
>>> as the size of the image changes. All of the sources within a given
>>> attribute should be identical save for density. This grouping, then,
>>> is very easy to understand.
>>
>> I think the implication from this is that requiring multiple
>> attributes is relatively rare. So it doesn't matter too much which one
>> we pick, and a single attribute is simpler.
>
> No, that's not an implication you can draw from that. I said that
> grouping/splitting is *natural*, not that it's rare; the RICG research
> on responsive images in the wild shows that "art direction" is
> relatively common among solutions that allow it.

My point was more that for each page, there are probably few images
that need art direction switching. Perhaps I'm wrong on this point?


I guess it doesn't matter too much that I don't like this part of the
spec. Everyone else here seems to like it, so it all hinges on
convincing webkit. I do like the concepts that src-N brings and I'm
fine with the syntax within the attributes. I'll keep following the
whatwg discussions...

-christian

Nico Weber

unread,
Nov 12, 2013, 8:46:19 PM11/12/13
to Christian Biesinger, blink-dev, Yoav Weiss, Tab Atkins Jr.

For what it's worth, I also think the multiple attribute syntax is ugly. More importantly, it's not so obviously better than the srcset syntax with a delimiter that it's worth the months of delay that arguing over this costs, IMHO.

Adam Barth

unread,
Nov 13, 2013, 1:51:58 AM11/13/13
to Nico Weber, Christian Biesinger, blink-dev, Yoav Weiss, Tab Atkins Jr.
I'd recommend taking further discussion about the shape of the API to the WhatWG list.  There's a fairly active discussion going on there on this topic at the moment with a number of vendors.

Adam

Ian Hickson

unread,
Nov 15, 2013, 5:14:08 PM11/15/13
to Christian Biesinger, Tab Atkins Jr., Yoav Weiss, blink-dev
On Tue, 12 Nov 2013, Christian Biesinger wrote:
>
> I guess it doesn't matter too much that I don't like this part of the
> spec. Everyone else here seems to like it

Lest we head to Abilene together, I'm not a fan of the src-* design
either, aesthetically. I just don't have a strong counter-proposal. The
subsequent discussion on the WHATWG list seems to have made some progress,
though, which is promising.

Christian Biesinger

unread,
Nov 19, 2013, 5:50:00 PM11/19/13
to Ian Hickson, Tab Atkins Jr., Yoav Weiss, blink-dev
On Fri, Nov 15, 2013 at 5:14 PM, Ian Hickson <i...@hixie.ch> wrote:
> On Tue, 12 Nov 2013, Christian Biesinger wrote:
>>
>> I guess it doesn't matter too much that I don't like this part of the
>> spec. Everyone else here seems to like it
>
> Lest we head to Abilene together, I'm not a fan of the src-* design
> either, aesthetically. I just don't have a strong counter-proposal. The
> subsequent discussion on the WHATWG list seems to have made some progress,
> though, which is promising.

(If anyone else was wondering: http://en.wikipedia.org/wiki/Abilene_paradox)

Yeah, the proposals on whatwg seem a lot better.

-christian

Tab Atkins Jr.

unread,
Nov 20, 2013, 12:41:35 PM11/20/13
to Christian Biesinger, Ian Hickson, Yoav Weiss, blink-dev
Progress report: the last 24 hours have been kinda crazy on this front.

Simon Pieters revived the suggestion of just using <picture>, with
Kornel's modified source selection algorithm that doesn't have the
problems of <video> and <audio>. With two additional small changes to
make sure it handles the same use-cases as src-N, I'm fine with this,
as are several other people who didn't like multiple attributes,
including Timothy Hatcher from WebKit.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-November/041592.html

~TJ

Adam Barth

unread,
Nov 20, 2013, 12:48:30 PM11/20/13
to Tab Atkins Jr., Christian Biesinger, Ian Hickson, Yoav Weiss, blink-dev
Difficult for me to tell from that link, but does this new iteration of <picture> address the implementation issues I raised in <https://groups.google.com/a/chromium.org/d/msg/blink-dev/MlE9vYVUlzg/lohBvySEIegJ>?  Please note that we now actually do run the preload scanner on a background thread whereas at the time I wrote that email, we were only considering the possibility of running the preload scanner on a background thread.

Adam

Tab Atkins Jr.

unread,
Nov 20, 2013, 12:59:29 PM11/20/13
to Adam Barth, Christian Biesinger, Ian Hickson, Yoav Weiss, blink-dev
On Wed, Nov 20, 2013 at 9:48 AM, Adam Barth <aba...@chromium.org> wrote:
> Difficult for me to tell from that link, but does this new iteration of
> <picture> address the implementation issues I raised in
> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/MlE9vYVUlzg/lohBvySEIegJ>?
> Please note that we now actually do run the preload scanner on a background
> thread whereas at the time I wrote that email, we were only considering the
> possibility of running the preload scanner on a background thread.

Ah, I'd missed that, and you didn't re-raise it for src-N, where it's
equally problematic.

We'd need to ship information about MQs over to the preload scanner
thread. If necessary, we can define a subset that are recognized by
the preloader, such as just the "width" and "height" MQs. These are
no more problematic than the w/h descriptors in full srcset were. I
suppose 'resolution', too, since the preloader will need to know
resolution information *anyway* to make a decision among the
densities. We can see what else might be interesting and possible, as
there are several MQs that are good for accessibility.

~TJ

Yoav Weiss

unread,
Nov 20, 2013, 1:09:45 PM11/20/13
to Tab Atkins Jr., Adam Barth, Christian Biesinger, Ian Hickson, blink-dev
I already have a PoC implementation of such "off the main thread" MQ evaluation inside the HTMLPreloadScanner (CL).  The only thing holding it back is the fact that the CSS parser is not thread-safe, and in particular MediaQueryExp isn't. In the CL I've resolved it in a sub-optimal manner, but I'm certain that a better way can be found.

Other than that, the new <picture> proposal also addresses concerns I've heard from WebKit folks regarding duplication of tests, code and roles with the <img> element. According to this new proposal, HTMLImageElement will do all the heavy lifting of actually fetching the resource and displaying it, leaving <picture> as a container of optional resources and nothing more.

Adam Barth

unread,
Nov 20, 2013, 1:13:57 PM11/20/13
to Tab Atkins Jr., Christian Biesinger, Ian Hickson, Yoav Weiss, blink-dev
On Wed, Nov 20, 2013 at 9:59 AM, Tab Atkins Jr. <jacka...@gmail.com> wrote:
On Wed, Nov 20, 2013 at 9:48 AM, Adam Barth <aba...@chromium.org> wrote:
> Difficult for me to tell from that link, but does this new iteration of
> <picture> address the implementation issues I raised in
> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/MlE9vYVUlzg/lohBvySEIegJ>?
> Please note that we now actually do run the preload scanner on a background
> thread whereas at the time I wrote that email, we were only considering the
> possibility of running the preload scanner on a background thread.

Ah, I'd missed that, and you didn't re-raise it for src-N, where it's
equally problematic.

Not to advocate for src-N, but at least src-N didn't support arbitrary media queries.
 
We'd need to ship information about MQs over to the preload scanner
thread.  If necessary, we can define a subset that are recognized by
the preloader, such as just the "width" and "height" MQs.  These are
no more problematic than the w/h descriptors in full srcset were.  I
suppose 'resolution', too, since the preloader will need to know
resolution information *anyway* to make a decision among the
densities.  We can see what else might be interesting and possible, as
there are several MQs that are good for accessibility.

It sounds like the new <picture> proposal has the same problems as the old <picture> proposal

On Wed, Nov 20, 2013 at 10:09 AM, Yoav Weiss <yo...@yoav.ws> wrote:
I already have a PoC implementation of such "off the main thread" MQ evaluation inside the HTMLPreloadScanner (CL).  The only thing holding it back is the fact that the CSS parser is not thread-safe, and in particular MediaQueryExp isn't. In the CL I've resolved it in a sub-optimal manner, but I'm certain that a better way can be found.

We won't be able to support those engineering constraints going forward.  The state needed to evaluate media queries simply doesn't exist on the parser thread, and it certainly won't exist if we move the preload scanner into a future network process.

As discussed six months ago, we won't be able to support arbitrary media queries, which means we won't be able to implement <picture>.  From my perspective, these discussions about responsive images are just going around in circles.

Adam

John Mellor

unread,
Nov 20, 2013, 2:07:56 PM11/20/13
to Adam Barth, Tab Atkins Jr., Christian Biesinger, Ian Hickson, Yoav Weiss, blink-dev
On Wed, Nov 20, 2013 at 6:13 PM, Adam Barth <aba...@chromium.org> wrote:
We won't be able to support those engineering constraints going forward.  The state needed to evaluate media queries simply doesn't exist on the parser thread, and it certainly won't exist if we move the preload scanner into a future network process.

As discussed six months ago, we won't be able to support arbitrary media queries, which means we won't be able to implement <picture>.

Most of the standard media features (resolution/device-pixel-ratio, device-width, device-height, aspect-ratio, device-aspect-ratio, color, color-index, monochrome, scan) are just static properties of the display, so it should be trivial for the parser thread to have a copy of that state.

The only tricky ones are width and height, which depend on the page's meta viewport (or @viewport). But the preload scanner can parse these if they're included in the <head>, and even if they're added dynamically by JS it should be possible to communicate updates to viewport size asynchronously to the parser thread.

Is there complexity that I'm missing here? 

Adam Barth

unread,
Nov 20, 2013, 3:18:37 PM11/20/13
to John Mellor, Tab Atkins Jr., Christian Biesinger, Ian Hickson, Yoav Weiss, blink-dev
There are lots of media queries today and there are likely to be lots more in the future.  For example, you didn't list |pointer|, which varies based on which position the screen is in on a convertible laptop/tablet.  Even if we could handle all the media queries that exist today, we don't want to constrain the future design of media queries to be able to be evaluated on a background thread or in another process.

The important thing to understand is that we're going to need to support this API for a long period of time.  If an API imposes design constraints on the engine, we need to make sure we're willing to live with those constraints over a long period of time.  In this specific case, I don't think we want to live with the constraint of coupling media queries with the preload scanner.  The preload scanner is too critical for performance to be coupled to the main thread, and media queries are two featureful to be decoupled from the main thread.

Adam

Yoav Weiss

unread,
Nov 20, 2013, 3:28:48 PM11/20/13
to Adam Barth, John Mellor, Tab Atkins Jr., Christian Biesinger, Ian Hickson, blink-dev
FWIW, I think that a limitation of the MQs that can be used in <picture> to a static subset of today's MQs is probably an acceptable compromise.
Assuming that such a limitation is agreed upon, will it remove the concerns regarding the preload scanner?

Adam Barth

unread,
Nov 20, 2013, 3:37:25 PM11/20/13
to Yoav Weiss, John Mellor, Tab Atkins Jr., Christian Biesinger, Ian Hickson, blink-dev
Depending on what subset of CSS you allow in <picture>, that could address the implementation concern but then it raises an API design problem.

In any case, I'd rather we discussed this issue on the WhatWG list where other vendors can participate.  The reason I replied to Tab's message on this mailing list was to remind him of the concerns I raised 6 months ago.

Adam

Tab Atkins Jr.

unread,
Nov 20, 2013, 4:02:18 PM11/20/13
to Adam Barth, Christian Biesinger, Ian Hickson, Yoav Weiss, blink-dev
On Wed, Nov 20, 2013 at 10:13 AM, Adam Barth <aba...@chromium.org> wrote:
> On Wed, Nov 20, 2013 at 9:59 AM, Tab Atkins Jr. <jacka...@gmail.com>
> wrote:
>> On Wed, Nov 20, 2013 at 9:48 AM, Adam Barth <aba...@chromium.org> wrote:
>> > Difficult for me to tell from that link, but does this new iteration of
>> > <picture> address the implementation issues I raised in
>> >
>> > <https://groups.google.com/a/chromium.org/d/msg/blink-dev/MlE9vYVUlzg/lohBvySEIegJ>?
>> > Please note that we now actually do run the preload scanner on a
>> > background
>> > thread whereas at the time I wrote that email, we were only considering
>> > the
>> > possibility of running the preload scanner on a background thread.
>>
>> Ah, I'd missed that, and you didn't re-raise it for src-N, where it's
>> equally problematic.
>
> Not to advocate for src-N, but at least src-N didn't support arbitrary media
> queries.

Yes it did. The first part of a src-N attribute was an arbitrary
media-feature list.

>> We'd need to ship information about MQs over to the preload scanner
>> thread. If necessary, we can define a subset that are recognized by
>> the preloader, such as just the "width" and "height" MQs. These are
>> no more problematic than the w/h descriptors in full srcset were. I
>> suppose 'resolution', too, since the preloader will need to know
>> resolution information *anyway* to make a decision among the
>> densities. We can see what else might be interesting and possible, as
>> there are several MQs that are good for accessibility.
>
> It sounds like the new <picture> proposal has the same problems as the old
> <picture> proposal

No, the major problem that killed it last time is that the source
selection algorithm in <video>/<audio> is regarded as a mistake. The
new proposal is for a different selection algorithm that avoids those
problems.

At the bare minimum, *every* suggestion floated so far from *anyone*
has included the ability to discriminate on width, height, and
resolution (often implicitly, through the density descriptor on each
url). Without these you simply can't address the bare-minimum
use-cases. These are also generally static properties of the display,
and so should be easily shippable to the preloader, as John says.

As I just said in the quoted section, we can define a subset of MQs
that work with the preloader. I'd prefer that they're all *allowed*,
but the preloader makes initial downloading decisions based only on
the ones it understands (if an unfriendly MQ would make the
preloader's decision wrong, oh well, wasted download, but still
correct image sometime later). This doesn't even have to be
explicitly specified; the preloader itself is an unspecified
optimization right now.

If you're trying to take a stance that *no* MQ or MQ-like evaluation
can go in the preloader, you're actually saying that it's impossible
for responsive images to work with the preloader at all. I don't
think you're saying that, though.

I'll bring up this concern on the WHATWG list.

~TJ

Ian Hickson

unread,
Nov 20, 2013, 4:31:48 PM11/20/13
to Tab Atkins Jr., Adam Barth, Christian Biesinger, Yoav Weiss, blink-dev
On Wed, 20 Nov 2013, Tab Atkins Jr. wrote:
> >
> > It sounds like the new <picture> proposal has the same problems as the
> > old <picture> proposal
>
> No, the major problem that killed it last time is that the source
> selection algorithm in <video>/<audio> is regarded as a mistake. The
> new proposal is for a different selection algorithm that avoids those
> problems.

The problem with <video>/<source> isn't so much the source selection
algorithm (I don't really know how else you'd do it, even if it was all in
one attribute); the problem is that it involves multiple elements. See:

http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html

Specifically the part where I write:

Generally, processing models for multi-element structures in the DOM
are a disproportionate source of trouble in a wide variety of areas:
- they introduce the need for much more elaborate error handling,
since they have multiple failure modes (what happens if one or
another element is found in another, or if the outer element has an
unexpected inner element?)
- the processing model has to deal with changes more complicated than
just "change" (what if an element is added or removed, or moved?)
- it introduces all kinds of complicated questions once you introduce
shadow trees (what if you bind something with a special child? what
if the shadow tree contains such a child?)
- it introduces complexities in the algorithms to deal with unexpected
text nodes, comment nodes, PIs, etc.
- it introduces some complexity in the parser, because you have to
handle the case where you're only half-way through parsing the
"parent" element when you return to the event loop, with more
children elements to process (when does the processing model
start? what do you expose in the DOM API half-way through? etc).

Processing models that involve multiple elements are significantly more
complicated than processing models that involve one element, merely due
to involving multiple elements. HTML and the DOM just aren't set up to
make things involving multiple elements very clean.
Reply all
Reply to author
Forward
0 new messages