Re: [css-counter-styles] About override loop

On Tue, Feb 25, 2014 at 11:22 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Feb 21, 2014 at 5:45 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>> On Sat, Feb 22, 2014 at 11:46 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Fri, Feb 21, 2014 at 2:26 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>>>> On Sat, Feb 22, 2014 at 8:33 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>>> Is it easier to handle it in the way you suggest?  I would think it's
>>>>> easier to just detect a cycle and then adjust the internal 'system'
>>>>> value of all of the offending counter styles to override decimal
>>>>> instead.  Then there's no special behavior.
>>>>
>>>> Yes, I think it is easier to implement in the way I suggested. For
>>>> that way, recursive call can still be used with some tricks, like
>>>> temporarily specifying the overridden style to decimal, to avoid
>>>> infinite loop. But if all styles in loop has to be treated as
>>>> overriding decimal, it is necessary to add an explicit loop detection,
>>>> and a specific procedure for styles in cycle.
>>>>
>>>> In addition, I think doing a minimal failure is more intuitive, isn't it?
>>>
>>> Depends.  CSS walks a balancing act between failing minimally and
>>> failing usefully - if you try to be too smart in error-handling, it
>>> becomes harder to debug (as something *mostly* works right, except for
>>> some weird bits), and harder to extend in the future.
>>>
>>> That's why we simply reject properties that don't conform to their
>>> grammar, but reject *only* the property, not the whole rule or the
>>> whole stylesheet.  That's a good level of "ignoring" in practice.
>>
>> Maybe it shouldn't be fully considered as an error. People may define
>> something like:
>>
>> @counter-style a { system: override b; prefix: X; }
>> @counter-style b { system: override c; suffix: X; }
>> @counter-style c { system: override d; prefix: Y; }
>> @counter-style d { system: override a; suffix: Y; }
>>
>> So they could have four different prefix-suffix pairs without writing
>> any descriptor twice. It doesn't seem to be very useful, but it might
>> probably sometimes make sense. I'm not sure :P
>
> Silly tricks aren't a use-case. ^_^
>
> But anyway, since I do a similar "consider everyone in the loop to be
> an error, and fix them back to a reasonable default value" for the
> other reference-chasing things ('fallback' and 'speak-as'), and those
> require explicit loop detections as well, I think it's best to be
> consistent here, and make it so that override loops are an error, and
> all the counter styles in the loop get defaulted to overriding
> decimal.

Fallback does not require an explicit loop detection. The spec has
said that it is not necessarily an error to have a fallback loop. The
behavior for override loop I propose here is, to some extent, similar
with the way for fallback loop. Different from speak-as, which has
only one value, fallback and override could affect multiple values
(fallback for discrete numbers, override for descriptors). Doing the
minimal failure, IMHO, is more intuitive for authors and also easier
to implement.

Imagine that, when an author writes an override loop by accident, if
he sees only the descriptors specified in the rule is effective, he
may think there is a spelling mistake of the name, and check over and
over again without catching the true reason. However if he finds some
descriptors in overridden system is also effective, while only the
counter representation is wrong, he will have a higher probability to
follow the override chain and notice the loop.

- Xidorn

Received on Tuesday, 25 February 2014 04:52:03 UTC