Three separated layers, capisce?

Si, capisco. But many people don’t understand. Or they don’t want to. Or both.
Interface code is supposed to consist of three layers:

  • Content (HTML)
  • Layout and looks (CSS)
  • Behavior/interaction(JavaScript)

This is so basic, just like using semantics. However, as Jeremy Keith writes in his excellent piece Gotta keep ’em separated (:hover Considered Harmful is also a recommended read), a common problem is that many, many developers use pseudo-classes in CSS for interaction effects.
Hence, of course they then complain about IE‘s incomplete support for CSS 2 (which is a very sad thing, I agree), since there are a lot more pseudo-classes available in it that are supported by web browsers like Firefox, Opera and others.

But pseudo-classes aren’t the way to go, and I don’t know what they’re doing in the CSS specification in the first place.
So why do developers use them? Like Jeremy, I believe that it is because it’s easier to do it that way, and not all of them are accustomed with JavaScript. Peter-Paul Koch also wrote about this (amongst other things) almost a year ago, where he concludes:

However, everyone’s personal preference seems to be CSS these days, and that’s what bothers me. The balance is lost. People seem to be afraid of JavaScript.

And Jeremy wonderfully states:

There is a gap in your skill set that needs to be filled.

That’s all to say, really. Do it right or don’t use it. Many developers (including my Interface Developer colleague at the company where I work) argue:

But it’s so easy to have it in the CSS file.

But what kind of an argument is that? As easy as using tables instead of CSS? As easy as having FONT tags? As easy as using DIV tags for every element on the page and then style them?
It shouldn’t be easy, it should be correct.

There are two cases to argue this, that are semi-valid points that should be answered:

  1. Accessibility
    True. There might be cases where the visiting web browser has JavaScript deactivated/doesn’t support it, but supports CSS.
    But as always, the page should be usable for visitors that doesn’t support script. Not a valid excuse. Another factor to this is that DOM scripting is more widely supported than CSS 2, which means that you will probably be able to target more users with an onfocus event than the corresponding :focus pseudo-class in CSS.
  2. Hover effects on A tags
    Having a numerous amount of links in a page would end up in massive code if you were to add onmouseover and onmouseout attributes to every A tag. But that’s not the way I’d do it, and not the way I’d recommend. Luckily, Mark has written the code for display, so I don’t have to put it here.

 

Now that we’ve finally managed to separate content and presentation, the risk is that the CSS file will just be the new replacement bulk file, with interaction in it as well. Please, please don’t let us repeat the mistakes we did with the HTML files in the beginning. Let’s separate things into where they belong.

