The menu uses the ultra efficient Nekkidblogger menu framework, the same as I used for the horizontal CSS drop menu. It uses an accessible, standard UL (unordered list) classed with classes for the levels of the menu. The CSS is light, simple and very fast.

Here it is. It only uses three "structural" CSS-rules for a multi-level menu (no javascript):

It is the most efficient menu there is: no complex CSS rules with long lists of descendant selectors and a clear separation between presentational and structural elements.

The menu has been tested extensively and works well in all modern browsers: Chrome, Firefox, Internet Explorer from IE 7 and up, as well as Safari and Opera. For IE6 some fixes are required. You can find these, along with the markup and CSS for this menu, in the online demo.

©2012 nekkidblogger. All Rights Reserved.

Introduction

Over the last couple of years there has been an increasing focus on Web page speed. Partly this is due to initiatives by Google and Yahoo, partly it is due to the explosive increase in web browsing on devices such as iPads and advanced cell phones (iPhone, Androids, etc).

Gradually, the focus on speed has also resulted in increased attention being devoted to more efficient CSS. Efficient HTML and CSS can help improve rendering speed significantly, not least on mobile devices with slower processors. I have done a lot of work to speed up web sites lately, and in the process I have noticed that menu systems is an area where there is a lot of inefficient CSS floating around. It turns out there is lots of room for improvements.

Markup (HTML)

What we want is a HTML/CSS menu with very efficient CSS. In the example I use a horizontal 4-level dropdown menu.

The markup is basically a standard unordered list (<ul><li>). I have highlighted the non-standard features. It has id="nekkidblogger" and each of the sub-levels (nested lists) have classes describing the level: level2, level3 and level4.

Usually lists used in menus are not styled with classes like this. However, doing it this way has some great advantages: It makes it easy to build a CSS menu with very few style rules; it allows for very efficient CSS; and provides (as a kind of bonus) convenient "hooks" (i.e. the "level" classes") for styling if one wants to style the dropdown levels differently from the top level.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

<ul id="nekkidblogger">
<li><a href="#">Link 1</a></li>
<li><a href="#">Link 2</a>
  <ul class="level2">
    <li><a href="#">Link 2-1</a></li>
    <li><a href="#">Link 2-2</a></li>
    <li><a href="#">Link 2-3</a></li>
  </ul></li>
<li><a href="#">Link 3</a>
  <ul class="level2">
    <li><a href="#">Link 3-1</a></li>
    <li><a href="#">Link 3-2</a>
       <ul class="level3">
         <li><a href="#">Link 3-2-1</a></li>
         <li><a href="#">Link 3-2-2</a>
            <ul class="level4">
              <li><a href="#">Link 3-2-2-1</a></li>
              <li><a href="#">Link 3-2-2-2</a></li>
            </ul></li></ul></li>
  </ul></li><li><a href="#">Link 4</a></li>
</ul>

On the right it is shown without styling. This is a standard unordered list. The <ul> for the overall menu has id=”nekkidblogger”. It has four top level links, and under Link 3 there are three dropdown levels. This is more than sufficient for a demonstration – there is no need to fill it up with lots of dropdown elements.

So now we are ready to give it structure and style!

CSS for the Nekkidblogger menu

One of the keys to efficient CSS is to use the "cascade" as much as possible – to allow "child-elements" to inherit as much as possible from "parent" elements. So here I don’t define selectors to the extent that I can avoid it. Also, I try to only style elements once, and then let inheritance take care of as much as possible.

In the following I mark the rules that are structural (makes the menu work as it should) as “Rule” and the presentational style rules as “Style” in order to clearly separate the two.

#nekkidblogger ul {padding:0;margin:0;} (Style 1)

This isn’t really part of the menu, but useful for setting the context. If you use a CSS reset, you don’t need this. Also, you may prefer simply ul, li {padding:0;margin:0;}. I use the more specific reset here (for the "nekkidblogger"-id only) since this is a blog where the general rules have been set for other purposes.

The Top level

#nekkidblogger li { list-style:none; position:relative; float:left;
    text-align:center; margin-right:5px; font: 10px verdana,
    sans-serif; } (Rule 1)

This is the first structural rule of the menu. Here "list-style", "position" and "float" are necessary structural elements, while "text-align" and "margin" are presentational. Note that I style the a-selector, not the <li>. The <li>-element adapts to its content – so we don’t need to define a "width" here for example.

#nekkidblogger a { display: block; width: 8em; color: black;
     line-height: 30px; text-decoration: none; background: silver;
     border:1px solid #fff; margin: 0 -1px -1px 0; } (Style 2)

Here everything is presentational. "display:block" is important in order to display the links as boxes. "width", "height" and the rest is styling. I set the properties of the links here, and then they are inherited by the sub-levels. In your own menu, you may want to style the dropdowns as well.

#nekkidblogger :hover > a { background:#7B7B7B;
         color:yellow } (Style 3)

This is a presentational element only – we don’t need to set different properties for the hover state – but most often one does that in menus to make them look better. Here I style the hovered link as well as the whole hover path instead of just the hovered link (one usually uses simply "a:hover"). I picked up and adapted this neat little trick from the excellent CSS experiments by Stu Nicolls.

What we have done so far (we have also "set the stage" for the lower levels):

• Link 1
• Link 2
• Link 3
• Link 4

Second and lower levels

The rest is purely structural – no presentational elements, as I simply let the lower levels of the menu inherit everything, including the hover state (see Style 3). However, I will show you how you easily can style the lower levels yourself if you want to:

A. Style the boxes

The classes ".level2-.level(n)" provide "hooks" that you can easily use to format the lower levels.

We could, for instance, give a different style to level two and the lower levels – just style ".level2" and let the lower levels inherit. Or we could style each level separately. For instance:

#nekkidblogger .level2 a { background: #FFF; height: 25px; etc .. }

And/or, we could style the lower levels like so:

#nekkidblogger .level3 a { ... }

#nekkidblogger .level4 a { ... }

OK. Back to the nekkidblogger menu:

B. Position the dropdown boxes

The top level is horizontal. We want to drop the second level down vertically from it. We have defined the <li>’s to be relative, so now we position the dropdown (.level2) in relation to them:

.level2 { position:absolute; top:30px; left:0;  }  (Rule 2)

Here "left:0" is default in the good browsers, so we should not need to specify it, but as it for some reason is not so in IE (surprise?), we still must. 30px is the line-height – see Style 2.

The next two levels – level 3 and level 4 – we want to fly out to the right of level 2. 8 em is the width of the a-element (see Style 2). I add .08em (about 1px – the width of the border) for good alignment. So:

.level3,.level4 { position:absolute; top:0; left:8.08em; } (Rule 3)

C. Dropdowns: Hide and make visible when hover

.level2,.level3,.level4 {visibility:hidden} (Rule 4)

We need to hide all levels separately – if we let "hidden"-property be inherited, then the "visible"-property will be too, and all levels would show up when we hovered a given level. Also note that if you want to add another level or two to the menu, all you need is to insert the correct classes in the HTML for the list and then add ".level5, .level6" in Rules 3 and 4. So adding N more levels, using the Nekkidblogger menu framework, does not add to the complexity of the CSS.

#nekkidblogger :hover > ul { visibility:visible; }(Rule 5)

Makes the child elements of a <ul> visible when <li> is hovered (but only the child-elements, not the "grand-children"). And that’s all!

Here is the menu:

Final remarks

So, that’s it. Five "structural" CSS-rules for a multi-level menu (The “Style”-rules are purely presentational). The rules are also comparatively very simple, mostly very short, and computationally effective (good for fast page rendering) with minimum use of descendant selectors.

If you examine the live demo with Google’s Page Speed (using Firefox), and look at the use of efficient selectors, you will find that it has "0 very inefficient rules, 0 inefficient rules, and 2 potentially inefficient uses of :hover". The "potentially inefficient ones are Style 3 and Rule 5, but they are as simple as can be.

If by comparison you run Page Speed on the Son of Suckerfish menu with three dropdowns, which is a very widely used menu and which was published in A List Apart, you will find that it has "7 very inefficient rules, 5 inefficient rules, and 5 potentially inefficient uses of :hover". So, there is a difference. And if Google’s Page Speed is worth anything, and if page rendering speed matters, it may well be a difference that matters.

The Nekkidblogger menu has been extensively tested, and works in all major browsers: Chrome, Firefox, Internet Explorer from IE 7 and up, Safari, and Opera. In the demo I give some more detail and show the fixes necessary to make it work in IE 6.

See Copyright and Terms and Conditions, on demo page, sidebar 1.

PS: In later posts I’ll show how to make the rightmost flyouts fly left and how to convert this horizontal menu into a vertical CSS menu by changing only tiny bits of CSS.

©2012 nekkidblogger. All Rights Reserved.

I have just completed a new three column CSS layout designed to be extremely robust and flexible. The major DIVs are build outside in to prevent column overflow, and the layout is designed to degrade very gracefully in narrower viewports. Give it a test by clicking the demo (below is just an image) – see how the header splits and the sidebars fold under one another as you make the viewport narrower.

It’s designed for ads in the header and 25o px wide ads in the middle sidebar. Have fun!

You can get the markup and the CSS by viewing the source of the demo!

©2012 nekkidblogger. All Rights Reserved.

Introduction

