Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Mike Bowers

+ Follow
since Oct 08, 2007
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike Bowers

What doctype should I use for XHTML documents?

The short answer is that I use the following doctype in all my web pages:

I also recommend using an HTML and CSS validator that ignores the doctype in my HTML documents and lets me choose what I want to validate. That way, I can use this doctype to trigger the correct browser rendering while including non-standard elements and attributes in my markup so I can take advantage of browser innovations in both HTML markup and CSS properties.

Here is the long answer...

This doctype specifies the type of document as "html" with a version of "XHTML 1.0 Transitional". It also specifies the location of the Document Type Definition (DTD) file that should be used for validating the document. In this doctype the location is the W3C website at "".

Doctype is related to the MIME content type, but has a completely different purpose. The MIME content type alone defines the type of document. It is set by the web server using the HTTP protocol when a document is downloaded. In spite of its name, a doctype has nothing to do with the identifying the type of a document.

A browser uses the MIME content type to determine what "driver" it will use to parse and display the document. In other words, if you use a MIME content type of "text/html", a browser will load its HTML parser and rendering engine. If you use a MIME content type of "application/xhtml+xml", it will load its XML parser and rendering engine. In other words, a browser will not even try to parse and render a document until it knows what type of document it is, and that information comes exclusively from the MIME type.

So what is a doctype and what is it used for?

A doctype is an element embedded inside an the head of an HTML or XHTML document. The doctype specifies the version of an HTML document and what Document Type Document (DTD) should be used to validate the document.

The doctype comes from the SGML roots of the HTML and XHTML specifications. SGML is the language used to define the HTML, XML, and XHTML languages. SGML is a powerful and complex language for defining markup languages.

SGML parsers look for a doctype element inside a document so they can load a DTD file to validate and parse the document. When an SGML parser encounters a doctype, it can use the DTD to determine the rules it should use for parsing and validating the document.

In the doctype I listed above, an SGML parser would go to and retrieve the DTD file and use it to parse and validate the document. You can specify any DTD file, and it can be located anywhere as long as it can be downloaded. The DTD can be on your local hard drive, on your own website, on someone else's website, etc.

Validator programs typically read the doctype, retrieve the DTD and use the DTD to validate your document. The W3C has a free validator at It reads the doctype of your document and validates it based on that doctype.

You can even download the DTD files supplied by the W3C and modify them to create your own rules for validating HTML and XHTML documents. In your doctypes, you can specify your own custom file as the DTD that should be used for validation. This is a perfectly appropriate technique. This is the original purpose of the doctype. If you are a programmer, DTDs are not hard to understand. Any good book on XML will show you how to create a DTD. All you need is a validator program, such as XML spy. You can specify any DTD in your doctype and XML spy will retrieve it from the location specified in the doctype and it will validate your document using it.

For example, there are many HTML and XHTML elements and attributes that the W3C has deprecated. Most of these are deprecated for good reasons and I don't recommend using them. But a few elements and attributes are fully supported by browsers and should not have been deprecated or were never included in the W3C specifications for political reasons. There is nothing wrong with including these elements and attributes in your documents. By using custom DTDs, you can use these elements and attributes in your documents and still validate your documents. Of course, be sure to test non-standard elements and attributes in all browsers to be sure they work the way you want.

In other words, a valid document is valid when it validates against a DTD � any DTD specified by the doctype. It doesn't have to validate against the W3C's DTDs. This is a very important point that the W3C doesn't advertise because they want you to use their standard because they want to be the only standard!

Don't get me wrong. I like the W3C and I like standards, but the W3C is not the only standard. HTML and XML are based on DTDs that can be modified beyond the W3C standard. The Internet succeeded because of the right balance of basic, open standards, and the freedom for anyone to extend these standards.

In fact the Internet is not as exciting as it used to be because the W3C is not in the business of innovating. Its business is standardizing, which by its nature opposes change. Browser vendors did the innovating and the W3C followed behind trying to set a standard upon which they all could agree � the process was political and was full of compromises. Now that Microsoft has conquered the browser market and killed Netscape, innovation is stagnant. Mozilla is not a standard setter, but a standard follower. Once we realize that standards are only a starting point, we can start genuinely innovating again.

