219516 - text-decoration doesn't work on submit input button in standards mode

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect)

Description

[Travis Watkins]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030911 Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030911 Firebird/0.6.1+

In http://mmcc.cx/submitlink, when you move your mouse over the text it should
get underlined and the input should have a background color of #eee. However the
only thing that seems to work is the cursor: pointer;. I have been told this
works correctly in Mozilla 1.2, so I'm not sure why it wouldn't now.

Reproducible: Always

Steps to Reproduce:
1. Create a page with <input type="submit" value="foobar">
2. Set some CSS to make it change its background-color or text-decoration on :hover

Actual Results:  
Nothing changed.

Expected Results:  
The background-color and text-decoration styles should have taken effect.

Comment 1

[Bill Mason]

WFM 20030911 PC/WinXP

Comment 2

[Travis Watkins]

Do you have any options set? All I've changed from the default install is Web
Developer 0.3 and User Agent Switcher 0.23, however I will try a fresh install
and if one of those was causing the problem, sorry for wasting time.

Comment 3

[Travis Watkins]

No change, still not sure what could be causing this. I was told it could be a
'regression bug', whatever that is.

Comment 4

[Andrew Schultz]

the background change worksforme with linux trunk 20030916, but I do see the
problem with text-decoration.

the text-behavior changed between linux trunk 2002120908 and 2002121021,
indicating bug 1777.

Comment 5

[Boris Zbarsky [:bzbarsky]]

The <input> is a replaced element, not a block.  So it's not clear what exactly
text-decoration applied to it should do.  The :hover is not an issue here, since
adding the text-decoration to the non-:hover rule also does not work.

Comment 6

[Hixie (not reading bugmail)]

<input> is a replaced element. We should handle it the same way as an image as 
far as text-decoration goes.

Comment 7

[Boris Zbarsky [:bzbarsky]]

In other words, do what we do now, no?

Comment 8

[Boris Zbarsky [:bzbarsky]]

If we decide to fix this, it's a matter of adding "text-decoration: inherit" to
the *|*::-moz-button-content rule in forms.css.....

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK, marking invalid per comment 6.

Comment 10

[Stefan [:stefanh]]

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

Comment 11

[Stefan [:stefanh]]

Hmm... When i open attachment 139113 [details] in bug 230983 with Mozilla 2004010905 (Mac
OS 10.2.8) text-decoration: blink; in standards mode works.

Comment 12

[Rick Bull]

Comment 6 states that replaced elements should not implement text-decoration,
but correct me if I'm wrong, that's not what CSS 2 says (unless this has changed
in a newer version):

  If the element has no content or no text content (e.g., the IMG element in
HTML), user agents must ignore this property

So text-decoration should only be ignored if the element doesn't have text
content, which <button> (and the ALT of image for that matter) does. It doesn't
say anything about replaced elements. But maybe I'm misinterpreting it?

Comment 13

[Mats Palmgren (inactive)]

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

Comment 14

[Nikolai Tsvetkov]

(In reply to comment #13)
> *** Bug 256653 has been marked as a duplicate of this bug. ***

Any suggestions to make the button text underlined, anyway?
style="text-decoration: inherited;" doesn't work. :-/

Comment 15

[Mats Palmgren (inactive)]

Reopening for re-consideration. CSS 2.1 says:

"If an element contains no text (ignoring white space in elements that have
'white-space' set to 'normal', 'pre-line', or 'no-wrap'), user agents must
refrain from rendering text decorations on the element."

http://www.w3.org/TR/CSS21/text.html#propdef-text-decoration

