BlogmyQuery – BMQ

You have likely seen the term �progressive enhancement� quite a lot, especially if you�re a regular reader of this website. But do you understand exactly what it means, and do you try to apply it in every detail of your daily work?

If the answer is no, you�re far from alone. The last couple of years, with HTML5 (or more correctly parts of CSS3 and various JavaScript techniques) becoming the new Ajax, it seems that people are so eager to apply the shiny new front-end toys that they forget that the Web is supposed to be universal. And in doing so, many developers unfortunately forget about or ignore progressive enhancement.

One reason may be that there aren�t enough resources that explain progressive enhancement in a practical and easy-to-digest way. Luckily, Aaron Gustafson has written a book called Adaptive Web Design that does just that.

Read full post

Posted in (X)HTML, Accessibility, CSS, JavaScript, Reviews.

Copyright © Roger Johansson

One of the problems that HTML5 aims to solve is that of heading levels, particularly in documents where content is cut and pasted from other documents or inserted through syndication from another source. In previous versions of HTML you need to manually make sure that any headings in the inserted or copied content are of the right level, i.e. h1-h6.

You can keep using h1-h6 in HTML5, but you can also choose to use only h1 elements for all headings and rely on the HTML5 outline algorithm to sort out the heading hierarchy. If you do this, however, you should be aware that currently there is very little support for the HTML5 outline in web browsers, screen readers and developer tools.

I bring this up because I have seen some HTML5 articles and blog posts that mention the new document outline without emphasising the current lack of support. That lack of support is a problem because it makes headings less useful to people who need a proper document outline to better understand content structure and use them as an aid for navigating within web documents. The most common example is screen reader users.

Read full post

Posted in Accessibility, HTML 5.

Copyright © Roger Johansson

Reading Ethan Marcotte’s book Responsive Web Design was a strange experience in some ways. While much of the techniques and philosophies described in the book are familiar to me, reading about everything from flexible design to mobile first with media queries carefully distilled into one book was something of a revelation that brought back feelings from over a decade ago.

Ethan opens the book with this:

As I begin writing this book, I realize I can’t guarantee you’ll read these words on a printed page, holding a tiny paperback in your hands. Maybe you’re sitting at your desk with an electronic copy of the book up on your screen. Perhaps you’re on your morning commute, tapping through pages on your phone, or swiping along on a tablet. Or maybe you don’t even see these words as I do: maybe your computer is simply reading this book aloud.

Ultimately, I know so little about you. I don’t know how you’re reading this. I can’t.

Read full post

Posted in Accessibility, CSS, Reviews.

Copyright © Roger Johansson

The setting I mentioned in iOS tip: how to zoom on web pages that have disabled user zoom lets you zoom on all web pages, which is great. But it’s even better than I originally thought.

Instead of having to double-tap with three fingers to zoom the entire screen of your iPhone, iPod Touch or iPad, it turns out that enabling the Zoom setting actually makes Safari ignore any meta name="viewport" scaling settings on the page. You can zoom in and out the normal way by using two fingers.

Read full post

Posted in Accessibility, iOS.

Copyright © Roger Johansson

In a recent project I needed to add a button to a column on the page. The design called for the button to be centered in the column. This turned out to be slightly less straightforward than I initially thought.

Centering elements is normally taken care of by giving them a width and auto for horizontal margins. In this case I didn’t want to set a width on the button since the site will be available in several different languages, so the amount of text on the button will differ.

My first thought was to just avoid setting a width since form controls are replaced elements and have an intrinsic width anyway once rendered by the browser, so I might be able to get away with this:

.button {
    display:block;
    margin:0 auto;
}

Read full post

Posted in Browsers, CSS.

Copyright © Roger Johansson