Sometimes in your content you end up with some really long words or URLs that just won't wrap and end up screwing up the width of your content (especially in IE 6), or just running off the edge of the page.

Some common solutions involve automatically shortening the word or URL to a character limit and putting three dots "..." after it. But what if you want the whole URL or word to be visible?

I think the perfect solution is to have the URL wrap like words in a sentence, but how do you tell the browser to split the URL up?

The answer is to use <wbr/>, the Word Break tag. This gives the browser a spot where it can split the line up. For example:

http://www.thefutureoftheweb.com/<wbr/>blog/2007/1/<wbr/>breaking-long-urls

This example gives the browser two places where it can break the URL and wrap the parts onto different lines:

http://www.thefutureoftheweb.com/
blog/2007/1/
breaking-long-urls

Unfortunately, the <wbr/> tag doesn't work in all browsers, only Firefox and Internet Explorer. Via QuirksMode, Gordon Mohr suggests another solution using CSS which makes <wbr/> work in Opera:

wbr:after { content: "\00200B" }

This adds ​ after the <wbr/>, an entity that achieves the same effect in Opera and Safari.

Unfortunately, neither <wbr/> nor this CSS will work in Safari. You can try putting &#8203 directly into your HTML, but then you'll end up with weird squares in Internet Explorer 6. Don't you love browser compatibilities?

For more info, check out the QuirksMode page I mentioned above.

I received a question this morning from someone asking:

In XHTML 1.1 we cannot use attribute 'target=blank', so what is the solution?

The solution is to use regular links, but to make them open into a new window using JavaScript. To do this, we can add something to the links to flag them as being special, perhaps a class called new-window:

<a href="page.html" class="new-window">Page</a>

Then, use JavaScript to find all the links that have this class name and tell them to open in a new window:

window.onload = function() {
    var links = document.getElementsByTagName('a');
    for (var i=0;i < links.length;i++) {
        if (links[i].className == 'new-window') {
            links[i].onclick = function() {
                window.open(this.href);
                return false;
            };
        }
    }
};

or using jQuery:

$(function(){
    $('a.new-window').click(function(){
        window.open(this.href);
        return false;
    });
});

If you have any other questions like this, feel free to ask me and I'll be happy to answer them here.

Usually, you want to be able to submit a form, like a login or search, just by hitting enter. But sometimes it doesn't work.

Firefox will always let you submit any form by pressing Enter, but Internet Explorer is a little bit picky. I figured out a generalised rule of when it won't work:

There is more than one text/password field, but no <input type="submit"/> or <input type="image"/> is visible when the page loads.

This rule has the following interesting consequences:

• If you just have a <button/>, hitting enter won't submit the form.
• Hiding submit buttons by using display:none, positioning them off the page, hiding them inside an overflow:hidden, or any other method will break the enter-to-submit functionality.
• If a form is hidden when the page loads and is displayed using JavaScript, the enter-to-submit will be broken.

It appears that Internet Explorer scans the page at load time and figures out which submit buttons are visible, then attaches the enter-to-submit functionality to those forms.

To fix these scenarios, you can use the following JavaScript:

function addInputSubmitEvent(form, input) {
    input.onkeydown = function(e) {
        e = e || window.event;
        if (e.keyCode == 13) {
            form.submit();
            return false;
        }
    };
}

window.onload = function() {
    var forms = document.getElementsByTagName('form');

    for (var i=0;i < forms.length;i++) {
        var inputs = forms[i].getElementsByTagName('input');

        for (var j=0;j < inputs.length;j++)
            addInputSubmitEvent(forms[i], inputs[j]);
    }
};

