HTML5 accessibility
A glanceable one-stop-shop for how today’s browsers are dealing with today’s accessibility features. Then you can dive deeper into each one.
Here's a little piece of web history: the proposal that was presented and rejected at the 2004 W3C workshop that led to the formation of the WHATWG.
A glanceable one-stop-shop for how today’s browsers are dealing with today’s accessibility features. Then you can dive deeper into each one.
A new presentation from the wonderfully curmudgeonly Steven Pemberton, the Nosferatu of the web. Ignore the clickbaity title.
I don’t agree with everything he says here, but I strongly agree with his preference for declarative solutions over (or as well as) procedural ones. In short: don’t make JavaScript for something that could be handled in markup.
This part really, really resonated with me:
The web is the way now that we distribute information. We will need the web pages we create now to be readable in 100 years time, just as we can still read 100-year-old books.
Requiring a webpage to depend on a particular 100-year-old implementation of Javascript is not exactly evidence of future-thinking.
Mike runs through the history of Flash. Those who forget the history of the web are doomed to repeat it:
The struggle now seems to be turning to native apps versus non-native apps on the mobile platform. It is similar to Flash’s original battle ground: the argument that the Web technology stack is not suitable for building applications with a polished user-experience.
This is hilarious …for about two dozen people.
For everyone else, it’s as opaque as the rest of the standardisation process.
HTML5 is now a W3C recommendation. Here’s what a bunch of people—myself included—have to say about that.
Getting consistent browser behaviour for the placeholder attribute.
You can quote me on this markup pattern.
Something is happening.
Agreeing and disagreeing with Divya.
Who knows where the time element goes?