This is a meta bug for tracking purposes only. It "depends" on individual outstanding bugs with HTML 4.0 compliance and is a way to track them and to speed the documenting of any deviations, exceptions, or known bugs which remain at release. NOTE: This meta bug depends on individual HTML 4.0 compliance bugs, not the other way around! If you wish use this meta bug to track an individual HTML 4.0 bug, either make this bug depend on the individual bug, or in the individual bug, use this bug # in the "bugs which depend on this bug" field.
Setting to M15 as this is a [META] bug for tracking only.
Setting to M20 as this is a [META] bug for tracking only.
Marking helpwanted and (since this is just a META tracking bug) reassigning to email@example.com so I don't get cc:d on every dependency change on every bug.
Changing QA contact to firstname.lastname@example.org so I stop getting spammed.
I'm the reporter for this bug, so I get email for every change on a dependent bug. I'd like to stop getting this significant volume of email. Is there any way a bug reporter can arrange to stop getting updates for a particular bug? If not, would it be possible for someone who actually wants to get these updates to create a replacement bug for this one with them as the reporter? Very sorry for the trouble. I'm simply reporting and cc:d on so many reports that I have to be careful to control flow in every way I can. Thanks for any assistance!
No there's no way to stop this, the RFE is at bug #17464.
*** Bug 53899 has been marked as a duplicate of this bug. ***
Taking responsability for tracking this...
Why is bug 2212 listed here? According to http://www.w3.org/TR/html401/struct/tables.html, user argents are not required to support the char= or charoff= attributes. Not to say that bug 2212 shouldn't be fixed, but it's not required for HTML 4.01 compliance.
This bug already contains many bugs that aren't required for HTML compliance. That's why it's called "full HTML compliance".
> This bug already contains many bugs that aren't required > for HTML compliance. > That's why it's called "full HTML compliance". Should this bug depend on bug #74073? I think so, email@example.com disagrees.
16 years ago
16 years ago
Added mozilla1.0 keyword since HTML 4.01 compliance is a design goal of mozilla.
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Should bug 10512 be added? Then again the comments in 10512 indicate the mozilla team isn't intersted in full HTML 4.01 support.
Same story with the WONTFIXed basefont bug 3875.
Based on reading the bugs referenced by Comment #17 and Comment #18, where it is stated by Mozilla/Netscape that 100% HTML 4.01 support is not going to happen, I really don't see the purpose of this META tracking bug. It seems obsolete, or end-of-lined, and thus should be marked WONTFIX.
just because it's not going to be 100%, doesn't mean it isn't worth tracking exactly which bits aren't compliant and whether they are going to be fixed or not.
It seems that Mozilla isn't interested in HTML 4.01 support According to comments in bug #692032 Mozilla isn't an XHTML user agent either. In particular ``XHTML isn't part of the current, official Mozilla agenda''. So I'm curious to know what goals are Mozilla pursuing? ISO/IEC 15445 perhaps? Maybe Mozilla isn't actually an HTML user agent? I suppose this isn't the correct forum to be rasing these concerns.
Russel: We don't have #692032 bug, yet. Luckily. Which bug do you refer to?
Sorry, It's bug #69032. Apperently Mozilla isn't an HTML UA, it isn't an XHTML UA, it is supposed to be an XML (+DOM +CSS) UA. Well, the goals of Mozilla seems to vary from place to place, and from person to person.
Removing [META]. We have keywords for that.
Should bug 3655 be on here?
Five and a half years later an update. Shouldn't this bug be closed now that we have HTML5?
(In reply to comment #27) > Five and a half years later an update. Shouldn't this bug be closed now that we > have HTML5? No, HTML5 is just a superstructure over HTML4, so without that being properly implemented, we are missing in HTML5 arena as well.
That's incorrect. HTML5 did not take HTML4 into account and is not a superset.
Regardless, Firefox needs to support HTML 4 for quite some time if it wants to remain a browser to be taken seriously.
There are 70+ users following this bug who do not want to lsiten in on a debate about the true nature of HTML5 and HTML 4. The question was, do Mozilla need to have this bug open? I was trying to help closing no longer needed bugs. HTML 4 is supported BY supporting HTML 5. There is only one HTML parser in Firefox and there is only one DOM tree. Firefox has switched to an HTML5 compliant parser. So is this bug helpful to keep track of stuff to implement, or are there better ways?
This is a tracking bug and 22 bugs it tracks are still open. This more or less should end this unnecessary discussion.
This bug is no longer being used to track/prioritize engineering work, so I'm going to close it out.