Why We Need to Improve the Style Attribute

O’Reilly Network

Some time ago, someone posted a question to comp.infosystems.www.authoring.stylesheets which was, on the face of it, a simple and reasonable request. All the poster wanted to do was style a single element and all of its descendants with an external stylesheet -- that is, they wanted to apply an external stylesheet to just a portion of the document, instead of the whole thing.

This required a capability for the attribute style that it doesn't currently possess. Having given this subject some thought and talked it over with a number of experts and interested parties, I firmly believe that we need to extend the style attribute in exactly the requested way.

(For those unfamiliar with the intersection of CSS and HTML, the attribute style can be applied to any element in HTML, and is used to attach a fairly simple set of styles to that element alone. This is sometimes referred to as inline styling, which is the term I'll use in this article.)

Of course, in order to extend its use, the style attribute needs to remain a part of Web markup. This state of affairs isn't quite as certain as you might suspect. In this article, I'll lay out the recent history of the style attribute and then explore a way to allow a vital enhancement of its abilities -- one that would actually promote the separation of style and structure. This enhancement is, all on its own, a powerful argument for retaining inline styling, as well as a necessary step forward in the development of the Web.

Pros and cons

It was only recently that the style attribute was nearly dropped from the Web altogether. During the creation of XHTML, there was a great deal of debate over whether the style attribute belonged in XHTML at all, and its status drifted from one module to another -- at one point, it was placed in the "deprecated" module, dropped into the same trash can as FONT, and marked for eventual termination. After a long and often heated argument, the style attribute was moved into its very own module.

Why all the fuss over what might seem like a necessary part of Web markup? The arguments against the style attribute can be mostly boiled down to this: XHTML should be a purely structural language. Therefore, any close binding of presentation to document structure should be dropped. Since we have the STYLE element and the ability to use external stylesheets, there is no need for the style attribute.

It was also argued that as an attribute, style does not contain any semantics as to which style languages are allowed. Setting it to default to CSS might make sense from a "widest use" point of view, but that has political ramifications. There is the view that if the style attribute's namespace defaults to CSS, then that is much the same as giving blessing to CSS as The Best Style Choice. Some members of the XHTML Working Group have problems with that implication, whether because they don't like CSS or because they simply don't want to get into the subject of what is The Best Style Choice for a given document.

These forces, among others, are what almost led the style attribute to be dropped from XHTML. Opposing this push were a number of authors and implementors who argued that the style attribute is a necessary part of the Web. Authors don't always have access to the entire document, they said, and so without the style attribute, these authors can't perform any styling at all. Besides, there are times when you just want to do inline styling. It might violate the perfect and holy schism of structure and presentation, but it's useful and convenient, goes this argument.

So now we have the style attribute dangling precariously off the side of XHTML, sitting in its own module and forever prone to being knocked out by a strong push from the Structuralists.

Making the attribute's powers complete

Personally, I don't think the style attribute goes far enough, even in its current form. As it stands, an author can have a single rule block as the value for the style attribute. This prevents authors from doing things like first-line styling as part of a style attribute. Why? Because selectors aren't allowed in style attribute values, and that includes pseudo-class selectors like :first-line. In other words, if you want to do a first-line style on a specific element, you're forced to give it a class or ID and style it from an embedded or external stylesheet.

This might not seem like much, but it's generated enough complaints that steps are being taken to fix the situation. If this work is taken to its conclusion, then authors will be able to accomplish first-line (and similar) styling inside style attributes. It might look something like this:

<p style=":first-line {color: green}; {font-family: Times, serif;}">...</p>

Assuming that this enhancement comes to pass, we'll have come very close to the point of allowing complete stylesheets as the value for a style attribute. This is a good thing, and it can be even better. Let's allow @import directives in style attributes, too:

<div style="@import url(aside.css);">...</div>

This was, in fact, precisely what that long-ago poster to Usenet wanted to do, although in his case he wanted to style a table.

You may well be recoiling in horror at this moment -- or nodding your head in agreement. Either way, let's see how this enhancement of the style attribute can make life much better for authors.

The implications are staggering

Okay, so if we allow @import directives in the style attribute, how will this improve things for authors, implementers, and everyone else? First, consider the ability that you as an author will gain. Re-using style written by other people on portions of your document will be vastly simplified.

For example, let's say you're a CSS expert and you write articles about how CSS works. Let's further assume you maintain a CSS browser support chart, showing which browsers support which properties. When you write an article about, say, display, you'd like to include the portion of your chart that charts display support in your article. Further assume that you write your articles for an online magazine which uses a document publishing system that prevents you from changing anything in the head of the document. All you can do is fill content into a portion of the body element. And finally, just to round out our completely random hypothetical example (ahem), suppose that the aforementioned support chart's display is almost totally dependent on an external stylesheet for styling. You have the data in a table, but the color-coding and other aspects of the chart are all handled with CSS.

All right, so there's the situation. You have a chart that requires an external stylesheet for its presentation, and an article where you can't add an external stylesheet to the document. What do you do, hotshot?

At this point, you have but one choice. You get to strip the class and ID information out of the chart fragment, and convert all the styles to inline styles. As an experiment, I did this for the "display" portion of the CSS1 browser support chart. The result can be seen in Example 1; I put it into a separate file because including it here would have doubled the length of the article!

By contrast, let's assume that I can use @import directives in the style attribute. This leads me to the result seen in Example 2. It's a lot neater, and rather than destroy the structural markup, this approach helps me preserve it. Habitual readers of my column could establish their own styles for the tables, knowing that the structural hooks they need will be there.

Of course, there is much more at stake here than simply making support charts easier to split apart and display. Let's say that you want to include a fragment of someone else's document (fully credited, of course) as a part of a page you're hosting. You'd like to keep the same styles that the original author used, but how? You'll have to link in his stylesheet, make sure none of his class or ID naming conventions conflict with yours, and also make sure that his styles aren't going to start applying to your content. After all, if he set paragraphs to green and you're trying to make them purple, you need to make sure your styles win in your part of the document, and his win in the excerpt.

How do you accomplish this? You could set an ID on the excerpt, and then use a copy of his stylesheet where every selector is modified to only operate in the context of that excerpt. But then later, if he changes his stylesheets, then you'll either have an outdated look, or else you'll need to get the new stylesheet and massage it. What a nightmare!

On the other hand, if you could just write this:

<div class="excerpt" 
    style="@import url(http://www.some.site/styles/forest.css);">

... then life would be much, much simpler for you, wouldn't it?

Let's take this particular idea even further. Let's say that you're very interested in mathematical markup. You've even gone to the effort of creating a dozen different stylesheets for rendering equations, and you put them on your Web site for others to use. Which do you think they'd rather do: go through a fair amount of manual effort to hook up your styles to their markup, or simply point to your stylesheets from within a style attribute? Especially in cases where they'd like to use two or three of your stylesheets within the same document? If they can perform a series of inline @imports of your stylesheets, then these problems simply evaporate.

Better still, how about styling different parts of a document in a media-dependent fashion, or even having more than one stylesheet associated with a fragment? Consider, for example:

<div style="@import url(basic.css) screen;
            @import url(printout.css) print;
            @import url(royal-shakespeare.css) aural;">

Try accomplishing that with HTML and CSS today. Even if you figure out a way to modify the markup and styles and make it work -- and remember, you have to restrict the styles in those stylesheets to this single div -- try it when pointing to stylesheets maintained by someone else on a remote server, where you can't change the selectors. (This ability was also demonstrated in Example 2, in case you didn't go look at it the first time.)

