Closed
Bug 786946
Opened 12 years ago
Closed 12 years ago
text-decoration: line-through should not be painted on a <select> child
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla18
People
(Reporter: deleted450090, Assigned: bzbarsky)
Details
Attachments
(2 files)
487 bytes,
text/html
|
Details | |
4.43 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120821170930 Steps to reproduce: Outlined in this StackOverflow post: http://stackoverflow.com/questions/12191753/css-overriding-an-inherited-text-decorationline-through#comment16324982_12191753 Demo at this fiddle: http://jsfiddle.net/Y7ZVp/ Actual results: Line through remains on child element with parent text-decoration: line-through even if child has text-decoration: none Expected results: The child should return to normal text.
Comment 1•12 years ago
|
||
Comment 2•12 years ago
|
||
I see no Difference to other Browsers.
Updated•12 years ago
|
Component: Untriaged → Style System (CSS)
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All
Comment 3•12 years ago
|
||
Reproducible on the 09/04 Firefox 18 Nightly on Mac and Linux (didn't try on Windows). As XtC4UaLL says, the same issue reproduces in Safari, Chrome, and Opera.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 4•12 years ago
|
||
And that's because the spec says to do this. Marking invalid, but if someone has the time to find the oldest report on this and mark duplicate, feel free!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Whiteboard: DUPEME
Assignee | ||
Comment 5•12 years ago
|
||
Though wait. I don't see the strike-through going through the select on Chrome on Mac. Does it do so on Windows?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Assignee | ||
Comment 6•12 years ago
|
||
Resummarizing to cover the actual issue, not the incorrect initial description. David, I think we've considered not propagating text-decoration to "replaced" elements in the past... Thoughts?
Summary: Inheritance of text-decoration: line-through is unable to be overridden → Inheritance of text-decoration: line-through should not propagate to a <select> child
Assignee | ||
Updated•12 years ago
|
Summary: Inheritance of text-decoration: line-through should not propagate to a <select> child → text-decoration: line-through should not be painted on a <select> child
(In reply to Boris Zbarsky (:bz) from comment #6) > Resummarizing to cover the actual issue, not the incorrect initial > description. > > David, I think we've considered not propagating text-decoration to > "replaced" elements in the past... Thoughts? In some cases we've changed their default display (or that of an anonymous child) from 'inline' to 'inline-block' to cause this (https://hg.mozilla.org/mozilla-central/rev/3a73e65c935e ; https://hg.mozilla.org/mozilla-central/rev/c9dff8b867f0). If we need to do it without that corresponding change in 'display' it might be reasonable as well.
(And I can't think of anything left other than select, after those two changes, actually.)
Assignee | ||
Comment 9•12 years ago
|
||
OK, well UA behavior for this is as follows: Default display: WebKit: No decorations Presto: No decorations Trident: No decorations Gecko: Decorations display:inline: WebKit: Decorations on combobox, not listbox Presto: No decorations Trident: Decorations in standards mode and IE8 mode. No decorations in IE7 and quirks modes. Gecko: Decorations display:inline-block: WebKit: No decorations Presto: No decorations Trident: No decorations Gecko: No decorations So just flipping the default display will give us the IE8/IE9 behavior and at least match WebKit on combobox. Sounds like we should do that.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → bzbarsky
Whiteboard: DUPEME → [need review]
Version: 15 Branch → Trunk
Assignee | ||
Comment 10•12 years ago
|
||
Attachment #659115 -
Flags: review?(dbaron)
Attachment #659115 -
Flags: review?(dbaron) → review+
Assignee | ||
Comment 11•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8d12416121a6
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla18
Assignee | ||
Comment 12•12 years ago
|
||
And backed out, because it breaks the font-inflation tests for <select>. David, is that a bug in the patch, or in the tests?
Flags: in-testsuite+
Whiteboard: [leave open]
Target Milestone: mozilla18 → ---
Probably the patch, since those tests were written based on desired behavior. Try adding the single line content->IsHTML(nsGkAtoms::select) to the function IsFontSizeInflationContainer in nsFrame.cpp (next to option and optgroup).
Assignee | ||
Comment 14•12 years ago
|
||
Yeah, that works. I'm going to reland with that change.
Assignee | ||
Comment 15•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/175c768112a4
Flags: in-testsuite+
Whiteboard: [leave open]
Target Milestone: --- → mozilla18
Comment 16•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/175c768112a4
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•