Steve — Thanks for the encouragement! As I said, I know this won’t happen overnight, but we have to start somewhere.
Gustavo — I understand your points about TT hinting, but most of the ideas I’m thinking of aren’t possible with the existing implementation of TT hinting anyway. I’m trying to push the discussion far beyond just size-specific adjustments and grid-fitting, to allow for much more flexibility and contextual variation.
As far as backwards compatibility, the great thing about responsive design on the web is that you can detect – and design – for inequalities in support. Universal support isn’t necessary for it to be useful with the smart clients.
You are right in pointing out the lack of an ideal format (or other kind of reference method) for the variations of a typeface. I don’t see this as a collection of static instances though, but more as parameters that can be interpolated on the fly as needed (like Multiple Master typefaces). Otherwise, if you store binaries for every possible situation of size, weight, width, resolution, OS, browser, etc, etc, you will quickly be drowning in data bloat. This is basically what we have now with the “detect and serve” method, but it is not scalable for anything advanced or fluid.
Thanks for pointing to those older links, they are all good food for thought.
Gunnar — Like you, I am painfully aware of the different concepts for what constitutes a “pixel” (I’ve even <a >commented about it on ALA</a> before). To answer your question of “What pixel are you referring to? Device pixel? CSS pixel?”, my answer is: both! We should be able to detect and respond to either one as readily as the other.
Oli — Your idea of “intelligent systems” is along the right tracks. I don’t see it as taking choices away though, I see it more as providing better defaults, or offering more flexibility to adjust to the environment.