Archive for the 'mobile' Category

The amazing all-new performant Holy Grail app development method

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“.

On the styling of forms

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 module input: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.

Anne van Kesteren discusssed this in his clean markup plea:

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”>.

Quite.

Co-chair of the W3C HTML5 Working Group, Apple’s Maciej Stachowiak tried to get some traction for specifying form styling in 2010:

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?

Turning off responsive web design

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.

I’m not the first to wonder about this. A couple of years ago Adrian Roselli coded a “view desktop site” link that a client requested, and wrote about Letting Mobile Users See Desktop View of RWD Site. Chris Coyier wrote Opt-Out Responsive Design? last September.

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.”

Reading List

A bumper reading list for those long holidays (and because I’ve been away conferencing for a few weeks and need to spurt out my backlog).

HTML5, CSS and NEWT

Industry

Conference videos

Misc

  • Cry-Baby of the Year – a list of ten previous winners of Cry-Baby of the Week who have been shortlisted by me as nominees for Cry-Baby of the Year
  • Dalkey Archive Press seeks unpaid interns -” Any of the following will be grounds for immediate dismissal during the probationary period: coming in late or leaving early without prior permission; being unavailable at night or on the weekends; failing to meet any goals; giving unsolicited advice about how to run things; taking personal phone calls during work hours; gossiping; misusing company property, including surfing the internet while at work; submission of poorly written materials; creating an atmosphere of complaint or argument; failing to respond to emails in a timely way; not showing an interest in other aspects of publishing beyond editorial; making repeated mistakes; violating company policies. DO NOT APPLY if you have a work history containing any of the above.”

And finally, here’s Kim Wilde, pissed on a train after the Magic FM Xmas party, singing “Kids in America” and “Rocking Around the Christmas Tree”.

Reading List

HTML5 etc

Responsive Web Design

Mobile

Misc

Reading List

Industry

Misc

Reading List

NEWT

Sublime Text 2

I haven’t actually enjoyed using an editor since VAX EDT in my old programming days, but Sublime Text 2 is an excellent program that not only doesn’t get in the way but has lots of utilities and features.

Industry

Dell Extends Ubuntu Retail into India – Unreported, of course, because it’s about FOREIGNERS, but Dell have been featuring Ubuntu on a wide range of Dell computers in China, starting at 220 stores and expanding to 350. They’re also expanding in to 850 stores across India.

misc

Specifying which camera in getUserMedia

getUserMedia started life as a nice little API that allowed the developer to grab video and/ or audio from a device.

navigator.getUserMedia({audio: true, video: true}, success, error);

It’s shipping for camera access in Opera 12 desktop and Opera Mobile 12 and implemented in Chrome nightlies.

The spec has ballooned since I last looked at it in detail. There is a new “constraints API” which adds significant complexity, while the language of the spec isn’t rigorous (yet). This is likely to delay standardisation yet the simplest use-cases that it originally met are the core features.

Originally, it had a method for authors to hint to the user agent which camera to use – you could suggest “user” for the camera that faces you, or “environment” for the camera that faces outwards. This has disappeared from the spec, to be dealt with later, once the complex capabilities & constraints API is fleshed out.

Should the author be able to specify which camera should be used? It seems to me that this would be a good idea. For example, my mobile phone camera is usually set to use the rear-facing “environment” camera, but if I were to start up a video-conferencing app (or any of the fun “Photo booth” apps on Shiny Demos) I’d like the app to switch to using the forward-facing “user” camera without my having to manually switch camera. (Some devices don’t have hardware switches, so would require me to go to a system preference to change which camera to use, which would be a major pain in the arse.)

I strongly feel that the Working Group should allow authors to choose which camera to use before fleshing out advanced capabilities & constraints APIs which are beyond the use-cases of many authors.

However, although most phones will continue to have two cameras, some devices like the Mito 611 have more than two. How do we write a specification for hinting which camera to use with multiple cameras?

Why HTML5 urgently needs an HTML adaptive images mechanism

After the recent kerfuffle about the draft HTML specification for a mechanism for adaptive images, and an excellent compromise suggestion by Florian Rivoal (Opera’s CSS WG rep), the mailing lists have gone quiet again.

