Conventions You Use in Your Markup

[Michael Morris]

Curious about what conventions folk use out there and figured I'd share one that I use that helps me.

I call this the capital convention. The rule is, if javascript cares - capitalize. If not, do not. Hence classes and id's that exist solely for CSS styling start with a lowercase letter - and classes and id's that have javascript code against them are capitalized.

I still style against the classes and id's javascript cares about - the goal here isn't to try to segregate the two but rather create a visual awareness so that the design team (and myself) knows at a glance what id's and classes can be changed without repercussions in the javascript code.

Illustrative example:

<div class="inputRow Toggles ECheck">
	<div class="inputCell">
		<label>Payment By (Name)</label>
		{$receiptentry_form.ec_info_name.html}
	</div>
</div>
<div class="inputRow Toggles Card">
	<div class="inputCell">
		<label>Payment By (Name)</label>
		{$receiptentry_form.cc_info_name.html}
	</div>
</div>	
<div class="inputRow">
	<div class="inputCell">
		<label>Processing Fee</label>
		<input type="text">
	</div>
</div>	

In the css I don't have any rules for Toggles or ECheck. Basically, depending on the mode of payment the Toggles fields may be visible or invisible. The two classes let javascript rapidly find the fields in question. A designer looking at this knows that Toggles and ECheck "belong" to the programmer and styling on them probably isn't advisable (at least in this case).

What else in this vein is out there?

[RyanReese]

If you're talking about naming schemes I try to keep mine the same. I try not to use camelCase just because it's so easy to screw up. That's just a personal opinion. If I ever need to use a two worded class or ID then I'll seperate it via a dash or something.

I use the same naming scheme for Javascript too just to keep things normal.

[Stomme poes]

If I ever need to use a two worded class or ID then I'll seperate it via a dash or something.

Did Opera ever fix that issue it had with - in class names?

I avoid - both for Opera (though it may have been fixed, haven't checked the old hack relying on - in a while) and for Javascript.

[Michael Morris]

Opera fixed that a long time ago, back on version 8 or so IIRC.

Personally I don't use - or _ but use camel case but that's a personal taste thing. It's like the open vs closed mark up.

Before I used the capitalization rule I briefly tried using a leading _ to mark the javascript critical classes and ID's -- but IE 6 didn't like that too much.

Here's another convention - I indent any 'sub' declarations. Example

#header {
}
    #header a {
    
    }
        #header a:visited {

        }

Also curious to know which is more popular among css users - open braces

#header
{
   property: ;
}

Vs. the closed system, which I used in the first example and is the one I prefer.

@Ryan - So yeah, naming schemes are part of it, but also formatting conventions are part of the thread subject.

[Stomme poes]

Here's another convention - I indent any 'sub' declarations. Example

I do, though only to a point. If I'm more than or 4 indents in, I don't go further. It does help me find subs of main boxes, and pseudo classes are always indented from their regular element declaration. All first children of a particular type are one indent in. If the child has an id or classname itself and has lots of children, it starts back at left and its children start indenting.
So far as I knew, I was the only weirdo in the universe doing that : )

Also curious to know which is more popular among css users - open braces... Vs. the closed system, which I used in the first example and is the one I prefer.

In Javascript, it matters (in special cases) where you put the braces. Crockford has advocated the original C style (closed) to prevent the ambiguity of semi-colon insertion in special cases. I've always had my opening brace on the same line as the declaration element... also in my Perl, also in my Javascript.

In Perl and CSS though there is absolutely no difference. I find it harder to read open braces only because I'm not used to staring at them that way 8 hours a day, but they're fine.

Off Topic:

Opera fixed that a long time ago, back on version 8 or so IIRC.

I've never used Opera before 9. But I still have a page that used the hack.

Let's see, I've dragged it out...
if
<body class="foo-bar">
then
body[class|="foo-bar"] #element {styles;}
would only target Opera, somehow simply because there was a - in the name.

But, on my current Opera, I can't see it taking effect, so they must have plugged that one since 9.28 (the version I used it on).

[AlexDawson]

I prefer camelCase to using dashes and underscores too (in most cases), both in JavaScript and CSS, it's worked for me all these years, I'll keep going with it! As for the structure of code, I always use the selector followed directly by a space and then the { open curly braces, then the code goes on the next line (indented by one tab) and the close curl } is on the same level as the selector. I only have the {} on the same line if there's only one or two things to declare. As for sub declarations or styles (in the case of within media queries) I also indent within the indent. I find it increases the readability of the file (though it's extra bytes).

[Paul O'B]

Here's another convention - I indent any 'sub' declarations. Example

#header {
}
    #header a {
    
    }
        #header a:visited {

        }

I can see how that is very useful visually to organise things but I find it very awkward to edit quickly and make quick copy and pastes without ruining the formatting. I also like to scan the page in a uniform way and have everything aligned nicely to the left.

However, I can see the benefits of the above method but it just doesn't suit the way I work.

Also curious to know which is more popular among css users - open braces

#header
{
   property: ;
}

Vs. the closed system, which I used in the first example and is the one I prefer.

I prefer:

#header {
   property:value ;
}

However if there is only one property value I will put it on one line to make it easier to read and scan through quickly (and also remove the trailing semi-colon).

e.g.

#header {property:value}
#header2 {property:value}
#header3{property:value}

[Stomme poes]

I do the one-line thing for IE6 comments. They stand out (because they look different) and are easy for me to find.

However once IE6 gets more than one or two properties, they get newlines like everyone else.

[AlexDawson]

That's funny, I do the exact same thing Stomme (and for the same reasons). Except in my case I span all the properties on a single line for that browser.

[gary.turner]

I can see how that [indenting as for nested code] is very useful visually to organise things but I find it very awkward to edit quickly and make quick copy and pastes without ruining the formatting. I also like to scan the page in a uniform way and have everything aligned nicely to the left.

I Agree. The scheme also implies a nested structure for css, which is not the case. Cascading does not equal nesting, though the html it applies against may indeed be nested.

I prefer:

#header {
   property:value ;
}

However if there is only one property value I will put it on one line to make it easier to read and scan through quickly (and also remove the trailing semi-colon).

Almost the same here. I will indent the closing brace, simply because it injects noise on the left side where I'm scanning for selectors, and I never omit the trailing semi-colon.

I am often reminded the Paul is a very intelligent man, as he does so many things the way I do them.

cheers,

gary