- The ride to 5 HTML5 Doctor article by @stevefaulkner, with quotes from the great and the good, including me. And Timbo.
- HTML5 is done, but two groups still wrestle over Web’s future – Stephen Shankland’s Cnet report
- W3C: Making Payments Easy on the Web – “the payment landscape is quickly changing, and new challenges are appearing. For instance, the average shopping cart abandonment rate is 72% across all devices, and 97% on mobile.”
- Web Payments: What you need to know – Introductory overview slidedeck
- Axiomatic CSS and Lobotomized Owls – interesting article by Heydon Pickering
- Formal Objection to advancing the HTML Image Description document along the REC track – W3C says “GTFO” to Apple’s objection to the
longdescextension to HTML5 (it isn’t actually part of full-fat HTML). Of course, if Apple don’t implement it, most developers are unlikely to use it; they haven’t used it much in the last 15 years.
- HbbTV 2.0 details revealed, release expected this year – “personalisation and recommendation of content for users, notably in a multi user environment, and the synchronisation of broadband with broadcast content onto one or more screens”
- Why Microsoft matters more than we think by Christian Heilmann. I agree with him. There are far more secretive players around.
- Bringing Interoperable Real-Time Communications to the Web Microsoft-flavoured ORTC API for WebRTC coming to IE. Jacob Rossi of the IE team writes “we’re working on ensuring an API subset is shared between the specs, Google started co-editing & calls it ‘WebRTC 1.1′”
- Excess XSS – “A comprehensive tutorial on cross-site scripting”
- Getting touchy – An introduction to touch and pointer events – Patrick Lauke’s “War And Peace”-esque day-long workshop slides.
- Making custom widgets accessible with ARIA by the jolly super Léonie Watson (how fast is her screen reader?!?)
- Opera and Telenor partner in Burma – free access to wikipedia (and Facebook Zero, whatever that is).
- W3C releases Code of Conduct. So no more “Fuck you, cocknose, go & read the spec!” mails on the lists. End of an era.
Archive for the 'accessibility web standards' Category
That nice Stephen Shankland just published a news report HTML5 is done, but two groups still wrestle over Web’s future on CNET, quoting me a couple of times.
As I’m occasionally asked questions about how I see the two different organisations working together (or not), here are the full questions that Steve asked me, and my responses (as approved unchanged by my bosses at Opera). I’m grateful to Steve for giving me his permission to reproduce them.
SS: How big a problem is it that WHATWG and W3C both are sorta kinda in charge?
BL: It’s not an especially big problem for the vast majority of developers who aren’t developing sites using still-fluid features that are only available in the latest nightlies. Where they differ, the W3C spec is a better guide to the stable features as implemented already in browsers – for example, it has dropped the <hgroup> element, warns about the lack of implementations of the outlining algorithm and has much better advice on using the <main> element today to make websites more accessible to people with disabilities.
SS: Which do you think has more power in charting the future of the standard?
BL: Neither. The power is with browser makers. As Ian Hickson of WHATWG said, it doesn’t matter what the specs say if browsers don’t implement them.
SS: It seems kind of like we have two horses pulling the same cart, with no coordination between the horses. Is this a bad use of resources? Or is that a bad metaphor?
BL: The web is the biggest platform we’ve ever had. Therefore, it has more constituencies and competing interests than we’ve ever seen. It’s absolutely right that those different interest groups slug it out. At least it’s (mostly) done openly, unlike the decisions made behind closed doors by proprietary organisations answerable to no-one.
SS: We can’t rewrite history to excise XHTML 2.0, but should the two communities work to converge into one somehow? Is that even possible?
BL: I’d like to see one community , but suspect the cultural clashes are too large. So we have to get along, working together mostly and fighting occasionally, just like a family – albeit sometimes most like the Addams Family.
SS: How much actual real-world confusion is there among developers? Where should they go to see what the “true” spec says?
BL: If you want to see what’s already implemented in browsers now, look at W3C spec. If you want to see what might be coming (or how things may change) look at WHATWG spec.
Opera implements following the WHATWG spec, because that’s where nitty-gritty of the leading-edge stuff is discussed. But we also actively support and participate in the W3C as we see the value in having stable snapshots that developers can refer to, and it’s also the forum for many other vital spec discussions about Web Manifest, Device APIs etc. It’s possible to love both and, as we’re Norwegian, our hearts are full of love for all.
all: initial. This resets all CSS properties to their initial value, and undoes browser stylesheets – in this example, the
blockquote is no longer indented or
display:block; as you’d expect.
Other values for the property are
inherit, which changes all the properties applying to the element or the element’s parent to their parent value, and
unset which changes all the properties applying to the element or the element’s parent to their parent value if they are inheritable or to their initial value if not.
They’re supported in Opera, Firefox and Chrome. The Mozilla Developer Network page has good examples of these.
What’s curious, though, is that the value that would be the most useful isn’t there at all. I wouldn’t want to completely strip away User Agent styles and then have to reset elements to display block-level and then indent them in CSS. I wonder why there’s no
all: ua-default (or somesuch) to reset them to the User Agent style sheet default?
Update: Saperlipopette! There’s a very good French-language post La cascade CSS avancée: all, initial et unset for those who speak Oohlala.
Microsoft wrote a spec called Pointer Events API that unifies touch, stylus and mouse inputs, and implemented it in IE11 (partially in IE10). Firefox are implementing it too. After initial enthusiasm from Google, Chrome announced that it won’t support it, after all.
- HTTP 203: Pointer Events – 4 min video in which Jank Architect and Longpoll Lewis explain why Chrome thinks the Pointer Events API smells.
- Jacob Rossi of Microsoft disputes the claims (G+ link, sorry).
- More discussion about the Pointer Events Smell video from @SlexAxton, @davemethvin (jQuery): “It all boils down to ‘Why is Chrome+IE+Firefox not enough for Pointer Events, but Chrome+Firefox enough for Touch Events extensions?'”
Other standards ‘n’ shiz
- Preloading and deferred loading of scripts and other resources – Hixie suggests stuff like
<script src=.. needs="previous-script" load-policy="optimistic">
- Building for mobile? Don’t forget that 2G is still “a thing”… a big thing, in fact. says Ilya Grigorik. (Google+ link, sorry)
- Status of Promises in gUM discussion – now gUM is being “moved” to the snappily-named
navigator.mediaDevices.getUserMediaand will use Promises, should “legacy”
navigator.getUserMediacontinue to use callbacks? Yes, in my opinion – there is a lot of stuff already out there.
- Brum Tech Scene – Stuart Langridge interviews @SusannahGoh of Birmingham Science City about health, data, and innovation. Having just returned from Fronteers conference in Amsterdam, I confirm Susannah’s assertion that stroopwafel is a biscuit made of superglue.
- anonabox : a Tor hardware router to anonymise all net use and bypass censorship, easy to hide/ destroy if the Secret Police/ Mullahs are at your door.
- Should getUserMedia and Geolocation continue to work on non-HTTPS sites? asks Anne van Kesteren, who adds “localhost is an authenticated origin, as are file URLs. I also expect developer tool overrides.”
- 2059 Opera commits to Blink/ Chromium/ v8. The second thousand took half as long as the first. Yay.
- CSS: It was twenty years ago today — an interview with Håkon Wium Lie – I interview Håkon, who proposed CSS on 10 October 1994, when it looked very different.
- Fun times with Appcache – “If you are using appcache, the best way is to have a separate webpage with the manifest and wrap it in an iframe. The main advantage of this is that it ringfences the cache… Who says enterprise software can’t do HTML5?” asks Matt Machell.
- To Picturefill, or not to Picturefill asks Scott Jehl. Should you polyfill responsive images and risk users without JS getting no images at all? He tends to “yes”, I tend to “no” for philosophical reasons. Commercial pressures outweigh those, natch.
- On a similar subject: Polyfills and products by Jeremy Keith
- HTTP/2 Frequently Asked Questions
- IndexedDB on iOS 8 – Broken Bad – “Apple may have screwed up their implementation of IndexedDB” says Raymond Camden.
- Chromium “focus should cycle from named anchor” accessibility bug getting some love.
- What Would Bruce Lee Do? The Tao of the Extensible Web by Brian Kardell, a fine and noble chappie who’s realised that, in all matters, Bruces know best.
- The Extensible Web Report Card – Documenting the state of the extensible web
- Text Email Newsletter Standard (TEN Standard) “is designed to ease navigation of plain text email newsletters by all readers, including those using special access technologies.”
- Paying on the Web with Manu Sporny – podcast on Web Payments. Transcript (Yay, Jen Simmons)
- Is autoplaying media always an accessibility no-no? muses Henny Swan, after usertesting the BBC iPlayer.
- Relative URLs in Web Components. My heart sinks a bit if even international spec brainbox @Anne van Kesteren says “this is a hard problem”. Later: “The lack of encapsulation is major hassle… Doesn’t really feel like it deserves to be called components. It’s more like assets.”
- HTML5 does not have a new best friend on why Apple “are some way behind Chrome and Android.”
- 4 billion people in the world don’t have access to Internet—India accounts for 25% of them.
Once in a generation, there is a perfect combination of circumstances that leads to the creation of something truly extraordinary. Today is that day – the flawless union of programming, content, beauty and functionality.
This week at the Future of Web Apps conference, the Stella McCartney of geek crochet, Ruth John, gifted me with a hand-made, individually-designed crocheted mankini. A photo of me wearing it is available on my fashion blog What’s Bruce Wearing Today (caution advised).
At the same conference, Syd Lawrence demonstrated his accelerometer-driven app Shake Her Booty which allows you to control J Lo’s bottom (“booty”) by shaking your phone.
Claudia Snell asked “when can we expect the @brucel version?” so Syd mashed up some video he’d made of me dancing in the mankini at the FOWA after-party, and today has released Shake Your Brucie.
Just tap my booty to begin.
Adam Bradley asked
@brucel meta is data about data right, so why is viewport in a meta tag, since they're instructing the browser what to do & not desc itself?
— Adam Bradley (@adamdbradley) September 22, 2014
Marcos Caceres replied
@adamdbradley @brucel it's the only a element you can use in the head of a doc that is backwards compatible. Nothing to do with semantics.
— Marcos Caceres (@marcosc) September 22, 2014
HTML never required an <html>, <head> or <body> element (only XHTML validators did). So if you open test 1 in any browser and view source you’ll see those three elements aren’t in the source. But if you inspect the DOM with any inspection tool, you’ll the browser has inserted those elements.
How does the browser know where to close the <head> and open the <body>? Test 2 shows a page that contains a <vomitingotter> element. This isn’t offcially part of HTML yet (hurry up Hixie!). There is no <body> element in the source, but the browser knew to leave the <title> and <meta charset> in the head and add the <vomitingotter> element into the <body> (which is why you can actually see its contents; by default, no text in the <head> makes its way into the visible page.)
Simply, the first element that isn’t known to be part of the <head> makes the browser close the <head> and open the <body>. So if it’s not recognised as metadata content (<base>, <link>, <meta>, <noscript>, <script>, <style>, <template>, <title>) it goes in the body. Any subsequent “head” elements remain in the <body>; they aren’t restored into the head (see the DOM of test 3), even if you explicitly wrap them in <html>, <head> and <body> elements in the original source – see test 4.
This doesn’t investigate the bigger question of why Apple – who invented the viewport meta tag – decided to add it to HTML at all. After all, HTML is about content and the viewport information is about styling, and would therefore be more appropriately be declared in CSS. I don’t know the answer to that, except that Apple knows best about everything.
There’s a CSS specification called CSS Device Adaptation that is basically “viewport in CSS”, with an @viewport rule (tutorial by Andreas Bovens). This generalises the viewport directive, and gives you more power, too; because it’s in CSS you can combine it with Media Queries. It’s supported in Opera, Chrome and Internet Explorer.
- Flexbox: changes since the previous spec
- Don’t use <picture> (most of the time) by Jason Grigsby. TL;DR: if you just want resolution switching (smaller image to non-“retina” devices, big image only to high-dpi screens), just use
<img src="lores.jpg" srcset="hires.jpg 2x">
- Using ServiceWorker in Chrome today and, indeed, other Chromium browsers. Excellent article by Jank Architect.
- Better @font-face with Font Load Events by Zach Leatherman
- The initial work for Manifest in Chromium M39 is done, and will hopefully be in Firefox OS 2.2. (Explainer article.)
- A Greater Voice for Individuals in W3C: Tell Us What You Would Value
- Primary Key issue on iOS8 implementation of IndexedDb. “when you have two different object stores in the same indexeddb, primary key values appear to be “shared” across all stores.” hurray.
- Accessibility issues with html5 <footer>: not exposed; should be exposed with an IA2 footer role and xml-roles/implicit aria role of contentinfo in some circumstances – fixed in Chromium.
- Brum Tech Scene – That nice @sil came round to my house and videoed me answering his questions about the Birmingham tech scene and biscuits.
- When can a High Court grant an injunction to trade mark holders against ISPs to block access to “infringing” websites? – Open Rights Group on an important test-case
- Support the independents “If you use a product that has a free version and a paid version, paying out for that “pro” or commercial license even if perhaps you could get away with not doing so, puts cash into the company, helps to ensure the survival and development of the product” says Rachel Andrew.
- LULZ: “JSONx is an IBM® standard format to represent JSON as XML.” – for those who want the joys of JSON with the piquant frisson of XML. Who doesn’t?
- EXTRA LULZ: Even Apple didn’t want my iPhone 6 Plus – unusual satire piece from The Verge, spoofing a cryPhone user whose emotional rollercoaster (caused by the new device being slightly bigger than his other one, which is why he bought it) culminates with the hilarious “I spent all this money on something that I thought would make me happy, and instead I felt like trash”. Genius.
- Web Components punch list – “Considerations for web component and custom control design: If your control has the stuff below covered, excellent! If not then please implement it before shouting to the world about it being the next big thing.” by Steve Faulkner
- Brum Tech Scene – On Monday, Stuart Langridge launched a series of interviews and conversations with interesting people doing interesting things in the Birmingham tech community. First is Simon Jenner, Head of Oxygen Startups and co-founder of Silicon Canal. He videoed me, too; coming soon.
- Who is “Joe Developer”? asks @johnfoliot. The background is the “living standards” vs “W3C snapshot” holy war. It’s a good question.
- What next for HTML? – now HTML5 is a W3C Proposed Recommendation, how should the language be further developed? Put your questions to editor Robin Berjon for an HTML5 Doctor interview
- The URL mess on the competing standards for defining how URLs work, by Larry Masinter
- Chromium: Web Application Manifest implementation chugs along (@marcosc & I wrote an explainer)
- All You Need To Know About Vertical-Align – “vertical-align can be a real scumbag sometimes. I set myself the target to clarify the behavior once and for all”
- Opera Mini to be pre-installed on all upcoming Micromax Android devices available in India, Russia, Bangladesh, Sri Lanka and Nepal
- Getting Started with Sass by Laura Kalbag
- iOS 8 and iPhone 6 for web developers and designers: next evolution for Safari and native webapps – they kept it quiet, but there’s a new phone and OS from FruitCo. Maximiliano Firtman does some testing so you don’t have to.
- Life Changed Much? – “Occasionally, new technology changes lives. But mostly it doesn’t.” by Tim Bray
I was lucky enough to visit Berlin very briefly for the Extensible Web Summit. It was organised, it seems, by members of W3C (but was not an officially branded W3C) and hosted by Beuth University, Berlin. Lunch was provided by Google, beers afterwards by Yandex (although I missed those as I’d taken the inexplicable decision to fly back straight after rather than hobnob with the great, the good, and Chaals.) Thanks to all organisations.
This isn’t a record of the day; the event notes were crowd-scribed. It’s my preliminary thoughts about the concept of the “extensible web”.
As far as I can deduce – because the term “extensible web” wasn’t actually defined on the day – it’s about giving/ exposing primitives so developers can extend various parts of the platform. (Read The Extensible Web Manifesto for a longer description and statement of intent.)
In the current world, we wait for something like Appcache to be specified, then implemented and then scoffed at. This can take a long time, and we might not get what we want; Hixie told me “The appcache API is another big mistake. It’s the best example of not understanding the problem before designing a solution … Appcache works great if you want to do what it was designed for, but it turns out most people want to do something different enough that appcache feels horrible to them”.
But while it’s good to explain magic, I feel we need to be careful about using the word “magic” pejoratively. A lot of the success of the Web was that simple HTML tags (<a>, <input>) made magic happen. You write <img src=”vomiting-otter.jpg”> and a vomiting otter appears; you don’t need to worry about how it gets there over the network, its caching, its format, etc. Similar with <input> – you just code a reasonably obvious word in angle brackets and it works.
As Steve Faulkner notes, a lot of the success of accessibility on the Web is/was that simple HTML elements makes accessibility happen.
Service Workers, and the spec that I’ve been closer to, <picture>, are great examples of listening to developers (partnership). Service Worker came out of a meeting between Opera, Mozilla, Google, BBC, Financial Times etc and was specified by Google, Mozilla and Samsung (and many others). <picture> came about because developers demanded it, even when the browser vendors and standards bodies didn’t care.
How can developers make their voices heard? It’s true that browser vendors are OBSESSED with solving developer’s problems. If we don’t, you’ll make native apps, and then browsers disappear, we default on our mortgages, our partners leave us for Apple employees and our hamsters starve. None of us want this to happen. So we try to listen.
Then there is the question of how developers can participate. The bravery barrier to entry for many of the mailing lists is already too high – I periodically get emails from people asking me to propose a feature or ask a question on a list as a proxy because lists are scary places.
W3C has set up a Specification forum where you can ask questions about specs/ propose a feature. Read around it to see if anyone else has a similar proposal, and if appropriate, add comments to that before you set up a new thread. Use Mozilla’s guidelines WebAPI Design Guidelines and please remember that use-cases are much better than a fully-worked out proposed syntax.
I’m enthused about the Extensible Web manifesto and the progress we’ve already made, eg baking popular jQuery-like syntax into browser engines via the Selectors API, getting our hands on the network with Service Worker, and the heady new world of Web Components. We need to ensure that all devs who want to can participate by allowing ease of collaboration, courteous discourse. And it would be perilous to forget that the declarative web reduces the barrier to entry and enhances accessibility.