Re: Proposal: "text-transform" property revision

On Oct 10, 2007, at 1:35 AM, Benjamin Hawkes-Lewis wrote:

>
> Brad Kemper wrote:
>> I don't think it is any further out of line with CSS purpose than  
>> the other text transformation values that exist today  
>> ("capitalize", "uppercase", "lowercase").
>
> I disagree. Those are clearly intended to be styling commands, not  
> data-cleansing commands.

Well, if purity is more important than usefulness (tempered by  
implementation difficulty), then maybe, although it seems like a  
pretty fine line separating them in this case. If I want the style of  
my text to be lowercase except for the first letter of each word,  
that is a styling command that is going to be much more useful most  
of the time than, say, "lowercase". And the fact that the proposed  
new keyword does NOT deal with initialisms and names with apostrophes  
and such is proof that it is NOT a robust data cleansing routine, but  
rather something to make certain texts more readable, and therefore  
within the realm of visual style.

> The underlying HTML can be separated from the CSS, for example for  
> exposure to assistive technologies, without losing content  
> information. See also:
>
> http://www.w3.org/TR/WCAG20-CSS-TECHS/#F2
>
> In the HTML layer, text should be in "natural" case... [clipped]

The link you provided makes a good case for not doing something like  
this in the HTML layer, which in one of my earlier examples, is  
exactly what I had to resort to in order to improve readability (I  
had to transform the case, and could not catch 100% of the times that  
would cause an improper initialism). Had I the ability to use CSS for  
this, then the HTML layer used for assistive technologies would have  
been unaffected, and we could all complain together about the  
problems of the data layer at that point (which would have exactly  
zero effect, believe me).

But the ability to transform the case of the text via CSS to make it  
more readable would have been useful. I would also like to add here  
that using "lowercase" or "uppercase" as a style command would have  
had an equally deleterious effect as the proposed "title-case"  
keyword. Abbreviations like "IT" and "IS" would be misconstrued as  
"it" and "is" in lowercase, and would be ambiguous in uppercase. The  
same problem would apply to all acronyms that are also meaningful  
words. So I don't think the similar effect a "title-case" keyword  
would have on such words should really be an argument against its use.

>
>> Speaking for myself, I have had on several occasions been involved  
>> in co-branded sites where I could provide a style sheet for the  
>> other site to link to, but could not change any of the data  
>> itself. If those other sites, which I wanted to conform  
>> stylistically with my own, decided on all caps, there was really  
>> nothing I could do about it to make them Title Case. On the other  
>> hand, if my site had used all caps for the headlines, lets say,  
>> then I could have used a style sheet rule to make their headlines  
>> all caps as well. Magic, but only in one direction, and this new  
>> keyword would provide more parity.
>
> I sympathize with your plight! However, I don't think it's the  
> purpose of CSS to fix this problem any more than it's the purpose  
> of CSS to correct spelling or provide missing alternative text for  
> images. Data problems must be fixed in the data layer, or it's not  
> a real fix.
> --
> Benjamin Hawkes-Lewis

Yes, and in an ideal world, they would be, perhaps. I don't think  
this really is equivalent to fixing spelling. The text in all caps is  
just as valid (from a language/grammar point of view) as it would be  
if it had had the "capitalize" transformation applied to it. rather,  
it is something that would help with the presentation of text to  
match a usage style, just as with the other transformation keywords.  
And since it essentially combines the effects of two existing  
keywords to do something that people would find very useful (I would  
argue more useful, more often, than those keywords by themselves), I  
wouldn't think  it would be much of an implementation problem for  
those already supporting the other keywords.

Received on Thursday, 11 October 2007 17:21:11 UTC