W3C home > Mailing lists > Public > www-style@w3.org > March 2004

RE: [CSS21] CSS 2.1 text-transform ambiguity

From: Ernest Cline <ernestcline@mindspring.com>
Date: Mon, 1 Mar 2004 16:24:40 -0500
Message-ID: <410-22004311212440328@mindspring.com>
To: "Felipe Gasper" <fgasper@freeshell.org>, www-style@w3.org




> [Original Message]
> From: Felipe Gasper <fgasper@freeshell.org>
>
>      I am designing a web application for managing accounting data. To
prevent 
> users from "instinctively" holding SHIFT to capitalize, I am capitalizing
all 
> text displayed in form elements (input[type='text'] {text-transform: 
> uppercase}). This, of course, has no effect on the *actual* data passed
to the 
> application server.
>
>      This technique works in Gecko and IE, but KHTML (both Konqueror and
Safari) 
> ignores this CSS property of the <input> tag, presumably because,
technically, 
> this is not "enclosed" text as the specification seems to point out.
>
>      Perhaps some stipulation should be added to the CSS spec regarding
this 
> useful property?

Hmmm.  I can see it both ways.  The user entered text is NOT part of the
contents of that element, so should a UA apply text effects to the entered
value or not? The CSS3 UI working draft may provide a possibility.
The ::value pseudo-element provides an explicit way to style the value
of a form control.  It could be that KHTML implements this; but  I have
no knowledge of KHTML.  In any case, it would be simple to test:
   input[type='text']::value {text-transform: uppercase}
and see if it works.

Another possibility is that as a security measure, KHTML disables
certain types of effects for form controls.  (Altho why text-transform
would be considered a security hazard is beyond me.)
Received on Monday, 1 March 2004 16:24:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:27 GMT