

RE: HTML Improvement/Suggestion

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Sun, 11 Dec 2005 23:33:42 -0000
Message-ID: <F9EB5216-7E37-4EDA-9C7E-1685F9ECAC2B@s15.mail.x-port.net>
Cc: <www-html@w3.org>


It's the same old ground again. One of the problems with the discussion that
keeps recurring, is that people are looking for a science, when the reality
is closer to art.

I'll explain what I mean. People often say that you only need <div> and
<span> (and perhaps now we're adding <object>). 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.)

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.

But if you then continued on that trajectory, and kept adding more and more
features to your language, you could end up with something top-heavy and

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. And preference would generally be given to methods of extending
the language in a fairly orderly and standard way, in any direction that the
author or a community wants.

I'm therefore saying that it is more art than science because there are no
simple formulae that can be applied to work out where to draw the dividing
line. <img> is used far more than an <object> that refers to a video, but
how much more does it need to be used before it gets its own tag? Who knows.
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. 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.



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from

> From: www-html-request@w3.org 
> [mailto:www-html-request@w3.org] On Behalf Of Anne van Kesteren
> Sent: 11 December 2005 20:55
> To: Mark Birbeck
> Cc: 'Spartanicus'; www-html@w3.org
> Subject: RE: HTML Improvement/Suggestion
> Quoting Mark Birbeck <mark.birbeck@x-port.net>:
> > <img> is a bit like <a> in that sometimes an author wants 
> to insert an 
> > image in a document, and it just *is* an image (or a link, 
> in the case 
> > of <a>). In other words, it's not a list item that is 
> represented by 
> > an image, or a heading that is represented by an image, 
> it's just an 
> > image. (If it was a heading, for example, then <h src="..." etc.> 
> > would be a better choice for the author.)
> Sometimes I want to insert a <video> in my document, or a 
> <audio> fragment, or some <radio>, or an <animation> or a 
> <three-dee-image> etc.
> Instead of inventing a lot of elements the HTML WG once 
> thought of <object>. The rationale was also that <object> was 
> eventually going to replace <img> from what I've heard. (That 
> was also the reason <img> was out of the draft and <object> 
> has been tested everywhere for interop.)
> Now you're arguing that sometimes specific elements are good?
> For linking, <a href=""> can just be <span href="">. After 
> all, an <a> element without "href" specified has similar 
> semantics to a <span>. Why wouldn't the opposite be true? And 
> I believe the opposite is true following the current wording...
> For embedding random objects, why can't <object 
> data="">/<object src=""> be replaced with <div src=""> or 
> <span src=""> (block level replaced element versus inline 
> level replaced element). Same thing, imho.
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
Received on Sunday, 11 December 2005 23:34:48 GMT
