LISTSERV mailing list manager LISTSERV 16.0

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


HTML-WG@LISTSERV.HEANET.IE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

HTML-WG Home

HTML-WG Home

HTML-WG  April 1995

HTML-WG April 1995

Subject:

Re: SHORTTAG

From:

[log in to unmask] (Craig Hubley)

Reply-To:

[log in to unmask]

Date:

Mon, 17 Apr 95 13:25:55 EDT

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (53 lines)


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:

Pros:
- 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
Cons:
- 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


Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

August 1996
July 1996
June 1996
May 1996
April 1996
March 1996
February 1996
January 1996
December 1995
November 1995
October 1995
September 1995
August 1995
July 1995
June 1995
May 1995
April 1995
March 1995
February 1995
January 1995
December 1994
November 1994
October 1994
September 1994
August 1994
July 1994

ATOM RSS1 RSS2



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager