: Basic semantic rules of CSS (and HTML), right or wrong? Here is the summary I've recently learnt from discussions on this site (and similar) of 4 basic rules, so please correct me if I'm wrong

@Speyer207

Element ID's

ID Styling

You can use as many ID's as it makes sense too, ID's should be treated singular classes that are not shared with any other element or class. So if you only have one slider gallery per a page then you could use #gallery however if you want to use multiple galleries then ideally you should use unique id's for both i.e #gallery -main #gallery -secondary. Then in your CSS you used shared CSS along with unique i.e

#gallery-main,#gallery-secondary{max-width:33%;}
#gallery-main{background:#000;}
#gallery-secondary{background:#FFF;}


ID Experience

You should be also aware that ID's are useful for enhancing the user experience for your users with 'go tos' i.e

<a href="#product-details">Product Details</a>
<div id="product-details" class="funkybox"> </div>


Sites that use Goto's will often have hundreds to thousands of ID's and this is completely acceptable as its improving the way people quick navigate to the content they want, without the need of additional scripts (Great for accessibility).

ID Summary

There's no such thing as too many ID's as long as it makes sense to use that many within your project.

HTML5 Article, Section, Header, Main etc.

There's nothing wrong with using DIV over article or section for validation or search rankings but for markup semantic markup it can vary from project to project and you should use whatever makes sense for your project. One site may require one articles, a few sections while another site could use hundreds of each, it really depends on the content... generally sites that are blogs and will have plenty of articles etc, while a business site may just decide to use DIV with ASIDE.

I recommend you use html5doctor.com/ and use the elements that makes sense for your project. By the way SECTION is one of the most least tags a site should generally use, in the start of HTML5 lots of people rushed in and used section to sparring for cutting up elements. Generally on HTML5 Doctor your notice a vibe that DIV is still the leading element for many reasons and you shouldn't use the HTML5 tags just for the sake of it.

Ideal Class Naming

Name classes according to the content, not appearance... This is purely down to personal opinion and dependent on your project. A big project for a large site with huge amounts of traffic should try to use shorter class names to avoid unnecessary increasing the size of both HTML and CSS.

So you could use something like:

.comment-box-below-article{}
.comment-box-below-product{}


or you could rather use a .cbba{} and .cbbp{} but again this is down to personal perf and it may vary on if your using SASS or LESS too as you could script a shorter-name for live sites, and longer names for development.

How many classes should I use?

Don't use too much classes... You should use as many classes as your project needs, there's no right or wrong here and you should use as many as you like or few as you like.

Generally using less is better, for example:

article aside {} will be better than using class names if these elements are the same across the site, but if they vary from page to page then you should opt to use classes vs element styling.

If your articles strictly use a format like so:

<article>
<header>
<h1>Article Name</h1>
<span>Something short about the article</span>
</header>
<div>
Content goes here
<aside>
<ul>
<li>Related Link1</li>
<li>Related Link2</li>
<li>Related Link3</li>
</ul>
</aside>
</div>
<footer>
Published by Blah
</footer>
</article>


Then you could use:

article aside{}
article div{}
article header h1{}
article header span{}


But then the problem can occur when you need multiple spans in the header or multiple divs and then your need to use multiple pseudo which isn't a bad thing but can get messy as the CSS gets bigger and bigger

Correct Planning

Your CSS should be planned where your site will be in the future, if you can't see the need of CSS increasing, changing then you can get away with using as less CSS class and Id's as possible, but if the site is going to get bigger, better and then you should forsee this changes and try to make the CSS as adapter-able as possible and using many class names and ID's, elements will allow this.

Vote Up Vote Down

@Shakeerah822

The “rules” are little else than opinions and coding style. They are not dangerous as such; they become dangerous if adopted as strict rules that make you deploy contrived methods and tricks just to be “pure” or “semantic” or “correct” (or whatever the buzzword is) according to your own standards.

A few examples:

a) There is no harm in defining id attributes more than you absolutely need for styling. They are not only for CSS; they are also crucial in linking, and “extra” id attributes (e.g., on every heading and every data table) let others link to specific parts of your page. In CSS, an id selector is handy for styling a specific element. However, in most cases, it is better to use a class selector (or other selector), just to prepare for the possibility that in the future, some other element might need the same styling. Not a big issue, though; it’s not that difficult to change an id selector to a class selector and add a class attribute.

b) “Descriptive elements” are coding style that is fashionable these days but does not give any tangible benefits beyond following suit (i.e., being perhaps more acceptable to your fellow designers/authors/developers). It has the definite problem of requiring extra code to make things work on old versions of IE. (Not much, but still.)

c) Class names have no impact on anything except people who read HTML and CSS (and JavaScript) source code. But it is generally better to use names that reflect the structure (and meaning) than just presentation. An attribute like class=red and a class selector like .red looks silly (and may even confuse) if the page is later styled, for some media at least, without using red color at all, perhaps even using another color for highlighting. But if you are using, say, <span class=red>♥</span> in order to display the heart suit symbol in red, it would be rather artificial to use a non-presentational class name.

d) There is no harm in setting up more classes than you need. They might help you in the future, or they might even help a visitor to style your page according to his preferences. On the other hand, inventing class names is mostly pointless if there is no specific need for class attributes. You might use class for some constructs just in order to be able to style them in a particular way if needed. But you might just as well add the attributes (and often span or div elements) when you have the need.

If you think you need a class on almost any element, then there is probably something wrong with the page design and your approach to styling.

Vote Up Vote Down

@Marchetta884

a) Use as many as you need but IDs are there for a reason and can serve a purpose. The problem with IDs is the same one might have with global variables in javascript. That one may forget the ID is used on another page causing problems cross-page while coding.

I agree with b and c.

d) will require more thought on my part but this can venture into personal preference and opinion more than fact.

To explain d) further, there are a lot of considerations about class usage for descending elements. Some may say all elements should have a unique class name so you can reference them directly for ease of use and speed of operation like so:

.myclass{}
.myclass_statement{}
.myclass_statement--highlight{}


Others say only one parent element needs a class name and we should continue with descendant selectors such as

.myclass {}
.myclass p {}
.myclass p span {}


In the first case, things can get verbose but, in the second case, you have to be concerned that someone may add a property to all span elements you aren't aware of and, thus, have a problem with the cascading of properties and specificity.

At one time, there was concern over speed of operation by the second method because browsers evaluate from right to left but this may have diminished in Chrome (at least. Not sure about other browsers).

Vote Up Vote Down