Review: Volpone, Royal Shakespeare Company

Volpone at RSC was very good last night. Sometimes the pacing was a little wobbly (mostly in the courtroom scenes), and Henry Goodman fluffed a line or two, but it was only the second performance. Goodman’s big set piece – Volpone pretending to be an Italian snakeoil peddlar – was hilarious (and he accused me of being a Norwegian from the stage in an audience participation section).

It’s a Ben Jonson play, so all of the characters are ciphers (and named according to type: Volpone the fox, Sir Politic Would-be, Corvino the crow etc) so don’t expect deep psychology, but more the Jonson parade of fools, monsters and freaks. The drawf, hermaphrodite and eunuch were excellent, and Trevor Nunn’s direction setting it in the Facebook and selfie era was inspired.

Reading List

On labelling NHS prescriptions with their real cost

Jeremy Hunt announced that all medicines costing over £20 will be marked “funded by the UK tax payer”. Fair enough. I’m happy to pay my taxes to help those who are sick. I call this idea “civilisation”. But it’s right that people understand where the money comes from.

Similarly, I trust that every sleeping member of the House of Lords wear a sign around their necks saying “My attendance today cost 7.5 medicines”; every ministerial breakfast be costed in terms of the number of life-saving drugs that could have been supplied but weren’t, because croissants were more important; every MP’s hotel room that isn’t the cheapest one on have a similar advisory notice on the wall and the receipt. GCHQ should have a sign outside saying “spying on you today cost 1 million prescriptions”.

That would be fair, because we’re all in it together. Aren’t we?

Edge Conf: notes on User Queries

Edge Conference is basically like TPAC for web developers, so there are always great hallway and pub chats sparked by the main speeches. I’ll write up the breakout session that my boss, Andreas Bovens gave on Installable Web Apps/ Progressive Apps (the jury is out on the preferred name) tomorrow, but there was another interesting conversation I was asked about, so here goes.

In the CSS breakout session (which I didn’t attend) the idea of user queries was discussed. Orde Saunders wrote it up:

The twitter pitch for user queries is: “Like media queries but for user preferences.” … With user queries there would be a number of settings available in the user agent. Presented via a settings UI these would allow users to set certain preferences that were then made available in the runtime in the way media queries provide information about the user agent.

One problem with this is the classic web dev chicken-and-egg problem. Web developers wouldn’t use it until it’s in browsers, browser makers wouldn’t add it until consumers requested it, and consumers won’t request it because they don’t know it’s (theoretically) possible.

Another problem is that most developers wouldn’t care enough to add something to stylesheets that reacted to an expressed user preference for high contrast like this:

