This is a nice vision from Anne van Kesteren, but reading it makes me feel a little uneasy. As proponents of the web, we shouldn’t be too inward-looking and get absorbed in our own web-focused world. The web and native platforms/apps have different strengths and weaknesses and there will always be a place for both — there doesn’t have to be a winner.
Posted in Linked List
Marking up and styling
<table>s has always been an interesting problem for me, and here Harry Roberts explains his clever method of normalising table layouts on a complex page.
A good run-down by Steve Souders of the prefetching and prerendering techniques now available to us in modern browsers. Some of this is really trivial to implement but could make a site noticeably snappier for users.
This post by Tab Atkins isn’t new, but it’s a good explanation for the uninitiated of what Futures (aka Promises) are and how they will work in the DOM, and it’s topical because Promises are out from behind their flag in Chromium as of a few days ago, which means they should be in Chrome stable within a month.
As usual, an excellent and thorough post by Max Firtman detailing the changes to Mobile Safari (and UIWebView) in iOS 7. A must-read for any web developer (and it’s certainly not all good news).
Side note: as predictable as all the talk about iOS 7 is the moaning about that talk. But consider that iOS is one of the world’s most used operating systems, and that Mobile Safari is one of the world’s most used browsers, and that it’s just shipped a major update, and that a week from now the majority of existing users will be running that update, and that millions of new users will join them. If the significance of that is lost on you, I don’t even know where to start.
A big milestone, and a couple of major changes — support for IE < 9 has been removed, slicing 12% off the file size, and you can now do custom builds to save more file size by removing modules you don’t need.
I was skeptical that the custom build thing would be worth much — that is, that you’d have to exclude the useful parts of the library to really save anything. However, looking at a (fairly large) project I’m working on right now, I could drop
sizzle without touching a line of code, and a few other modules are only used once or twice and could be sacrificed in the name of speed.
Tab Atkins bring us down to earth with this post detailing why element queries would be so challenging to implement.
Personally, I think the ideas about ways to avoid the looping problem won’t really satisfy developers — what we really want is a
min-container-width media query and nothing less will do. I’d be interested to hear how implementers feel about the looping problem — could it be managed with robust error handling (e.g. detect whether an element query will cause a loop, and if so then ignore the CSS within it) or is there just too much risk of crashing the browser?
I guess it’s just too much work to walk out the front door five steps, pick up the newspaper that was delivered while you slept, and then bring it back to your kitchen table each morning to read the news of the world. Now you want it to appear instantly on your computer screen. OK, Mr. Fancypants Bigshot.
I’m usually bored by tech journalism, or whatever you want to call it, but John Siracusa’s recent surge of writing on Hypercritical has been quite entertaining.
A good round-up by David Storey of what it looks like IE11 will be including. Very promising.
Thanks to John Resig, I finally understand what Asm.js is and why I’ll almost certainly never use it.