Closed
Bug 163505
Opened 24 years ago
Closed 21 years ago
marquee stylistic attributes should be handled through attribute mapping
Categories
(Core :: Layout, defect, P4)
Core
Layout
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: dbaron, Assigned: martijn.martijn)
References
Details
(Keywords: testcase)
Attachments
(3 files, 4 obsolete files)
|
350 bytes,
text/html
|
Details | |
|
548 bytes,
text/html
|
Details | |
|
3.97 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
marquee's stylistic attributes should be handled through the attribute mapping
code (nsIStyledContent::GetAttributeMappingFunction, etc.) rather than through
the current JS hacks. This would fix things such as the second half of bug
163031, which is that the 'width' property on the marquee element doesn't work
right, but instead is overridden (or partly so) by the width attribute. It
would also make things a lot cleaner and fix a bunch of bugs related to
attribute handling.
Having said that, I still think it's pretty low priority.
| Reporter | ||
Updated•24 years ago
|
Priority: -- → P4
Updated•24 years ago
|
QA Contact: petersen → amar
Updated•24 years ago
|
Target Milestone: --- → Future
Comment 1•24 years ago
|
||
Testcase showing that width does not work when set with css.
Comment 2•24 years ago
|
||
This testcase has width set as an html attribute. Note that the scroll area of
the Marquee is 400 px, but that the marquees width seems to be 100%.
Updated•24 years ago
|
Keywords: mozilla1.2
Comment 3•23 years ago
|
||
this shows the behaviour of marquee when the width is assigned as an HTML
attribute vs. a CSS property
Attachment #96149 -
Attachment is obsolete: true
Attachment #96150 -
Attachment is obsolete: true
Updated•23 years ago
|
Keywords: mozilla1.2
Comment 4•23 years ago
|
||
To doron. Perhaps the XBL should implement nsIStyledContent? Can XBL implement
non-IDLified interfaces?
Assignee: attinasi → doron
| Assignee | ||
Comment 5•21 years ago
|
||
| Assignee | ||
Comment 6•21 years ago
|
||
| Assignee | ||
Comment 7•21 years ago
|
||
Boris had a quick look at the previous patch, he had this to say:
bz {#developers} mw22: so you want IsAttributeMapped to match
GetAttributeMappingFunction
bz {#developers} mw22: that is, use a different map there for the
different nodeinfos
bz {#developers} mw22: other than that, looks fine to me..
He also said to remove gutter and cols stuff.
Attachment #200203 -
Attachment is obsolete: true
Attachment #200297 -
Flags: superreview?(dbaron)
Attachment #200297 -
Flags: review?(doronr)
Comment 8•21 years ago
|
||
Comment on attachment 200297 [details] [diff] [review]
patch2
I really don't feel comfortable reviewing content code. bz might be a better
person.
Attachment #200297 -
Flags: review?(doronr)
| Assignee | ||
Comment 9•21 years ago
|
||
Comment on attachment 200297 [details] [diff] [review]
patch2
Ok, thanks. Asking Boris for review, then.
Attachment #200297 -
Flags: review?(bzbarsky)
Comment 10•21 years ago
|
||
Comment on attachment 200297 [details] [diff] [review]
patch2
>Index: content/html/content/src/nsHTMLDivElement.cpp
> nsHTMLDivElement::IsAttributeMapped(const nsIAtom* aAttribute) const
> static const MappedAttributeEntry* const map[] = {
>- sDivAlignAttributeMap,
> sCommonAttributeMap
> };
>-
> return FindAttributeDependence(aAttribute, map, NS_ARRAY_LENGTH(map));
replace all this with |return
nsGenericHTMLElement::IsAttributeMapped(aAttribute)|, please. That will ensure
that this is consistent with GetAttributeMappingFunction even if the generic
changes.
Apart from that, looks great.
Attachment #200297 -
Flags: superreview?(dbaron)
Attachment #200297 -
Flags: superreview-
Attachment #200297 -
Flags: review?(bzbarsky)
Attachment #200297 -
Flags: review-
| Assignee | ||
Comment 11•21 years ago
|
||
Ok, done that.
Attachment #200297 -
Attachment is obsolete: true
Attachment #200557 -
Flags: review?(bzbarsky)
Updated•21 years ago
|
Attachment #200557 -
Flags: superreview+
Attachment #200557 -
Flags: review?(bzbarsky)
Attachment #200557 -
Flags: review+
Updated•21 years ago
|
Assignee: doronr → martijn.martijn
Comment 12•21 years ago
|
||
Checked in on trunk. Is there a followup bug to remove the JS hacks?
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 13•21 years ago
|
||
I've filed bug 313642 for that.
You need to log in
before you can comment on or make changes to this bug.
Description
•