Closed Bug 219516 Opened 21 years ago Closed 13 years ago

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

Categories

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

Product:
Core
Component:
Layout: Block and Inline
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: travis.watkins, Unassigned)

References

(
URL
)

Details

(Keywords: qawanted, testcase)

Attachments

(2 files)

Simple test case to show this bug
283 bytes, text/html
Details
Testcase showing all text-decoration values on inputs (type=button) and paragraphs
1.01 KB, text/html
Details 
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.
WFM 20030911 PC/WinXP
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.
No change, still not sure what could be causing this. I was told it could be a
'regression bug', whatever that is.
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.
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.
Summary: text-decoration doesn't work on :hover with submit input → text-decoration doesn't work on submit input in standards mode
<input> is a replaced element. We should handle it the same way as an image as 
far as text-decoration goes.
In other words, do what we do now, no?
If we decide to fix this, it's a matter of adding "text-decoration: inherit" to
the *|*::-moz-button-content rule in forms.css.....
OK, marking invalid per comment 6.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
*** Bug 230983 has been marked as a duplicate of this bug. ***
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 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?
*** Bug 256653 has been marked as a duplicate of this bug. ***
(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. :-/
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).
Severity: normal → minor
Status: RESOLVED → UNCONFIRMED
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All
Resolution: INVALID → ---
*** Bug 264026 has been marked as a duplicate of this bug. ***
*** Bug 270379 has been marked as a duplicate of this bug. ***
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.
*** Bug 273283 has been marked as a duplicate of this bug. ***
Keywords: testcase
*** Bug 292363 has been marked as a duplicate of this bug. ***
This works if the button is position absolute or fixed or if the page is in
quirks mode.
leaving this unco while others dupe bugs aginst it seems pointless
->New ( based on comment #15 )
Status: UNCONFIRMED → NEW
Ever confirmed: true
> This works if the button is position absolute or fixed

Or if it's just |display: block|, which those force.  See comment 5.
*** Bug 310047 has been marked as a duplicate of this bug. ***
Note that this needs a clear spec before we change any code.  Ian?
Blocks: 300051
# 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.
Blocks: 332124
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.
Maybe related to the bug about text-decoration on inline-block?
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: Block and Inline
QA Contact: ian → layout.block-and-inline
No longer blocks: 300051
after 4 years, why haven't you resolved this bug yet?
Please, can you fix it in firefox3?
Flags: blocking1.9?
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.
Flags: blocking1.9? → blocking1.9-
But it is a bug!

Why can't you resolve it?
> 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".
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.
Flags: wanted1.9.1?
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1-
>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


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
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.
Summary: text-decoration doesn't work on submit input in standards mode → text-decoration doesn't work on submit input button in standards mode
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!
Status: NEW → RESOLVED
Closed: 21 years ago → 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: