Open Bug 307590 Opened 20 years ago Updated 3 years ago

Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

People

(Reporter: mikedbreed, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, testcase)

Attachments

(3 files)

Testcase
353 bytes, text/html
Details
Expanded testcase
882 bytes, text/html
Details
I think this is the way to go
1.25 KB, patch
dbaron
: review-
dbaron
: superreview-
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 This bug applies to HTML pages using the DOCTYPE element=<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">. If a <select> element is styled as having absolute position and either underlining or strikethrough text styling, the underline/strikethrough line appears to the right of the drop down list. Reproducible: Always Steps to Reproduce: 1. Using Firefox v1.0.6, enter the following URL into the address bar http://www.jessandmike.net/mozilla/selectboxbug.html and observe OR 2. Create an HTML document with <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> as the first line 3. Add a form with one select element 4. Add a few options to the select element 5. Add a style for the select element 6. Add position: absolute; to the style for the select element 7. Add text-decoration: underline line-through; to the style for the select element 8. View the page using Firefox v1.0.6 Actual Results: The select box was displayed in the upper left hand corner of the page, with lines sticking out to the right side of the box. Expected Results: The text inside the select element should have been underlined and struckthrough. If the DOCTYPE element is removed, the page will render correctly. If the DOCTYPE element is changed to <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">, the page also renders correctly. If the select element is not absolutely positioned, no styles are applied to the text inside the element at all.
Without the doctype, Mozilla uses 'quirks' mode rendering, where certain rules are ignored. Here we're seeing the correct "by the book" rendering. What's happening is that the <option> entries are not inheriting the text-decoration style; if you style them directly you'll get the desired behavior. This appears to be correct according to http://www.w3.org/TR/2005/WD-CSS21-20050613/text.html#propdef-text-decoration Over to CSS for confirmation by a CSS guru (the prose I linked to is a bit complicated given my CSS knowledge). In any case, the layout seems off in the testcase with those lines to the right.
Assignee: nobody → dbaron
Component: Layout: Form Controls → Style System (CSS)
QA Contact: layout.form-controls → ian
Summary: Underline and strikethrough incorrectly displayed for drop down lists with postion=absolute and HTML 4.0.1 Transitional DOCTYPE → Underline and strikethrough incorrectly displayed for drop down lists with postion=absolute in strict mode
Need testcase attached to the bug.
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: Form Controls
Keywords: helpwanted, qawanted
QA Contact: ian → layout.form-controls
Keywords: testcase
Attached file Testcase —
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
The key is display:block, not positioning.
Keywords: helpwanted, qawanted
Summary: Underline and strikethrough incorrectly displayed for drop down lists with postion=absolute in strict mode → Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #207795 - Flags: superreview?(dbaron)
Attachment #207795 - Flags: review?(dbaron)
I did verify that in the expanded testcase the only behavior that changed is that of the <select>.
Priority: -- → P3
Summary: Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode → [FIX]Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 207795 [details] [diff] [review] I think this is the way to go I'm not going to let you add more callsites that check NS_FRAME_REPLACED_ELEMENT without clearly defining what NS_FRAME_REPLACED_ELEMENT is supposed to mean. For this use case, I think it would be inappropriately set for HTML <button> and a whole pile of things constructed in nsCSSFrameConstructor::ConstructXULFrame.
Attachment #207795 - Flags: superreview?(dbaron)
Attachment #207795 - Flags: superreview-
Attachment #207795 - Flags: review?(dbaron)
Attachment #207795 - Flags: review-
And I think you need testcases for 'text-decoration' being set on inline containers of these "replaced" elements, don't you?
So the real question is what it is about <select> that means we shouldn't strike through it like this.... Should we do it for buttons? Text inputs?
Need clear idea of how this needs to behave...
Assignee: bzbarsky → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Priority: P3 → --
Summary: [FIX]Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode → Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode
Target Milestone: mozilla1.9alpha1 → ---
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: