W3C home > Mailing lists > Public > www-html@w3.org > January 2003

We don't need the style attribute

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 16 Jan 2003 12:19:27 +0000 (GMT)
To: www-html@w3.org
Message-ID: <Pine.LNX.4.21.0301161217170.15749-100000@dhalsim.dreamhost.com>


We don't need the style attribute. Several reasons have been given for
its existence in XHTML2, but in each case I think better solutions exist:

1. Editing: Copying a block from one document to another should
   preserve the styles.

Most people responded to this by saying that you can always associate
the style through and ID and an embedded or external style sheet, but
IMHO that misses the point.

XHTML2 is designed to be a semantic language. An XHTML2 document has
*no* inherent associated presentation. It may be distributed over the
network with a style sheet, but that style sheet is optional: the
document does not lose any meaning if the style sheet is not applied.
XHTML2 UAs do not need to support CSS.

When you author an XHTML2 document, all you are authoring is a
document with its semantics. If that isn't what you want, then XHTML2
is not the language for you: HTML 3.2, PDF, XSL:FO, and other page
layout languages are more appropriate.

Web authors may expect to find their Web page editors act like their
DTP or word processing software, but that does not imply that they
must generate the same kind of output.

A good Web editor would take the user's input in two forms: on the one
hand, marking up the document's structure and meaning, by providing UI
for the various semantics represented by XHTML2, and on the other
hand, taking the user's stylistic input as a key to constructing a
style sheet. If the user selects a paragraph and specifies that it
should be blue, for example, then all paragraphs could be made blue.
Or the user could be given the opportunity to specify whether he
wanted his first paragraph blue, or wanted to alternate the colour of
the paragraphs, or wanted the default page colour to be blue, or
wanted all paragraphs with the class of this paragraph to be blue.

The user may also have meant that he wanted to indicate that the text
he selected was semantically different: by checking what rules already
have blue text, the editor could also offer the user with the choice
of changing this element to another element ("Your other blue blocks
are block quotes. Would you like to convert this paragraph to a quoted
paragraph?"), or offer the user with the ability to specify what is
special about this paragraph ("What do blue paragraphs represent?").

It is up to Web editor implementors to develop intuitive solutions to
the creation of documents and style sheets that are completely
separate. I am no UI expert, so this is not something I will even
attempt to address.

The point is, though, that editors do not need style attributes: they
need innovative new ways of exposing semantics to the user.

Specifically regarding the copying and pasting of material: If the
author copies a paragraph from one document into another with a
different style sheet, then the pasted content should actually fit in
with the new document, not the old one. Even word processors like Word
implement _that_ correctly.


2. DOM: We need the style attribute because the alternative to the
   "style" DOM property is horrendous.

The CSS DOM is a mess. The whole thing needs a big revamp. However,
the style attribute is completely orthogonal from this.

Most uses of the .style DOM property are for animations or other
behavioural effects, and should really be modifying the override style
sheet, a part of the CSS DOM that has so far not been implemented.

However, the current interface to the override style sheet is pretty
unintuitive, and it would be much better if we could simply say:

   element.overrideStyle.color.red.percent = 50;

...or some such. The CSS WG will be working on the CSS DOM, and by the
time XHTML2 is widely implemented, there should be a much better CSS
DOM in place.

The point, in any case, is that DOM access does not depend on there
being a markup-level attribute for stylistic hints.


3. If you don't have a style attribute you can't serialise the
   document after DOM style changes.

There are plenty of things that can be done that prevent a document
from being serialised, so I'm not sure why this is a relevant one. In
any case, if you are correctly using XHTML2 then you shouldn't have
any need to serialise it with presentational information.

In any case, if this really is a required feature, then it should be
implemented in the DOM: It should be possible to add to the CSS DOM a
method that returned a composite style declaration responsible for a
particular element's style. For example:

   element.cascadedStyle.color.red = 128;

...which would modify the 'color' property that was responsible for
this element's style (or created a rule to match this element and
added it to one of the style sheets). This has the advantage of keeping
the style sheet author's initial dependencies (e.g., "the headers
should be the same colour") intact.

