Archive for the 'CSS3' Category

Reading List

The last reading list of the year is a bumper one, so you have plenty to read over the hols. Enjoy!








Kerrrazy Shit!

Notes on Adaptive Images (yet again!)

All the cool kids are doing responsive design, it seems. This means fluid designs, having some hot media query action to reformat your layout depending on screen size, and ensuring your images are flexible so they don’t break out of container, generally by setting them to {max-width:100%;}.

Having images scaling down presents a problem though, if you’re a performance-minded sort of chap(ette). Why send a 300K 400 x 800 image that would look lovely on tablet device attached to wifi, but which takes ages to download on a 3G phone, and which gets resized by the browser to fit a 320px wide screen? Not only are you wasting your user’s bandwidth and time, but not every browser is created equal and not every resize algorithm makes pleasing end results. The CSS 4(!) image-rendering property can help with this but it only hints to the browser.

Sending the right-sized image to devices without wasting bandwidth is one of the knottiest problems in cross-device and responsive design at the moment. In the 24ways advent calendar series of articles, the subject has been discussed twice in eight articles (by Matt Wilcox and Jake Archibald). There are numerous other techniques, as well, such as tinySrc and the Filament Group’s Responsive Images.

All these are very clever, different solutions to solve the same problem, and they all rely on scripts, or cookies, or server-side cleverness or (in the case of Jake’s ideas) dirty hacks and spacer GIFs. I’m reminded of Image Replacement techniques from more than 6 years ago, which were over-engineered solutions to the problem better solved by CSS web fonts.

Let’s recap. We have several images, of different sizes, and want to send only the most appropriately-sized image to the browser. The circumstances differ. The canonical use case is to send smaller, lower-resolution images to smaller screen-sizes on the assumption that connection speed is slow and they have low-resolution displays. This isn’t the case, though. Some people are using retina displays on fast wifi networks. SO, while currently CSS Media Queries allow us to detect screen width and pixel density, we need new media features such as network speed/ bandwidth.

The DAP is working on a Network Information API, there’s a Phonegap version for native apps, and a Modernizr detect, but using script for this seems much harder than being able to access it via Media Queries, and if you just want to rearrange CSS layout, CSS is the place to detect it. (Purists may argue that network connection isn’t a characteristic of device, but in your face, purists!)

Once you have a media query, you can swap images in and out using the CSS content property:

