Re: DIV/CLASS

Lee Daniel Crocker <lee@piclab.com> writes:
>> > If 3.2 were really just an encoding of current practice,
>> > then the DTD would have disallowed SHORTTAG.  Allowing it
>> > when nobody supports it makes validation meaningless, [...]
>>
>>       <DL COMPACT="COMPACT">
>>       <IMG ISMAP="ISMAP"> . . .
>>
>> browsers still don't get attribute name minimization right for things like
>> <P CENTER> as shorthand for <P ALIGN="CENTER">, and SP won't catch those.
>> . . .
>
>SHORTTAG implies those?  Damn.  I guess that means we have to keep
>it, because it's too late to back away from <DL COMPACT> now.  I
>only wanted <B/Bold/ and <> and <!> expressly forbidden.
><P CENTER> obviously should be as well.  I appears, then, that
>the SGML DTD is inadequate for validation, and validators have
>to have a lot of application conventions built in to forbid things
>that nobody supports but that are SGML legal.  That's unfortunate.

You seem to assume that HTML is a fixed language. Documents that validate
under HTML 2.0 with SHORTTAG = YES don't necessarily have to validate under
a different, newer DTD with SHORTTAG = NO. The predominant purpose of a DTD
is to allow variations in SGML applications, otherwise we'd simply all use
one SGML application (although I can't imagine one that would cover the
gamut). I would hope that future versions of HTML do turn off SHORTTAG in
the declaration. It's utility is long since past given the problems leaving
it YES entails for validation.

>While we'd all love to see browsers become SGML-based, that isn't
>going to happen; not now, not in the future.

Huh? Precognitive, you know the future or something? I guess we'll just
close up shop here and go home. Damn, and we were so close...

Funny thing is, out with the SGML bathwater goes complex stylesheets,
document validation, SGML application-independent browsers (HTML 2.0, 3.0,
4.0, etc.), and a host of other features.

The first part of your statement, "we'd all love to see browsers become
SGML-based" is a rather grand assumption. There are plenty of people I can
think of that would rather not see that happen. The second part, well,
there's simply no good reason why that would follow from the given reasons.
Why couldn't an "SGML-based browser" (by which I'm assuming you mean one
that builds a document representation based on parsing a document instance
against its declarated DTD) simply have corrective error behavior?

In a roundabout way, that's what the current "non-SGML browsers" do: they
have built-in error handling behavior to handle all the incredibly sloppy
markup out there. Simply build error handling into an "SGML-based" browser
and voila, the real deal. Plus, you finally get to see where sections of
that important document might be missing to half of your clients because of
a missing quote or a bad comment.

Segue...

>While we're at it, can we solidify the hopelessly ambiguous and
>ill-specified comment syntax?  No matter what, we're going to
>break some existing browsers when that one is cleared up, so we
>might as well pick the cleanest, easiest-to-parse (and as it
>happens de facto standard) syntax.  I.e., begin with <!-- and
>end with -->, no exceptions, no weird stuff like "<! -- first
>comment -- bet I can break your parser! -- second comment -- >".

Rather than rehash this one, I'll just refer to a document I posted online
recently:

    http://www.stonehand.com/doc/comments.html

This message was getting kinda long as it is...

Murray

```````````````````````````````````````````````````````````````````````````````
     Murray Altheim, Program Manager
     Spyglass, Inc., Cambridge, Massachusetts
     email: <mailto:murray@spyglass.com>
     http:  <http://www.stonehand.com/murray/murray.html>
            "Give a monkey the tools and he'll eventually build a typewriter."

Received on Thursday, 16 May 1996 08:04:37 UTC