56253 - [FIX]<input> contents inherit text-indent

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Hallvard B Furuseth]

From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; SunOS 5.7 sun4u)
BuildID:    2000100610

The contents of input boxes are indented
by the enclosing text-indent, often right
out of the box.

Reproducible: Always
Steps to Reproduce:
1. View the upcoming attachment.
2. Type in the input field.

Actual Results:  1. Contents of both text input field and
   Reset box are indented.
2. And of course the cursor can't reach the left edge.

Expected Results:   No indentation inside the fields.

Text-indent generally seems to be too aggressive.  See also:
Bug 45694 (1st line of each page is indented as a paragraph),
Bug 51968 (align=center should override text-indent)

Comment 1

[Hallvard B Furuseth]

Attachment: HTML with <input> fields inside <p style=text-indent...>

Comment 2

[Hixie (not reading bugmail)]

This can be fixed by putting 
   text-align: 0;
...in the html.css rule for input and button elements.

Comment 3

[Asa Dotzler [:asa]]

is this a bug in mozilla? should it be confirmed or marked Invalid?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd say it is.  INPUT cannot be described as a block according to CSS.

Comment 5

[Marc Attinasi]

Accepting bug.

Comment 6

[Hixie (not reading bugmail)]

These elements can be described as inline-block, though, assuming CSS3, and at
that point it _does_ become valid for them to inherit the text-indent.

(BTW, I meant 'text-indent' not 'text-align' earlier.)

Comment 7

[Vladimir Strigun]

Reproduced for me:                                                             
              
with 04/06/2001 nightly under WinNT4.0
with 04/08/2001 nightly under RH Linux 6.2

I have the same behaviour:  

Actual Results:  1. Contents of both text input field and
   Reset box are indented.
2. And of course the cursor can't reach the left edge.
                                                               
                                                                               
                          

Comment 8

[Marc Attinasi]

OK, so putting 'text-indent: 0' in forms.css for input and button elements will
fix this. Other than that fix, which could be considered a workaround according
to dbaron's line of reasoning, we need to dramatically change how we apply style
to controls.

I'm sending this to rod s. so he can decide if he wants the new rule in forms.css

A more general bug about how style is applied to form controls should probably
be opened - there are already several specific instances recorded of that
general problem.

Comment 9

[rods (gone)]

Setting to 0.9.1, I will probably check in this fix as a work around.

Comment 10

[Raghu Sakleshpur]

Updating OS to All based on Vladimir's comments

Comment 11

[rods (gone)]

