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 freewebtips.co.uk, but brucelawson.co.uk – 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?
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.
As someone who is timezone-maths challenged and forever dialling into international conference calls an hour early or an hour late, I greatly appreciated the intuitiveness of the everytimezone iPad app by Amy Hoy (idea & design) and Thomas Fuchs (development).
David Storey, Patrick Lauke and I set about exploring why. The answer was simple: browser-sniffing. The app was only looking for browsers with the strings “webkit” or “Gecko” in the user agent string, and only feeding those browsers the necessary code. So we copied the code and, as a proof of concept, added “opera” to the list of strings being sniffed, and made trivial amends to the JavaScript to send -o- prefixed styles.
Additionally, the main CSS was only using -webkit-border-radius and -moz-border-radius, while Opera and IE9 use the naked property name border-radius. (See my Writing cross-browser, future-proof CSS 3 for more on this.)
Adding this to our proof of concept made the application work in Opera. There are differences; Opera doesn’t support CSS Gradients so those don’t show (although an SVG gradient as a CSS background-image would work perfectly well) and a bug means it doesn’t pick up the Futura font. But visual differences are to be expected on the Web; it’s the content that’s king (or, in the case of an application, the functionality).
We sent this to Thomas, and very sportingly he made the code live, so now everytimezone.com works in Opera too. The moral is that it’s pretty easy to make your sites work across all modern browsers and, while you might expect the user to be coming from one specific device, if your app is on the Web (rather than a W3C Widget or some proprietary format like Apple app store) you can expect visitors using other devices, browsers and operating systems.
Of course, it won’t work in IE9, even though it was announced yesterday that IE9 will support canvas, as the browser-sniffing locks out all versions of IE, past and future. That’s the downside to browser-sniffing: it’s completely non-futureproof. If you make a deliberate policy to block a browser, and a future version of that browser is capable of supporting your code, you have to go back and amend your blocking code. If you have hundreds of sites in your portfolio, that’s a massive commitment.
So congratulations s to Thomas and Amy for a lovely little app; I can now dial into conference calls with confidence and punctuality!
Here’s a quick tutorial (actually, rant) that came out of an aside I mentioned when doing my talk for Future of Web Design two weeks ago.
It came about when I was using the IE9 preview to test some sites. I noticed that a site that boasts rounded corners didn’t appear to have them in IE9, even though IE9 allegedly has border-radius support.
“Silly IE9″, I thought.
Wrong. Silly developer.
The difference between a pro developer and a wannabe is that the pro developer makes sites that are cross-browser and, as far as possible, future-proof. By contrast, the wannabe assumes that everyone is the same as him and therefore if the site works on the browsers he uses, that’s enough.
By using only vendor prefixes, the wannabe developer ensures that this nice part of the design will only work on those browsers.
A pro, however, cares about his client so doesn’t leave them with a site that will need changing later. A pro cares enough about his site’s users to give the design to their browser and let it do with it as it will.
How?
Simply by adding the non-prefixed cross-browser version of the property, he can add border-radius support for IE9 now, Opera now and any new browser that comes along in the future:
In the above example, border-radius is pretty mature, so IE and Opera jumped straight to using the standard prefix-less property, but other fancy CSS 3 properties are implemented only with vendor prefixes at the moment. Note I said “at the moment”; in two years’ time, a new browser may consider that feature stable enough to implement without a vendor prefix and, because you’re a pro rather than a wannabe, you want to ensure your code works in 2 years time as well as today.
For maximum compatibility, I advise adding all vendor prefixes (I do it in alphabetical order to help me remember) plus the non-prefixed version.
So here’s a version that future-proofs and cross-browserifies™ CSS3 transforms:
If, for example, IE adds support for the prefixless version, or uses the -webkit- version, you have one line—27 bytes—of redundancy. So what? And now your code works everywhere that has support, today and tomorrow.
And that’s how it should be.
I feel very strongly that using JavaScript to remove all that extra CSS away is a bad idea. Apart from the absurdity of using “20kb minified js to avoid 5kb ‘untidy’ CSS” (as one person commented about eCSStender), it’s ducking responsibility. If you as a developer choose to use experimental, pre-standardised code on a production site, then you need to live with the consequence of that choice. There’s no getting around it: experimental, pre-standardised code is susceptible to change. If the specification changes, you’ll need to change your CSS (which is easier to do if it isn’t being hidden away by some library).
Many developers have assumed that only Gecko and Webkit browsers will ever render CSS rounded corners or transitions, so have only specified their CSS with -moz- or -webkit- prefixes—sometimes while simultaneously berating other browsers for not supporting these properties yet. Note that Microsoft has announced that IE9 will support border-radius but if you only specify Firefox and Safari in your code, your future IE9 users won’t see those wonderful rounded corners anyway.
So, to widen the reach of your super-sexy designs, please take a minute to add the -o- prefix to your CSS transitions and transform declarations, and to add border-radius and box-shadow without vendor prefixes.
After 8 days, 11 universities and 9 kilograms of Nasi Goreng per person, the first Opera university tour of Indonesia is finished.
Here are Bruce’s slides: Web Standards for the Future, (PDF 550K). Note that I was tweaking and changing the slides depending on the University’s focus, so here’s the “full” version that includes everything. No university got all of these. The format is accessible PDF to make it small, as I’ve experienced Indonesian bandwidth speeds..! If you need another format, drop me a line. You’re welcome to share these with your friends or classmates – I hope they make sense. If not…well, you’ll have to invite me back again!
Zibin’s slides: Web Browser Industry (PDF 1M). This presentation is about the mobile web industry -trends today and tomorrow. I’ve also presented Opera’s four main products. The slide about top ten sites transcoded by Opera Mini in Indonesia was the showstopper. Audience giggled upon finding out that friendster bandwidth was more than the 2nd to 10th spot combined.
To celebrate the success of the Indonesian tour, we’ve published a new State of the Mobile Web report focussing on South-East Asian mobile browsing. Bad news for any web site that doesn’t follow Web Standards, with data like this:
Indonesia and Malaysia lead the way for mobile Web adoption, followed by Thailand and Brunei.
Indonesia leads the top 9 countries in page views, with each user browsing 358 pages on average in October 2008, well above the global average.
Growth rates are soaring: Malaysia leads the top 9 with 462.6% growth in users this year, followed by the Philippines (396.4% growth) and Indonesia (329.5% growth).
Friendster is the premier social-networking site in the region, with hi5 coming in second.
Nokia is dominant in the region, with brands like Sony Ericsson and Huawei competing for a distant second place.
I’ve been quiet lately as I’ve been gallivanting. Last week was exhausting but amazing, as I toured with Eric and Roberto from Opera giving talks at English universities on an Opera Education university tour.
Rather than just pimp the company and bore the audience rigid, I gave 45 minute talk about why and how you should use Web Standards for any-device development, and took the audience on a lightening tour around SVG, CSS 3 and (mostly) HTML 5. (The talk needs a labs build of Opera that includes support for the video element.) Grab the talk Web Standards for the Future on the Opera Developer Network blog.
Feedback shows that we got the balance right—in fact, some people actually said they’d like to hear more corporate information! People also caught on to my personal excitement about the subject matter. I’m really excited about using Standards like SVG and CSS media queries to build the mobile web. Our figures from our Opera Mini servers for September 2008 show
Egypt now has more mobile web use than Germany
Growth rates are soaring: Libya saw 3780% growth this year
Overall, Africa experienced a usage surge of 180 percent over the past nine months
And what’s also fascinating is that across the world people want the same kinds of sites: free (as in open and uncensored) information sites like wikipedia and the BBC, search, social networking and news. There is little difference between Poland, Indonesia, America and Egypt.
Coupled with the interesting work coming out of the w3c Mobile Web for Social Development, I think there’s a really exciting potential to use standards to help bring about change for good in the world. Or you may say I’m a dreamer. But I’m not the only one. (I’m also one of the pacifists in the browser war—and declared that War is Over, too.)
Anyway, thanks to all who came to see us and went for a beer—as well as to old friends Simon Mackie, Ian Lloyd and Jon Hicks who came out for a bevvy. And even to Elliott who made me fall out of love with my Omina.
Mobile widgets
Yesterday, I visited the Smartphone Show at Earls Court to deliver a 5 minute “speed dating” presentation about Opera Widgets. (90 mins, 12 tables, people come to a table, listen for 5 minutes until a whistle blows and audience moves on to next table.)
The presentation Opera Widgets: uses, development and standards won first prize for best product pitch, as voted for a panel including representatives of Samsung, Symbian and Nokia. I’m a bit surprised, as my talk was for developers and so I’d dressed in no-name jeans and a hoodie (more Naomi Klein than Calvin Klein) and then found myself surrounded by sharp-dressers.
Here’s me getting the award. I didn’t blub.
Oslo, Indonesia
Next week, more quietness as I go to Oslo to do an internal presentation to Opera employeers “What developers think of Opera” (so please let me know what you think in the comments or by email). Then it’s off to Indonesia to talk more about Standards, the developing world, SEO and the like.
After a question about image replacement on accessify forums, I began to explore the image replacement options that CSS 3 will offer us. There is a potentially a mechanism using the content property that requires no extra markup and which degrades well even with CSS on and images off, because it doesn’t hide the text it replaces.
I discuss it on the new Opera Developer Relations team blog (part of the forthcoming ODiN, the Opera Developers Network), so comments there please.
(You might consider subscribing to the ODiN blog, as it’s a group blog for the Developer Relations team to discuss all things Web; it’s not a place for pimping Opera and slagging off the opposition.)
CSS 3 image replacement
Since before the dawn of time, designers have wanted sexy fonts or images for headings, links and buttons on web pages. The adoption of @font-face for CSS to use any font a designer specifies will take away some of the use cases. The time-honoured method of using img in the source code, and using the alt attribute to as a text alternative still works, of course, and very nice it is too, but some designers prefer to use CSS to replace text with an image.
There is a variety of image replacement techniques, but they all add a background image and then hide the text, usually by moving off the screen. They all suffer from restrictions: they can only be used with opaque images, or against flat colour, or they need extra spans for style hooks. There’s also the problem of people who surf with images off, which is quite common for those using phones whose web use is metered. They don’t see the image, but don’t see the text either.
It’s interesting to note how the browsers style this differently. To centre the logo, you need to style the h1 with text-align:center, as if Opera centres the real text and then replaces it with the image. Safari will only centre the logo with margins, as if it replaces the text with an virtual img tag, which is then impervious to text-align.
What should browsers do if the image can’t be shown?
I think, in any circumstance that a browser can’t show an image, it should show the content of the element in the natural position for that text. That would ensure that this CSS 3 image replacement technique degrades well when CSS and images are off.
This behaviour would be similar to iframe: “The information to be inserted inline is designated by the src attribute of this element. The contents of the iframe element, on the other hand, should only be displayed by user agents that do not support frames or are configured not to display frames.” In a similar way, html has a fallback mechanism for images and objects: when it can’t show the image, it shows the alternate text.
Here’s where the support for this image replacement mechanism gets experimental, even in the highly standards-compliant browsers. This is because the specification changed between CSS 2.1 and CSS 3.
CSS 2.1 said
If the user agent cannot display the resource it must either leave it out as if it were not specified or display some indication that the resource cannot be displayed. CSS2 spec
So the current "standard" says that it should either show the contents of the element (the actual text between the tags), which makes sense to me, or some sort of “image not found” icon, which seems to me to be the worst of all worlds. If a screenreader or a search robot gets the plain text, why not a user who has images switched off?
The CSS 3 spec allows you to set a series of fallbacks, much like when you set font-family. So here, the browser will try to replace the header with a movie, then an animated gif if it can’t find or display the movie, or a standard jpg if it can’t find or display that gif, and if it can’t render any of those, it will just show the contents of the element:
If no alternatives exist, then ‘none’ is used as a final fallback…Thus to make an element fallback on its contents, you have to explicitly give ‘contents’ as a fallback. CSS 3 spec
To me, it’s odd that anyone should want to display nothing instead of the content, let alone make it the default, but at least the new specification allows you to unambiguously tell the browser to display the contents of the element: it’s not allowed to "choose" between the text and a "image not found" icon.
What do browsers do?
However, browser support is still experimental as the generated and replaced content module of CSS 3 is still susceptible to change. My no-images test page shows that Opera and Safari still have problems following the CSS 3 spec fully.
Conclusion
Once the CSS 3 spec is finalised and the browser support is solid, a foolproof way of doing image replacement will be available to us that is accessible to screenreaders and which degrades gracefully with CSS off and with images off.
Last year, the webkit developers have been adding some interesting experimental additions to CSS that gives some sexy effects such as animations, transitions and masks. There has been some discussion about whether we should add such effects into the full CSS spec when they’re already available in SVG: is it desirable or even correct to duplicate features across two technologies?
You might be forgiven for thinking that as a web standards wonk I would be dead against such mixing—surely separation of structure, markup, behaviour and animation is a holy grail for a standardsista?
But my take is that it’s perfectly fine to extend CSS this way. In fact, it’s highly desirable. My initial attraction to standards wasn’t because of philosophical purity, but because it seemed to me that there are practical benefits to use standards: maintainability; portability and simplicity. Sure, CSS has its complexities due to browser support, but at its heart it’s an extremely simple idea.
It reminds me of some of the discussions a few years ago when CSS support was new and some DOMscripting experts believed that JavaScript should be used instead of the :hover pseudoclass, because hover is “behavioural” rather than stylistic. They are probably right; :hover is about behaviour. But they lost the argument because it’s simpler to write a :hover rule than a JavaScipt event handler.
We poor web developers have enough to get our pretty little heads around, what with mark-up, CSS, script, server-side techniques, accessibility, without learning loads of spooky xml just to get a sexy bit of eyecandy going.
Nothing against SVG: it’s great for sexy animations (it’s so sexy that it’s an acronym of “Sleep with Voluptuous Girls”) and it’s perfectly possible already to use SVG to get a bit of menu bling, but I know that I’d much rather add a rule in CSS (that is ignored by browsers that don’t get it) than learn another language. (There’s little overhead to allowing both because browsers would be making use of the same code and routines to display the effects whether they are called from CSS or SVG).
What’s your take?
Opera Dragonfly alpha 2 released
David-not-Dave has been hard at work making Opera Dragonfly a better debugging toolbar for web developers. Alpha 1 was usable but clunky, but now he’s added commandline auto-complete, CSS editing, docked window mode, a debug menu, as well as many bug and stability fixes.
