Closed
Bug 29171
Opened 24 years ago
Closed 23 years ago
upper case HTML Elements within a XHTML document should be ignored
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: conradwt, Assigned: nisheeth_mozilla)
References
Details
(Keywords: relnote, xhtml, Whiteboard: [fixinhand] relnote-devel)
Attachments
(4 files)
300 bytes,
text/xml
|
Details | |
3.94 KB,
patch
|
Details | Diff | Splinter Review | |
3.53 KB,
patch
|
Details | Diff | Splinter Review | |
2.79 KB,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 [en-US] (Windows_NT; I) BuildID: 200001 2520 How are you doing? It seems that I was able to violate the XHTML authoring rules. For example, in section 4.2 of the "XHTML 1.0: The Extensible HyperText Markup Language", it says that XHTML documents must use lower case for all HTML element and attribute names. However, I was able to load the following document without error: hello.xhtml: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <H1> Hello XHTML! </H1> </html> It should have displayed these as regular text instead of performing the HTML H1 tag rendering. -Conrad Reproducible: Always Steps to Reproduce: 1. simply load hello.xhtml file 2. 3. Actual Results: The HTML H1 tag was rendered as if it was HTML h1 tag. Expected Results: It should have displayed the HTML H1 tag as regular text if there doesn't exist an XSL stylesheet which can process the H1 element. No addional information can be provided.
Comment 1•24 years ago
|
||
confirming, changed status to new. This sounds like parser to me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•24 years ago
|
||
changing component to Parser. this is a validation issue and I think that is in the world of Parser.
Assignee: cbegle → rickg
Component: Browser-General → Parser
QA Contact: asadotzler → janc
Our XHTML support is minimal at this time, and it basically uses mechanisms that were in place to support HTML and XML. I'll give this to our nisheeth (Mr XML) to deal with post beta.
Assignee: rickg → nisheeth
Assignee | ||
Comment 4•24 years ago
|
||
Marking M20 for now...
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Assignee | ||
Comment 7•24 years ago
|
||
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M19 → Future
Nominating for nsbeta3. This is perhaps the biggest bug in our XHTML support.
Keywords: nsbeta3
Comment 9•24 years ago
|
||
This is a serious bug!!! It DESTROYS our XHTML support! If people start thinking case insensitive is ok, then we'll have given ourselves a legacy that we will not be able to get out of!! cc'ing Eric Krock.
Keywords: correctness
Comment 10•24 years ago
|
||
| This is a serious bug!!! It DESTROYS our XHTML support! | If people start thinking | case insensitive is ok, then we'll have given ourselves | a legacy that we will not be able to get out of!! Exactly! Though Mozilla's XHTML support is already pretty much destroyed (and certainly much worse than Navigator 4.x's!). See bug #26026 ...
Comment 11•24 years ago
|
||
Hang on a second, folks. 1) Nav4 had *no* support for XHTML. 2) As discussed in bug 26026, there is no commitment to any support or any particular level of support for XHTML. See http://www.mozilla.org/newlayout/faq.html for info about the standards we have committed to support. If I understand the spec and this bug report correctly (and by all means please clue me in if I don't), there is a simple workaround for this bug: as the content developer, do the right thing and use lowercase instead of uppercase. If that's indeed the case, then: a) Does this bug prevent people from doing the right thing? No. b) Does this bug break the XHTML page if developers do the right thing? No. c) Does this bug "destroy" our XHTML support? No. d) Does this bug make it possible for people to do the wrong thing? Yes. Of course, that's unfortunate, as inevitably, some content developers may ignore the XHTML spec and do the wrong thing out of ignorance because it seems to work in the first release. Such folks will be forced to fix their content by a simple search-and-replace Perl script when we fix this bug for future releases. We *will* be able to get out of this "legacy" because we *will* fix this bug for a future release. Netscape does not commit to provide backward compatibility in future releases with bugs such as this that are known and documented at the first release and for which it is still possible to Do The Right Thing. (Real "legacy" problems occur when a bug *forced* you do do the Wrong Thing in a way incompatible with the Right Thing, but for this thing, the Right Thing works in both the first release with the bug and a subsequent release without it.) To minimize this as much as possible, we should document this in the release notes and aggressively educate and evangelize doing the right thing. David, this would be a good brief technical note for you to write and publish to mozilla.org in the second half of your internship; that would be another way to help developers support standards. Even the *WSP itself* has stated clearly that Mozilla and Netscape 6 must ship ASAP. The only way to achieve that is to aggressively triage our bugs and focus on work that we absolutely cannot do without for the first release. If you want our standards support in the first release to be as good as possible, the way to help the most at this point is by helping to distinguish those compliance bugs that *must* be fixed from those that we can document, educate, and live with. Marking relnote. Changing summary from "HTML Elements within a XHTML document must be lower case" to "upper case HTML Elements within a XHTML document should treated as text, not markup." If I understand this bug correctly, I recommend nsbeta3- and rtm-.
Keywords: relnote
Summary: HTML Elements within a XHTML document must be lower case → upper case HTML Elements within a XHTML document should treated as text, not markup
Changing title, since new title is wrong. Uppercase elements are markup, but they don't mean anything. I disagree with Eric's message in points (1)-(2). We haven't committed to support XHTML, but we've also said that we wouldn't put in buggy, partial support for things that would break them in the future.
Summary: upper case HTML Elements within a XHTML document should treated as text, not markup → upper case HTML Elements within a XHTML document should be ignored
Rather than arguing about it, I'll just fix it. It looks easy. I'll add an aCaseSensitive argument (with default value false) to NS_CreateHTMLElement (in nsHTMLContentSink), have nsXMLContentSink::OpenContainer call it differently. Then I'll just make NS_CreateHTMLElement do a string compare on the stuff returned from the parserService and bail out if the strings are different. It's easier than teaching the parserService to be case sensitive sometimes, and it shouldn't be a performance problem because it should never be called! I might have to do the same for attributes, I'll see.
Assignee: nisheeth → dbaron
Status: ASSIGNED → NEW
Priority: P3 → P2
Target Milestone: Future → M18
Comment 14•24 years ago
|
||
| 1) Nav4 had *no* support for XHTML. No support is better than partial/buggy support. | 2) As discussed in bug 26026, there is no commitment to | any support or any | particular level of support for XHTML. See | http://www.mozilla.org/newlayout/faq.html | for info about the standards we have | committed to support. | | If I understand the spec and this bug report correctly (and by all means please | clue me in if I don't), there is a simple workaround for this bug: as the | content developer, do the right thing and use lowercase instead of uppercase. Yes. | If that's indeed the case, then: | a) Does this bug prevent people from doing the right thing? No. No. | b) Does this bug break the XHTML page if developers do the right thing? No. No, but bug #26026 does! You can write a web page that'll work in NN 4.x, IE 4 or 5 or any other browser that supports HTML + CSS or XHTML + CSS, and that web page won't work in Mozilla (because of buggy XHTML support -- *NO* XHTML is much better). | c) Does this bug "destroy" our XHTML support? No. Well, yes. It means we don't support XHTML, i.e. destroy Mozilla's XHTML support. Yes, I there's no commitment to support XHTML. And no, I don't think this is the most serious XHTML bug. Bug #26026 *is*, though. If you send your document as 'text/html', you can't use XML features. If you send it as 'text/xml', you can't use inline stylesheets or the 'style' element. | d) Does this bug make it possible for people to do the wrong thing? | Yes. Of course, that's unfortunate, as inevitably, some content | developers may ignore the XHTML spec and do the wrong thing out of | ignorance because it seems to work in the first release. Such folks | will be forced to fix their content by a simple search-and-replace | Perl script when we fix this bug for future releases. What I'm afraid of is that *too* many people will write XHTML documents that aren't valid (or well-formed!), and Mozilla will be "forced" to support them. But now I see David Baron will fix this. great! | (Real | "legacy" problems occur when a bug *forced* you do do the Wrong Thing in a way | incompatible with the Right Thing, but for this thing, the Right Thing works | in both the first release with the bug and a subsequent release without it.) Well, bug #26026 *forces* you avoid using one of the most useful features of (X)HTML. This means that web site developers will *never* be able to use inline styles or the 'style' element (because there'll *always* be many people using Mozilla 5.0, just like some people are still using Navigator 3.x). This is the same thing's that happened to the 'q' element. People just *can't* use it, since the majority of browsers doesn't support it (even though the latest do (Lynx and Opera!)). | Even the *WSP itself* has stated clearly that Mozilla and Netscape 6 Just Netscape. | must ship | ASAP. The only way to achieve that is to aggressively triage our bugs and focus | on work that we absolutely cannot do without for the first release. Well, beta 2 will soon be ready. Perhaps it'll make the WSP a *little* happier? :/ One thing that really puzzles me on Mozilla's XHTML support (or lack of, really) is that XHTML documents sent as 'text/xml' are treated one way, while XHTML documents sent as 'text/html' are treated another way (though *not* as ordinary HTML documents). Much of this bug wouldn't exist if Mozilla treated all XHTML documents the same way (as XML), since not well-formed documents wouldn't be displayed at all, e.g.: <h1>Title</H1> wouldn't work. Of course: <H1>Title</H1> would still work, but in this case the tags should be ignored (or the document not displayed if Mozilla was a validating UA).
Comment 15•24 years ago
|
||
Karl: Please, lets keep this bug to the case sensitivity issue. If you want to discuss advocacy, please do it in the newsgroups. Thanks. Eric: I agree with all your points; and so long as we would *really* have not supported this in future releases, then I would happily have let this slide. David: Cool, you rock :-)
Giving this bug back to Nisheeth and resoring its state before I took it. I've stopped caring about Mozilla's XHTML support because the specs are too unclear to describe an implementation. They don't exen say what MIME types should be used for XHTML or how XHTML sent as text/html should be handled (whether by an XML parser or HTML parser, and if XML, how XHTML should be detected). I thought the whole point of XHTML was to improve interoperability. If people try to implement XHTML now in its underspecified state, they will all make different decisions and it will hurt interoperability, not help. I know that's not relevant to this bug, but I don't want to pour my time down a black hole.
Assignee: dbaron → nisheeth
Priority: P2 → P3
Target Milestone: M18 → Future
Keywords: xhtml
Updated•24 years ago
|
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
Comment 19•24 years ago
|
||
Nom. nsbeta1. We want to avoid permitting/encouraging the creation (in innocent ignorance) of bad XHTML by web developers.
Keywords: nsbeta1
Bug 64999 describes this same problem, but I believe there are actually two bugs (or three, depends on how you look at things): 1) XML content sink creates an (X)HTML element when it sees the XHTML namespace - it does not check if the element is correct case. 2) Style system applies (X)HTML style to the wrongly cased element. [3) HTML content sink does not check element case when the document is XHTML] We could say this bug is 3) and keep this still open, and fix 1) and 2) with 64999 or something...
Assignee | ||
Comment 21•24 years ago
|
||
Removing future marker to bring this onto my radar.
Target Milestone: Future → ---
This should be straight forward to fix on the XML side... it then probbaly hides the problem in the CSS code, but I think the XML side of things is more important. As Johnny pointed out when I tried a naive fix for this, we want the elements in wrong case to be in XHTML namespace, but they should be of type unknown. So a potential fix would be to add new function NS_CreateXHTMLElement() (notice the 'X'), which would check if the element is in wrong case, and if so it would create the element as unknown, otherwise call NS_CreateHTMLElement(). We would also need nsIXHTMLElementFactory etc. (again notice the 'X'). NS_Create* is used in content DLL, element factories elsewhere. Then just change all the callers so that they will call the correct HTML or XHTML element creator.
Keywords: mozilla0.9
I think the style system was working fine, but something in the element creation was normalizing the case of the element stored in the content model (which I think we do for performance) to lowercase, which was causing CSS selectors to match when they shouldn't have. So I think this would be fixed if we stop creating the inappropriate content object and stop normalizing case for XHTML.
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.1
Updated•23 years ago
|
Assignee | ||
Comment 25•23 years ago
|
||
Assignee | ||
Comment 26•23 years ago
|
||
I just attached a fix that uses most of David's patch. The one difference is that NS_CreateHTMLElement() creates an HTML content object of type "unknown" when it comes across XHTML namespaced elements that are non lowercased.
Assignee | ||
Comment 27•23 years ago
|
||
Comment 28•23 years ago
|
||
sr=jst
r=heikki
Updated•23 years ago
|
Whiteboard: [nsbeta3-] relnote-devel → [fixinhand] relnote-devel
Assignee | ||
Comment 30•23 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 31•23 years ago
|
||
Verified on build: 2001-05-29-20-Trunk platform: Win NT The result is as expected.
Status: RESOLVED → VERIFIED
*** Bug 64999 has been marked as a duplicate of this bug. ***
Comment 33•13 years ago
|
||
what does this imply "unknown"? does this imply that lower case elements in css will now no longer work? they do in other browsers as of 7/7/2011 (say, that rhymes). because that's what's happening with ff 5.0. just tested it. an xhtml document with either CSS comments like <style type="text/css"> <!-- blah --> </style> or uppercase css element names will not work. for example <style type="text/css"> DIV.zappy { background-color:#339; } </style> I see this kind of example in some jquery example code and people are coding it in XHTML and having no success with ff, and neither am I.
Comment 34•13 years ago
|
||
oops, sorry, wrong bug. I should make this a new bug - sorry guys.
You need to log in
before you can comment on or make changes to this bug.
Description
•