RE: CSS1 and tables

It depends on how major the differences between "legacy mode" and
"strict mode" are.  To be truly useful, you have to essentially have two
versions of the SGML parser, let alone the rendering property handlers -
one error-correcting "legacy" parser and one strict, SGML-only one.
(Yes, it is possible these could be one - but I'm betting the complexity
of that one would be enough to warrant keeping them separate.)

The problem is that in the user's hands is not really where you want
this control to be - that's the problem with me explaining our table
inheritance behavior as "user stylesheet settings".  The document author
needs to be able to make some presumptions about how documents will be
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?

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.

	-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

Received on Thursday, 9 October 1997 14:28:56 UTC