(If you don’t know why we need such a mechanism, read Matt “Grrr” Wilcox‘s article Responsive images: what’s the problem, and how do we fix it?.)

We’ve needed such a mechanism for a while, but it’s particularly urgent now. Webkit has implemented a new non-standard CSS function called -webkit-image-set:

selector {
background: image-set(url(foo-lowres.png) 1x,
                      url(foo-highres.png) 2x) center;}

The changeset describes it:

The idea behind the feature is to allow authors to provide multiple variants of the same image at differing resolutions, and to allow the User Agent to choose the resource that is most appropriate at the time. This patch will choose the most appropriate image based on device scale factor.

(Read the email/ specification for -webkit-image-set.)

As far as I can tell, it will be in Safari 6 (OS X 10.8, shipping in July) and Mobile Safari for iOS 6, so we’ll be able to do adaptive background images but not adaptve content images.

Once that happens, I bet it’s 0.03 nanoseconds before developers convert <img src=”foo.blah” alt=”useful alternate text”> into an empty <div>s with adaptive background images using -webkit-image-set and (please!) a fallback background images for non-webkit browsers.

Why wouldn’t they? Retina screens will download massive but beautiful images, while users of lower-res phones save bandwidth by downloading smaller images instead of huge images and then reducing them down. Problem solved.

And, unfortunately, people who don’t download images, or can’t perceive images won’t get any alternate text, as there is no content <img> element any more. Those guys have always been last in the pecking order and there’s no reason to assume they’ll get a better deal this time.

And that’s why some agreement on <picture>, <pic>, <img srcset=”…”> (whatever it is; I don’t much care) needs to happen, and fast.

Update 22 June 2012: WHATWG conversation mysteriously dried, so Matthew Marquis wrote to W3C HTML WG and proposed Florian’s suggestion.

Review: Build Mobile Websites by Castledine, Eftos, Wheeler

I got this book free in lieu of payment for my Sitepoint article Notes on Designing Websites for the Asian Market. When it arrived, I looked in the index for “Opera” and found no entry at all. As this is a book is called “Build Mobile Websites and Apps for Smart Devices” and is about designing mobile websites (not just apps), I decided that the book would be another iOS wankathon, and put it immediately in my recycling pile. (“iOS wankathon” is the technical term employed by medical professionals to describe articles/ books/ conference talks that stupidly assume all mobile users have iPhones or other webkit-based browsers.)

Luckily, I decided to give it a go and picked it up just before getting a flight. It’s actually a really good book, with only one webkit wank (a very low number when “apps for smart devices” is in the title).

There’s good information on responsive web design, although it doesn’t replace Ethan Marcotte’s book, it summarises well. The second edition should add information on CSS Device Adaptation (“CSS viewport”) now that IE10 and Opera support it.

I found the chapter on design for mobile very useful with its different patterns for organising information. The chapter “markup for mobile” was less so, probably because I know more about markup than design.

One slight niggle – in an example app, the use of ellipsis is shown by including the name of a person “I am a celebrity with an incredibly long name for some unfathomable reason”. Long names seem quite common in Thailand, Sri Lanka, Russia, Greece etc; it’s only “unfathomable” if you think in the context of English names.

The only example of webkit wanking comes in the “Mobile web apps” chapter. In order to navigate from page to page, -webkit-animation is used with no other vendor prefixes. The authors have ensured that a simplified page swap is available on other browsers, but that tests WebKitTransitionEvent in JavaScript. Why not just use all the vendor prefixes and the non-prefixed version, and only then fallback to a “simplified” page swap? It’s particularly remiss when Firefox supported Animations from May 2011, while the book was published in June 2011.

Better still would be to ensure that vital functionality like navigation is available everywhere and only then progressively enhanced.

In conclusion, this is a decent book. Client-pleasing stuff such as touch, accelerometer, geolocation is covered. But while it was languishing on my shelf more cutting-edge features have become available. You can still learn from this book now, especially if you’re interested in sites that work well on mobile rather than all-singing all-dancing applications, but it would be good to see a second edition that addresses getUserMedia and proper cross-browser vendor prefixing.