- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Fri, 2 Dec 2011 07:53:29 -0800
- To: Florian Rivoal <florianr@opera.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
Good start, Florian. I like your Asterix example. Have you considered some limited form of regex? A boundary indicator would help with your long S case, so that it wouldn't transform at the end of a word (and would also finally allow us to transform to a basic title case). Regex could also indicate ranges without using a separate property name in the @rule. On Dec 2, 2011, at 6:49 AM, "Florian Rivoal" <florianr@opera.com> wrote: > On Thu, 01 Dec 2011 14:31:31 +0100, John Daggett <jdaggett@mozilla.com> wrote: > >> fantasai wrote: >> >>> === Keep in Level 3 === >>> >>> These features are both already-implemented and required for EPUB: >>> >>> * text-transform >>> >>> === Defer to next level === >>> >>> * text-replace / @text-transform >> >> There's an issue that's been brought up a couple times, most recently >> at the TPAC F2F, about whether the right approach for transforms like >> 'full-size-kana' is to add a new value, given that the use case is >> fairly small. Rather than adding more values for uncommon use cases >> like 'full-size-kana', I think we should instead support a simple >> mechanism like @text-transform that allows authors to specify >> arbitrary transforms for use cases like this. This allows authors to >> define a transform that fits their needs without the need for the CSS >> WG to define new values for small use case situations. >> >> If we can't resolve this before the next WD of CSS3 Text, I'd at least >> like the issue marked in the spec, wherever 'full-size-kana' is defined. > > I've made a little draft of what the proposed @text-transform could look like, > and how it would be used to solve the use cases we've discussed so far: > > http://wiki.csswg.org/ideas:at-text-transform > > This is a first try, so I am sure that a lot of things can be tweaked, but > I think that this illustrates that a generic mechanism: > > 1) wouldn't be very hard to spec > 2) wouldn't be very hard to use > 3) could be used by authors to solve many more use cases that > the ones th WG has identified and understands well > > I think we should here do something similar to what we're going with counter styles: > Collect a number of use cases, and use them to refine the generic mechanism, then > make the generic mechanism normative, and keep the use cases and associated research > published somewhere, on the side. > > Yes, this is a little more work than just defining full-size-kana. But it still isn't > a very large feature, and it is orders of magnitude more useful than full-size-kana > alone. > > If there is a sense of urgency about solving the full-size-kana use case quickly, let's use > this momentum to get this @text-transform thing done quickly. > > - Florian >
Received on Friday, 2 December 2011 15:54:01 UTC