5by5 | The Web Ahead #73: DRM with Jeremy Keith and Doug Schepers on Huffduffer
Here’s the chat I had with Jen and Doug about the prospect of DRM in browsers.
Here’s the chat I had with Jen and Doug about the prospect of DRM in browsers.
This is the worst idea for a W3C community group ever. Come to think of it, it’s the worst idea for an idea ever.
Scott gives us an excellent State Of The Web address, looking at how the web can be central to the coming age of ubiquitous computing. He rightly skips through the imitation of native apps and gets down to the potential of just-in-time interactions.
Dr Harry Halpin writing in the Guardian about the crucial crossroads that we have reached with the very real possibility of DRM mechanisms becoming encoded within HTML:
Most of us are simply happy to launch our browsers and surf the web without a second thought as to how the standards like HTML are created. These standards are in the hands of a fairly small set of standards bodies that have in general acted as responsible stewards for the last few years. The issue of DRM in HTML may be the turning point where all sorts of organisations and users are going to stop taking the open web for granted.
Bruce sits down for a chat with Hixie. This is a good insight into the past and present process behind HTML.
Bruce writes about a worrying trend in standards work:
Tossing a specification that you’ve written in-house, in secret and already implemented onto a table at W3C, saying “here, standardise this” as you saunter past isn’t a Get Out of Jail Free card for proprietary misdemeanours. And it isn’t standardisation.
There’s a W3C community group now for looking at the responsive images question.
Alex weighs in on the newly-reopened debate on vendor prefixes, roundly squashing Henri’s concerns.
Daniel responds to Henri’s call-to-arms on vendor prefixes. While he stridently disagrees with most of what Henri suggests, there is also overlapping agreement: they both want vendor prefixes to ship only in experimental builds, not stable browser releases.
This encapsulates the difference between the WHATWG and the W3C: a concern for interoperability matched against a concern for procedure.
While others recall Steve Jobs’s legacy with Apple, Tim Berners-Lee recounts the importance of NeXT.
Bruce nails his colours to the mast of future-friendliness (and nicely summarises recent heated debates between John Allsopp, Alex Russell and Joe Hewitt).
John pushes back against the idea that browser innovation is moving too slow.
I was all set to bristle against an attack on the W3C from Alex …but when I actually read the post, I found it hard to disagree with. If anything, this shows just how much Alex cares about the W3C (probably more than most people).
The conversation in the comments is worth reading too.
A fascinating examination by Hixie of web technologies that may have technically been “better” than HTML, but still found themselves subsumed into the simpler, more straightforward, good ol’ hypertext markup language.
The follow-on comments are definitely worth a read too.
An excellent zero-edit counter-proposal from Anne detailing why version numbers are unnecessary and undesirable for HTML.
Some excellent cross-polination between HTML5 and internationalisation — remember the other two Ws that come before Web in WWW.
Some musings from Norman Walsh. I have to say, I’m still not entirely sure why the HTML/XML Task Force exists. The “use cases” described here are vague and handwavey.
Tantek is as disappointed as I am with the buzzword-compliant definition of HTML5 being pushed by the W3C.
Instead of providing precision and clarity, they’ve muddied the definition of HTML5 further with yet another “here’s our bucket of things we like which we’re going to call ‘HTML5’” message.
Curiously, though, the standards group—the very people one might expect to have the narrowest interpretation of what exactly HTML5 means—instead say it stands for a swath of new Web technologies extending well beyond the next version of Hypertext Markup Language.
Documenting the use and abuse of fragment identifiers.
Bobbie is publishing the interviews he conducted with various HTML5 bods when he was researching his Technology Review article. First up: Hixie.
This W3C document is done and dusted: proposed recommendation. Every one of the guidelines for optimising for mobile also holds true for "desktop" sites.
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.
I couldn't agree more with this rant from Remy. He took the words right out of my mouth.
An all-in-one validator from the W3C: markup, CSS and feed validation.
Science meets standards: NASA joins the W3C.
An excellently written zero-edit change proposal from Edward O'Connor and others, refuting issues raised by Shelley Powers (I offered to help with this change proposal but I never followed through).
Microsoft, Mozilla and Opera have formally submitted the WOFF font format to the W3C.
Purely for my own benefit because I keep needing this URL, here are the current outstanding issues registered at the W3C for HTML5.
An excellent piece by Bruce on why the details element needs to be in HTML5.
Your one-stop shop for ongoing accessibility work related to HTML5.
An entertaining and accurate history of markup up to and including HTML5.
Maciej Stachowiak is an inspired choice as co-chair of the HTMLWG. His evenhand peace-making has already made him an HTML5 hero.
Wendy gives some commentary from her ringside seat at the theatre of HTML5.
Bert Bos's 2000 Treatise (published in 2003) is a must-read for anyone involved in developing any kind of format. "This essay tries to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, longevity, and other long words ending in -y."
It looks like XHTML2 is going to get mothballed at the end of this year.
Eleven years old and more relevant than ever.
The W3C validator—one of the most valuable tools in the web developer toolkit—is in danger. Please help out. And please spread the word.
Henri Sivonen's HTML5 validator has now been integrated into the W3C validator.
Mike Smith has extracted all the parts of the HTML5 spec related to authoring (as opposed to error handling, DOM and other user-agent instructions) to create a pure markup spec. Very handy.
WCAG 2.0 has just entered proposed recommendation status. What a long strange trip it's been.
Shawn at the W3C wants feedback on the ARIA working draft, particularly "feedback on host language embedding, that is, how ARIA is implemented in HTML, XHTML, SVG, and other host languages." If you don't chime in now, don't bitch later.
A good overview of ARIA from the mighty Gez Lemon. There seems to be quite a bit of overlap with some HTML5 ideas here.
The selector of the beast does not exist.
The last piece is falling into place. IE8 has ARIA support, Mozilla has ARIA support ...and now WebKit is getting there. Excellent!
For those times when you need to validate your markup but you don't have a 'net connection.
Here's the in-depth lowdown on the CSS Eleven supergroup announced by Andy at Web Directions South last week.
I was feeling very browbeaten after Molly's tirade but count on Jeffrey to put things in perspective.
The Validator got a new lick of CSS paint and it's looking good.
Stephanie Sullivan has redesigned. Her site is now almost as smart and sassy as she is. Very nice work, Steph.
Happy tenth birthday, CSS.
The W3C Validator now has an API. It's SOAP only unfortunately, but this could still prove to be immensely useful for rolling into a CMS.
Who says the W3C don't have a sense of humour? Check out the logo of the Web API Working Group (who are doing great work, by the way).
The W3C proves that it can move with the times: "The mission of the W3C Web API Working Group is to develop specifications that enable improved client-side application development on the Web." This is very good news indeed.
An interview with Tim Berners-Lee. He likes blogs.