Right now you only seem to support the URI http://www.w3.org/TR/REC-html40 for the html namespace. (It is now used in the above document.) However, I think you should support the ones in XHTML (and track it as it becomes a REC), since those are the only formally defined namespaces. When the namespace URI was: http://www.w3.org/TR/xhtml1 then the above document didn't work (which is also the link to the spec).

Whoops. Accidentally hit wrong module. One letter *does* make a difference.

Moving this to M9 when we will do a lot of the HTML/XML/XUL content sink code factoring. Support for XHTML might be an easy fallout of that effort.

CCing Vidur so that he is aware of this bug. He is going to do the content sink factoring.

The content sink cleanup work is probably going to happen in M10. Moving this bug accordingly.

Moving content sink code factoring related bugs to M12.

The content sink code factoring has been postponed to post beta. Moving related bugs out to M15.

What's the status of this bug? I think this should be relatively easy to do, right? XHTML became a recommendation today, and the official namespace URI is: http://www.w3.org/1999/xhtml Frankly, if you're going to claim that Mozilla's XML support is standards-based, you have to do this, since right now the only way to use the HTML vocabulary in XML documents in to use the non-standard http://www.w3.org/TR/REC-html40 URI. However, it does bring up a few tricky issues in the style system (supporting multiple namespaces for @namespace) and other places **UNLESS** you completely remove the support for the nonstandard http://www.w3.org/TR/REC-html40 (which I believe is a pure Mozilla-ism, except that it was used in a few made up examples in the xml-names REC which are probably non-normative). This would be an easy change - a global search-replace for the HTML namespace URI in: * the namespace code that recognizes it (html.css and some C++ code) * all the XUL files that use it * any sample code written using the nonstandard way. (?)

I'm going to bring in this bug to M14. It'll be nice to get this done by beta and I'll try hard to make it happen...

XBL is another case of re-entrant parsing. This seems to work fine on the tip before your changes. :) What's the assertion?

These XML bugs need to move to M15, unfortunately. These aren't beta 1 stoppers and I have to pull in other more critical bugs from Kipp's plate for beta 1.

I'd like to see this bug fixed soon, please. It affects mathml. In particular all latex to mathml convertors give a xhtml namespace not this html4.0 namespace. Of course this can be fixed by hand... But this is inelegant, and gives non-standard xml/mathml pages.

