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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 5 Dec 2011 07:35:06 -0800
Message-ID: <CAAWBYDCY=DrJqNtevjuKXwoaWHtdi+6A19nQ7knZJ7sRqiAg4A@mail.gmail.com>
To: Florian Rivoal <florianr@opera.com>
Cc: www-style@w3.org
On Mon, Dec 5, 2011 at 2:07 AM, Florian Rivoal <florianr@opera.com> wrote:
> 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.

Both of the literal variants seem problematic, unfortunately.  The
first uses commas with a different precedence than normal (ordinarily,
spaces bind tighter than commas), and the second uses a brand-new
character that we haven't used as a separator before.

> 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.

Ah, I missed that you were suggesting that multiple 'convert's should
be processed in order, and didn't grasp the significance of the
examples that used that.  Okay, given that, keeping them in a single
descriptor is ideal.

Received on Monday, 5 December 2011 15:35:56 UTC

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