Archive for the 'mobile' Category

Reading List

Apologies for the irregularity of the Reading List at the moment; September and October are autumn conference season and my schedule is bonkers.

Responsive Images

A meeting at Mozilla Paris on how to solve Responsive Images, organised and summarised by Marcos Caceres concluded

  • Browser vendors agree that srcset + DPR-switching is the right initial step forward (i.e., the 2x, 3x, etc. syntax).
  • Agreement to then consider srcset + viewport size after some implementation experience (possibly drop height syntax from srcset spec). If not implemented, Width/Height syntax to possibly be marked at risk in srcset spec.
  • Browser makers acknowledge the art-direction use case, but still think <picture> is not the right solution.
  • Adding new HTTP headers to the platform, as Client-Hints proposes to do, has had negative impact in the past – so Client Hints might need to be reworked at bit before it becomes more acceptable to browser verndors.

So initially, we’ll use something like

<img src="normal.png" 
srcset="retina.png 2x"
alt="otter vomiting">

Browsers that have “retina” displays will choose retina.png as they have 2 CSS pixels to one physical pixel. Browsers that aren’t retina, or don’t understand the new syntax, fall back to the good old src attribute.

WebKit and Blink have implemented (but not yet shipped) srcset, Mozilla is planning implemention now.

Meanwhile, an alternative “srcN” proposal has been put forward by Tab Atkins and John Mellor (excitingly, “John Mellor” was the real name of The Clash’s Joe Strummer). It claims to solve Resolution-based discrimination, Art-direction discrimination and Viewport-based discrimination usecases. Discussion here.

UK Government Web

The Cabinet Office’s Open Standards Board is recommending open standards technology. The first two to be approved are HTTP/1.1 and Unicode UTF-8. Francis Maude, the Minister, allegedly said “open standards will give us interoperable software, information and data in government and will reduce costs by encouraging competition, avoiding lock-in to suppliers or products and providing more efficient services”.

This may not be revelatory to those of us in the web world, but it’s a Good Thing for the nation.

I had the pleasure of hearing Paul Arnett (now of Twitter, previously of gov.uk) talking about the gov.uk initiative at From The Front conference a few days ago, and thought it was a sign of schizophrenia that the same government that can allow subject experts make a world-leading governmental portal is the same government that disregards experts and its own consultation in wanting to censor the web.

I realise now that it’s the old Tory DNA: the belief in encouraging competition by economic liberalism, reducing bureaucracy, while remaining socially authoritarian and reeling from one moral panic to the other. So no change there.

Standardsy Stuff

Misc

Reading List

Here’s your bank holiday reading list!

Reading List

Responsive images

WebKit has (partially) implemented a new attribute to our ancient chum <img> called srcset that allows authors to send a high-res image only to browsers that have high-resolution displays. It looks like this:

<img alt=… src="normal-image.jpg" srcset="better-image.jpg 2x">

That “2x” thing after the file name means that if a browser has 2 or more physical pixels per CSS pixel (eg, high resolution), it is sent better-image.jpg. If it’s not high-res, or if it’s a browser that doesn’t support srcset, it gets normal-image.jpg. There’s no JavaScript required, and it doesn’t interfere with browsers’ pre-fetch algorithms because it’s right there in the markup.

You can extend it further if you want to:

<img alt=… src=… srcset="better-image.jpg 2x, super-image.jpg 3x">

This implementation doesn’t have the horrible “pretend Media Queries” syntax that sources close to Tim Berners-Lee* called “like, a total barfmare, man”, but this is potentially a great leap forward; it saves bandwidth for the servers, stops people downloading gigantic images that they don’t need, is easy to understand and has graceful fallback.

Let’s hope it turns up in Blink, Trident and Gecko soon.

* “sources close to” is UK newspaper code for “we just made it up”.

Graceful degradation of SVG images in unsupporting browsers

Very very clever: SVG and <image> tag tricks. (Yes, <image> which the HTML5 parser aliases to <img>.)

Microdata / RDFa / “semweb” shizzle/ SEO

In The Downward Spiral of Microdata, nice Mr Manu Sporny predicts the death of “HTML5″ Microdata and the triumph of RDFa Lite now that both WebKit and Blink have dropped support for the Microdata API (which allowed JS access to Microdata).

Co-incidentally, Mr Sporny is an inventor of RDFa Lite. Personally, I don’t care which triumphs – now only Opera Presto supports the Microdata API, there is no technical reason to prefer one to the other (in fact, as Facebook supports RDFa and not microdata, so you could argue it has greater utility).