The minimal fix to support the XHTML namespace in the XML content sink is included below. I'd like to see if it's possible to include this for beta1. It would bolster our standards support (even thought it's not a complete implementation) and is a very low risk fix for a potentially high gain. I believe Eric Krock agrees. Index: nsNameSpaceManager.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/base/src/nsNameSpaceManager.cpp,v retrieving revision 3.9 diff -r3.9 nsNameSpaceManager.cpp 36a37 > static const char kXHTMLNameSpaceURI[] = "http://www.w3.org/1999/xhtml"; 111a113 > nsString* xhtml = new nsString(kXHTMLNameSpaceURI); 114a117 > gURIArray->AppendElement(xhtml); 117a121 > NameSpaceURIKey xhtmlKey(xhtml); 120a125 > gURIToIDTable->Put(&xhtmlKey, (void*)kNameSpaceID_HTML);

I agree that this is low risk and a valuable feature.

Putting on PDT- radar for beta1.

Oh, crap, I attached that testcase to the wrong bug! Sorry about the spam.

There's only one official HTML namespace -- the XHTML one. Using REC-html40 as a namespace URI should go away.

Updating summary...

Moving bugs out by one milestone...

We are not going to try and remove support for REC-html40 before beta2. Setting milestone to 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.

There is absolutely _no_way_ that we can let Netscape ship a browser which recognises http://www.w3.org/TR/REC-html40 as a namespace. That would make it completely impossible for people to author valid XHTML documents. It is absolutely *imperative* that by FCS we use the correct XHTML namespace: http://www.w3.org/1999/xhtml ...otherwise we will basically be killing the work of the XHTML WG in deciding what the namespace is. Removing Future milestone. This really should have been fixed yesterday (beta1) so that content developers do not get annoyed when we finally do change. Nominating for nsbeta2.

Mozilla has spent a lot of work adding XML support. XHTML is not only the current HTML standard but is essential for the current modularization effor for HTML. The VAST majority of XML applications will be mixing various XML document types (SVG, MathML, XHTML modules, etc) within XML/XHTML documents. It is arguable that without proper XHTML (and general) namespace support, any support Mozilla does have for XML/XHTML is basically nullified. What good is supporting XML/XHTML if you can't display any usefull/real documents? I don't consider Mozilla as even supporting XML until this bug is fixed.

Just to clarify, right now I think mozilla supports both namespaces via some strange mapping. However, I think most of the documents (e.g., XUL) use the wrong one (which sets a bad example), so the first step is to change all that stuff over to the right thing...

I should have tested again before I spoke, as I hadn't actually tested this bug in a while. David is right, unlike my previous attempt, both namespaces are now mapped to the same "value". The last time I tried it wouldn't even recognize the proper xhtml namespace, only the improper HTML one. The behavior as it stands is at least useable. That brings us to the core issue with this bug. I do not have a problem with recognizing (applying semantics to) the Rec-html40 namespace. I question the current behavior of merging the "attributes" of both the HTML and XHTML namespaces into one. I would think that the proper behavior, as the third attachment above demonstrates, would be for the semantics of both namespaces to be recognized, but "attributes" kept in the separate namespaces as they are declared, not merged into one "pseudo" space. As in the attachment, I think you should be able to style HTML:H1 and XHTML:H1 independently, being as they are declared to be in *different* namespaces, albeit those namespaces have the same semantics.

Putting on [NEED INFO] radar. nisheeth, please speak with rickg.

I think that supporting HTML semantics for elements declared in the REC-HTML40 namespace is only neeeded for supporting the internal XUL files that use this functionality currently. I don't think the web community is going to use that namespace, now that we have the XHTML namespace to do the same thing. So, the intent behind "futuring" this bug was the desire to avoid spending time on cleaning up the internal XUL files to use the new XHTML namespace. But, I see your point, Chris, that people might want to style REC-HTML40 namespaced elements/attributes. At the same time, I differ from your opinion in that I don't think that the REC-HTML40 namespace should have any HTML semantics associated with it. The XHTML namespace is now the standards based way of associating HTML semantics in an XML document. We should not confuse the web community by supporting REC-HTML40 also. In my opinion, the work to remove RECHTML40 support is not a beta 2 blocker. I think the earliest we should try to do this is for beta 3. Ian, if you agree with this stance, please remove the nsbeta2 keyword. I am adding the nsbeta3 keyword.

Actually, after considering it, I withdraw my statement about not having a problem with applying semantics to REC-html4. I had being playing with namespaces in Moz and IE5, and I guess what led me to stating I was not dead set againsed it was that it is the _only_ "html semantic" namespace recognized by IE5, and thus the only _current_ cross browser method of applying those semantics to an XML document. But you are right, supporting it will just lead to more confusion, and even worse (because of the cross browser thing), people may actually use it. I don't so much mind stuff like backward compatibility with the old HTML DOM, because the HTML document base is already a complete mess, but I would like to see XML/XHTML documents stay nice (style free), shiny (well-formed/valid), and very compliant with standards (no extraneous namespaces :-)

Chris, if REC-html4 is the _only_ "html semantic" namespace recognized by IE5, and thus the only _current_ cross browser method of applying those semantics to an XML document, and we drop support for it, how will web content & web app developers create cross-browser content? Please explain. Here's my take: 1) We apparently already make it possible for developers to Do The Right Thing (use the XHTML namespace) if they are so inclined, and it will work. That's the critical thing for FCS. We can educate developers to use the Right Way. 2) Making it impossible to do the wrong thing, while in theory desirable, is not necessarily a requirement for FCS. Caveat emptor. 3) If it's true that using the REC-html4 is the *only* way to use HTML elements in XML on IE, disabling REC-html4 may well be unwise and make life harder for content developers. As much as I would like to be able to dictate that all content developers Do The Right Thing and that all browser vendors Support The Right Thing, the fact is that I can't: IE5 has substantial market share and limited standards support, and the unfortunate reality is that it's not going to disappear when N6/Moz ships. Content developers will be trying to write for both. If we've given them the ability to do things Right when they want to and not work on IE (and it appears that we have), then we shouldn't necessarily take away the option of doing things Less Right and working on both IE5 and N6/Moz. That's a choice for the content developers to make. Chris, if you can explain a way that content developers can equally easily create working cross-browser XML with HTML elements for IE5 and N6/Moz if we disable REC-html40, then it makes sense to consider doing so, but if not, I think we'd better leave the option in. BTW, I'm the first to admit I don't fully understand all the issues here, so folks please educate me (perhaps including simple sample markup examples!) if you've got the time. Thanks!!!