27 Comments

  • Dejan says:

    Of all languages/techniques that are in standards use today, I think Javascript still remains one of the things most people are not too familiar with. Surely, there is no single answer that could explain this, but certainly important factor is background and profile of people that are in a situation to use it.

    Finding good designer is not so hard, and finding good developers too… but finding good designer with decent backgound and knowledge of programming is not so easy. Notice that I did not say "programmer with design skills", simply because design talent is something you either have in your nature or not, but design skills are something that cannot be learned simply by reading books or trying hard (design is just another form of arts like music, painting, etc.).

    So, average web designer is usually someone who started with Photoshop/Illustrator and later started diggining into HTML/CSS. Both HTML and CSS are simply markups, and along that path, Javascript is usually first real programming language that person gets introducted to. And that is usually point where most of them stops and say: "I do not like this".

    Very interesting irony in this whole story is that JS is rather "messy" language, rather hard for learning even for someone experienced in dozen of other languages, so person learning it as his/her first language would be more than capable of becoming complete developer.

    One interesting question: as .NET Framework spreads more and more, and soon to be deployed on virtually every machine, we will take it for granted as we take Flash players today. In that case, there is technical possibility to use C# as a scripting language to replace Javascript on the client side.

    Consequences? One programming language less, more uniformity and shorter learning curve.

    What do you think?

  • Tommy Olsson says:

    I’ve seen this topic come up in a few places lately, but I’m not sure I agree. Is a hover (or focus) effect really a behaviour? Or is it merely a state?

    Adding onmouseover and onmouseout as attributes in the markup, which is what most people would do if you tell them that :hover is considered harmful, is definitely not a good idea. That ties the behaviour to the structure much more than a single rule in an external CSS file.

    As you mentioned, JavaScript can be disabled in CSS-compliant browsers. Requiring JavaScript to be enabled, with all the security hazards that entails in browsers that resemble Swiss cheese, just to add important usability like hover and focus effects, that sounds backwards to me.

    I think :hover, :focus and :active belong in the CSS. But I don’t like the ideas about replacing the target attribute with CSS properties, as has been proposed for CSS3! That is definitely behaviour. Today’s pseudo-classes represent states, IMHO. But controlling whether a link is opened in a new window or tab, that is way beyond the realm of CSS.

  • Robert says:

    Dejan,

    Thank you for a long comment.

    Regarding myself, I didn't start out with Photoshop, I started with HTML. Got hooked on it and then simultaneously moved on to Photoshop and JavaScript from there (and so on).

    Interesting question you pose with C#. I take for granted that you mean a situation where no compiling would be needed, not in the developing environment nor JIT(Just In Time) compiling.

    Otherwise, it wouldn't meet the easiness of JavaScript.

    Another factor is if the .NET will be as wide-spread as you hope/think. Also, regarding other platforms, such as Mac and Linux,

    I believe it is up to initiatives like the Mono project to make that happen.

    Basically, though, I think using C# for scripting things such as the DOM would be overkill. JavaScript is light-weight and definitely suited for it. I believe that JavaScript has gotten messy for the same reason as HTML has: it has been allowed to be messy.

    I, for one, would welcome strict data type declarations and real classes, but i think it's just fine the way it is now too. It's rather the

    web browser environment holding further things back when it comes to developing advanced things that demand better performance from it.

  • Dejan says:

    Well, whole webapps story is a really sad one. In the beginning there was one stateless, nonpersistant protocol for simple transfers of data over the net (HTTP). That protocol was meant for transferring text to client, and that text would be renderred in a pretty straightforward way. And nothing more. Then protocol became standard for a new media (Web), so people started devising ways to expand functionalities of protocol, and script languages were introduced (Javascript), and used for some cool simple tricks.

    A few miles down the road, people started making "webapps", so they started emulating persistance, states, etc. – everything that was missing from whole concept of HTTP. XML that was first devised as a way for data exchange between different platforms became new standard for data transfers, although it is really not more useful than CSV, but cool phrases really sell good, you know.

    And if you look what we do have today, you will see whole mish-mash of technologies invented and used just to cover huge unvocered manholes on the road.

    What real web should look like? IMHO, Java applets was good beginning that needed a few iterations to become mature. Java applets are just a part of bigger concept called "Mobile Software" where true "write once, run everywhere" is reached. Software is precompiled in higlhy compact intermediate form that is transferred using internet to client machine. Upon arrival, JIT compiler produces native code that is very optimized and fast (since it is custom tailored to specific configuration) and after that it is executed in secure "sandbox" so high security is achieved.

    By this approach, things are done right from the beginning, instead of using inapproriate concept and then patch-and-fox it with dozens of temporary solutions. No Sir, you cannot build Golden Gate with toothpicks…

  • Robert says:

    Dejan,

    Well, that goes a little further than just my attempt to get people to structure the interface code into three layers… 🙂

    However, what I personally like with the nature of the web is that is (should be) the same, no matter the plattform if correct recommendations and standards have been followed.

    What comes with that is that the user doesn't have to install a certain JVM etc, but just the browser of their choice (or the one that's forced upon them… *cough*).

    Then, of course, people try to do too advanced things in the web browser, and then the question is if the web browsers aren't capable enough for it, or if it isn't the suitable environment.

  • Tommy Olsson says:

    I forgot: I realise that you mean to add the hover/focus "behaviour" through unobtrusive JavaScript in an external file. I still think it's overkill and that it is quite proper to control this with CSS.

  • Robert says:

    Tommy,

    Thank you for your input.

    I'd avoid labeling hover as state or behavior, rather as an event. And events, IMHO, belongs to the programming, not presentational, code.

    This sounds easy in theory and almost impossible in practice, but I think the security issues are the web browser vendors/OS vendors problem, that shouldn't affect good coding practice (I know, I know, in a perfect world…).

    It is a tough question, but I'm just afraid that too much functionality will be added into the CSS file because of lazy developers/those who don't know JavaScript and those few, like you, that bring up the security aspect.

    I can forgive hovers (I sin with them too…), but generally, I think it's better to draw the line now before CSS becomes the new bloated HTML equivalent.

  • Tommy Olsson says:

    Presentational effects (which is all you can to with <code>:hover</code> et al.) belong in CSS, if you ask me.

    If a site uses a hover effect that makes it hard to use for someone, e.g. due to a disability, they can simply override it with a user style sheet. You can't do that with JavaScript, even if I think Opera 8 now supports user JavaScript as well as user style sheets.

    So from an accessibility point of view, CSS is more appropriate.

    While I do understand how you think, I'd say it's going way overboard, like marking up sentences as ordered lists of words. 🙂

  • Robert says:

    From an accessibility point of view, I understand you.

    That's the weak point in my argument… 🙂

    I just fear that the CSS will we riddled with pseudo-classes in the future that does just about anything.

  • Mark Wubben says:

    Robert, have you read my follow-up already?

  • Robert says:

    I have now… 🙂

    But I'm not sure what your conclusion is. :hover is something that can be discussed for a long time, but regarding other pseudo-classes, would you encourage using them or using JavaScript?

  • Faruk Ates says:

    Tommy,

    "Target is definitely behaviour" ?

    Correct me if I'm wrong, but I thought that the TARGET attribute was a gigantic mistake? It should be completely and solely up to the user (person using the browser) to decide whether or not a window should open in a new window (or tab), and at most the website author may specify what they PREFER to happen for the link, but the browser (user agent) should make it completely and easily possible to override such preferences on the user level.

    Given that, the TARGET attribute seems to have no behavioural purpose or definition at all. It's a browser behaviour, sure, but not website behaviour (it doesn't change anything on the website, it 'changes' the browser).

    As for pseudoclasses…

    Robert:

    But pseudo-classes aren’t the way to go, and I don’t know what they’re doing in the CSS specification in the first place.

    Pseudo-classes and pseudo-elements are nearly all completely visual. Their purpose is to access (style) elements in a more dynamic way, i.e. not via ID or CLASS selectors. <code>:first-line</code> is something that you can't specify with a class or id attribute, and separating it in the markup is an even worse idea.

    My point is, the pseudo-classes have a very distinct and valuable purpose, and the only thing that they do (except for the dynamic pseudo-classes, being :hover, :active, :focus) is allow you to add visual styling, which is what CSS is for.

    That said, I do question the need for dynamic "content-styling" done through CSS, and with that I'm talking about the pseudo-elements (:before and :after) in conjunction with Generated Content. The name itself, to me, indicates that it is content — obviously — so, shouldn't it be in the actual content, then? Thus, in the structure layer that contains the content: HTML/XHTML/XML.

  • Robert says:

    Faruk,

    Target is evil. Relieve us from it.

    I think it's an interesting aspect you bring up with dividing the pseudo-classes into styling ones and dynamic ones.

    It was good that you clarified that. Of course, the ones like :first-line should definitely be in the CSS, it was the dynamic ones I was adressing.

    I have also thought about the content ones, and I totally agree with you there: the content should be in the content file/-s, not in the CSS file.

  • Mark Wubben says:

    Robert, I think they should be used. They are there to style an element in a specific state, they don't contain the logic to allow for that state.

  • Faruk Ates says:

    I wrote a Log post about this, which I had told Robert in private but I may as well let the rest of the people in this discussion know about it. 🙂

    I think I've summed up my view on the entire thing rather completely, there…

  • Robert says:

    Mark,

    Thank you for your answer.

    I see your point and the difference you point out, but to me it is like handling interaction in the CSS file, which feels incorrect.

    Faruk,

    Thanks for the link.

    As a reply to not belonging in the specification: As said above, it's only the dynamic pseudo-classes I'm talking about. The other ones, like :first-letter should definitely be in the specification, no question about it.

    I think you and I only have different opinions when it comes to replacing dynamic pseudo-classes with JavaScript when it comes to solely changing the look of something.

    If that's true, I think I can give in a little…

    For instance, if :hover is only used to change the color of a link but not displaying another element or something similar.

    What my rant was about is that people will use it for more interactivity, though, as soon as it is availible in more web browsers, hence I wanted to preach about separating it before it's too late.

    Mark my words, if/when IE supports :hover on any element, the web will be littered with CSS menus and their likes.

  • Faruk Ates says:

    Fair enough, and I share your concern and I agree with you entirely.

    How'd you think we have different opinions, again? 😉

    Seriously though, if it's purely visual, only a color/background change or whatever, then it's CSS. It's 100% style. But the moment someone does more with that, yes, it should be done with javascript.

  • Robert says:

    Faruk,

    I think we’re reached some acceptable middle-ground here.

    Problem is, just as with HTML, if something is allowed (avoid closing P tags in regular HTML, or doing all the interactivity through CSS and so on), then people will do it.

    My belief is that it is easier to keep a firm and consistent standpoint, like all interactivity should be handled in another layer etc, instead of even making people aware of the exceptions to the rule.

    We’ll see what the future holds…

    But don’t worry, we will definitely find something else that we have different opinions about! 😀

  • I suppose I am late to the party? Sorry guys, just going through my backlog of feeds!

    I really like this subject and I haven't made up my mind completely yet. Yes, I am a criminal and abuse the hell out of the :hover class (mind you that this is a 1 year old experiment, if not older).

    The thing is, I am not sure where to draw the line. While reading Robert's original entry and the comments and finally Faruk's entry (implement comments already! ;)), I noticed Faruk's first half of the entry basically says what I think. I don't agree entirely with the second half though, mainly because I am not sure where to draw the line between presentation and behaviour.

    Hmmm, good stuff. Really good. More to think about while sitting in the train! 😛

  • Robert says:

    Hi Jeroen,

    You can join the party anytime!

    It is a tough and interesting subject, but I think it's good to have these kind of discussions to become aware of and see people's different opinions and experiences about it.

  • Robert Nyman says:

    MHayes,

    Thanks for a long and thourough comment, and for contributing with your two cents!

    When it comes to accessibility, it is a factor that someone have to consider, where to demand of the visitor to have JavaScript activated or making sure the web site works when JavaScript is off (or, of course, ommit those functions).

    Regarding:

    …I’m betting the odds are higher that this CSS is gonna work vs this javascript

    As I (and Jeremy Keith) state, DOM scripting has a more wide-spread support than CSS 2, so, when done right, it should be guaranteed to work in most web browsers.

    As you probably know by know, my personal belief is that one needs to be skilled in all three layers (HTML, CSS and JavaScript) to achieve the most structurally correct web interfaces.

  • MHayes says:

    While I'm way late coming around the back side of the track on this one the comment by Mark/novemberborn.net kinda captures it for me…

    "because there are browsers out there which aren't capable of managing the state of elements internally".

    While the 3 layers of separation is a good principle somewhere as a designer you reach that point of okay what are the trade-offs. CSS or Javascript? It's kinda been drilled into our minds at this point that hey, "the user could have javascript turned off!"

    You kinda of reach a point where you say okay I'm gonna jump around semantics or whatever because I'm betting the odds are higher that this CSS is gonna work vs this javascript. Not to mention the CSS is alot quicker to drop in to achieve the same effect-don't have to be a programmer. Coming from a long ago (don't laugh) COBOL background I'd much rather tangle with HTML & CSS (2 elements) than have to worry about Javascript as a third element.

    I thought to myself this is wonderful I can achieve the mouseover/mouseout stuff without even programming–getting twisted and tangled in all of these states and extra quotes and apostrophes.

    If you said DOM this versus standard (css) that…. pseudo codes (with some limits) wouldn't trash the css too offly bad per se. Anyway, my two cents. 2 more cents… to heck with IE and it's proprietary action x self–3 year plus Mozilla Suite user (some firefox lately).

  • Easy Reader says:

    Trash + DOM = Treasure?

    I was browsing the popular links on del.icio.us today and stumbled onto Nifty Corners and (via that page) More Nifty Corners. I have to say that I am incredibly impressed with the scripting, but I fear there is something wrong with this picture.
    Late…

  • […] Three separated layers, capisce? (tags: webdev bestpractices) […]

  • javascript says:

    css layer examples / properties and layer attributes
    http://css-lessons.ucoz.com/css-layer-properties….

  • HI i need your help i really want to create my own website/web page but i dont know how to go about doing it so can you please help me out

  • bdlab says:

    Hi! I was surfing and found your blog post… nice! I love your blog. Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.