A constraint on markup for EMPTY elements

The idea of being able to start using <foo/> right now, finessing it past 8879 
with stupid NET tricks until WG8 applies the correct ETAGC machinery, is 
elegant and pleasing.

But perhaps it's really dumb.  Because to ignore the pervasive influence
of the Web, in Anno Domini MCMXCVI, is to risk shuffling down the silent road
to dusty death.  And HTML of course has <BR> and <HR> and <IMG> and
doubtless others as well that don't come instantly to mind.

One reason that this constraint is serious is the following, which I am
sure has drifted through more than one of the heads on this list: Microsoft
IE already processes stylesheets.  Netscape says that they will too in
the next release.  Suppose, just suppose, that either or both of them
started recognizing and putting into effect stylesheet directives on tags
that weren't part of that vendor's dialect of HTML?  Well then, aside from
the handy semantics of <IMG> and <A> and a couple of others, you could wrap
your high-value data in your own tags before shipping it downstream, and
still have it formatted nicely.  So, there is a real chance that XML could 
smoothly and uncontroversially and with no requirement for filtering or 
downstream software changes, displace a significant proportion of the world's 
HTML.  Which arguably would make the Web a more useful place.  But, maybe not 
if we insist on saying <IMG SRC="mypic.jpg"/>.  [Plan B: convince MS & NS to 
start recognizing our EMPTY syntax... not impossible, I guess]

Taken at another level, more crassly sociological, XML has a greater chance
of widespread adoption if it doesn't "look weird" to the world's several
million HTML hacks.

Someone, please, explain why this fear is unfounded.  Because I would
really like to have a syntactically-obvious EMPTY element in XML.  Or
(serious question) is invading HTML's turf a non-goal of XML?

Cheers, Tim Bray
tbray@textuality.com http://www.textuality.com/ +1-604-488-1167

Received on Sunday, 15 September 1996 02:37:47 UTC