Re: [css3-text] @text-transform

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?

>> 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. Note that the turning
all its content to white space as discussed in the previous issue has
the same implications.

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.

  - Florian

Received on Tuesday, 3 January 2012 10:18:38 UTC