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 they wanted to do was style a single element and all of its descendants with an external stylesheet. This required a use of the style attribute which it can't currently handle. 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.
Recently, the XHTML Working Group seriously considered dropping the style attribute from the language, and very nearly did so. I think that would have been a huge mistake, because it's a useful attribute in general, and also because it could be the source of even more power-- not to mention actually promote the separation of structure and presentation, which is what most style attribute detractors claim it destroys.
Personally, I don't think the style attribute goes far enough, even in its current form. As it stands, an author can have a 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. 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 work now being done 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>
Given that such things are possible, we've come to the point of very nearly 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.
Okay, so if we allow @import directives in the style attribute, how will this improve things for authors, implementors, 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 which 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 which 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 two choices. One is 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 this 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 actually helps preserve it.
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?
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 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.
In addition, implementors 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 directive 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.
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.