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

Re: [css-counter-styles] speak-as: auto and the override system

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 19 May 2014 16:21:53 +0900
Message-ID: <CAAWBYDDp6STa-qod3-QbZ6gR0KPzk2o+zKdJmshEknCLcP4L9w@mail.gmail.com>
To: Xidorn Quan <quanxunzhen@gmail.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
On Mon, May 19, 2014 at 1:38 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> On Mon, May 19, 2014 at 11:35 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Thu, May 8, 2014 at 8:13 AM, L. David Baron <dbaron@dbaron.org> wrote:
>> > On Wednesday 2014-05-07 16:08 -0700, L. David Baron wrote:
>> >> Instead, I would propose that the 'auto' value say:
>> >>   # If the system is override, this value has the same effect that
>> >>   # 'auto' would have for the overridden counter style.
>> >> which seems more consistent with how the override system otherwise
>> >> works.
>> >
>> > And I suppose the same proposal applies to 'range: auto', which has
>> > the same issue (though without the loop detection complexity), and
>> > which is defined in
>> > http://dev.w3.org/csswg/css-counter-styles/#counter-style-range
>> Both of these sound great to me.  Changed.
> There is one problem with the new rule: the behavior of 'range: auto' is not
> defined for complex builtin styles, especially Chinese and Ethiopic styles
> which have no system defined at all. I think it might make sense to specify
> the behavior for those styles separately, but this makes the spec more
> complex.
> For the reason, I propose that the behavior of 'auto' for 'range' should be
> reverted to the previous version, so that we don't need to handle those
> special cases. As this behavior is slightly different from that of other
> descriptors, it might be helpful to have a note to describe.

That's not a very strong reason. The "auto" range for the complex
predefined ones is just their normal range. I can just define that.

Received on Monday, 19 May 2014 07:22:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:42 UTC