RE: The concept of cascading

Sorry, I don't see this as a problem.  There's nothing in HTML that
allows the "rigid corporate look and feel" to require a navigation bar
at the top of all documents on the corporate site, either - but I don't
see this as a major limitation of the HTML format.  Such requirements
can be handled in a variety of other ways - for example, the corporation
could require all documents to be authored in SGML (or XML with a
corporate-defined DTD), and then convert all documents to the delivery
format(s) (HTML+stylesheets), which would provide a) much more
flexibility in the long run, as new stylesheet and XML capabilities are
added to the status quo user agents, and b) much more control over the
look&feel of the documents on the corporation's site, since the actual
presentation is generated by the corporate-controlled filter (be it
based on HTML+CSS, XML/SGML+DSSSL, PDF, RTF, whatever).

(I'm not advocating such a system in the least, just demonstrating what
I feel would be a better way to accomplish it.  I personally think
individual departments or people should have the final control over how
their documents are presented, with a look&feel supplied but
overridable.  But then again, I think most of the people I work with
have plenty of common sense.  :^)

But I did understand what Paul was saying, and my statement stands -
with such a system (e.g. DSSSL as it is at the moment), it does not
appear to be possible to generate some baseline defaults but allow the
document author final control without a significant amount of what I
would refer to as "style programming" - that is, either the corporate
designer would have to write fairly sophisticated systems to allow
parameterization (and limit the parameters the document designers are
allowed to control), or the document designers would have to be
reasonably sophisticated in the interactions and design their systems
using the parameters supplied by the corporate designer.  Neither of
these seems as graceful and simple to understand as the cascading
mechanism in CSS.  Their advantage, of course, comes in the control
afforded over what can be controlled at the document design level (or at
the corporate design level).  I see this as a benefit in some
situations, but I described a mechanism using much more portable data
formats than HTML that accomplishes that objective.  I DO NOT believe
that should be the only way to combine presentation attributes - your
description of bad interactions between foreground and background colors
is a legitimate (possible) problem, but we have that today - most
browsers allow the user to set their preferred foreground and background
colors, and most support the document author changing the foreground and
background colors as well.  How do you believe that problem is addressed
by document authors today?

	-Chris
Chris Wilson
cwilso@microsoft.com
***

> -----Original Message-----
> From:	wmperry@aventail.com [SMTP:wmperry@aventail.com]
> Sent:	Tuesday, April 29, 1997 6:19 AM
> To:	Chris Wilson (PSD)
> Cc:	'Paul Prescod'; David Perrell; www-style@w3.org
> Subject:	Re: The concept of cascading
> 
> "Chris Wilson (PSD)" <cwilso@MICROSOFT.com> writes:
> 
> > I'd say you just answered your own question.
> 
>   I don't think he asked the question you think he answered. :)  The
> original point was that of a _rigid_ corporate 'look and feel' for a
> coporation, with certain things that can be changed on a
> per-department
> basis (contact point, smaller logo for the division, etc), that are
> used by
> the stylesheet.
> 
>   If you allow the department to change anything and everything about
> that
> stylesheet, not just what the corporate thesis on look & feel says,
> then
> you can loose the coherent look that they want.
> 
>   Currently there is no way in CSS to say that all headers must be in
> yellow courier 120% font-height, and _not_ let someone change it.
> Personally, I like this, but then I wrote a web browser in lisp. :)
> But it
> can be bad in certain circumstances.
> 
> -Bill P.
> 
> > > -----Original Message-----
> > > From:	Paul Prescod [SMTP:papresco@calum.csclub.uwaterloo.ca]
> > > Sent:	Monday, April 28, 1997 7:05 PM
> > > To:	David Perrell
> > > Cc:	www-style@w3.org
> > > Subject:	Re: The concept of cascading
> > > 
> > > David Perrell wrote:
> >
> > > > Perhaps I'm all wet, but I don't see site maintenance being
> > > > torrentially anarchized by cascading stylesheets. I was
> referring to
> > > > documents styled for the department from which they're
> generated, not
> > > > on-the-fly-customized for the requestor. Control over appearance
> is
> > > > gained with a few centrally-controlled stylesheets, not lost. As
> for
> > > > specifying stylesheets and elements based on parameters, that's
> > > > getting pretty trivial using server-side scripting such as
> > > > ASP. Though not necessary with SS-scripting, using external
> cascading
> > > > stylesheets could still simplify maintenance.
> > > 
> > > I don't understand the benefit of cascading over parameterization.
> > > With parameterization the person in the central design office says
> > > exactly what can be changed and the departments supply "stubs"
> that do
> > > the changing. With the cascade, they can change whatever they feel
> > > like.

Received on Tuesday, 29 April 1997 14:25:07 UTC