TV version (Display Regular Site)

Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Abstracting CSS

January 07, 2004

The further you abstract the structure of your markup, the weightier your CSS file becomes. It’s inevitable, and by all indications, the way things are meant to go for two important reasons: it fulfills the complete separation of structure and presentation, and CSS is cachable — each new page load pulls new content alone, without pulling new presentation.

Structural purists would like you to write markup that looks like so:

Markup Listing 1

Of course, we all know that’s simply an ideal. The reality these days is still something more along the lines of this:

Markup Listing 2
<body class="secondLevel">
<div id="container">
  <div id="mainContent">
    <h2 id="tagline"></h2>
  <div id="sideBar">
    <ul id="nav">
      <li class="home"></li>
      <li class="about"></li>
      <li class="contact"></li>

Why the disconnect? With gratuitous use of CSS2 and CSS3 selectors, we could very well achieve for Listing 1 the amount of control we’d expect to apply to the Listing 2 and its extra <div>s and classes. Except that, thanks to a few stagnant and under-powered browsers, we can’t today.

It’s easy to just say that things will be perfect when the proper selectors are supported across the board, but those who dismiss the issue that easily haven’t looked hard enough at the implications of the incredible CSS-fu necessary to make the first example work. How do we hook into the second <li> of the <ul>, for example, if more than one <ul> exists on the page? The corresponding CSS for Listing 2 is easy:

#nav .about {}

Or simply, if there prove to be no conflicts with other elements on the page,

.about {}

What about the code in Listing 1? Consider the following snippit:

h3 + ul > li + li {}

Technically this selects all instances where a second li is immediately adjacent to the first, so it works for selecting the second one, but we’d have to go further and override the rest of the li elements in that particular list. Of course if we were trying to target the 8th element in any given list, that trailing group of li + li + li + ... selectors gets awful long. CSS3 minimizes this by introducing the :nth-child pseudo-element:

h3 + ul li:nth-child(8) {}

Neither of the previous two work in all of today’s browsers. But we’re exploring the future here, so stay with me.

Let’s say we’ve written our selector to target the above-mentioned second <li> in the list in Listing 1, .about. Now we want to add modest formatting to the link within, say a style each for the :link, :hover, and :visited states. We’ll forget :active for now, but assign the same style to :focus that :hover will get:

h3 + ul > li + li a:link {}
h3 + ul > li + li a:hover, 
 h3 + ul > li + li a:focus {}
h3 + ul > li + li a:visited {}

For comparison, the equivalent code for Listing 2:

.about a:link {}
.about a:hover, .about a:focus {}
.about a:visited {}

Now, so far we’ve assumed that there will only be one instance of the mentioned h3 + ul adjacency. What happens if our document is littered with this particular one-after-the-other combination? How would we target a single item and style the links we mentioned above? What if we’re relying on a parent element (perhaps an id assigned to the <body> element) to specifically style the link on a per-page basis? Let’s extend the above example to address these what-ifs:

#homePage h3:nth-child(3) + ul > li + li a:link {}
#homePage h3:nth-child(3) + ul > li + li a:hover,
 #homePage h3:nth-child(3) + ul > li + li a:focus {}
#homePage h3:nth-child(3) + ul > li + li a:visited {}

Clearly there’s a problem here. As the markup simplifies, the necessary selectors increase dramatically. The current state of affairs says that the CSS equivalent of an old-school table-based design reduces the code’s byte-size by roughly 50%. That’s not a hard number, but the case is strong that file size savings are to be had. If the markup simplifies further, will the CSS complexity (and size) increase proportionately, or exponentially?

I’ve explored just this in the past. I’d even revise my numbers upwards — I now foresee writing CSS files of 80k to 100k and beyond. While comparing this experience to old style sites that wasted all their bandwidth in the markup is a valid point, I can’t help but wonder about the future once we’ve stopped doing that.

There’s a digression here about authoring files of that size, especially when you need to edit but one single selector. I’ll save it, since I’d imagine most who work with 15k CSS files can easily see the consequences of that much more bulk.

There’s another digression here about the selection methods used above, and how they’re ultra-reliant on linear ordering. This again will be saved, though it bears investigation some time down the line.

Most of this isn’t a problem now. Odds are it won’t be for many years. But this is the ideal that we’re supposedly moving toward, and I’m not quite sure how ideal it is.

Reader Comments

Nick Franceschina says:
January 07, 01h

“Next up: why client side xslt is bad.”

-I am anxiously awaiting your post

Dris says:
January 07, 01h

In vague relation to this topic:

Honestly, I think the real thing that CSS support in the future will change is extraneous markup. Getting rid of IDs and classes isn’t necessarily ideal, especially if these further identify the content (as opposed to having a “bold” class and a “leftBar” ID). The real deal in coming implementations of CSS will be content generation.

Currently my site’s design employs several extra, non-semantic DIVs just to apply a custom border. CSS3’s content generation module is awesome; I’ll be able to put in the extra design-related elements in as I see fit, without touching the markup (plus, CSS3’s border’s module will eliminate this particular case of extra DIVs, but it was an easy example).

Don’t get me wrong; complex selectors are quite useful, and will probably reduce the number of unnecessary IDs and classes, but I don’t see a need to get rid of them all. The real awesomeness is in content generation.

January 07, 01h

” … there’s gonna be alot of trouble finding the particular class when you need something changed.”

I’ve started indenting elements in stylesheets to identify dependencies. It makes things a little easier to track. Or it would if things weren’t broken across multiple stylesheets. Even so, it creates a clear indication of whether a style declaration exists on its own or if it needs to be placed inside another element before it applies. Anything to make the CSS scanable again. You can see the germ of the idea (it’s about 6 months old) here:

January 07, 02h

jgraham wrote”

“Having a class element is not a bad thing, because the “semantic poverty” of html is a design feature. Semantic poverty is good because it allows the html language itself to stay clean and *simple*, with most elements being general purpose and only a few elements with narrowly defined semantics. Class then allows the author to add structure* relevant to his or her particular topic.
*Structure. /Not/ semantics. Using classes does not add semantics unless you also provide a rigorous specifcation detailing the type of content in each class.”

Which is why it really burns my toast when people use <em> to italicize some text, and *think* that by doing so they’re being more “semantic.”

Rather than using <span class=”…”> or, if that’s too much trouble, using the humble <i> element, they take one of the few elements of HTMLwhose semantics convey definite meaning (the text herein is *emphasized*) and spooge it.

Sean Sieg says:
January 07, 02h

I personally prefer markup example 2 simply because if I were to look at example 1, I would be hard pressed to tell what each part was. ID and Class are not a bad thing, and there is no reason to get rid of them, and indeed they are necessary. Sure, complete division of structure and presentation is a nice ideal, but it’s just that, an ideal.

If my CSS files have to bloat from ~3k (with very minimal hacks, as I don’t believe in CSS hacks unless I have to) to obscene filesizes just to create a more pure division, that’s going too far. I definately embrace XHTML and CSS, but I prefer my data being able to tell me what a portion of content is, whether it be a masthead, menu, or whatever, rather than having to guess, and playing markup games to style my navigation list for example. (When can I have <nl>s?)

January 07, 03h