As far as cross browser considerations, as a content developer, I am totally frustrated for a million reasons already - I want to stick my head in the sand, code to the specs, and let the browser manufacturers sort out the mess. You could let users Do The Wrong Thing if they must, be assured that it is this decision right here that very well could lead to a world full of REC-html4 namespaced documents, with nobody following the proper spec. I wish MS could have just played nice. Anyone know if IE 5.5 beta has come to it's senses? (You can easily test on the attachment to this bug) That brings us back to the issue I raised in my "2000-06-09 10:32" comment - Mozilla incorrectly merges attributes from both namespaces into one. The application of a particular semantic to a namespace (Rec-html4 in this case) should not effect how document fragments in a different namespace (XHTML in this case) are rendered. As my atachment demonstrates, you should be able to style HTML:H1 and XHTML:H1 independently, being as they are declared to be in *different* namespaces. So fine, support both namespaces, but if you do, I would ask to try and do it properly (this is a gray area). And I will be the second to admit that I am not an expert on this - I have read all I could find on the subject as of my first commenting on this bug, but at that time even XML-Dev seemed to be rather muddled WRT namespaces. I am beginning to wonder if _anyone_ has all the answers. I still don't really understand partitions, nor how semantics for unprefixed attribute name collisions between namespaces are resolved :-)

In response to the comments that IE5 recognizes only REC-html40: Do you have a test case to demonstrate this? My testing of IE5 just now shows (what was also my previous understanding) that IE5 doesn't actually care about the namespace. IE5 applies HTML semantics to any namespace *qualifier* that is "html". (Testing in IE 5.00.2919.6307 on Win98.) Was your test using "html" and "xhtml" as the qualifiers? Could you test that your version of IE is also doing this (i.e., using the qualifier rather than the namespace). If so, then this is a non-issue.

IE just uses the prefix? Ewwee! Why the hell would they do something like that? It is so blatantly againsed the standard. My only test is the attachment to this bug which I have been referring to: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=6705 It (coincidentally) uses html as the prefix to the Rec-html4 namespace, which would explain it working. Under IE 5.00.2920.0000 using Windows 2000, only the html namespaced/prefixed h1 appears as a heading (large). Neither styling for the html or xhtml is recognized and thus both are black. If I remember correctly, as far as styling is concerned, I think IE just has a problem with me using the (proper) '|' vertical bar rather than ':' in the style sheet. Under Mozilla 2000052508, both are rendered as headings (large). Both headings appear in the blue xhtml style (demonstrating the attributes being merged). So I guess that means REC-html4 might as well dissapear then.

Just to clarify (for the record), I think the cross-browser way of doing things is: * use the correct (XHTML) namespace * use "html" as the namespace qualifier and I don't think there are any X-browser design issues here.

