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.
I consider this a HUGE limitation. And I hear people asking about the
ability to include boilerplate HTML constantly, incessently, unendingly.
> 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).
You also lose information (as any transformation to HTML does), waste
disk space, waste cache space and waste bandwidth. You introduce an extra
management layer between source and target. You can introduce software bugs.
Besides which, this seems like a tremendous amount of work to get a
standardized header across departments. Even as an SGML advocate I
wouldn't advise this approach to standardized headers.
> (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. :^)
What does a standardized header have to do with "final control?" It seems
to me to be about making everyone's lives easier. The same goes with
allowing people to modify a stylesheet in predictable ways so that later
you can change it and know if you are breaking anything. Surely when you
program C++ you think carefully about what functions are virtual: when
you go to change that class you know which functions you do not have
complete control over. Stylesheets are not C++ programs, but we ARE
talking about inheritance and overriding.
> 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.
Any predictable parameterization is easy. There is no "sophisticated
system." Instead of typing this:
(make scroll background: (color rgb 0 0 0))
you type this:
(make scroll background: departmental-background-color)
Yes, you must predict the user's needs. No, you do not have to do
difficult programming to achieve it. Yes, there are facilities for
overriding things without explicit consent. No, I would not advise anyone
use them except in an emergency..
> Neither of
> these seems as graceful and simple to understand as the cascading
> mechanism in CSS.
DSSSL parameterization is based on the most simple of computer concepts:
define a variable, use a variable. People raised on WordPerfect will call them
"macros". People raised on DOS will think of them as environment variables.
There is no 7 step algorithm involving the union of rules spread across
files with different levels of priority and specificity.
> 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.
Why resort to other formats, custom programming, information loss, cache
and bandwidth wastage etc.? Just let the stylesheet do it.
> 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?
I either enforce ALL of my rules: "use my colours always" or I allow the
author to have control. Most often the latter, because I don't want to
lose information that some author has hidden in a CLASS. This is also
how I would advise people to use stylseheets (CSS or otherwise).