I really look forward to full-CSS3 availability times. Markup 1.01 would be my choice, with .01 being that I would add ids to particular headings and then gladly use that complicated syntax to define styles for elements going with that header.

I’m sick and tired of changing my HTML, just to be able to implement particular layout.

jgraham says:
January 07, 03h

OKthen: “why client side XSLT is bad”.

It’s slow. To view a normal html document, you need to download and parse a single file. If the file links to any other files (in particular, those with rel=”stylesheet” or rel=”script”), those files need to be downloaded and parsed. In the XSLT case, it is necessary to:
Download the XML source.
Parse the source
Download the XSLT file
Parse the XSLT file
Run the XSLT file against the source
Parse the resulting document
Download any linked documents such as scripts or stylesheets.
Parsing XML is not known for speed, and this could certianly be a problem for low speed devices such as PDAs or phones.

It’s inaccessible. This is the real killer. At present, only two browsers I know of support XSLT - IE and Mozilla. However, for XML+XSLT->HTML to be accessible, it must be perfectly supported by everyone. If a browser doesn’t support CSS, it is still possible to use the document. If a browser doesn’t support XSLT and the document uses some madeup markup language the user doesn’t have a recourse. They will be presented at best with an XML tree (like viewing a raw RSS feed), at worst with a bunch of unformatted text, or a blank screen. Because web browsers are highly optimised for HTML viewing, even if the user goes to the trouble of reading this bundle of text, features such as links won’t work*. The situation with oral browsers is even worse. To my mind, this alone is enough to file client side XSLT under “fundamentally broken”, except perhaps in a controlled-browser environment.

It doesn’t provide additional seperation of presentation from content, especially where there is scripting involved. Although you can generate different presentations of a document using XSLT, the DOM used by client side scripts is still that of the final document. So any client side scripting you want to use still has to know about the final structure of the document.

It provides no benefit to the user. If you feed a user a made up dialect of XML, it doesn’t provide the user with any additional semantics they can use in a meaningful way, unless you yourself provide specalised tools. The simplest example of this is trying to obtain the source of the html document. View-source gives the original untransformed file in both existing implementations. This means that I can’t look for (say) ids that I can use as fragment identifiers. Moreover, the user’s tools have to work with the transformed document, since they are designed to process html- so these applications are not getting any additional information above and beyond what is provided by the html - a screenreader cannot work out that your <book> element represents the name of a book and should be read as such - it still has to rely on the transformed <span class=”book”> and an appropriate stylesheet. This increases the complexity, whilst reducing the usability.

On the other hand, I think that /server side/ XSLT or indeed any kind of server side transformation which allows you to keep your documents in files which are easy to author** and use markup which matchs their logical structure is an /excellent/ idea. In fact, if you are planning on going XHTML (with proper mime types of course), having some sort of content management system that deals with XML properly is all but necessary***. However, I don’t see any value in burdening the client with random XML, especially given the serious drawbacks that approach has.

* Xlink isn’t a solution either, unless you expect every UA to support Xlink.

** This doesn’t have to be XML, of course. Jacques uses something like LaTeX to write equations which are then converted to MathML because authoring in MathML is tedious at best.

*** Unfortunatley, this means that XHTML will never acheive its stated goals. People just aren’t good at writing well formed markup, particually if the document itself isn’t rigidly structured - as is the case with all HTML documents. Instead, we’ll see XHTML 1.x documents that are just as malformed as HTML 4 documents, but with a different doctype.

January 07, 03h

I, for one, would rather edit a 100k CSS file than have to edit each and every page on an entire site. Surely this is the whole point? It might be easier to do with the likes of Dreamweaver but like many others here, I still use a text editor. What is needed is better structuring of the CSS in order to make it easier to find specific selectors etc. The only advice that I can find concerning the structure is about making sure you name things sensibly. This is obviously not enough. A logical pattern would make even a 100k file easy to change. I just wish I could figure one out!

Eric says:
January 07, 03h

This is a test, I have submitted several comments and they do not show up.

Lenny says:
January 07, 03h

An exponential increase in CSS size will still decrease overall bandwidth usage because the ids and classes in the HTML would otherwise be downloaded anywhere from five to hundreds of times. If the concern is downloading the 100k in one shot, by the time CSS 3 is actually implemented on 85% of browsers you can also expect 85% of your visitors to have broadband internet access.

jgraham says:
January 07, 03h

I think the problem with large CSS files is not so much the size (although maybe 100Kb is quite large, one can compress the file or split the CSS into several sheets representing useage patterns across the site, for example) but the complexity of editing such large files.

As always, the tools will save us all :)

At risk of being like mpt and linking all my own work, see for some suggestions I made regarding Mozilla Composer (lately Nvu). In particular, when editing an html document, one should easilly be able to get a list of all selectors from any source that apply to the current element. Maybe Dreamweaver already allows this - I haven’t used it for quite a while.

ic says:
January 07, 04h

I agree with Jacques and Gerrit.
Counting down the s when you can simply identify the
right one with simple and bandwidth effective (compared to li+li+etc) id=”foo” seems the right way to do. And less prone to errors too.

nth-child would reduce the usage of class attribute I guess, but that’s a different story.

January 07, 04h

100k CSS files brings up another problem… sure, the overall bandwidth usage of a certain site may go down a lot, the initial (and all important) first page load (eg home.html) – the first impression a user gets – might mean a 10k html file PLUS 100k+ of linked CSS and JS files.

110K+ download for a first impression? That’s pretty scary!

I think this is an excellent argument for splitting CSS up into smaller files, given the user the styles they *need* for a certain type of page, rather than the styles for an entire site.

To get back on topic, I don’t believe that this is the intention of where CSS+XHTML is going at all – it’s just an extension which will become useful, and perhaps reduce the number of divs required to achieve certain effects, NOT a replacement.

If divs, spans, classes and ids were on the way out, I think they’d be labelled as deprecated.

The good news is that until a div IS deprecated, we won’t have to change our ways at all.

Tim Hill says:
January 07, 04h

re: previous post about broadband
Perhaps in richer countries but in poorer countries, modem connections may be the only solution for a while.

Are we seperating content from presentation so our pages are available to a wider audience?

with bloated css files are we going against this?

MikeyC says:
January 07, 04h

“Are we seperating content from presentation so our pages are available to a wider audience? with bloated css files are we going against this?”

I suppose the argument could be made that dial-up users can always “turn CSS off” in their browsers to avoid downloading bloated css files in the same way that some dial-up users “turn images off” in their browsers.

I think this actually demonstrates one of the benefits of diverting page weight from your markup to your stylesheet: content (what’s important) is still accessible to all.

January 07, 05h

To repeat a bit more bluntly what a few people have said : Whose-the-heck ideal is markup without classes or IDs? Using classes and IDs RATHER than proper elements is the semanticists’/structuralists’ beef, not classes or IDs themselves. Indeed, the “ideal” selectors listed above are not just unsupported and convoluted, but just plain WRONG.

There’re “semantics” to styles too. “I want to apply this style to the eighth item in this list” means something COMPLETELY DIFFERENT from “I want to apply this style to //this particular// item.” These plain-English statements are how you decide what selectors to use; they’re how you distinguish whether a class, or an ID, or a descendant selector, etc. etc., or a combination thereof are appropriate. And if you go by those statements, your use of superfluous classes and IDs is greatly reduced.

