Goodbye WebKit

2013-04-05T00:00:00+01:00

When Opera announced their move to WebKit, I wanted to write about the loss of competition, the growing WebKit monoculture, and the poorer place the web would be without the Presto rendering engine. And then Google announced Blink and everything changed again.

Personally, I think Blink is a good thing. More browsers and more rendering engines means more competition and innovation. Remember the long years of IE6? That’s what a monoculture looks like. And because Blink is a fork of WebKit, it will already have solid support for standards and developers don’t need to worry about a sudden change in the next version of Chrome.

Another reason to be optimistic is that Google seem to be committed to an open development process. Thanks to Chrome, Blink will inherit an enormous number of users and Google are aware of their dominance in a space that relies on cooperation and interoperability. So far, they appear to be taking their responsibility to the wider web seriously.

As I said, I think Blink is going to be good for the web. However, it does present some of us developers with a new browser testing headache. I know I am supposed to test in all the browsers and I know that you cannot assume that two WebKit browsers will work exactly the same. But I cannot test in Safari because I haven’t got a Mac.

I want to test my sites in Safari, but there is no way I can afford a Mac just for browser testing. And Windows remains dominant on the desktop, so it still makes sense to focus my testing there than on any other platform. With Chrome and Opera moving to Blink, there is no mainstream WebKit browser on Windows and as the two rendering engines diverge, this is going to become a problem. A headache for me, but something worse for Safari? Suddenly, and unexpectedly, WebKit is no longer the dominant force on the web.

Jekyll

2012-11-26T00:00:00+00:00

I built the first version of this website using WordPress and, because nobody was there to stop me, I used everything. It had a dynamic sidebar, categories, comments, search, and various archives. I learned a lot about WordPress, but after a while I realised it was a lot more than I needed for posting the occasional bit of text.

I looked a various content management systems, many of them claiming to be simple and elegant, but I was never convinced they offered any real advantages over the system I had already mastered.

Then I discovered Jekyll, a powerful, minimalist static site generator written in Ruby. Articles and pages are just plain text files; there is no default template or structure; and it supports all sorts of useful blogging features, like categories, tags, pagination, and archives.

The sheer simplicity of the system appealed to the hacker in me, but there are also other benefits to having a static site.

There is no database and no server-side scripting, so a static site loads fast.
Hosting requirements are minimal. You can even host a Jekyll site using GitHub Pages.
Flat files are hard to hack, so your site is as secure as it could be.

So Jekyll does what I want for my site right now. It certainly isn’t for everyone, or even for me all the time. I still like WordPress a lot and a good CMS is still the obvious choice for anyone who doesn’t want to spend their time staring at the command line. And if you need comments, multiple users, search, or just the ability to log in and edit the site from anywhere, you still need a CMS.

The q element

2012-11-21T00:00:00+00:00

The <q> element first turned up in HTML4 for inline quotations and is still a part of HTML5. The idea is that the browser adds the correct quotation marks around the text, taking into account the current language and whether the text is nested inside another quotation. However, lack of support meant that it was largely ignored. By the time support was added to Internet Explorer 8 more than eleven years after the <q> element was standardised, most developers had forgotten about it.

These days, all the major browsers support the element and the related quotes CSS property. Despite this, I still don’t think it is a good idea to use the <q> element. Take a look at the following extract from The Sign of the Four.

He laughed until his ears were quite red. “That would hardly do,” he cried. “I don’t know what he would say if I brought you in that sudden way. No, I must prepare you by showing you how we all stand to each other. In the first place, I must tell you that there are several points in the story of which I am myself ignorant. I can only lay the facts before you as far as I know them myself.

“My father was, as you may have guessed, Major John Sholto, once of the Indian army. He retired some eleven years ago, and came to live at Pondicherry Lodge in Upper Norwood …

Where would you put the <q> tags? The dialogue is interspersed with text that is not part of the quotation, but then the quotation spans more than one paragraph. It is a bit late to ask Arthur Conan Doyle to use a <blockquote> instead.

The obvious solution is to use real quotation marks. And if we can use real quotation marks, why do we need <q> at all? We don’t have HTML elements for other punctuation. The characters exist in Unicode, they are semantically correct, and they are right there on your keyboard.

What is holding back the web?

2012-07-12T00:00:00+01:00

An article by Louis Lazaris appeared in Smashing Magazine this week, blaming all versions of Internet Explorer for holding back the web. I know nobody likes Internet Explorer 6, but is version 9 really that bad? Nicholas C. Zakas has already written a great response, but I thought I might add a few points in defence of at least some versions of Internet Explorer.

I would draw a major distinction between old and current versions of Internet Explorer. Old versions, which I would describe as version 7 and below, lack key features and contain major bugs and that means they can be a real headache for developers. Patchy and wildly unpredictable support for CSS 2.1 makes layout difficult and time-consuming. But ten years, three operating systems, and a heck of a lot of websites separate Internet Explorer 6 from Internet Explorer 9. You really cannot put them in the same category.

