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)
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.
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:
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.
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.
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.).
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.
Consequences? One programming language less, more uniformity and shorter learning curve.
What do you think?
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?
onmouseoutas attributes in the markup, which is what most people would do if you tell them that
:hoveris 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.
:activebelong in the CSS. But I don’t like the ideas about replacing the
targetattribute 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.
Thank you for a long comment.
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.
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.
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.
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…
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.
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…).
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.
Presentational effects (which is all you can to with <code>:hover</code> et al.) belong in CSS, if you ask me.
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. 🙂
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.
Robert, have you read my follow-up already?
I have now… 🙂
"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…
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.
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.
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.
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…
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.
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.
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.
Fair enough, and I share your concern and I agree with you entirely.
How'd you think we have different opinions, again? 😉
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! 😛
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.
Thanks for a long and thourough comment, and for contributing with your two cents!
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.
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".
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).
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.
[…] Three separated layers, capisce? (tags: webdev bestpractices) […]
css layer examples / properties and layer attributes
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
Hi! I was surfing and found your blog post… nice! I love your blog. Cheers!