Bug 76122 - CSS text-transform property not applied on input type="text" fields
Summary: CSS text-transform property not applied on input type="text" fields
Status: CONFIRMED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: 4.8.4
Platform: FreeBSD Ports FreeBSD
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL: http://www.gtalbot.org/BrowserBugsSec...
Keywords: reproducible, testcase, triaged
: 149366 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-25 17:55 UTC by Felipe Gasper
Modified: 2012-06-20 22:15 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
testcase (235 bytes, text/html)
2008-04-06 18:06 UTC, Nic Gould
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felipe Gasper 2004-02-25 17:55:59 UTC
Version:            (using KDE KDE 3.2.0)
Installed from:    FreeBSD Ports
OS:          FreeBSD

The following HTML, in IE and Mozilla, capitalizes the text in the form input, but not in Konq or Safari. Reading the spec, I'm not sure exactly which would be correct behavior; all browsers capitalize the paragraph.

-------------------
<html>
<head>
<style type='text/css'>
.testClass {
     text-transform: uppercase;
}
</style>
</head>
<body>
<input class='testClass' type='text' />
<p class='testClass'>this is all in lowercase in the source file.</p>
</body>
</html>
Comment 1 Stephan Kulow 2004-02-26 14:55:58 UTC
do they only show it uppercase or do they also uppercase when sending to the site?
Comment 2 Felipe Gasper 2004-02-26 16:33:37 UTC
If I understand your question correctly, you're asking me to confirm that CAPS LOCK isn't down when typing into Moz or IE using this test page. CAPS LOCK is not down. It shows whatever is typed in as uppercase. Of course, it doesn't actually alter the data, but it just uppercases the display text. So for example, if you typed "hello", it would display as "HELLO" in the browser, but it would be submitted as "hello".
Comment 3 Stephan Kulow 2004-02-27 11:10:42 UTC
I didn't ask about CAPS LOCK :)

But your second sentense answers my question. Because altering the data would be easy - displaying something different than submitting might be hairy to add ;(
Comment 4 Felipe Gasper 2004-02-27 16:34:15 UTC
It's worth pointing out that the CSS 2.1 spec only talks about "an element's text", so strictly speaking, this CSS property shouldn't affect empty tags like <input>. OTOH, I think it's a nice feature to have, and it doesn't compromise anything else (that I can think of) to have it.

http://www.w3.org/TR/2004/CR-CSS21-20040225/text.html#caps-prop

I'm going to ask the CSS 2.1 people to clarify this property with regard to <input>; I think the way it's worded now is somewhat ambiguous.
Comment 5 Felipe Gasper 2004-03-05 17:59:33 UTC
Well, the verdict from those on the www-style@w3.org list is that since the value text isn't *enclosed* in the input field, text-transform etc. shouldn't apply to it, which means KHTML is more "letter of the law"-compliant. (Gecko is apparently likely to switch to a different form handling method which will, among other things, make it behave like KHTML in this way.) Still, a browser loses nothing and gains IE compatibility by implementing this.

CSS3 has the ::value pseudo-selector, so the ability to style a form element's value presentation will be called for eventually. A long shot, but does KHTML implement that yet?
Comment 6 Allan Sandfeld 2006-05-01 14:40:17 UTC
No we do not implement ::value yet. It is an XFORMS selector though.
Comment 7 Nic Gould 2008-04-06 18:04:01 UTC
Tested in 4.0.3 - confirmed that behaviour is still the same as reported previously. text-transform does not apply to the input box. Latest version of firefox 2 still does apply it though.
Comment 8 Nic Gould 2008-04-06 18:06:12 UTC
Created attachment 24244 [details]
testcase

Inline html from above added as testcase.
Comment 9 Gérard Talbot (no longer involved) 2010-03-29 23:22:43 UTC
Hello all,

Could it be possible for someone to update the current bug report summary from

[testcase] text-decoration CSS property doesn't work in input fields

and modified to

[testcase] CSS text-transform property not applied on input fields

please?

I also think this bug should be resolved as INVALID since text-transform should not apply on block-level replaced elements.

As for XForms ::value pseudo-element ( http://www.w3.org/TR/xforms/#N90219 ),  text-transform should not apply anyway for the same reason. When user submits content (personal data), "a" (code position 97) should look like an "a", not like an "A" (code position 65).

regards, Gérard
Comment 10 Gérard Talbot (no longer involved) 2012-01-05 22:05:40 UTC
> text-transform should
> not apply on block-level replaced elements.

I meant to say that I believe that text-transform should not apply to inline-block replaced elements.


Can someone update the current bug report summary from
 
[testcase] text-decoration CSS property doesn't work in input fields

and modified to

[testcase] CSS text-transform property not applied on input type="text" fields
 
please?  Thanks!

Gérard
Comment 11 Gérard Talbot (no longer involved) 2012-01-13 07:29:09 UTC
Updating bug summary
Comment 12 Andrea Iacovitti 2012-06-08 18:21:30 UTC
*** Bug 149366 has been marked as a duplicate of this bug. ***
Comment 13 Myriam Schweingruber 2012-06-18 13:52:27 UTC
What is the last version this is confirmed in?
Comment 14 Gérard Talbot (no longer involved) 2012-06-20 17:40:01 UTC
Attachment 24244 [details] is the testcase but it is in quirks mode: it does not have a doctype declaration triggering web standards compliant rendering mode. 

To know Konqueror's current rendering engine and the rendering mode currently used by Konqueror, read
Investigating Konqueror Bugs: Konqueror rendering engine and webpage rendering mode 
http://www.konqueror.org/investigatebug/#rendering-mode

So, 
1st: we need to create a perfectly valid reduced testcase, fully compliant with web standards and following guidelines given at
Investigating Konqueror Bugs: HTML/CSS problem
http://www.konqueror.org/investigatebug/#html

2nd: verify that CSS text-transform can apply to input type="text" fields
which seems to be applying to input type="text" although I am still skeptical...

Valid test:
http://www.gtalbot.org/BrowserBugsSection/Konqueror4Bugs/Bug76122-Text-transform-Input-Text.html

Firefox 13.0.1, Opera 12.0 and Chrome 19.0.1084.56 pass this test.

Konqueror 4.8.4 fails this test.

I'll chek later that test with IE 8 and Safari 5.1.7.

Adding reproduceable, testcase keywords to bug report.

Gérard
Comment 15 Gérard Talbot (no longer involved) 2012-06-20 18:30:50 UTC
(In reply to comment #5)
> the verdict from those on the www-style@w3.org list is that since the
> value text isn't *enclosed* in the input field, text-transform etc.
> shouldn't apply to it, which means KHTML is more "letter of the
> law"-compliant.

Felipe, always give a link to the threaded discussion where this verdict is given so that we can safely resolve a bug based on such discussion and verdict.

CSS 2.1 text-transform ambiguity
From: Felipe Gasper 
Date: Mon, 01 Mar 2004 14:16:25 -0600
http://lists.w3.org/Archives/Public/www-style/2004Mar/0000.html
is most likely the start of that threaded discussion.

http://lists.w3.org/Archives/Public/www-style/2004Mar/0004.html
has interesting comments:
"
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.
"

This bug report needs a spec clarification and the spec most likely requires an explicit normative indication wrt this issue of entered text by user. I have posted:

[CSS21] [CSS3 Text] Should 'text-transform: uppercase' apply to input type="text" (text entered, typed in text field by user)?
http://lists.w3.org/Archives/Public/www-style/2012Jun/0474.html

Gérard
Comment 16 Gérard Talbot (no longer involved) 2012-06-20 22:14:46 UTC
We got an answer from Elika "fantasai" Etemad, the expert of many CSS experts :)
http://lists.w3.org/Archives/Public/www-style/2012Jun/0476.html

{
yes, text-transform applies to text in form elements.
However, since form element styling is out-of-scope for CSS [1], it's
entirely possible that a particular implementation act as if it
forces the contents to have 'text-transform: none'.

So the testcase is valid, but failure does not indicate non-conformance.
(I suppose it should therefore be marked as 'may'[2].)
}

[1]: 
"
CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.
"
CSS 2.1, section 3.2 UA Conformance
http://www.w3.org/TR/CSS21/conform.html#conformance

So, in other words, Konqueror fails this test 
http://www.gtalbot.org/BrowserBugsSection/Konqueror4Bugs/Bug76122-Text-transform-Input-Text.html
but implementing such feature for input type="text" is optional in CSS and not required to achieve CSS 2.1 conformance.

[2]:
"
5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)
"
http://www.w3.org/TR/CSS21/refs.html#ref-RFC2119
http://www.ietf.org/rfc/rfc2119.txt


I am using
KDE Platform Version: 4.8.4
Konqueror version: 4.8.4 (with KHTML rendering engine)
Qt Version: 4.8.1
Operating System: Linux 3.2.0-25-generic-pae i686 (32bits)
Distribution: Kubuntu 12.04 LTS
here.

I have modified this bug Component field, Version field, URL field, Keywords field.
I am marking this bug as NEW

Gérard