This is an excellent initiative by the Dutch Fronteers group to have professional web developers represented in W3C working groups. In this particular case, they’re funding Rachel for the CSS working group. This sets a great precedent—I really hope the W3C goes for it!
If you’ve ever wondered what it would be like to be a fly on the wall at a CSS Working Group meeting, Richard has the inside scoop.
The consensus building is vital. Representatives from all the major browsers were in the room, collaborating closely by proposing ideas and sharing implementations. But most fundamentally they were agreeing together what should go in the specifications, because what goes in the specs is what gets built and ends up in the hands of users.
Hadley points to the serious security concerns with AMP:
Fundamentally, we think that it’s crucial to the web ecosystem for you to understand where content comes from and for the browser to protect you from harm. We are seriously concerned about publication strategies that undermine them.
The anchor element is designed to allow one website to refer visitors to content on another website, whilst retaining all the features of the web platform. We encourage distribution platforms to use this mechanism where appropriate. We encourage the loading of pages from original source origins, rather than re-hosted, non-canonical locations.
That last sentence there? That’s what I’m talking about!
Given my experience publishing Resilient Web Design as a web book, I think I should take a good look at this nascent spec.
What we envision for Packaged Web Publications is similar to the goals and techniques of Progressive Web Apps: breaking the boundaries between web sites and mobile apps, an emphasis on “offline” paradigms, and so on. The time is right to broaden the scope and power of the web to include publications.
Web developers aren’t going to shed many tears for Flash, but as Bruce rightly points out, it led the way for many standards that followed. Flash was the kick up the arse that the web needed.
He also brings up this very important question:
I’m also nervous; one of the central tenets of HTML is to be backwards-compatible and not to break the web. It would be a huge loss if millions of Flash movies become unplayable. How can we preserve this part of our digital heritage?
This is true of the extinction of any format. Perhaps this is an opportunity for us to tackle this problem head on.
Here’s an interesting proposal to slightly amend the semantics of the
small element so it could apply to the use-case that
hgroup was trying to cover.
If you’re building a blogging platform, you can allow your users choose from a wide variety of posting clients by implementing the Micropub spec.
If you’re building a posting client and want it to work with many different server backends instead of hard-coding it to Twitter or other proprietary APIs, implement the Micropub spec and you’ll quickly have people eager to start using the app!
The Encrypted Media Extensions (EME) addition to HTML is effectively DRM with the blessing of the W3C. It’s bad for accessibility, bad for usability, bad for security, and as the Internet Archive rightly points out, it’s bad for digital preservation.
It’s fascinating to look back at this early proposal for CSS from 1994 and see what the syntax might have been:
A one-statement style sheet that sets the font size of the h1 element:
h1.font.size = 24pt 100%
The percentage at the end of the line indicates what degree of influence that is requested (here 100%).
A damning assessment of Tim Berners-Lee’s defeatist portrayal of the W3C:
No matter which side is right, the W3C faces an existential crisis.
- The W3C is a shepherd of the web for all, the web on everything, and a web of trust. But now it is fundamentally compromising its own principles in the name of maintaining industry relevance.
- Or, the W3C is merely an industry body for browser vendors to collaborate and its mission statement is nothing more than PR to increase buy-in from the smaller, largely powerless, members.
Both can’t be true. Neither is good news for the organisation.
Much as I respect Tim Berners-Lee, his logic here is completely flawed. First of all, treating DRM as though it’s an implacable force of nature is a category error. Secondly, EME doesn’t in any provide a standardised solution: it provides a sandbox for each DRM vendor to inject their own proprietary solution.
Really good advice for anyone thinking of releasing a polyfill into the world.
This document provides Best Practices related to the publication and usage of data on the Web designed to help support a self-sustaining ecosystem. Data should be discoverable and understandable by humans and machines.
The security research that went into improving the spec for the Battery Status API. This is why it’s so important that the web holds itself to high standard.
Even most unlikely mechanisms bring unexpected consequences from privacy point of views. That’s why it is necessary to analyze new features, standards, designs, architectures - and products with a privacy angle. This careful process will yield results, decrease the number of issues, abuses and unwelcome surprizes.
A complete list of HTML elements, past and present. They’re all hyperlinked to the relevant specs.
Written in 2001, this history of the web takes in CERN, hypertext, the ARPANET, SGML, and lots more.
I just noticed that I’m mentioned in the acknowledgements of this most handy of W3C documents. This pleases me disproportionately.
Paul Ford’s potted history of web standards, delivered in his own inimitable style.
Reading through the standards, which are dry as can be, you might imagine that standardization is a polite, almost academic process, where wonks calmly debate topics like semicolon placement. This is not the case.
A cute videolette on web standards.