Save bandwidth with webP – soon with fallback!

A long time ago, “responsive” didn’t mean “resize your browser window repeatedly while fellow designers orgasm until they resemble a moleskine atop a puddle”. It simply meant “Reacting quickly and positively”, meaning that the page loaded fast and you could interact with it immediately.

One way to do this is to reduce the weight of the page by serving images that have a smaller file-size, thereby consuming less bandwidth and taking less time to download a page. In the last year, web pages download approximately the same number of images, but their total size has increased from about 600K to 812K, making images about 60% of the total page size.

One way to reduce this amount is to encode images in a new(ish) format called webP. It’s developed by Google and is basically a still version of their webM video codec. Google says

WebP is a new image format that provides lossless and lossy compression for images on the web. WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller in size compared to JPEG images at equivalent SSIM index. WebP supports lossless transparency (also known as alpha channel) with just 22% additional bytes. Transparency is also supported with lossy compression and typically provides 3x smaller file sizes compared to PNG when lossy compression is acceptable for the red/green/blue color channels.

Opera uses it precisely for this compression; it’s used in Opera Turbo, which can be enabled in Opera desktop, Opera Mobile and the Chromium-based Yandex browser. This transcodes images on-the-fly to webP before squirting them down the wire and, on slower connections, it’s still faster.

In tests, Yoav Weiss reported that “Using WebP would increase the savings to 61% of image data”.

WebP is currently supported only in Opera (Presto), Google Chrome, Yandex and Android Browser on Ice Cream Sandwich, which makes it difficult to deploy on the Web. Firefox doesn’t like it and IE hasn’t said anything (I wonder if the new confidence about technologies in the VP8 video codec on which it’s based might make them feel better about it?)

However, there’s some handy new CSS coming to the rescue soon (when browser vendors implement it). We’ve long been able to specify CSS background images using background-image: url(foo.png);, but now say hello to CSS Image Values and Replaced Content Module Level 4’s Image Fallbacks, which uses this syntax:

background-image: image("wavy.webp", "wavy.png", "wavy.gif");

(Note image rather than url before the list of images.)

The spec says “Multiple ‘image -srcs’ can be given separated by commas, in which case the function represents the first image that’s not an invalid image.”

Simply: go through the list of images and grab the first you can use. If it 404s, continue going through the list until you find one you can use. Note that this isn’t supported anywhere yet, but I hope to see it soon.

[Added after a reminder from Yoav Weiss:] It needs finessing too; Jake Archibald points out “If the browser doesn’t support webp it will still download ‘whatever.webp’ and attempt a decode before it’ll fallback to the png” and suggests adding a format() qualifier, from @font-face:

background-image: image("whatever.webp" format('webp'), "whatever.jpg");

But what about old [current] browsers?, I hear you ask. Give them the current url syntax as fallback:

background-image: url("wavy.gif");
background-image: image("wavy.webp", "wavy.png", "wavy.gif");

Now all browsers get a background image, and those that are clever enough to understand webP get smaller images. Of course, you have to make a webP version (there are webP conversion tools, including a Photoshop plugin).

It seems to me that the spec is overly restrictive, as it seems to require the browser to use the first image that it can. webP is heavily compressed so requires more CPU to decode than traditional image formats. Therefore, I could imagine a browser that knows it’s on WiFi and using battery (not plugged in) to choose not to use webP and choose a PNG/ JPG etc to save CPU cycles, even though the file-size is likely to be larger.

What about content images?

Of course, not all images on your webpages are CSS background images. Many are content images in <img> elements, which doesn’t allow fallbacks.

There is, however, an HTML5 element that deliberately allows different source files to get over the fact that browsers understand different media formats:

<video>
<source src=foo.webm type=video/webm>
<source src=foo.mp4 type=video/mp4>
... fallback content ...
</video>

Wouldn’t it be great if we could use this model for a New! Improved! <img> element? We couldn’t call it <image> as that would be too confusing and the HTML5 parser algorithm aliases <image> to <img> (thanks Alcohi). So for the sake of thought experimentation, let’s call it <picture> (or, if we’re bikeshedding, <pic> or —my favourite— <bruce>). Then we could have

<picture>
<source src=foo.webp type=image/webp>
<source src=foo.png type=image/png>
<img src=foo.png alt="insert alt text here"> <!-- fallback content -->
</picture>

And everyone gets their images, and some get them much faster.

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