NB: This page is archived without styles. Go to our home page or read our blog.
Eric Meyer's comments about my original 'What's in a name' column have prompted me draw some conclusions. My original thinking lacked depth, so I started thinking of an approach which would allow for the greatest flexibilty.
Eric Meyer's recent comments about my original What's in a name column have prompted me draw some conclusions from the comments and suggestions made on And All That Malarkey and elsewhere.
First I want to lay a few ghosts to rest. Suggesting that designers and developers follow naming conventions is not about stifling creativity. Scouring around this blog's referrer logs, I found this gem.
The layouts of CSS designed sites need to change. Not all CSS based sites are gingerbread men, but the vast majority it seems contain the same general layout. Things are becoming so common they had a naming convention. In a field that prides itself in creativity, some web designers sure are making piss poor examples these days.
It's strange that on one hand, David has misunderstood the purpose of the original column, and yet on his home page he hits the nail right on the head.
You love Latent Medium's content, but can't stand the design? Now, through the magic of CSS you can create a page that appeals to you!
Also, one commenter to the original column proposes a standard XHTML template. This does not sit well with me at all. Real-life web development for paying clients is not a Zen Garden and our content should dictate our layout, not the other way around.
Eric makes an open offer.
Does my site design not serve your needs, or bore you? Create something better suited to your tastes! I promise I won’t mind; in fact, I’d like to see what you devise.
As a designer, I would not be interested in proposing anything which limits or devalues creative flexibility, but as a web user I would sometimes like an easier way to customise the pages that I visit and as a businessman I would like to establish conventions which make my development time more efficient and therefore more profitable.
That is why I think that establishing a set of naming conventions makes sense, not because I'm some kind of Maoist revolutionary who thinks that we should all wear the same grey boiler suits, but because it can make life easier for us and our end-users. Nobody who commented seemed to disagree, except on the fine details of the names themselves and some points were raised which made me rethink both the names that I use on a regular basis.
Reading through the comments and talking to other Brit Pack designers, I realised that my original thinking was too simplistic and lacked the depth that would allow designers to extend the conventions when they needed to, but within a defined framework. So I started thinking of a multi-level approach that would allow for the greatest flexibilty, starting from the outside of the onion and working in.
For example;
Each of these elements can exist independantly from each other and refer to content rather than positioning. Designers could add a further definition, eg: #branding-(whatever), but if a search form was to be positioned 'inside' the branding area, it would be wrong to name it #branding-search as this would be presentational. A straightforward #search-input would be more appropriate.
It also makes sense to me to follow Cameron Adams' suggestion that an inner element or function comes second in the name, eg: #nav-main rather than #main-nav. The separation can be made with a hyphen or by capitalisation, eg: #navMain, at a designer's discretion.
I also think that it's worth saying that these id names don't necessarily have to apply only to <div> they can just as easily apply to other elements; <span>, <p>, <ul>, <dl> etc. to attempt to reduce further the weight of code where it is possible. They can also be used on classes if there is a need to have more than one instance of any element on a page.
OK, here goes... my latest thinking...
My main reasons for these particular suggestions were to:
So, what do you think? Does this reasoning 'work' or am I barking up the wrong tree? And even if these conventions are not definitive (and I don't suppose for a minute that they are ;) ), how can we best promote (what Eric continues to call) 'best practices' and see a set of conventions widely used?
Eric continues the discussion over at meyerweb.com.
#1 On June 20, 2004 10:03 PM David Hawdale said:
I like your reasoning Andy, and working structurally, you might extend by considering the information architects view of the world when naming the navigation elements. For example a global navigation element might exist on every page and be unchanging throughout the site indeed, thats the definition of it, so rather than calling it 'main' or 'primary' call it global.
Similarly, you might use 'local' as the term for the navigation element that is common only to that section ... another IA term.
And finally ... to move another step towards reflecting the functional defintions of the navigation rather than a simple position in the pecking order, frequently there is a nav element that contains links that are related in some way or other ... semantically most often ... and they might be 'related-links'
It would be nice to get CSS 'away from the page' and to reflect the structure of the site via the labelling of the navigation as well as the structure of the page...
#2 On June 20, 2004 10:25 PM Mike Machuidel said:
I have something similar (a dash defines the level in the tree):
site
- #siteHeader/Branding
-- #siteLogo
-- #siteSlogan (tagline might be a better name for this)
- #siteNavigation- #siteContent
-- #mainColumn
--- .entry
---- .entryTitle, .entryAuthor, .entryAuthorEmail, .entryCreated, .entryModified, .entryContent, .entryChildren. These are all optional of course.
-- #subColumn- #siteFooter/Info
-- #siteCopyrightEach non-leaf node can have a header and a footer.
An "entry" class can be anything like an article, news/updates, downloads or comments.
The "entryChildren" class says something about the amount of children under the current node. Ex. an news entry with a specific number of comments.
The "subColumn" contains links and other side information related to the content of the mainColumn.
And of course most classes can be replaced with the closest semantic equivalent.
I hope it's any useful?
#3 On June 20, 2004 11:08 PM Jake Liddell said:
A 'designer' may feel that their 'creativity' is being stifled by your suggested approach. I have to side with your view. Those of us truly considering the needs of our clients will be attempting to provide the most compelling customer experience we can. We're looking for a site that attracts the visitor, again and again.
I work hard to produce designs that people will find attractive and useable. I want them to be accessible to all, but I also want as many as possible to get a designer feel combined with true usability, from the default look that they receive when they first visit the site. I know there are some people who won't stay around for anything less.
However, if there are others out there who will only keep on coming back if they can have it their way, why would I possibly stop them from doing so? It requires no effort on my part - so it just doesn't make commercial sense not to encourage them. I can't see that my creativity is going to be stifled, when I always build some navigation, and I always build some content! It's not as if I can't define some other ids for my default style if the occasion dictates. As you say - content dictates layout. And if a designer feels creatively stifled by a bit of commonality of CSS ids, they're either having a bad day, or’ well, let's hop they're just having a bad day.
So, I think the standard ids idea is a good one. Like standard short-cut keys for accessible browsing, I think it'll be very hard to get a standard set of names into common usage, but it's a good idea. My gut feel is that your current set is a little verbose - I usually go for shorter names at the moment - to do my bit for page sizes, and to keep my typing fast. But I'd be happy to standardise on a common set, if any form of consensus is reached.
#4 On June 21, 2004 12:19 AM Jon B said:
This seems a very reasonable idea, however I see a lot of this as just 'common-sense'. I don't spend a lot of time deconstructing peoples sites to examine their naming conventions but anybody who does want to build decent sites and doesn't already employ a naming system so logical as suggested here can't be right in the head. I forgive those people only if they are foreign and spell stuff differently, otherwise they are just shooting themself, and anybody they work with, in the foot.
I like standards to a degree - standards mean guaranteed compatibility (ish) , ease of use for visitors or other developers, and just 'feels better'. But at the same time lets be grown up about it all and work towards what works best in each individual situation for both client, visitor, and fellow developers - standardising things too much can actually have a negative effect if it gets to the point when we have set predefined names and templates and layouts and then where will it end - be flexible and sensible and informed and the life will be good ;)
#5 On June 21, 2004 12:20 AM starvingartist said:
If, for instance, "#branding-logo" is underneath "#branding", isn't the "branding-" part of the former sorta a bit redundant?
For example, a subsection with a class name "section" can be applied to both "navigation" and "content" ids for example. There's no need for separate #nav-section and #content-section, when descendant selectors (like "#nav .section") could be used to apply style.
It could be a solution to the "#branding-search" vs "#search-input" example you gave above. It could also reduce the weight of the code even more.
Or it could also be a matter of personal preference on my part =)
#6 On June 21, 2004 05:24 AM Stephane said:
And I though I was the only crazy guy questioning my naming convention !
I'm always questioning my div name, should I be very specific, should main be before menu or after, etc. Of course, since I'm french, I also had the big question about should it be called #footer or ’ #bas_de_page ’...
But like starvingartist said, I tend to use #header .logo instead of #headerLogo or other similar formulation.
#7 On June 21, 2004 12:34 PM James Stevens said:
I agree - more and more of the sites I develop have taken the descriptive "content" approach to naming rather than the "position" approach.
I find it much easier to come back to a site in a few months time whilst using this approach, and moreso if the client wants to play around with or view the css it makes it much easier - as more than likely the client understands what everything is on the page, but not necessarily where it is in relation to other divs.
I can't see how a designer would ever be "stiffled" by this logical approach! This is akin to saying that a designer would be stiffled by Photoshop as he would choose to name the taskbar elements differently! It's not about the designer ultimately, it's about the end user! If the end user doesn't come back for whatever reason then the site, and the designer, has failed.
#8 On June 21, 2004 01:39 PM Erik Sagen said:
Excellent article, Andy. I'm drawn to the idea of 'branding' a site, which when you think about it, just makes sense.
Whether someone wishes to apply these naming convention methods is their choice, of course. I suppose those that feel this would stiffle their creativity would utilize other naming conventions.
However, to be honest, rarely do I dig that deep into the code.
#9 On June 21, 2004 03:36 PM Johan Sand said:
It's an interesting discussion indeed, but I'm still wondering what the reason for a global naming convention possibly could be. Who would benefit and how? I can't, unfortunately or not, find one single valid reason so far. Maybe someone could clarify the idea...
(ok, there might be a half-witted one: you can have all blogs in blogger land look like your own from your own computer, which might be fun for a second or two in lack of better entertainment (no pun intended))
On a serious note though:
Code is not for end users. Period. You could argue yourself to the moon here, but it won't change that simple fact. You may, of course, encourage your users to play around with your code, but that doesn't call for a global naming convention. You may ask any arbitrary Joe or Jane to be creative with your personal creation, it still doesn't call for a global naming convention. You may want to help newcomers understand basic principals about coding with your own code as example instead of writing a tutorial, and still there's no valid reason. You may tell your client, who just invested $45'000 in you for a new UID, that you optimized the code for even greater user interaction enabling every Schmoe to ruin months of research by simply launching their browsers...
Whatever you choose to do with your personal website is your own personal business - not global. When dealing with clients it's their business - not your personal.
So where does a "generalized" naming convention make sense? -In an organizational environment. -Wherever there's more than one individual digging around in the code. That's where such a naming convention makes sense and, which might not be a big surprise, that's where it's usually practiced. What's meaningful, however, differs from organization to organization depending on culture, policies, religion, language, business, etc (which it also does in the "Bud's Fabulous Homepage" sector).
Some have drawn parallels to programming and this much is true: we do try to utilize meaningful naming since our source often is shared with other programmers, but do we limit ourselves to, say, a set of predefined names for variables and arrays? -Of course not, then we could give up programming today since we'd be out of names a long time ago.
I'm not opposing semantics - I'm indeed in favor. I'm not saying it's a bad idea to name your elements in a meaningful manner, on the contrary - you should, but what's meaningful is and really should remain my, my team's or my organization's business and should not have to satisfy anyone other's needs or requirements.
And let's not forget what this attribute is and what roles it play:
https://www.w3.org/TR/html4/struct/global.html#adef-idBut as I started out - this is what I think. Maybe somebody actually has reasons I, and fellow "globalization skeptics", would be willing to buy into.
cheers
/j.
#10 On June 21, 2004 05:52 PM Andy Budd said:
Seems like the list is starting to come together. My only comment would be that some of the supplemental nav elements may actually appear outside the main nav element. i.e. you may want to nest #nav-main in the #nav element, but have #nav-supp outside of #nav.
Still it's looking like quite a logical grouping.
#11 On June 21, 2004 07:22 PM Jeff Hardy said:
Kudos on publishing an article that attempts to help us all agree on some sort of naming convention when it comes to semantic markup. Although no list could ever claim to be definitive, this more than a good start.
My only comment is on the use of 'container'. While this convention is commonly used, I have always found that it makes little sense semantically.
My suggestion? I use #document in place of #container. When reading code, I find that such a construct paints a clearer picture of the content contained within.
Thoughts?
#12 On June 21, 2004 08:19 PM starvingartist said:
Johan Sand: I believe the strongest argument for standardized CSS naming conventions is this statement in the post: "as a web user I would sometimes like an easier way to customise the pages that I visit."
In the hypothetical situation that everyone had the same CSS naming convention, you can apply your own user stylesheets to fit your preference.
You can, for example, apply styles to "#content-main" so that it increases font size, sets the font color to black, and the background to white, for all the websites you visit. Instantly, all the websites you come across are accessible to your own liking. Currently, it's not really possible to do this without setting up a custom style for every site you visit.
#13 On June 22, 2004 12:34 AM Michael Koch said:
Having worked in business software development for years now, I've seen similar debates over and over again. In the older days, certain programming languages forced you to include sections and declarations - even put statements into very specific columns (COBOL, for example). As these languages matured and systems development became less restrictive, these limitations fell too. Surprisingly, the result sometimes was complete mayhem. Programmers complained about "Spaghetti code" or variable names such as "$h768". After years of battling, I can now say that usually smaller IT departments/organisations tend to use longer, more descriptive names. Larger organisations (which usually require a higher level of standardisation due to their size) very often opt for the shorter, alphanumeric/mnemonic name.
I can hear you now shouting: "But CSS ain't no programming language." - and you are damn right there. But the principle remains the same for me:
Larger project or department means more need to standardise (especially if more individuals are concerned). One-man bands or projects, fewer tendecies to standardise (especially when the going gets tough).
All in all, aiming for standardisation is a good thing. But in the case of CSS's current state, I can't help but think it's a bit like asking your neighbours not to bin their garbage after a certain time at night. If lots of people adhere to it, great. But there's not a lot you can do if nobody cares about it.
#14 On June 22, 2004 12:40 AM Malarkey said:
Hi guys,
Interesting and useful comments as usual... I'll tell you why we adopted conventions at Stuff and Nonsense.
Firstly it speeds up development time by eliminating some of those mental 'conversations' that sometimes get in the way of creativity. Things like, "Ummm, now what should I call this?" ... coffee... ciggie... "Ah, I know!" It means that we can get on with designing rather than having brain-numbing code naming thoughts.
Secondly, it allows us to work from a common denominator with makes editing easier. Particularly when coming back to a site after a period or (more usually) when several members of the team work on the same project.
Lastly, it just 'feels' more organised. Just like cleaning the KFC wrappers from your car, or organising you bookcase.
Now if in doing this, we also make our documents more logical, more like XML, easier for users to customise, easier for newcomers to CSS to understand when they delve into our code, that is great too.
Hey, it ain't exactly the most important thing in the world to worry about (football is THE most important right now), but it makes sense to me.
#15 On June 22, 2004 02:46 PM Gabriel Mihalache said:
What about obfuscation?
Java programmers use obfuscators to automatically rename variables and methods to methodA, methodB, etc. so that their code is hard to steal and understand.What if we had a tool to obfuscate HTML/CSS so that the design would be difficult to steal?
#a
--#b
--#cDesign stealing is widespread. What else could we do?
#16 On June 23, 2004 01:53 PM Sam said:
All this is good and makes sense.
I myself try to keep some standards, though mostly undocumented.It is good practice and good for the long run and it makes you feel good...so trust me, I am FOR standard naming conventions.
BUT I don't see users benefiting from this, not a huge number anyway.
I haven't come across users who know CSS and will write a style-sheet to view my site. If they did, we would call them designers! And most designers would like to view the original design.
(Unless you are a pseudo-ego-maniacal-nut who wants to think that all sites have been designed by you alone!..OR maybe you are Jakob Neilson)So, has anyone come across statistics which show really how many surfers apply custom style sheets?
#17 On June 23, 2004 09:26 PM Jules said:
I can only blame you for the fact that I now check out the ids used on pages. How about these ones?
div id="kopf"
div id="kopflinks"
div id="kopfrechts"
div class="unsichtbar"
div id="mitte"
div id="haupt"
p class="abstand"In the same way that database designers and programmers are recommended to use field and variable naming-schemes that makes it clear to them and their co-workers or people who replace them what the fields/variables are to represent, I think that while there are consistencies, it is best that the web designer/developer use names that mean something to them and the organization of the page. It neither stifles nor improves creativity, it just clarifies the code.
Should there be a standard? I don't think that one should be enforced but, going along with Derek Featherstone's article about "Printing It Your Way", standardised names allow you to print and display someone else's web site/pages that meet your needs.
#18 On June 24, 2004 12:52 AM dmitry said:
The idea of standardizing layout element names is excellent, but I don't like the idea of putting semantics into what is basically a semantic free medium (HTML). This smells of a hack to me. In essence, what you are trying to do is to add meta-data to an HTML document. There are already provisions for doing this: 1) the meta tag; 2) RDF.
So if you use method (1), you'd end up with a document that looks like this:
<html>
<head>
<meta name="layout.main">//body/div[1]</meta>
<meta name="layout.header">id("banner")</meta>
<meta name="layout.footer">5</meta>
</head>
<body>
<div id="banner">
’
</div>
<div id="main_content">
’
</div>
<div id="5">
</div>
</body>
</html>Notice that the content of meta tags are either plain node identifiers as in the case of layout.footer or valid XPath expressions as in the case of layout.main and layout.footer.
One could also externalize the mapping into an RDF file with the following syntax:
<html>
<head>
<link rel="layoutmapping" href="layout.rdf"/>
</head>
’There is an obvious disadvantage to my suggestion: it's relative complexity. But it is hands down outweighed by the advantages:
1. Freeing coders/designers to choose the identifiers according to any other convention, be it a company enforced scheme or a language necessity.
2. Ability to add mapping to existing documents without having to edit content
3. Removing the dependency on CMS/portal vendors to implement the conventions.W3C's mantra's is standard reuse. Good or bad, that's their current practice and I believe it will benefit the web developer community if we try to adhere to it.
#19 On June 24, 2004 01:14 AM Malarkey said:
Wow Dmitry !
I wish I was clever enough to understand what you just said... ;)
I'm only a humble designer, so I will get my partner Peter to explain it to me. He has a brain the size of a planet too.
However, I do understand (I think) what you are suggesting. In the (soon to be beta-tested) Karova (https://www.karova.com ) site development tool and CMS, Peter has separated all web-page content into XML files (just pure structured XHTML) and creates the layout structure though XSLT style-sheets.
This means that a designer can create an unlimited number of layout structures in just one file and 'call' them at will. This eliminates the need for having any structural elements mixed in with the data.
It will make development very rapid and will take the separation of content, layout and styling to a further level. The application will also validate XML and XSLT (but not CSS) as files are uploaded to the server via the developer's control panel.
When I know more about the beta-release plans, I'll post something here. Any volunteers for beta-testing?
#20 On June 24, 2004 04:16 PM Mike Pepper said:
Couldn't agree more, mate; that's how Enigma's structured. Hmm ... you peeped, didn't you :o)
But, as you suggest, a structured template speeds development enormously and in the commercial world this means sharp delivery and commensurate costs reduction.
As to stifling creativity, no, I don't believe so; the creative aspect and associated aesthetics are the flesh on a solid skeletal structure.
I have set templates I develop from, simple but refined structures I can hang the baubles off.
#21 On June 27, 2004 08:46 AM Dom Padden said:
Developing a naming convention for CSS made sense for the company I work for (a very large applications and platform company). They are quite big on standards these days.
One part of our company makes an enterprise portal product. The CSS files are naturally customisable so that our customers can make the portal elements suit their corporate branding.
Another group makes a pattern-based browser user interface for business applications. They chose to use the same naming convention as the portal guys, so that when it appears in the portal, it picks up the portal CSS automatically, and the presentation is consistent.
If most followed the same naming convention, this page you are reading could appear as content in the portal, and follow the same design.
Although this is allowing users to choose their own presentation, which has drawbacks (as noted above) in this case it is the corporate design team who is the 'user'.
The end user simply sees a very consistent presentation. The customers' investment in design would be leveraged again and again.
My thoughts, not my employers...
#22 On June 27, 2004 12:45 PM jac said:
Its funny, I guess we're all on the same thing really and quite independently.
Ever since I started moving my agency towards XHTML/CSS, and inspired by csszengarden, its been a bit of a holy grail for me to create a default structure for our sites, so that we could - should we feel mad enough to - swap the CSS between our developments and have them work still.
Whilst this might seem pointless, the real issue for me is for creating base templates for reskinning, especially with our proprietary CMS and other user/admin applications we develop.
As such all my main creative developers have a set of templates and scripts setup in BBEdit and we tend to work back from the design and create the content as a logical 'mosaic' style site before making good with the CSS to replicate the layout. Which is kinda fun :)
But we're not too far apart, we also have our stuff all broken down like:
corporateLogo
corporateStraplineetc
And as soon as more than 2 or 3 of these sites go live, including our own which is much in need of an overhaul after 4 years [when do we ever get the time to do our own site?], then I'll setup versions with swapping CSS between the sites and see if it works ok... if it does, I'll let you know ;)
#23 On June 29, 2004 06:26 AM Bob Ryskamp said:
Hmm, how about this:
<h1>
<h2>
<h3>
<p>
<ul>
<li>
<h4>
<h5>I know it's a stretch...Seriously, I've stopped using classes and ids and now just style the HTML tags. It takes some creativity but also forces me to design in a simpler way, which users usually appreciate.
#24 On July 5, 2004 05:48 AM David said:
Hmmm, what to say. Well I should start with this, I'm not against setting up a standard set of names. I would say that I'm against a set that acts as the one and only that is correct.
In any case, I was just trying to say layouts were much too similiar for my tastes, and not trying to bad mouth your article.