- 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