@user (contrast: high) {
  background-color: white;
  color: black;

and consumers wouldn’t bother expressing preferences if only a handful of sites took note of them.

The proper place for acting on user preferences, I think, is in the browser rather than in the stylesheets of individual sites. We’ve seen the latter experiment in the early 2000s in which some sites gave a method of upping the font size on their sites and remembering the user choice with a cookie. But this only worked for that site. So browsers and operating systems provided a mechanism for zooming, or over-riding the author stylesheets and imposing a minimum font size for all sites.

There are many examples of this: night mode settings that reverse colours; Opera Mini’s image quality setting that will always choose the lowest-quality image, regardless of what <picture> and srcset say, in order to save bandwidth (or even download no images at all); mouse gestures for those who prefer to browse that way; settings to avoid auto-start media; extensions that spoof location to get over location-based content blocking. or block advertising. These work on all sites, regardless of whether the developer cares about user preferences.

And I declare an interest here: I work for a browser vendor and such settings are exactly the kind of personalisation and UX enhancements that we compete on, now we’ve seen the light and stopped building nonsensical proprietary web “standards” to lock users in.

Reading List

Progressive Apps and bikeshedding with Alex Russell

In the corridor track at Velocity Conference, Santa Clara, I had a natter with international glamourpuss Alex Russell about Installable Web Apps/ HTML Manifest and Opera’s forthcoming implementation on Android. Alex has elegantly written his thoughts down in Progressive Apps: Escaping Tabs Without Losing Our Soul. Go and read it, because he’s absolutely right, except for one thing.

The name. He was so close:

Frances called them “Progressive Open Web Apps” and we both came around to just “Progressive Apps”. They existed before, but now they have a name.

“Progressive Open Web Apps” makes the satisfying acronym “POWA”. Enthused and infused with the mightiness of HTML App Manifest, Add to Homescreen and Web App Install banners, I went to the Marvel comics’ Superhero generator and gave them a mascot for the collective pusissance. Meet…The POWA-arranger:

POWA arranger

I jest, of course. Doesn’t matter to me what they’re called. A good user experience, and all the power of URLs and the Web is what matters to me. As Alex writes

Building immersive apps using web technology no longer requires giving up the web itself.

Stay tuned for an announcement about this functionality in Opera for Android. Product Manager Andreas Bovens will be leading a breakout session about installable web apps at Edge Conference London on 27th July. I’ll be there too, to straighten his tie, warm his microphone and shake my pom-poms.

Whether or not you’ll attend in person (it’ll be streamed and recorded) feel free to add questions or discussion points.

Reading List

Is HTML ‘complete’?

Tim Bray recently wrote an interesting post called </html> in which he stated

in­ter­est in work on “vocabulary” (by which they mean the ac­tu­al angle-bracketed thin­gies that go in­to HTML) seems pret­ty lack­ing.

Me, I think HTML is done. Which doesn’t mean I think that the whole Web-programming plat­form is in a good state…

Let’s down tools and fo­cus on more im­por­tant prob­lem­s.

I agree with Tim that fixing the web platform is more important right now than adding more elements to HTML. He cites fixing the things that jQuery, Backbone, Angular, Less, DART et al are trying to fix. Those too, but I’d also cite Service Workers, Web Manifest, device APIs as things that are urgently required to bring some level of feature-parity between web and native.

But I think it’s incorrect to claim HTML is finished. We’ve been there before, with HTML 4.01 published in December 1999 and then considered “finished”. HTML5 added lots more elements, some of which are well-used (20% of the top 100,000 sites use the HTML5 doctype, 12.% of those use <header>, for example).

Some of the HTML5 elements haven’t gained good traction. I’m inclined to agree with Matthew Thomas, who wrote (in 2004!) that new elements need to have some form of User Interface:

One way of improving this situation would be to reduce the number of new elements — forget about <article> and <footer>, for example.

Another way would be to recommend more distinct default presentation for each of the elements — for example, default <article> to having a drop cap, default <sidebar> to floating right, default <header>, <footer>, and <navigation> to having a slightly darker background than their parent element, and default <header>…<li> and <footer>…</li> to inline presentation. This would make authors more likely to choose the appropriate element.

Not every manifestation of UI is visual, however. There are still many gaps in the language that have to be patched with WAI-ARIA; on the webkit blog, James Craig writes

Many of the original features of ARIA (such as dialogs, landmarks, and menus) have been adopted into recent versions of HTML as elements. However, there are interaction patterns, common on the Web since the 1990s, that still have no native support or unreliable rendering support in HTML, such as date pickers, combo boxes, tab sets, data grids, tree controls, and more. Web developers must render all these controls themselves, using custom code or a JavaScript framework.

Steve Faulkner has a list of Aria roles and properties not available in HTML5. I’m not suggesting all should become elements or attributes, but it shows that what people make constantly outpaces the semantics available in HTML.

Since the WHATWG stopped adding new elements, we’ve seen the <main> element added to the language, which —although comparatively new— is used on 5% of the HTML5 sites in the top 100,000. Although it has no visual UI, it hooks into assistive technologies so that users can quickly get to the main content on a page.

Similarly, <picture> and associated responsive images attributes (srcset, sizes, x and w descriptors) have been added to the language.

Brian Kardell, Léonie Watson, and Steve Faulkner are working on a spec for a Panels and Panel Sets Extension that “defines elements and attributes for constructing a panel or collection of panels based on a single interaction paradigm.”

Elsewhere, attempts at adding other useful declarative features to the language are rebuffed. For example, <table sortable> was specified (with 9 years of anecdata from Stuart Langridge) to allow data tables to be natively sorted in the browser (a very common use-case), but implementation was rejected because “Instead of trying to bake so much into the platform someone should create a web components library that supports Hixie’s spec”.

Ah, Web Components – not ready for production any time soon, totally reliant on JavaScript, and so much harder for authors to implement than adding a single attribute.

I’m encouraged by the Extensible Web Manifesto which states

We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization… We want web developers to write more declarative code, not less.

Trialling stuff out in JavaScript, and then standardising it and adding it to core HTML/ CSS is the future of standardisation, I think. So, to declare HTML “finished” is, in my opinion, premature.

(Thanks to Steve Faulkner for crunching his dataset —ooh, matron— to provide use stats for <header> and <main>.)

Reading List

The Girl In The Room

A 4 chord ditty that’s under 2 minutes but took ages to record; I moved it from acoustic guitar folk ballad to a chamber-style serenade (“a musical greeting performed for a lover… an evening piece, one to be performed on a quiet and pleasant evening”) because that’s what the lyrics are (kind of) about.

The girl in the room
talks at dusk of musk and sandalwood
Of warm winter mornings
and cool summer nights.
Telling tales without tomorrows
of her yesterdays and ancient times;
of a castle in the birch trees
in the calmness of twilight.

The girl in the room
is thunder-lightning: fiercely beautiful;
weighed down with words, then musical,
with her faces in her moon.
She asks if you could love her
and before you can recover
she needs to be somewhere or other.
Through the trees, the breeze sings tunes.

The girl in the room
talks at sunset in her box of text,
of monsoon rain and games and sex
and the ruins where bluebells bloom.
Lost in feelings like a forest,
there are no certain maps to happiness;
She spills wine on her Chinese dress,
and the breeze brings you tunes.

(Written in Barcelona and Cambodia, recorded in Birmingham, mixed in Santa Clara, California. No bluebells were harmed during the making of this song.)

Words and music © Bruce Lawson, 2015

Posted in my music . Comments Off on The Girl In The Room