Here’s a handy graph from Paul:
Powered by data from caniuse.com and StatCounter, this page indicates the percentage of users who have a browser that natively supports various web platform features.
Here’s a handy graph from Paul:
Powered by data from caniuse.com and StatCounter, this page indicates the percentage of users who have a browser that natively supports various web platform features.
This is what Nick Sherman has been banging on about for years, and now the time has come for variable fonts …as long as typographers, browser makers, and standards bodies get behind it.
More details on Ev’s blog.
It’s always, um …”interesting” when a mainstream publication covers a topic from the web’s bikeshed. In this case, it’s progressive web apps, and—apart from the sensationalist headline—it’s actually not that bad at all.
An in-depth look at the current Shadow DOM spec. It’s well-written but I don’t think this will really click with me until I start playing around with it for myself.
It’s good to see that the examples have some thought given to fallback content.
There’s also a corresponding tutorial on custom elements
A thorough explanation of
@supports from Jen, with plenty of smart strategies for using it in your CSS today.
I’m in a similar position to Remy:
But, like Remy, I’m interested in knowing what are the ideas and techniques embedded within large frameworks that will end up making their way into the web stack:
What I want to know is: what should I be taking away from React into my own continued evolution as a web developer?
There are some good responses in the comments.
Another dive into the archives of the www-talk mailing list. This time there are some gems about the origins of the
input element, triggered by the old
The ancestors of the Internet were kind enough to give us a communication standard which is free, transparent, and standardized. It would be a shame to see the tech communication landscape move further and further into the world of locked gardens and proprietary schemas.
Jake has written up the notes from the most recent gathering to discuss service workers. If you have any feedback on any of the proposed changes or additions to the spec, please add them. This proposal is the biggie:
We’re considering allowing the browser to run multiple concurrent instances of a service worker.
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.
Paul argues that the biggest problems for interoperability on the web don’t come from support (or lack of support) for entire features, but from the frustrating inconsistencies when features land in different browsers at different times with different implementations:
- Platform inconsistencies hurt us more than big feature differences, we should start to try and prioritize aligning the platform
- We need better tools to help us understand what the inconsistencies are and guidance on how to manage them
- Developers should raise more issues to keep browser vendors accountable when there are differences
From the ARPANET to the internet, this is a great history of the Domain Name System:
Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularly given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.
A wonderful deep dive into the history of styling languages before CSS. I love spelunking down these internet history potholes—fascinating stuff!
The slides from Aaron’s talk at OS Bridge in Portland, looking at the formats and protocols powering the indie web.
I agree with everything Andrew says here. Progressive web apps are great, but as long as Google heap praise on mobile-only solutions (like the Washington Post doorslam) and also encourage separate AMP sites, they’re doing a great disservice to the web.
More features arrive regularly to make this “one web” even better and easier to maintain. Service worker, streams, app manifests, payment request, to name a few. But adding these features one at a time to large, mature applications like WaPo or FT or Nikkei is a slow and painstaking process. That’s why it’s taking us a long time for us to tick off all these new features, and why it seems like madness to try and build the entire app several times over.
However, by creating the concept of PWAs and marketing them as they do, Google is encouraging publishers to ‘start again’. And they’re doing exactly the same thing with AMP.
The Working Draft podcast is usually in German, but this episode is in English. It was recorded in a casual way by a bunch of people soaking up the sun sitting outside the venue at Beyond Tellerrand. Initially that was PPK and Chris, but then I barged in half way through. Good fun …if you’re into nerdy discussions about browsers, standards, and the web. And the sound quality isn’t too bad, considering the circumstances under which this was recorded.
Remy looks at the closing gap between native and web. Things are looking pretty damn good for the web, with certain caveats:
The web is the long game. It will always make progress. Free access to both consumers and producers is a core principle. Security is also a core principle, and sometimes at the costs of ease to the developer (but if it were easy it wouldn’t be fun, right?).
That’s why there’ll always be some other technology that’s ahead of the web in terms of features, but those features give the web something to aim for:
Flash was the plugin that was ahead of the web for a long time, it was the only way to play video for heavens sake!
Whereas before we needed polyfills like PhoneGap (whose very reason for existing is to make itself obsolete), now with progressive web apps, we’re proving the philosophy behind PhoneGap:
If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.
A really interesting proposal for more logic constructs in CSS: when/else conditions. At first glance, this looks like it would complicate the language (and one of the most powerful features of CSS is its simplicity), but when you dig a bit deeper you realise that there’s nothing new enabled by this extra syntax—it actually simplifies what’s already possible.
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.
Ted has snuck a blog post out from behind Apple’s wall of silence, and it’s good news: WebKit is not going to use vendor prefixes for new features.
I particularly like Ethan’s Stop Making Sense era David Byrne suit.
If you want to keep up to date with all the coolest stuff landing in CSS, I recommend bookmarking this ever-changing page.
A trip down memory lane with Håkon.
It’s not like the web has been done. This is history in the making. The web is only 25 years old. It’s going to be around for a long time, so there are lots of things to develop.
While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.
Rachel compares two CSS layout modules; Grid and Flexbox. This distinction is crucial:
Flexbox is essentially for laying out items in a single dimension – in a row OR a column. Grid is for layout of items in two dimensions – rows AND columns.
Markdown gets its own media type: text/markdown.
This is a really good primer on all the pieces that make up the Houdini approach to CSS—giving authors access to low-level APIs for rendering.
As is often repeated here, it’s still early days and caution is advised, but it’s still a good idea to wrap your head around what’s coming down the standards pipe.
There’s even more specs in Houdini’s list of drafts, but the future of those is rather uncertain and they are not much more than a placeholder for an idea at this point. Examples include custom overflow behaviors, CSS syntax extension API, extension of native scroll behavior and similar ambitious things that allow you to screw up your web app even worse than ever before. Rejoice!
Microsoft are officially on board with implementing Service Workers in Edge:
Roadmap Priority: High — We intend to begin development soon.
The proxy browser Opera Mini is one of the most popular mobile browsers in the world, and rightly so. Ire Aderinokun has put together a handy collection—based on caniuse.com data—of all the features that are unavailable or only partially available in that browser. The point here is not to avoid using these features, but to make sure you’ve got a solid fallback in place:
This isn’t about bashing the problem, but figuring out the solution.
I really, really want to like this article—it’s chock full of confirmation bias for me. But it’s so badly-written …I mean like, just the worst.
Here’s an actual sentence:
So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.
So, yeah, I’m still linking to it, but instead of it being for the content, it’s because I want to lament the dreadful state of technology writing.
Written in 2001, this history of the web takes in CERN, hypertext, the ARPANET, SGML, and lots more.
It would be convenient to think that because we live in a world where people’s browsers are regularly updating, that we live in a world where the web is in a reliable state.
The web is a continually moving target. It probably changed in the time it took me to write this. If you work with web stuff you need to embrace this fact. It will be the only constant in your career.
Do not panic:
On the web progressive enhancement is and will always be, the methodology of choice. It makes your site robust to the shifting sands of the web front end.
Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.
Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.
Visit this site using different browsers on different devices to get a feel for what you can do with web technologies.
Native will always be ahead, but the feature gap is closing impressively fast.
A new presentation from the wonderfully curmudgeonly Steven Pemberton, the Nosferatu of the web. Ignore the clickbaity title.
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.
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
Rachel outlines the history of the CSS Grid Layout spec so far:
The process works, as slow as it may seem to us who wait anxiously to be able to take advantage of these techniques. I am happy that we are waiting for something that I really believe has the ability to completely change how we do layout on the web.
Ben and Erin are shipping experimental support for AMP in the latest version of Known, but Ben has some concerns about the balance of power tilting towards one major player, in this case Google:
But it’s Google’s whitelist of approved ad providers that’s most concerning:
We’ve shipped support for AMP because we see potential here, and recognize that something should be done to improve the experience of loading independently-published content on the web. But attempting to bake certain businesses into a web standard is a malformed idea that is doomed to fail. If this is not corrected in future versions of the specification, we will withdraw support.
The sad history of
I wish I could share in the closing optimism:
Now imagine the future where Web Components are supported natively, and someone else is allowed to write a <better-input>, an element that is a real, encapsulated DOM element, and not just a div soup. Imagine using this <better-input> that isn’t implemented differently in each browser, that looks the same everywhere, and that probably also knows how to bake you a cherry pie.
But I all I can think is:
Now imagine the future where Web Components are supported natively, and everyone is allowed to write a million variations of <my-idea-of-a-better-input>, an element that is an inaccessible div soup under the hood.
An alternate version of AMP HTML that works in more parsers and user agents.
The AMP project have “A new approach to web performance” making your website dependent on Google. The Be Nice AMP Project follow the old approach: Make your site fast following best practice guidelines and be independent of Google.
We need the Internet of Things to be the next step in the series that began with the general purpose PC and continued with the Internet and general purpose protocols—systems that support personal autonomy and choice. The coming Internet of Things envisions computing devices that will intermediate every aspect of our lives. I strongly believe that this will only provide the envisioned benefits or even be tolerable if we build an Internet of Things rather than a CompuServe of Things.
Here’s a classic. David Siegel—of Creating Killer Websites fame—outlines exactly why he turned his back on that 1×1 spacer .gif trick he invented.
Alex recounts the sordid history of vendor prefixes and looks to new ways of allowing browsers to ship experimental features without causing long-term harm.
A wonderful, wonderful history of the web from Dave at this year’s Beyond Tellerrand conference. I didn’t get to see this at the time—I was already on the way back home—so I got Dave to give me the gist of it over lunch. He undersold it. This is a fascinating story, wonderfully told.
So gather round the computer, kids, and listen to Uncle Dave tell you about times gone by.
This is a deep, deep dive into responsive images and I can only follow about half of it, but there are some really useful suggestions in here (I particularly like the ideas for swapping out images for print).
An in-depth look at where web components stand today, together with some very good questions about where they might be heading tomorrow.
I really like this impassioned love letter to the web. This resonates:
The web is a worthy monument for society. It cannot be taken away by apps in the app store or link bait on Facebook, but it can be lost if we don’t continue to steward this creation of ours. The web is a garden that needs constant tending to thrive. And in the true fashion of the world wide web, this is no task for one person or entity. It will require vigilance and work from us all.
I really like Alex’s framing of best-of-breed progressively enhanced websites as “progressive apps” (although Bruce has some other ideas about the naming).
It’s a shame that the add-to-homescreen part isn’t standardised yet though.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
Charlotte has experimenting with a nice discrete bit of flexbox on her personal site. Here she documents what she did, and what the fallback is.
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.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
Paul Kinlan writes an honest post-mortem of his push for Web Intents.
There are some valuable lessons here, particularly for the indie web’s web actions.
Everyone who calls for WebKit in Internet Explorer is exactly the same kind of developer who would have coded to Internet Explorer 15 years ago (and probably happily displayed the best viewed in badge).
It’s happening again, and every petulant, lazy developer who calls for a WebKit-only world is responsible.
First, the browsers competed on having proprietary crap. Then, the browsers competed on standards support. Now, finally, the browsers are competing on what they can offer their users.
There are some good points here comparing HTTP2 and SPDY, but I’m mostly linking to this because of the three wonderful opening paragraphs:
A very long time ago —in 1989 —Ronald Reagan was president, albeit only for the final 19½ days of his term. And before 1989 was over Taylor Swift had been born, and Andrei Sakharov and Samuel Beckett had died.
In the long run, the most memorable event of 1989 will probably be that Tim Berners-Lee hacked up the HTTP protocol and named the result the “World Wide Web.” (One remarkable property of this name is that the abbreviation “WWW” has twice as many syllables and takes longer to pronounce.)
Tim’s HTTP protocol ran on 10Mbit/s, Ethernet, and coax cables, and his computer was a NeXT Cube with a 25-MHz clock frequency. Twenty-six years later, my laptop CPU is a hundred times faster and has a thousand times as much RAM as Tim’s machine had, but the HTTP protocol is still the same.
I just noticed that I’m mentioned in the acknowledgements of this most handy of W3C documents. This pleases me disproportionately.
Like caniuse.com, but for typography features. Find out what’s supported in browsers today.
A history lesson and a love letter to the early web, taking in HTML, Photoshop, and the web standards movement.
Those were long years, the years of drop-shadows. Everything was jumping just slightly off the screen. For a stretch it seemed that drop-shadows and thin vertical columns of text would define the web. That was before we learned that the web is really a medium to display slideshows, as many slideshows as possible, with banner ads.
Stuart has implemented webmentions on his site, which is great. It’s also fitting, as he is the inventor of pingback (of which webmention is a simpler reformulation).
This strikes me as an eminently sensible idea by Emil: using the picture element to begin providing WebP alternatives to JPG.
Of course, picture-supporting browsers will have to adjust their decision-making algorithm to support this pattern.
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.
I’m an advocate for progressive enhancement. Tom Dale is not. But even though we may disagree on that, there’s a lot to like in his sensible, balanced answers to some sensationalist linkbaity questions.
It’s not that the pace of innovation on the Web is slower, it’s just solving a problem that is an order of magnitude more challenging than how to build and distribute trusted apps for a single platform. As we saw on the desktop, it may take a few years to catch up to all of the capabilities of a native, proprietary platform, but in terms of the impact it will have on humanity, forgive me for not losing sleep if we have to wait a few years for it to arrive.
A cute videolette on web standards.
Netflix are going full 927 on TLS.
This is hilarious …for about two dozen people.
For everyone else, it’s as opaque as the rest of the standardisation process.
Tantek shares a fascinating history lesson from Tim Berners-Lee on how the IETF had him change his original nomenclature of UDI—Universal Document Identifier—to what we now use today: URL—Uniform Resource Locator.
HTML5 is now a W3C recommendation. Here’s what a bunch of people—myself included—have to say about that.
My name is Jeremy and I am a boring front-end developer.
This is what Scott Jenson has been working on—a first stab at just-in-time interactions by having physical devices broadcasting URLs.
Walk up and use anything
I share the concerns expressed here about the “sizes” attribute that’s part of the new turbo-powered img element (or “the picture element and its associates”, if you prefer). Putting style or layout information into HTML smells bad.
This is a concern that Matt Wilcox has raised:
Change the design and those breakpoints are likely to be wrong. So you’ll need to change all of the client-side mark-up that references images.
I can give you a current use-case: right here on adactio.com, you can change the stylesheet …so I can’t embed breakpoints or sizes into my img elements because—quite rightly—there’s a separation between the structural HTML layer and the presentational CSS layer.
Following on from that post of Jason’s I linked to, Chris also emphasises that, for most use cases, you probably only need to use srcset (and maybe sizes), but not the picture element with explicit sources.
It’s really, really great that people are writing about this, because it can be quite a confusing topic to wrap your head around at first.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
Jason points out that the picture element might not be needed for most responsive image use cases; the srcset and sizes attributes will probably be enough—that’s what I’m doing for the photos on my site.
Soledad Penadés also went to the Extensible Web Summit in Berlin, where she gave a lightning talk. Sounds like it was really good.
This also includes some good advice that, again, Alex might want to consider before denouncing any disagreement on Web Components as “piffle and tosh”:
If the W3C, or any other standardisation organisation wants to attract “normal” developers to get more diverse inputs, they/we should start by being respectful to everyone. Don’t try to show everyone how superclever you are. Don’t be a jerk. Don’t scare people away, because then only the loud ones stay, and the quieter shy people, or people who have more urgent matters to attend (such as, you know, having a working business website even if it’s not using the latest and greatest API) will just leave.
Bruce went to the Extensible Web Summit in Berlin and wrote up his notes.
Sounds like he shares my excitement, but also my nervousness.
There’s also this important point, that Alex would do well to remember before crying “Piffle and tosh!”:
We need to ensure that all devs who want to can participate by allowing ease of collaboration, courteous discourse.
A really nice little documentary about my friend Jeffrey.
The Web Manifest spec is still very much in draft, but it’s worth reading through Bruce’s explanation of it now. Basically, it will provide a way for us to specify in one external file what we currently have to specify in umpteen meta tags and link elements.
One more reason why you should never sniff user-agent strings: Internet Explorer is going to lie some more. Can’t really blame them though—if developers didn’t insist on making spurious conclusions based on information in the user-agent string, then browsers wouldn’t have to lie.
Oh, and Internet Explorer is going to parse -webkit prefixed styles. Again, if developers hadn’t abused vendor prefixes, we wouldn’t be in this mess.
Here’s a dystopian vision of the web in ten years time, where professional developers are the only people able to publish on the web.
This (literally) charts the evolution of HTML, tracking which elements have been added and which have been removed.
Some good ideas from Matt on the importance of striving to maintain digital works. I find it very encouraging to see other people writing about this, especially when it’s this thoughtful.
Here’s the chat I had with Jen and Doug about the prospect of DRM in browsers.
I really hope that this is the kind of usage we’ll see for web components: enhancements for the browsers that support them without a good ol’ fashioned fallback for older browsers.
Right now, this move to remove URLs from the interface of Chrome is just an experiment …but the fact that Google are even experimenting with it is very disturbing.
“Who? Me? No, I was never going to actually blow the web’s brains out—I just wanted to feel the heft of the weapon as I stroked it against the face of the web.”
I think I concur with this list. Although I guess it’s worth remembering that, given the size of the CSS spec, this isn’t an overly-long list.
It’s interesting that quite a few of them are about how things are named. It’s almost as if that’s one of the, say, two hardest things in computer science.
Derek’s excellent advice on avoiding over-reliance on data attributes has this brilliant nugget of insight:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works
Funny because it’s true:
The thing I regret the most is how my class addiction affected my relationship with HTML.
Bruce’s thoughts on ensuring accessibility in Web Components. He thinks that the vocabulary of ARIA is up to the job, so that’s good enough for me.
A healthy dose of scepticism about Web Components, looking at them through the lenses of accessibility, security, and performance.
I share some of this concern: Web Components might look like handy ready-made out-of-the-box solutions, but the truth is that web developers have to do much more of the hard graft that was traditionally left to the browser.
The importance of long-term thinking in web design. I love this description of the web:
a truly fluid, chaotic design medium serving millions of imperfect clients
Some good ideas on the idea of element-level media queries, a feature that developers are crying out for and browser makers are saying is too hard. This post has some thoughts on how to deal with the potential issues.
A lovely history lesson on CSS from John.
This looks interesting: a CSS postprocessor that polyfills support for perfectly cromulent styles.
John shares his concerns about the increasing complexity involved in developing for the web.
Some excellent practical advice on progressive enhancement.
A nice bit of markup archeology, tracing the early development of HTML from its unspecced roots to the first drafts.
I recognise some of the extinct elements from the line-mode browser hack days at CERN e.g. HP1, HP2, ISINDEX, etc.
A fascinating snapshot from 1995, arguing for the growing power of HTML instead of the siren song of proprietary formats.
I’m very happy that this is still available to read online 18 years later.
The authors of the Extensible Web Manifesto explain the thinking behind their …uh… thinking.
Alex starts with a bit of a rant about the phrase “semantic HTML”, which should really just be “well-written HTML, but there then follows some excellent thoughts on the emergence of meaning and the process of standardising on vocabularies.
A love letter to HTML, prompted by the line-mode browser hack event at CERN.
Henri gives an overview of the DRM-style encryption proposed for HTML. It’s a very balanced unbiased description, but if you have the slightest concern about security, sentences like this should give you the heebie-jeebies:
Once you get past the cheesy intro music, there are some gems from Robert Cailliau in here.
I took a little time out of the hacking here at CERN to answer a few questions about the line-mode browser project.
Go, Dan, go!
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.
The semantics of the cite element are up for discussion again. Bruce, like myself, still thinks that we should be allowed to mark up names with the cite element (as per HTML 4), and also that cite elements should be allowed inside blockquotes to indicate the source of the quote.
Let’s pave that cowpath.
WebKit nightlies now have support for
srcset. I’m pleased to see that it’s currently constrained to just handling the case of high-density displays; it doesn’t duplicate the media query functionality of
I’ve always maintained that the best solution to responsive images will be some combination of
picture: they each have their strengths and weaknesses. The “art direction” use case is better handled by
picture, but the “retina” use case is better handled by
A terrific lighting talk by Scott on the need to think bigger. The solution to long-term issues is rarely “start a company”—we need to think more about creating a shared infrastructure …just like the internet.
A great call-to-arms from Tim, simply asking that we create websites that take advantage of the amazing universality of the web:
The web has the power to go anywhere—any network, any device, any browser. Why not take advantage of that?
Inevitably there is pushback in the comments from developers still in the “denial” stage of coming to terms with what the web is.
A call for developers to let standards bodies know what we want:
It is important that we as developers focus on the right things again. If you encounter a bug, you should not only fix it for your site; you should reach out to browser vendors and web standards people to fix this in a long-term solution. It might cost you a few minutes, but brings a lot of improvement to the whole developer community.
This a great proposal: well-researched and explained, it tackles the tricky subject of balancing security and access to native APIs.
Far too many ideas around installable websites focus on imitating native behaviour in a cargo-cult kind of way, whereas this acknowledges addressability (with URLs) as a killer feature of the web …a beautiful baby that we definitely don’t want to throw out with the bathwater.
A superb piece by Marco Arment prompted by the closing of Google Reader. He nails the power of RSS:
RSS represents the antithesis of this new world: it’s completely open, decentralized, and owned by nobody, just like the web itself. It allows anyone, large or small, to build something new and disrupt anyone else they’d like because nobody has to fly six salespeople out first to work out a partnership with anyone else’s salespeople.
And he’s absolutely on the money when he describes what changed:
RSS, semantic markup, microformats, and open APIs all enable interoperability, but the big players don’t want that — they want to lock you in, shut out competitors, and make a service so proprietary that even if you could get your data out, it would be either useless (no alternatives to import into) or cripplingly lonely (empty social networks).
I share his anger.
Well, fuck them, and fuck that.
The closing hot topics panel I moderated at this year’s Mobilism conference in Amsterdam, featuring Remy, Wilto, Jake, and Dan.
A great history lesson from Dave.
Ah, I remember when the CSS Zen Garden was all fields. Now get off my CSS lawn.
The battle between web fonts and performance. Ian Feather outlines some possible solutions, but of course, as always, the answer is “it depends”.
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.
Google’s track record is not looking good. There seems to be a modus operandi of bait-and-switch: start with open technologies (XMPP, CalDav, RSS) and then once they’ve amassed a big enough user base, ditch the standards.
This echoes what Scott Jenson has been saying: the current trend with connected devices is far too reliant on individual proprietary silos instead of communicating with open standards.
So instead of talking directly to one another, devices on today’s nascent Internet of Things now communicate primarily with centralized servers controlled by a related developer or vendor. That works, after a fashion, but it also leads to a bunch of balkanized subnetworks in which devices can communicate perfectly well with each other - but can’t actually talk to devices on any other balkanized subnetwork.
My presentation from the Industry conference in Newcastle a little while back, when I stepped in for John Allsopp to deliver the closing talk.
An intriguing initiative to tighten up the loop between standards development and implementation.
A terrific quiz about browser performance from Jake. I had the pleasure of watching him present this in a bar in Amsterdam—he was like a circus carny hoodwinking the assembled geeks.
I guarantee you won’t get all of this right, and that’s a good thing: you’ll learn something. If you do get them all right, either you are Jake or you are very, very sad.
A great post by Stuart on the prospect of DRM-by-any-other-name in HTML.
The argument has been made that if the web doesn’t embrace this stuff, people won’t stop watching videos: they’ll just go somewhere other than the web to get them, and that is a correct argument. But what is the point in bringing people to the web to watch their videos, if in order to do so the web becomes platform-specific and unopen and balkanised?
Jake casts a scrutinising eye over the way that browsers load and parse scripts …and looks at what we can do about it.
I need to get Matt to an Indie Web Camp.
A fascinating look at the history of cookies …from the inventor of cookies.
The litany of open standards that Google has been abandoning: RSS, XMPP, WebDav…
I’m in general agreement with this rousing defence of CSS. I think it does a pretty great job of balancing a whole ton of use cases.
Wow! The CSS Zen Garden is a decade old. Crazy! It’s a true piece of web history …and it’s back!
Scott points out a really big problem with the current state of the “internet of things”: everyone is inventing their own proprietary walled-garden infrastructure instead of getting together to collaborate on standards.
The single biggest fallacy I want to blow up is this utopian idea that there is this SINGLE thing called ‘The Cloud’. Each company today reinvents their own cloud. The Cloud as a concept is dead and has been for years: we are living within a stormy sky of cranky clouds, all trying to pretend the others don’t exist.
A terrific piece by Remy—based on a talk he gave—on when he uses jQuery and, more importantly, when he doesn’t. His experiences and conclusions pretty much mirror my own, but of course Remy is far more thoughtful and smart than I.
Really good stuff.
A good history lesson in rendering engines: KHTML, WebKit, and now, Blink.
This is wonderful stuff! I’m a big fan of the
datalist element but I hadn’t realised how it could be combined with
input types like
I like these design principles for server-side and client-side frameworks. I would say that they’re common sense but looking at many popular frameworks, this sense isn’t as common as it should be.
Brent Simmons pens a love-letter to RSS, a technology that you use every day, whether you realise it or not.
Tantek steps back and offers some practical approaches to reclaiming a more open web from the increasingly tight clutches of the big dominant roach motels.
Notice that he wrote this on his own domain, not on Branch, Medium, Google+, Facebook, or any other black hole.
This issue of A List Apart is a great double-whammy. Lara Swanson has a ton of practical tips for front-end performance enhancements, and Brian dives deep into making your own icon fonts.
An excellent explanation from Tom Loosemore on why the Government Digital Service is putting its energy into open standards and the web, rather than proprietary native apps.
The “client hints” proposal looks really interesting: a way for user-agents to send data to the server without requiring the server to have a library of user-agent strings. But Scott has a few concerns about some of the details.
The WaSP is closing its doors. It has been a privilege and an honour to serve with such a fine organisation.
A very hand tip from Ben on using SVG background images with a PNG fallback for IE8 and below.
I like the sound of the book that Chris is writing for Smashing Magazine. It sounds like a very future-friendly approach to front-end development.
Related to my rant on links that aren’t actually links: buttons that aren’t actually buttons.
You’re probably doing each of these already but just in case your’e not, Andy has listed six quick wins you can get from HTML5.
Bruce takes a look at the tricky issue of styling native form controls. Help us, Shadow DOM, you’re our only hope!
A good explanation of the litany of woes that comes from Internet Explorer 8 being the highest that users of Windows XP can upgrade to. It’s a particularly woeful situation if you are a web developer attempting to provide parity. But there is hope on the horizon:
2013 will see the culmination of all these issues; support for IE 8 will drop of rapidly, users of XP will find an increasingly broken web, the cost of building software in XP organisations will increase.
A good explanation of HTML5’s sectioning content and outline algorithm.
This off-canvas demo is a great practical example of progressive enhancement from David. It’s also a lesson in why over-reliance on jQuery can sometimes be problematic.
Bruce sits down for a chat with Hixie. This is a good insight into the past and present process behind HTML.
Here’s a treasure trove of web history: an archive of the www-talk list dating back to 1991. Watch as HTML gets hammered out by a small group of early implementors: Tim Berners-Lee, Dave Raggett, Marc Andreessen, Dan Connolly…
I love that Tantek is as pedantic as I am …although I don’t think “pedantic” is exactly the right word.
A well-reasoned argument for tackling image optimisation on the server, using content-type negotiation.
The slides and audio from Andy’s exceptional talk earlier this year at Southby, combined into one video.
It really is excellent, although he does make the mistake of pulling the “dogma” card on those who woud disagree with him, and he really doesn’t need to: his argument is strong enough to stand on its own.
Tantek has put together a wiki page to document the arguments for and against adding a new “main” element to HTML.
This echoes Scott Jenson’s call for more open standards when it comes to networked devices. We’ll need it if we want “If This, Then That” for an internet of things.
Man, I just love Scott Jenson.
Our brains have collectively gone startup-crazy, seeing the world through stock option colored glasses, assuming that if there is no money, there is clearly no value. This is madness. I’m so desperately worried that the internet will turn out to be a happy accident.
Turning his focus on “the internet of things” he makes the very good point that what we need isn’t one company or one proprietary service; we need an ecosystem of open standards that will enable companies to build services.
We all have to appreciate how we need a deep, open solution to solve this problem. If we don’t understand, demand even, that hardware devices need to be just as discoverable an open as web servers are today, we’ll never see the internet of things come to pass.
Steven Wittens, who gave a terrific talk all about maths at last week’s Full Frontal conference, describes his experience at that most excellent event.
Andrea looks at support for HTML5 input types in IE10 Mobile.
A worrying look at how modern web developers approach accessibility. In short, they don’t.
Useful advice from Tim on preparing your responsive site for IE10’s new “snap mode”. Don’t worry: it doesn’t involve adding any proprietary crap …quite the opposite, in fact.
This is an excellent resource from Anna. She’s documenting the browser capabilities of games consoles.
A one-stop-shop for browser-compatibility information. This is MDN, HTML5 Rocks, and Quirksmode all rolled into one.
A lovely bit of hypertext.
Bruce’s thoughts on the proposed inclusion of a “content” or “maincontent” element in HTML5.
Personally, I don’t think there’s much point in adding a new element when there’s an existing attribute (role=”main”) that does exactly the same thing.
Also, I don’t see much point in adding an element that can only be used once and only once in a document. However, if a “content” or “maincontent” element could be used inside any sectioning content (section, article, nav, aside), then I could see it being far more useful.
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.
How about this for a trip down memory lane—a compendium of articles from over a decade of A List Apart, also available as a Readlist epub. It’s quite amazing just how good this free resource is.
The only thing to fault is that, due to some kind of clerical error, one of my articles has somehow found its way onto this list.
If this were Twitter, you’d be at-replying me with the hashtag “humblebrag”, wouldn’t you?
Nicholas is inside my head! Get out of my head, Nicholas!
What makes the web beautiful is precisely that there are multiple browsers and, if you build things correctly, your sites and applications work in them all. They might not necessarily work exactly the same in them all, but they should still be able to work. There is absolutely nothing preventing you from using new features in your web applications, that’s what progressive enhancement is all about.
This is a well-reasoned, thoughtful article on avoiding class names in CSS …but I don’t agree with it. That said, perhaps there’s a reasonable middle ground to be found between this extreme stance and the opposite (but in some ways just as extreme) stance of OOCSS.
Wilto does an excellent job of summarising the current state of responsive images, highlighting Florian Rivoal’s compromise proposal that combines the best of the picture element with the best of srcset.
A nice round-up of the issues around responsive images and their potential solutions.
Like the Web Standards Project but for ePub. I approve of this message.
Jason outlines the real challenge to every proposed solution for responsive images: they just don’t jibe with the way that browsers (quite rightly) pre-fetch images.
Bravo, Bruce, bravo.
I heard Glen Campbell’s “Like A Rhinestone Cowboy” on the radio and began absent-mindedly singing “Like a rounded corner” to it.
A well thought-out evaluation on responsive images from Bridget.
Have you thought “There must be a good reason for the blink element.” Well, read on.
The video of the panel I moderated on device and network APIs on the second day of Mobilism in Amsterdam. It’s not quite as snappy as the browser panel (which, given the subject matter, is unsurprising) but it was still good fun.
This seems like a sensible way for browsers to approach implementing vendor-prefixed CSS properties.
Wilto gives a thorough explanation of the state of things with responsive images, particularly the work being done at the Responsive Images Community Group at the W3C.
An oldie but a goodie: Clay Shirky looks at the design principles underlying HTML in order to figure out what made it so successful. Even though this is fourteen years old, there are plenty of still-relevant insights here.
A great talk by Nicholas on what progressive enhancement means today. There’s some good ammunition in here.
Mozilla will be supporting H.264 …but they’re not happy about it.
I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance.
Chris defends himself from some inaccuracies I flung his way, regarding fonts and DRM.
A great post that discusses exactly what we mean when we talk about “supporting” different browsers.
A look at the new pseudo-classes in CSS3 that go hand-in-hand with the form enhancements introduced in HTML5.
Here’s a great braindump from Paul following the Responsive Summit, detailing multiple ways of potentially tackling the issue of responsive images.
The slides from Chris’s presentation on the known unknowns of the web.
There’s a W3C community group now for looking at the responsive images question.
A really handy test site from Lea that reports your browser’s recognition of CSS properties.
Paul quite rightly sings the praises of box-sizing: border-box — this is something that Microsoft got right and the spec got wrong. I never thought of making it part of a universal reset though.
A very useful site for checking browser support for CSS features. The test cases are really handy and the site gets extra bonus points for not calling itself “HTML5” anything.
Some valuable musings from Ben on how browsers could be better — and I don’t mean the usual moaning about performance or device APIs.
This is really handy: a bookmarklet that will disable any CSS3 on a page so you can check that your fallbacks look okay.
Joni points out a great advantage to the mobile-first approach if you choose not to polyfill for legacy versions of IE: you can go crazy with all sorts of CSS3 goodies in the stylesheet you pull in with media queries.
An in-depth look at browser polyfills: what they are, how they work, and how you can make your own.
Put this one on speed dial.
A call-to-arms for web developers combined with a handy list of projects you can get involved in.
Alex weighs in on the newly-reopened debate on vendor prefixes, roundly squashing Henri’s concerns.
Luke points out that the web is everywhere: it’s accessible through the browser but also through many native applications. This is the real Web Operating System.
The Web (browser) is inside of every application instead of every application being inside the Web (browser).
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 is a very thoughtful piece by Henri on vendor prefixes and it’s well worth a read …however the thought of one browser implementing support for vendor-prefixed properties intended for a different browser does make me quite quesy.
This is a great response to my recent post about semantics in HTML. Steve explores the accessibility implications. I heartily concur with his rallying cry at the end:
A very even-handed look at the time and data debacle in HTML5.
A single-serving website expressing the frustration and bewilderment at Hixie’s unilateral decision to drop the time element from HTML.
David gives a quick rundown of some of the selectors we can expect to see in CSS4.
This is a great encapsulation of what I’ve been banging on about at conferences for a while now: let’s stop pretending we know the capabilities, network speed or viewport size of a site visitor’s browser.
This encapsulates the difference between the WHATWG and the W3C: a concern for interoperability matched against a concern for procedure.
Given some recent hand-wringing about the web as a “platform,” it seems appropriate to revisit this superb article from Ben. The specifics of the companies and technologies may have changed in the past year but the fundamental point remains the same:
Everything about web architecture; HTTP, HTML, CSS, is designed to serve and render content, but most importantly the web is formed where all of that content is linked together. That is what makes it amazing, and that is what defines it. This purpose and killer application of the web is not even comparable to the application frameworks of any particular operating system.
Jonathan has encapsulated his CSS methodology into a short online book. He isn’t presenting this as the “right” way to do things: he’s simply documenting what he does in the hope that it will help others.
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.
It’s Opera …but it’s folk.
This just launched at the Breaking Development conference: another site that uses the term HTML5 to include CSS and Ajax. Still, despite its inaccurate nomenclature, it’s a useful compatibility table of device support in mobile browsers.
A great opinion piece from Addy Osmani prompted by the panel discussion I took part in at the Update conference.
This abuse of the !important declaration in Firefox’s user-agent stylesheet was driving me crazy recently. Roger proposes a CSS patch, but this is really something that needs to be fixed in the browser.
Once again I’m getting all my CSS3 information from Jonathan. This time he’s discovered the vw and vh units which allow you to specify sizes relative to the size of the viewport.
Jake’s talk at DIBI earlier this year was absolutely fantastic. It features a rape reference, a story about pissing, and a Human Centipede metaphor.
It’s also very, very informative. Watch this.
A valiant attempt to polyfill support for hyphenation in browsers other than the latest Safari and Firefox.
Insanely in-depth look at how browsers work, right down to the nitty gritty. You’d think there’d be a lot of engineering talk, but actually a lot of it is more about linguistics and language parsing.
A brave attempt to explain the new outline algorithm in HTML (although it inaccurately states that no browsers have support for it—Firefox shipped with it a while back).
You can safely skip the comments: most of them are discouraging, ignorant, and frankly, just plain stupid.
There are some inaccuracies and misrepresentations in here, but on the whole this is a pretty good round-up of your options when dealing with responsive design in older browsers.
Some great, considered thoughts from Mark on how CSS Grid Layout could work as part of a larger tradition in design.
A really nice little primer on getting started with HTML5.
A great reminder from Bruce that we need to remember to use cutting-edge web technology responsibly.
A great round-up by Richard of some of the most common semantic pitfalls encountered with HTML5.
Everything you ever needed to know about adding HTML5 audio and video to your site, courtesy of the mighty John Allsopp.
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.
So true, it hurts.
I agree with Oli’s conclusion:
This is an excellent idea from Andy: selector queries. Like media queries but at the component level. Quite often it isn’t the width of the viewport that matters, it’s the width of the containing element for whatever you’re trying to style.
Mike takes on the very tricky task of explaining the new outline algorithm—definitely one of the hardest features of HTML5 to explain, in my opinion.
I’m getting behind Oli’s proposal to allow non-quoted footers within blockquotes in HTML. Here’s where I quote the design principles to support his case.
Now this is how you make progress on getting changes made to a spec: by documenting real-world use cases.
This dovetails nicely with my recent post about the spirit of distributed collaboration. Here’s a great little bit of near-history spelunking from Paul, all about styling new HTML5 elements in pesky older versions of Internet Explorer.
Here’s a video of the mobile browser panel I moderated at Mobilism in Amsterdam today. It gets fairly technical for a while but it was mostly a lot of fun.
A good round-up by Jack Osborne of where things currently stand with the hgroup group.
Well, ya learn something new every day …or at least I did. I had no idea about the rem unit—relative em—for font-sizing in CSS.
Ben Buchanan has a nice round-up of some of the options available when you’re switching over to HTML5.
A quick chat with me in the hallway after my talk in Seattle.
An excellent zero-edit counter-proposal from Anne detailing why version numbers are unnecessary and undesirable for HTML.
A beautifully readable subset of the HTML spec, with an emphasis on writing web apps (and with information intended for browser makers has been removed). Very handy indeed!
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.
The spec previously known as HTML5 is now simply HTML. Good. The W3C are now free to abuse the term “HTML5” to mean everything under the sun.
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.
Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as “a hammer.”
PPK on the circle of life when it comes to online technology advances; innovation happens fast in proprietary platforms, but the good stuff ends up being natively supported in browsers. It’s a pretty good ecosystem, all in all.
Documenting the use and abuse of fragment identifiers.
A great little jQuery script to automatically assign ARIA roles to HTML5 elements with the corresponding semantics.
An oldie but a goodie. This is why we have standards.
A one-stop link shop for resources on web standards.
Bobbie is publishing the interviews he conducted with various HTML5 bods when he was researching his Technology Review article. First up: Hixie.
A delightful online book that makes excellent use of HTML5's history API.
An inspiring State Of The Web address by Tim Berners-Lee. He can't resist pitching linked data at the end, but it's mostly a stirring call to arms.
A quick run-through of some of the new HTML5 form features coming in Firefox 4.
All the tests and all the results, all in one place.
A great explanation of the responsive enhancement of this site.
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 handy table of new HTML5 elements and whether or not they are exposed to assistive technology.
I couldn't agree more with this rant from Remy. He took the words right out of my mouth.
A very handy page for showing HTML5 form element support in your browser.
Cute illustration of different content types in HTML (though, personally, I would put sectioning content — section, article, nav, aside — into their own group).
HTML5 resources, gathered together in one place.
A great post from the frontline of markup. This is just a taste of the confusion to come.
Another set of default HTML/CSS/JS templates with some very clever ideas built in (courtesy of the always-brilliant Paul Irish).
The latest Webkit nightly includes the HTML5 parsing algorithm. Now it's a race between Firefox, Safari and Chrome to see which will be first (non-beta) browser to ship with the new parser.
A great bit of research from Emily. She correctly values data more than opinion.
An interesting performance proposal from mozilla that will degrade nicely in legacy browsers.
An all-in-one validator from the W3C: markup, CSS and feed validation.
Frances takes issue with the hgroup element in HTML5.
Dan has an idea for a possible application of the HTML5 mark element in navigation lists.
An excellent argument in favour of vendor prefixes in CSS, from Eric.
Just in case you forget.
A new HTML5 resource from Paul Irish and other Googlers.
Science meets standards: NASA joins the W3C.
Tantek is working with Mozilla now. I expect great things will come of this.
Anne explains exactly why the HTML parser defined in HTML5 is A Very Good Thing for everyone.
Henri Sivonen gives the lowdown on the HTML5 parser that will ship with the next version of Firefox. This is a huge development ...and yet users won't even notice it (by design).
The origins of the blink element are fascinating. To nobody's surprise, alcohol was involved.
Finally! A lint tool for HTML (including HTML5) so you can enforce strictness in your writing style.
A very detailed set of coding standards and guidelines.
Blaine outlines the vision for Webfinger.
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).
A nice explanation of the ruby element in HTML5: very handy for marking up phonetic pronunciation.
A first bash at describing how to write (X)HTML5 documents that can be parsed as XML as well as HTML.
Microsoft, Mozilla and Opera have formally submitted the WOFF font format to the W3C.
Hixie needs your help. Document examples of augmented video (or audio) such as captioned or subtitled media.
This web conference in July in St. Petersburg, Florida looks great — the line-up is excellent and tickets cost just $99. Bargain!
Purely for my own benefit because I keep needing this URL, here are the current outstanding issues registered at the W3C for HTML5.
A lovely bit of CSS3.
A very handy GUI for figuring out the somewhat complicated syntax of border-image in CSS3.
An excellent piece by Bruce on why the details element needs to be in HTML5.
Mozilla aims to plug the :visited/getComputedStyle bug/feature.
A thoughtful piece by John Gruber on HTML5 video: yes, software patents are toxic to the web but perhaps H.264 isn't the worst offender.
PPK proposes a new buzzword for standards-based mobile development: HTML5 Apps. Definition: "an iPhone app that works on several other platforms, too, and doesn’t have to go through the app store approval process."
This is an interesting idea: paste in some markup and this will automatically generate CSS selectors based on your classes and IDs.
Hixie is proposing a new addition to HTML but separate from HTML5, "to enable video conferencing from HTML applications."
PPK offers a rebuttal to Paul Graham's attack on Apple's App Store policies by placing the blame firmly at the feet of developers who refuse to embrace web technologies.
A fascinating trip down memory lane to the birth of the IMG element.
The Web Magazine for Young Designers and Developers. Very nicely done, and all in HTML5 too.
A very handy interface for browsing the contents of the HTML5 spec.
It's not very often, I must confess, that I see a poem about CSS. You know a technology is in its prime when people start talking about it in rhyme.
An entertaining and accurate history of markup up to and including HTML5.
Getting font-linking to work in all browsers.
Ted explains what all those HTML5 documents for authors are about.
My buddies and I express our support for HTML5 ...with caveats ...and unicorns.
A thoughtful piece on the question of extensibility in HTML5.
Simon St. Laurent explains why mobile support for HTML5 mitigates Microsoft's dominance of desktop web browsing.
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.
Watch this space for Mark Pilgrim's dive excursions into HTML5.
Turning Japanese, I think I'm turning Japanese, I really think so.
My words have been given new life in comic form thanks to the very talented Brad Colbow.
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."
Remy's riposte to http://ishtml5readyyet.com/
Oli gives a nice hands-on tutorial on using the new structural elements in HTML 5.
I think Gareth is reading my mind. Get out my mind, Gareth!
The spectre of patents is hurting progress on the web.
A nice rundown of media queries and multiple columns in CSS3.
Answering your questions about HTML5.
Ben calls bullshit on Microsoft's defence of Outlook's rendering. Ben, as usual, is correct.
Announced at SXSW, this is the curriculum that the Web Standards Project has been working on. Education, education, education.
Bend over 'cause Microsoft is about to stick it to us standards-savvy developers. Again.
An excellent write-up by Bruce of a talk he gave at the Betavine birthday party. Down with .mobi! One Web FTW!
This addition to Firebug is rather excellent: a built in reference for whatever you're inspecting.
Gez lays out the case for and against keeping the alt attribute mandatory in HTML5. If he's missed anything, add a comment.
A superb article by Bryan Rieger on designing for multiple screen sizes. The closing section makes it clear that if you care about mobile, you'd better get comfortable with liquid layouts fast.
Bid farewell to IE6.
A guide to using ARIA roles from the mighty Steve Faulkner.
Cameron rounds up articles on HTML5 from 'round the web.
A document outlining browser support standards for bbc.co.uk
Chris has written an in-depth critique of the state of OpenID, focusing strongly on usability.
Here's a handy little trick from Paul: use conditional comments to add a class to your BODY element, allowing you to target IE without a separate stylesheet.
Håkon is not happy with the default settings in IE8. Deep in the preferences, "Display intranet sites in Compatibility View" is checked.
Here's a great project from Andrew Mager. He takes a little time out at lunch to post a small markup or CSS tip. Over time this builds up into a really valuable resource.
Opera have unveiled the Web Standards Curriculum. It's released under a CC attribution non-commercial share-alike license and it looks like a very valuable resource.
Scott Kveton rips Chris Saad a new one, and rightly so. We all sent Chris the same message at Social Graph Foo Camp, he's had enough time to shape up but instead things have become increasingly hype-laden and bullshitty with him.
The last piece is falling into place. IE8 has ARIA support, Mozilla has ARIA support ...and now WebKit is getting there. Excellent!
Gareth tries to figure out why Django seems to strike a chord with standardistas. It may that the separation of concerns resonates with the methodology of progressive enhancement. Some good comments follow
The WaSP kicks it up a notch. Putting bookmarks in books was just the beginning. Now you can tag bad developers with the web standards equivalent of the scarlet letter.
Live in San Diego? Interested in web standards? Come along tomorrow to the inaugural San Diego Web Standards Group meetup. You won't regret it.
Mark Pilgrim fisks Joel Spolsky. He's not greedy either: there's still plenty of straw men left in Spolsky's screed for the rest of us to skewer.
Here's the first initiative from the WaSP Street Team: labeling outdated webdev books in libraries as hazardous material.
Praise Jeebus! The IE team are doing the right thing regarding the default behaviour of version targeting in IE8. Thank you, thank you, thank you!
A nice analysis and skewering of Microsoft's proposed default behaviour for version targeting.
A superbly clear analysis of the proposed default version targeting behaviour in IE8+.
The madness of the default behaviour in IE8 explained in a beautiful koan.
The timeline behind Microsoft's latest announcement.... as told by stuffed lemurs.
Rachel adds her thoughts on Microsoft's broken implementation of version switching—and very good thoughts they are too.
Tantek talks about the importance of open media for the longevity of data.
A new version of Dean's IE7 script is available. Given my daily frustrations with IE6, I hope its marketshare declines enough that I can use this as a magic bullet in front-end development.
Great news from Redmond: IE8 passes the Acid2 test.
PPK points out a potentially dangerous aspect to Opera's actions, one that that the rest of us have missed: "Without consulting anybody, Opera is trying to give a political body the right to decide what does and what does not constitute a web standard."
For those times when you need to validate your markup but you don't have a 'net connection.
A really nice visual representation of just how isolated the Imperial system is.
A thoughtful post from PPK on the quality (or lack of it) in discourse around Web standards.
I was feeling very browbeaten after Molly's tirade but count on Jeffrey to put things in perspective.
Hail to the King... so says Business Week.
The second part of John Allsopp's superb series on semantics, philosophy and markup. Don't miss it! And be sure to go back and read the first part, too.
Happy tenth birthday, CSS.
Dave redesigns. And before I could bash him for his wide fixed width layout, he went and added a Jeremy Keith Button® on his about page that toggles between liquid and fixed. Cheeky bugger.
Dan has redesigned his site and it looks gorgeous.
Andy showed me some pages from the book over video iChat today. It looks great.
Read it and weep (for joy). The updated graded browser support table from Yahoo! "Termination of A-grade Support, IE5.5, Win"
New kids on the block.
Registration is now open for Web Directions North in Vancouver in February. Come for the geeky presentations, stay for the skiing.
Joe's notes make for great reading, specifically "Accessibility is a precursor to usability."
This transcript of Pat'n'Bruce's talk at the Geek in the Park makes for a great, thought-provoking read.
A PDF of Dan's slides from RailsConf. Looks like it was an excellent presentation.
Steve, Kevin, and the other AOLers do the right thing and provide a transcript of their (excellent) panel from Southby. Come on, other speakers... where are your transcripts?
Andy gets interviewed and starts reminiscing about the good ol' days.
Bruce pointed out this porn site that doesn't turn away blind users. That gives it the moral high ground over Target, in my opinion. NSFW if your Wplace is prudish.
Cindy redesigns... with standards. Gorgeous!
Where the worlds of web and booze collide, slap-bang in the middle of London. Arranging meet-ups, every now and then, where likeminded web peeps with sore livers can share these very special interests.
John has been working behind the scenes on this for quite a while and now it's ready for launch. Lots of yummy standards-based goodness in bite-sized chunks.
Drew adds support for microformats to Dreamweaver. Awesome!
Camino 1.0 is out. Come and get it.
Useful markup statistics from Google, complete with snotty commentary.
Garret Dimon runs through some of the options available when using CSS to improve readability.
"...it must degrade well. It must still be accessible. It must be usable. If not, it is a cool useless piece of rubbish for some or many people."
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.
Patrick Lauke, master of photography and accessibility.
The book that changed how websites are designed is back in a smart new second edition.
This is something I always meant to do but never got around to: a gallery site for good liquid design.
Eric and Jeffrey are going to the city of brotherly love.
Mike has a really nice stopgap technique for improving your site on mobile devices.
Eight people, including myself, explain what's so great about CSS.
Some good thoughts on accessibility. I'm really looking forward to seeing Derek again at @media.
Some nice CSS based redesigns this year. Of course, most of them are fixed width. C'est la vie.
The DOM support looks great.
John Allsopp on the importance of open formats for documents.