Related
TL;DR Is it a bad practice to change default display property in my CSS?
Issue
Recently, in our project we had to position 2 header tags so they would look like one. They had the same font size and similar styling so the only issue was how to place one next to another. We had 2 different ideas on that and it le do a discussion on whether or not is a good practice to change default display property
So, our very basic code
<div class="container">
<h1>Header:</h1>
<h2>my header</h2>
</div>
The outcome we would like to have:
Header: my header
Note:
The code needs to consists of 2 different headings because on mobile version we want to display them in in separate lines (so leaving default display: block).
Approach #1: Use display: inline
This is pretty stright forward. Block elements became inline so they are positioned in the same line. The disadvantage of this approach is that default display properties of both h1 and h2 were changed.
Approach #2: Use float
H1 can be positioned on the left using float: left property. This approach leaves the default display property intact, but will requires some hacks if the .container is not long enough to fit both headers in single line.
The question
It all leads to a simple question: Is it a bad practice to change the default display property of HTML elements? Is it breaking the standard and should be avoided if possible? Or is it our bread and butter and it does not really matter, as long as code is semantically correct (so headers are placed in h1, articles are placed in article etc...)
Answering your main question:
tl;dr is it a bad practice to change default display property in my CSS?
NO
WHY?
A: Because it is all about semantics
Elements, attributes, and attribute values in HTML are defined (by
this specification) to have certain meanings (semantics). For example,
the ol element represents an ordered list, and the lang attribute
represents the language of the content.
These definitions allow HTML processors, such as Web browsers or
search engines, to present and use documents and applications in a
wide variety of contexts that the author might not have considered.
So, in your case if you really need to have 2 headings semantically then you can change their styles, including the display property.
However If you don't need to have 2 headings semantically, but only for purely cosmetics/design (responsive code), then you are doing it incorrectly.
Look at this example:
<h1>Welcome to my page</h1>
<p>I like cars and lorries and have a big Jeep!</p>
<h2>Where I live</h2>
<p>I live in a small hut on a mountain!</p>
Because HTML conveys meaning, rather than presentation, the same page
can also be used by a small browser on a mobile phone, without any
change to the page. Instead of headings being in large letters as on
the desktop, for example, the browser on the mobile phone might use
the same size text for the whole the page, but with the headings in
bold.
This example has focused on headings, but the same principle applies
to all of the semantics in HTML.
** Emphasis in the quote above is mine **
P.S - Remember that headings h1–h6 must not be used to markup subheadings (or subtitles), unless they are supposed to be the heading for a new section or subsection.
With all this above in mind, here is a few (good) approaches:
If you're doing the two headings purely for design then:
add a span inside of the h1, using a media query either using mobile first approach (min-width) or the non-mobile approach (max-width).
PROs - easily manageable through CSS, changing only properties.
CONs - adding extra HTML markup, using media queries as well.
h1 {
/* demo only */
background: red;
margin:0
}
#media (max-width: 640px) {
span {
display: block
}
}
<div class="container">
<h1>Header:<span> my header</span></h1>
</div>
If you need to use the two headings semantically then:
use flexbox layout.
PROs - no need to add extra HTML markup or the use of media queries, being the most flexible currently in CSS (basically the cons from option above mentioned).
CONs - IE10 and below has partial or none support, Can I use flexbox ? (fallback for IE10 and below would be CSS TABLES)
.container {
display: flex;
flex-wrap: wrap;
align-items: center;
/*demo only*/
background: red;
}
h1,
h2 {
/*demo only*/
margin: 0;
}
h2 {
/*640px will be flex-basis value - can be changed as prefered */
flex: 0 640px;
}
<div class="container">
<h1>Header:</h1>
<h2>my header</h2>
</div>
Sources:
W3C specs - 3.2.1 Semantics
W3C specs - 4.12.1 Subheadings, subtitles, alternative titles and taglines
tl;dr is it a bad practice to change default display property in my CSS?
No. As expressed by W3C themselves; HTML conveys meaning, not presentation.
As an HTML author, it's your job to structure a page so that every section of the page carries the intended semantics as described by the documentation, so that software (browsers, screen readers, robots...) can correctly interpret your content.
As a CSS author, it's your job to alter the default styling of correct markup to present it the way you want to. This includes changing the default display properties just as much as changing the default color.
Any software can, however, decide that certain usage of CSS properties changes the way they interpret your page. For instance, a search engine could decide that text that has the same color as their parent's background should carry no weight for their ranking system.
In regards to subheadings, it's considered incorrect to markup a subheading with an <hX> element. What you should do is to decide on one <hX> element, wrap it in a <header> and wrap subheading-type text in <p>, <span> or similar.
The following is an example of proper subheadings, taken from the W3C documentation:
<header>
<h1>HTML 5.1 Nightly</h1>
<p>A vocabulary and associated APIs for HTML and XHTML</p>
<p>Editor's Draft 9 May 2013</p>
</header>
Note that there's a discrepancy between the W3C specification and the WHATWG specification where the latter uses the <hgroup> element for this specific purpose, while the former has deprecated it. I personally go with W3C's example, but most software will still understand hgroup, likely for many, many years to come, if you prefer the WHATWG approach. In fact, some argue that WHATWG should be followed over W3C when the specs differ.
In your particular example, however, I'm not sure why you chose to split the <h1> into two elements in the first place. If what you marked up as an <h1> is actually supposed to be a generic "label" for the heading, then it should probably be considered a subheading instead. If you need to split it for styling purposes, wrap the two parts of text in <span> as such:
<h1>
<span>Header:</span>
<span>my header</span>
</h1>
tl;dr is it a bad practice to change default display property in my CSS?
Its a good practice but choose carefully when to use it because it can cause some critical structure mistakes.
Why is it a good practice
The display property is open for changes. It makes HTML simple and generic. HTML elements come with a default display value that match the general behavior - what you would usually want. But they dont have to be kept and manipulated around to imitate another display property. Think about <div> for example. Obviously most of the times you want it to have display: block;, but display: flex; is much more suitable once in a while.
Lets look at a really common example of lists. <li> comes with the display property of list-item that breaks the lines for every new item.
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>
But horizontal lists are very common too. So why there is no special element for horizontal list items? Writing a special element for every common display behavior adds complexity. Instead, the convention, as also suggested by W3C is to set the <li> display property to inline.
ul li {
display:inline;
}
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>
display: inline-block; as an alternative to float
float has been used massively in page layout for many years. The problem is that it wasnt created for this task and was originally designed to wrap text around elements. A well-known float issue is that non floated elements dont recognize floated children because they are being removed from the normal flow of the document. You also cannot centrally float an element. you are limited to left or right floats only.
display is much more suitable for layout many times. display: inline-block; tells browsers to place that element inline, but to treat it as though it were a block level element. This means that we can use inline-block instead of floats to have a series of elements side by side. It is more intuitive and eliminates floats <div class="clearfix"></div> which is an additional non semantic element in your HTML.
Floats are useful when there is a need to float an element so that other page content flows around it. But there is no need to always press them into the service of a complicated layout.
Things to avoid when changing display
When you change the display property remember:
Setting the display property of an element only changes how the element is displayed, NOT what kind of element it is.
<span> test case:
In HTML early versions <span> is considered an inline-level element and <div> is block-level. Inline-level elements cannot have block-level elements inside them. Giving the <span> a display:block; doesn't change his category. It is still an inline-level element, and still cannot have <div> inside.
HTML5 introduced content models. Each HTML element has a content model: a description of the element's expected contents. An HTML element must have contents that match the requirements described in the element's content model. <span> can contain only phrasing content. It means that still you cannot nest a <div> (flow content) inside a <span>. Giving <span> a display:block; still doesn't change it.
Avoid:
span {
display:block;
}
<span>
<div>
Still Illegal!
</div>
<span>
In conclusion, changing the default display property is certainly our bread and butter. Remember that it only changes how the element is displayed, NOT what kind of element it is and use it correctly.
Now about the original two heading issue:
With respect to the comments:
Let's assume for the sake of the question, that we need to have two
headings. Or let's forget about the headings for the time being. - by the author
And also to the comment:
This question is not about resetting the display value globally. Using
selectors to target only the specific elements is implied. The
question is what we should do with these elements once selected. - by the person who set the bounty
Two headings side by side not only to handle mobile layout changes, can be done in many ways. The original example is simple and correct so its actually a good way.
h1, h2 {
display: inline;
}
<div class="container">
<h1>Header:</h1>
<h2>my header</h2>
</div>
It follows HTML rules and doesnt require any additional hacks.
Sure changing the default behaviour is redundant and even can hit performance. As a subjective solution, would recommend to use flex (but i'm not sure about performance of it, altho you can google it), it's broadly supported, and doesn't change any element css properties, it's just a layout thing, check this out
.container {
display: flex;
justify-content: flex-start;
flex-direction: column;
align-items: baseline;
}
.container.mobile {
flex-direction: row;
}
web
<div class="container">
<h1>Header:</h1>
<h2>my header</h2>
</div>
<hr />
mobile
<div class="container mobile">
<h1>Header:</h1>
<h2>my header</h2>
</div>
Notice that h1 styles stay the same
Changing default css properties is not a good idea, and should be avoided to prevent unwanted shortcomings in your markup. Instead, you should give "id" or better "class" to all html elements you want to customize and do the styling for those.
Besides, using css like "h1", "div" etc. is the slowest way as the engine try to find all those elements in the page.
In your example, it doesnt matter to use display or float as long as you give your h1 elements a css class.
Also, using correct html elements for better semantics can be useful for things such as SEO etc.
best Practice is to group the two heading in hgroup and change the display property for mobile and other views using #media query.
<hgroup class="headingContainer">
<h1>Main title</h1>
<h2>Secondary title</h2>
</hgroup>
The HTML Element (HTML Headings Group Element) represents the
heading of a section. It defines a single title that participates in
the outline of the document as the heading of the implicit or explicit
section that it belongs to.
As hgroup defines a single title for a section ,therefore changing display property within hgroup is not bed practice.
UPDATE
It seems that I might've obscured the Plunker, since Anthony Rutledge obviously failed to see (or neglected to review) it. I have provided a screen shot with a few tips on how to use the Plunker.
PLUNKER - Embed
PLUNKER - iNFO
PLUNKER - Preview
Q & A
It all leads to a simple question: Is it a bad practice to change the default display property of HTML elements?
No, not at all. Matter of fact it's a very common practice of web developers (myself included), to alter not only properties of an element, but also attributes, and it's contents to name a few.
Is it breaking the standard and should be avoided if possible?
No, but perhaps the way one goes about doing it may break the code itself which IMO is a greater concern than standards. Standards of course plays an important role but not an essential one. If that were the case, then web browsers should comply under one common set of standards (I'm talking to you IE :P). Off the top of my head, here's things that should be avoided:
Using the table element for a layout
<table>
<tbody>
<tr>
<td><img></td>
<td><input type="button"/></td>
</tr>
...
Using inline styles
<div style="display: inline-block"></div>
Using inline event handlers
<div onclick='makeASandwich();'></div>
Or is it our bread and butter and it does not really matter, as long as code is semantically correct (so headers are placed in h1, articles are placed in article etc...)
Changing an element's display property is a very small yet fundamentally essential aspect of web developing. So yes I suppose it can be considered bread and butter, which would make semantics the parsley that's used as garnish and never eaten. Semantics is subjective, a way of thinking, it is not a standard. I believe a novice should be aware of it's importance (or at least how it's important to others), but should not be pontificating between an <article> and a <section> being semantically better than using a <main> and an <aside>. In due time, semantics will just feel right.
Approach #1: Use display: inline
I have never found a good reason to use display: inline because display: inline-block is a far better choice.
Approach #2: Use float
Floats are fragile antiques. Just like handling Grandma's bone china dinner plates, you must take certain precautions if you plan on using them. Be mindful of how to clear floats and don't throw them in the dishwasher.
Basically, if given only these 2 options, Approach #1 is a better choice, especially if using inline-block. I'd stay away from floats, they are counter-intuitive and break easily. I recall only using them once because a client wanted text wrapping around an image.
CSS & CSS/JS
Provided is a Snippet comprising of 3 demos:
Pure CSS solution utilizing display: flex.
Pure CSS solution utilizing display: table-row/table-cell.
CSS and minimal JavaScript solution utilizing display: inline-block and the classList API
Each of these demos are identical on the surface:
HTML
<section id="demo1" class="area">
<!--==Pure CSS Demo #1==-->
<!--======Flexbox=======-->
<header class="titles">
<h1>Demo 1 - </h1>
<h2>display: flex</h2>
</header>
</section>
This is the original markup with the following changes:
div.container is now header.titles
h1 text is: "Demo #n"
h2 text is: "prop:value"
section#demo#n.area is wrapped around everything.
This is a good example of semantics: Everything has meaning
You'll notice at the bottom of the viewport, are buttons. Each button corresponds to a demo.
Details on how each demo works as well as pros and cons are in the following files located in the leftside menu of the Plunker (see screenshot):
demo1.md flexbox
demo2.md disply: table
demo3.md classList
PLUNKER
These notes are not for the purpose of informing the OP of anything relevant to the question. Rather they are observations that I would like to address later on.
Further Notes
Demo 1 and demo 2 are powered by the pseudo-class :target. Clicking either one of them will trigger the click event It resembles an event because it's invoked by a click, but there's no way of controlling, or knowing the capture or bubbling phase if it actually exists. Upon further clicking of the first and second button, it will exhibit odd behavior such as: toggling of the other button then eventually becoming non-functional. I suspect the shortcomings of :target is that CSS handles events in a completely different way with little or no interaction with the user.
You should use:
$('element').css('display','');
That will set display to whatever is the default for element according to the current CSS cascade.
For example:
<span></span>
$('span').css('display','none');
$('span').css('display','');
will result in a span with display: inline.
But:
span { display: block }
<span></span>
$('span').css('display','none');
$('span').css('display','');
You can use flex box to arrange elements also, like this
<div class="container" style="display: flex;">
<h1>Header:</h1>
<h2>my header</h2>
</div>
Try to read this tutorial about flex, it is really great and easy to use
https://css-tricks.com/snippets/css/a-guide-to-flexbox/
I have a super simple question, are children elements allowed to be classless in BEM CSS methodology?
So, is this code valid:
<div class="foo__label">
<p class="foo__text">Something <strong>else</strong></p>
</div>
Or maybe it should be written as:
<div class="foo__label">
<p class="foo__text">Something <strong class="foo__text-strong">else</strong></p>
</div>
I will allow myself to quote #Intervalia:
Your first example is fine. In your second example you only need to
add a class if you plan to create CSS for it. class="foo__text-strong"
is needed if you need it to be.
His comment perfectly answers your question. However I would like to add another scenario which may come in handy.
It is regarding user generated content from a CMS (worpdress for example). In this scenario the user is usually writing content in WYSIWYG editor and can not add BEM classes or even the user is not so advanced to know about them.
In this case is perfectly fine to have a "parent" element in which you can style elements by tags.
Examples:
.text ul{}
.text p{}
.text iframe{}
.text img{}
.text strong, .text b{}
.text em, .text i{}
.text a{}
UPDATE 1: Info on using nested selectors:
Nested selectors increase code coupling and make reuse impossible. The
BEM methodology allows using nested selectors, but we recommend
minimizing their use.
https://en.bem.info/methodology/faq/#can-i-use-nested-selectors
So yeah if you think it is overkill you may go with #Rene's suggestion.
UPDATE 2: Helper Classes.
The BEM methodology doesn't have strict rules for creating helper
blocks. A lot depends on specific implementations and the personal
preferences of the developer. An example of a helper block in bem-core is the clearfix block.
https://en.bem.info/methodology/faq/#can-i-create-helper-classes
Perhaps this technique can help? Personally I always have few global helpers which I use a lot.
Example, the famous Screen Reader only styles:
.sr-only{
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0,0,0,0);
border: 0;
}
In your case you can define for example .accent-color or simply .accent which can turn any element's color into red or whatever :)
You could use a cascade .foo__text strong if you are aware that:
It is not BEM compliant;
It wouldn't be possible to add a nested block with a <strong> element as a children of .foo__text.
Regarding the second point, the semantic of <p> element already has limitations. Your cascade just adds one: no <div>, no <ul> as child (because the parent is a paragraph)... and then in your case no BEM block that could have a <strong> element.
So, if you're not a purist, why not.
See also: BEM And Layout Rich Texts
Is it right, to add styles to html 5 semantics (nav, header, footer, etc...) like we add them to divs?
To use them instead of regular divs?
One time I heard frome someone I respect, that we should not add any style to html 5 semantic elements - just only if it is really necessary add a bit, but no many styles to this elements. Is he right?
for example
<nav>
<ul>
................
<ul>
</nav>
nav {
background-color: .....
width: ....
height: ......
margin: .....
color: ......
padding: ......
}
instead of
<nav>
<div id="nav">
<ul>
................
<ul>
</div>
</nav>
#nav {
background-color: .....
width: ....
height: ......
margin: .....
color: ......
padding: ......
}
How we should do it right?
What is the proper way of coding this?
What is perfect way of handling it?
The idea of separating the structure/content (you html code) from your style gives you exactly this ability, and actually drives you in this direction.
The structure gives multiple devices the ability to better understand your content in order to give your users a better experience. For example - if you will just use a ul > li structure for your menu, some devices that are not regular browsers will not be able to fully understand that this is the menu for your website, while using nav > ul > li gives them exactly that.
The style only tells the device how it should display them - and you should use it in order to give your users better experience.
The semantic elements helps us separate the structure of the page, for example:
Well, HTML5 semantic (nav, header, footer, etc...) were created to help us give meaningful and self-descriptive names to sections of our web pages. They are expected to be unique.
So, before the introduction of these semantics, sections were done this way:
<div id="main-section">
your content
</div>
<div id="sidebar">
your sidebar content
</div>
HTML5 semantics were supposed to save us from situations like the above while also being descriptive.
Styles were added to sections like the above then, and I don't see why we can't do the same now. There isn't really any rule against adding styles to HTML5 semantics but ensure that HTML5 semantics are used for unique elements in the first place.
I agree. Avoid adding styles to semantic elements. This is because these elements add nothing new when we are speaking about how things 'look'.
Remember that you want to avoid redundancy. If you need a block element, you are thinking about the 'look', and so use a div and style that. Then immediately inside that div, add your semantic element if you wish. Leave the semantic elements as hidden as possible from your css, and even from your selectors, whether in the css, or the javascript. However, adding a custom class that marks these semantic elements is good for clarity. And so, instead of:
div > * h1,
you would write like this:
div > .semanticElement h1.
This should be better for clarity, while avoiding referencing the semantic element.
If the reason for some of the above is not clear, think of it this way. The semantic changes for one element, and now suddenly I also have to make a change in the css and javascript, which is absurd.
I am new to front end development- HTML/CSS. I was playing with CSS properties: "Float" and "Position:Fixed". When I run the code(given below), i got an output where the floated text and text from #static3 div tag were positioning itself in such a way that some text got hidden behind the fixed text. To make the output appear correctly, i applied the margin property for both the float text and #static3 text. For the float text the output got corrected, but for #static3 text, the whole page moves down when i apply margin property. Both are defined under seperate "div" tag(block element), then why both of them work differently.
Please help.
HTML Code:
<!DOCTYPE html>
<html>
<head>
<title>This is a layout example page</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="CSS/Layyouts.css" type="text/css">
</head>
<body>
<div id="static1">This position changes</div>
<div id="static2">
This is some text thats using float attribute to be placed on right side while other text goes around and i need to make this text long to have a better look when this page is turned into a html page so better i write more
</div>
<div id="static3">This is a random text for the static example. There are many different ways you can use our services – to search for and share information, to communicate with other people or to create new content. When you share information with us, for example by creating a Google Account, we can make those services even better – to show you more relevant search results and ads, to help you connect with people or to make sharing with others quicker and easier. As you use our services, we want you to be clear how we’re using information and the ways in which you can protect your privacy.
Our Privacy Policy explains:
What information we collect and why we collect it.
How we use that information.
The choices we offer, including how to access and update information.
We’ve tried to keep it as simple as possible, but if you’re not familiar with terms like cookies, IP addresses, pixel tags and browsers, then read about these key terms first. Your privacy matters to Google so whether you are new to Google or a long-time user, please do take the time to get to know our practices – and if you have any questions consult this page.
</div>
<div id="static4">This is a random text for the static example. There are many different ways you can use our services – to search for and share information, to communicate with other people or to create new content. When you share information with us, for example by creating a Google Account, we can make those services even better – to show you more relevant search results and ads, to help you connect with people or to make sharing with others quicker and easier. As you use our services, we want you to be clear how we’re using information and the ways in which you can protect your privacy.
Our Privacy Policy explains:
What information we collect and why we collect it.
How we use that information.
The choices we offer, including how to access and update information.
We’ve tried to keep it as simple as possible, but if you’re not familiar with terms like cookies, IP addresses, pixel tags and browsers, then read about these key terms first. Your privacy matters to Google so whether you are new to Google or a long-time user, please do take the time to get to know our practices – and if you have any questions consult this page.
</div>
<div id="static5">This is a random text for the static example. There are many different ways you can use our services – to search for and share information, to communicate with other people or to create new content. When you share information with us, for example by creating a Google Account, we can make those services even better – to show you more relevant search results and ads, to help you connect with people or to make sharing with others quicker and easier. As you use our services, we want you to be clear how we’re using information and the ways in which you can protect your privacy.
Our Privacy Policy explains:
What information we collect and why we collect it.
How we use that information.
The choices we offer, including how to access and update information.
We’ve tried to keep it as simple as possible, but if you’re not familiar with terms like cookies, IP addresses, pixel tags and browsers, then read about these key terms first. Your privacy matters to Google so whether you are new to Google or a long-time user, please do take the time to get to know our practices – and if you have any questions consult this page.
</div>
<div id="static6">This is a random text for the static example. There are many different ways you can use our services – to search for and share information, to communicate with other people or to create new content. When you share information with us, for example by creating a Google Account, we can make those services even better – to show you more relevant search results and ads, to help you connect with people or to make sharing with others quicker and easier. As you use our services, we want you to be clear how we’re using information and the ways in which you can protect your privacy.
Our Privacy Policy explains:
What information we collect and why we collect it.
How we use that information.
The choices we offer, including how to access and update information.
We’ve tried to keep it as simple as possible, but if you’re not familiar with terms like cookies, IP addresses, pixel tags and browsers, then read about these key terms first. Your privacy matters to Google so whether you are new to Google or a long-time user, please do take the time to get to know our practices – and if you have any questions consult this page.
</div>
</body>
</html>
CSS code :
#static1{
position: fixed;
width: 100%;
text-align: center;
font-size: 24px;
font-family: cursive;
font-weight: bold;
text-transform: capitalize;
background-color: lightgrey;
margin: 0px;
}
#static2{
width: 200px;
float: right;
border-top: 2px black solid;
border-bottom: 2px black solid;
margin: 50px 4px 4px 4px;
padding: 2px 2px 2px 2px;
}
#static3{
margin-top: 50px;
}
FIDDLE
EDIT I think I understand what you meant to ask. The thing with the whole page moving down when you add margin to static3 is due to these things:
The static1 has position:fixed but not actual position properties ( top, right, left, bottom), so it positions itself relatively to the following element which is static2
The static2 element has a float:right property, therefore it is positioned relatively to static3 (its margin-top is calculated relatively to the top position of static3 and not the top of the body)
That way, all the elements in your page are positioned relatively to the position on the static3 div. When you add margin to that element, the other two recalculate their positions relatively to the new coordinates.
Old Answer
Not sure what you're trying to achieve, but if the goal is for the "article" to not be overlayed by its "title" (#static1), just add a top:0 property to #static1:
CSS
#static1{
top:0; // ADDED THIS LINE
position: fixed;
width: 100%;
text-align: center;
...
DEMO
The thing is you have to specify a position when you use position: fixed, or else the browser will understand that your element must not move from its original position, but will not necessarily render it in the desired position. Here, the browser understands that the static1 has to be rendered "at the top of static3 and then fixed there no matter what"
I am not aware of internal workings of CSS parser, but I can tell you that changing margin-top to padding-top in your #static3 section does solve the problem.
I've been there and that's how I solved my problem. Try for yourself.
How does one go about establishing a CSS 'schema', or hierarchy, of general element styles, nested element styles, and classed element styles. For a rank novice like me, the amount of information in stylesheets I view is completely overwhelming. What process does one follow in creating a well factored stylesheet or sheets, compared to inline style attributes?
I'm a big fan of naming my CSS classes by their contents or content types, for example a <ul> containing navigational "tabs" would have class="tabs". A header containing a date could be class="date" or an ordered list containing a top 10 list could have class="chart". Similarly, for IDs, one could give the page footer id="footer" or the logo of the website id="mainLogo". I find that it not only makes classes easy to remember but also encourages proper cascading of the CSS. Things like ol.chart {font-weight: bold; color: blue;} #footer ol.chart {color: green;} are quite readable and takes into account how CSS selectors gain weight by being more specific.
Proper indenting is also a great help. Your CSS is likely to grow quite a lot unless you want to refactor your HTML templates evertime you add a new section to your site or want to publish a new type of content. However hard you try you will inevitably have to add a few new rules (or exceptions) that you didn't anticipate in your original schema. Indeting will allow you to scan a large CSS file a lot quicker. My personal preference is to indent on how specific and/or nested the selector is, something like this:
ul.tabs {
list-style-type: none;
}
ul.tabs li {
float: left;
}
ul.tabs li img {
border: none;
}
That way the "parent" is always furthest to the left and so the text gets broken up into blocks by parent containers. I also like to split the stylesheet into a few sections; first comes all the selectors for HTML elements. I consider these so generic that they should come first really. Here I put "body { font-size: 77%; }" and "a { color: #FFCC00; }" etc. After that I would put selectors for the main framework parts of the page, for instance "ul#mainMenu { float: left; }" and "div#footer { height: 4em; }". Then on to common object classes, "td.price { text-align: right; }", finally followed by extra little bits like ".clear { clear: both; }". Now that's just how I like to do it - I'm sure there are better ways but it works for me.
Finally, a couple of tips:
Make best use of cascades and don't "overclass" stuff. If you give a <ul> class="textNav" then you can access its <li>s and their children without having to add any additional class assignments. ul.textNav li a:hover {}
Don't be afraid to use multiple classes on a single object. This is perfectly valid and very useful. You then have control of the CSS for groups of objects from more than one axis. Also giving the object an ID adds yet a third axis. For example:
<style>
div.box {
float: left;
border: 1px solid blue;
padding: 1em;
}
div.wide {
width: 15em;
}
div.narrow {
width: 8em;
}
div#oddOneOut {
float: right;
}
</style>
<div class="box wide">a wide box</div>
<div class="box narrow">a narrow box</div>
<div class="box wide" id="oddOneOut">an odd box</div>
Giving a class to your document <body> tag (or ID since there should only ever be one...) enables some nifty overrides for individual pages, like hilighting the menu item for the page you're currently on or getting rid of that redundant second sign-in form on the sign-in page, all using CSS only. "body.signIn div#mainMenu form.signIn { display: none; }"
I hope you find at least some of my ramblings useful and wish you the best with your projects!
There are a number of different things you can do to aid in the organisation of your CSS. For example:
Split your CSS up into multiple files. For example: have one file for layout, one for text, one for reset styles etc.
Comment your CSS code.
Why not add a table of contents?
Try using a CSS framework like 960.gs to get your started.
It's all down to personal taste really. But here are a few links that you might find useful:
http://www.smashingmagazine.com/2008/08/18/7-principles-of-clean-and-optimized-css-code/
http://www.smashingmagazine.com/2008/05/02/improving-code-readability-with-css-styleguides/
http://www.louddog.com/bloggity/2008/03/css-best-practices.php
http://natbat.net/2008/Sep/28/css-systems/
Think of the CSS as creating a 'toolkit' that the HTML can refer to. The following rules will help:
Make class names unambiguous. In most cases this means prefixing them in a predicatable way. For example, rather than left, use something like header_links_object2_left.
Use id rather than class only if you know there will only ever be one of an object on a page. Again, make the id unambiguous.
Consider side effects. Rules like margin and padding, float and clear, and so on can all have unexpected consequences on other elements.
If your stylesheet is to be used my several HTML coders, consider writing them a small, clear guide to how to write HTML to match your scheme. Keep it simple, or you'll bore them.
And as always, test it in multiple browsers, on multiple operating systems, on lots of different pages, and under any other unusual conditions you can think of.
Putting all of your CSS declarations in roughly the same order as they will land in the document hierarchy is generally a good thing. This makes it fairly easy for future readers to see what attributes will be inherited, since those classes will be higher up in the file.
Also, this is sort of orthogonal to your question, but if you are looking for a tool to help you read a CSS file and see how everything shakes out, I cannot recommend Firebug enough.
The best organizational advice I've ever received came from a presentation at An Event Apart.
Assuming you're keeping everything in a single stylesheet, there's basically five parts to it:
Reset rules (may be as simple as the
* {margin: 0; padding: 0} rule,
Eric Meyer's reset, or the YUI
reset)
Basic element styling; this
is the stuff like basic typography
for paragraphs, spacing for lists,
etc.
Universal classes; this section
for me generally contains things
like .error, .left (I'm only 80%
semantic), etc.
Universal
layout/IDs; #content, #header,
or whatever you've cut your page up
into.
Page-specific rules; if you
need to modify an existing style
just for one or a few pages, stick a
unique ID high up (body tag is
usually good) and toss your
overrides at the end of the document
I don't recommend using a CSS framework unless you need to mock something up in HTML fast. They're far too bloated, and I've never met one whose semantics made sense to me; it's much better practice to create your own "framework" as you figure out what code is shared by your projects over time.
Reading other people's code is a whole other issue, and with that I wish you the best of luck. There's some truly horrific CSS out there.
Cop-out line of the year: it depends.
How much do you need to be styling? Do you need to change the aspects of alomost every element, or is it only a few?
My favorite place to go for information like this is CSS Zen Garden & A List Apart.
There are two worlds:
The human editor perspective: Where CSS is most easily understand, when it has clear structure, good formatting, verbose names, structured into layout, color and typesetting...
The consumer perspective: The visitor is most happy if your site loades quickly, if it look perfect in his browser, so the css has to be small, in one file (to save further connections) and contain CSS hacks to support all browsers.
I recommend you to start with a CSS framework:
Blueprint if you like smaller things
or YAML for a big and functional one
There is also a list of CSS Frameworks...
And then bring it in shape (for the browser) with a CSS Optimizer (p.e. CSS Form.&Opti.)
You can measure the Results (unpotimized <-> optimized) with YSlow.
A few more tips for keeping organized:
Within each declaration, adopt an order of attributes that you stick to. For example, I usually list margins, padding, height, width, border, fonts, display/float/other, in that order, allowing for easier readability in my next tip
Write your CSS like you would any other code: indent! It's easy to scan a CSS file for high level elements and then drill down rather than simply going by source order of your HTML.
Semantic HTML with good class names can help a lot with remembering what styles apply to which elements.