RE: HTML Improvement/Suggestion

On Sun, 11 Dec 2005, Mark Birbeck wrote:

> People often say that you only need <div> and <span>

I always thought it was a parody of some HTML authoring habits.

> I always find that a little
> daft, because if you followed that logic right to its conclusion, then you
> actually only need <element> or even <node>, and you could just mirror the
> DOM in mark-up. (A *lot* of mark-up.)

I don't know what you mean by mirroring the DOM and a lot of mark-up,
but the element could be named <a> and we could call the resulting
markup language "A". Or maybe "AML". You could handle presentation
in CSS, and issues like embedding (or transclusion) would be handled
with general attributes like in the current draft. Of course, you would
need a lot of class attributes for the presentational part, using
<a class="foo" ...>, so the language might just as well use <foo ...>,
which most people would find more natural and convenient.

Isn't this what XML was about, letting everyone use the tags
he wants? :-)

"HTML" would then be just a matter of defining a set of general-purpose
_attributes_ like href and src. They would carry on the HTML tradition
of cryptic names.

> However, as with any programming language, you would shortly find that you
> often did the same things over and over again, and so would want another
> element, one that captures the semantics of an <element> plus attribute
> combination. The result might be more usable, easier to explain, more
> compact, or whatever.

In programming, we use subroutines or macros in such situations.
In modern programming language design, predefined subroutines are not
part of the language itself but available in standard libraries.

> So, the tricky task that the HTML WG faces is to try to capture enough of
> these 'patterns' to be useful, but not too many to be prescriptive and
> top-heavy.

That's a way to guarantee a complex and confusing result. People will 
always disagree on what is common enough, and working groups will then
make compromises that mean an eclectic mixture of approaches.

> Would it be the end of the world to lose the <img> tag? Of course not--and
> for me you could, since I'd rather see all external objects load the same
> way.

The idea of embedding an external object is a simple one and would best
be expressed with an element named <embed>. If, on the other hand, you
regard embedding just as a special case of transclusion, <object> is a 
logical choice, but then you might end up with using just src attributes
with any element. This would however mean excessive generalization that 
turns a simple markup language into an abstract model written in a clumsy
syntax.

> But you have to agree, it's a pretty common pattern, so using <img> as
> a shorthand for <object src="..." type="image/*"> (or whatever the right
> attribute is) seems a pretty reasonable addition to me.

And since images are mostly GIF or JPEG images in practice, we might just 
as well define <gif> and <jpeg>, right?

A general embedding element is fine, and the it's the best approach when
designing a "next generation" of HTML that is not meant to be compatible 
with any previous generation and need not work on current or near-future browsers.
But it should then be named <embed>, not <object>, which is far too 
abstract and associates with the tragicomic history of HTML 4.0 <object>
and its broken implementations.

The type attribute, if used to express the Internet media type (MIME 
type), reflects a wrong approach. The media type is to be known and 
announced by the server that delivers the object. The embedding document 
should just reserve space for the object (and contain fallback content to
be presented when the object is not available)

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

Received on Monday, 12 December 2005 04:47:50 UTC