[webkit-dev] The SrcN responsive images proposal

[John Mellor]

On Mon, Nov 4, 2013 at 10:19 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> 99 is a very high upper bound while it would still allow us to implement
> the optimization we're thinking of.
>
> I'm of the opinion that we should use exactly one attribute for this
> feature.
>

The thing is, srcN isn't a list, it's a list of lists. Consider the
following srcN for a fixed-width image with art direction:

<img src-1="(min-width: 640px) 0.5x photo at 0.5x.jpg, 1x photo at 1x.jpg, 2x
photo at 2x.jpg"
     src-2="0.5x photo-crop at 0.5x.jpg, 1x photo-crop at 1x.jpg, 2x
photo-crop at 2x.jpg">

I guess one could combine it all into one attribute, e.g. by introducing
"||" as an 3rd separator, in addition to the existing "," and ";". For
example:

<img srcset="(min-width: 640px) 0.5x photo at 0.5x.jpg, 1x photo at 1x.jpg, 2x
photo at 2x.jpg || 0.5x photo-crop at 0.5x.jpg, 1x photo-crop at 1x.jpg, 2x
photo-crop at 2x.jpg">

But that seems rather harder to read...


> - R. Niwa
>
> On Mon, Nov 4, 2013 at 2:04 PM, Yoav Weiss <yoav at yoav.ws> wrote:
>
>>
>>
>>
>> On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>
>>> On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss <yoav at yoav.ws> wrote:
>>>
>>>> On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa <rniwa at webkit.org>wrote:
>>>>
>>>>> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
>>>>>
>>>>>> On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto <koivisto at iki.fi>
>>>>>> wrote:
>>>>>> > Ignoring other aspects of this, the idea of making attribute name an
>>>>>> > enumeration is somewhat distasteful. It will require ugly special
>>>>>> parsing.
>>>>>> > The platform has plenty of attribute values that are lists already.
>>>>>>
>>>>>> The parsing aspect isn't particularly new - parsing data-* attributes
>>>>>> presents the same problem.  You just need to filter the list of
>>>>>> attributes on the element to look for things with a src- prefix.  I've
>>>>>> heard direct feedback from Yoav, implementing in Blink, that it's not
>>>>>> a big problem.
>>>>>>
>>>>>
>>>>> Just because it was not a big problem in one engine, it doesn't mean
>>>>> it won't be in other engines.
>>>>> 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.
>>>>>
>>>>
>>>> Out of curiosity, what would be the benefits of such a restriction?
>>>>
>>>
>>> We're considering to implement an optimization that takes the advantage
>>> of parsed attributes being a finite set at the compilation time.
>>>
>>>  Having this feature will make it much harder to implement such an
>>> optimization.  Note that data-* attributes don't need to be parsed since it
>>> doesn't synchronously update Element's internal states.
>>>
>>> - R. Niwa
>>>
>>
>> Will setting the limit on the number of possible attributes at 99 still
>> enable that optimization?
>> Many people (on the RICG's IRC and on Blink-dev) feel that setting the
>> limit to 9, even if it'd be enough today, leaves fairly little space for
>> future evolution. Setting it to some random number between 10 and 99 feels
>> arbitrary to me. So, will 99 be OK with you?
>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131105/a75e62d1/attachment.html>