In addition, allowing inline @import will let implementers get a huge leg up on a tighter integration of the Web and other applications. When copying text from a Web browser to a word processing application, for example, it is often very important to bring the styles along with the text. At present, the only way to accomplish this is to either create inline styles on the fly, or else do some kind of proprietary magic in order to get the text to look right. If @import directives are permitted in style attributes, however, neither is necessary. The word processing document can simply point to the original stylesheet, or perhaps to a local copy of the external stylesheet. Either way, the document's size and complexity is reduced in favor of a simple pointer.

Conclusion

It's really very hard to envision a downside to this enhancement of the style attribute, unless you count the screaming it will inevitably provoke in certain areas. By permitting @import directives in the style attribute, we'll gain the following:

Remember that in every case, the document's structure doesn't need to be changed at all. When a piece of one document is inserted into another, its original structure can be preserved. With current style association mechanisms, this isn't always possible. There are cases where attempting to bring in an excerpt will require special manipulation of the document structure and the styles used in order to make the inclusion work. This benefits almost nobody. As I believe I've shown in this piece, there is a better way to do things. Although the concept needs a little touch-up work to hammer out the fine details, it's a very positive step forward for Web authoring, and I believe it to be a necessary and logical enhancement of an existing mechanism. With all of the advantages this enhancement embodies, it's my fervent hope that we'll see it come into being in the near future.