The Suckerfish menu, first published in A List Apart in 2003, was a major achievement. The authors, Patrick Griffiths and Dan Webb, showed how to build a horizontal dropdown menu with very efficient CSS. It is often referred  to as a CSS-only menu. For browsers that didn’t support the “li:hover” (Internet Explorer – IE – 6, of course), the authors provided a JavaScript that made the menu work even there.

Markup (HTML)

A standard unordered list (<ul><li>). It has class="barmenu".

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

<ul class="barmenu">
	<li><a href="#">Link 1</a></li>
	<li><a href="#">Link 2</a>
<ul>
	<li><a href="#">Link 2-1</a></li>
	<li><a href="#">Link 2-2</a></li>
	<li><a href="#">Link 2-3</a></li>
</ul>
</li>
	<li><a href="#">Link 3</a>
<ul>
	<li><a href="#">Link 3-1</a></li>
	<li><a href="#">Link 3-2</a></li>
	<li><a href="#">Link 3-3</a></li>
</ul>
</li>
</ul>

CSS (with comments)

The Suckerfish

The logic of the Suckerfish menu has since been used widely to build menus for web pages. The core of it was provided by the authors in a barebones version. The Suckerfish dropdown menu uses the following 5 rules to do the job (I have included their original comments as well):

ul { /* all lists */
    padding: 0; margin: 0; list-style: none; } (Rule S-1)

li { /* all list items */
     float: left; position: relative; width: 10em; }(Rule S-2)

li ul { /* second-level lists */ display: none;
     position: absolute; top: 1em; left: 0; }(Rule S-3)

li>ul { /* to override top and left in browsers other than IE,
  which will position to the top right of the containing li, rather
  than bottom left */ top: auto; left: auto; } (Rule S-4)

li:hover ul, li.over ul { /* lists nested under hovered list items */
     display: block; } (Rule S-5)

That’s it. Five CSS rules for a dropdown. This was a major achievement at the time it was published – neat, simple, orderly rules and very cross-browser compatible. The question is: Can it be improved on now, almost ten years later, with more standards-compatible browsers and with IE 6 more or less out of the picture? As of July 2011 IE6 is used by 2.3% of users. And IE7 is used by a little more than 4%!

Modern CSS dropdown – barebones

In the following rules you can take out the “.barmenu” if you want – I just need to use a “class” here because I have other menus and other unordered lists in this blog, so that I need to use more specific rules.

.barmenu ul, .barmenu li { /* all lists */
	padding: 0; margin: 0; list-style: none; } (Rule 1)

.barmenu li { position:relative; float:left; width: 5em;
    padding:0 0 1px; } (Rule 2)

I usually style the link element rather then the <li>, but since I don’t style I simply give the <li> a width here. This should go out when the menu is styled. The strange padding is explained below (under Rule 4).

.barmenu li ul { position:absolute; visibility:hidden;
      top:20px; left:0; }(Rule 3)

I usually use use “visibility: hidden” and “visibility: visible” to hide and unhide the dropdown. “Visibility” was introduced in CSS2 and is well supported today. I could also have hidden the dropdown outside the viewport, positioning it absolutely at -999em, which today is another standard method. Or, I could have used “display:none”. As it turns out, all the three ways of doing it encounter similar problems in IE7 and IE8.

“top” and “left” above are needed for IE7 and IE8, the modern browsers (Opera, Chrome, Firefox, and Safari) do not need them. The modern browsers seem to assume “left:0″ and a vertical offset equal to the current line height – both reasonable assumptions. IE, on the other hand, assumes 0 vertical offset and a default margin <ul> or <li> offset, which simply is odd.