BUT, who’s even to say that there’s any such thing as a superfluous class or ID? Yeah, maybe bytewise you don’t want to use them unnecessarily. But if you establish that one element belongs to a class, why shouldn’t you put it on other elements that belong to it, even if you don’t want to style them? Likewise, if you give an element an ID, why shouldn’t you give its siblings IDs to match?

You can say that classes and IDs aren’t just there to be hooks for style, but they ARE there to be hooks for things in general. Maybe someone somewhere someday will run your code through their own special parser or something; I don’t know, I’m not totally up on the projected future coolness of XML, or what the semanticists say people should be able to do with others’ code. But I do know that being stingy with classes and IDs cannot possibly help anyone, anywhere, in any way, except for shaving a few increasingly unimportant bytes off the file.

Michael R. Havard says:
January 07, 07h

From someone who uses XML/XSLT daily I don’t agree with the “no benefit to the user” comment. We have a pretty complex web app with dataviews, tabpanels, custom event binding and communication, validation, full CSS liquid layout, DHTML select boxes, error handling, help system, RPC, etc. This app is used 24/7/365 and our response time per page has to be on average 5 seconds. The majority of the time it’s within 3 seconds (average, most pages are subsecond, a few go up to 30 seconds because of backend systems).

We use XSLT in both server side and client side parsing modes and can switch depending on the user/client.

The gain from client side use for certain clients is mostly from a caching point of view. If I have often used data or some of our more generic templates, they can be cached at the client and help reduce our bandwidth and off load some of our server CPU cycles. We haven’t noticed any appreciable speed difference between the two methods of parsing.

I mean if we argue that parsing XML/XSLT is slow can’t the same thing be said about parsing on the server as well. The difference there is really in the hardware chosen.

As to the accessibility issues, yes I’d agree - some user agents won’t be able to do anything with the content. We are relatively lucky in that we know exactly who is using our app and what their systems are capable of. So for some unknown external user use I might agree that it’s a bad fit client side, due to the lack of control.

Chris Cooper says:
January 07, 07h

“The further you abstract the structure of your markup, the weightier your CSS file becomes.”

In fine art, to abstract something is to simplify it by breaking complex forms down to their more basic shapes. This also makes the piece more *ambiguous*. In fine art this is not necessarily a bad thing. But we’re not talking about fine art. When sifting through hundreds or thousands of lines of code, ambigousness is never a good thing. Using a combination of CSS selectors and tag identifiers is probably a better way to design a document so that it makes sense when you are altering the code. Aristotle said that finding the path of balance is the most advantagious.

Forgive me, but I see very little sense in being a structure purist. Using tag identifiers such as id and class is an easy way to hook into our CSS files. The real problem is that HTML tags do very ambiguous jobs. DIV doesn’t mean a thing to a web design initiate, much less what you do with one. Learning web design is becoming very difficult without programming experience. We shouldn’t allow it to become even more difficult.

CSS needs to reach a point where it’s a completed standard that is completely implemented. Additionally, XHTML must remain relatively easy to learn, and tags must become more representative of what they are meant to do. There are always better ways of doing things, but at some point a standard must mature and remain consistent, or it loses all of its authority.

Dris says:
January 07, 07h

Just to dip my feet in the somewhat digressive XSLT topic…

I wouldn’t be so quick to label an unsupported technology as inaccessible. Here’s an example to illustrate my point.

Let’s say you have a browser that will absolutely choke and die if it sees any XHTML nonsense. It’s stuck in the past and can only understand vanilla HTML. Would you label XHTML as inaccessible? Would you say that XHTML is simply not practical in any foresight, that all client-side implementations of XHTML should be abandoned?

I should hope not. After all, XHTML isn’t what’s inaccessible. It’s obviously the user agent in question that’s causing inaccessibility, and I think we need reminded of that now and then. If you change your code just to candor to an inaccessible browser, aren’t you degrading the code (in essence creating *more* inaccessibility)?

Back to my example. Let’s say that the browser in question is used by 90% of web surfers.

Given that, one can safely say that it’s a bad design decision at that point in time to employ XHTML; however, you just can’t say that XHTML is inaccessible.

Take that and apply it to client-side XSLT. It’s not a great design decision to employ its use on a diverse, public system. However, it’s no more inaccessible just because some user agents don’t work with it. Again, the user agents are those responsible for accessibility problems.

To sum it up: XSLT isn’t practical right now, but it’s an accessible recommendation that has its place in the future.

January 07, 07h

Tony Cervo wrote:

“When you select “New CSS Style in DWMX2004, the last item on the dialog is “Define In:”. Simply select which external style sheet to add it to, and it appends it to the end. I do it all the time…DWMX has *never* dropped a style in the head of my document, and won’t unless I tell it to by selecting “This document only” for the “Define In:” dropdown.”


At a meeting of a local user group i am a member of, a Macromedia technician was showcasing some of the MX products (not sure if it was just MX, or MX2004). As he was showing off some of what dreamweaver was doing, he decided to edit the style of a certain piece of text. As he did, the new style (i think he changed a font from black to red) was dropped into the head of the document.

He said that you can define styles in a seperate file, but if you are in the HTML file, and want to change a style, it will not append the external sheet from within the HTML file, it will just add it to the head section. He said you just have to open the stylesheet seperately.

again, back to the topic at hand…

Eric says:
January 07, 09h

I’m inclined to agree that this isn’t necessarily an ideal worth striving for. With the current model we have of XHTML and CSS, it is ludicrous to me to _completely_ separate style and content. As you pointed out, we are still dependent on a linear system of organization which, though frustrating at times (skip nav! don’t skip nav!) works really pretty well.

My question is: what will the future bring with regard to XML and styles which purport to be able to allow more complete separation and more complete control? Are the examples you cited reasons that XHTML + CSS will simply become obsolete like table-based layouts?

If we are moving to a world of nth selectors and plus signs and <> up the wazoo, I might want to get off. CSS was supposed to simplify life. But maybe that’s just if I have to hand-code all of it.

IF we want the complexity that 100K CSS files will bring us, I have a feeling that some management tools will step in to help us out. I mean, I remember my 300 baud modem and waiting a couple hours for an image download; size is relative… 100K sheets may not be that bad if we have better ways (software) to manage them and/or they write some things for us. Just think of writing pages of the complexity you are talking about without CSS…

I’m still old fashioned - I still code in notepad and write my own style sheets, but if the day comes when the demands placed on us as designers requires that we use some software, and it is developed well, I don’t really think it’s a problem.

January 07, 10h

Good article. One pedantic note:

“h3 + ul > li + li” will apply to all but the first element of said ; i think what you’re looking for is “h3 + ul > li:first-child + li”.

Obviously, as you mention, this gets to be quite a bore when you’re trying to select any specifically ordered child. Furthermore, it’s going to be more of a bore to wait for “all modern browsers” (of their day) to support CSS3 selectors properly.

Gerrit Kaiser says:
January 07, 10h

This is supposed to be the ideal we’re moving towards? Well, if it is, then I’d rather not move with you ;)

