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

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.

~TJ

Received on Tuesday, 25 February 2014 00:23:05 UTC