A subtree of a Document can be marked as inert. When a node or one of its ancestors is inert, then the user agent must act as if the element was absent for the purposes of targetting user interaction events … Note: When a node or one of its ancestors is inert, it also can’t be focused.
An entire Document can be marked as blocked by a modal dialog dialog. While a Document is so marked, every node that is in the Document, with the exception of the dialog element, its ancestors, and its descendants, must be marked inert.
The great thing about a built-in <dialog> element, even with its egregious mis-spelling, is that it will make a lot of websites more accessible. For example, many sites use pseudo-dialogs that they either write themselves or get from JavaScript libraries. Many of these don’t allow modal dialogs and lightboxes to be closed using just the keyboard, for example (see Lightboxes and keyboard accessibility for more). Building accessible dialogs into the language is far better than expecting every developer to bolt it on.
HTML5 Accessibility Chops: ‘real world’ ARIA landmark use – “From an initial analysis the correct use of ARIA landmark roles is surprisingly high. Developers are generally using ARIA landmark roles as intended. Although use is low, there is an major upward trend in use as sites switch to HTML5.”
Why We Shouldn’t Make Separate Mobile Websites – me in Smashing Magazine on why Jakob Nielsen is wrong about mobile usability. (The title isn’t mine. It’s really about why you shouldn’t always assume it’s best to make a separate site.
Mood Changes in UK Twitter Content 2009-2012 – “we analyse a collection of 484 million tweets generated by more than 9.8 million users from the United Kingdom over the past 31 months, a period marked by economic downturn and some social tensions.” With handy animation!
Safety Tat – stick-on QR codes for children in case they get lost.
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.
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".
Here are some links I’ve tweeted recently, for those without time, inclination or access to read them on Twitter. And why would you, when I’ve categorised them here for you?
a simple graphics API that will allow either 2D Canvas (immediate-mode) or SVG (retained-mode) images with the same set of methods and parameters, with the only difference being which “mode” the author selects to have as the instantiated form. If the author draws a circle to the canvas context, it would simply be drawn to the screen with no structure; if the author draws that same circle to the SVG context, it creates a element with the appropriate attribute values and style and inserts it into the DOM
This would allow authors to learn only one API for 2D graphics for the Open Web Platform. With this ease of learning and use, the author could decide on a case-by-case basis, even within the same application, which mode works best.
WebRTC is real-time communication in the browser (think: video-conferencing). Google open-sourced their code. “we expect to see WebRTC support in Firefox, Opera, and Chrome soon!”
Trygve Lie has some cool Orientation API demos: Using a mobile phone as a remte conrtrol for a video on a desktop, and a remote / receiver demo that captures the orientation events from a device and transfers these over a WebSocket to the receiver to create a rotating image in the receiver. The image in the receiver will rotate depending upon how the remote is rotated.
What’s the opposite of “to develop”? That’s right – “to inhibit” or “to retard”. So after the “Web Development” section, stuff that inhibits the Open Web:
One (of many) super outcomes of the HTML5 evolution is that browser vendors are striving towards interoperability – even Microsoft is talking of “same markup”.
However, the dedication to interoperability hasn’t spilled over into the world of installable browser applications. Installable apps (in W3C parlance, Widgets – which is a terrible name) allow authors to write apps using HTML(5), CSS, JavaScript, SVG etc, and package them up into a glorified Zip file with some configuration details which can then be installed on a computer. They then use the browser’s rendering engine, but don’t show browser chrome. To all intents and purposes, they’re indistinguishable from native apps.
The W3C defines them as
full-fledged client-side applications that are authored using technologies such as HTML and then packaged for distribution. Examples range from simple clocks, stock tickers, news casters, games and weather forecasters, to complex applications that pull data from multiple sources to be “mashed-up” and presented to a user in some interesting and useful way.
Opera (disclosure: my employer) uses the W3C standard for its packaging format – so the assets are bagged up in a zip file, which is renamed .wgt The configuration information is an XML file that specifies things like required features (eg, camera access), default size of the Widget (full-screen, minimised etc) and its network access permissions. (Learn more or download some widgets and have a play).
I was intrigued to find out what sort of formats the Chrome Web Store was using for its “installed web applications”, and discovered somewhat to my surprise it uses yet another packaging and manifest format! This is in addition to the two manifest formats Google already uses (for Gadgets/OpenSocial/Wave and Google App Market).
The format uses the file extension “.crx” and consists of a 7-Zip archive and a manifest file in JSON. The actual contents however are almost identical to W3C Widgets, and so I created a proof-of-concept set of conversion code.
My question to chums in Chrome and Mozilla (which has its own Mozilla Install Manifest format): what’s missing from the standard W3C Widgets specification that you need? Wouldn’t it be better for us all to collaborate on one interoperable specification, as we’re doing so successfully with HTML5?
My chum Marcos Caceres is the editor of the Widgets spec and would doubtless leuurve your feedback.
Update 24 July 2012. I never got an answer from Chrome, but they have announced their own non-standards-based proprietary Packaged Apps format. Hurray for interoperability.
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.
When it was released 10 years ago, IE6 was the most sophisticated browser on the market. Now it lingers like a nasty fart in a crowded lift, embarrassing its producer Microsoft so much that it sent flowers to a mock-funeral for IE6 and now has released IE6countdown.com, asking developers to market IE9 by adding a browser upgrade link on their sites.
Two years ago, I wrote about IE8 in a ZDNet article:
If Microsoft is serious about wishing to persuade users and corporates to upgrade, it should address the reasons why people have not yet upgraded.
It could, for example, encourage systems administrators to upgrade corporate networks by officially announcing that IE6 has reached the end of its life and stop supporting it, and back-port IE8 to run on Windows 2000 so users of that operating system have an upgrade path.
But IE9 is only available for Windows 7 and Windows Vista users—so users of Windows XP, the most-used operating system in the world, cannot leave IE6 for IE9.
If Opera can make Opera 11, with its superb support for modern standards, work on Windows 2000 and above, why can’t Microsoft make Microsoft Internet Explorer 9 work on Microsoft Windows XP and Microsoft Windows 2000?
That would significantly help them towards their goal of watching “Internet Explorer 6 usage drop to less than 1% worldwide”.
I really can’t think of a reason why they don’t backport it – can you?
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?