What makes things complicated with the doctype is that web browsers are not SGML parsers. They don't follow SGML rules. They don't look up the DTD file at the location specified in the doctype. They don't use the DTD to validate documents. Instead, they use their own rules for parsing HTML -- and each browser vendor has different rules. Until CSS entered the picture, browsers completely ignored the doctype!

Unfortunately, during the early days of the Internet browser vendors rushed out new versions faster than the W3C could define specifications. Different browsers implemented early draft versions of CSS specifications differently. Once CSS became standardized, browser vendors needed a way to know which rules to use when rendering a document: the old HTML rules, the new CSS rules, or rules that were backward compatible to some proprietary vendor standard.

The browser vendors decided to use the doctype for this purpose. This is called doctype sniffing. This was a mistake. It is a kludge of the worst kind, but we are stuck with it.

There are dozens of different doctype signatures and all the different browser vendors use different signatures to trigger different CSS behaviors. You can read about these signatures at

After years of research and experimentation, I have found only one doctype that reliably triggers compatible behavior among all the browsers. It is the doctype I listed previously. All the design patterns in my book use this doctype.

If you want to use HTML instead of XHTML (which I don't recommend), you can use either of the following HTML doctypes:

Further, if you plan on using elements and attributes that are not supported by XHTML 1.0 Transitional, you can use an HTML validator that ignores the doctype in your documents and lets you choose what you want to validate. This way, you can choose the doctype that triggers the right CSS behavior in browsers and allows you to include non-standard elements and attributes in your markup. This will free you to take advantage of browser innovations in both HTML markup and CSS properties.

Lastly, XML has an untapped power for document markup: it allows you to use your own custom elements and attributes to extend the semantic and structural meaning of your markup. The real power of CSS is that it allows you to style your custom markup as you please. This approach doesn't yet work consistently in all web browsers, but I can't wait until it does!

Chapter 2 of my book, Pro CSS and HTML Design Patterns, on pages 38-40 also discusses doctypes in a simpler and more practical manner. You can also see an example at
[ October 13, 2007: Message edited by: Mike Bowers ]
Thank you all for such great questions and responses!

I have really enjoyed this forum!

Thank you JavaRanch for this opportunity. You have a great website!
How do you add a horizontal scrollbar to an element?

The overflow design pattern in chapter 6 of my book, Pro CSS and HTML Design Patterns, shows exactly how to do this.

You can see an example of overflow in action at

Ram Chml's code is a great example of how to do this. (Be sure, though, not to embed CSS directly within the style attribute of an element because this makes your code hard to maintain � instead use a class attribute and style the class in your stylesheet).

I don't yet recommend overflow-x or overflow-y because Opera 9 doesn't support these properties -- although all the other major browsers do.

Lastly, I don't generally recommend using overflow because it annoys users when they have to scroll to see something. Of course, I'm sure your case is one of the many exceptions to this generalization.
[ October 12, 2007: Message edited by: Mike Bowers ]
Does Pro CSS and HTML Design Patterns have dropdown and tab menus that do not use JavaScript?

Because IE doesn't support some CSS features, it isn't possible to do a reliable dropdown or tab menu without some JavaScript.

Chapter 17 of my book has dropdown and tab menu design patterns. These patterns use JavaScript, but only in the most minimal ways. Also notice that there is absolutely no JavaScript code in the body of the XHTML document! My approach uses the best practice of fully separating XHTML, CSS, and JavaScript. This makes the code more maintainable because these items are not intermingled throughout the XHTML code.

You can see the dropdown menu in action at

You can see the tab menu in action at

Note that both of these design patterns are fully accessible, work in all major browsers, and display nicely when CSS is turned off and JavaScript is disabled.

[ October 12, 2007: Message edited by: Mike Bowers ]
[ October 13, 2007: Message edited by: Mike Bowers ]
Should I use XHTML documents or XHTML syntax in HTML documents?

This is a great question. I discuss this important topic on pages 38-40 of my book, Pro CSS and HTML Design Patterns.
After several years of pondering this issue and trying many different approaches, I have developed a pragmatic opinion.

I code everything in XHTML and I validate it as XHTML. I do this because XHTML is future compatible and allows XML parsers, such as XSLT, to manipulate documents. Most importantly, though, XHTML guarantees a browser will interpret the hierarchical structure of my code exactly as I intended. This is essential for CSS because CSS selectors choose XHTML elements based on their location in the document hierarchy. The problem is that HTML allows you to take shortcuts, such as using <p> without </p> and these shortcuts cause different browsers to interpret the hierarchy of your code differently. (You can read about this in more detail and see examples of this in my book.) This problem is eliminated when you use valid XHTML and this eliminates a lot of troubleshooting in your CSS code!

I strongly recommend that everyone who uses CSS use XHTML. There are no limitations to coding in XHTML -- other than the inconvenience of using a more exacting syntax.

So once you code your pages in XHTML, what MIME content type should you use?

The HTTP protocol requires a web server to specify what type of document it is delivering to the browser. This is the MIME content type. The idea is that a browser will know the type of document so it can display it properly. HTML documents have a MIME type of "text/html".

The W3C allows XHTML documents to be represented by four different document types: "text/html", "application/xhtml+xml", and "application/xml", and "text/xml". This has created no end of confusion. How do we know which MIME type is better?

If you want your web pages to work in all the major browsers, there is only one answer: "text/html". This is the only answer because all major browsers have problems displaying XHTML documents when the MIME type is anything other than "text/html". On the other hand, all major browsers have no problems displaying XHTML documents when the MIME type is "text/html" � as long as you put an extra space between the element name and the closing slash in singleton elements like <br />.

In other words, I use XHTML with a MIME type of "text/html". Sadly, any other choice simply doesn't work in the real world.

For example, if you use one of the XML MIME types for your XHTML document, Internet Explorer (versions 6 and 7) has major problems displaying it. The page renders two to three times slower than HTML; IE ignores interactive elements like buttons; and IE displays all elements inline. The result is a real mess! Since IE still owns 85% of the market, I prefer to deliver my web documents as "text/html" so they are rendered correctly.

Even Firefox has problems rendering documents with an XHTML MIME content type. For example, when it gets an XHTML MIME type from the server, it downloads the entire XHTML document before it begins rendering so it can validate the document first. This is a performance problem because the user is used to seeing a page load incrementally. Even more importantly, if the document has even the smallest error, Firefox won't render it! This requires all web pages to be 100% valid XHTML, and it requires us never to make a mistake and never to forget to validate no matter how hectic things get. All it takes is one tiny typo and Firefox won't display the web page � unless it is delivered with a MIME type of "text/html".

My book, Pro CSS and HTML Design Patterns, contains much more information and examples about XHTML and MIME content types. If you are the kind of developer that cares about these issues, you'll love my book. I wrote this book for developers because all other books on CSS were written for designers and didn't have the in depth coverage needed by developers.

To get a feel for the breadth of my book and its quality, you can examine hundreds of examples from my book at
[ October 13, 2007: Message edited by: Mike Bowers ]
To answer your question requires much more information from you and many long detailed answers from me. I would literally have to write a book to explain it ...what a minute...that is what I have done :-)

