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

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

From: Florian Rivoal <florianr@opera.com>
Date: Mon, 05 Dec 2011 11:07:33 +0100
To: www-style@w3.org
Message-ID: <op.v50g2vvd4p7avi@localhost.localdomain>
On Fri, 02 Dec 2011 17:58:24 +0100, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> On Fri, Dec 2, 2011 at 6:49 AM, Florian Rivoal <florianr@opera.com>  
> wrote:
>> 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
>
> For the first issue (regarding whether to use an ident or an
> function-with-ident), just use an ident and define a few special
> values as not overwritable by authors (specifically, "none",
> "initial", "inherit", and any other global values we end up creating).

Sounds fine to me.

And if the author overrides an existing keyword that can be used as a value
of text-transform (eg: uppercase), the author's definition wins?

> For the 'convert' and 'convert-range' descriptors, I recommend instead
> taking an approach similar to what Lists does now.  Create two
> descriptors "convert-from" and "convert-to" and have each take a
> space-separated list of idents, strings, or <urange>s (from Fonts).
> The corresponding entries in the two lists are then paired up.

<urange>s are neat. I didn't know about them, and they definitely
make sense here. That said, maybe we should also keep the literal
character notation, as "a","z" (or the "a":"z" variant) is a lot
more readable than U+41-5A.

As for splitting into two descriptors, I don't think I agree.

In my proposal, when you have multiple convert descriptors (or
convert range descriptors), the the resulting transform is not
 from the union of their 'from' range to the union of their 'to'
range. Each conversion is applied sequentially, and the order
is significant.

For your syntax, I am not sure if you meant that you should be able
to write multiple pairs of convert-from and convert-to. If no, then
your proposal is able to express less, and I'd argue that's a problem.

If yes, I am not sure I find it pretty. My initial proposal is a bit
out of ordinary for css, giving a meaning for the order in which the
descriptors are given. But yours pushes the ordering constrains
further. Should this be allowed?

@text-transform abc
{
     convert-from: "a";
     convert-from: "b";
     convert-to: "b";
     convert-to: "c";
}

I'd say no, and for similar reasons, I think my initial proposal
should be replaced by my newer one. Instead of this:

@text-transform abc
{
     convert: "a" to "b";
     convert: "b" to "c"
}

I now prefer:

@text-transform abc
{
     convert: "a" to "b", "b" to "c";
}

> Hmm.  That still doesn't get us around the issue of what definition
> for grapheme cluster to use, though.  Darn.

Unicode recommends using extended grapheme clusters "for general
processing", while legacy grapheme clusters are supposed to be for backward
compatibility. I may very well be missing something important, but that
suggests we should be using extended grapheme clusters.

Elika, as you were the one who suggested legacy, could you say why?

  - Florian
Received on Monday, 5 December 2011 10:08:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:47 GMT