Integrating STYLE to cover most functional needs

David - Morris (
Thu, 4 May 95 18:38:37 EDT

I believe there is an approach which could satisfy many of us interms
of how globalize/localize specification of style information. With
this approach we should teach folks that globalized style specification
is better as common style provides a better overall look/feel but
where style changes apply to a single instance (for what ever
objective the publisher has), local specification is generally appropriate.

My proposal is that style information should come from a hierarchy of
1. The browser implementation, as configured by the user
2. External file, cached, etc.
3. Document HEAD
4. ?container element?
5. individual tag.
6. User mandatory over-rides (point one would be preferences).
Point 1 is current practice and in general 2-6 don't exist today.
Point 6 is intended to acknowledge the fact that users may have
requirements such as FONT size, color blindness, etc. which if not
handled will make content useless. Point 1 will always exist.
Point 6 is optional and possibly left to the browser implementor to
specify. It may be worth some form of RFC description of the kinds
of control a user might need/desire. The effectiveness of this
capability may be impacted by our specification of points 2-5 and
hence this level in the style merge hierarchy should at least be

I believe we have been discussing <LINK> as a mechanism for retrieval
of point 2. Caching applies and the globalization / localization
decision applies. Single document, include it, many documents,
use <LINK>. Write some guidelines and leave it to the information
provider to exercise judgement (afterall, their bandwidth will
suffer greatly if the wrong choice is made).

The document <HEAD> should have a new <STYLE> container. If <LINK>
is used for style information, put it inside the <STYLE>. Style
specifications would be processed in order. The <LINK>ed style
'sheet' should be an HTML document .. the body if present ignored ... that is
The ed