It was with a wry smile and a glass of snarkasm that I relayed the amazing news that airbnb had discovered the “Holy Grail” of app development:
serving up real HTML on first pageload, but then kicking off a client-side JavaScript app. In other words, the Holy Grail.
For a few years, JS developers have been extolling the virtues of the empty <body> element in pages and injecting markup with JavaScript to construct the DOM. This obviously fails for clients that don’t have JavaScript, but also increases rendering time because JavaScript must be downloaded and executed before anything is rendered – particularly laggy on slow mobile connections (and presumably more draining on the battery). Airbnb’s Holy Grail app
looks exactly the same as the app it replaced, however initial pageload feels drastically quicker because we serve up real HTML instead of waiting for the client to download JavaScript before rendering. Plus, it is fully crawlable by search engines.
The performance gains are an awesome side effect of this design. In testing, we’re using a metric we call “time to content”…
Over a mobile connection, it may take 2 seconds to download the initial page of HTML, but it can be immediately rendered. Even as the rest of the JavaScript application is being downloaded, the user can interact with the page. It feels 5x faster.
All hail the Holy Grail method. Or, as some fuddy-duddies have called it, “Progressive Enhancement“.
(This is a personal blogpost; it doesn’t represent the opinion of my employer, my wife or my hamster.)
Until now, I hadn’t paid much attention to the details of the DRM extension to HTML (which is actually called “Encrypted Media Extensions” in the same way as some people call a “fart” a “trouser cough”).
This is due to a resigned feeling that, like death and taxes, DRM is inevitable because too many vested interests require it and until it does get specified and implemented, those powerful corporations won’t invest in the not-as-open-as-before Web.
Therefore, I wrote last year “Like an unpleasant medical procedure such as having a catheter inserted, if it must happen it might as well come sooner rather than later.”
I also thought that at least specifying it in the language means that some users won’t be completely locked out (as, for example, Linux users are by Silverlight DRM.)
The EME specification does not specify a DRM scheme in the specification, rather it explains the architecture for a DRM plug-in mechanism. This will lead to plug-in proliferation on the Web. Plugins are something that are detrimental to inter-operability because it is inevitable that the DRM plugin vendors will not be able to support all platforms at all times. So, some people will be able to view content, others will not.
I don’t have a moral problem with DRM. I just don’t believe it works, so it’s a waste of time. But encouraging plugins that will leave some law-abiding customers who want to pay for content unable to do so is the worst of all worlds.
Note to DRM people: I’m patenting the idea of <article drm=”drm”> which will disable copy and paste in the browser and pop up an alert warning people not to copy it. Implement it and feel my mighty lawsuit.
Carousels – are content strategy compromise, usability and accessibility nastiness, and design twattery
Accessibility Priority Tool – a “mechanism for helping web content developers and organisations identify and correct issues that could reduce the ability of some people to access web content” by the Russell Crowe of accessibility, Roger Hudson
Design process is a myth – “Bad product design is fixed by hiring good designers not by adopting a better design process.”
Apple Forced Google’s Hand On Android – “By seeking to holistically control the customer experience, Apple has simply ensured that the majority of the market will, in fact, get that experience … from Google.”
Actual Facebook Graph Searches New FB search makes it easy to find “Islamic men interested in men who live in Tehran, Iran”
Social media is a giant scam – “You are an arrogant, entitled scumbag. Stop claiming you’re a voice for the downtrodden, fighting in the name of fairness. You’re an asshole, plain and simple. And people like you have turned the entire world of social media into a giant scam.”
The South By South West conference has published its First Timer’s Guide with such nuggets as advising readers to drink water and “Be sure you know the name of your hotel”. In my customary mode of unceasing public service, I offer some more tips:
Wipe your bottom after every poo. Wipe from front to back.
Do not put a sharpened pencil into your ear, then smack the side of your head against a wall. This may drive the pencil through your Eustachian tube and into your brain.
If any panellist mentions Postel’s law, Fitt’s law or Moore’s law, loudly applaud their effortless erudition. However, if a food retail operative mentions “Cole’s Law”, they are referring to salad consisting primarily of shredded raw cabbage.
If a tiger escapes from Austin Zoo and, maddened with fear and hunger, races into a conference session that you’re attending, don’t embarrass yourself by falling victim to the tiger-petting anti-pattern.
If a stranger asks you if (s)he can see your genitals, say “no” in a friendly but firm voice. (Video tutorial)
Even though this is your first time, tell everyone you meet that “it was much better back in ’07”. Everyone will love you.
Happy Southby!
(It was much better in ’02 when I was hanging with Cory Doctorwho and David Byrne at the Jackalope. Of course, nobody went to the Jackalope, then.)
The earliest incarnation of the specification that we now call “HTML5” was an extension of HTML forms, called Web Forms 2.0 (Working Draft 5 February 2004 – almost nine years ago!). It contained lots of cool stuff that’s in the spec today, like <input type=”date”>, <input type=”email”>, the required attribute, and cool stuff that never made it to the final spec like <input type=”location”> and repeating templates (the latter was implemented in Opera, and subsequently removed in 2010).
When I first started talking about HTML5, I’d show these new forms controls to developers, who were all initially very excited. After all, who wants to code JavaScript date-pickers, or email validation routines? But the excitement dissipated after the inevitable question about how you can style the forms and their error messages.
The answer is that unfortunately you can’t very well. You can apply some styling – for example, making invalid or out-of-range inputs have a different border colour with CSS pseudoclasses, as defined in the CSS Basic UI moduleinput:invalid {border:2px solid red;}, but this was badly thought out because, for example, fields with a required attribute are “invalid” at page load and therefore take the ugly styles before the user has even begun to interact with the form. Mozilla implemented their own -moz-ui-invalid mechanism that solves the problem:
If the element is required, the preceding rules apply only if the user has changed the value or attempted to submit the form.
It’s only implemented in Firefox, as it’s proprietary, but it’s a really good idea and informed a W3C proposed :user-error pseudoclass:
The :user-error pseudo-class represents an input element with incorrect input, but only after the user has significantly interacted with it.
This is good, but only deals with styling erroneous input fields. Error messages can be styled in WebKit using proprietary pseudoelements ::-webkit-validation-bubble, ::-webkit-validation-bubble-arrow-clipper, ::-webkit-validation-bubble-arrow, ::-webkit-validation-bubble-message. There’s no cross-browser proposal at W3C, but Peter Gasston has interesting ideas. The only reliable way at the moment to control the appearance of validation is turn it off with <form novalidate …> and script your own, which rather defeats the purpose.
There are no real ways of styling the controls themselves. The HTML5 spec is mostly silent on styling matters (and rightly so); the CSS Basic UI module would be a natural place for it, but that hasn’t been touched for a year, and before that update had languished for half a decade. Of course, this isn’t a trivial problem. <input type=”date”> might be rendered as a pop-up calendar widget on a desktop browser, and you may wish to “grey out” weekends – but are weekends Saturday and Sunday? or Friday and Saturday? How would you achieve that in CSS? input[type=date]::friday {color:gray;}? And the same browser’s mobile version might use the operating system’s native date picking UI, in which case it would probably be unstylable anyway.
And what of sliders? When you have a pointer/ grabber, its track and tickmarks, what would input[type=range] {color: red;} change? Bear in mind that most browsers don’t follow the one styling suggestion that the spec does offer, which is to render vertical sliders when the input’s CSS height exceeds the width.
One thing that working in the web for a decade has taught me is that where there’s a will, clever people will solve the most head-pulsing problems. But I’m beginning to wonder if there is a will. Phenomenally brainy Tab Atkins wrote
I think any arguments that sites will refuse to use the native controls because they don’t match the site’s theme are countered by the observation that most sites using JS-library equivalents today still don’t theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library.
This doesn’t meet my experience of developers telling me they’ll continue to use things like jQuery UI because of the themes it offers.
It means that developers continue to make forms out of non-semantic elements like <div> and pile on contenteditable attributes and (hopefully) ARIA attributes and tabindex to make them accessible, even though native form controls are accessible by default.
Write whatever the fuck you want with some WAI-ARIA sugar on top is in some scenarios the only thing what works right now. I do not believe that means we should just let it run its course. The real solution to making a button implemented using five div elements and some scripting accessible is not WAI-ARIA. It is to drastically improve the styling capabilities of <input type=”button”>.
Popular sites are applying a great deal of custom styling to form controls. One example page we love to use here is google.com. If you take a peek in, say, Safari or Firefox, you can see that Google has put a lot of custom styling on the text field and the two <input type=submit> buttons on their home page. This lets them have a custom look while still working in old or obscure browsers, or in browsers with script disabled, and to provide good accessibility while maintaining fairly compact markup. But by styling form controls at all, they are in a no-man’s land in terms of standards. We need to bring this technique into the real of interoperable-specified behavior.
…but to no avail. So what is to be done? The Shadow DOM may help. Shadow DOM gives you access to the internals of browser widgets; for example, the buttons in a <video> element that the browser provides when you specify the controls attribute. It’s a work in progress, part of the suite of specifications called Web Components. Spec editor Dimitri Glazkov writes
Shadow DOM specifies that all HTML elements must behave as if they already have an existing, UA-provided shadow tree, which in turn allows the author-created shadow trees to properly override and even include) those UA-provided shadow trees.
You should be able to do the same exact thing with every other element (though there’s a very tricky issue with IMG, VIDEO, OBJECT, et al. about the nature of “the insides” of the actual replaced content that will need to be first resolved by CSS WG).
So, again, back to the CSS Working Group. I’d like to ask them, when they’re specifying the insides of replaced content, that they do the same with form controls, and give us pseudoelements.
As Tab Atkins continued:
…us devs are mostly lazy, and love being able to write a simple element instead of piping in a library just to do a crappy calendar.
Tab’s absolutely right. And developers really start to use features when they’re specified in languages they already use. We’ve seen this with CSS transitions, animations and filters, all of which were possible for ages in SVG but that was something extra to learn.
The Shadow DOM is potentially a great advance in web development, but it’s a whole new set of technologies. Allowing form styling through CSS would make it simple and allow developers to satisfy the marketing department’s demand for sliders in corporate heliotrope and goldenrod, while using native, accessible controls rather than JavaScript libraries, ARIA bolt-ons and abusing semantics.
If you’re a developer, let me know if you use the native HTML5 form inputs, or – if you use some JS library – do you adjust them to suit your site?
Shadow DOM 101 – while it’s a bit early to call Web Components “a set of cutting edge standards” (it’s more accurately “something Google is adding into WebKit”), this is a useful introduction to concepts behind the Shadow DOM and HTML Templates.
Emmet the essential toolkit for web-developers: type CSS-like expressions that can be dynamically parsed, and produce output depending on what you type in the abbreviation. (previously known as Zen Coding)
I’ve long been a fan of responsive web design (here’s my July 2010 Mobile-friendly: The mobile web optimization guide) but recently I’ve been musing on whether mobile browsers should have a mechanism to turn it off – that is, pretend to have a really wide screen so width-based media queries don’t kick in, thereby allowing people to see the “desktop site”.
Chrome for Android has a feature called “Request desktop site” but this only changes the User Agent string (dropping “Android” and device name). Opera Mobile has the facility to change UA string from mobile to desktop (Settings, Advanced). These are useful for old-skool sites that do UA-sniffing and serve cut-down sites to mobile browsers. Neither of these “undo” Media Query-based layout changes (I tested them on the new A Book Apart site).
But why would anyone want to?
My reason for wondering this is watching my dad use his Xmas Android phone and seeing his puzzlement that some sites look completely different on that device. Non-RWD sites loaded the layout he was familiar with – the desktop layout – which meant he could verify he was on the right site, he knew where in the layout the content he wanted was, and then scroll and zoom to it. When a site looked radically different, he’d check the URL bar to ensure that he’d typed in the right address. In short, he found RWD to be confusing and it meant he didn’t trust the site – no way would he buy anything from these sites.
Not everyone thinks like this. In reponse to my musings on Twitter, Orde Saunders said “We saw 6% growth in mobile traffic over and above underlying mobile increase trend after RWD was rolled out.”
Aaron Mentele said “Three weeks without, three weeks with (typical responsive patterns) iPhone/iPod transactions: up 112.50%. Android transactions: up 333.33% (This is an ecommerce store.)” and promised to blog some real numbers soon.
There’s also the philosophical niggle that we force RWD onto users. Some may wish to scroll and zoom around a facsimile of the site they’re used to on desktop, but we decide they shouldn’t be able to.
If people really want to do this, should developers deal with it or should it be a browser setting? Perhaps it’s simply too niche; Roger Johansson said “I’ve implemented a switch on some sites (sets a cookie, removes meta viewport and mq.css) … The stats I’ve seen show that very, very few use the switch.”
Anorak’s corner: First suggestion of CSS Media Queries: "DISPLAY_HEIGHT > 30cm ? stylesheet : alternative stylesheet by Opera CTO Håkon W Lie, 10 Oct 1994
Conferences aren’t the problem – Frances Berriman on the fact that lack of diversity of conference speakers reflects that in our industry. She’s right, of course; if our industry were really diverse, our sites would be accessible. Link includes bonus comment from holocaust-denier who dislikes diversity.
Jay Fanelli on online etiquette – “You may think you’re standing outside the building, harmlessly yelling at the front door, but you’re really standing next to someone’s desk embarrassing them in front of their colleagues.”
It’s been an interesting year. I had my mother-in-law stay with us for six months. I can heartily recommend everyone do this. My cousin Mark got married; my uncle Colin died; my aunt Sue died of Multiple Sclerosis.
My son started high school and somehow became taller than my wife and turned from good humoured child into occasionally ill-tempered adolescent who’s the finest gamer in his gang. My daughter turned into a beautiful and strong teenage woman; her strength of character is an immense source of pride. For example, for months she and some colleagues had been bothered by an adult male taking upskirt photos of them with a mobile phone on the bus to school. No-one said anything until my daughter bravely called him out on the bus (getting an obscene tirade in response) and reported him to the police who deported him.
Countries
I visited Amsterdam in The Netherlands (twice); Oslo, Norway numerous times (where I bought the most expensive beer I’ve ever bought: £12.50!); Sofia, Bulgaria; Toulouse, France; Dusseldorf, Germany; Krakow, Poland; Moscow, Russia; Prague, Czech republic and Cape Town, South Africa. Cape Town was particularly surprising; I didn’t expect to like it much and came away believing it to be one of the few places in the world outside the UK where I could actually imagine myself living.
I didn’t visit the USA in 2012 (but already have plans to go to Future Insights, Vegas) and had to turn down trips to Istanbul in Turkey, Lisbon in Portugal and Venice in Italy because of scheduling conflicts. Thanks to all the conference organisers, fellow speakers and attendees who allow me to travel to beautiful, interesting places and drink beer with and learn from some of the finest minds in the industry.
For pleasure, I visited Thailand and Cambodia with my mum, uncle and cousin and also my grandmother in powdered form, scattering her ashes in Angkor Wat. I did some Asian posing and got papped by a monk.
Having survived Cambodia and Thailand unscathed, I got a horrible bite in the UK which had me in A&E for the second time in two years. (The first time was after I was onstage barefooted in Sweden and stood on a rusty nail.)
After finishing the second edition of Introducing HTML5, I needed to do something unrelated to web in my free time and was commissioned to develop and write a weekend course to train teachers how to teach English to very young children (which is what I did in Thailand before the millennium and getting into the web business).
Talking of web, my personal website saw a few bemused visitors in 2012. The top search phrases were
bruce lawson (2.6%)
personal website (1.5%)
personal site (1.2%)
jacobean plays (1%)
friday jokes (0.7%)
pui fan lee (0.6%)
pui fan lee husband (0.6%)
cartoon newt (0.6%)
pui fan lee married (0.5%)
html5 form (0.5 %)
It’s good to see that I’m not just a one-trick pony (although “html5” was the top single term). In the full list, I was pleased to see “naked men showering”, “spiffing” (an adjective, not a verb), “the pencil test”, “lovely bums”, “kerala beautiful ladies” and – by way of geographic balance, “uk anal sluts”.