> > Things like proper MIME content negotiation are being totally ignored
> > simply because people are using MIME types that simply don't exist, and
> > not paying attention to the parameters for MIME types (like "version="
> > for "text/html").
>
> I would like to make a point at my own expense. I teach HTML, and I
> don't know anything about MIME types. What I do teach, as best as I can, is
Perhaps my comment above was somewhat unrelated to "direct HTML"
discussion, that's why it may seem out of place. Allow me to explain
what I meant:
When a Web client requests a URL from a server, the server tries to
determine the "type of content" in the URL, and report this accordingly
to the client. If this cannot be determined, the server will either use
a default or will leave the issue to the client to handle.
The client will generally try to guess content type based upon "file
extension" (loose use of term) - for example, when using Netscape
have a look in the "Helper Applications" section of the preferences
setup and you'll see all the MIME types (like "video/quicktime").
Here's the not-so-HTML-related bit (of which I was primarily
complaining about, above): when people have a file type (eg., Excel)
which they wish clients to detect and automatically start some
application, they'll create their own MIME types instead of following
either the IANA standard types, or the standard of prepending "x-" to
the subtype.
Here's the HTML-related bit - MIME type "text/html" specifies a
particular language; there are variants thereof, and that's why
parameters like "version=" exist (so that clients can use content
negotiation to get the variant that they want/understand).
If this feature was being used more extensively, then vendor-specific
HTML may not be causing so many complaints and/or problems because
the browsers would request some other variant (and the vendor's
browsers would quite happily accept the vendor-specific stuff).
> the expertise to pay attention to the parameters for MIME types is a
> stretch -- considering that most users of HTML have probably never heard
> of MIME, and many have probably never heard of "parameters."
"text/html" refers to a specific language - if the users are being taught
(and are using) that language, then there's no problem, "text/html"
remains quite explicit.
What irks me is when people write textual resources that are served up as
"text/html" (without any further qualification) when they're *not*
(strictly speaking) HTML.
To me, "HTML" refers to the *standard* language, whereas anything else is
a variant and requires some qualification (that's why "2.0" and "3.0" are
appended to differentiate between the two major variants of HTML being
standardised by the IETF).
It's when "HTML" (no qualification) is being used to refer to some
vendor-specific variant that I get rather annoyed.
> > To ensure that browsers who claim to support this language are in fact
> > not butchering it themselves, can/should W3C trademark the name of the
> > language and only permit those browsers who pass a validation test to
> > claim support for the language? If BigBusiness wants to play dirty and
> > screw-up the Web (as it has done), then it should be aware that two can
> > play that game.
>
> Oh, but BigBusiness can play it SO WELL. It sounds like you are
Basically, what I *want* is for "HTML" to refer to some standard language
so that there is no ambiguity when that term is used; what I *want*, is
for HTML as standardised by IETF to be that language (and variants
thereof). What I *want* is for vendor-specific variants to be designated
as such, and to either pick a different MIME type, or to add some
qualification to "text/html" (rather than using it verbatim).
Will that ever happen? Not bloody likely. Vendors are creating terrible
ambiguity when referring to "HTML", because people not aware of the
different variations are using tags thinking they are using "HTML" and
that everyone will be able to view the information as the author
intended, which is just not true.
I would *like* to see HTML remain the lingua franca of the Web, but as a
standard language it must be just that - *standard*. That's not to say
that innovation shouldn't continue, just that differences shouldn't claim
to be the same as the original.
Since I don't see BigBusiness bending to what is logical and fair, then
the only other alternative is to, as has already been suggested, get the
hell out of the way - take "standard HTML" elsewhere and rename it (so
that no ambiguity may result).
> considering inventing a new language (when there are hundreds of
> thousands of users of an existing language), inventing a new name for
No, I'm not thinking of an entirely *new* language - but a *standardised*
language whose title instantly indicates who/what it is; "HTML" is no
longer enough to explicitly indicate what tags are in use.
> that language (when there are even more people who know the name "HTML"),
> and then engaging in trademark and legal battles (which cost a lot of
That was a second suggestion to ensure that should a "new language"
(mainly in terms of name) emerge, then the same thing that has happened
to HTML will not happen to it, also.
I don't know if such a thing is viable, or even possible (or even
desirable), which is why it's open for discussion.
> Is it conceivable that there is something better to do with one's time?
If the vendors would stop overloading "HTML", then there would be no
need. Do *you* think there is any chance of this happening? Sadly, I do
not.
Cheers..
dave