Re: Recent ERB votes

Paul asked:
> What's wrong with, e.g.:
> 	<?XMLEmpty BR HR IMG>
> to list the empty elements?  The "new syntax" doesn't seem so difficult,
> and I see no more possible inconsistencies than are inherent in any
> markup scheme.  Whether you also allow the <e/> syntax is an orthogonal
> issue, but I personally would find the "new <e/> syntax" more of a bother
> than a simple PI with a list of empty elements, and would rather not have
> to worry about explaining or handling it.

If you come at it from an SGML viewpoint, I agree with you.

If you come at it from a quick-perl-hack or a short-C-program point
of view, having EMPTY elements marked is such a big win I can't
even begin to describe it.  It's the difference between being able to
write something useful in under ten minutes, and taking a day or two
or not doing it at all.

Frankly, this HTML compatibility thing is a total waste of time.
To be at all HTML comptibile, you have to cope with
    <li>first item
    <li>second item
    <b><li>bold item</b></li>
    <hr>did you know hr isn't allowd here?</hr>
    <li><img src=http://bet/you/need/quotes/in/sgml.gif>

Yes, this "works" in Netscape.  Say it isn't calid all you like.
shout until you're blue in the face.  But reading this is what
HTML compatibility is about today.

So don't bother about a list of EMPTY elements for HTML compatibility.
I don't believe for a moment that that was the real reason that anyone
wanted to be able to use <e> -- or if it was, they were having a bad day!

To use an XML application to parse HTML, you had better have a

Now, if you are generating the HTML yourself, and it is valid, and
you'd like to use the same document in XML programs, SGML programs,
RTF programs, a C compiler, five HTML browsers and a food mixer,
you can enter the Obfuscated PostScript contest... :-)
In the meantime, source-level HTML compatibility isn't one of the
goals I see in the charter for this list, nor in the draft spec.

Supporting an optional syntax for empty elements clearly violates goal
(5) (no optional features).
Having two syntaxes for the same thing because the ERB couldn't make
up their mind, apart from being silly, seems to me to compromise
goal (4) (easy to write programs).
It does so without advancing any other stated goal, so is presumably
purely political.

Let's try not to make too many political compromises, especially
where we don't need to...

Don't have multiple syntaxes for anything.

We've argued long and hard for empty elements to be marked as different,
so that they can be parsed easily, reliably, and without a DTD.

Don't throw that away now.