Archives filed under "web standards"

So true.

It’s not unlike the situation with bugs: you solve one, and 14 new ones pop up.

Web designers who are interested in providing an optimal experience for viewports of widely-varying width—I’m looking at you, traditional computers, iPhone & iPad—will be very interested in responsive web design.

A term coined by Ethan Marcotte in a revolutionary article (and compelling read), responsive web design takes together a number of elements that have been rattling around recently—CSS3 media queries, fluid grids, flexible images, in particular—and Marcotte showed how they can interact with one another to provide a powerful web presence across widely varying viewports. Since then, he’s expanded upon the subject by publishing a book. It’s the single best place to go in order to get up-to-speed on the subject—although, like all “A Book Apart” titles, it’s woefully small & at best a very general introduction to the subject.

I’ve just completed the process of converting a site I’ve been working on to a responsive design. This site is an ideal candidate for a responsive web design approach in that it’s an academic site & the participants, the prime candidates to access its content, are all around the world. The site provides information about upcoming workshops, meaning that the target viewers (participants in the academic project) are very likely to access the site’s content while using handheld devices such as the iPhone or iPad. As such, I received a nice introduction into the subject, particularly with the real-world repercussions.

Janus Cascade

One thing that I didn’t notice in Marcotte’s article or book is that by wrapping our designs in media queries, a style’s cascade is now two-facing. There are massive implications with this approach, and if you take a pixel-based approach, as opposed to the percentage-based approach Marcotte takes, all hell breaks loose. Here’s an example to show what I mean:

Say you have a DIV & when the viewport is a desktop size, you want it to be 100 pixels & float left; but on an iPad’s portrait mode, you want it to remain the same size & float right; and finally, on an iPhone portrait mode, you want it to be 300 pixels & display as a block. Here’s how you might go about that:

  @media screen and (min-width: 1040px) { /* For Traditional Computers */
    div { width: 800px; float: left; }
  }

  @media screen and (min-width: 810px) { /* For iPad: Portrait Mode */
    div { float: right; }
  }

  @media screen and (min-width: 320px) { /* For iPhone: Portrait mode */
    div { width: 300px; display: block; }
  }

If you looked at the page with the DIV in question in your various viewports, everything would seem to be OK. But for the sake of experimentation, on your desktop machine, resize your browser window.

You’d be in for a shock if you resized your browser window. When the browser’s wide, then the DIV is big & floats left. Shrink the window & the DIV floats right. What happens when you make the browser really small? Well, actually, it’ll still float right because you haven’t overridden the iPad portrait mode declaration. Now refresh your tiny browser window & you’ll see that the DIV now displays as a block. That’s because it’s not cascading the iPad portrait mode’s float declarations, because that condition hasn’t been met in your refresh. As Keanu Reeves would say: Whoah!

Now start resizing the window from that tiny width. You’ll notice that your floats aren’t floating, but displaying as a block; and furthermore, your box has not jumped to 1000 pixels in width, but has remained at 300 pixels. Again, it’s because you’re inheriting the display: block from the iPhone portrait mode declaration. See? Cascades now work two ways, depending upon how you resize. Double whoah! The solution here is to explicitly state in your iPad portrait mode that you want the div at 800px & also declare in each case where you want the DIV to float & how it’s to be displayed in the document flow.

Go With Percentages, Not Pixels

The other implication that I’ve only grazed above: working in pixels is a bad, bad idea. This is the reason why Marcotte exclusively refers to items in percentages: it’s a more elastic approach & won’t fall apart quite as thoroughly as pixel-based approaches. And in my experience, when I switched from pixels to percentages, the site coalesced really quickly.

Go Forth Warily

Freaky deaky responsive web design: you probably have a lot more testing to do now. And for Internet Explorer (prior to version 9, which is very good), you’ll need some help for reading media queries.

Make no mistake: responsive design is the future of web design & with the explosion of handheld devices, it’s very much worth it: no longer will you have to design multiple sites for different classes of devices. In fact, the first non-personal site, the Boston Globe, has just launched as a responsive site, and the power of this unified approach is self-evident.

That the recent brouhaha over the death of XHTML2 is totally overdone. After all, the spec was so fucking obtuse & abstract that no browser vendor was going to implement it.

I mean, the authors wanted to get rid of the IMG tag, fer chrissakes!

If you’re a web developer, you’re going to be interested in the fact that Microsoft Internet Explorer 8 has been released.

There’s a lot of good news: it’s passed the Acid2 test & supports CSS tables, making it the last major browser to achieve both of these. Apparently it’s also more secure than previous versions, although that has yet to be fully tested in the real world. Finally, it’s also faster than previous IE versions, although according to Computerworld, IE8 is still the slowest browser based upon SunSpider benchmarks. In my (very limited) experience, IE8 is significantly faster than previous versions—not dramatically so against Safari or Firefox, however—but more importantly I’m grateful that it hasn’t munged up any of my layouts!

What a difference a few years make: when IE7 came out, it’s only real competition came from Firefox (with Opera as well, of course). It’s now a very full field, with Safari & Chrome freely distributed as well. It’s really great to see such strong competition, and it has to be said that the IE team seem to have done a good job on the browser.

It remains to be seen what the new release will mean for IE’s declining market share; I can’t speak to that. For developers, IE6 was pretty odious & IE7 a bastard step-child of a browser, as it only made half-steps towards standards compliance. IE8 has removed support for HasLayout, the code that trips up most developers, including me.

But… the insta-reviews aren’t positive, and although they’re concentrating mostly upon installation problems, the centre of my concern lies in advanced standards support. There’s still a lot of room for improvement from a developer’s point of view. Whilst the other major browsers have passed the Acid3 test, IE8 still fails, and pretty miserably.

Just as important is the lack of CSS3 support. One might argue that CSS3 isn’t a full recommendation yet, but its development was modularised so browser vendors could start implementing portions as they were completed. And on this score, Safari & Firefox roundly beat IE8. I know I’d love to have multi-column & RGBa support across the board. Yet even if IE8 did support these, it’d be years before we could use them with confidence, that is until older IE versions finally dropped off the face of the earth The fact that the IE team haven’t supported them yet means the day is that much farther away.

Maintaining Older Browsers for Testing

If you’re like me, you’ll have multiple slices of Windows so you can test sites against IE versions. To not get tripped up & accidentally overwrite an IE6 or 7 install because of an automatic update, I’d suggest you install the IE8 blocker toolkit.

So Microsoft have distributed the next public release of Internet Explorer 8. If you’re using XP (and who among you, honestly, is using Vista?), you can get it here.

Here’s an interesting note in the “known bug” list: looking at the markup within an iframe tag is impossible if the first item within is a comment. Ohforchristssakeareyouserious.