W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Re: [counter-styles] At-risk list

From: Reece Dunn <msclrhd@googlemail.com>
Date: Wed, 30 Oct 2013 18:11:13 +0000
Message-ID: <CAGdtn27rORSt-Q1CNOwygu45ah38ct9HjJh2QLi-y0kaphuZVQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On 30 October 2013 17:38, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Oct 29, 2013 at 6:37 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
>> On 30 October 2013 01:02, fantasai <fantasai.lists@inkedblade.net> wrote:
>>> I think we should add 'pad' and 'speak-as' to the at-risk list.
>>> Not that I think 'speak-as' is unworthy, but we don't really
>>> have much in the way of CSS speech implementations. :/
>>
>> FWIW, I have an experimental implementation of a slightly older draft
>> of the CSS Counter Styles spec (dated 2012-10-09) that I am using in
>> my text-to-speech project (http://reecedunn.co.uk/cainteoir/engine).
>>
>> This does not currently support 'speak-as' (the property was not
>> introduced in the revision I used). However, I intend to improve and
>> update the implementation to the current version of the Counter Styles
>> spec. When I do this, I can provide feedback on the 'speak-as'
>> property.
>>
>> A cursory inspection of the property looks ok.
>>
>> I have 2 comments regarding named style lookup:
>>
>> 1. Is that handling recursive counter style lookup is undefined -- for example:
>>
>>     @counter-style foo {
>>         speak-as: foo;
>>     }
>>
>> Should the style be treated as not existing (i.e. default to auto) in this case?
>
> Ah, thanks for catching that.  Cycle detection is currently defined
> for the 'fallback' descriptor, so I'll just copy that behavior over to
> 'speak-as'.  In the case of cycles, yes, it'll default to 'auto'.

The note in the fallback descriptor mentions that cycles are not
strictly an error. The example given is an odd/even counter style
pair. It is not clear in the note when a cycle constitutes an error --
is it that if no matching value is found after walking the graph a
complete cycle, then there is an error? That would make sense.

So if I am reading the spec correctly, the traversal be something like:
1.  traverse the counter styles via the speak-as property, resolving
cycles and default values accordingly;
2.  traverse the fallback chain as done for resolving the presentation
counter style from the counter style resolved in (1).

Thus, if you have:

@counter-style odd_even { speak-as: 'odd_even_speak'; }
@counter-style odd_even_speak { speak-as: 'odd_speak'; }
@counter-style odd_speak { symbols: 'odd'; fallback: 'even_speak'; ... }
@counter-style even_speak { symbols: 'even'; fallback: 'odd_speak'; ... }

Then the text being spoken will resolve as 'odd', 'even', 'odd', ...
as the fallback chain is resolved. NOTE: I am not sure exactly how you
would specify an alternating fallback chain as described in the note
within the fallback property description.

>> 2. When should counter style resolution take place? That is, given:
>>
>>     @counter-style abc { speak-as: def; }
>>     @counter-style def { ... }
>>
>> Will abc use def or auto as the speak-as value?
>
> CSS doesn't care about ordering constraints except when explicitly
> noted.  (That is, stylesheets aren't considered to be processed
> eagerly in a particular order; it's a declarative language, so
> references can be to things earlier or later in the document, or in
> earlier or later documents.)
>
>> If this is valid, speak-as cycles with more than one item are possible
>> (e.g. a -> b -> c -> a). Thus, should there be a maximum depth to
>> resolve these chains before defaulting to auto?
>
> Resolving 'fallback' chains requires arbitrary-depth cycle detection
> already, so resolving 'speak-as' won't be any more difficult.  In
> general, there are a few features in CSS now that require
> arbitrary-depth cycle detection, such as detecting cycles in Custom
> Properties/Variables, so if you're doing a CSS implementation you need
> a good cycle detector anyway.  There are appropriate and efficient
> algorithms in the literature for this.
>
> ~TJ
Received on Wednesday, 30 October 2013 18:11:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2013 18:11:41 UTC