Closed
Bug 35646
Opened 25 years ago
Closed 25 years ago
Editor needs a way to identify "unknown" ("userdefined") tags (not in HTML DTD)
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: cmanske, Assigned: cmanske)
References
Details
(Whiteboard: [nsbeta2+ until 5/16])
Attachments
(1 file)
|
276 bytes,
text/html
|
Details |
In Composer, I am implementing an "All Tags" editing mode that displays
an image for all the known HTML tags starting with <body> and it's
children using CSS-generated content. But what happens when we encounter
a tagname that the parser doesn't understand (e.g., very old tags or
maybe some Microsoft proprietary tags)? I assume the display type is set
to "none" and we just ignore them in the frame tree. But the editor
needs to display a generic icon, like the "yellow tags" we have in 4.x
Composer.
This is how we display an icon for tags that are known:
body {
margin-left: 2px;
padding-left: 13px;
background: url(chrome://editor/skin/images/tag-body.gif) no-repeat;
background-position: top left;
}
So it's hard to make a rule if we don't know the tagname.
A suggestion:
During parsing, can we append an attribute node
named "_moz-unknown" to any tag not in the HTML DTD? Then I could make a rule
like this:
*[_moz-unknown] {
display: inline;
margin-left: 2px;
padding-left: 13px;
background: url(chrome://editor/skin/images/tag-unknown.gif) no-repeat;
background-position: top left;
}
|
Assignee | |
Comment 1•25 years ago
|
||
Some good comments from Matthew Thomas (mpt26@student.canterbury.ac.nz):
Such an idea could work, provided that:
(a) the attribute has a name such as "moz-unknown", which is much less
likely to clash with a real attribute in a future DTD than a single
English word like "unknown" is;
(b) the "moz-unknown" attributes are *not* saved with the document, but
are regenerated each time the document is opened. (You'd probably
want to hide them when showing the source of the document while
editing it, too.)
These two things would help make sure that bad stuff doesn't happen if I
happen to use an old copy of Moz Composer to edit a W3C HTML 6.1
document, in a few years time. :-)
Harish has been working on a method GetDTDForDoctype() that will solve this
problem.
Assignee: rickg → harishd
Status: ASSIGNED → NEW
|
|
Assignee | |
Comment 4•25 years ago
|
||
I don't see how GetDTDForDoctype solves this problem. Harish?
|
|
Assignee | |
Comment 5•25 years ago
|
||
Beth: Is this a "feature"? If yes, then we better get it on the beta2 bandwagon
ASAP.
An outside developer made a suggestion that is worth exploring:
Use this style to cover all tags:
* {
display: inline;
margin-left: 2px; margin-top: 2px;
padding-left: 13px;
background: url(chrome://editor/skin/images/unknown.gif) no-repeat;
background-position: top left;
}
I tried using this in an editor override stylesheet, but that doesn't work.
Do override sheets have their own cascading? Would loading this in an override
sheet before ua.css work? Possible problem is performance.
Does that sound like a viable strategy?
Keywords: nsbeta2
I'm not sure either how the DOCTYPE would address this problem. I'll consult
with Rickg about this. Setting M16
Status: NEW → ASSIGNED
Target Milestone: --- → M16
|
|
Assignee | |
Comment 7•25 years ago
|
||
As an experiment, I added the general rule described above to ua.css, before
the 2 @import lines for html.css and xul.css and it definitely does not work!
The rules in html and xul css don't seem to override the general rule.
Charles: I understood from talking to beth that you were iterating the content
model yourself to determine the elements. It looks from you example that you're
using CSS instead (and mapping an image via a property). In this case, using the
DTD is insufficient. We'll add the _moz-unknown property for you shortly.
Taking this back to implement for charles.
Assignee: harishd → rickg
Status: ASSIGNED → NEW
|
||
Comment 10•25 years ago
|
||
I added support for this attribute. The special attribute is called, drumroll
please, -moz-userdefined. It works fine in my tests, but I didn't check in any
support in the html.css file (I'll leave that to charlie).
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 11•25 years ago
|
||
I need this open until I do the required CSS part for Composer. Also:
Akkana: Do you need to detect this when we output HTML so the attribute is
stripped?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
Assignee | |
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
|
|
Assignee | |
Comment 12•25 years ago
|
||
I'm going to show the "unknown" tag icon only in "Show All Tags" mode.
Does that sound ok? I don't see any point in cluttering the normal editor
mode -- that will make Mail Composer much cleaner, especially with input
from Microsoft mail programs.
|
||
Comment 13•25 years ago
|
||
The output methods automatically strip any attribute which starts with the
string "_moz", since that's what the editor has been using. I'd appreciate it
if we could change the attribute name to start with _moz instead of -moz.
|
|
||
Comment 14•25 years ago
|
||
Do me a favor, please: let's refer to this as the user-defined tag, no the
unknown tag. UnknownTag has different semantics altogether in layout.
|
|
Assignee | |
Comment 15•25 years ago
|
||
Just occured to me: Is "-moz-userdefined" the best term? It is really "we don't
know about it in our DTD" which covers deprecated tags and Microsoft and old
Netscape proprietary tags. I'm using "tag-unknown.gif" for the icon;
anything wrong with "-moz-unknown"?
Assignee: rickg → cmanske
Status: ASSIGNED → NEW
|
|
Assignee | |
Comment 16•25 years ago
|
||
Rick: Didn't see your comment -- what is UnknownTag in layout?
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 17•25 years ago
|
||
I can make that change - I don't think Rick will mind, correct?
Summary: Editor needs a way to identify "unknown" tags (not in HTML DTD) → Editor needs a way to identify ?unknown? tags (not in HTML DTD)
|
|
Assignee | |
Comment 19•25 years ago
|
||
The attribute is now set, but the CSS rule is not responding to show the
icon.
|
|
Assignee | |
Comment 20•25 years ago
|
||
|
|
Assignee | |
Comment 21•25 years ago
|
||
I can't get the "_moz-userdefined" to trigger a CSS change.
I want to use this:
*[_moz-userdefined] {
display: inline:
min-height: 35px; margin-left: 2px; margin-top: 2px;
padding-left: 16px;
background: url(chrome://editor/skin/images/tag-unknown.gif) no-repeat;
background-position: top left;
}
in an editor override CSS file, but it didn't work.
I added the sample Rickg sent me directly to ua.css:
@import url(resource:/res/html.css);
@import url(resource:/chrome/xul.css);
*[_moz-userdefined] {
display: inline;
margin-left: 2px;
padding-left: 13px;
background-color: yellow;
}
and it doesn't show the yellow background in mozilla browser or viewer.
|
||
Comment 22•25 years ago
|
||
Try
*[-moz-userdefined] { ... }
Or, if you have changed the code to use underscores,
*[\_moz-userdefined] { ... }
Underscores are not valid in CSS and must be escaped.
|
|
Assignee | |
Comment 23•25 years ago
|
||
Thanks for the escaping tip. This finally works!
Will checkin soon.
Summary: Editor needs a way to identify ?unknown? tags (not in HTML DTD) → Editor needs a way to identify "unknown" ("userdefined") tags (not in HTML DTD)
|
|
Assignee | |
Comment 24•25 years ago
|
||
*** Bug 22262 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Comment 25•25 years ago
|
||
CSS now checked in. Thanks Rick and Ian!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
|
||
Comment 27•25 years ago
|
||
this is not my area....Gerardo please assign this to someone on your team...
I only verify Editor component bugs...
QA Contact: sujay → gerardok
|
|
Assignee | |
Comment 28•25 years ago
|
||
This is a Composer issue! Simply load the attached test page, view it in the
"Show All Tags" mode (tab near window bottom), and you should see an icon with
"?" to represent the <foo> tag.
You need to log in
before you can comment on or make changes to this bug.
Description
•