Honestly: While it is true that the second document structure contains theoretically unnecessary div’s only needed for styling-hook purposes, I don’t think there’s a need to forget about classes and IDs.

I consider these as markup-enhancing elements not as mere style hooks. While I wouldn’t call myself a “markup purist”, even one of those guys will probably like better than one without ID.

IDs and Classes are an important part of HTML. They’re not just there for Styling purposes (e.g. for DOM Scripting aswell). And they also enhance structure. And they will be there in the future. At least I think so.

January 07, 10h

I agree with Eric.

I too handcode all my stuff (Homesite for xhtml, TopStyle Lite for CSS) and when you start getting large style sheets going, it gets pretty hard to keep up with everything.

IF dreamweaver mx 2004 handled style editing better (writing to/appending and external file rather than dropping it in the head of the doc) it would come close to a good editor, as long as you stayed away from the WYSIWYG. I still don’t trust those things.

On the last few sites I have designed, including the new version of, i started by writing strictly in markup, then wrote the styles for it. I found that i really only had to make a few changes to the markup to pull in a special style for certain h2 or h3 elements.

Gerrit Kaiser says:
January 07, 10h

replace: “even one of those guys will probably like better than one without ID.”

with: “even one of those guys [markup purists] will probably like <ul id=”navigation” /> better than one without ID.”

in my previous posting.
Note to self: never forget to use the preview button again. It’s useful.

January 07, 10h

While I certainly like the look of Markup Listing 1 better, I think I’ll be sticking with the latter method for quite some time to come. It’s taken long enough to get browser support up to a level where basic CSS works. Just imagine how long it will take to get CSS3 support across the board.

Nick Franceschina says:
January 07, 10h

I’m wondering the same as Eric. What about XML? If we’re talking “the future”… then why would I want to create markup that looks like when I could just do , and then use XSL to style it exactly? If we’re talking about the future, then why are we working on CSS3 when we could work on XML/XSL support on the client side?

Are there any posts/discussions on this site about CSS vs XSL? I’m sure it’s been discussed here somewhere….

Huck says:
January 07, 10h

Sometimes I wonder if we changed CSS3 (or CSS4 or whatever) to XCSS, if Microsoft and uh, whoever else sucks at standards, would be forced to implement it entirely for buzzword compliance. Wouldn’t that be cool?!

Mike says:
January 07, 10h

Nice observation Dave. I noticed the same in a recent redesign that we did - while removing the effects of ‘classitis’ the stylesheet balooned (well actually it doubled).

What I find (and I’m sure we’ve all observed while we toil away) is that carfeul use of id’s can mitigate things to some degree, though it wouldn’t allow the level of specificity you outline with your list classes.

After reading though I do have a question (which betrays my shortsightedness!) - Why would we need to forgoe the use of classes for such specificity - other than ‘because we can’?

Anyway, I’ve started experimenting with serving up gzipped content+css as a result of the ballooned stylesheet (it’s only 17k, but hey, a zipped 17k text fileleads to some serious packet reduction).

Nick Franceschina says:
January 07, 10h

Whoops! sorry:

why would I want to create markup that looks like <span class=”book”> when I could just do <book>

January 07, 10h

Aside from the totally superfluous <div id=”container”> in the second markup, I see no reasonable sense in which it is “inferior” or “less semantic” than markup 1. Indeed, I would argue that the opposite is the case.

The fact that you need ridiculously complicated CSS2 selectors to style markup 1 (or only slightly less ridiculous CSS3 selectors) is symptomatic of its unsemantic, brittle nature.

Reorder the links in your navigation list (or add an new one) and — poof! — you break your hideously complicated CSS stylesheet.

By removing the <div id=”container”> and <div id=”sideBar”> from markup 1, you’ve removed all traces of structural groupings and muddled the semantics of your document.

id’s are potential link-targets, not just hooks for CSS styling. Again, by removing them, you’ve harmed the semantics, decreased the accessibility, etc, etc of your document.

The *only* good thing to be said about markup 1 over markup 2 is that it has fewer bytes. Turn on gzip compression and even that advantage goes away.

jonner says:
January 07, 10h

Nick, the reason we’re not having css vs. xsl discussions is because they work hand-in-hand. XSL is a transformation language more than a style language. And it transforms XML into HTML. You’re still left with the problem of how to style the HTML in this case. Then you’re right back to the tables versus CSS argument again.

MJH says:
January 07, 10h

I think as a reult of these 100k files, theres gonna be alot of trouble finding the particular class when you need something changed. Even if you break your CSS into multiple files, only the original developer will be intimate with the code enough to find the proper class to change…

Good thing we’re getting rid of CSS Hacks which would unnecessarily add to the CSS file size. ;)

I agree with the XML/XSL comments above though. It seems the way to go, but try cross-browser developing in it right now. Near, if not totally, impossible.

Andrew says:
January 07, 10h

I always have thought that the web was for the masses. Once we get to the point where you have to have a degree in coding will the web become only for corporations and the elite. Using ID’s and Classes make coding and layout easier. I work in the museum business archiving lot’s o stuff. For this we have RAD, EAD, Dublin Core, MARC and so on. Once we start creating our own tags <book> instead of <span class=”book”> we are going to begin to get a standard that if printed out would take numerous binders. While we may end up there, there is a point where you have to go ‘enough’ and deal with what you have.

Can you imaging the flame wars discussing the use of a <book> tag or similar? “Is this really a book, more like a collection, maybe it’s a periodical” etc…. Classes work well - perhaps what is needed is a controlled Vocabulary so that when you do mark up a book you would use <span class=”book”> replacing ‘book’ with whatever is needed.

Maybe we should just code all our sites in SGML and leave it at that - but do we really want to write our own DTD for each site, or page? BTW if you really want a brain hemorrhage try reading the SGML specs. I think that classes and ids are more than just a hook for styling they give meaning to an otherwise meaningless tag.

David House says:
January 07, 10h

Remember why we’re seperating content from style (well, one of the reasons, anyway) — for ease of updateability (made that word up on the spot :D). Overuse of the adjancecy selector tosses this out of the window. For example, we have this list:

<li>Item One</li>
<li>Item Two</li>

If we want to refer to only the second item, it seems quite obvious that we use ul li+li. But as the list gets longer and longer, it gets harder and harder to specify the right element (especially if you add an element high up in the list — whoops! twenty CSS declaration blocks need to be changed), and if we’re dealing with, say, lists 20 items long, and with CSS files in excess of 20k, well, it’s starting to look infeasible.

That’s why :nth-child() needs to be supported. It’s great.

Nick Franceschina says:
January 07, 10h

jonner, alot of people think about XML/XSL that way, but what if instead of sending HTML to the browser we sent XML to the browser and instead of linking in a CSS we linked in an XSL (IE has been able to do this for years). XSL has MUCH more powerful selection capabilities than CSS… and it has it right now. the problem is that it isn’t well supported on the client side. but we’re talking about he future ;)

so you get better markup and better selection power.

Suzanne says:
January 07, 10h

Is there a compelling reason to not use the cascading part of cascading stylesheets to ease one’s pain with larger files? They can be nested, in that regard, no? As long as we have identified elements that structure the document, one could have a stylesheet for positioning, and then a stylesheet for each unique div, all nested in a larger global stylesheet. Dynamic scripting could control which CSS files are popped inside the main one?

