The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web.
Here are some of the most useful commentaries (both for and against). Mostly I haven’t commented, except for Andy Clark’s piece which contained factual inaccuracies which could mislead readers.
Opera confirms WebKit prefix usage – the .net magazine article that broke the story, based on a leaked email and catching me unawares as I was heading out for the airport
Why O, why? by David Kaneda. This is more balanced than I expected, as the author works for a only-works-in-webkit-woo! mobile framework/ library thing, although one of his 3 pieces of practical advice is to detect WebKit browsers and block them from Opera’s demos, thereby opening the Web by closing the Web, and helping users by hurting users
and the one that neatly sums up my personal ambivalence, and then acceptance of our move: Opera, -webkit-, and the purpose of browsers: “The secret to reaching “Acceptance” is to simply ask yourself, “What are web browsers for? What is their absolute primary purpose? The answer: A web browser’s primary function is to display web content.”
My favourite commentary has been Daniel Davis‘ interview with Dr Stanley Dards, wise old man of the web:
Mobile
How we use our mobile devices “more people have mobile phone subscriptions than have electricity or safe drinking water”
Reponsive News – a blog by the team making the BBC News website responsive
Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA. The rights to other codecs are often less clear, as has been described in the press. Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty.
There is no truth in alleged “leaked emails” that our business plan reads 1) Publish photos of loads of multi-ethnic hipsters in glossy report 2) alias -webkit- prefixes 3) profit!
There are a couple of key nuggets in there (although the full report is worth a read). First, let’s remind ourselves that the internet contributed £121 billion (not million) to the UK last year, which is more that £2000 per person, making it 8.3% of the economy. Let’s also agree that mobile is an important and rapidly-growing part of that.
A bad experience on a mobile website leaves mobile web users much less likely to return to, or recommend, a particular website. Nearly half of mobile web users are unlikely to return to a website that they had trouble accessing from their phone and 57% are unlikely to recommend the site.
It’s pretty likely that visitors are coming to your website from non-webkit browsers: Opera is huge. It’s becoming more likely as Internet Explorer on Windows Phone 7 hits the market and when Firefox Fennec is released.
If you don’t make sure that your website works in those browsers (this means testing), 50% of those customers won’t come back. And, unless you are selling something completely unique, they’re quite likely to buy from your competitors instead:
Mobile users do not have much patience for retrying a website or application that is not functioning initially — a third will go to a competitor’s site instead.
Another interesting finding is likely to annoy some developers. When asked “What is the most common problem you’ve encountered accessing websites or applications on your mobile phone?”, respondants answered “Slow to load” (38%), “Crashed/froze received an error” (18%), “Formatting made it difficult to read and use” (15%).
This tells us that speed is more important than aesthetics. So perhaps some of the time and effort put into media queries, viewports, avoiding scrolling, line length would actually be better employed reducing HTTP requests and optimising so that websites are perceived to render faster.
Certainly, if you’re using gigantic libraries and frameworks to speed up your development, you might pause to wonder whether trading off faster development for slower loading is a trade-off you want to make, given that most users find speed to be the main problem – and problems drive consumers away and potentially into the arms of competitors.
It seems to me that old-fashioned, oh-so-dull techniques might not be ready for retirement yet. You know: well-crafted HTML, keeping JavaScript for progressive enhancement rather than a pre-requisite for the page even displaying, and testing across browsers.
They might not be cool. But it’s what users want. And if your business doesn’t provide it, your competitors will.
Added 17 April: in a survey conducted in Brazil, 62% agreed that speed was the most important feature for them while browsing the mobile web.
Just three links for this reading list, because they show a profound schism in the way people are thinking about building applications that have previously been desktop only and take them to mobile.
The schism is the same as we’ve long had on desktop. It’s simply: do you make your target audience as wide as possible, or do you only design for people who use the same technology as you do?
The nations’s favourite social-media based conference organiser thingy, Lanyrd, launched its mobile version two days ago. I don’t own an iThing, but I assume it’s great there, and it looks and works excellently on Opera Mini and Opera Mobile on Android.
“Although we’re employing some ‘new and shiny’ browser features, we’ve taken the righteous path of progressive enhancement and been liberal with our testing and support. While most mobile offerings are targeted at particular devices or WebKit, our support includes quirky devices like the old Blackberry 9000 (yes, it still haunts people’s pockets), the Kindle, and even basic feature-phones if they can run Opera Mini. The site works as expected without JavaScript.
It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.
What is this fabulous remedy that 37signals have found? Simply, ignoring users of browsers that you don’t want to support. “Supporting your browser is hard – let’s go shopping”, as Barbie says, or Regressive Ken-hancement in strict Computer Science terminology.
It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) – from targeting users, to focusing on devices and modern browsers.
We write about new techniques without considering fall back mechanisms, we use ARIA “hacks” that look like anti-patterns and we use frameworks that have chosen to ignore oldIE.
If you read no other high-level articles this month, read that one.
The first reading list of 2012 is themed, rather than the usual miscellany. It’s about the Open Web and the dangers it faces.
I’ve nailed my colours to the mast – most lately in The Pastry Box:
The Web is about communication. It connects many people who previously were isolated such as those with disabilities or those in oppressive regimes. It’s a World-Wide Web, not a Wealthy Western Web. If your super-clever site only works with a mouse and monitor, on the latest $2000 super-spec laptop, with a fat broadband connection, you’re missing the point.
The principles of universality of access irrespective of hardware or software platform, network infrastructure, language, culture, geographical location, or physical or mental impairment are core values in Web design.
One of the most worrying trends we see at the moment is the erosion of this idea. In a survey, Peter-Paul Koch asked "Do you hope that WebKit will become the only rendering engine, and that the others will gradually disappear?". Shockingly, 32% have replied “yes” (at time of writing). You read that correctly! 32% actively wish for a monoculture. Because, y’know, cross-browser development is hard – so let’s go shopping! Who cares about the users? Who cares about the future? We’ve been here before with IE6- the darling of developers at the time – and look how well that went.
It’s pretty obvious that this is a case of a group of developers that believes that everyone should be just like them and should use the same devices and browsers. After all, despite all their genuflecting to Safari on their iPhones, it appears from December’s mobile statisitics (as written up by PPK) that
Opera once more overtakes Safari. It’s clear now that Android’s untrammeled growth has ended, and that the race for first position will continue to be between Opera and Safari.
(If you’d like to start testing your sites in the number one mobile browser, there are plenty of Opera testing tools available. Note: Opera is my employer, but this is my personal opinion.)
we have to start building sites using solid, future friendly principles such as progressive enhancement…not just when it’s handy or simple, but all the time.
and goes on to show a Barack Obama re-election site in which it was impossible to navigate in many devices, even some new high-spec devices. In a news report about this, the journalist quotes my three incredibly ground-breaking, never-before-heard rules:
Code to standards, not to browsers
use progressive enhancement
remember that you are not your user.
Yes, I know! Utterly new concepts.
However, we’re approaching a monoculture on mobile. This is not the work of an evil organisation, but it’s developer-constructed. Few people are stupid enough to use Olde-Skool browser sniffing and blocking, but we’re seeing lots of people breaking cross-browser compatibility by neglect rather than design.
One way this happens is developers using only one vendor’s CSS vendor prefix even when other vendors support the same properties. Of course, for experimental things only implemented by one rendering engine, that’s fine. That’s what vendor prefixes are for.
The trouble comes about when people do something like -webkit-transition for widely-supported properties, without the corresponding -o- for Opera, -ms- for Microsoft and -moz- for Mozilla.
People never aim to create content that’s cross-browser compatible per se, with a tiny minority of exceptions. People aim to create content that reaches users. What that means is that right now people are busy authoring webkit-only websites on the open web because they think that webkit is the only UA that will ever matter on mobile. And if you point out this assumption to these people, they will tell you right to your face that it’s a perfectly justified assumption. The problem is bad enough that both Trident and Gecko have seriously considered implementing support for some subset of -webkit CSS properties.[my emphasis]
Since then, we’ve had many more debates about the merits of vendor prefixes (see previous reading list), and even the co-chair of the CSS Working Group, Daniel Glazman, wrote
The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web.
I believe vendor prefixes were a good idea, and remain so if used in a cross-browser, future-proof way. But because so many people only use the -webkit- one, I’m starting to wonder too if vendor prefixes should be considered harmful…
Adding Islamic calendar support in HTML5 – a request from IBM to add new types of HTML <input> to cater for the three Islamic calendars. I agree with Lars and Lachlans’ comments that this is a browser enhancement and not an addition to the language.
EcmaScript 6 versioning. Dutch Specmeister Anne van Kesteren writes “this still strikes me as a slippery slope towards the mess Internet Explorer is dealing with (and Word has in the past). Not very webby, ECMAScript”
Backbone.js mini-book by Addy Osmani, who says "any contributions welcome. Plan to keep adding more everyday".
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:
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">
</picture>
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.
PrefixFree: Break free from CSS prefix hell – Lea’s script parses CSS on the client and adds only the vendor prefixes that the browser requires. A sort of Modernizr for CSS, but note it adds a dependency on 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.
For three years Jared Smith and his lovable chums at WebAIM have conducted a survey of screenreader users, analysed the result and posted them. This year’s results are out. Let’s take a moment to give them a round of applause.
There is much to digest, but one figure really caught my attention: only 1.6% of respondents had JavaScript disabled. Turning that round, 98.4% of screenreader users had JavaScript enabled.
Hopefully this will finally bury the WCAG1-era myth that JavaScript is automatically bad for accessibility or that pages that depend on scripting are inaccessible to assistive technologies.
This myth came about from the early days of screenreaders, which took a snapshot of the rendered page into a buffer and, when a user was navigating a page, he was really navigating that snapshot. If a page was changed with script the user wouldn’t know because another snapshot wasn’t triggered. (Even in this model, some JavaScript was fine. If, for example, your page contained lots of document.writes that executed immediately, and wrote HTML to the page, that would be available.)
As the Web made more use of “Ajax”, screenreaders became more sophisticated and now can handle most scripted interactions. This doesn’t mean that JavaScript is always fine to use; just as you can write inaccessible HTML and CSS, it’s possible to script away accessibility. An understanding of WAI ARIA is vital to professional JavaScripters.
(It’s also important to understand that not all accessibility needs are assistive technology needs. Christian Heilmann and Antonia Hyde showed that some scripting can be empowering for people with cognitive problems with their Easy YouTube and Easy Flickr.)
So we know that script doesn’t scare off assistive technologies, and we know from Yahoo! developer Nicholas C. Zakas’ report How many users have JavaScript disabled? that only 1% of visitors to Yahoo! have turned off JavaScript. Does this mean that we can safely forget about those who can’t use JavaScript.
Well, no. But JavaScript-required is not an accessibility problem, it’s a usability problem. As Zakas says
While the percentage of visitors with JavaScript disabled seems like a low number, keep in mind that small percentages of big numbers are also big numbers.
We spend a lot of time making our sites work with old browsers, using JavaScript shivs and polyfills but we don’t talk much about users without JavaScript. The Opera mini browser, for example, is the most-widespread mobile browser out there but, because it renders on a server, interactivity is limited (See Opera Mini: web content authoring guidelines for more information.)
How far can an application that requires Web Sockets, local storage, cross-domain messaging, canvas be expected to degrade gracefully?
I’ve written an article on making sure your websites have a fighting chance of working across devices (mobiles, consoles etc).
It’s for web designers used to making desktop sites, rather than for people designing iThing apps.
The article was originally called “The ultimate guide to mobile optimisation” but the boss rightly said no (you could write a book about the subject, but all the main points are introduced in the article).