Below you find the last seven QuirksBlog entries.
Two weeks ago I heard that a person close to me is seriously ill. I spent too much time in the hospital lately, but fortunately the situation has improved all the way to serious but not hopeless. Let’s hope it improves again from there — not impossible at all, but not a certainty, either.
Well, last week’s article generated quite a few hits, and even some useful responses. It’s time to respond to the responses — and note one interesting coincidence.
I feel it’s time to revisit the web vs. native debate, and concede defeat — or, at least, concede that the web cannot, and should not, compete with native when it comes to complex, app-like structures.
I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue.
I feel that our desire to take on native heads-on has given rise to unnecessarily complex toolchains that slow down what could be simple websites. I’m especially thinking of struggling news sites here, and will argue below that they should go native all the way and forget about the web.
Seems Facebook (which I don’t use) has put out a new product that allows iPhone users (and only them) to read news articles without leaving Facebook. John Gruber wrote an as-always thought-provoking article about why this could be bad for the web as a whole.
Although I don’t agree that the web is in danger (we hear this story every week, it seems), John makes an important and valid point:
Daring Fireball pages load fast, but the pages I link to often don’t. I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.
After last week’s rant about, among other things, the W3C Device Adaptation spec, one of the spec’s authors asked me to clarify my critique. Fair enough. Here’s my take on the current specification.
My critique of Device Adaptation consists of three main themes:
- The spec does not address the actual current situation at all, while all browsers actually support my theory of the layout, visual, and ideal viewports decently, and I’ve already done the heavy lifting.
- The spec is obscure about what its most important components actually mean; I’m especially thinking of the initial and actual viewport. A simple schematic would have helped a lot here, and it’s fairly easy to produce.
- Although the spec treats relevant media queries as well as the meta viewport and the
devicePixelRatio. That latter, especially, could do with some specification.
Today I rant about undocumented Chrome features and unreadable W3C specs. There’s too much of both nowadays, and I’m getting VERY tired of both. Google and W3C should clean up their act.
During my research of modern input types such as
number I stumbled upon the
type === 'text' detection, mostly in order to cater to Android WebKit, although it also solves a few other problems.
Even older entries
See the March 2015 archive and beyond.