210383 - Mozilla should render HTML 3.2 doctypes without supporting additions in later recommendations

Status: RESOLVED WONTFIX

(Core :: Layout, enhancement)

Description

[Brian 'netdragon' Bober]

People who wrote their pages for HTML 3.2 a long time ago should be able to
stick an HTML 3.2 doctype in their pages so that browsers such as Mozilla can
render them as 3.2

People will not write standards-compliant pages if they have to rewrite them
every time a new recommendation is released by w3c. There are a lot of legacy
pages out there written for older versions of HTML and its unrealistic to expect
them to update them.

Comment on bug 25537 from [e-mail]:

Brian 'NeTDeMoN' Bober writes:
> You can't run MS-DOS on a palm pilot. Unlike Linux, DOS isn't ported to many
> platforms. You are stuck using the integrated operating system on a palm top and
> browsers that basically do nothing but render pages. They won't be able to
> afford to put in backwards-compatibility measures for every permetuation of
> standards-breaking pages and browsers.

The great majority of handheld browsers (and TTY browsers too, for that matter)
support only HTML 3.2, because it's lightweight and easy to implement relative
to all of HTML 4 + CSS.  At the time I started authoring my site, browser
support for HTML 4 and CSS was so hit-and-miss that HTML 3.2 was the clear
choice for a consistent user experience.  Since that time, I haven't seen a
convincing reason to rewrite all my pages.  

Indeed I want my site to render properly on those handheld browsers.  The Palm
OS browser I use which supports tooltips, Xiino, supports them only for the ALT
attribute, not the TITLE attribute -- naturally; it's an HTML 3.2 browser.  My
pages all have a link in the footer to validator.w3.org which you can use to
verify that they are compliant HTML 3.2.  Therefore, I can't throw on additional
TITLE attributes just to support Mozilla and Netscape 6-7.  And no, I don't
think it's realistic to expect me to maintain two separate copies of each of my
pages so that image tooltips will work in Mozilla-based browsers.

Luckily it's not a huge issue for my site because for accessibility reasons I
have authored it to avoid purely graphical navigation when possible. 
Unfortunately there are plenty of sites out there where this isn't the case.  To
name just a single example, forums such as
http://www.creativecow.net/index.php?forumid=24 use multiple icons for
navigation / mode-switching whose purpose is probably unclear the first time you
see them.  Each has ALT text which the web authors expect to appear as a tooltip
so you can learn what the icons do.  That text is equally applicable in the case
that the graphic isn't shown at all and as a clarifier when the graphic is
shown.  The claim that ALT text and tooltip text should almost never be the same
thing is absurd, and ignores the ultra-common case of images used for navigation.

> I'd like to remind people that there has
> already been 3 years worth of browsers without ALT tooltips.

And yet the vast majority of sites still have only ALT attributes (if anything),
not TITLE attributes.  Perhaps this particular crusade isn't having enough of an
effect to justify losing more users over.

Added my vote for this bug.

Comment 1

[Hixie (not reading bugmail)]

We do support HTML 3.2 and 2.0. (We don't support HTML 3.0, but I've never seen
a document written in HTML 3.0, so I don't think that's a problem.)

Could you give an example of where we _don't_ support HTML 3.2 or HTML2?

Comment 2

[Dan Harkless]

As is discussed in bug 25537, from whence Brian pulled my text, you don't
display tooltips for ALT text as the major graphical browsers did during the
HTML 3.2 era.

Even if your mind is completely closed to ALT tooltips on HTML 4 pages, Mozilla
ought to support them on HTML 3.2 pages, where it's not possible to use the
TITLE attribute and remain compliant.

Comment 3

[Hixie (not reading bugmail)]

Where does it say in the HTML3.2 spec that <img alt="foo"> should result in a
tooltip? As far as I can tell, the HTML3.2 spec is pretty clear that it should
be a _replacement_, not a tooltip.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This bug seems to be rehashing already-WONTFIXed bugs with a summary designed to
confuse people who don't know that "support" in this context makes little or no
sense.

Comment 5

[Brian 'netdragon' Bober]

What I meant is that Mozilla should handle the HTML 3.2 doctype without 
supporting any of the additions made in later recommendations.

Comment 6

[Hixie (not reading bugmail)]

We already do.

If you have a valid HTML3.2 document, we render it according to the spec,
without supporting additions from later specs.

If you have an _in_valid HTML3.2 document, we can do what we like (the HTML spec
does not define error handling behaviour).

So I don't see what the problem is. WONTFIX is right.

Comment 7

[Robin Lionheart]

1> Could you give an example of where we _don't_ support HTML 3.2 or HTML2?

Now that URNs have a syntax, Mozilla may at last blaze the trail and be the
first browser to fully support HTML 2.0's long neglected <A URN="...">
attribute. :-)