I will admit that current versions of Internet Explorer (8 on Windows XP, 9 on Windows Vista and above) lack a few features. However, what they do support, they support well. When I view my designs in Internet Explorer 8, they might not have rounded corners, shadows, opacity, or other formatting niceties, but I can rely on them being the right size and shape. The websites still work. And if Internet Explorer 8 isn’t holding my websites back, I can hardly complain about version 9.

So with a bit of progressive enhancement, I don’t see Internet Explorer as a problem. I might even argue that mobile browsers are becoming more of a limiting factor. All the major mobile browsers are tied to their operating systems and a lot of people don’t bother with the upgrade, even if it is available. Android updates are notoriously inconsistent, but I know plenty of people with old iPhones who have never updated iOS. Internet Explorer isn’t the only old browser in the wild.

However, I don’t want to pass the blame on to some other browser. In fact, I don’t think any browser is “holding back” the web. All the browser manufacturers are releasing new versions, new standards are emerging, and more people are using the web in new and interesting ways than ever before. I don’t see anything holding back the web and I think it’s a great time to be a developer.

Simple responsive JavaScript

2012-04-22T00:00:00+01:00

Brad Frost recently wrote a great summary of responsive navigation patterns. Personally, I prefer the toggle method, which keeps the menu out of the way until you need it and that is the method I chose for my own site. Here is how I implemented it.

My own approach is similar to an example by Filament Group, but mine completely avoids trying to detect the size of the window with JavaScript.

I’ll start with a simple HTML navigation menu:

<div class="nav">
    <ul>
        <li><a href="#">Lorem Ipsum</a></li>
        <li><a href="#">Dolor Sit Amet</a></li>
        <li><a href="#">Consectetur</a></li>
    </ul>
</div>

Because I am going to use a mobile first approach, the menu will start out as a vertical list:

@media screen {

    .nav li {
        display: block;
    }

}

On larger screens, the menu will be converted into a horizontal list:

@media screen and (min-width: 60em) {

    .nav li {
        display: inline;
    }

}

The navigation menu will now adapt to the size of the screen. The next job is to use JavaScript to collapse the menu at small screen sizes and add a control to toggle the menu on and off.

The script is very simple. The first part adds a link to the top of the menu to act as a control:

// Get existing nav elements
var nav = document.getElementsByClassName('nav')[0];
var ul = nav.getElementsByTagName('ul')[0];

// Create new nav control elements
var control = document.createElement('div');
var link = document.createElement('a');

// Function to add control elements
var setNavControl = function() {
    link.href = '#';
    link.innerHTML = 'Show Navigation';
    control.className = 'mq-control';
    control.appendChild(link);
    nav.insertBefore(control, nav.firstChild);
    ul.className = 'mq-small-hidden';
};

// Add the nav control elements
setNavControl();

The toggle control only needs to be visible on small screens, so I can now hide it on large screens in the stylesheet:

@media screen and (min-width: 60em) {

    .mq-control {
        display: none;
    }

}

The second part of the script then toggles a class on the navigation list element when the control is clicked:

// Function to toggle nav list class
var toggleNavControl = function(event) {
    if(ul.className === 'mq-small-hidden') {
        link.innerHTML = 'Hide Navigation';
        ul.className = '';
    } else {
        link.innerHTML = 'Show Navigation';
        ul.className = 'mq-small-hidden';
    }
    link.blur();
    return false;
};

// Call toggle function when user clicks the nav control link
link.onclick = toggleNavControl;

In this case, the text of the link is also updated. For this to work, this class should be hidden on small screens, but visible on large screens (where there will be no toggle control). Therefore, another bit of CSS is required:

@media screen {

    .mq-small-hidden {
        display: none;
    }

}

@media screen and (min-width: 60em) {

    .mq-small-hidden {
        display: block;
    }

}

The result is a navigation menu that collapses at small screen sizes but does not rely on any detection of browser size or orientation with JavaScript. It is quick to produce and accessible, and progressive enhancement means that the menu will function with or without the script.

Tools I use all the time

2012-04-18T00:00:00+01:00

Since I started making websites, I have been building up a list of useful tools, scripts, and other bits of software that just make my job a little bit easier. This is my current list.

