- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Mon, 2 Jan 2012 11:11:28 -0800
- To: Florian Rivoal <florianr@opera.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
- Message-Id: <D25B6AD4-3C6A-49A8-94AB-B5B74A33E988@gmail.com>
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. 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. Otherwise, I think authors would end up hacking around the restriction by replacing the text with some non-visible character, such as a line feed or zero-width space.
Received on Monday, 2 January 2012 19:12:02 UTC