Re: HTML Improvement/Suggestion

On Tue, 13 Dec 2005, Laurens Holst wrote:

> Basically you would just be controlling (or rather: filtering) the Accept: 
> header I suppose thats an advantage of having <img> as a shorthand for 
> <object srctype="image/*">;

Why should it be controlled? What could possibly be achieved? If the URL 
points to a resource of wrong media type (say, text/plain instead of the 
expected image/...), the server would respond with an error message,
which is probably more obscure than the one the browser could show if it 
got wrong type of data. Besides, if authors used srctype attributes,
these attributes themselves would be wrong rather often. Experience shows
that people get HTTP things wrong quite easily.

The HTML 4.01 spec (and hence XHTML 1.0) says about the type attribute for 
<object>: "If the value of this attribute differs from the HTTP 
Content-Type returned by the server when the object is retrieved, the HTTP 
Content-Type takes precedence." This is sound by HTTP principles, but it 
more or less breaks the idea.

The description of srctype in the XHTML 2.0 draft is a big mess that 
simply makes the problem more explicit. But it creates new kinds of 
absurdity:

"A user agent must imitate similar behavior when using other methods than 
HTTP. For instance, when accessing files in a local filestore, <p 
src="logo" type="image/png, image/jpeg"> might cause the user agent first 
to look for a file logo.png, and then for logo.jpg."

That's a request for foolish trickery and gives a wrong impression of what 
HTTP is. An HTTP server may perform content negotiation by media type, but 
that's by no means an obligatory part of HTTP.

> Anyways, the definition is fine by me. If you specify a type, obviously you 
> dont want anything else (object type="image/svg+xml" clearly doesnt mean you 
> would like to receive a PNG ^_^).

Authors will create unnecessary media type restrictions by hard-wiring
specific types into their documents. It's similar to hard-wiring the pixel 
dimensions of an image in markup or CSS, except that hard-wiring the 
dimensions may be of some use in improving efficiency. But it's awkward to 
have to edit HTML or CSS pages just because you reduced the dimensions of 
some images, and it would be even more awkward to have a huge number of 
HTML files with srctype="image/gif" references after you have realized 
that many of the images would work better as vector images. Changing the 
images themselves should be enough. (There might be problems with 
misbehaving user agents that honor URL extensions like .gif more than
they honor the HTTP protocol, but that's a different problem, with 
different cure.)

> But yeah, why change the name

If you look at the attributes named 'type' at
http://www.w3.org/TR/REC-html40/index/attributes.html
you'll realize how the name is horrendously overloaded semantically.
On the other hand, 'srctype' follows the bad tradition of cryptic or
brutally truncated names ('src', 'img', 'a', 'ul', etc.), and
'mediatype' would be reasonable _if_ you think such an attribute is 
needed.

> Anyways, I would appreciate it if for once the HTML WG would either commit to 
> using the XHTML 1.0 namespace (oh, yes please), or just break totally free 
> from it. Then at least Id know what were heading for with this, and form an 
> opinion based on that. Because obviously if you want to stay semi-compatible 
> with XHTML 1.0, there are other considerations than if you dont.

It would be harmful to use the XHTML 1.0 namespace without compatibility 
with XHTML 1.0. Either you should design an extension of existing HTML,
or you should design something completely new, so that old names are
a reason _not_ to use the same name, though some names might be so natural 
that there is no good alternative.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Tuesday, 13 December 2005 08:33:03 UTC