W3C home > Mailing lists > Public > www-style@w3.org > December 2011

Re: [css3-text] Splitting CSS Text into Level 3 and Level 4

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 2 Dec 2011 07:53:29 -0800
Message-Id: <B2374870-4DA4-45F9-9EBE-45D3FDCFC9EE@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
To: Florian Rivoal <florianr@opera.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:08 UTC