<img id=thingy src=picture.png alt="a mankini">
@media all and (max-width:600px) {
 #thingy {content: url(medium-res.png);}

@media all and (max-width:320px) {
 #thingy {content: url(low-res.png);}

@media all and (network-speed:3g) {
 #thingy {content: attr(alt);}

A browser that doesn’t support Media Queries, or doesn’t report “true” for any of the Media Queries shows the picture.png, which is the src of the img. A browser that is less than 600px replaces picture.png with medium-res.png. A 320px or narrower browser replaces picture.png with low-res.png. A browser that is only connected via 3g replaces the image with its alt text.

I first researched this technique in 2008 as a way of doing image replacement without extra markup (ironically enough). The first two media queries only works in Opera and Chrome at the moment, as they’re the only browsers that fully support content without :before or :after. (The network-speed media query works nowhere as I just made it up).

Recently, Nicolas Gallagher experimented with generated content for responsive images, and unfortunately discovered that there are no advantages to the technique because browsers always download picture.png, even if they never show it because they immediately replace it. Perhaps this could be optimised away by browsers, but there would still be the double-download problem with current browsers.

My mind turned to HTML5 video. Here we have an element that has the ability to specify multiple sources (because of different codecs) and can also switch sources according to media characteristics. It borrows syntax from Media Queries but puts them in the HTML:

<source src=high-res.webm media="min-width:800px"> 
<source src=low-res.webm> 
<!-- fallback content --> 

I firmly believe that if something as new-fangled as video can be responsive in a declarative manner (without needing script, APIs, cookies or server magic) then responsive images should be similarly simple.

Previously, on the mailing list, a new <picture> element was proposed. I mashed up that idea with the already-proven video code above and came up with a strawman:

<picture alt="angry pirate">
<source src=hires.png media="min-width:800px">
<source src=midres.png media="network-speed:3g">
<source src=lores.png>
   <!-- fallback for browsers without support -->
   <img src=midres.png alt="angry pirate"> 

This would show a different source image for different situations. Old (=current) browsers get the fallback img element. As I said, this is a strawman; it ain’t pretty. But it would work. (It’s discussed in my recent Smashing Magazine article HTML5 Semantics.)

I prefer the media queries to be in the HTML for two reasons: you don’t need to have ids or complex selectors to target a particular image, and (more importantly) many content authors use a CMS and have no ability to edit the CSS. (Although the nasty <style scoped> could solve this.)

On the other hand, I might be over-engineering the whole problem. I chatted informally with my colleague Anne van Kesteren, glamorous Dutch WHATWG inner circle member. There’s a school of thought that says everything will be 300ppi and networks will be fast enough, so this is really an intermediate problem until everyone starts using highres graphics and all displays go from 150 to 300. Standards are long term, and by the time we have a standardised version, the problem might have gone away.

What do you think?

(Matt Machell pithily pointed out “if only browsers hadn’t forgotten the old school lowsrc attribute for images“.)

Looks like our chums at WHATWG are discussing this too.

Reading List

Links’n’stuff that I’ve tweeted, for those who don’t spend their days on twitter but who work instead.

HTML5, markup

Groovy webdev stuff


Vendor prefixes


HTML5, hollow demos and forgetting the basics

My heart sinks when I see the latest flurry of tweets about some new “HTML5” demo. As someone else said, it’s usually a warning that you’re about to visit a browser-freezing lump of JavaScript without a hyperlink in sight.

I feel the same way when I see someone draw an image of the IE logo, a map of Paraguay showing every branch of Greggs, or a gyrating representation of Konnie Huq’s spleen using only CSS, because I know that the HTML will be a series of empty <div>s with no content at all.

“But it’s just a demo!” you will protest. True. And demos exist to kick the tyres of a technology, to see what it can do and what its limits are. But people learn from demos. People pick them apart to see how they work, and hack them about. So using fundamentally the wrong technology to achieve an eye-candy result doesn’t help anyone learn.

The biggest danger is when that demo mentality leaks into production websites.

The Web is about content. Sometimes that content is video, but we can ensure a text-based representation exists for older browsers, lower-specced devices, slower bandwidths and – of course – people who can’t consume video. Content on the web should be available to all using progressive enhancement, polyfilling and the provision of text alternatives.

I agree with the anonymous author of the provocatively-titled Reckless web development practices are encouraging idiots:

Because these sites are absolutely reliant on JavaScript, or Flash, or a particular browser … in order to display their content, the sites are failing at their job. They’ve taken us back to the early 90s in terms of the maturity of the web. They show an absolute disregard for the building blocks of the web in favour of ‘the shiny’ — a repugnant phrase which reflects the shallowness at the heart of many web workers’ outlook. They are style over content.

This isn’t true 100% of the time; a tiny fraction of the Web is games. Games don’t degrade terribly well to plain text or map to HTML semantics. But the fact that we can script first person shooters in <canvas> rather than Flash isn’t a signal to abandon responsible practices on non-game sites – practices such as choosing the most appropriate element for the job and ensuring that the content is available to those unfortunate peasants who aren’t running Opera.Next, a WebKit nightly or Firefox Aurora on the latest greatest hardware.

My colleague Karl Dubost wrote 3 rules of thumb for Web development:

  1. Can I bookmark this information? (stable URIs)
  2. Can I go from here to there with a click? (hyperlinks)
  3. Can I save the content locally? (open accessible formats)

It seems to me that there is nothing inherent HTML5 and associated technologies to diminish the relevance of these rules.

In the first edition of Introducing HTML5, Remy and I closed the book with this advice:

Forget the marketing B.S. of “Web 2.0.” We’re at the beginning of Web Development 2.0: powerful languages like HTML5, SVG, and CSS3 will revolutionise the way we build the Web. Browsers support more and more of these aspects of these languages (and you can be certain that more and more support is being added daily).

Of course, have a play with the new features. Experiment with the new markup structures, manipulate video on the fly, and build fun and attractive games and apps that use <canvas>. By reading this book, you’re demonstrating that you’re an early adopter, ahead-of-the-curve, so please set a good example to your colleagues; respect those visitors to your new creations who have older browsers or assistive technologies.

For the second edition (coming soon!) we were worried enough about The Shiny that we’ve augmented it:

It’s vital that we remember that we are dealing with Web development. The Web is based on URLs, hyperlinks and is a method to deliver content. If your amazing demo is basically content-less <div>s being flown around the screen by JavaScript, or if your content is text-as-pixels scripted with <canvas>, if you require a mouse or a touch-screen, or if you have no links, no content or no URLs for bookmarking or linking to, ask yourself: am I developing for the Web, or am I re-inventing DHTML or Flash intros that just happen to run in the browser instead of a plugin?

We mustn’t forget the basics.

CSS Regions, CSS Exclusions

At Web Directions and Opera’s very own pubgeekmeetupaganza, Stephanie Rewis and Peter Gasston discussed some of the new proposals for layout in CSS, including the CSS Regions and associated CSS Exclusions specs written by Adobe. For the first time, layout is “unboxed” and text can flow in (or around) arbitrary shapes.

Part of me thinks “yay, cool!”. The other part of me thinks that it’s a shame that some designers still haven’t yet come to terms with the idea that the Web’s not print, and still hanker after pixel-perfect layouts that mimic highly-designed magazines rather than design for a new medium.

CSS Regions are doubtless coming for iPads and other such devices where glossy magazine publishers feel safely DRM’d away from the nasty open Web, so we might as well get used to them.

At the moment, the regions have to be manually expressed as a series of points, but it’s easy to imagine some sort of CMS that allows the page author to upload a page’s background image which is then overlaid with a canvas/ SVG-based app that allows the user to trace arbitrary paths on the image (like Photoshop’s lasso tools) or choose primitive shapes such as circles, rectangles etc, and then the paths can be exported as CSS declarations.

Another useful feature that people have suggested would be the ability to tell the browser via CSS to wrap text using the alpha channel of an image so you wouldn’t need manually to define paths.

You can try Adobe’s prototype. It’s all clever stuff.

I’m looking forward to debugging pages laid out in a combination of floats, absolute positioning, grid layout, template layout, flex-box, CSS tables, multicolumns, regions and exclusions. And I bet you are too.

Mobile Web talks, SxSW and Bath

On Saturday Saturday 12 March at 5:00PM in Ballroom C of the Austin Convention Center, I’m doing a talk snappily-titled Web Anywhere: Mobile Optimisation With HTML5, CSS3, JavaScript.

This will be a really fast-moving talk with tips and code snippets you can use right away. We’ll cover

  • mobile web philosophy: what is “mobile web”?
  • The three methodologies for mobile web development
  • What new goodies HTML5, CSS 3 and JavaScript offer us
  • Tips and tricks (code) to make your site faster on mobile
  • Apps vs Web and how the boundary is blurring
  • What’s coming soon, with hopefully a preview of what’s cooking in Opera Labs

I doubt many people will be there—it’s pretty late in the day, but do come along if you can. Otherwise, please come and say hi at the Opera booth in the trade show; there will be a giant red O suspended from the ceiling, so you can’t miss us.

I’m doing a cut-down version (1 hour into 40 minutes) at The Big M Conference in Bath, UK, where Patrick Lauke will be giving a 3 hour workshop.

Here are the slides.

Reading list 3

Stuff that people who aren’t following my tweet stream may have missed.

Polluter pays: building it right

I was having a conversation with someone who was developing a site and who had it looking good in some browsers and not others. She had markup like this:

<div id="before-nav"></div>
<div id="before-footer"></div>

with the empty <div>s being used to hold the top half of an image of some rounded corners. The page’s document landmarks needed rounded corners, and my friend was using images rather than CSS3 border-radius so it would work in IE<9.

Her problem was lining up the top half of the background effect with the bottom half, as they’re behind two separate elements and browsers have inconsistent browser stylesheets. So to get it to line up she was going to reset loads of elements and potentially resort to CSS hacks.

The trouble with this is that you’re then building hacks on top of hacks. Using completely empty <div>s for presentational purposes is already hacky, and it means that Opera, Firefox, Safari, Chrome and IE9 get markup and images they don’t need, as they could just use border-radius.

It might seem obvious, and the “build for good browsers, then hack for bad browsers” methodology has been around for a while, but let me gently remind you: don’t penalise the good guys. In Web design, unlike the real world, the polluter pays.

So, my friend should have designed her site with no extra unsemantic thingummies, and used border-radius to achieve her design effect. (If she were using more experimental CSS3 properties, she’d neeed a cross-browser future-proof vendor-prefix stack.)

Once this is tested and lovely in Opera, Firefox, Safari, Chrome and IE9, she can add one line into her CSS, courtesy of CSS3Pie, and her CSS rounded corners will work everywhere, but only the naughty browsers download the extra stuff.

This works nicely for CSS. For HTML5 APIs, there are all the HTML5 Polyfills. Sure, there are edge-cases and undetectables, but as a general methodology, the polluter-pays approach will speed up your development and leave you with clearner, less-hacky and therefore more maintainable code.

Dear Bruce, your site is ugly. Sort it out.

It’s usually nice to receive feedback. But not always. Before Twitter became so popular an outlet for one’s ephemeral thoughts, I would occasionally receive emails berating me for having the temerity to publish personal blog posts and urging me to return to posting techy stuff. I would always answer these

Dear kindly correspondent, as you may have noticed, my site is not called, but – the unique portion of which is my name. This is not a co-incidence; it is because this is a personal site which I pay to register and I pay to host and therefore consider it my personal space upon which I can write personal posts if I so choose. Please do not read them if they offend you.

That seemed to work: I never heard from those people again, anyway.

This morning, someone had taken the trouble to write:

Im just getting into coding as i am myself a Graphic Designer. And i keep seeing your book advertised in most the places im learning from. I was suprised to see (with no offence meant) that your site is not the best looking around. Sorry i know thats probably not your general worry here, but personally i think for someone who seems quite well known you should have a much more attractive site!

When I launched this site in 2003, I was aware that I am graphic-design challenged. Being an old punk rocker, and admiring Jamie Reid‘s punk do-it-yourself aesthetic, I spent as long as two to three hours sticking bits of newspaper to paper and scanning it. In the intervening seven years, I’ve even added the Holy Grail of design, border-radius, and spent days and days reading the HTML5 spec to craft the best markup I could.

Should I now add all the other things that current web design mandates by law: hundreds of empty nested divs upon which to hang transitions, gradients, reflections and transforms that distract from the words, double the rendering time and drain mobile batteries?

Or point out that markup and semantics != visual design?

Or tell my correspondent to STFU?

Rant: HTML5 != CSS 3

Trying out my new Ranting Hat, a present from Japan from Nedjma. Please note that rants are just that, and not necessarily eloquent or factual. (And I know that Eric Meyer and Jeffrey Zeldman are not the only two social liberals in the USA; I’ve actually met the other three.)

Oh, and do I have to say that this is a joke, is personal and nothing to do with my lovely employers at Opera? Unfortunately, I probably do.

(I’ll transcribe it when I’m not so tired)
Transcription thanks to the splendid Karen Mardahl, follow her at @stcaccess.