RE: CSS1 and tables

At 11:28 AM 10/9/97 -0700, Chris Wilson wrote:
[-snip-]
>parsed and rendered by default.  Really, what you want is a switch that
>the document author could set that says, "this document expects to be
>parsed in strict accordance with the HTMLx DTD, and does not expect to
>have any abnormal stylesheet hacks to match default rendering."  Maybe
>that switch should be linked to the presence of (or the value of) the
><!DOCTYPE>, I don't know - but that seems like a better route for
>attacking the problem.  Comments?
>
	Yeah. I thought about that as well, but proposals to add new <!DOCTYPE>s
generally haven't gone over that well in www-html and similar mailing
lists.  It would make a lot of sense to me, especially if people start
rolling their own DTDs and browsers start supporting downloadable DTDs.
Increasingly, web authors would be used to using whatever the appropriate
DTD was for their documents.  The problem is that when you are talking
about supporting "legacy behavior" in browsers, the behavior that you are
modelling very often does not conform to any DTD at all.  How long was it
before there was anything approaching a Netscape DTD?  Someone, I don't
recall who, finally hacked up a DTD that fairly closely approximated the
behavior of the Netscape browser, but it wasn't an "official Netscape DTD".
 I think, although I'm not sure, that it was at least in part because some
of the legacy behaviors of the Netscape browsers couldn't be described in a
DTD.  Or when you [Chris Wilson] were talking about table inheritance
behavior.  Most of that discussion hinged on people understanding the
difference between text-level and block-level markup elements, and which
were which.  Bold <B> and <FONT> are both text-level, <TABLE> and <P> are
block level.  The start of a new block level element implies the closure of
any open text-level elements.  The <TABLE> in the example couldn't inherit
from the <B> element, because it couldn't be nested inside the <B></B>
element.  Very simple. But then how do you describe in terms of a DTD the
"legacy behavior" whereby the browser picks opens up the <B> element after
the table, automatically matching it with its otherwise un-paired </B> tag?
 I suppose we could start writing DTD which do away with the concepts of
block-level and text-level markup, at least to a certain point. That would
allow you to nest just about anything in anything else, and <TABLE> could
inherit from an enclosing <B>  element.  I'm not sure we want to go there.
On the other hand, maybe we do ...

>XML, incidentally, does not really have the same legacy-generating
>problems, for two reasons - 1) It's quite strict about how
>error-correction is done, and what the containership model is, and 2)
>there IS no default rendering attached to XML tags; you have to somehow
>link a stylesheet to the elements to control their rendering properties.
>
	Yeah, but how do you support legacy HTML support behaviors? The problems
don't exist for new documents in XML, but you still have to deal with old
documents written in somewhat less strict HTML.

-John

>	-Chris
>Chris Wilson
>Didjeridu players drone on and on...
>cwilso@microsoft.com
>***
>
>> -----Original Message-----
>> From:	John Udall [SMTP:jsu1@cornell.edu]
>> Sent:	Thursday, October 09, 1997 8:35 AM
>> To:	www-style@w3.org
>> Subject:	Re: CSS1 and tables
>> 
>> At 02:59 PM 10/7/97 -0700, David Perrell wrote:
>> [-snip-]
>> >
>> >On the other hand, maybe this lame legacy support is a good thing.
>> >Stylesheet authors probably shouldn't make any assumptions about
>> default
>> >stylesheets, and this situation shows why. Don't take chances with
>> CSS and
>> >taxes. Declare everything.
>> >
>> 	Pardon me for butting in, but what would the impact be in terms
>> of
>> development effort, code-base size, maintenance requirements, etc. if
>> one
>> were to develop the browser so that it has a user-controlled toggle to
>> switch between a more permissive "legacy support" mode for viewing
>> documents and a more strict DTD interpretation of the documents? I'm
>> just
>> brain-storming here. I can see some potential problems from an
>> interface
>> design point of view, like how do you explain what this feature is and
>> how
>> it would work to the end-user. But calling it something like
>> "compatability
>> mode" with appropriate options would probably take care of that.  If
>> you
>> want to encourage more people to use more strict HTML, then just ship
>> the
>> product with the strict option set.  If the user community screams
>> during
>> beta testing (or alpha, since betas are turning into "preview
>> releases"
>> rather than real tests recently), then ship it with the more
>> permissive
>> HTML interpretation as the default. This puts the control firmly in
>> the
>> hands of the end-user, where most of us want it to be anyway.
>> 	
>> 	It just seems to me that a feature like this would be desirable,
>> if it
>> could resonably be accomadated in the development process.  Otherwise,
>> we
>> can all just wait for the XML browsers, and deal with same legacy
>> support
>> problems again at that point.
>> 
>> -John
>> 
>> >David Perrell
>> >
>> >
>> >
>> 
>> Standard Disclamer -- The opinions expessed here are my own. They do
>> not
>> represent official advice or opinions of Cornell Cooperative Extension
>> 
>> or Cornell University.
>> 
>> John Udall,                                       
>>       Programmer/Systems Administrator            40 Warren Hall
>> Extension Electronic Technologies Group           Cornell University
>> Cornell Cooperative Extension                     Ithaca, NY 14853
>> email: jsu1@cornell.edu                           Phone: (607)
>> 255-8127
>

Standard Disclamer -- The opinions expessed here are my own. They do not
represent official advice or opinions of Cornell Cooperative Extension 
or Cornell University.

John Udall,                                       
      Programmer/Systems Administrator            40 Warren Hall
Extension Electronic Technologies Group           Cornell University
Cornell Cooperative Extension                     Ithaca, NY 14853
email: jsu1@cornell.edu                           Phone: (607) 255-8127

Received on Thursday, 9 October 1997 15:17:34 UTC