(Of course, it's better if you use addDOMLoadEvent instead of window.onload and addEvent instead of onkeydown.)

If you use jQuery, you can just write:

$(function(){
    $('input').keydown(function(e){
        if (e.keyCode == 13) {
            $(this).parents('form').submit();
            return false;
        }
    });
});

The return false is rather important in Internet Explorer, because it prevents that beep that you might hear if you hit return. The beep is saying "you can't hit enter here!", but return false cancels the key press and therefore the browser won't warn.

Update: As Eric Lentz pointed out, my previous code would submit a form when hitting enter in a textarea. I fixed the solution so the onkeydown event is added to <input> elements only.

It's a miracle! There is a new W3C CSS Validator. I checked, and it's true, Unitless Line Heights are now considered valid!

Back in February, Eric Meyer wrote about Unitless Line Heights, explaining that you don't need to put px, pt, % or em at the end of a line height, and you don't even need decimals. Unfortunately, for a long time, the W3C CSS validator said that this was invalid:

body { line-height: 1 }

Oddly, if you changed it to 1.0, it became valid.

I took the challenge, and downloaded the Java source code of the validator. After reading through the code for a few hours, I found the problem. At the core of the bug, it was requiring the value to be a Float but not a regular Number.

Anyway, on February 11th, 2006, I sent in a patch to fix the problem.

And now, about a year later, the live validator is finally fixed. Now we can all rejoice by having our valid CSS actually validating.

I've talked about Semantic HTML before, and many other people have. But the one thing I find missing in these discussions is an explanation of why we should use Semantic HTML, or more specifically, who or what it will be that later reads your Semantic HTML to extract meaning from it.

Semantic HTML is all about adding meaning to your document by using appropriate HTML elements. It's a great concept. Why waste time and space with unnecessary <div> and <span> elements when other more meaningful elements are available like <h1> or <label>?

Certainly, Semantic HTML has many practical benefits. <label> has usability and accessibility benefits, like allowing people to click some text to check a checkbox, or allowing people with screenreaders understand what a text input is for. Headers like <h1> give a document structure by allowing hierarchical naming of the sections of a document. <title> lets you give a document a title. And of course, <a> lets you create hyperlinks which tie web pages together.

All these are very clear and understandable benefits and ways of using Semantic HTML. I find there are other benefits to using a variety of elements, like being able to work with the HTML and CSS of a document more easily. If a document was make completely with <div>s, you'd spend a lot of time giving things class names and IDs unnecessarily, and you spend a lot of time trying to figure which </div> goes with which <div>.

Now what really bugs me is when people start arguing about the semantic meaning of a certain element. Recently on Snook was a discussion of the Use of ADDRESS Element. Now, I understand where such discussions are coming from. The W3C HTML specs do try to define what each element is supposed to be used for. But if such a definition isn't totally clear, then you really can't use the element for anything. And you know a definition is vague when a dozen semantic and standards enthusiasts can't quite agree. And if these people can't agree, then what about the millions of other people who make web pages and haven't even heard of the W3C?

I believe it comes down to practicalities. For example, with the <address> element, you could argue that the element should only be used for web page contact information because the specs imply this. But what will this allow us to do? Is someone going to make a tool that looks for <address> elements on a page and uses it to let you contact the owner of the page? I doubt it, except maybe spam email harvesters. And even if there was, the tool would find itself to be nearly useless since so many web pages are likely using <address> for a wide variety of purposes that have little to do with web page contact info.

And what about other elements that don't even have a specific use like ordered, unordered and definition lists? I find it hard to imagine a scenario where the semantic meaning implicit in a list of items can be utilized. It's possible Google Sets uses lists this way, but chances are it mostly uses comma-separated words. And maybe the definitions feature of Google could use definition lists, but most of the results come from sites that don't use definition lists at all.

Well this brings me to the point I wanted to make. We need to think about who or what it is that will actually be extracting the meaning we're adding to our documents by using Semantic HTML. And basically I can think of three groups:

1. Web developers

   Yourself or others that will actually be reading and working with the HTML you produce. For this purpose, class names, IDs and elements all add semantic meaning or at least readability to a document. This makes it easier to work with the HTML, and understand what each element represents structurally.

2. Search engine spiders and other bots

   These are tools that read a large number of web pages and try to extract some meaning from them. Search engines understand that text in titles, meta tags, links and headers is special. Technorati's Microformats Search is another great example of semantics being utilized.

3. Web browsers, screen readers and other clients

   These understand what many of the different elements are for and allow the visitor to interact with these elements in a unique way, like with a checkbox or link. Also, the client can communicate semantics to a visitor by displaying elements a certain way, like numbering the items of an ordered list. However, this semantic communication can be messed with by using CSS. An ordered list with list-style: none and list items floated will communicate no semantics to a user of a visual web browser.

In terms of these three groups of web page users, try to think of what difference it will make if a <dd> gets used for a blog post body instead of strictly a word definition. If the semantics can't be used or even considered to really mean anything, then can they even be considered semantic?