Color Scheme Designer 3: An invaluable tool for finding complementary shades and colours, with a good range of options and a simple interface.
CSS Lint: A controversial choice, but still something I use regularly. You don’t have to do everything it says, but it will pick up errors and it might just make your code a bit more efficient. Always read the label.
Current IP Check: Does exactly what it says it does.
DomainTools WHOIS Lookup: There are plenty of options for WHOIS queries, but I have always found this one the quickest and simplest.
Down For Everyone Or Just Me: Also available at isup.me, this simple site will save a lot of shouting across the office.
Dynamic Dummy Image Generator: Have you ever needed a dummy image to fill a gap in hurry? This generator is quick and simple and even prints the dimensions on the image, so you can remember what they are later.
Font Squirrel: Not really a single tool, this is a great resource for finding open source web fonts. The brilliantly flexible @font-face generator has also made a lot of projects a lot easier.
HTML Lint: You know your code is valid, but is it pretty?
htpasswd generator: If you don’t have time to do it yourself, this can quickly add a bit of security to your site.
Is My Blog Working?: This site checks your blog for errors, efficiency, and visibility. More useful than you might think.
JSHint: A friendlier cousin of the venerable JSLint, this code checker has plenty of options and provides really useful feedback on your JavaScript code.
Mr Data Converter: What if you have some comma-delimited data that need to be in an HTML table, or a PHP array, or a JSON string, or something else entirely? Job done.
PXtoEM.com: Put away the calculator. This site converts your old-fashioned px units to shiny, responsive em units.
Responsive Design Test Bookmarklet: Still endlessly resizing the window to test your responsive design? Stop that. You can also use Matt Kersley’s version, but personally I find the bookmarklet more convenient.
Validator.nu: The original and best HTML5 validator.

And that is my list.

Query without jQuery

2012-04-14T00:00:00+01:00

One of the great advantages of using jQuery is that it makes it easy to select a set of elements on the page using the familiar syntax of CSS. But did you know you can also do that without jQuery?

The Selectors API has been around for a while now, but not many people know about it. The API is supported by all the recent versions of the major browsers, including Internet Explorer 8 and above. It provides two methods, querySelector() and querySelectorAll(), which take a CSS selector as an argument and which return a DOM object.

The querySelector() method only returns the first match, whereas the querySelectorAll() method returns all the matches as a collection of objects. For example, the following will return the first element with the example class:

document.querySelector('.example');

And this will return all the elements with the example class and the third span element child of each p element:

document.querySelectorAll('.example, p > span:nth-of-type(3)');

Using these methods, it is possible to select a relatively complex range of elements very quickly and easily. Obviously, these methods will only work with the CSS selectors actually supported by the browser and so it is not a replacement for all the possible jQuery selectors. And if you need to support Internet Explorer 7 or below, you are out of luck. But for other situations, it is a simple method that might save you some time and bandwidth.

Adding multiple load events

2012-03-08T00:00:00+00:00

This is an old tip, but it’s still useful. Starting a function when your page loads using window.onload is well supported, but you can only add one onload event. The newer window.addEventListener method should make this easy, but it doesn’t work with old versions of Internet Explorer. However, with a simple function, you can add as many events as you want without worrying about backwards compatibility.

The trick is to check if window.onload already exists and then to make a copy of it that can be added to a new window.onload event.

function addLoadEvent(fn) {
    var old = window.onload;
    if(typeof window.onload !== 'function') {
        window.onload = fn;
    } else {
        window.onload = function() {
            old();
            fn();
        };
    }
}

I first spotted this in The JavaScript Anthology by James Edwards and Cameron Adams, but I’ve seen it in all sorts of places since then.

Touch icons demystified

2012-03-05T00:00:00+00:00

If you have ever struggled to get your site’s icons working on smart phones, you should definitely check out Mathias Bynens’s excellent post on touch icons. A simple, clear explanation that leaves us with no excuse for our missing icons.

Doing more with links

2012-03-02T00:00:00+00:00

Hyperlinks are the most important part of any web page. A page without a link is a dead end, no more useful than a printed document. However, you can do a lot more with a hyperlink than simply linking to other pages.

As a web developer, writing a hyperlink to another page is probably one of the first things you learned:

<a href="http://www.example.com/">example web page</a>

And then there is the mailto: protocol for linking to an email address:

<a href="mailto:example@example.com">example email</a>

However, did you know that you can also use mailto: links to specify multiple email addresses, subject lines, and even the text of the email itself:

<a href="mailto:example@example.com,second@example.com,third@example.com?from=fromaddress&bcc=addresslist&cc=addresslist&reply-to=address&subject=subject%20text&body=body%20text">example email</a>

Smart phones provide more options, including the tel: protocol for telephone numbers. You cannot use spaces in the number, but you can add hyphens anywhere you want to make your code a bit more readable.

<a href="tel:+44-1234-567890">example telephone number</a>

And you can even use a hyperlink to send a text message:

<a href="sms:+44-1234-567899">text message</a>

As with mailto: links, you can specify multiple recipients and text of the message itself:

<a href="sms:+44-1234-567890,+44-0987-654321?body=body%20text">example text message</a>

Hyperlinks have always been vital for connecting web pages together. Now you can use them to connect to things outside of the internet as well.