W3C home > Mailing lists > Public > www-style@w3.org > February 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 24 Feb 2014 16:22:18 -0800
Message-ID: <CAAWBYDDzv88BBau_tUaa=EOpoFSpJ1Zdz1MwixQKaK00CzfxRQ@mail.gmail.com>
To: Xidorn Quan <quanxunzhen@gmail.com>
Cc: www-style list <www-style@w3.org>
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

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC