Re: [css3-text] @text-transform

On Jan 3, 2012, at 2:15 AM, "Florian Rivoal" <florianr@opera.com> wrote:

> On Mon, 02 Jan 2012 20:11:28 +0100, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
>> On Jan 2, 2012, at 10:06 AM, "Florian Rivoal" <florianr@opera.com> wrote:
>> 
>>> Hi,
>>> 
>>> I've made a number of changes to my text-transform proposal, in response to feedback since last time.
>>> 
>>> Not everything that was said has been put it, but I think I've marked as issues all the things that
>>> didn't include.
>>> 
>>> http://wiki.csswg.org/ideas/at-text-transform
>> 
>> My thoughts on the following issues:
>> 
>>> ISSUE 2: Should we allow spaces and other collapsible characters in the target? Since text-transform is applied after white space collapsing, what are the implications of generating runs of collapsible white space that won't be collapsed?
>> 
>> It does seem useful, e.g. To turn hyphens into spaces or to turn camelCase into separate words. I think the most sensible thing would be to collapse the results of text-transform.
> 
> CSS3TEXT says: "Text transformation happens after white space processing".
> Do you think white space collapsing should happen twice, then?

Yes, as an extra step when there is white space in the "to" part of text-transform. In all other cases it can be optimized away. 

>>> ISSUE 3: Should we allow an empty <char-list> as the target? It has been suggested that this be used to delete text. I am not sure I like the idea that text-transform could be able to make some non-empty element empty.
>> It wouldn't actually be an empty node. The text should still be there if it was copied unstyled for pasting elsewhere. It wouldn't match ':empty'. I would allow it. One might want to get rid of all spaces in the target, or all punctuation, or all characters that will ultimately be server-ignored anyway in a field that is to be submitted.
> 
> What is the behavior of this "sort of empty but not quite" node with
> regards to margin collapsing, for instance? I suppose the margin of
> the preceding inflow element would be able to collapse through it
> with the margin of the following inflow element.

My conception is that there would still be a text node there, but with zero width, like a shim, if the text-transform removed all the characters. So margin collapsing would remain unaffected. 

> Note that the turning
> all its content to white space as discussed in the previous issue has
> the same implications.

Does it? A node with white space is not the same as an empty node. 

> I am worried if allowing what's proposed in issue 2 and 3 would make
> implementation harder / slower, by forcing multiple passes, reodering
> of the processing stages, and other unpleasant feedback loops
> in the text processing pipeline.

It would require an extra pass in those cases where all glyphs are removed. I don't think there would need to be reordering or feedback loops.

Received on Tuesday, 3 January 2012 17:05:27 UTC