- From: Reece Dunn <msclrhd@googlemail.com>
- Date: Wed, 30 Oct 2013 01:37:02 +0000
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>
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?
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?
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?
> (If we end up adding a group-separator descriptor in response to
> http://lists.w3.org/Archives/Public/www-style/2013Oct/0702.html
> then that should probably be at-risk, too.)
>
> ~fantasai
>
Received on Wednesday, 30 October 2013 01:37:33 UTC