REASON FOR CROSS POSTING
========================
This rather long message is intended to focus solely on the interface
between HTML and style sheets, specifically CSS type declarations for style.
I am not including any comments about the details of CSS specifications,
as those are more appropriate for the [email protected] list, not here.
However, as the current CSS draft does include information about the
linkage to HTML, and my proposal would require a small addition to
the CSS, I have cross posted to both lists.
POSITION
========
I wish to join the voices raised in opposition to the current mechanism
of use of the STYLE attribute on every HTML element as proposed
in this draft.
I understand the motivation for this attribute, and would like
to propose a constructive alternative that I believe would provide
the functionality that the people who wish to include it have
expressed, and yet resolve the arguments that the people opposed
to it have also expressed.
I would like to believe that this proposal is win/win.
BACKGROUND
==========
To place this issue in context, a review of this discussion on the
www-style e-mail group archive[1] as well as the notes[2] from the
conference on style sheets is in order:
At the Paris 1995 conference on Style Sheets Hakon Lie proposed
the presence of a STYLE attribute for every element of HTML.
Quoting from the notes[2] of that conference he suggested:
To further ease acceptance we could introduce the style attribute for
every element of HTML, allowing in-line style specifications in a
somewhat cleaner and more powerful way than with ad-hoc
attributes/elements.
In a later e-mail message[3] to the www-style group he further summarized
the discussion from the conference:
Hakon Lie ([email protected]) wrote on Fri, 10 Nov 1995 13:57:48
> The issue was discussed at length at the Style Sheet workshop[4]
> Main argument against:
> - the STYLE attribute mixes presentational information into the
> structure of the document. This is just what style sheets try to
> avoid, and the attribute is therefore counter-productive.
> Arguments for:
> - one STYLE attribute is better than ten new visual tags.
> - it will be an introduction to style sheets and lead people to the
> real thing. The same notation can be used in both the attribute and
> the style sheet proper.
> I think this is one crucial compromise we have to make if we want to
> see style sheets realized on the web. There is a danger that authors
> never get past the attribute, but we'll have to take that chance. If
> implementations support both style sheets and the STYLE attribute, it
> shouldn't be too hard for authors to see which gives you the best
> milage.
RATIONALE FOR COUNTER-PROPOSAL
==============================
While I agree that a STYLE attribute will be an introduction to style
sheets, I believe that the specific method proposed is counter-productive
to ever using style sheets. Having the style specifications embedded within
the body of the document will make it even more difficult to extract those
specs and now place the same style information into a separate style sheet.
I believe that it is imperative to keep all the detailed style specification
inside the content of the STYLE element that is proposed as part of the
HEAD of the HTML document. That way it is easy to extract that STYLE element
content and place it in a separate document for use with other documents
(which is one of the major purposes of style sheets). It provides the
natural transition to a separate style sheet file, i.e. test it out in its
own separate document first, then extract it as a standard style sheet.
However, I also agree that a user will want to make "this <H3>
different than that other <H3>, etc." or only have some special style
charactistics on this one area of the document, and let the rest default.
It is this motivation that leads to the desire for an attribute on all the
HTML elements that easily defines a style that is unique to this specific
element, as well as the need for a specification that is not simply
tied to HTML element names, or CLASS or ID.
I believe there is a way to satisfy both needs.
PROPOSAL
========
In HTML:
1. Allow the STYLE attribute on all HTML elements.
2. Restrict the value of the STYLE attribute to be a selector NAME of a
style specification which is defined either in the STYLE content in
the HEAD of this document, or in an inherited style sheet specification.
3. Eliminate the new HTML element <C> and instead use the element <SPAN>
which is already defined as part of the internationalization
proposal [draft-ietf-html-i18n] and will easily suit the purpose
with the addition of a STYLE attribute which it, like all HTML
elements, will now have.
In CSS:
1. Retain the current proposal that all HTML element names are valid
selector names, as well as CLASS and ID as selectors.
2. Add syntax to define an arbitrary selector name for a style.
For example:
arbitrary-selector-name {style declaration}
Note that there is value to being unable to distinguish between a
declaration for an arbitrary selector name and a defined HTML element.
This intentionally avoids a difference in style declarations between
"standardized" HTML elements, and elements that are vendor extensions.
It allows reference to the style declaration by a browser that does not
define that element from a document that still wants to use that style.
EXAMPLE OF HTML USE
===================
<HTML>
<HEAD>
<STYLE NOTATION="application/css">
mine {
font-size: 12pt;
font-leading: 2pt;
font-family: helvetica;
font-weight: bold;
font-style: small-caps
color: red
}
</STYLE>
<BODY>
<P><SPAN STYLE="mine">The first three</SPAN> words of this paragraph are
to be rendered in my special style.</P>
</BODY>
</HTML>
CONVENIENT SIDE-EFFECT
======================
Note that by letting the STYLE attribute reference selector names,
and since CSS already defines all elements as selector names, if a style
had been defined for, say, the <H4> element, then that style is accessible
by any element with the use of the STYLE attribute, e.g.:
<CAPTION STYLE="H4">text</CAPTION>
And note that styles (and therefore style sheets) from vendors which
have extension (non-standard) HTML elements are still able to be used
in this indirect manner within documents.
ANALYSIS AGAINST ALL MAJOR ARGUMENTS
====================================
> Main argument against:
> - the STYLE attribute mixes presentational information into the
> structure of the document. This is just what style sheets try to
> avoid, and the attribute is therefore counter-productive.
While it mixes a presentational tag inside the structure of the
document, it keeps the style specifications separate, and easily
movable later to a style sheet.
> Arguments for:
> - one STYLE attribute is better than ten new visual tags.
The STYLE attribute is retained, so this is still valid.
Plus it defines a "standardized" way to declare a style on extension
elements that is still usable to browsers that do not implement those
elements.
> - it will be an introduction to style sheets and lead people to the
> real thing. The same notation can be used in both the attribute and
> the style sheet proper.
The same notation is used for both the attribute and the style sheet
proper, it simply requires placing the notation in the HEAD and
defining a name to refer to it by. Thus it provides the same valuable
introduction to the style sheet notation. And by focusing on separator
names, it encourages setting styles for named elements, which leads
directly into the world of style sheets.
> I think this is one crucial compromise we have to make if we want to
> see style sheets realized on the web. There is a danger that authors
> never get past the attribute, but we'll have to take that chance. If
> implementations support both style sheets and the STYLE attribute, it
> shouldn't be too hard for authors to see which gives you the best
> milage.
The danger of never getting past the attribute is minimized since it is
clear that the specification can be easily moved to a file (style sheet)
since it is all in one location, the STYLE content in the HEAD.
CONCLUSIONS
===========
I believe my proposal minimizes the objections to the proposed STYLE
attribute while retaining the value that its introduction provides.
By allowing the existence of the STYLE attribute, my proposal keeps the
desired separation of CLASS for specification of content categories from
the specification of presentation information by use of the STYLE attribute.
This provides the ability of users to control presentation in the document
in a totally arbitrary manner, but provides an easy transition to style
sheets by ensuring that all style specifications are defined in the HEAD.
It trains the user to look elsewhere for the style specification, i.e.
in the HEAD (or some "@include" file, or some style sheet via LINK or STYLE).
This now provides a simple and style-sheet oriented way for the users and
browser vendors to define their latest "fun" style capability, without the
need for continual addition of HTML elements and attributes.
REFERENCES
==========
1. http://www.eit.com/www.lists/www.lists.2.html
2. http://www.w3.org/pub/WWW/Style/951106_Workshop/report1.html
3. http://www.eit.com/www.lists/www-style.1995/0193.html
4. http://www.w3.org/pub/WWW/Style/951106_Workshop/
__________________________________________________________________________
Michael J. Hannah "Opinions are mine only,
Scientific Computing Systems and will change without notice
Department 4918, Mail Stop 0807 whenever appropriate."
_/_/_/ _/ _/ _/ _/_/_/
_/ _/_/ _/ _/ SANDIA NATIONAL LABORATORIES _/_/
_/_/_/ _/ _/ _/ _/ Scientific Computing Systems _/_/_/_/_/_/
/ _/ _/_/ _/ Albuquerque, NM 87185-0807 _/ _/_/ _/
_/_/_/ _/ _/ _/_/_/_/ _/ _/_/ _/
_/_/_/
"Exceptional Service in the National Interest"
__________________________________________________________________________