M dot or RWD. Which is faster? – initial research on the top 1,000 mobile websites concludes that “m dot” sites are 50% slower for time to first byte, and “RWD sites are VERY competitive on Visually Complete and SpeedIndex scores. The median values are within 5% for both metrics. Even though it appears that RWD is faster, there is enough fluctuation in the data that we should probably call it a dead heat.”
Iterators gonna iterate – Iterators. They’re like ES6 velociraptors. And they’re in Opera, Chrome and Firefox. Jank Architect has the low-down.
The following content is not acceptable from the 1st December 2014 – “Pornography is the canary in the coalmine of free speech: it is the first freedom to die. If this assault on liberty is allowed to go unchallenged, other freedoms will fall as a consequence” – a lawyer on the ridiculous new UK censorship laws. Gotta love government small enough to fit in your bedroom.
I enjoyed watching Dimitri Glazkov’s introduction to Web Components Easy composition and reuse with Web Components, given at the Chrome Developer Summit. It’s an excellently-constructed talk that builds on the use-cases that web components address to make a compelling argument for the technology.
Custom elements is really neat. It basically says, “HTML it’s been a pleasure”.
There we are. Bye-bye HTML; you weren’t useful enough. Hello, brave new world of custom elements. Of course, this isn’t the full messaging; a 20 minute video can’t go into the nuances. But it’s what a lot of people are hearing.
Let’s straighten that out.
One of the advantages of oh-so-boring HTML was that certain elements carried default behaviours in browsers and assistive technology. Like, when you use this mark-up
<label for="form-name">What's yer name?<label>
Custom Elements present a fantastic opportunity for us to improve accessibility on the web.
Yes. Yes. Yes. (Thanks Addy and Alice!) It’s perfectly possible to make web components and custom elements accessible. Alice has an example which I’ve screenshotted in Opera (top) and Safari (bottom).
Note that the first column does render in Safari, but it’s just normal checkboxes; they aren’t sexy web component-ised as they are in Opera. But – crucially – you can still interact with them, as they’re web components progressively enhancing silly old “useless” HTML. It works like this:
<input type="checkbox" is="io-checkbox">
Simple, huh? You have a silly old useless HTML element, and a new attribute that says “this is extended via web components into a special element I’m calling ‘io-checkbox'”. The web component inherits all the silly old useless behaviour like associating labels with form fields, activation with keyboard for free.
Compare with the sexy but not progressively-enhanced way that doesn’t work in older browsers (the second column):
There’s a super-whizzo-fabbo-megalicious UltraShiny custom element there, which has no graceful degradation. It needs a tabindex and a role there because who wants that silly old useless HTML behaviour? Not us! We’re post-HTML. Yay!
Snarking aside, why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements? I don’t know.
Of course, not every new element you’ll want to make can extend an existing HTML element. In this case, you can still make your custom element accessible. Just because you’re in the super-whizzo-fabbo-megalicious UltraShiny world of web components, you can – and should – still add ARIA information to make your code accessible. Just because you’re hiding nasty code behind the Shadow DOM, it doesn’t mean that you can brush proper coding under the web components carpet.
You’d hope that those who are assiduously pushing components into the platform would ensure that their demos did this – after all, those demos are meant to be studied, copied and adapted by developers, right?
Google has expertise in-house to create functional, beautiful, web-component stuff that is also accessible. It would be great if high-profile demos like these would actually take advantage of those resources to create things that work not just for sighted mouse/touchscreen users…
To which he received the reply
There’s plenty that can be done in the convenience of unlimited time and resources. If you’d like to help, please submit a PR.
A big demo of a Google cutting-edge technology, made by Google, and there’s no resources simply to make it accessible.
At Paris Web, Karl Groves and I talked about Web Components – the right way, we talked of extending existing elements, adding ARIA and suggested that web accessibility advocates actively fix issues on Open-Source projects. But I meant fixing small projects that you’re using in your own sites – like the WordPress Live Comment Preview plugin, which I tweaked, thereby making 44,837 sites accessible.
I wasn’t talking about fixing demos by a company with a $362.48 Billion market capitalisation. As Patrick Lauke so eloquently puts it:
My resources are currently a bit more stretched than Google’s…but I’ll put it on my to-do list
I’m a fan of web components. But I’m increasingly worried about the messaging surrounding them.
This week’s reading list is devoted to Device Detection vs Responsive Web Design.
With all the cool kids getting into RWD these days, it’s time to have a look at the Device Detection companies again. Device Detection is the practice of matching a device’s UA string against a table of such strings and looking up certain characteristics of that device and then serving different websites accordingly.
Those who oppose Device Detection do so for philosophical reasons – it’s one web and we shouldn’t serve different content to different devices or browsers, or they are certain browser vendors: Internet Explorer, Firefox OS and Opera all have reasons to dislike browser sniffing or device detection (“this website is only available to iPad users”). Google uses device detection all the time on its properties, as do many other large companies.
The device detection companies have begun to issue reports comparing their products with responsive, client-side techniques. Here are three that I’ve seen this week:
RWD sites were the slowest, on average, to load on mobile – 8.4 seconds – while dedicated mobile sites loaded fastest – in 2.9 seconds. Non-responsive desktop sites took 6.57 seconds to load.
I’d like to see proper A/B testing: a well-made responsive version of a site versus its “m-dot” equivalent, redirected from its canonical URL and assembled after a device look-up, across a variety of devices and network conditions. If we’re going to argue, it might as well be about data.
Update 1 Dec 2014: Here’s some initial research on the top 1,000 mobile websites: M dot or RWD. Which is faster? that concludes that “m dot” sites are 50% slower for time to first byte, and
RWD sites are VERY competitive on Visually Complete and SpeedIndex scores. The median values are within 5% for both metrics. Even though it appears that RWD is faster, there is enough fluctuation in the data that we should probably call it a dead heat.
Web Sensor API: Raw and Uncut – Boris Smus writes “Sensors found in smartphones define the mobile experience … I’ve had to step away from the web as a development platform, in part because of the poor state of sensor APIs. In this post, I will describe some of the problems, take a look at sensor APIs on iOS and Android, and suggest a solution in the spirit of the extensible web manifesto.”
Google makes image recognition advance – “Scientists at Google have created artificial intelligence software that can describe the contents of photographs far more accurately than ever before.” Doesn’t mean you can get out of writing alt text, though!
Internet Architecture Board Statement on Internet Confidentiality – “The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it isnot yet deployed, and we urge firewall policy administrators to permit encrypted traffic.”
Web standards for the future cute non-techy 2 minute video from W3C about why standards are important. I like it to show my kids and NGMs what I do, which is basically helping to build Skynet through the medium of mailing lists.
HTML5 Accessibility – “information about which new HTML5 user interface features are accessibility supported in browsers”. TL;DR: “Firefox and Chrome are beating the pants off IE!”
Tenon “is a one of a kind accessibility testing tool… which can be seamlessly integrated into your existing toolset…This ability to test early and often allows you to catch and fix accessibility issues before they happen, not after, and allows you to release accessible code from the beginning.” < in free public beta. Disclosure: made by Karl Groves, a friend of mine
Confused corner:Why you should worry about HTML5 mobile apps – “New research demonstrates that, unlike native apps, those written in HTML5 are susceptible to code injection attacks” because of “middleware” like WebView or PhoneGap “that is susceptible to malicious code injection”. Unlike those totally secure native apps.
Internet Xmas Party by Luke and Charlotte – for London-based freelancers, homeworkers & other just-pants-all-day folk
A while ago, there was discussion in CSS Working Group about an alt property to be added to CSS. Its purpose is to let assistive technology know the meaning of unicode characters inserted into a visual rendering of a document with CSS generated content. The problem is described by James Craig, Apple’s nice accessibility chappie.
It’s been shipping as -webkit-alt for a year now, and has just been added to the draft CSS Pseudo-Elements Module Level 4 spec. Let’s say you’re using a star glyph to show something is “new”, by generating CSS content using a class of .new as your selector:
The alt gives information to assistive technology.
The alt string can be blank. Assume you’re generating “►” to show that a widget is expandable. Because you’re a lovely human being and a responsible developer, you’re using aria-expanded="false" in the HTML. Therefore, you’d use empty alt in the CSS that generates the glyph to prevent assistive technology “helpfully” reading out “Black right-pointing pointer” after the AT has relayed the ARIA information to the user:
content: "\25BA"; /* a.k.a. ► */
/* aria-expanded="false" already in DOM,
so this pseudo-element is decorative */
Update 17:05 GMT fantasai of the CSS WG has mailed the CSS Working Group protesting against the syntax above. I don’t have any horse in the syntax race; my aim with this post is to show that we need some mechanism to give alternate content to assistive technology given that we allow non-textual content to be generated via CSS.
When I tweeted about this earlier, a few people objected to the concept because it adds content to CSS. But that ship has long sailed, with the content property that people have been using for ages. If you say “adding non-decorative content to a page is a misuse of CSS that merits the author 100,000 years in purgatory with Tim Berners-Mephistopholee pouring hot Ovaltine over their dingle-dangles whenever they try to sleep”, I will vehemently nod my agreement.
But sometimes, for organisational reasons, or because you inherited code, or you’re refactoring code from before you saw the light, you’re working with CSS that generates icons. This new property at least allows an author to make that content more accessible.
Years ago, I joined a web team a week after their brand new website had been delivered, months late and squillions over budget, by Big London Agency PLC. The site was a vile splodge of nested layout table cells and spacer GIFs with “click here” links pointing to PDFs. Of course, I could have instantly resigned my job and let the bank repossess my house.
Instead, I gently pointed out to any who would listen the inadequacies of the site and made plans about how it could be refactored. But while biding my time, I was also making small tweaks here and there to make it better and incrementally more accessible; removing duplicate link text from title attributes, changing “click here”s, putting blank alt text on spacer GIFs in the small parts of the template I controlled.
This was before the days of ARIA but I would have jumped at the chance of adding role="button" to the horrible mess of nested <div>s that the CMS spat out. Yes, it’s much better to spend a fortune getting the external CMS provider in to change the templates, the retest every single form on every single browser – but that simply wasn’t possible.
Two years later, when the senior manager who commissioned the terrible site left and we could jettison it, we did. And then we did it right. But for those who needed the content and were unable to wait nearly three years (that is, everyone), I’m glad I applied sticking plasters and polished turds.
It’s often said that if a job’s worth doing, it’s worth doing well. But it’s also wise to remember: sometimes, if a job’s worth doing, it’s worth doing badly than not at all. If you must have meaningful content generated by CSS, at least now you can make it accessible.
As a quick tip, I find a helpful way of coming to grips with it is by likening Flexbox to String Theory. Thus, flex-basis is analogous to a Calabi–Yau manifold or similar higher-dimensional analogues of K3 surfaces, and think of flex-shrink as behaving like the 7 compactified dimensions propagating from one point to another by summing probability amplitudes.
W3C: Making Payments Easy on the Web – “the payment landscape is quickly changing, and new challenges are appearing. For instance, the average shopping cart abandonment rate is 72% across all devices, and 97% on mobile.”
As I’m occasionally asked questions about how I see the two different organisations working together (or not), here are the full questions that Steve asked me, and my responses (as approved unchanged by my bosses at Opera). I’m grateful to Steve for giving me his permission to reproduce them.
SS: How big a problem is it that WHATWG and W3C both are sorta kinda in charge?
BL: It’s not an especially big problem for the vast majority of developers who aren’t developing sites using still-fluid features that are only available in the latest nightlies. Where they differ, the W3C spec is a better guide to the stable features as implemented already in browsers – for example, it has dropped the <hgroup> element, warns about the lack of implementations of the outlining algorithm and has much better advice on using the <main> element today to make websites more accessible to people with disabilities.
SS: Which do you think has more power in charting the future of the standard?
BL: Neither. The power is with browser makers. As Ian Hickson of WHATWG said, it doesn’t matter what the specs say if browsers don’t implement them.
SS: It seems kind of like we have two horses pulling the same cart, with no coordination between the horses. Is this a bad use of resources? Or is that a bad metaphor?
BL: The web is the biggest platform we’ve ever had. Therefore, it has more constituencies and competing interests than we’ve ever seen. It’s absolutely right that those different interest groups slug it out. At least it’s (mostly) done openly, unlike the decisions made behind closed doors by proprietary organisations answerable to no-one.
SS: We can’t rewrite history to excise XHTML 2.0, but should the two communities work to converge into one somehow? Is that even possible?
BL: I’d like to see one community , but suspect the cultural clashes are too large. So we have to get along, working together mostly and fighting occasionally, just like a family – albeit sometimes most like the Addams Family.
SS: How much actual real-world confusion is there among developers? Where should they go to see what the “true” spec says?
BL: If you want to see what’s already implemented in browsers now, look at W3C spec. If you want to see what might be coming (or how things may change) look at WHATWG spec.
Opera implements following the WHATWG spec, because that’s where nitty-gritty of the leading-edge stuff is discussed. But we also actively support and participate in the W3C as we see the value in having stable snapshots that developers can refer to, and it’s also the forum for many other vital spec discussions about Web Manifest, Device APIs etc. It’s possible to love both and, as we’re Norwegian, our hearts are full of love for all.