Re: Container model vs Switches (was: <IMAGE>? <TT> == <I>? toHell(NS))

Abigail <abigail@ny.fnx.com> wrote:
>Foteos Macrides wrote:
>++ 
>++ 	The orginal question was what to do about
>++ 	
>++ 	<TT>teletype font</I>
>++ 	
>++ where the </I> is either a typo or an (ILLEGALLY!!!) interdigitated
>++ end tag for an earlier <I> start tag.  And that discussion basically
>++ has been about whether tags can be treated as just switches, a la
>++ the original NCSA Mosaics and the MCOM_oops_copyright_infringement_NCOM
>++ browsers, or as SGML conformant markup.  I'm suprised at what's being
>++ claimed MSIE does with it, particularly if it's a version with style
>++ sheet support, because that implies style sheets can be supported while
>++ retaining "switch logic", and thus might not force NSN into greater
>++ SGML compliance.
>
>Well, it has always surprised me why style sheets need the container
>model in stead of the switch model. A non-style sheet aware browser
>might treat '<I>' as "add 1 to italic counter", '</I>' as "decrement
>1 from italic counter", and print the text in italics if the italic
>counter > 0. 
>Now, with a style sheet, the I element can be configured to have
>blue background and 12 points font. Why do I need a container model
>for that? Just use 12 points and a blue background whenever italic
>counter > 0.
>
>Furthermore, does the model _matter_? Why should I care if the browser
>use a container model, or a tree, or switches? As long as it does the
>task right, (and reasonable efficient), that's ok, isn't?

	Certainly, in theory, anything which does the task "right"
and is reasonably "efficient" is OK, just as, in theory, any number
of "angels" you can fit on the head of a pin is OK.

	Style sheets are a side issue.  The more important issue
is conformance of HTML with an SGML-structured DTD.  WWW HTML had
*no* SGML-structured DTD before 1995 (at which time, RFC 1866 gave
it one).  During *most* of it's evolution

	( (1995 - ~1990) >> (1996 - 1995) )

HTML was just a relatively small collection of tags, for platform
independent, global information sharing by anyone, who in a relatively
short period of time could get the "hang" of "throwing" them together
into an HTML "document", using one's favorite text editor.  It was a
highly user-friendly, inherently semantic (element and attribute
names that made sense semantically and whose usage could be inferred,
largely, if you speak English, from those names), yet much more
powerful than the information sharing via gopher, which it has thus
supplanted.  The display engine needn't use a "real" SGML parser
with an SGML-structured DTD ('cuz there wasn't one adopted as a
"standard"), and it didn't *really* matter if it used an ad hoc,
SGML-like "container parser", or some "switch detector" for the
relatively small tag and attribute soup.  But HTML and the http
protocol are *much* more complicated now.  The decisions to formalize
the HTML tag and attribute soup via an SGML-conformant ("container
model") DTD and continue it's development more rigorously, with
high compliance to the already well-developed SGML principles,
rather than reinvent the wheel via elaborations of the "switch model",
seems sound (even if you have to spend about #50 to get TheBook by
TheOtherCreator and start learning all those non-intuitive acrnonyms
like EGO and UGH-OH 8-).

	Style sheets come into it because there is inheritance of
styles in relation to sequences of nested (*never* interdigitated)
containers, and the rules for inferring whether or not elements have
ended based on the DTD-specified patterns of optional versus required
start and end tags.  The "need" for a STYLE attribute for tags,
like the "need" for a FONT element, largely stems from hoping to make
a "switch model" tag and attribute soup handler still work reasonably
in conjunction with (or instead of) style sheets being coordinated
with an SGML-conformant DTD for the structural markup.

	Now you have the combination of default styles for container
and contained elements, plus the FONT element, STYLE attributes, and
style sheets, with all kinds of computations and formal or ad hoc
rules for what applies when, where, how.  And sure, anything which
does those tasks "right" and is reasonably "efficient" is OK, just as
any number of "angels" you can fit on the head of a pin is OK.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 31 October 1996 13:42:59 UTC