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
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
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.
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
Removing [META]. We have keywords for that.
Should bug 3655 be on here?
bug 189643 ? (see bug 1882 for discussion on standards compliancy)
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.
[Tracking Requested - why for this release]:
This bug is no longer being used to track/prioritize engineering work, so I'm going to close it out.