The Wrong Way To Use Css In Page Layouts
Posted on 16 Mar 2002
by Adrian Roselli (aardvark)
Rated 4.23 (Ratings: 23)
- More articles in Site Development
Figure 2: This screen capture shows a more severe example of the reported issues. Text is more illegible, and it seems impossible to determine what text goes where.
So how did this happen?In each of these cases, a developer using a WYSIWYG editor was the culprit. Having spent many of my years as a web developer cleaning code spit out by these editors, I've gotten used to recognizing much of the specific syntax and style that they use. I recognized most of these offenders as Macromedia Dreamweaver. Generally regarded as one of the better editors on the market, and deservedly so, it offers the ability for developers to create table-free layouts thanks to CSS positioning syntax. Developers who wanted to claim they were ditching tabled layouts for CSS-only layouts, something that organizations such as the Web Standards Project (WaSP) have been pushing for some time, could now do just that without having to learn a lick of CSS.Unfortunately, Dreamweaver's approach to layouts powered by CSS is anything but ideal. It eschews structural and semantic HTML elements in favor of the most basic elements, the ones that imply nothing but act simply as containers —
<div>s. Instead of wrapping headlines in headline tags (
<h6>) or blocks of text in paragraph tags (
<p>), everything gets wrapped in a
<div>, every paragraph, every headline, even every table. This can be overridden, and there are many talented developers who do just that, but they aren't the ones creating these problem pages. Once a developer starts dragging paragraphs around the screen, each one is assigned an absolute x and y coordinate that it must occupy, as opposed to simply flowing one after another as in a word processor. And developers did just that, they dragged every block of text to just where they wanted it. With the WYSIWYG interface hiding the underlying code, these developers never saw the coordinate being assigned to each
<div>, let alone the fact that each
<div>was also assigned an absolute height and width, regardless of how much content it held. Figure 3 shows what the developer would have seen, a simple layout with paragraphs of copy flowing one after another. It's worth noting that I have a bit of a bias against WYSIWYG editors, something you can read more about in the article "To Hell With Bad Editors". Figure 3: The developer sees nothing wrong. After all, he or she is developing on his or her own system, so it should look ideal there.
What made it break?One problem with laying out blocks of text in very specific positions on the screen is that it doesn't take into account users who have their font sizes enlarged for any reason. It also doesn't take into account users on flat panel displays who often have the display set to something other than 72 or 96 pixels-per-inch (ppi). And it seemed there were enough of both of these kinds of users that the calls came in. Blocks of text ended up being larger than accounted for by the designers for these users. So while the second paragraph may have been placed 175 pixels from the top of the page, at higher resolutions or larger font sizes, the end of the paragraph above it extended below that 175 pixel mark, causing the text to overlap. Of course, this was compounded as the page progressed, and sometimes a third paragraph would start before the first one had ended. All three of the above images are screen captures from Netscape 6.02 on Windows 2000. The default size for text in Netscape 6 is 16 pixels at 96ppi. Figure 3 shows the default setting the developer would have used. Figure 1 shows how that same page looks if the default font size is set to 18 pixels, and Figure 2 shows it set to 20 pixels. If the user had extremely good eyesight and set the font sizes to 12 pixels (lower than the developer's settings), there would be very large gaps between the blocks of text. Those users on laptops, for example, would see similar results if their display settings, not their browser settings, were modified. During more testing, general users of flat panel displays experienced these problems as well, owing to their tendency to run their displays at resolutions higher than 72 ppi — often 100 ppi, and even a few at 140 ppi for the group used for testing. These users were initially told by developers that the users simply had their font sizes set too large. This is regardless of the fact that if the developers were correct, users did that so they could actually read the text. And so users correctly responded that, for the most part, their font settings were at the default. It occurred to some of the developers that people might come to the sites with larger fonts, but it was generally decided that these users could simply make their text smaller to see the page. Some of those developers, however, built their pages with type size units (pixels or points, for example) that could not be resized by the browser. It never occurred to any of the developers, however, that some users might be running at different pixel densities. So when developers had ordered their clients and their users to simply resize their fonts, and it didn't work, they were stumped. They hadn't gotten under the hood to see what was wrong with the code.
How did you fix this?Correcting this problem was embarrassingly simple. By opening the pages in a plain text editor, I could immediately see the offending code. It was just a matter of replacing every positioned
<div>with a more semantically correct
<p>tag for paragraphs, and
<h6>tags for headings. With the removal of all positioning, the page would flow well for any user, regardless of their browser, screen settings, or font size settings. Clearly there could be exceptions, but none were encountered. The solution was simply a case of under-engineering. Removing all the widgets resulted in an eminently usable page.
How can I tell if my site is broken?Well, one of the simpler ways is to change your font sizes in your favorite browser. A slightly more complex method involves changing your display settings to something significantly higher than 96 ppi. The simplest way, however, is to look at the code. It's one thing to absolutely position some elements on the page, such as logos, navigation, or other design elements, but it's another thing to do that with every paragraph of copy. If, in the source code, every paragraph is wrapped in a tag like the one below, you may want to run the other tests I mention above:
<div style="position:absolute;left:20px; top:175px; width:500px; height:50px; z-index:2">The statement
"position:absolute"is the first sign of trouble. The assignment of pixel values to
"top"means the block is positioned a specific distance from the top left corner of the window. While a
"width"attribute might not be bad, a
"height"attribute could be an issue as well if the code is also set to hide text that doesn't fit within the specified dimensions (via a