For me, the essential part of separating the style from the content isn’t standards or current trends or cred – it’s not having to touch the content itself repeatedly. I don’t mind revising the templates and the CSS files, but to have to go in an work with existing markup drives me crazy. I’d gladly create complex CSS to save myself from the tedium of modifying the markup of already marked up content.

January 07, 11h

Jeremy F. wrote:
“IF dreamweaver mx 2004 handled style editing better (writing to/appending and external file rather than dropping it in the head of the doc) it would come close to a good editor…”

When you select “New CSS Style in DWMX2004, the last item on the dialog is “Define In:”. Simply select which external style sheet to add it to, and it appends it to the end. I do it all the time…DWMX has *never* dropped a style in the head of my document, and won’t unless I tell it to by selecting “This document only” for the “Define In:” dropdown.

Ok, back to the topic…

January 07, 11h

I want my XHTML2, complete with <section> and <h> tags.

DIVs really don’t have any meaning. They are just the generic block-level tag (like SPAN is for inline elements). Sections will allow us to make semantically correct chuncks with less markup (you can probably trash a few of your class names along the way with section tags).

Then again, many out there don’t like XHTML2, but I digress.

jgraham says:
January 07, 11h

I have to agree with Gerrit and Jacques here. I don’t think anyone has tried to depreciate class or id yet.

In fact, the more id’s you put in your documents the better, becase they allow people to link to specific parts of the document. Ideally, documents would have ids on every element that anyone might want to link to - which basically means every block level element in the document.

The side efffect of this is it makes it very easy to select individual elements in the document to apply style. This is orthogonal to the use of complex css selectors, which allow you to apply rules based on patterns of elements, so that the same style may appear throughout the document with only a single rule.

sil says:
January 07, 11h

As people seem to be suggesting, the solution that seemed obvious to me was to mark up the first example with IDs, surely?

Michael R. Havard says:
January 07, 11h

As with everything in life, moderation is best. I don’t think going the nutso-selector route is a good idea. Sure mozilla-philes tout it as the only way to go (especially by ignoring the colgroup/col html tags).

I think it has it’s place but as is the case with dynamic content you don’t always know at what level that element might be.

For instance we have a “dataview” which is XML data transformed by XSLT into a tabular dataset with scripting providing client side sorting and row hit highlighting. Each column has to be sorted according to it’s data type which also defines how it’s styled. So in a header we might have a class called “standardDate”. In IE we could set that class on the col and have it format the alignment of that particular column. In Mozilla we can’t use col so we have to go the selector way tr > td + td + td + td. The problem with that is that no two dataviews throughout the app are the same. This means on one page it’s tr > td + td + td + td and another it’s tr > td + td.

We could have the XSL just output the CSS with the selector set properly but that’s extra processing time. Likewise it’s extra processing time to put the column class on every “x” cell for that column. Unfortunately placing the class in every cell is easier for the developer to read, easier for use with CSS, and better cross browser.

The point here being that I think id, class, and selector are all just tools and you’ll find ways that they work, and areas where they don’t work well enough. It’s just a matter of striking a balance between keeping your content/style seperated and keeping things maintainable.

Eric S says:
January 07, 11h

Curmudgeon alert. I think that if people thought CSS was headed any direction except this, they never really understood it. The point wasn’t to simplify sites, it was to make markup meaningful. A 1000 page site with a 100k CSS file isn’t a bad thing. Requiring intimate knowledge of CSS isn’t a bad thing.

Anne says:
January 07, 11h

Although CSS selectors and styling the BODY element are great things. ID does add quite a lot of sementics to a document as said by Jacques and jgraham.

The only thing I’m not sure about is CLASS, I think that one is just lame and is currently only there for people who don’t know how to use CSS or for the few times you need it, since IE doesn’t supoprt anything better.

January 07, 11h

Anne wrote:

“The only thing I’m not sure about is CLASS, I think that one is just lame and is currently only there for people who don’t know how to use CSS or for the few times you need it, since IE doesn’t supoprt anything better.”

OK, so let’s see how we can improve markup 2. First of all, we should ditch the <div id=”container”>, which serves no semantic purpose. The other two <div>s serve to group elements into semantically-meaningful units. So they stay.

All the id’s stay. They are potential link-anchors, hooks for DOM scripting, and just plain *id*entify sections of your document.

What about the <li class=”“>s in the navigation list?

Sure you could replace those with cleverly-chosen child selectors. But that would be brittle: add an item to the list, or reorder the items and your stylesheet would break. An unordered list is supposed to be … unordered. CSS selectors which would break horribly if you reordered the list are just *wrong*.

I think the <span class=”book”> versus <book> example discussed above is an example why – given the semantic poverty of XHTML – the use of class selectors are inevitable.

January 07, 11h

to be honest, i wouldn’t say that grouping sections of a document via DIV or similar goes against a structuralist way of building pages…on the contrary. it does, imho, add quite a bit of structural information.
so…i don’t think the future is quite that shade of black that you’re painting it here…

jgraham says:
January 07, 12h

Having a class element is not a bad thing, because the “semantic poverty” of html is a design feature. Semantic poverty is good because it allows the html language itself to stay clean and *simple*, with most elements being general purpose and only a few elements with narrowly defined semantics. Class then allows the author to add structure* relevant to his or her particular topic. From the point of view of CSS, class is invaluable when styling html because it is the /only/ way to write a single selector that applies to multiple elements in the document which cannot be distinguished by position in the document tree alone. Hence class is absolutely necessary if you want html to be both simple** and useful.

Incidentially, if you were wondering why “Only four properties apply to table columns”, Hixie has all the gory detail:

Next up: why client side xslt is bad.

*Structure. /Not/ semantics. Using classes does not add semantics unless you also provide a rigorous specifcation detailing the type of content in each class.

**What, out of interest, could replace ‘class’, provide the same functionality, but be “more semantic”. Regardless of the number of elements you define in the specifcation, it is impossible to cover every possibility, and you loose simplicity. Allowing authors to define arbitary elements is even worse, since there is no structure to the language. The /really/ geeky solution is to require authors to define elements where they would have used class, but place the elements in their own namespace. If that ever happens (it won’t), I’m defining a namespace that provides a single attribute: class, which everyone will be encouraged to use.

Adam Rice says:
January 07, 12h

As usual, Jacques hits the nail on the head in his earlier post. Removing all ID’d DIVs is not markup to aspire to–that’s much like telling programmers “don’t forget to remove all comments from your source code.” Bleah. If nothing else, that would play hell on site maintenance. Balance the microseconds that thousands of readers will sacrifice against the hours you as a designer spend tracing through dependencies.

Class still has a use–the “posted by” lines in this blog (and mine, and others) are <p class=”posted”> or something similar. Having that class attribute could make useful things happen other than just CSS styling. It could make even more useful things happen if everyone used the same markup.

The syntax of CSS, frankly, isn’t set up for maximum ease of authorship or markup. CSS3 looks to be a bit of an improvement.

January 08, 01h

Stripping of id’s and classes is for the johnnys that used visually names styles, like class=”topleft”, class=”blue”.

These add nothing to the semantic value of the markup, and are all about visual appearance. If you are descriptive with your id’s and classes, they have a value in the markup, both now and in the future. The CSS3 selectors are icing on the cake, but you will have to be careful when specifying relativity or adjacency, as any changes to markup will fail the design more quickly than named selectors.

One thing that needs resolving is the use of additional elements to allow for proper box model positioning. Some of these have a semantic purpose in the markup, others do not. The top level ‘container’ in your example is redundant semantically, as ‘body’ should perform that function, but we know that we need it to reliably centre content on the page.

jgraham says:
January 08, 02h

In the case where you have precise control over the users of your site, I agree the accessibility issue becomes less of a concern. Moreover, the disadvantages I listed were primarilly based on the idea of a document based site rather than a web app. If you’re creating a web app and you can control what browser your users are using, you could conceivably replace the html with something that was designed specifically for providing application interfaces like Mozilla’s XUL. Not only would that provide familiar widgets, but it would also allow you to cache the entire application locally and only load the data from the server.

The fundamental difference that I see between using XHTML and random XML + XSLT is that XHTML is broadly backwards compatible. Anyone using XHTML can still serve it as text/html to UAs which don’t support XML and still expect the page to display and function. If there’s one thing that HTML UAs are good at, it’s dealing with malformed HTML.

If the world ever moves to XHTML 2, this syntax compatibility won’t be avaliable, but I would still expect XHTML 2 sites to provide a HTML-compatible version of their page (e.g. using server side XSLT to convert from the stored XML format to either XHTML 2 or HTML and selecting the type to send based on the accept header of the browser). In fact, depending on how XHTML 2 turns out, it might not be necessary to do this, since the syntax may be close enough to HTML that browsers will display something reasonable. At the very least, it will still look like a document (a title at the top, followed by subheadings and body text).

For XML+XSLT, there are never two documents with the same syntax, so the poor HTML UA is left without a hope.

January 08, 05h

Little typo there Dave.

“No we want to add”, “no” should be “now”.

Carps says:
January 08, 05h

Using classes, you can apply the same styling to different things, over-ride part of the styling in specific instances through selectors and change document structure and retain style. Who in the history of the world, *ever*, has written a structurally perfect document first time round without thinking… “hmm - I could do with another set of links here.” Answer: no-one. Hence, we use classes.

More importantly, you can find and change what you need to change in a matter of seconds instead of trying to replicate the document structure with the tab key, or carefully counting the tags to find the nth one.

So, the argument is a none-starter. It won’t be taken up, because it can’t be - in much the same way that XHTML 2.0, or XML / XSLT won’t be taken up en-masse. It requires people to act in a coherent, structured and logical fashion at all times.

Semantic purity is for machines - not people.

And frankly, I couldn’t give a tinker’s cuss whether or not a UA can understand the structure of my document - all I want to know is that I can go in myself, find the menu and change the style without worrying about whether it is a child of x, adjacent to y or sibling of z. There’s a whiff of techno-fascism about all arguments to the counter…

jason says:
January 08, 05h

I have been considering this issue of having to overstyle stylesheets. I am currently testing shortcutting instances of selectors that tend to be repetitively used in CSS, like color, font-size, etc. You can check it out at Although the site is extremely basic, to renders as intended in IE 6 and Opera 7. The shortcutted CSS is a little tricky to follow, but at this point, I have reduced the CSS from 92 to 30 lines of code by doing this. Maybe this is a viable way to cut down on redundant CSS markup and clean up style sheets?

January 08, 06h

The debate here seems to be a bit dubious. Do we really want to style list items separately? Make the ninth item a different colour? It sounds like a rare case.

As for removing class and id, well they do make a mess of your code. I hate image tags - you have to put so much in them (width, height, ALT etc) that a simple piece of HTML becomes awful to read. Add classes and other stuff and it gets worse.

I still code by hand though.

I would say the future lies in XML, that is converted on the server into whatever format is required. New formats can be added easily without touching the code. Hence you will never have to look at the output (except to test it). Headers and sections will be declared in single tags, like the first HTML example in this article. (Mind you, namespaces can add all kinds of junk to XML tags, ending in a soup that’s as bad as old school HTML. Ever looked at the source of a Word file?)

Nick Franceschina says:
January 08, 06h

jgraham, good post. my comments for those that care:

“It’s slow”. Your entire first paragraph about “it’s slow” and then you go into all the details of what has to be downloaded/parsed/linked/parsed/etc/etc… but all of that has to be done with HTML as well! There’s no quantitative proof that it takes less time to download/parse HTML, then download/parse CSS, then download/parse scripts. it’s the same thing. Also, I am not aware of XML parsing “not being known for it’s speed”. The thing is, HTML *IS* XML… it’s a predefined set of XML and parsing either takes the same amount of effort (of course, you could find a crappy XML parser that is the slowest thing on earth and then make that claim). The difference is only that the XML parser will expect a well-formed document, and the HTML parser will take anything. So I’d bet if we ripped open the code for the HTML parser, we’d find it was actually more complicated.

“It’s inaccessible” - IE 5.x and Netscape 6.x (and so, of cousre, Mozilla) supports it… and that’s over 95% of the market… and that’s inaccessible? Your point about what a user sees if the browser doesn’t support XSL vs CSS is well taken. But again, I thought this entire discussion was about THE FUTURE of styling…not the present.

Good point about the scripting issue… I hadn’t thought about that. but then again, if you put your scripting in the stylesheet (since the script will be dependant on the type of “DOM” you’re going to create…. HTML/WML/??), then it doesn’t much matter.

“It provides no benefit to the user” - I’d argue that a user reading “semantic HTML” would be just as lost as reading XML. There are really only a few of us in the world that actually view the source of a document. I know, when you surround yourself with those people (us) it seems hard to imagine… but I’m sure well over 80% (maybe even 90%) have no idea about any of this crap. Yes, the user AGENT may not know what to do with it… but that’s why you woudl send the style sheet for that type of user agent (the HTML stylesheet). Yeah, we could do it server-side with a agent check (as mentioned above)… but again, we’re talking about the FUTURE of styling. A screen reader that expects HTML would request the HTML XSL and that would transform the XML into a format it wanted. If the reader was like an RSS reader, then it would be happy with just the XML.

In any case, there are no standards for either the source HTML or source XML. HTML has predefined tags that browsers know to look for, because browsers are all about reading… where XML is about storing data semantically. “Semantic HTML” is just an attempt to bring XML usefulness to a markup that is out of control. But I would say that having all of the data properly marked up in an XML document would make MORE sense than having a bunch of spans and divs…

everyone, please feel free to fire back at me. I’ve been looking for some enlightened people to discuss this very topic with :)

Nick Franceschina says:
January 08, 07h

see, I *could* just make an XML document that reflects the same structure of a “semantic HTML” document… then have an XSL that styles it… EXACTLY like CSS would style the HTML.

OR, with XSL, I could make the XSL the actual HTML file, and then pull in the XML as datachunks and place them on the page. Now you’re talking about full control of the page. no worries about “hey, I need an extra DIV here or an ID there”. You use the XSL to build the HTML exactly as you want it to be… and use the XML to fill in the content. You’re not limited to simply styling of CSS.

