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:
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.
Tim Bray recently wrote an interesting post called </html> in which he stated
interest in work on “vocabulary” (by which they mean the actual angle-bracketed thingies that go into HTML) seems pretty lacking.
Me, I think HTML is done. Which doesn’t mean I think that the whole Web-programming platform is in a good state…
Let’s down tools and focus on more important problems.
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
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”.
I’m encouraged by the Extensible Web Manifesto which states
(Thanks to Steve Faulkner for crunching his dataset —ooh, matron— to provide use stats for <header> and <main>.)
Gosh, what a snappy title. I’m not expecting a job offer from Buzzfeed any time soon.
Today, Apple sent their consolidated feedback on Web Components to the webapps Working Group. The TL;DR: they like the concept, are “considering significant implementation effort”, but want lots of changes first including removal of subclassing, eg <button is=”my-button”>.
my-button element inherits focussability and activation with return or spacebar withut you having to muck about with
tabindex or keyboard listeners. (I wrote about this in more detail last year in On the accessibility of web components. Again.)
Apple raised a bug Remove the support for inherting from builtin subclasses of HTMLElement and SVGElement and notes “without this hack accessibility for trivial components is harder as more things have to be done by hand” (why “this hack”? A loaded term). However, it calls for removal because “Subclassing existing elements is hard as implementation-wise identity is both object-based and name / namespace based.”
Implementation is hard. Too hard for the developers at Apple, it appears. So Web developers must faff around adding ARIA and tabindex and keyboard listeners (so most won’t) and the inevitable consequence of making accessibility hard is that assistive technology users will suffer.
HTML has a series of design principles, co-edited by Maciej Stachowiak who sent Apple’s feedback. One of those is called “Priority of Constituencies” which says
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.
Fine words. What changed?