As I’ve mentioned previously, I’m in the process of redesigning this web site. It’s very much a work in progress.
As a first step I’m building a pattern library and I’ve decided to open source the repo during the build process. I’m using Pattern Lab for the purpose.
In my last post, I mentioned I was trialling the SUIT CSS naming convention as I redevelop this site. More generically, let’s address why a naming convention should be used at all.
For the purposes of this post, I’m talking specifically about class naming conventions. (While one may have naming conventions for JavaScript functions, variables, and HTML IDs too, they’re not the focus of this post.)
The HTML5 Boilerplate popularised the html tag conditional classes pattern. This pattern is usually some variation of:
<!DOCTYPE html>
<!--[if lt IE 7 ]> <html lang="en" class="ie6"> <![endif]-->
<!--[if IE 7 ]> <html lang="en" class="ie7"> <![endif]-->
<!--[if IE 8 ]> <html lang="en" class="ie8"> <![endif]-->
<!--[if IE 9 ]> <html lang="en" class="ie9"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html lang="en"> <!--<![endif]-->
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
Respecting someone or their publication does not prevent one from disagreeing with them. In fact, I think to nod along saying “you’re so right, OMG, you are so right!” is less respectful than listening to and considering what they say. That dealt with, allow me to disagree with some people I respect.
Frequently, I see HTML forms coded as lists. I’ve seen this in code by some publications and people I highly respect, such as on A List Apart. The code may be:
<form action="example.php" method="post">
<ol>
<li>
<label for="itemOne">Item One</label>
<input id="itemOne" name="itemOne" />
</li>
<li>
<label for="itemTwo">Item Two</label>
<input id="itemTwo" name="itemTwo" />
</li>
</ol>
</form>Long ago, on the @soupgiant account, I tweeted:
Vaild html / css doesn't indicate your code is best practice; it may even indicate the opposite. #css3 ^pw
— Soup Giant (@soupgiant) April 29, 2010
While neither the xHTML nor the CSS on this site validates, we consider it to observe best practices.