The HTML4 specification is not really clear about CLASS attributes. It can be used as a style sheet selector or for general purpose processing by user agents. Now I’m not sure what is meant by the latter, but perhaps it signifies some kind of extension mechanism. Actually, after rereading the section I think it links back to the roles the ID attribute has in HTML where “general purpose processing by user agents” is explained by some examples: for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.
Personally, I have never used the CLASS attribute for anything other than the possibility I might want to style that set of information in a different way than its normal style. Of course, sometimes I think I’d better remove it as it serves no useful purpose, but somehow I think it identifies the little piece of standalone information. Theoretically this is of course not true. The CLASS attribute value serves of no useful purpose whatsoever for search engines or browsers. User stylesheets might make use of it, but given the amount of people who actually take the time to customize a site with them (I know one) it isn’t really worth the effort.
There are ways however to add some semantics to the values; using the PROFILE attribute of the HEAD element. It was used to create the XFN profile for example. (Ok, that were values of the REL attribute, but the same logic applies to the CLASS attribute.) Makes you wonder why Google didn’t create a profile for rel=nofollow. Perhaps they are just too big to worry about such things. Kind a like FONT and co were introduced.
Anyway, how should you pick a CLASS attribute value? If user agents don’t care anyway, why don’t name it after what it does? <div class=red> anyone? (Or border.) Perhaps sometimes this might make sense, when you are not distinguishing the contents from each other, but the presentation. The problem is that by choosing such a value you are binding your document to a particular style. Just like FONT does. (You might argue TABLE does too, but with the current state of CSS we are still bound, be it less, to the order of elements.) You probably don’t want left, but sidebar looks ok. Using left isn’t bad by the way. It doesn’t harm anyone; it isn’t unsemantic, because the CLASS attribute can’t add any semantics without an appropriate PROFILE attribute value that is recognized by UAs.
(Note that you always want to use meaning ID attributes. Contrary to the CLASS attribute, ID attributes serve other purposes as well. Most important being identifying the element. Being able to bookmark to particular fragment of the document using #right just isn’t good. That would be an example of bad URI design, if you take it a bit further.)
Not important for what you're trying to say, but I personally don't think sidebar is a very good name as it sidebar still implies a sidebar (be it left or right). Just a small example of a sidebar which got turned into a non-sidebar: your very own menu, which as such you named menu, which I think to be a better name. At least, I don't think menu implies any position, all it implies is that it is a list, so you're just semantically giving extra meaning to the list, only you don't really win something with it other than ability for easy styling.
it isn’t unsemantic, because the CLASS attribute can’t add any semantics without an appropriate PROFILE attribute value that is recognized by UAs.
What the? That just doesn't make sense. If you remove the double-negative (isn't unsemantic
) from the sentence, it becomes: It is semantic because the CLASS attribute can’t add any semantics… :-)
I guess he meant "semantically neutral", Lachlan.
There is a slight difference between "it isn't unsemantic" and "it is semantic", but in this case it doesn't make it make any more sense... :)
I think what the sentence should have said is not that it isn't unsemantic
, but that the class attribute is semantically empty.
Argh, a bit slow there!
"or general purpose processing by user agents"
I always thought that to mean that it was something you could use to label things for use in javascript. That might not make sense the way i worded it.
An example would be if you wanted to use javascript to perform image rollovers. You could use a technique similar to the one shown here. Where you would simply give the image class="imgover" and add a "_o+ to the end of your original images.
Lachlan, it doesn’t make the document unsemantic. So it isn’t a unsemantic useage ;-) Perhaps I should have mentioned document there.
Isn't this just another application of the Liskov Substitution Principle (pdf)? Look at it this way:
So in Frenzie's example, changing the concrete implementation of the "sidebar" abstract class changes its behavior. This is a sign that design isn't appropriate.
In fact, just as the markup community seems to relearn the principles that led to LISP, the semantic web community seems to reiterate the principle of OOP. In particular, the whole point of using stylesheets is an application of the Open Closed Principle (pdf). Not that there is anything wrong with that!
I think a class value bears a meaning (ie. is semantic) if the User Agent understands it and knows what to do with it.
A browser couldn't care less if you use class="red" instead of class="error", and from the web designer standpoint everything is always semantic (red does mean red..).
But you don't have to use a profile attribute (which alone doesn't help anything) to add semantic to a class. In the wForms extension (javascript based), class="required" on a input field is understood by the browser and prevents the form from being submitted if the field is empty.
cedric, that is true of ALL computer names from an URI to library function names to the bytes encoding this string. The idea behind "semantic markup" is to use a general framework so that applications can work with markup names that haven't been designed yet.
You see, the requirements of any standard changes constantly. (HTML was never meant for web applications, for example.) Namespaces and other schemes allow a single document to be used by multiple applications without having each standard step on each other's toes. For instance, some other application or standard may need class="required" for a totally different purpose. Without using a namespace scope to resolve the attribute's intent, then documents in each app would break the other one.
Jimmy, the class attribute in HTML is a generic group identifier. As Anne pointed out, it has no implied semantic by default. It's implementation is up to the designer (presentation with CSS, behavior with javascript, ...). IMHO class="required" is consistent with the attribute intent in the XHTML namespace.
Now in an ideal world, I agree with you, instead of class="required", you would use XForms or some other XML schema where required would be an attribute on its own. But most web browsers can't handle that just yet.
There are ways however to add some semantics to the values; using the
PROFILEattribute of theHEADelement.
A profile does not magically add semantics. For semantic markup, you need a mutually recognized human-readable spec stating the intended semantics and software whose programmed behaviors make sense considering the specified semantics.
Makes you wonder why Google didn’t create a profile for
rel=nofollow.
Because doing so would not have added any real value? If Google says there is now rel=nofollow that has a certain meaning, we have a de facto spec. It has been implemented in software. No profile needed. (In practice, there is no need to disambiguate Google’s rel=nofollow from some other rel=nofollow. Profiles solve a problem we are not really having.)
Giving a class a name like 'red' is a bit silly when you stop to think about it. Designer or not. I can see it's red and someone who is blind can't, and software can't see if it's red either. What if the designer changes his mind and alters the colour and not the class name? Happens al the time.
I dont see the point of adding presentational information in a (x)HTML document anyway. Taking the opportunity to use semantic names that relflect the documents structual context does seem helpfull. Also in development and maintenance this can prove useful and effecient.
I also use additional classnames to show the state of an presented element. Toggles for example can look like this. <ul class="menu open">. The script then doesn't have to do the presentational work with obj.style.display="block" for example. It just inserts a classname. This adds more meaning, makes the script more generic and doesn't hurt a fly.
Though I don't use user stylesheets, I do save web pages for printing, first running them through a script that looks at the title to identify the web site, and then adds style rules to hide stuff I don't want printed out, and if necessary adjusting the layout of the main text.
On the "for general purpose processing by user agents": I'm using the class attribute to tag things inside XHTML and SVG as what I call "XML objects". Elements (or rather element sub trees) tagged this way then can be manipulated interactively by users, for instance selected, moved, et cetera. The user agent in my case is thus a JavaScript library (or rather a set of files) that implements the common behavior. In principle, for Mozilla or Firefox, this behavior could even be put into an extension and then be triggered by whatever web pages uses class tags with appropriate class identifiers. In this respect the extension would become part of the user agent, so to say.
Well, I do see a real use of the class attribute (beside its CSS usage)
I agree with an early comment "sidebar" is not very "semantic" identifier (id or class). I use "panel" or something of the sort. More often than not, I find that my "sidebar" is something other than a bar on the side.
I also tend not to use classes like "border" or "red" because they don't articulate really why they're different, usually. I have been known to class elements by their relationship to other elements. For example, on a site which has multiple palette choices, I use "primary-color", "secondary-color", etc. to associate particular containers to their palette's value.
I also find that where I'm trying to do something different, (ie. where a class "border" might be appropriate) I find that I can find a more generic description of its content like "last-element" or find a more appropriate selector. To me the most confusing thing would be to apply "red" class all over and then actually need it to be orange.
Though, admittedly, this is not always possible. In those cases where I can't, or there's no real reason to, I just class its style (usually something like "no-floating" for a label that I don't want floated, or something).