Yes, now I remember, IE hardcodes recognition of html: as the HTML namespace prefix *regardless* of what you've declared, and yes, that's totally in violation of the point of the XML namespace spec. Here's the issue, then: 1) We support doing the right thing. 2) As long as you use the html: prefix, it will work cross-browser. 3) Therefore, we *could* remove REC-html40 support from the browser, and at some point we should as a cleanup step. 4) *However*, we have tons of XUL files in the product that use REC-html40, and it would be a poor use of developers' and QA staffers' and external testers' time at this late stage of development to start an effort to fix that all. Every cycle put into that effort would be a cycle taken away from fixing REAL html40, css1, and dom1 bugs, and that would reduce the degree of standards compliance in the final product. So here's what we're going to do: 1) leave the support for REC-html40 in for RTM solely so we needn't change all our XUL files, explicitly deprecating it 2) aggressively educate and evangelize developers to use the correct namespace identifier in the content and XUL they create; dbaron will create and post to mozill.org a TechNote explaining how and why to do this and warning that we intend to *drop* support for REC-html40 in a future release 3) post-RTM, clean up our own XUL files in the product to use the correct namespace (I'll open a separate FUTURE bug on this) 4) after doing (3), we *may* fix this bug and drop REC-html40 from a post-RTM release (I'll make this bug dependent on the bug for (3) Vidur confirms that dbaron and I understand the issues here correctly. He notes that there's one related issue which is that the reverse mapping of prefix (e.g. html:) to URL (e.g. http://www.w3.org/1999/xhtml) is currently returning the wrong one (REC-html40), and we *should* fix that. dbaron and I agree; vidur will open a separate bug report on that and we will nominate that nsbeta2. Removing [NEED INFO] and my own nsbeta3 nomination. Recommending nsbeta2-. Marking FUTURE.

Note related bug 42278, "REC-html40 incorrectly returned as a result of reverse mapping XHTML identifier."

Putting on [nsbeta2-] radar. Not critical to beta2. Putting on nsbeta3 keyword radar.

Eric/Nisheeth/Vidur, if the REC-html40 was removed, would you accept the fix? Is there some other technical reason preventing the removal of REC-html40 (other than the lack human resources)? The reason I am asking is because I could help by passing the tree under a query-n-replace Perl script that would replace all occurrences of REC-html40 with the right namespace, and automatically check-in the modified files. Fixing this now will save from the reverse-mapping problem that has just surfaced and the later headaches of explaining to people not to use REC-html40.

My $.02: I think REC-html40 should be removed. In the long run, this would really be the best thing to do. IMHO, running a global search and replace sounds like a good thing to do.

My $.02: I think REC-html40 should be removed. In the long run, this would really be the best thing to do. IMHO, running a global search and replace sounds like a good thing to do.

Nisheeth wrote: > Ian, if you agree with this stance, please remove the nsbeta2 keyword. I completely agree (I had not originally realised that we already supported the correct namespace). Seems like things moved on without me though. ;-) Note that if our XUL and CSS files use the incorrect namespace, this will IMHO have a much stronger impact than we might imagine. It is a fact of life that most web authors do not code by looking up the correct behaviour and writing-to- spec, they code by copy-and-paste. If Roger can do the mass search-and-replace safely, then I would very strongly recommend that we use his fix. Roger: If you do this, could you attach a diff so that we can double check that only files that _should_ be changed did in fact get changed? [BTW, does it make sense for an nsbeta2-,nsbeta3 bug to be marked Future? ;-) ]

Regarding the search & replace - I think it's a good idea. However, it's not quite as trivial as doing the search & replace and checking it in - you should coordinate with other people who work on XUL files, since they may have a lot of changes in their trees, and not want to deal with too many merge conflicts (although in theory a change like this shouldn't cause merge conflicts, so maybe it's not so bad). This means you should probably post to a newsgroup (mozilla-xpfe??) about it, and maybe email a few of the key XUL people (hyatt@netscape.com, ben@netscape.com, etc.).

Unfortunately, I am having difficulties attaching the Perl script and the list of all the files that will be changed. Bugzilla seems not to handle attachments very well (this is not first time that I experience such difficulties.) With the Perl script, someone with a fast machine could launch the mass search-and-replace, clobber-build, and tell us what is happening. I am currently doing a clobber-build on my non-luxurious system and it may take a while.

Finally, bugzilla accepted the attachments. Using the script is pretty straightforward and it is worth giving a go if you have a fast machine. To try *without effecting any replacement*, simply set $just_show_me = 1 and from the directory above mozilla (on one line): replace.pl 'http://www.w3.org/TR/REC-html40' 'http://www.w3.org/1999/xhtml' mozilla > output.txt This will give a listing similar to attachment 10081 [details]. Setting $just_show_me = 0 will *actually effect the changes in your tree*. (replace.pl -i will do the replacements in a case-insensitive manner if this is necessary?) I am currently rebuilding my tree on Win32, and for safety, someone should also try this on a different platform.

My clobber-build is finished and things seem to alright (viewer / profileWizard / mozilla / mailnews / composer). Mindful of the fact that it is a search-n-replace of REC-htlm40 with something else, is there somewhere specific in the product that I should look at?

To be safe, could you please propose this operation on netscape.public.mozilla.xpfe, cc:ing hyatt and ben to be sure they see it, before actually doing it on the tree? It would be great indeed if we can get this fixed, but I'm concerned about changing a lot of files in the tree during a time when folks are doing large #s of checkin's to meet the FC cutoff. Thanks for your interest in this!!!

Thanks for your openeness. Albeit simple, this change is massive and frankly, if it wasn't automated, it would be unlikely to do it at this crucial branching point. I have sent an email to a number of newsgroups including n.p.m.xpfe and CCed to hyatt and ben. After running the script, I have checked with the 'Find' function to see if there were files containing 'REC-html40'. One show up, layout.xml, because the case didn't match. Now that I have the tree built with the replacements (as listed in attachment 10084 [details]), is there something specific that I should particularly look at? Are there some files (perhaps .html) that should be left alone with their REC-html40 unchanged?

