Most web developers who have viewed their work in an iOS device know that Safari for iOS likes to zoom in on the page and do weird things to font size when you change the device’s orientation from portrait to landscape. A too common way to prevent that is to completely disable the user’s ability to zoom, which you really do not want to do.

The reason is simple. Browsers and assistive technology haven’t implemented the HTML5 outline algorithm yet (the only exception I’m aware of is JAWS, which gets it wrong, as Jason Kiss explains in JAWS, IE and Headings in HTML5).

As columns of text become narrower, the risk of a single word being longer than the column width increases. When that happens, the text normally extends outside the column (unless the column element’s overflow property has been given a different value than the default visible). The effect can be anything from just a slight visual glitch to unreadable text. Either way it’s something you don’t want to happen.

The main issue Chris talks about is omitting semi-colons at the end of JavaScript statements, the subject of a current JavaScript drama. Doing so is valid syntax in many cases, and browsers parse and execute the code fine. However, it does not improve code readability for humans, who are often as important to target as the browsers that run the code.

This is good since it gives you an opportunity to provide the user with hints regarding what they are expected to enter in the field. What is not good is that the placeholder attribute is often used as a substitute for the label element. I’ve seen this in various demos of the placeholder attribute as well as in demos for scripts that emulate the placeholder attribute in browsers that don’t natively support it. So some developers appear to misunderstand what the placeholder attribute

I agree completely. Too many people include too much by default in their web projects these days. Boilerplates, polyfills, shivs, crazy conditional comments, rare or uneccesary meta elements, and so on.

In summary: following an in page link (a link that targets an element on the same page, like Skip to main content) does not properly move keyboard focus in WebKit browsers. This means that when you press tab after activating an in page link, focus is moved to the first focusable element after the link rather than the first focusable element after the target.

I recently ran into a problem that was really hard to figure out. I was working on a responsive design where I used img {max-width:100%;} to make sure that images would be downsized rather than overflow in narrower viewports.

Sometimes the only way of incorporating data from a third party is by loading it in an iframe element. A few examples are financial reports, e-commerce applications, and ticket booking applications. Using an iframe is not ideal for many reasons, one of which is that it can make multiple sets of scrollbars appear on the page. Not only does it look ugly, it also makes the site less user-friendly. But there is a workaround.

Changing only the colour can be a bit subtle though, especially for people with colour vision deficiency. Depending on which colours are used to differentiate between visited and unvisited links it can be hard to tell them apart. To make the difference more obvious, there are a number of techniques involving background images, generated content (like the one I describe in Check marking visited links), and other CSS properties. However, if you’ve been using any similar tricks to style visit

Unfloating a floated element is as simple as specifying float:none. Width doesn’t seem to be quite as straightforward – lately I’ve come across several cases where people use width:100% to undo explicitly specified widths when they should be using width:auto instead. So here’s a brief explanation of the difference.

This was pretty puzzling as I couldn’t remember having any problems with buttons in Safari for iOS before. After taking a closer look at the CSS I was using for these particular buttons and the CSS I had used previously, I managed to find out what made the difference.

As I have noted in a couple of blog posts recently, there are some cases when CSS has quite unexpected results in screen readers (or the way web browsers create the accessibility information they hand over to screen readers). If you haven’t read them, the posts are Screen readers, list items and list-style:none and Using display:table has semantic effects in some screen readers.

That isn't necessarily a problem provided that you use progressive enhancement and unobtrusive JavaScript. If you follow those principles, content and basic functionality will still be there when scripting is unavailable. Many of us understand that. But one thing I’ve noticed is that some developers forget to consider semantics or accessibility in the markup they use JavaScript to insert.

With that said, sometimes you have to do things you don’t really want to. Like styling select elements, which I’ve recently had to find a way to do. There are quite a few workarounds for doing this out there. However, most of the ones I looked at replace the select element with a bunch of links which changes semantics and behaviour a bit too much for my tastes. I couldn’t find any implementation that I was completely happy with, so I took the best one I could find and tweaked i