When Safari 3 was released as a beta about 2 months ago, it brought some cool features. One of them were the so-called “Resizable Text Fields”. What it means is that any textarea element can be resized by dragging its lower-right corner. This feature comes in handy when you have more text to input than the website author predicted. You can resize your field to avoid scrolling it. Great.

But as many web developers are aware, more freedom to the user means more worries to the designer. By resizing the text field, a user can affect the look of a website. Of course, a page should allow some customization, but what about extreme values (too small, too wide, …)? Will they make my website fall apart? Well, the good developers of Safari thought of that. Therefore textareas in Safari respect the CSS2 minimum and maximum widths and heights. For example, when a max-width of 300px is set, a user will still be able to resize the text field, but no wider than 300 pixels. Neat.

Another nifty thing we can use is the CSS3 resize property. This allows us to limit the resizing of an element (in this example, the textarea) to horizontal, vertical, or none. So by applying textarea { resize:vertical; } the user will be able to resize textareas vertically, but not horizontally.

A word of advice though - Resizable text fields were introduced to help the user. Even though we can prevent resizing all-together, it’s usually not a smart thing to do. Users like to use such features so don’t take this away from them. Do limit resizing within some reasonable values if you think it’s necessary, but don’t take it as an excuse for bad element positioning.

For better understanding, I split this post into three parts. The first one may be skipped by experienced web developers.

Some basic XHTML tag-closing theory
In HTML, tags needn’t be closed. So this is correct:

<ul>
    <li>Item 1
    <li>Item 2
</ul>

But with XHTML, we have to respect the strict XML standards, meaning each and every tag has to be closed. A bit more code is needed.

<ul>
    <li>Item 1</li>
    <li>Item 2</li>
</ul>

Also, we have to take care of tags with no closing tag, such as <br>:
<br> is wrong, while <br /> is correct.

This way XML parsers can read our HTML code. And what’s more, the code is much easier to read and understand by human beings, such as ourselves. If done correctly it doesn’t affect the way our code is rendered.

Can every tag be self-closing?
According to W3, every tag can be self-closing, therefore <div /> is a valid piece of XHTML code. But can we use this in the real world?

Self-closing tags demo

As you can see in the demo, browsers get confused by self-closing tags. They treat them as if we never closed them. You can try navigating the HTML structure with the Firebug extension for Firefox, to see how confused they really get.

I’ve tested this with IE7, Opera 9.2, Safari 3, Firefox 2 and Konqueror 3.9. All produced the same results.

Conclusion?
Do self-close tags with no closing tag, such as br, hr, img, link, base or meta. For example, <br></br> is not valid. But don’t do it to tags that do not expect that. It may be valid, but you won’t like the result. Just do <a name="anchor"></a> or such.

Because not all people use the same browser, it’s not enough to test a design on only one of them. What’s worse, some people don’t even use the latest version of their browser, so we also have to test different versions. So here’s a list of most common browsers and links on where to download them (including older versions).

Mozilla Firefox
You can download different versions on Mozilla’s FTP server. Select your version and your operating system. As long as you don’t overwrite another version, you can have any number of versions installed. To run multiple versions at once, I believe you need to run each one under a separate profile. I usually check websites on 1.0, 1.5 and 2.0, but there are rarely any differences between versions. Camino, Netscape and Galeon use the same rendering engine so they will show sites as Firefox does.

Internet Explorer
This one is windows only. Linux users can use Vmware or Wine to install it, mac users can use VirtualPC on Ppc or Bootcamp/Parallels on Intel machines. I myself use a remote desktop connection to a Windows machine. You can install IE7 on your Windows (via Windows update) and use standalone versions of older versions, found here. These require no installation, just unzip the folder and run the exe. I can confirm them working on windows XP but can’t tell you about older Windows versions. To solve cookie and conditional comments problems with standalone versions, see here. I tend to make websites look ok on 5.5 and higher versions (since even Microsoft doesn’t make websites for older versions).

Safari
Apple offers only the latest (beta) version of their Safari browser, But click here to download any of the older versions. Some versions may not work if you’re not running the latest version of OS X, but everything seems to work fine on Tiger. Testing on 2.0 is recommended since 3.0 is still beta and it doesn’t automatically update. I do believe Omniweb and Shiira use the same rendering engine as Safari does.

Opera
You can download the latest version of Opera for your system on their website, but older versions can be found here. Again, if you don’t overwrite an older version you can install as many as you like. I usually test versions 8 and newer, since Opera 7 doesn’t really show up in statistics.

Konqueror
Linux users get Konqueror with their KDE. Mac users can also install KDE and use Konqeuror. Windows users can probably install KDE on Cygwin, but I haven’t tested this myself. How to get different versions is a mystery to me, but I’ve found Konqeuror to be the most standards-compliant browser, so if your page works on every other browser without hacks, it should work on any newer version of Konqeuror. Also, I believe that Linux users do upgrade their software regularly.

Lynx, screen readers
Lynx is a text-only browser for Unix that works in a command line environment. I guess Linux users know how to install Lynx… Mac users can find it in Fink, Windows users can give this a try. Lynx won’t render any css or tables, so I do recommend writing semantic code. Also note that people with bad or no eyesight use screen readers to “view” websites, so Lynx is your best approximation to this.

Yesterday, Apple released it’s Safari 3 beta for OS X and Windows. I’ve been playing with it and it seems quite nice. Windows users did report some problems (and even more problems).

Anyway, I’ve been looking at the web standars project page just now, and noticed the menu looks rather weird in safari. So I’ve investigated a bit and found out it uses text-shadow. So I made a little test case. See how it renders in Safari. Pretty neat, ha? I don’t think any other browser supports this currently. Firefox 2.0.0.4 and Opera 9.00 sure don’t, but I’ll check a few newer versions later today.

update: Opera 9.2 and Firefox 3.0 alpha fail to render text-shadow

update #2: It seems this is old news. text-shadow has been around since safari 1.1 and is said to be working in konqueror also. But what are the big guys (firefox, opera, ie) waiting for?

Now we all know that making browser-specific css rules is a bad practice. But sometimes it can save a lot of nerves and code. It’s why we all love those CSS Filters tables. They give us some basic information on what works and what doesn’t in which browser. But we still have to determine just which rules to combine for a specific browser.

So I created a little demo case where I apply a certain css rule only to one browser at a time. Or to the viewer… it tells you what browser you are using - css only. It’s valid CSS 3 (with 2 warnings) and the code is documented so you can see what I did.

CSS browser detection - see for yourself

Please notify me of anything not showing correctly or if you think I should add a certain browser to the table.