There was a catch... When the REC-html40 is part of the URI (as in the various DOCTYPE) In fact, this would have been detected long ago had I attached a diff as Ian suggested. I was delaying doing a diff because bugzilla scares me with the attachments :-) I have now corrected the Perl script to avoid the case where REC-html40 is part of a URI. I will attach a diff and a list of the REC-html40 left unchanged in the tree, if bugzilla permits... With both listings it would be easier to tell what is replaced and what is left in. After check-in I could then go and update http://www.mozilla.org/projects/mathml/authoring.html to let math people know that Mozilla is indeed fully XML/XHTML 1.0 compliant :-)

Another thing you may not want to change is the C++ code that recognizes REC-html40 as a namespace. (You can change the calls to CreateElementNS, etc., that use it.) That code should probably be changed by hand, only once we're sure that we don't need to support it for backwards compatibility with existing skins, etc. (It should certainly not be done immediately after checking in the XUL changes.) Changing it by hand will also involve removing whatever allows the 2 namespaces to be recognized as 1.

Attahing doesn't work reliably... Here are the occurences that will be unchanged (with line-wrapping due to the bugzilla form): mozilla/expat/expat.html =================================================================== "http://www.w3.org/TR/REC-html40/loose.dtd"> mozilla/expat/gplelect.html =================================================================== "http://www.w3.org/TR/REC-html40/loose.dtd"> mozilla/htmlparser/src/nsParser.cpp =================================================================== "http://www.w3.org/TR/REC-html40/strict.dtd"> "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">", "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">", "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 6.0//EN\" \"http://www.w3.org/TR/REC-html40/strict.dtd\">", mozilla/extensions/transformiix/source/examples/include.html =================================================================== "http://www.w3.org/TR/REC-html40/loose.dtd"> mozilla/extensions/transformiix/source/examples/sort.html =================================================================== "http://www.w3.org/TR/REC-html40/loose.dtd"> mozilla/extensions/transformiix/source/examples/test.html =================================================================== "http://www.w3.org/TR/REC-html40/loose.dtd"> mozilla/extensions/transformiix/source/examples/functions.html =================================================================== "http://www.w3.org/TR/REC-html40/loose.dtd"> mozilla/webshell/tests/viewer/samples/test_weight.html =================================================================== "http://www.w3.org/TR/REC-html40/loose.dtd"> mozilla/extensions/transformiix/source/xml/printer/HTMLPrinter.cpp =================================================================== out <<endl<< " \"http://www.w3.org/TR/REC-html40/loose.dtd\">" <<endl;

OK David, following your line of thoughts, I will temporarily change kXHTMLNameSpaceURI in nsNameSpaceManager.cpp to the old REC-html40 stuff. Therefore, as per Vidur's comments on 2000-02-29 11:15, this massive swap will basically mirror the old behavior in reverse... Because the remaining changes will be located in that single file (nsNameSpaceManager.cpp), a simpler clean-up could be done upon confirmation that all is fine.

