Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why are dashes preferred for CSS selectors / HTML attributes?

People also ask

What is the purpose of using symbol in CSS selectors?

The '>' Symbol CSS rules will be applied to elements which are direct children of the particular element. It will target (represented with a green dot in HTML image) all the <p> tags which are immediate children of container <div>, but the children of children will not be selected (represented with the red dot).

Can HTML ID have dashes?

The HTML 4.01 spec states that ID tokens must begin with a letter ( [A-Za-z] ) and may be followed by any number of letters, digits ( [0-9] ), hyphens ( - ), underscores ( _ ), colons ( : ), and periods ( . ). For the class attribute, there is no such limitation.

Can CSS classes have hyphens?

CSS is already a hyphen-happy syntax It's natural and consistent to use hyphens for our CSS declarations and our HTML class names and IDs.

What are the three most common CSS selectors used to select HTML to style?

Simple selectors (select elements based on name, id, class) Combinator selectors (select elements based on a specific relationship between them) Pseudo-class selectors (select elements based on a certain state)


Code completion

Whether dash is interpreted as punctuation or as an opaque identifier depends on the editor of choice, I guess. However, as a personal preference, I favor being able to tab between each word in a CSS file and would find it annoying if they were separated with underscore and there were no stops.

Also, using hyphens allows you to take advantage of the |= attribute selector, which selects any element containing the text, optionally followed by a dash:

span[class|="em"] { font-style: italic; }

This would make the following HTML elements have italic font-style:

<span class="em">I'm italic</span>
<span class="em-strong">I'm italic too</span>

Ambiguity with arithmetic operator

I'd say that access to HTML elements via dot notation in JavaScript is a bug rather than a feature. It's a terrible construct from the early days of terrible JavaScript implementations and isn't really a great practice. For most of the stuff you do with JavaScript these days, you'd want to use CSS Selectors for fetching elements from the DOM anyway, which makes the whole dot notation rather useless. Which one would you prefer?

var firstName = $('#first-name');
var firstName = document.querySelector('#first-name');
var firstName = document.forms[0].first_name;

I find the two first options much more preferable, especially since '#first-name' can be replaced with a JavaScript variable and built dynamically. I also find them more pleasant on the eyes.

The fact that Sass enables arithmetic in its extensions to CSS doesn't really apply to CSS itself, but I do understand (and embrace) the fact that Sass follows the language style of CSS (except for the $ prefix of variables, which of course should have been @). If Sass documents are to look and feel like CSS documents, they need to follow the same style as CSS, which uses dash as a delimiter. In CSS3, arithmetic is limited to the calc function, which goes to show that in CSS itself, this isn't an issue.

Inconsistency with variable naming across languages

All languages, being markup languages, programming languages, styling languages or scripting languages, have their own style. You will find this within sub-languages of language groups like XML, where e.g. XSLT uses lower-case with hyphen delimiters and XML Schema uses camel-casing.

In general, you will find that adopting the style that feels and looks most "native" to the language you're writing in is better than trying to shoe-horn your own style into every different language. Since you can't avoid having to use native libraries and language constructs, your style will be "polluted" by the native style whether you like it or not, so it's pretty much futile to even try.

My advice is to not find a favorite style across languages, but instead make yourself at home within each language and learn to love all of its quirks. One of CSS' quirks is that keywords and identifiers are written in lowercase and separated by hyphens. Personally, I find this very visually appealing and think it fits in with the all-lowercase (although no-hyphen) HTML.


Perhaps a key reason why the HTML/CSS community aligned itself with dashes instead of underscores is due to historical deficiencies in specs and browser implementations.

From a Mozilla doc published March 2001 @ https://developer.mozilla.org/en-US/docs/Underscores_in_class_and_ID_Names

The CSS1 specification, published in its final form in 1996, did not allow for the use of underscores in class and ID names unless they were "escaped." An escaped underscore would look something like this:

    p.urgent\_note {color: maroon;}

This was not well supported by browsers at the time, however, and the practice has never caught on. CSS2, published in 1998, also forbade the use of underscores in class and ID names. However, errata to the specification published in early 2001 made underscores legal for the first time. This unfortunately complicated an already complex landscape.

I generally like underscores but the backslash just makes it ugly beyond hope, not to mention the scarce support at the time. I can understand why developers avoided it like the plague. Of course, we don't need the backslash nowadays, but the dash-etiquette has already been firmly established.


I don't think anyone can answer this definitively, but here are my educated guesses:

  1. Underscores require hitting the Shift key, and are therefore harder to type.

  2. CSS selectors which are part of the official CSS specifications use dashes (such as pseudo-classes like :first-child and pseudo-elements :first-line), not underscores. Same thing for properties, e.g. text-decoration, background-color, etc. Programmers are creatures of habit. It makes sense that they would follow the standard's style if there's no good reason not to.

  3. This one is further out on the ledge, but... Whether it's myth or fact, there is a longstanding idea that Google treats words separated by underscores as a single word, and words separated by dashes as separate words. (Matt Cutts on Underscores vs. Dashes.) For this reason, I know that my preference now for creating page URLs is to use-words-with-dashes, and for me at least, this has bled into my naming conventions for other things, like CSS selectors.


There are many reasons, but one of the most important thing is maintaining consistency.

I think this article explains it comprehensively.

CSS is a hyphen-delimited syntax. By this I mean we write things like font-size, line-height, border-bottom etc.

So:

You just shouldn’t mix syntaxes: it’s inconsistent.


There's been a clear uptick in hyphen-separated, whole-word segments of URLs over recent years. This is encouraged by SEO best practices. Google explicitly "recommend that you use hyphens (-) instead of underscores (_) in your URLs": http://www.google.com/support/webmasters/bin/answer.py?answer=76329.

As noted, different conventions have prevailed at different times in different contexts, but they typically are not a formal part of any protocol or framework.

My hypothesis, then, is that Google's position anchors this pattern within one key context (SEO), and the trend to use this pattern in class, id, and attribute names is simply the herd moving slowly in this general direction.


I think it's a programmer dependent thing. Someones like to use dashes, others use underscores.
I personally use underscores (_) because I use it in other places too. Such as:
- JavaScript variables (var my_name);
- My controller actions (public function view_detail)
Another reason that I use underscores, is this that in most IDEs two words separated by underscores are considered as 1 word. (and are possible to select with double_click).