It’s all very admirable, but it also feels a little bit 927.
Rachel uncovers a great phrase for dealing with older browsers:
It isn’t your fault, but it is your problem.
She points to multiple ways of using CSS Grid today while still providing a decent experience for older browsers.
Crucially, there’s one message that hasn’t changed in fifteen years:
Websites do not need to look the same in every browser.
It’s crazy that there are still designers and developers who haven’t internalised this. And before anyone starts claiming that the problem is with the clients and the bosses, Rachel has plenty of advice for talking with them too.
Your job is to learn about new things, and advise your client or your boss in the best way to achieve their business goals through your use of the available technology. You can only do that if you have learned about the new things. You can then advise them which compromises are worth making.
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.
This is an excellent proposal from Emil. If we can apply
display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:
The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But
display: contentsis not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.
Whaddya say, browser makers?
Bram hopes for a way to define aspect ratios natively in CSS. We can sort of manage it now, but all the solutions are pretty hacky.
How the IETF redefined the process of creating standards.
To some visionary pioneers, such as Ted Nelson, who had been developing a purist hypertext paradigm called Xanadu for decades, the browser represented an undesirably messy direction for the evolution of the Internet. To pragmatists, the browser represented important software evolving as it should: in a pluralistic way, embodying many contending ideas, through what the Internet Engineering Task Force (IETF) calls “rough consensus and running code.”
Analysing what the web is. It’s not the technology stack.
To count as being part of the web, your app or page must:
- Be linkable, and
- Allow any client to access it.
I think that’s a pretty good definition.
Mind you, I think this is a bit rich in an article published on The Verge:
The HTML web may be slow and annoying and processor intensive, but before we rush too fast into replacing it, let’s not lose what’s good about it.
Still, we can agree on this:
Preserving the web, or more specifically the open principles behind it, means protecting one of the few paths for innovation left in the modern tech world that doesn’t have a giant company acting as a gatekeeper.
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!
RSS isn’t dead, but it has metamorphosed into JSON.
I don’t know if syndication feeds have yet taken on their final form, but they’re the canonical example of 927ing.
Anyway, I’ve gone ahead and added some JSON feeds to adactio.com:
Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:
Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.
I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:
I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.
But we can all agree that the web is a wonderful thing:
Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.
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.
Håkon wrote his doctoral thesis on CSS …which is kinda like Einstein writing a thesis on relativity. There’s some fascinating historical insight into the creation of the standards we use today.
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%).
Here’s the panel I was on at the AMP conference. It was an honour and a pleasure to share the stage with Nicole, Sarah, Gina, and Mike.
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.
An alternative history of technology, emphasising curation over innovation:
We start to see the intangibles – the standards and ideologies that help to create and order technology systems, making them work at least most of the time. We start to see that technological change does not demand that we move fast and break things. Understanding the role that standards, ideologies, institutions – the non-thing aspects of technology – play, makes it possible to see how technological change actually happens, and who makes it happen.
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.
Jason revisits responsive images. On the whole, things are looking good when it comes to browser support, but he points out that
scrset’s precursor in CSS—
image-set seems to have dropped off the radar of most browser makers, which is a real shame.
Jake is absolutely spot-on here. There’s been a lot of excited talk about adding an
h element to HTML but it all seems to miss the question of why the currently-specced outline algorithm hasn’t been implemented.
This is a common mistake in standards discussion — a mistake I’ve made many times before. You cannot compare the current state of things, beholden to reality, with a utopian implementation of some currently non-existent thing.
If you’re proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn’t.
Jake rightly points out that the first step isn’t to propose a whole new element; it’s to ask “Why haven’t browsers implemented the outline for sectioned headings?”