It might be better to leave nsNameSpaceManager.cpp alone and let vidur deal with it (it's already covered by bug 42278, nsbeta2+). He already has a patch there. Or maybe it should all be checked in together...

With these replacements and the change that I mention for nsNameSpaceManager.cpp, the fix for bug 42278 is not necessary anymore.

Vidur, could you please clarify? Should I go ahead? The script is ready and it will be doing: cd relevant_dir cvs update [prompt] cvs add a_set_of_files [prompt] cvs commit a_set_of_files [prompt] Each prompt will give the opportunity to continue/skip/abort, and actions will be logged.

Checkins in progress. Let the clean up begins and let's see how it goes...

I just read the entire diff, and with the exception of the changes in code which have been mentioned above, I saw no change that seemed to me to be wrong. Thanks Roger!

Apparently all went well. Is the final namespace of XUL still the mouthful http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul ? BTW, I understand the idea behind the W3C's format of namespaces ([w3c][year][spec]) is to include the year when the spec became a recommendation. Mozilla may well do the same, taking the year of the invention of the feature for historical values. This way we could all remember that it was the year when we were hacking the lizard!

There are a bunch of changes that need to be made to the doc tree too. (REC-html40 shows up as a namespace in lots of documentation.)

Ah... The more light at the situation, the more it appears that it was really time to clean-up once for all. Thanks for letting the change happens. The danger of leaving these temporary names is that there could be so many legacy code and documents that the names would become a "standard" of their own. A case in point is the fact that correcting the typo in 'referer' became impossible due to a similar situation. So if XUL/XBL has to be cleaned-up as well, I can go through an iteration of the perl script once more.

When you do these kinds of changes to the tree, you will also need to check stuff that is NOT in cvs.mozilla.org but in gila.mozilla.org as well. For example, the viewer XML debug demos are there (they are also in the normal mozilla tree). I just checked in the fixes to gila for the debug demos (they are now identical to the files in the mozilla tree). Perhaps we should consider if these duplicates could be removed... Then there is also the documentation and samples to consider... Searching for "REC-html40" at www.mozilla.org just gave 82 hits.

Indeed, all these should be cleaned-up before things spread out of *.mozilla.org and get out of control.

I just cleaned-up the doc tree as well. At the next refresh of the mozilla.org website, the updates should show up. I think we can start talking about XUL/XBL also :-) Do you really want to be typing: http://www.mozilla.org/keymaster/gatekeeper/there.is.only.{xul,xbl} in each and every of your XUL/XBL files ?!? I understand these long-winded names were meant to be temporary. Unfortunately, they haven't been revisited and more and more documents are been produced with them. I am having that feeling that if we miss this opportunity, it is going to be very hard (impossible?) to change these names later. So what do you people think of the much simpler: http://www.mozilla.org/2000/xul http://www.mozilla.org/2000/xbl All I need is a `go ahead' and I will run and monitor the Perl script as I did with the previous batches of replacements.

Cc:ing some XUL people @netscape, hyatt and ben, and the mozilla.org's tree custodians, brendan and waterson, to see what they think.

IIRC, "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" was intentional, it was never intended to be a placeholder. I have no problem with the status quo. I admit even to being somewhat fond of the current NS. David could tell you more. (btw: the current XBL NS is actually http://www.mozilla.org/xbl)

I didn't know that it was intentional and definitive. There are things that outsiders like us don't know :-) Although the xmlns' "Notes" section at http://www.mozilla.org/xpfe/xulref/windowref.html seems to suggest otherwise.

ah, had not seen that doc. :-) Yes, David was the one who came up with the current NS as part of the whole Ghostbusters theme surrounding XUL. He will cry if anyone makes him change it ;-)

Wow, namespace discussions appear to be passionate in general (at W3C, here and elsewhere)! If that's the general feeling, then we can leave hyatt enjoy his fond name for a while -- before it gets called ECMAsomething!! Be prepared :-)

Setting milestone to M17... Doesnt make sense for a bug with so much activity to remain marked future, right? :-)

Seems the bug has served its original purpose and can be marked as FIXED? This will clear the way for some other bugs that depend on this. Now the ball has bounced back to Eric/Nisheeth/Vidur to decide whether to completely get rid of REC-html40 from nsNameSpaceManager.cpp ... Bug 42280 points out however that remnants of REC-html40 may still exist in demos and the commercial tree, see? I am now leaning toward getting rid of this REC-html40 while we can, so that we can be done with it, and have the peace of mind that it will not come back and haunt us again.

nsbeta3-/future. let's not change support for this suddenly before a release, but rather warn developers in advance when we know they are ready.

Marking rtm-.

I just learned that Opera also uses the incorrect HTML namespace, and ONLY the incorrect one (bug has been filed for the Opera folks). I don't think we should disable support for that anytime soon. Some kind of warning perhaps?

An example at http://www.opera.com/opera5/specs.html suggests that Opera 5 does support the right namespace URL. Supposing that Opera 5 indeed supports the right namespace, I don't think Opera is a reason enough for supporting the wrong namespace URL.

I just downloaded the free Opera 5.01 for Windows (NT) and it does not seem to understand the correct NS, at least not in the testcase 12/18/00 11:26.

XMLNS related. Changing QA contact to bsharma@netscape.com

What's the status of Opera 6.0 beta?

Opera 5.0 Carbon beta 2 supports the right namespace URL. Opera Software has used the right namespace URL in their own press release (http://www.opera.com/pressreleases/xhtml/20011026.xml), which suggests that they support the right namespace on other platforms, too.

reassigning qa contact

Marking FIXED since jst has now discontinued this REC-html40 in his checkin for bug 134278.