Scott re-examines the browser support for loading everything-but-the-critical-CSS asynchronously and finds that it might now be as straightforward as this one declaration:
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">
I love the fact the Filament Group are actively looking at how deprecate their loadCSS polyfill—exactly the right attitude for polyfills in general.
A fascinating look at the web today with IE8. And it’s worth remembering who might be experiencing the web like this:
Whoever they are, you can bet they’re not using an old browser just to annoy you. Nobody deliberately chooses a worse browsing experience.
The article also outlines two possible coping strategies:
- Polyfilling Strive for feature parity for all by filling in the missing browser functionality.
- Progressive Enhancement Start from a core experience, then use feature detection to layer on functionality.
Take a wild guess as to which strategy I support.
There’s a bigger point made at the end of all this:
IE8 is today’s scapegoat. Tomorrow it’ll be IE9, next year it’ll be Safari, a year later it might be Chrome. You can swap IE8 out for ‘old browser of choice’. The point is, there will always be some divide between what browsers developers build for, and what browsers people are using. We should stop scoffing at that and start investing in robust, inclusive engineering solutions. The side effects of these strategies tend to pay dividends in terms of accessibility, performance and network resilience, so there’s a bigger picture at play here.
Move over, JavaScript alerts; HTML dialogs are here.
Really good advice for anyone thinking of releasing a polyfill into the world.
Behind the amusing banter there’s some really solid performance advice in here. Good stuff.
Client Side Rendering (CSR), or as I call it “setting money on fire and throwing it in a river” has its uses, but for this site would have been madness.
This is such a great perspective on what it’s like to build for the web over the long term. The web will always be a little bit broken, and that’s okay—we can plan for that.
The Web has history. If you build with web technology it will stick around. We try not to break the web even if it means the mistakes and bad decisions we have made in the past (and will make in the future) get set in stone.
You’re supposed to be able to create two-handled sliders with input type="range" but the browser support isn’t there yet. In the meantime, Lea has created a nice lightweight polyfill.
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.
This looks interesting: a CSS postprocessor that polyfills support for perfectly cromulent styles.
I completely agree with everything Rachel says here. I see far too many projects that start out with pre-emptive conditional comments, JavaScript libraries and polyfills, without knowing whether or not they’re actually going to be needed.
An in-depth look at browser polyfills: what they are, how they work, and how you can make your own.
A valiant attempt to polyfill support for hyphenation in browsers other than the latest Safari and Firefox.