.barmenu :hover > ul { visibility: visible; margin-top:-1px;
  background: #FFF; }(Rule 4)

(PS 9/23/2011: I have revised and changed .barmenu li:hover > ul to .barmenu :hover > ul.) This rule makes the child elements of a <li> visible when <li> is hovered. Note that “visibility:hidden” reputedly leads to “performance problems” in IE7 and IE8, while the modern browsers seem to handle content hidden with “visibility: hidden” quite well.

However, it also contains two “fixes” for IE7 and IE8. The first is “background: #FFF”. This is not included to give a background (I use white – #FFF – here anyway, so the menu inherits that) – it is there to make the display of the dropdown stable and scrollable in IE7. Without background the submenu appears as long as the mouse hovers over the parent menu item, but once you move the cursor down over the submenu, the submenu disappears. This is not what we want.

I have spent many hours tesing various fixes to this. The usual fixes for IE problems, such as “zoom:1″ or “height:1%” don’t work here. But background does – either a color or a background image. Omer Greenwald at webtechwise.com uses a transparent background image as a fix, and that seems to work just as well.

The other fix used here, which also seems to be required for IE7, is to make certain that the top menu and the dropdown actually “touch” one another. If there is a one pixel gap, the dropdown will disappear when you move the cursor down and over the “gap” to click the submenu items. The fix for this is to include a padding of 1px at the bottom of the <li> (Rule 2) and then use a negative margin of 1px to move the dropdown up into the top menu (Rule 4).

It is somewhat interesting to note that if you move the dropdown a little too far down – for instance “top:25px” – the problem returns.

Note that most of the fixes for IE used here are specific to a barebones menu. Once you style the menu, the dropdown is likely to actually touch the top level menu, so that problem disappears. And when you give color to the background – which you probably will – you take care of that issue too. (To the right is the list before we apply CSS and turn it into a menu.)

OK. That’s it. One rule less than the Suckerfish menu, and we don’t need any java if we don’t support the soon to be gone IE6. It works as intended in all major browsers as well as IE8 and IE7. To make it work in IE6 will require rewrites, as IE6 does not support the child selector > that I use here. It will also require JavaScript as IE6 only supports the hover property on links, not on lists and other elements.

Here’s the menu:

So that’s it. Four CSS-rules for a dropdown menu – and one of the rules a reset rule (Rule 1). If you have resets in place in your CSS, you probably don’t need it. So, three rules really. That’s all we need with modern browsers! But then, of course, lots of fixes for the older versions of Internet Explorer. What a huge waster of web designer man hours those browsers have been.

Basic styling

Usually one styles the links rather than the <li>-items. The advantage is that  by doing it this way, one increases the clickable area of the menu. The <li>-items don’t need styling – they simply adapt to the space required by the content.

.barmenu2 a { display: block; width: 5em; color: black;
  line-height: 25px; text-decoration: none; background: silver;
  text-align: center; } (Rule A)

I need to use a different class, as I display both menus here.

.barmenu2 a:hover { background: #7B7B7B; color: yellow; } (Rule B)

If you want to style the dropdown (I don’t do it here), you can use:

.barmenu2 li ul a { something .. }, and
.barmenu2 li ul a:hover { something else } (for the hover)

And that’s all. So now I can remove the various fixes (in Rules 2-4) from the barebones example. The only ones I still need are “top:25px” (adjusted to 25px as that is the height now) and “left:0″. I’ve also taken out the width in the <li>-rule:

.barmenu2 li{ position:relative; float:left; } (Rule 2)
.barmenu2 li ul { position:absolute; visibility:hidden;
    top:25px; left:0;  } (Rule 3)
.barmenu2 :hover > ul { visibility: visible; } (Rule 4)

A useful tip on styling menus with hidden dropdowns or flyouts is to simply comment those parts that hide it out and style the menu with the whole menu visible. Here that would simply mean to comment it out like so /* visbility: hidden; */ in Rule 3. When done, you simply remove the comments.

OK. Here is the menu:

So there it is with some basic styling. Now it works just fine in all browsers, including IE7 and IE8. See the demo with source and CSS.

Stay tuned for much more on menus!

©2012 nekkidblogger. All Rights Reserved.

I’ve been looking into forum software lately. I want to set up a couple of discussion forums. It seems to me that the most highly recommended among the free, open source bulletin boards is phpBB, now in version 3 – phpBB3.

So I’ve installed it on a test site and have started to work with it. And, so that it’s said, the core functionality of phpBB3 is excellent! Really outstanding. It’s an excellent bulletin board. And there are a lot of good folks in the community doing an excellent job in developing good mods. However, being used to working with WordPress, I have to say I was shocked. Completely. WordPress is so geared towards making it easy to use. By contrast, with phpBB3 everything is so 1980s: Installing it is OK, not as easy and quick as WordPress, but still not too complicated either. But there it stops.

First of all, the whole attitude surrounding phpBB, including the new phpBB3, is old fashioned: It’s made by people who can write programs using HTML, CSS, PHP and MySQL for people who can do all the same things. The attitude seems to be that if you can’t do that, you shouldn’t be using the software. Very little is done, compared to WordPress, to make is easy to use.

In WordPress, we have become accustomed to automatic upgrades – just click a button for upgrade, and the system upgrades itself, including the databases. Same thing with themes and plugins: Search for a theme or plugin, find it, read the docs and user reviews, decide you want it, click install, and once installed click “activate” and it’s up and running. Smooth. Nice. Easy for people who can’t program in PHP and/or don’t want to mess with MySQL.

With phpBB3 it is still 1980-something. There are mods. But you have to either download them to your PC, unpack them, upload them to the site, and install them manually or use something the good folks at phpBB call a “mod-manager”, called “Auto-Mod“. Now, manually really means going in and manually changing PHP-files and into MySQL and running scripts or instructions to create new tables, alter existing ones and the like. Very tedious. And you can make mistakes that may have serious consequences and can cause lots of grief.

But the mod-manager is tedious too! If you are patient and finally manage to find the instructions for installing it, you will find that they are OK for programmers but make no sense for non-programmers. They say, for instance: “After uploading the files, you need to run the install script.” Which script? They don’t say precisely. How do you run it? They don’t tell. Lots of people will give up at this point. Why isn’t it simply integrated in the install of phpBB3? If the plugin and theme installers hadn’t been integrated into WordPress, they probably would have had tens of millions fewer users.

I actually installed it, and used it to install another mod. Even with the auto-mod installer in place, the instructions still said I had to download and unzip the mod and then upload it to my server. Did all that, navigated though poor instructions again, installed a mod and ended up with more than a screen-full of so-called “do-it-yourself”-instructions, which required me to move files, edit PHP-code, and run MySQL-script. What’s wrong with these folks? Auto-installation and auto-upgrading is expected by everyone everywhere these days. No only does WordPress do it – even Microsoft and Adobe manages that! This really sucks big-time!

Using the auto-install was scary business as well. I’ve tested it out with two mods. The first one crashed my board – I just got a white screen and could not get into it even through back-doors, so I had to wipe and re-upload all system files. The second time I tried, I got the message that the install was “successful”, but every time I wanted to go back to the forum I got messages that files were missing, so I ended up having to upload 10 or so files manually before it started to work again. Not so good!

There is no objective reason why phpBB3 couldn’t be as easy to use as WordPress. WordPress plugins and updates overwrite and install new PHP-files and modify the MySQL database. It’s quite possible – as WordPress demonstrates – to do it. But the emphasis on user friendliness is not nearly as high among the good people developing phpBB, so the standards for it have not been developed and aren’t pushed as they are with WordPress. Another sign of the same lack of standards for user friendliness is that many mods conflict with one another: It’s a big mess for people running the boards, but quite easy to avoid if you devote attention to it.

I was also shocked by the lack of emphasis on SEO in phpBB3. It writes URL’s like this: “http://example.com/viewforum.php?f=3&sid=f00744bc867aec5bc739f4ee59364726″ (NB: Not a working URL). Not a very search engine friendly URL, if you ask me. Totally 1980s and totally bad from a Search Engine Optimization (SEO) point of view (also a dimension where WordPress really excels, by the way). Using URLs like that is almost like telling Google “I want to be invisible” or “Please don’t list me on any of the first 20 pages of search results”. To most webmasters today, being found in by the search engines is imperative. In the 1980s it wasn’t.

For sake of comparison, on another test site I installed WordPress with the bulletin board plugin bbPress. A few clicks, and there it was, up and running. And right out of the box it produces URLs that look like this: http://www.examplesite.com/forums/forum/recent-seo-software-news/ (NB: Not a working URL). The core functionality is not nearly as good, but it will get traffic from the search engines.

Also, if you want to change something, like put in place a new header image or alter the layout, it’s a lot of work. The system more or less forces you to do the changes online, while logged in, in a pretty poor editing window without, for instance, search capability. A couple of days ago I sat for hours editing a CSS-file more than 2500 lines long. Without a file-search facility available, that means scrolling up and down hundreds of lines to find the class or id one wants to modify, finding perhaps the color definitions at line 2300 or something and other styles for it at line 350 or whatever – that’s bad. And it’s boring too. And it could have been easy to fix – if user friendliness was a concern, that is.

Of course and predictably, I ended up scrapping the header that came with the system and creating my own from scratch. It simply was easier – but that’s not how it ought to be.

So, there you have it, an excellent program that has a long, long way to go in terms of user friendliness and that has been built with an old-fashioned and out-dated philosophy, so that the platform in reality is its own worst enemy. From the outside it looks like a project and community in need of a clearer vision, better prioritizing and improved leadership.

©2012 nekkidblogger. All Rights Reserved.

Thesis 1.8 uses DOCTYPE 1.0 Strict. This is fine if that’s the right DOCTYPE for the content of your WordPress blog. Otherwise you may want to change it. If you do, there are mainly two options available to you:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE HTML>

The first is 1.0 Transitional, and the second and much shorter DOCTYPE declaration is HTML 5. You can read a little about the advantages and disadvantages of each in my previous post about how to change DOCTYPE in WordPress, which also has links to more informative articles.

Changing DOCTYPE in the Thesis theme is a little different from changing it in other themes but just as easy. There are two ways to do it.

Using custom_functions

Go to the file “/wp-content/themes/thesis1_8/custom/custom_functions.php”. Make a backup of the file. First, for 1.0 Transitional, copy and paste the following into the file and replace the file.

/* !Custom Doctype */
function custom_doctype() {
    return '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">';
}
add_filter('thesis_doctype','custom_doctype'); 

To change the DOCTYPE to HTML 5, copy, paste and then replace the file after adding the following:

/* !Custom Doctype */
function custom_doctype() {
    return '<!DOCTYPE html>';
}
add_filter('thesis_doctype','custom_doctype'); 

And that’s it. I’ve tested both, and they both change the DOCTYPE the way they should.

Changing “frameworks.php”

The second, and “cleaner” way to change the DOCTYPE of a Thesis 1.8 WordPress blog, is to edit one of the “core” files of the Thesis framework, the file “frameworks.php”. This is the file that actually assigns DOCTYPE 1.0 Strict in the first place, so changing the DOCTYPE declaration at this point is in a sense more correct, and also cleaner (as you will see), especially in the case of HTML 5. I used this method to change to 1.0 Transitional for this blog.

First, you need to open the file “/wp-content/themes/thesis1_8/lib/html/frameworks.php” (it’s smart to make a backup before you edit it). On the very top of the file you see:

	echo apply_filters('thesis_doctype', '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">') . "\n";
?>
<html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>

1.0 Transitional

For 1.0 Transitional all you need to do is to copy and paste the Transitional DOCTYPE declaration given at the beginning of this post into the first line above (between the apostrophes), like so:

	echo apply_filters('thesis_doctype', '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">') . "\n"; 

Then save the file, clear the cache if you use one, and check it.

HTML 5

The correct way to change into DOCTYPE HTML (HTML 5) is to change both the first and the second line in “frameworks.php”. The reason is that the <html>-tag in the HTML 5 DOCTYPE is different from the ones for 1.0 Strict and 1.0 Transitional. It is simply an empty tag or a tag that defines language, that is either simply <html> or something like <html lang=”en”>.

So now you replace both the lines with the following:

	echo apply_filters('thesis_doctype', '<!DOCTYPE html>') . "\n";
?>
<html <?php language_attributes(); ?>>

Again, save the file, (clear the cache) and check the result.

That’s it. Good luck!

PS: Full disclosure: May I add that I am a great fan of the Thesis theme, and use it on several sites. I am also an affiliate of DIYThemes because I use it and like it. It’s a theme I recommend – fast, easy to customize, and with good support:

©2012 nekkidblogger. All Rights Reserved.

Most WordPress blogs seem to use either 1.0 Strict or 1.0 Transitional. This makes some sense, given that the WordPress engine unfortunately delivers output in XHTML rather than HTML format. Because of this, pure HTML doctypes, such as DOCTYPE 4.01 Transitional, are not good choices for bloggers using WordPress for the moment.

However, HTML 5 is also an alternative, as it’s syntax is compatible with WordPress: The Twenty Ten theme that was distributed with WordPress 3.0 used DOCTYPE HTML (HTML 5).

In WordPress, DOCTYPE is set by the theme. The developer may choose DOCTYPE on the basis of personal preference or what he or she is most used to working with. Many developers prefer DOCTYPE 1.0 Strict. Some do it because 1.0 Strict means the code meets very strict quality standards. Which, of course, is good news for people wanting to use the theme and probably works as a sales argument.

However, regardless of the choice of the theme developer, it is ultimately the coding style and preferences of the people using the themes in their blogs that determine which DOCTYPE is the right one for a particular blog. If the blog posts are written in a style that is more compatible with 1.0 Transitional, then the DOCTYPE should be transitional as well. If the blog uses plugins and features that are in HTML 5, then most likely the DOCTYPE for the blog should be HTML 5 as well. As the respected WordPress developer Alex King says:

The main reason we choose to use XHTML 1.0 Transitional for our WordPress themes is simple: we have no idea what someone might decide to do with it.

It doesn’t matter if the theme validates strictly if the content doesn’t – and with all of the great tools and widgets available for WordPress, it’s pretty easy to add something that breaks your strict validation.

This is something you should consider if you’re a theme developer. Don’t just think about the code you’ve written to build the theme, think about what people using your theme will be doing with it; and make the best choice you can.

The point here is not that Alex King prefers 1.0 Transitional, but rather his argument that it doesn’t matter if the theme validates if the content doesn’t – meaning that the most important thing is that the DOCTYPE is right for the blogger and the content of the blog. (See also Fix Your Site With the Right DOCTYPE! by Jeffrey Zeldman.)

The choice of DOCTYPE, therefore, is a choice you – as a blogger – should make. It is also a choice can you make, as it is fairly easy to change the DOCTYPE of your WordPress blog.

DOCTYPES

W3C has a complete list of recommended Doctype declarations, but here are the three most likely and most suited candidates for WordPress blogs:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE HTML>

The first is 1.0 Strict, the second is 1.0 Transitional, and the third and much shorter one is HTML 5.

Which one to choose is up to you. I use 1.0 Transitional on this blog. Elsewhere I use 1.0 Strict. And I am about to move a couple of blogs over to HTML 5. What I run depends on the content and what I do in a blog or website. In this blog I have some stuff that has deprecated HTML tags, so 1.0 Transitional suits me best. On another blog I have some plugins that will not validate unless I move to HTML 5, so I will do that. The way I see it, the choice of DOCTYPE is a pragmatic choice, one of convenience, not a deep principled choice of coding philosophy. Other people may have a different take on that.

Some references if you want to learn more about DOCTYPES: HTML5 differences from HTML4 (W3C), Dive into HTML by Dave Pilgrim gives a nice overview of HTML5, see also Put XHTML 1.0 Strict and Transitional to work, HTML/XHTML Elements and Valid DTDs

Why not 1.0 Strict

From a purist point of view it can be argued in favor of other DOCTYPEs than 1.0 Strict. As most browsers actually parse XHTML documents as “text/html” and the state of XHTML is somewhat less than unproblematic on the net (see Beware of XHTML), there is little reason to prefer Strict 1.0 for parsing or rendering reasons. Also, if you want it to, HTML is no less “clean” than XHTML – you can code in lowercase, close all the tags and so on if you want.

From a more practical point of view, 1.0 Transitional or HTML 5 will in many cases be better choices than 1.0 Strict for bloggers:

1. They both allow some tags that are not allowed in 1.0 Strict (deprecated elements and attributes), such as “target=_blank” (“target=”_blank” will not validate, but still works just fine in Strict – the browser makers are more pragmatic than W3C)
2. The 1.0 Transitional and especially HTML 5 DOCTYPEs provide better platforms for use of embedded multimedia objects such as video and music in blogs and websites
3. Some of the social media plugins in WordPress (Facebook-plugins especially) will work but not validate unless the DOCTYPE is HTML 5.
4. If you have ads in your blogs, many types of ads will create huge numbers of validation errors in 1.0 Strict (Amazon ads and links will do that regardless of DOCTYPE – the W3C validator (and some other ones as well) has an hysterical fit when it sees an ampersand – & – that isn’t written as &, but again the browsers render correctly in this case as well, so you can overlook the validator if you want to)
5. Also, keep in mind that many ads use the “iframe”-tag. This tag is not permitted in 1.0 Strict or 1.1 XHTML. Neither is it permitted in HTML5. So if you have this type of ads, you may want to change the Doctype to 1.0 Transitional.
6. I suspect many users of WordPress do not and will not adhere to the requirements of Strict 1.0 – e.g. do not close all tags properly, place inline styles in their posts and the like.

There are many other reasons for changing to another DOCTYPE, but these are the ones I view as the most important. But see also Why Transitional Doctypes are Better for WordPress Blogs

How change DOCTYPE in your WordPress blog?

You need to use either the built-in theme-editor in WordPress or preferably an editor on your local machine and a FTP-program. The file you want to modify is in the WordPress directory where your theme resides and is most often called “header.php” (e.g. “/wp-content/themes/(“name of your theme”)/header.php”). The first thing to do is to make a copy of this file as a backup.

In one of the themes I use the first line in header.php is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

In this case all that is needed is to copy and paste the exact code for the DOCTYPE I want to use from the listing above instead of this one (you want to copy and paste, as it is imperative that the letters are exactly the same), save it and replace the old “header.php”.

In the default WordPress 3.0 theme TwentyTen it looks like this:

1
2
3

?><!DOCTYPE html>
<html < ?php language_attributes(); ?>>

This declares HTML 5, and here it is a matter of replacing the text after ?> (which is part of the PHP) on the first line with the DOCTYPE we want, for instance like so:

1
2
3

?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

and leave the second line as it was. Again save (and replace on the server), and all is well.

That’s it. Look in “header.php”, find the DOCTYPE declaration, carefully replace it with the one you want, save and replace it on the server, and there you go. If you can’t find the DOCTYPE declaration in the “header.php”, you may need to look in other php-files or get in touch with the developer of your theme. But most often you will find it there.

©2012 nekkidblogger. All Rights Reserved.

In a previous post I wrote that for WordPress 3.1 and beyond I would like to see speed increases – blogs that are meaner and leaner, that load faster. Now it seems I will get what I want. In the WordPress Development Blog, Mark Jaquith writes that the plan for WordPress 3.2 is “faster, lighter”. I don’t think this happens because I wrote about it, but rather because many people, like me, have started to focus more on speed and fast loading of their web sites.

There is a good – excellent actually – reason for this: Google have officially stated that web site speed is one the factors that determine search ranking. While implementing this may require a balancing act by Google, it is a move that makes a lot of sense. Web site speed is one of the factors that influence whether users like a web site or not – there is nothing worse than a very slow site. And it is easy to understand why Google doesn’t want search results with links to very slow sites – if users get annoyed they will eventually get annoyed with Google as well.

If you ask me, it’s about time for a lighter and faster WordPress. The current and previous versions of WordPress are quite heavy and require execution of a lot of PHP and a large number of MySQL queries to produce its output (many of the themes and plugins are very slow too, but that will not change in the short term). As a result, most people running WordPress these days use caches that store pure HTML-version of the pages and serve them instead.

I am looking forward to the new version. I love WordPress and eagerly await every new version – but 3.2 perhaps more  than the previous ones. I hope developers of plugins and themes pick up on the implicit challenge by WordPress and start to focus more on speed as well. Also – I would love to see WordPress or the WordPress community publish speed rankings of themes and plugins – as it is you are pretty much left to your own devices when it comes to finding efficient, fast and reliable plugins and themes.

©2012 nekkidblogger. All Rights Reserved.

HTML & XHTML DeMYSTiFieD is an excellent book for people wanting to learn the basics about how to build web sites by self-study. It is a well designed book that starts right at the beginning – with what HTML and XHTML is – and quickly moves on to show readers how to build their first web pages.

The author, Lee Cottrell, is a computer teacher at the Bradford School. He has been creating Web pages with HTML since 1993 and teaching it to students for more than 12 years. Throughout this time, Cottrell has learned how to effectively describe HTML’s core elements.

The book is a practical, self-paced guide to HTML and XHTML. It is hands on from start to finish and gives thorough and more than sufficient guidance on required Web design techniques and technologies. The step-by-step approach is well thought out, and the sequence and progression in this nice little course book seems very appropriate. It shows first how to build a simple web page, and then it teaches you the use of various important yet basic HTML elements like hyperlinks, lists, tables and forms.

The book also takes some steps beyond the pure HTML and teaches you how to layout and format pages and page elements with CSS, and some neat small Javascript utilities to spice up and make your HTML-page become more interactive and live. Also, Learning HTML and XHTML is full of smart and very useful advice that teaches you to do things the right way from the start, and that – if you follow Cottrell’s advice – will save you a lot of time and worry later one.

• The book covers Covers HTML, XHTML, HTML5, and CSS
• Develops two stand-alone examples per chapter: one created by the author; the other for you to practice
• Helps you recognize and resolve common HTML errors
• Is an excellent book for self-study

At the end of each chapter are review questions and at the end of the book is a final exam– with well-considered questions that provide excellent tools for revealing whether you have digested the materials the way you should or not. In my opinion this is a great book for self-study or for use in a class room for students learning HTML and the basic techniques of web site building for the first time! HTML & XHTML DeMYSTiFieD is a book with hard stuff made really simple!

Links to books by Lee Cottrell on Amazon US, Amazon UK, and Amazon CAN.

©2012 nekkidblogger. All Rights Reserved.

This is the second – and substantially revised and expanded – edition of Dan Cederholm’s best-selling Web Standards Solutions. Web Standards is a movement that is gathering strength among Web designers, and is increasingly embraced as the standard technology specifications enforced by the World Wide Web Consortium (W3C) to make sure that web designers and browser manufacturers are using the same technology syntax. Dan Cederholm, a very well-known and excellent CSS guru, has long been in the forefront of this movement.

Standard solutions improve consistency, make redesign and changes of web sites easier and add robustness to web sites. Increasing adherence to standards also makes possible a smoother transition to new types of screen and viewing devices, such as screen readers for people with vision impairments, cell phones, PDFs, e-book readers, and what not. HTML, XML, XHTML and CSS are all such technologies.

This is a truly excellent book written by one of the best programmers and designers out there. I have used the previous edition of this book for a long time, and often gone back to it to find inspiration or solutions. A very useful book! And the new version is even better!

Web Standards Solutions is a great guide to understanding the advantages you can bring to your web pages by implementing web standards and precisely how to apply them.

Cederholm shows you how can use CSS to lay out your pages in excellent, solid designs that are flexible and look good across viewing platforms, as well as a number of smaller, neat and efficient techniques for producing great looking elements that go into the layout, all equally scalable and easily revisable as the layout itself.

• The Expanded edition contains great bonus material.
• Teaches how to use Web Standards effectively to build better web sites.
• Cederholm’s “solutions style” promotes learning.

Web Standards Solutions has 16 short chapters, each covering the theory and practice of different web standards concepts and showing multiple solutions to given problems for easy learning. You’ll learn about multi-column layouts, using image replacement techniques to your best advantage, making the best use of tables and lists, and many more. Cederholm gives you advanced web design techniques and discusses important caveats.

This is a great book for people wanting to learn how to use CSS the right way, who wants good, solid workable and pretty looking solutions, and Web developers and designers wanting to learn standards-based techniques to improve their sites. Web Standards Solutions is very good investment, in my opinion!

Links to books by Dan Cederholm at Amazon US, Amazon UK, and Amazon CAN.

©2012 nekkidblogger. All Rights Reserved.