But in that case, you’d probably want to use all three technologies… :)

jgraham says:
January 08, 07h

>[it’s slow] … but all of that has to be done with HTML as well!

No. If you send HTML over the wire, then the UA just parses the HTML once (through the slow HTML parser or the faster XML parser if you get the right mime type). With XSLT + XML -> HTML you *still* have to parse the resulting HTML, just as if you’d sent it over the wire. But you *also* have to parse the XSLT and the XML. There might be situations where this isn’t a problem - principally if each page is broadly similar so a) the XSLT can be cached and b) sending XML only is significantly smaller than sending all the html. Even then, this is only a benefit if the network connection is slow compared to the processor speed. This might be true for the web app case, but is unlikely to be true for a document based site.

> [it’s inaccessible] … But again, I thought this entire discussion was about THE FUTURE of styling…not the present.

Yes, but the point is that using client side XSLT produces a *requirement* that all future browsers support XSLT, or miss out on the content delivered that way. It also *requires* everyone to upgrade to such a browser.

As for IE + Mozilla accounting for 95% of all browsers; that may be true, but accessibility isn’t really about catering for 95% of people 95% of the time. I might use Mozilla 99% of the time and lynx the other 1%. But when I’m using lynx, it might be because X windows won’t start and I’m trying to work out which line of the config file is wrong. In that case I *really* need sites to work in text only browsers which have no clue about style (or XSLT for that matter). So maintaining accessibility is important for everyone.

> If the reader was like an RSS reader, then it would be happy with just the XML.

Well assuming the XML was RSS. Which I think is my point; a user only has tools to deal with a limited number of document types. I see no benefit in sending the user a document type they don’t understand and a script to convert it to a type that they do understand over just sending them a document type that they understand in the first place. Moreover I see several disadvantages, of which ‘inability to view source’ was just one example.

> “Semantic HTML” is just an attempt to bring XML usefulness to a markup that is out of control

No, semantic html is all about what the user is able to do with it. The advantage of having an <em> element over having everyone write a variation on <span class=”quite-important”> is that it allows consistent interpretation by user agents (e.g. visual user agents might render it red ot italic, oral user agents would apply a certain vocal style). This makes life easier both for users and for authors.

> But I would say that having all of the data properly marked up in an XML document would make MORE sense than having a bunch of spans and divs…

On the authoring side, sure. But markup only adds semantics insofar as it is possible to know what a piece of markup means. Semantics are only useful insofar as it is possible to use them for something. So, if you want to author in your own madeup namespace where all the tags correspond to the type of data in your documents, that’s A Good Thing, because it adds value for you (you can use the semantics to enable different presentations of the document via XSL transforms, for example). For delivering the content, it adds no value, because the user has no way of knowing what your markup means. Even if you provide a rigorous specifaction of what the different elements mean, the user isn’t likely to have any tools that will help them extract any of those semantics. If, on the other hand, you convert the document to a widely used delivery format such as HTML or RSS, then the user already has tools that understand those namespaces, and are able to make your markup meaningful /to the user/.

> You use the XSL to build the HTML exactly as you want it to be…

Which sounds cool, but it’s nothing that can’t be done just as inaccessibly using the DOM+javascript, or done server side at a higher cost of server hardware but with the massive benefit that all your users can actually get at the content.

Anne says:
January 08, 08h

Something I read on the lists of the W3C and I totally agree with: “XML has no semantics, HTML has”. Maybe not those words, but it was something like it.

For the CLASS used in each LI, that should have been IDs, since there is only 1 link to ‘home’ etc.

About the SPAN with the CLASS ‘book’, using a custom element BOOK is indeed better and possible using namespaces etc.

Nick Franceschina says:
January 08, 08h

>[it’s slow]
OK, I see what you’re getting at. didn’t catch that from the first post. but in reality, it will take all of a few milliseconds longer to parse two extra docs (XML and XSL) into an HTML doc on the client. the slowness will come from downloading the two (instead of one html). Then it will do all the same work that an HTML doc would do. good point though.

> [it’s inaccessible] [XSLT produces a *requirement* that all future browsers support XSLT, or miss out on the content delivered that way]
Isn’t that just the same as requiring a browser to support xHTML2 and CSS3? If accessibility is a question of backwards compatibility, then yeah… XML/XSL will never work :)

The advantage of sending someone the XML along with a script to convert it to what they want (if they don’t have their own) is that I can maintain my content in one core format: XML, and then I can give it to everyone. I dont’ have to maintain my content in HTML and RSS and blah blah blah. Sure, if I have a database system that can generate the files based on templates… then the problem is somewhat solved. but if I could just keep all of my content stored in one format (either my favorite format, or a standard format for my industry), then I don’t have to maintain duplicates… and that’s better for everyone. Of course, I can just do the transformation on my side and send back the HTML… and then everyone is happy :) … just wondering about the future and how many “stylesheet” technologies the W3C has to develop.

> [Semantic HTML]
OK, makes sense. at some point someone will want to say “hey, all this XML is a mess… we need to come up with a standard for readable documents. let’s make an XML markup that looks like this, and we’ll call it HTML”. and the cycle will continue. I know this probably seems obvious to everyone… but I like to break things down to the basics and think about them (even if they seem trivial, you never know what you might find)

thanks for your input, jgraham!

Nick Franceschina says:
January 08, 08h

also, I’m just grasping this new meaning of “accessibility”… a restaurant may be “accessible” to 99% of it’s patrons, but if it doesn’t have a wheelchair ramp, then it’s “accessibility” is very poor

rudy says:
January 08, 10h


Which is why it really burns my toast when people use to italicize some text, and *think* that by doing so they’re being more “semantic.”

Rather than using or, if that’s too much trouble, using the humble element, they take one of the few elements of HTML whose semantics convey definite meaning (the text herein is *emphasized*) and spooge it.


oh my &deity;

finally, somebody who understands – if you’ll pardon the pun – the meaning of semantics

thanks, Jacques

anybody want to discuss the semantics of the humble SUP tag?

wrong thread, i guess

jgraham says:
January 08, 11h

> Isn’t that just the same as requiring a browser to support xHTML2 and CSS3?

CSS3 shouldn’t affect backwards comptability, because CSS only affects layout not content. XHTML 2 is more problematic (see my earlier comment), which I think explains much of the resistance to it.

> Of course, I can just do the transformation on my side and send back the HTML… and then everyone is happy :)

That’s certianly what I would advocate.

> About the SPAN with the CLASS ‘book’, using a custom element BOOK is indeed better and possible using namespaces etc.

Why is that better?

> anybody want to discuss the semantics of the humble SUP tag

Like ?

dusoft says:
January 08, 12h


why the class in body?

<body class=”secondLevel”>

I guess you can always change body using just <body> alone. Eventually for the different pages you can override it just by using specific one-page css.

Brian says:
January 09, 03h

Can anyone explain why upcoming versions of CSS aren’t structured with XML? It just seems like such a logical application. Also, why are we dealing with plus signs and greater-than signs and whatnot in our selectors when something like XPath has been designed exactly for this purpose?

Rob Halff says:
January 09, 03h

I think the first example isn’t ideal at all and totally broken markup, the second example comes closer to how it should be.

