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.
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.
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?
|CSS 및 이미지 네이밍에 관심있으신 분은 같이 참여해주세요. :)||이온디||2009/01/22||8350|
|13||[CSS] Get BEM||이온디||2018/12/01||39|
|12||[CSS] What’s in a name? A CSS naming convention overview||이온디||2018/12/01||61|
|11||[CSS] #tnb (Top Navigation Bar) ||이온디||2015/04/27||697|
|10||[CSS] What Makes For a Semantic Class Name?||이온디||2013/03/01||3811|
|9||[CSS] 레이아웃 네이밍 가이드 ||이온디||2012/01/19||5923|
|8||[사이트 전반] HTML 마크업 설계 템플릿(한혜진)||이온디||2010/11/03||7610|
|6||[CSS] NHN Naming Guidelines (추천)||이온디||2009/01/20||6295|
|5||NHN UI(html, css) 하드코딩 기본룰||이온디||2009/01/20||6968|
|css 네이밍 규칙 ||이온디||2009/01/20||11830|
|3||[CSS] 모든 디자이너가 해야할 9가지 CSS 원칙 (추천)||이온디||2009/01/19||6892|
|1||웹 개발자를 위한 네이밍 룰(Naming Rule) 가이드 (최현진, 2002년)||이온디||2003/11/14||9416|