Jump to content

Recommended Posts

Posted (edited)

#content {
position: relative;
width: 768px;
margin: auto;
padding-top: 20px;
}
Stuff

 

VS

 

div.content {
position: relative;
width: 768px;
margin: auto;
padding-top: 20px;
}
Stuff

 

I know functionally they both do the same thing, both elements would look identical using the code above, but what's the general census as to which way (and why) the 'proper' syntax is?

 

Going off gut-feeling, it makes more sense to me to do div.class, because you're going to have multiple different types/classes/styles of div, but then again, if I'm going to div.content, div.header, div.footer, etc, it makes more sense to #content, #header and #footer for (minutely) smaller filesizes.

Edited by Garacesh
noticed id/class was wrong in example code
Posted
#content {
   position: relative;
   width: 768px;
   margin: auto;
   padding-top: 20px;
}
Stuff

 

VS

 

div.content {
   position: relative;
   width: 768px;
   margin: auto;
   padding-top: 20px;
}
Stuff

 

I know functionally they both do the same thing, both elements would look identical using the code above, but what's the general census as to which way (and why) the 'proper' syntax is?

 

Going off gut-feeling, it makes more sense to me to do div.class, because you're going to have multiple different types/classes/styles of div, but then again, if I'm going to div.content, div.header, div.footer, etc, it makes more sense to #content, #header and #footer for (minutely) smaller filesizes.

I personally use class if I'm going to have multiple of the thing on one page, and id if it's the only one

Posted

So for example, you ran a news site or blog (assuming you wouldn't just use a CMS for it, because... reasons...) you'd do #header, #footer, and maybe #menu, but div.MenuItem and div.ArticleContent ?

(It's the only example I can think of off the top of my head lol)

 

Edit: Actually probably not the best example, 'cause you'd probably use #menu.item :doh:

Multiple ways to skin a cat and all that lot

Posted (edited)

Think of it based on the nomenclature:

 

There are many students in a class. A single student has an ID.

 

It's best practice to use an #ID to distinguish a single element on a page, and to use .class to identify multiple elements with the same formatting. Your code will not pass validation if you assign multiple #IDs on a single page, as it goes against the intended usage of an #ID.

Edited by Mako
  • Thanks 2
Posted
Your code will not pass validation if you assign multiple #IDs on a single page, as it goes against the intended usage of an #ID.

 

More to the point, often it simply will not work.

Posted
So for example, you ran a news site or blog (assuming you wouldn't just use a CMS for it, because... reasons...) you'd do #header, #footer, and maybe #menu, but div.MenuItem and div.ArticleContent ?

(It's the only example I can think of off the top of my head lol)

 

Edit: Actually probably not the best example, 'cause you'd probably use #menu.item :doh:

Multiple ways to skin a cat and all that lot

Yes, except I tend to use heavily styled ul and li for menus.

  • Thanks 1
Posted
Yes, except I tend to use heavily styled ul and li for menus.

 

Yeah, I've done them with ul/li and also with buttons&classes. Not sure which method I prefer yet. I think I'm leaning towards div/button/class if you're just loading different content on the same page (javascript toggled display: block;/display: none; ), and ul/li if it's navigating through pages (a href).

 

Or maybe I'm just over-complicating things. I tend to do that a lot :rolleyes:

Posted

Whilst there's no hard and fast rule, the accepted convention (as it favours semantics and accessiblity) is to use ul / li within a nav tag for Navigation menus. Semantic navigation with the nav element | HTML5 Doctor

 

Specific

,
and
elements were brought out in HTML5 spec to reduce the need for div.header / #header / div.footer / #footer etc, again due to semantically correct coding and increased compatibility for accessibility.

  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...