IMO, a button "contains text" (unless it's a type=image).

Comment 16

[Bill Mason]

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

Comment 17

[Erik Fabert]

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

Comment 18

[charon me]

i originally posted 270379. sorry for not finding 219516, because it does not
have the word button in it.

Do we see text on top of a button as text or not? I think it is a matter of
interpretation. I understand it is possible to say it is not text (its a value),
but is it an image? is it empty? do font properties apply to it? Does it consist
of letters and is readable? It seems to me it is text indeed.

so to be consistent the alt on an image should be treated the same way, but it
isnt: http://www.charon.sk/button_underline_test.htm
text-decoration:underline is applied do the alt text of an image as well as
other text and font properties.

Comment 19

[Micha³ Piaskowski]

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

Comment 20

[Jason Barnabe (np)]

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

Comment 21

[Jason Barnabe (np)]

This works if the button is position absolute or fixed or if the page is in
quirks mode.

Comment 22

[Peter van der Woude [:Peter6]]

leaving this unco while others dupe bugs aginst it seems pointless
->New ( based on comment #15 )

Comment 23

[Boris Zbarsky [:bzbarsky]]

> This works if the button is position absolute or fixed

Or if it's just |display: block|, which those force.  See comment 5.

Comment 24

[Adam Guthrie]

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

Comment 25

[Boris Zbarsky [:bzbarsky]]

Note that this needs a clear spec before we change any code.  Ian?

Comment 26

[Hixie (not reading bugmail)]

# CSS2.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.
 -- CSS2.1 section 3.2.

Comment 27

[Helen Emerson]

Attachment: Simple test case to show this bug

In quirks mode it displays the underline, in standards mode it doesn't. If you add a position:absolute; style to the button it will display the underline. It probably should be consistent for all types of positioning.

I was testing this on Firefox 2.0.0.3:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

I also tested the same sample in IE7 and Opera 9.10 and it showed an underline in IE7 but no underline in Opera.

Comment 28

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

Maybe related to the bug about text-decoration on inline-block?

Comment 30

[Gabriele Best [:Gabri]]

after 4 years, why haven't you resolved this bug yet?

Comment 31

[Gabriele Best [:Gabri]]

Please, can you fix it in firefox3?

Comment 33

[Boris Zbarsky [:bzbarsky]]

It's not clear that the current behavior is wrong (and hence that there is anything to fix).  The key is to figure out what the "right" behavior is, which is a specification matter, not an implementation one.  

And had you read the bug, you'd know all that.

Comment 34

[Gabriele Best [:Gabri]]

But it is a bug!

Why can't you resolve it?

Comment 35

[Boris Zbarsky [:bzbarsky]]

> But it is a bug!

Why?  Please read this bug carefully.  Then read the relevant specifications.

Then think about whether a GIF of some text styled with "text-decoration: underline" should underline the text.

It's clear that you would like this sort of thing to work.  It's not clear that it should.  It also isn't clear that it shouldn't, which is why this bug is open pending spec clarification and not resolved "invalid".

Comment 36

[Gabriele Best [:Gabri]]

I'm a web developer, not a c++ one :(
I'm not capable to resolve this bug patching firefox.

I think that after 4 years, you should to resolve this stupid bug.

Comment 38

[pike]

>Why?  Please read this bug carefully.  Then read the relevant specifications.

You are repeating comment 6, which marked this bug invalid. 
So I will repeat comment 12, which marked it valid again. Sigh.

" If the element has no content or no text content (e.g., the IMG element in
HTML), user agents must ignore this property. So text-decoration should 
only be ignored if the element doesn't have text content, which <button> does"

so button { text-decoration:underline; } should work, but it incorrectly doesn't. 
notice button {text-decoration:line-through; } does work, btw

*-pike

Comment 39

[pike]

reading my own post, maybe my complaints were not really on the right place; i've now filed a more specific bug report about the <button> element only (so not the <input type=button> element) here : https://bugzilla.mozilla.org/show_bug.cgi?id=444795

Comment 40

[jsp]

Attachment: Testcase showing all text-decoration values on inputs (type=button) and paragraphs

Enhanced testcase, showing all text-decoration values applied to inputs of type button and to paragraph text (the latter to illustrate what is supported by the browser).

At present, while underline, overline, and line-through are not supported by inputs, blink is, so the implementation is inconsistent.  One text-decoration is supported, three are not.

Comment 44

[Adam Brunner]

This bug is not reproducable under:
Firefox 4.0 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0) Gecko/20100101 Firefox/4.0)
Firefox 5.0 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20100101 Firefox/5.0)

Thanks guys!