- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 5 Dec 2011 07:35:06 -0800
- 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? Yeah. >> 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. ~TJ
Received on Monday, 5 December 2011 15:35:56 UTC