The best answer I can suggest is to buy my book...not so I can get another book sale, but because it will explain to you how the six block models work and how they are affected by all the CSS properties and property values like percentages. Lastly, it will take you step-by-step through the process of creating fluid layouts.

My fluid layout design pattern works. Just check out the examples in my book. They work in all major browsers at all screen resolutions and they even work in PDAs and cell phones.

I understand your doubts because before I invented this breakthrough design pattern, and I never could get floated divs to behave consistently -- it all seemed like a black art of trial and error -- mostly error!

For example, I just now pulled up my website, on my blackberry. The entire website is based on the fluid layout design pattern and the pages look great on the blackberry's tiny display. I then navigated to the Fluid Layout examples in Chapter 17 and they displayed perfectly--wrapping around to fit the display on my blackberry. Even when I turn off CSS in my blackberry, these pages still look great. This is the true power of my fluid layout design pattern. It just works!

Unfortunately it would take about a dozen pages of text here to explain how and why this design pattern works so well, but you can find it all in my book :-)

I hope you enjoy my book! It is packed full of useful, proven techniques.
Is there an easy/good/proper way to dynamically load stylesheets for different browsers?

There is only one proper way to load stylesheets conditionally based on the version of the browser. It is through Microsoft's proprietary "conditional comment". This is client-side side code that is interpreted by Internet Explorer (IE).

The idea is that if the version of the browser matches the conditional expression in the comment, the browser will interpret the content of the comment as XHTML code. If the version of the browser does not match the conditional expression, the browser ignores the content. You can use a conditional comment anywhere in your HTML document to conditionally insert XHTML.

The following code loads a stylesheet only in Internet Explorer version 6 or earlier.

As you know IE6 occasionally needs help to be compatible with other browsers. For this reason, using conditional comments to load stylesheets are an essential technique in Internet Explorer 6. When you use the design patterns in my book, you won't need to use conditional comments very often, but when you need them, they are a must!

Normally I wouldn't recommend a proprietary solution, but conditional comments are an exception. They are perfectly valid XHTML, and because they are comments, they are ignored by browsers other than IE. And lastly, Microsoft officially recommends them as the ONLY proper way to insert version-specific XHTML.

Unfortunately, the W3C specifies NO official way to conditionally evaluate HTML or CSS code! This is a major oversight because all versions of all browsers have bugs that need to be worked around � even Firefox!

Because the W3C and other browser vendors do not offer a solution, some developers "hack" a solution by taking advantage of bugs in specific versions of browsers. As thousands of web developers found out when IE 7 was released, bugs get fixed and hacks no longer work.

In chapter 2 of my book, Pro CSS and HTML Design Patterns, I have a design pattern called "Conditional Stylesheet" that goes into more detail on how you can take advantage of conditional comments. For an example, check out the book's website at View this page in Internet Explorer and in another browser and you will see it is styled differently in Internet Explorer. You can look at the source code to see what is going on.
If you like lots of high-quality examples, you'll love my book.

Also if you want cross-browser compatibility, my book is the best way to get it. I have done all the work of figuring out what works in all the major browsers and what is most natural for XHTML and CSS. The end result are design patterns that work in all major browsers without hacks or tricks.

You can check out all the examples in my book at
As you know, a bold font-weight increases the width of text. If the width of your tabs is based on the width of the text, then they too will expand. I assume this causes the jerkiness you mentioned.

The solution depends on how you have coded your tabs using XHTML and CSS.

In general, you can use a block element for the tab and give it a fixed size (or even better a minimum size) that is wide enough to hold its text when it is bold. Then when the text within the tab becomes bold, it won't resize the width of the tab.

The downside to using fixed-size blocks is that they may not adapt well in browsers with different screen sizes and font sizes. For this reason, I avoid using dynamic style changes that alter the size of text, such as making text bold or changing the font size. Instead I prefer adding an underline to text to show that it is being hovered over and that it is clickable -- the underline is also the standard convention for communicating that text is clickable.

Chapter 17 of my book contains two design patterns for tabs that you might find useful. You can see the examples for these tab design patterns at the following two links:
What are the top three or four CSS "gotchas"?

At the end of Chapter 1 in my book, Pro CSS and HTML Design Patterns, I have a section on Troubleshooting CSS. It lists 12 CSS gotchas. Here are my top three.

Gotcha number 1: invalid XHTML. It is the top culprit because CSS selectors choose which elements to style based on XHTML structure. Invalid XHTML structure causes some elements not to be styled or can actually style the wrong elements. This can be very subtle and can really cause you to pull out your hair.

Gotcha number 2: invalid CSS. It is the second top culprit because CSS requires browsers to ignore errors on individual properties. Thus, it is very easy to have a typo on a property that causes the browser to ignore it. This is very hard to track down unless you use a tool like the error console in FireFox. The easiest way to prevent this type of problem is to validate your CSS.

Gotcha number 3: incorrect CSS selectors. It is easy to have a typo in a selector that causes it to select no element or to select the wrong element or to select too many elements. To solve the problem, you can add a blatantly obvious CSS property to the selector in question so you can see exactly what the selector is selecting. For example you could assign border:10px solid red; to the selector so that each selected element is surrounded by a fat red box.

For the rest of these troubleshooting tips you can get my book at
There is a significant semantic difference between tables and divs � they have different meanings.

When you use a table in your markup you communicate that the contents of each cell is related to the header cells in its row and column. This is analogous to a database table where all the columns in a row are uniquely identified by the primary key of the row and the name of each column identifies the meaning of that column.

This might not be a big deal for visual users when they can't see a table that is used for layout, but for non-visual users it is a big deal. Tables are more difficult for non-visual users to navigate. Screen readers announce the row and column header cells before they read the contents of a cell. This annoys non-visual users when row and column headers have no meaning because the table is used only for visual layout.

Lastly, divisions are more flexible than tables. A table's columns can't wrap around vertically when the browser window is narrower than the table's width. This typically isn't a problem for desktop computers, but users of small Internet devices, like PDAs and cell phones, have a hard time navigating a table because it is awkward to scroll horizontally on these devices.

Chapter 17 of my book, Pro CSS and HTML Design Patterns, shows how to create fluid layouts that can match any layout you create with tables. This design pattern is called Fluid Layout and it works reliably and predictably in all major browsers. You can see an example of fluid layouts in action at . The whole page is designed using nothing but divisions. Because this example uses fluid layouts, it is fully accessible to non-visual readers and reflows nicely in devices with narrow displays like cell phones and PDAs. For example, when a display is narrow, the virtual "columns" in the fluid layout wrap around to become rows. This is really cool behavior that doesn't work when you use tables.

On the other hand, I like XHTML tables. They are very useful for displaying tabular data, and they have some advanced layout features that can't be mimicked by any other markup. I have devoted chapters 15 and 16 of my book to tables. In these chapters I expose some powerful layout features of tables that are not documented anywhere else. See and .
I also like CSS Sprites. So much so, that I put them in Chapter 14 of my book, Pro CSS and HTML Design Patterns. As you pointed out, the main benefit of a CSS Sprite is to increase the download speed of a website. This works because each file a browser has to download takes time because of latency.

For example, I did some testing and found out that it is typically not the number of bytes that slows the rendering of a web page (unless the user uses a dialup connection or you include huge image files on your page), it is the number of files. This is because it takes 0.1 to 0.5 seconds per file for a browser to talk to a DNS server to translate a URL into the IP address of the web server and to send an HTTP request to the web server to get the file. Even if a browser caches all the files in a web page, it still takes 0.1 to 0.5 seconds per file just to ask the web server if the file is stale and needs to be updated.

MSN is much slower than Google mainly because each page has so many files to download � a page from MSN takes 6 to 8 seconds on my broadband connection and Google takes 0.5 seconds.

Thus, the best way you can increase the performance of web pages by limiting the number of files the page needs to download. You can put all the images in one CSS sprite, and embed all your CSS and JavaScript in the header of the web page. This will give you maximum performance.

If you are interested in other ways to improve your web pages and dramatically speed your web development, check out my book, Pro CSS and HTML Design patterns. You can view its examples at
I have the perfect solution. Chapter 17 of my book contains two design patterns that show you how to create a tabbed menu.

You can see the solution in action at my website

The core design pattern is called Tab Menu ( ). Another design that is enhanced by JavaScript is called Tabs ( ). Both design patterns can be styled by CSS to fit the look and feel of your site.

The example at the end of the chapter pulls together all the techniques used in the chapter where you can see the tab menu in context. (See )

Note tab menu design patterns are advanced and use many other design patterns presented earlier in the book. Feel free to use the source code from the examples from my website, but if you want to understand how they work and how you can adapt them to fit your needs, you will need to read my book.

If you need a copy of my book fast, you can download an eBook version from Apress at
I have the perfect solution for you. Chapter 17 of my book presents design patterns that do exactly what you want.

You can see the solution in action at my website Chapter 17 discusses fluid layouts in detail (see ).

The core design pattern is called Fluid Layout. It allows you to create layouts that can have any number of headers, footers, sidebars, etc. These layouts adapt fluidly to browsers with larger and smaller widths (such as cell phones, desktops, wide screens, etc). This pattern works in all major browsers including Internet Explorer 6 & 7, Firefox (all versions), Opera 9, and Safari 2. (See )

The example at the end of the chapter pulls together all the techniques used in the chapter (see )

If you need a copy of my book fast, you can download an eBook version from Apress at