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)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: conradwt, Assigned: nisheeth_mozilla)

References

Details

(Keywords: relnote, xhtml, Whiteboard: [fixinhand] relnote-devel)

Attachments

(4 files)

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.
confirming, changed status to new.  This sounds like parser to me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Marking M20 for now...
Status: NEW → ASSIGNED
Target Milestone: --- → M20
M19 is a better place for this...
Target Milestone: M20 → M19
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
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
| 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 ...
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
| 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).
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
Marking nsbeta3-
Status: NEW → ASSIGNED
Whiteboard: [nsbeta3-]
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
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...
Removing future marker to bring this onto my radar.
Target Milestone: Future → ---
updated qa contact.
QA Contact: janc → bsharma
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.
Target Milestone: --- → mozilla0.9.1
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.
sr=jst
Whiteboard: [nsbeta3-] relnote-devel → [fixinhand] relnote-devel
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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. ***
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.
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.

Attachment

General

Created:
Updated:
Size: