Closed
Bug 325405
Opened 18 years ago
Closed 18 years ago
Get rid of _moz-userdefined
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: sicking, Assigned: sicking)
Details
Attachments
(2 files)
2.01 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
1.72 KB,
patch
|
sicking
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
We don't need it, be gone!
Assignee | ||
Comment 1•18 years ago
|
||
Ok, I guess I should be a bit more verbose in my explanation. So we currently set a _moz-userdefined attribute on all elements that are unknown to us. However that is only needed by the EditorAllTags.css stylesheet. However, that stylesheet could just as well use cascading to accomplish the same thing. mrbkap has offered to do the parser bit, I'll do the css part.
Assignee | ||
Comment 2•18 years ago
|
||
This fixes the css end of this. It isn't the most pretty, but unfortunatly the CSS cascade doesn't cut it. The problem is that I'd have to define rule to exclude elements with the "_moz_anonclass" attribute set, this gives the selector higher specificity then the other rules making all elements get a '?' image. So instead I listed all the elements that are not currently marked with a _moz-userdefined attribute. It is ugly, but it's better then sprinkling the doc with extra DOM attributes.
Assignee: general → bugmail
Status: NEW → ASSIGNED
Attachment #210327 -
Flags: superreview?(bzbarsky)
Attachment #210327 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 3•18 years ago
|
||
I should add: It unfortunatly seems like the tag mode is fairly broken :( Images for block-level elements seem to render fine, but images on inline elements are not shown, although they take up space.
Comment 4•18 years ago
|
||
> The problem is that I'd have to define rule to > exclude elements with the "_moz_anonclass" attribute set, this gives the > selector higher specificity then the other rules making all elements get a '?' > image. I'm not sure I follow this.... What does _moz_anonclass have to do with this? > I should add: It unfortunatly seems like the tag mode is fairly broken :( > Images for block-level elements seem to render fine, but images on inline > elements are not shown, although they take up space. On trunk that would be a recent regression -- bug 324960.
Comment 5•18 years ago
|
||
This trivial patch makes the parser not output _moz-userdefined tags on userdefined tags.
Attachment #210415 -
Flags: superreview?(jst)
Attachment #210415 -
Flags: review?(bugmail)
Comment 6•18 years ago
|
||
Comment on attachment 210415 [details] [diff] [review] Parser patch sr=jst
Attachment #210415 -
Flags: superreview?(jst) → superreview+
Assignee | ||
Updated•18 years ago
|
Attachment #210415 -
Flags: superreview?(jst)
Attachment #210415 -
Flags: superreview+
Attachment #210415 -
Flags: review?(bugmail)
Attachment #210415 -
Flags: review+
Updated•18 years ago
|
Attachment #210415 -
Flags: superreview?(jst) → superreview+
Comment 7•18 years ago
|
||
Comment on attachment 210327 [details] [diff] [review] css part I can't think of an obvious better approach. The other way to do it, perhaps would be to just list :not() for those known tags that shouldn't get any tag label at all and make all the other rules !important.... I think that would also work.
Attachment #210327 -
Flags: superreview?(bzbarsky)
Attachment #210327 -
Flags: superreview+
Attachment #210327 -
Flags: review?(bzbarsky)
Attachment #210327 -
Flags: review+
Assignee | ||
Comment 8•18 years ago
|
||
That should almost work. I would need to remove the |display: inline;| though, which may or may not be ok. blame doesn't help much with why it was put in there. I think i'd prefer to go with this solution for now, it can always be changed in the future if it matters to anybody. For future readers of this bug, I couldn't just use a '*' rule for two reasons: 1. We want no picture for elements with an _moz_anonclass attribute 2. We want no picture for some elements, like <blink>, <bgsound> and <html> Once the rule is changed to exclude that the specificity goes up above the specificity of all other selectors giving all tags an '?' icon.
Comment 9•18 years ago
|
||
I checked the parser patch in.
Assignee | ||
Comment 10•18 years ago
|
||
The css part is also in. Bonsai is currently taking a nap, but things are hopefully fine.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•