Or alternatively:

   element.overrideStyle.color.red = 128;
   element.overrideStyle.persist();

...where persist() could be a method which took the element's
overrideStyle, found which properties had been set on that element,
and created a unique, class-based rule to match this element, in a
particular style sheet, possibly creating a new globally class at the
same time if required.

Or it could also be done with a single line, as in:

   element.persistStyle.color = 0xFF0000;

These last two options have the advantage that all the overrideStyle
can be removed in one fell swoop. There could even be a convencience
method for it:

   document.overrideStyle.reset();

Or alternatively, the DOM Load and Save mechanism could be augmented
so that it serialised the style into a specific style sheet. The DOM
Load and Save mechanism will need to deal with style sheets at some
point anyway, so this would not be too difficult. This has the
advantage that it is tightly coupled with the serialisation mechanism.

The point is that this doesn't require a style attribute, and doesn't
have to be complicated: There are many other ways of solving this
problem, all of which are better in other ways too.


4. Style is central to my application.

There are cases where the main content of the application is
stylistic, for example if the document is really some kind of
Web-based game. In these situations, XHTML2 is not the language you
should be using. If you have any control over the end user UA, as most
Web based games and applications do ("To play this game you must be
using WinIE6 or Mozilla 1.2.1 or later", followed by a lot of
UA-sniffing), then using a custom XML language with its style
attribute would be perfectly reasonable.


5. Content syndication: I want my content to be rendered the same,
   regardless of which document it is embedded within.

Then XHTML2 is not the right language for you, because XHTML2 is not a
page layout language, it is a semantics language. That's fine: XHTML2
isn't the be all and end all of markup languages. XHTML1 Transitional
might be closer to what you want.

If your content is correctly marked up, then you don't _need_ any
particular style sheet. If you can agree class conventions between all
the users of your content, then you can even use the class attribute
if XHTML2 doesn't provide all the semantic flexibility you need.


6. HTML e-mail requires the style attribute!

HTML e-mail uses HTML 3.2, not XHTML2. There is no reason for e-mail
to switch to XHTML2, since e-mails typically do not need semantic
markup (HTML e-mail should really have been rich text e-mail).


7. We need the style attribute to store stylistic information in an
   intermediate clipboard format.

Formats that do not go over the network do not need to comply to any
particular specification, since all the consumers are under the
control of a single vendor. Therefore there is no reason to use XHTML2
for this scenario.


8. My XHTML2-based discussion system needs a way for my authors to
   style their material because they consider it to be a formatting
   language.

Again, XHTML2 is probably not the right format. (Do you really expect
your users to write well-formed content?) In any case, since you have
to parse their content carefully to get rid of any scripting,
bindings, javascript expressions, etc, it is trivial to extend this
process to extract the style information into external style sheets.


Conclusion: If you need a style attribute, then you are probably not
writing a semantic document, and therefore there is no reason for you
to be using XHTML2. XHTML2 is specifically about *semantics* (like
HTML2 was supposed to be). If what you want is a page layout language,
then use HTML 3.2.

The semantics and the style should kept separate at _all_ levels of
the development process, including the editor. If this is done right,
then there is no need to use the style attribute.


Incidentally, the existence of the style attribute has disadvantages:

1. It encourages a mindset that considers the visual media to be the
   most important one.

2. It discourages the development of alternate stylesheets.

3. It encourages a mindset that presentation is more important than
   semantics, which hurts accessibility.

4. It allows authors to use the wrong semantic element and fix the
   error by changing the style inline, instead of picking the right
   element.

Note also that while the "class" attribute is indeed almost as bad as
the "style" attribute, it has several advantages, mainly that it can
be used with alternate stylesheets. In general, class attributes
should be avoided if possible; IMHO they may be used when the
distinction being made cannot be made by any other method. (For
example, class="permalink" is a bad choice, since rel="bookmark" means
the same thing.)

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 16 January 2003 07:19:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:54 GMT