Message-Id: <email@example.com> Date: Thu, 16 May 1996 08:04:34 -0500 To: Lee Daniel Crocker <firstname.lastname@example.org> From: email@example.com (Murray Altheim) Subject: Re: DIV/CLASS Cc: firstname.lastname@example.org Lee Daniel Crocker <email@example.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:firstname.lastname@example.org> http: <http://www.stonehand.com/murray/murray.html> "Give a monkey the tools and he'll eventually build a typewriter."