css 네이밍 규칙
첨부파일 https://eond.com/css_naming/164008

What's in a name (pt2)

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.

Focussing on the negative

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.

Focussing on the positive

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.

Building the blocks

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;

Used for a header or banner to brand the site.
Used for a site logo
Used for a strapline or tagline to define the site's purpose

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.

My suggestions

OK, here goes... my latest thinking...

Page container (usually a <div>)
Used for a header or banner to brand the site.
Used for a site logo
Used for a strapline or tagline to define the site's purpose
#nav or #navigation
Used to contain a navigation device
Main or primary navigation
Navigation to pages within the current site section
Navigation to pages outside the site
#nav-supplementary or #nav-supp
A supplementary list of links, perhaps in a footer. This can replace the common, but presentational #footer
A list of links named at a designer's descretion
Related to search interface and search results
A search form
Search results which could include a <div> or other markup including definition lists
Used for content rather than for another purpose such as navigation
The main content area
News related content
Could include any form of content, including #content-related, #content-quote etc.
Used for various site related information
Copyright information etc.
Designer or other credits

E-commerce related

An overall area containing products
Referring to individual products
Prices, discounts, special offers etc.
A summary or longer description of a product
A customer review
Could include any form of product related content


My main reasons for these particular suggestions were to:

  • Name for content rather than presentation or positioning
  • Build a structural heirarchy
  • Allow for flexibility and extensibility within a common framework

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?




코멘트 0
접기/펴기 | 댓글 새로고침
Total 14 articles in 1 / 1 pages
번호 제목 제목 글쓴이 글쓴이 날짜날짜 조회 수
공지 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) [1] 이온디 2015/04/27 697
10 [CSS] What Makes For a Semantic Class Name? 이온디 2013/03/01 3811
9 [CSS] 레이아웃 네이밍 가이드 [6] 이온디 2012/01/19 5923
8 [사이트 전반] HTML 마크업 설계 템플릿(한혜진) 파일 이온디 2010/11/03 7610
7 SideNavigationBar (x) 이온디 2009/02/21 5494
6 [CSS] NHN Naming Guidelines (추천) 이온디 2009/01/20 6295
5 NHN UI(html, css) 하드코딩 기본룰 파일 이온디 2009/01/20 6968
현재글 css 네이밍 규칙 [7] 이온디 2009/01/20 11830
3 [CSS] 모든 디자이너가 해야할 9가지 CSS 원칙 (추천) 이온디 2009/01/19 6892
2 CSS 네이밍 이온디 2009/01/14 5621
1 웹 개발자를 위한 네이밍 룰(Naming Rule) 가이드 (최현진, 2002년) 파일 이온디 2003/11/14 9416

해시태그 디렉터리