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
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.
> > -----Original Message-----
> > From: Paul Prescod [SMTP:firstname.lastname@example.org]
> > Sent: Monday, April 28, 1997 7:05 PM
> > To: David Perrell
> > Cc: email@example.com
> > 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.