Symantically the first example is totally meaningless, if I would like to parse that code I would end up with some meaningless headers and some paragraphs. Where is the content part ? Which part belongs to the navigation ?

It would be quite challenging in the first example to center the main content and put a border around it, simply because there is no main content, just some headers and paragraphs.

The <div> parts have a right to be there, because it’s the place where ideally would be something like <maincontent> <navigation> or <article>whatever.

Like Mr. Franceschina said, why use <div id=”book”> when you could write <book>. The div’s are there because the markup of html is very limited.

I tried to play around with making my own dtd and using a stylesheet with it. I’m wondering if such a thing is valid. Just a custom DTD and using Css with it:

jgraham says:
January 09, 04h

> I tried to play around with making my own dtd and using a stylesheet with it. I’m wondering if such a thing is valid.

I’m not sure, but I think some of the following points may be valid:

1) On the client side, I’m not sure why you’d want to do this. I’ve said a lot about that already so I’ll try to avoid that discussion here

2) Creating a custom DTD is a perfectly valid thing to do. Obviously. Sending a file using that doctype as text/html seems like a hack though. On the other hand, without employing the hack, you can’t do much. In general, the amount of useful stuff you can do with a custom DTD in a browser is limited. You have to rely on existing html elements to do any of the interesting stuff (like linking, inline stylesheets and so on). You probably also want default styles for the various elements, so that you don’t end up with 100Kb stylesheets(!).

3) Most web browsers (as far as I know, all web browsers, but I might be wrong) are non validating. That means that they don’t have to load the DTD file and in particular don’t have to resolve external entities. The fact that this works for entities defined in the html spec is because the browser carries around a hardcoded list of such entities. This is an example of browsers being well adapted to html, but poorly adapted to generic (SG / X)ML.

4) One reason your XML file doesn’t display as expected is because you’ve commented out the stylesheet (XML parsers can ignore comments, the practice of hiding data in comments is specifically forbidden in the XHTML/HTML compatibility guidelines). The other reason is that you’re relying on specific XHTML semantics in a text/xml document - in particular the use of <style> as a containing block for CSS rather than using an XML-PI to link an external stylesheet. You’re also relying on certian default styles like display:none; for the <head> element.

5) The above seems to hold (in Mozilla) even if you send the document as application/xhtml+xml rather than text/xml. So if you want this to work with xml, you can’t rely on *any* namespace specific functionaliy (like <a href=”“>, for example).

6) If you decide to sidestep the issue by putting your own elements in your own namespace then stuff in the xhtml namespace should work as you expect. However, if you want to be able to validate your content, you still have to write your own doctype that includes elements from all the namespaces you’re using. See for more information about this. XSchema which has referenced there seems to have morphed into Document Definition Markup Language : As far as I know, this is still an unsolved problem.

6) Using the DOM might be ‘fun’. I don’t know what type of DOM browsers would give you javascript access to, but I’d guess “none”. Hopefully I’m wrong.

7) Have I mentioned that using custom elements doesn’t add semantics that most users can make use of? Can I say that again in spite of 1)? If your <book> is different from my <book> then all custom elements create is confusion. Element names temselves don’t mean anything - the specifcation ascribes meaning to those elements.

8) A ‘working’ version of your XML document is here Some margins seem to be off. It might be a Mozilla bug, it might be an assumption that you’ve made about the CSS which doesn’t apply without the default html stylesheet.

jgraham says:
January 09, 05h

>Can anyone explain why upcoming versions of CSS aren’t structured with XML? It just seems like such a logical application.

Why should it be? I can’t find a reference right now, but I get the impression that people working on CSS see the simplicity of the syntax a big advantage (compared with say XSL). Bear in mind the target audience of CSS is not programmers but rather site authors. Ask on www-style if you want more information.

> Also, why are we dealing with plus signs and greater-than signs and whatnot in our selectors when something like XPath has been designed exactly for this purpose?

January 09, 11h

Ok, I’ll summarise my own position rather than referencing particular viewpoints —

* There is nothing unsemantic about IDs and classes. These are annotational mechanisms to add extra semantic information in addition to the conventional semantics of the tag. Note that this definition immediately rules out unsemantic annotations and annotations who’s semantics clash with the conventional (i.e. common practice) semantics of the tag.

* CSS is a language for converting between a machine-orientated interchange format (XML) to a human-orientated interchange format (visual design, aural communication etc).

* XSL(T) is a language for converting between machine interchange formats so that they can be ‘understood’ (a synonym for ‘processed’ in my book) by other processors.

* In the end, its all just processors storing information in a particular form (RDBMS, OODB, RDF, neural network etc), throwing interchange formats at each other and having conversion systems to mediate between these grammars (note that this means that XML occupies the same position as syntax does in human languages. In fact I often call the semantics/(phrasal/morpho)syntax/phonology pattern the ‘Holy Trinity of information’)

Anne says:
January 10, 01h

“Some margins seem to be off.”

All elements including :root are display:inline; in Mozilla by default:

jgraham says:
January 10, 04h

> All elements including :root are display:inline; in Mozilla by default:

I don’t think that was the problem, I think the problem was the assumption that <li> would be automagically display:block. For the 4 people still reading, I updated the stylesheet to ‘fix’ the problem.

Anne says:
January 11, 01h

It should be ‘display:list-item;’.

jgraham says:
January 11, 03h

> It should be ‘display:list-item;’.


John Prevost says:
January 13, 09h

Commenting on the discussion of XML+XSLT to use for markup. From my experience (as a programmer, not a designer, having worked with web systems for… longer than I really want to think about), the benefit here is on the site-builder’s side. And, while that side is less important in some ways than the page-reader’s side, it’s not inconsequential.

A specific example I can think of is back when I was first experimenting with XML+XSLT. One of the secretaries had been managing the company webpages for quite a while using patched-together HTML templates. (You know, the old style kind where you have the type comments.) Well, we couldn’t depend on very complicated CSS at the time either, but we could happily put a server-side XSLT processor up. I set up a test-of-concept system with a specific stylesheet and simple page language, and showed the secretary how it worked. Even with the more constrained nature of XML (having to close every tag, empty tags with />, etc.), she thought it was *wonderful*. And she asked why we hadn’t been doing it that way all along. To her, building pages had just become ten times simpler. No longer a process of searching out what to replace and then going for help when part of the template went wrong–but having a sort of simple toolkit for building pages according to the company style.

With the multiple document inclusion features in XSLT, you can do a very large number of things with very very simple documents. Of course, the more you do, the more complicated the stylesheets become, as usual. But what I like to think about is the fact that things like page navigation aids can be moved out of the main page into secondary pages. You could even do this by making your XSLT source language be XHTML–the stylesheet would transform it by adding site-wide navigation elements.

In any case, I do agree that depending on XSLT support on the browser is somewhat troublesome. Every so often I look for a quick and easy tool that will let me do server-side processing for some client types and send the raw XML versions to clients for others. Because, heck, *my* time matters a heck of a lot.

Anyway, there’s some distance to go here, but I think XSLT can be a very valuable tool–whichever side of the pipe it goes on. Not necessarily for page semantics for the recipient, but for the sanity of the author.