Closed
Bug 159747
Opened 23 years ago
Closed 21 years ago
everything is inherited into the new boxes in a <marquee>
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla1.7alpha
People
(Reporter: bugzilla_kl, Assigned: bzbarsky)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
380 bytes,
text/html
|
Details | |
1.85 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
..even properties, which shouldn't, as padding, background-image, border, margin
or width/height
Comment 1•23 years ago
|
||
Minimal testcase:
http://www.nexgenmedia.net/bug3/marquee.html
Updated•23 years ago
|
QA Contact: petersen → amar
Comment 3•23 years ago
|
||
I see the problem. Thats not the way its suppose to render. Confirming the bug
and changing the component to style system
Status: UNCONFIRMED → NEW
Component: Layout → Style System
Ever confirmed: true
Priority: -- → P3
QA Contact: amar → madhur
Comment 4•23 years ago
|
||
testcase should show only one 100px height rectangular box with 1px solid lime
border. But I see two 100px height rect boxes on branch builds:
2002-08-01-08-1.0 on WIN2K.
![]() |
Assignee | |
Comment 5•23 years ago
|
||
How about reassigning this too? ;)
The problem is just that style is applied to the anonymous content inside the
<marquee>... Shouldn't XBL prevent that from happening? I seem to recall there
being something in place for that...
Assignee: attinasi → dbaron
QA Contact: madhur → ian
Comment 6•23 years ago
|
||
Are you wanting to stop rules in author sheets from applying, or are you wanting to actually cut off CSS inheritance of properties like font and color? XBL can do the former, but does not have any mechanism for the latter.
![]() |
Assignee | |
Comment 7•23 years ago
|
||
I think in this case preventing author rules from applying is what we need.
![]() |
Assignee | |
Comment 9•21 years ago
|
||
![]() |
Assignee | |
Comment 10•21 years ago
|
||
![]() |
Assignee | |
Comment 11•21 years ago
|
||
Comment on attachment 138821 [details] [diff] [review]
Equally simple fix
David, would you review? I'll fix up the tab in the second hunk before
checking in.
Attachment #138821 -
Flags: superreview?(dbaron)
Attachment #138821 -
Flags: review?(dbaron)
Comment on attachment 138821 [details] [diff] [review]
Equally simple fix
Properties still inherit to the real content, right? Just not the anonymous
content? If so (test that 'color' still works, when inherited), r+sr=dbaron.
Attachment #138821 -
Flags: superreview?(dbaron)
Attachment #138821 -
Flags: superreview+
Attachment #138821 -
Flags: review?(dbaron)
Attachment #138821 -
Flags: review+
![]() |
Assignee | |
Comment 13•21 years ago
|
||
Yeah, that still works. And document rules still apply to the real content.
"inheritstyle" is really pretty badly named...
Assignee: dbaron → bz-vacation
Target Milestone: --- → mozilla1.7alpha
![]() |
Assignee | |
Comment 14•21 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 15•21 years ago
|
||
Comment on attachment 138820 [details]
Simple testcase
Note that IE6/Win shows a top and bottom border on the marquee with this
testcase. Are we aiming for (marquee-)parity with IE?
Comment 16•21 years ago
|
||
The current XBL spec has a different name for "inheritstyle." I agree that the name is bad, and Hixie and
I have fixed it in the spec.
![]() |
Assignee | |
Comment 17•21 years ago
|
||
Malcolm, could you attach a screenshot of what IE shows?
Comment 18•21 years ago
|
||
screenshot from IE6: http://nexgenmedia.net/IEMarquee.png
![]() |
Assignee | |
Comment 19•21 years ago
|
||
Um... so the non-anonymous div in IE is _not_ being scrolled with the text? Or
what? Notice that in Mozilla, with my patch, there is a single red border
around the text; but it's shrink-wrapped.
Comment 20•21 years ago
|
||
The text is moving, just the left and right div borders are never visible.
![]() |
Assignee | |
Comment 21•21 years ago
|
||
Right. So it scrolls the text, but it's not clear what it's doing with the div.
I don't think we care, really.
You need to log in
before you can comment on or make changes to this bug.
Description
•