Index: forms.css
===================================================================
RCS file: /cvsroot/mozilla/layout/html/document/src/forms.css,v
retrieving revision 3.11
diff -u -r3.11 forms.css
--- forms.css   2001/04/18 02:56:12     3.11
+++ forms.css   2001/05/01 14:15:29
@@ -71,6 +71,7 @@
   -moz-user-focus: normal;
   -moz-binding: url("resource:///res/builtin/platformHTMLBindings.xml#inputFiel
ds");
   padding: 1px 0 1px 0;
+  text-indent: 0 ! important; /* work around for Bug 56253 */
 }

 textarea {

Comment 12

[rods (gone)]

I am giving Ian's fix an r=rods

Comment 13

[Marc Attinasi]

sr=attinasi

Comment 14

[Hixie (not reading bugmail)]

Hold on!

Do we really need the "!important"?

Putting it there will block content authors from having text-indents in buttons
if they want them. There is no reason, as far as I can tell, to use "!important"
in this case.

Comment 15

[rods (gone)]

Well, it breaks if it is greater than zero, so I figure it should be !important
for all form controls.

Comment 16

[Hixie (not reading bugmail)]

What "breaks"? Web authors could very well intentionally use 'text-indent' on 
form controls. The only times we should use '!important' are when allowing the
author to change the value would do something like cause a crash or open up a
security flaw or some such.

Comment 17

[rods (gone)]

Ian, I got this bug because it doesn't work "right" when not set to zero, so if 
I check it in without !important, then I am just going to see a bunch more bugs 
files on this. But then maybe I will get bugs files that it doesn't work also.

Comment 18

[Hixie (not reading bugmail)]

When set to non-zero it works per the spec, right? The only way that authors
could end up with a non-zero case (if you don't put !important) is if they
explicitly ask for one. So that's fine, those bugs will be INVALID and should
end up being triaged as such even before you see them.

Comment 19

[rods (gone)]

Ian, no it is all screwed up when non-zero. So I want to keep them from making 
it anything but zero so it behaves correctly.

Comment 20

[Hixie (not reading bugmail)]

Is there a bug about how it is all screwed up?

Comment 21

[rods (gone)]

Ian, I thought THIS was the bug about how it is screwed up.

Comment 22

[Hixie (not reading bugmail)]

Oh. Well in that case, the fix that is given above, with sr=attinasi and r=rods,
is not a valid fix. It's a band-aid workaround, and as such should not be 
checked in on the trunk.

Comment 23

[Hixie (not reading bugmail)]

Wait. If this is the bug about text-indent not working correctly on form 
controls, then which is the bug about text-indent being inherited into 
form controls by default, which is also a bug? Is this bug covering both
issues? I'm confused...

Comment 24

[Hixie (not reading bugmail)]

*** Bug 83895 has been marked as a duplicate of this bug. ***

Comment 25

[rods (gone)]

Attachment: more precise fix

Comment 26

[rods (gone)]

As it turns out, text-indent, whether it is inherited or as inline style breaks 
all form controls except text fields and textareas. This new patch will fix 
that.

Please give it an r=

Comment 27

[Kevin McCluskey (gone)]

We should not let the text-indent be set if we are not prepared to handle it
correctly in the form elements.
patch looks good.
r=[e-mail]

Comment 28

[David Hyatt]

sr=hyatt

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is there instead a pseudo-element inside the form controls on which you could
specify the 'text-indent' (where you wouldn't need the !important)?  (Do
!important rules in ua.css reduce the effectiveness of the memory reduction in
hyatt's new style stuff?)

Comment 30

[rods (gone)]

Attachment: new patch with text-align set on psuedo content

Comment 31

[rods (gone)]

David, good suggestion (see new patch). The only question is whether I should 
add the rule to the input file to keep the text in the text portion from sliding 
over. I can go either way with that. 

Comment 32

[Hixie (not reading bugmail)]

I still don't think we should check in this work around into the trunk.

There are two bugs here: 

First, text-indent being inherited by default into form controls. The fix for 
that is simple -- It's 
   http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37519
...but without the !important declarations.

Second, form controls don't support text-indent. This is the main bug that 
should be fixed, although I don't think any attempt has been made to fix it.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ian, I think doing this on the pseudo-elements inside the form is perfectly
reasonable, although I admit the controls could be designed differently, there's
no need for them to be.

Are there any cases that the first patch fixes but the latter patch doesn't?
I'd prefer to approve the latter one but it doesn't have r=/sr=.

We shouldn't let text-indent mess up form controls -- form controls are a black
box as far as CSS's rendering model is concerned.

Comment 34

[Hixie (not reading bugmail)]

dbaron: As we both know, that's one of the few things on which we have a 
technical disagreement. :-)

Comment 35

[rods (gone)]

Complex issue, moving off to future milestone

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I was hoping you'd check one of those fixes in -- I'd rather not support
text-indent within form controls (if there is such a thing) than do it wrong...

Comment 37

[Simon Montagu :smontagu]

*** Bug 112174 has been marked as a duplicate of this bug. ***

Comment 38

[Boris Zbarsky [:bzbarsky]]

*** Bug 139286 has been marked as a duplicate of this bug. ***

Comment 39

[Alex Vincent [:WeirdAl]]

Thanks to bz for finding my bug as a dupe of this one.  I figured someone knew
about it.

Question:  What about the other block-level-only properties?  In CSS2, I count
only about 12 of them, total.

The patch suggestions have probably bitrotted by now; any chance of a workup for
1.0 or 1.1??

Comment 40

[Boris Zbarsky [:bzbarsky]]

*** Bug 171733 has been marked as a duplicate of this bug. ***

Comment 41

[Boris Zbarsky [:bzbarsky]]

*** Bug 204891 has been marked as a duplicate of this bug. ***

Comment 42

[Boris Zbarsky [:bzbarsky]]

.

Comment 43

[Boris Zbarsky [:bzbarsky]]

Attachment: Ok, we should just do this

I see nothing "all screwed up" in any of the testcases attached to this bug, so
I don't see a reason to make these !important unless we really feel that users
should not be able to set text-indent on these form controls.

Comment 44

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 135462 [details] [diff] [review]
Ok, we should just do this

David, if you think we should do !important let me know and I'll add that
before checking in.  The <option>, <optgroup>, <button>, etc don't have
anonymous kids, so the only ones we could use anonymous content for easily are
text and textarea inputs.

Comment 45

[Boris Zbarsky [:bzbarsky]]

Checked in.