Behaviors and semantics and the classic unobtrusive popup
When learning unobtrusive JavaScript
one of the core examples I nearly always come across is the classic popup demo without having to use inline JavaScript. Without a doubt, if you’ve looked into this semi-new wave of scripting outside the body, you may have seen something along these lines:
classic popup (bad)
<p>
<a href='#' onclick="window.open('http://example.com',WinName,'width=300,height=300);">
Glossary Term Lookup
</a>
</p>the “accessible” popup (better)
<p>
<a href='http://www.example.com' onclick="window.open(this.href,WinName,'width=300,height=300);">
Glossary Term Lookup
</a>
</p>the “unobtrusive” popup (best)
<p>
<a href='http://www.example.com' class='popup'
Glossary Term Lookup
</a>
</p>As you can see, in the first example, our information behind this glossary term will fail to be accessible if JavaScript is turned off. In the second example our glossary term will have a fall back if JavaScript is disabled and still open up an ordinary window instead of a popup. Finally in the third example we’ve removed the inline eventHandler and replaced it with a class name of “popup.”
Semantics gone bad
The above example is all fine and dandy, but one thing JavaScript developers and early unobtrusive
adopters have failed to recognize is the naming of our popup link. Albeit we’ve separated the behavior from the anchor element, we now have an unsemantic class name.
In CSS, developers are often encouraged to veer from naming classes in the likes of bold or big or blueBox. Reason being, they convey presentation, and… that’s bad (and lets refrain from arguing otherwise for the sake of this article).
Likewise, for JavaScripts’ sake, it’s also a good idea to refrain from naming classes that convey behavior. Thus, in our popup example, the class name popup conveys behavior. So we may want to alter our unobtrusive popup example and make one final change to our html lest we decide to change the behavior of our popup class to do something else.
Our final alteration should look more like this:
unobtrusive with semantics (better than best)
<p>
<a href='http://www.example.com' class='glossaryTerm'
Glossary Term Lookup
</a>
</p>Lesson Learned
This isn’t a big deal. It’s just something to keep in mind that as JavaScript development continues to grow, it’s good to keep in mind semantics. It would be a bit silly having a class name of “popup” when later we decide to attach some toolTip effect to our links with a popup class attached to it.
All in all, it’s just one more step toward learning to remove presentation and behavior from our markup layer.
January 30th, 2006 at 7:30 pm
I was thinking about this the other day actually. Its a very valid point.
January 30th, 2006 at 8:04 pm
Yup, I agree with you there. I usually use the class name “help” for links like that.
January 30th, 2006 at 10:32 pm
I have to disagree with you on this point. I think the class ‘popup’ is a better choice. There will be other locations in the site that will requrire popups - so we can group all those links under just one class ‘popup’. We we were to prefer the sementic way, there will be a lot of classes involved.
I think that the most semantic solution is using the ‘rel’ attribute like this…
<a href=’http://www.example.com’ rel=”popup”>Glossary Term Lookup</a>
But then we will not be able to use the handy ‘getElementsByClassName’ function.
January 30th, 2006 at 10:46 pm
Binny, I think you’ve missed the point on this one. ‘popup’ is a behavior, and has no semantic meaning to the content you’re relating to. Naming your glossary terms (or as justin calls them ‘help’ words) with a class name of ‘help’ or ‘glossaryTerm’ detatches the context of it being a popup. As I was saying in this entry, it would be silly that later on you’d want to change the behavior of all your glossary terms… but you’ve went ahead and put the word ‘popup’ on all of them.
You’re also abusing the ‘rel’ attribute (if you were to use it) as a relationship cannot technically be a behavior like ‘popup’.
Another thing, if you’re going to group links together to all hold the same popup window, now all your links (with a className of ‘popup’) are tied to the same behavior - and in fact it will be more difficult down the road to detatch them lest they require different behaviors.
January 31st, 2006 at 2:13 am
When I said I want to group all popups under one class name, I meant that I will be able to do this….popup:after { content:” (popup)”;}Instead of going like this….glossaryTerm:after,.help:after,.anotherPopupClass:after,.yetAnotherPopupClass:after,.etc:after { content:” (popup)”;}Yes, I know that using the ‘content’ property is not recommended because it creates content when CSS is for presentation. I may want to change colour of the links - orI may want to show a small icon using ‘background’ to mark the links that will appear in a popup. The point is that I can do that by given the rule to just one class - instead of a whole list of classes.Class names have been ’semantic-free’ - and I like to keep it that way. It is a more practical approach the the semantic way. As long as the class don’t have any presentational meaning(like ‘bluetext’ or something), it is fine with me. But that is my personal opinion - so I could be wrong.
January 31st, 2006 at 2:15 am
Sorry about the formating - I just can’t get it right here.
January 31st, 2006 at 5:15 am
Why shouldn’t you add a behavior to a relationship?
It makes sense, if I want help from another page I should use
rel="help"and if I need help I usually don’t want to leave the page I’m on, at least not in the context where I used it on one of my pages (Datevalidation) and you can still use CSS to differentiate the help link from other links.At least in Firefox:
a[rel="help"] {background: url(help-icon.png) no-repeat left center; padding-left: 16px;}or whatever you choose.I don’t feel like I’m abusing the
relattribute. And while you’r at it you can add to the title of the link that it will pop up in a new window, just to let the user know what is going to happen.January 31st, 2006 at 6:54 am
Nicely summarized, Dustin.
Just a little bit of nitpicking on the examples, although this doesn’t really have anything to do with the point of the article (which, btw, was very well written):
1) You forgot the closing “>” on the a-element in example 3 and 4.
2) The closing single-quote around ‘width=300,height=300′
3) And should perhaps do something with |WinName|. Either note that it’s a variable, or put it in quotes to make it a string.
NB! I’m just nitpicking because everything else was good =)
January 31st, 2006 at 10:32 am
Mats, rel=”help” would be a good idea since “help” is not a functional behavior or action.
January 31st, 2006 at 5:21 pm
Recently I was thinking about abusing the class attribute in a different way. I have an element on my page which ideally I could attach some behavior to by referencing its ID. However, the server side language I am using (ASP.NET) can mangle the IDs of elements on a page. So as I work around, I have resorted to referencing it by class. So essentially I have changed the class attribute into a backup ID. It bothers me to use it like that, but I can’t think of a better way.
January 31st, 2006 at 5:36 pm
It only mangles the ID’s of elements that are not going to be unique, like those inside a datagrid or equivalent.
I’m not saying I’m disagreeing with you here, but it happens for a reason and not because ASP.NET is crazy.
I’ve found that although you cannot retrieve an element by it’s ID, you can use functions like getElementsBySelector() to iterate a datagrid and retrieve the controls you are looking for.
February 1st, 2006 at 3:22 am
While I basically agree with you, I also think Binny is on to something oin terms of maintenance and as few class names and little code as possible.
Lets compromise: how about naming the class “more-info”?
February 1st, 2006 at 10:19 am
Thanks, Justin. I found Simon Willison’s getElementsBySelector(), and it looks very handy. I’m just starting to get into all the things you can do with Javascript. There’s so much to learn. There has been quite a bit of advancement in the last couple years regarding it’s use.
ASP.NET will also prefix your IDs if your elements are inside a user control. Also, in ASP.NET 2.0 if you are using master pages, all the IDs of the elements in your content pages will be prefixed (on server controls). Don’t get me wrong though, I really like ASP.NET.
February 1st, 2006 at 12:54 pm
Lance, I forgot about user controls until after I posted that, but yeah those ID’s get mangled as well. Haven’t played with 2.0 yet, but that’s interesting.