Speaking for myself, I support the idea of SHORRTAG=YES because it
would help prevent nonstandard HTML extensions from conflicting
with SGML conventions. Developers would stick within SHORRTAG instead.
Also, it seems absolutely mandatory because HTML ignores unrecognized
tags - it can only do this for a SHORTTAG if the parser knows what one is!
Therefore it saves much work and avoids much confusion to support SHORTTAGS
from the beginning.
Regarding the issue of 'informing HTML developers of the implications',
I like the idea but as an addendum, NOT as part of the actual standard.
IMHO, it may not be doing anyone a favor to tell HTML authors/developers
that they can get away with all the SHORTTAG shortcuts... it probably
wont' be stable in the first HTML 2.0 revision of the browsers.
Also, putting such an addendum in the standard is only likely to open up a
controversy that will end up requiring a SHORRTAG=SOMETIMES extension to SGML...
ARGH! No, let's let it pass with SHORRTAG=YES and deal with the fallout later.
My reasons for supporting this:
- it makes things a little simpler for HTML authors, by supporting
their existing constructs and giving them some more brevity/flexibility.
- it might subvert less-SGML-compliant shortcuts that otherwise arise.
- it might demonstrate to doubters that the prior art of SGML is of great value
- HTML authors would get even lazier than they are... inconceivable! This
becomes a *pro* if you think laziness is inevitable, and that it is worthwhile
channeling it into a SHORTTAG-compliant shortcut.
- HTML extensions not respectful of the SHORTTAG conventions, which prior to
SHORTTAG=YES might have worked, might now *not* work as initially expected
(e.g. tag attributes defaulting to values other than SHORRTAG would specify)
... anyone checked this ? This becomes a *pro* if your mission in life is
to destroy all SGML-incompatible HTML extensions.
- HTML browser/editor developers from outside the SGML world might
balk at supporting this more complex parsing problem. This becomes
a *pro* if you are already vending an SGML-compliant parser... as it
raises the bar to a level you've already passed.
Is there no facility in SGML to make legal certain SHORTTAG constructs
and disallow others... I can see the abuses being made of a null end
tag, for instance... but if you have to support it in an 'unrecognized'
tag then you have to support it, period.
Craig Hubley Business that runs on knowledge
Craig Hubley & Associates needs software that runs on the net
[log in to unmask] 416-778-6136 416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5