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

On Fri, May 30, 2014 at 5:03 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> On Mon, May 19, 2014 at 5:21 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> 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.
>
>
> Ping. It seems that you haven't fixed this problem in the spec. I'm fine
> with whatever the solution would be. I just wanted to prevent the spec from
> being more complex.

Sorry about the delay; fixed.

~TJ

Received on Monday, 9 June 2014 22:32:44 UTC