On Mon, Nov 4, 2013 at 10:19 PM, Ryosuke Niwa <rn...@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 ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x
ph...@2x.jpg"
src-2="0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x
photo-c...@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 ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x
ph...@2x.jpg || 0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x
photo-c...@2x.jpg">
But that seems rather harder to read...
> - R. Niwa
>
> On Mon, Nov 4, 2013 at 2:04 PM, Yoav Weiss <y...@yoav.ws> wrote:
>
>>
>>
>>
>> On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa <rn...@webkit.org> wrote:
>>
>>> On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss <y...@yoav.ws> wrote:
>>>
>>>> On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa <rn...@webkit.org>wrote:
>>>>
>>>>> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr.
>>>>> <jackalm...@gmail.com>wrote:
>>>>>
>>>>>> On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto <koivi...@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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
