The Extensible Web Manifesto
extensiblewebmanifesto.org
extensiblewebmanifesto.org
The problem with this approach is the trade-off with standardization: some vendors will implement things in different ways and libraries may not always work together without a little effort on the part of the user. Standardization does have its benefits... we almost went down the rabbit hole of active-x and "this site is made for Y," in the web world and it would be a shame to repeat that nasty bit of history (but we're already looming fairly close). The problem is that not everyone will cooperate and fickle web developers concerned with elegance and prettiness will go off and write three different incompatible implementations of the same thing. Users don't care about that stuff.
So it's not clear to me that this manifesto is actually the right choice. For every high level API misstep there is a corresponding low level one as well.
So, first, it's not the mark of failure for their to only be a high or low-level version of some capability in the platform; at least not immediately. The issue arises when, having exposed one or the other, we [users|vendors|spec-authors] think the job is done.
It's like saying you've got a map of a continent having mapped either the outer shoreline or the inland lakes. It's a nonsensical thought, but it's where we tend to leave things today.
Your brought up AppCache -- which, as it happens, is a topic near and dear to my heart as I'm currently trying to engineer its low-level explanation: https://github.com/slightlyoff/NavigationController.
AppCache had relatively well-known, overwhelming deficiencies early in life...yet instead of attempting to peel the onion and explain the layers below the manifest format, the spec process rewarded piling into the clown-car of declarative configuration. It's the natural thing to do, after all.
What we're after here is _connecting_ the high and low levels. Creating a fully descriptive map that has texture, color, and major features marked and named.
We must always start somewhere, but we must also be anxious to know and describe what we can sense but can't yet explain. And that requires a sense of urgent investigation.
And THAT is what is missing today.
Regards
> What we're after here is _connecting_ the high and low levels. Creating a fully descriptive map that has texture, color, and major features marked and named.
A low level AppCache API doesn't exist though. So there is no connection to happen, right? I realize people wish AppCache had been designed differently. I wish Touch Events had been designed differently. The web is littered with mistakes, I don't think a manifesto is going to prevent them from occurring.
What is the essence of this manifesto? I read it as favoring low level APIs. Ideally we could have both but there aren't the resources to make that practical.
As a part of that process (and Web Components before it), the goal isn't to throw out what has come before (we don't get that luxury out here on successful, non-proprietary platforms), but to re-cast it in the light of a lower-level thing that explains it.
You can go the other way too. Noodle on this to get a sense for it: how much of the <audio> element can be implemented with some JS and the Web Audio spec? Since those connections make sense, why isn't <audio> spec'd in terms of Web Audio, such that you can plug in/out the bits you need when you need something slightly different?
High-level API design problems are often of the form "there's no way to make this do what I need". That's what Yehuda's blog post about AppCache points out, and the result is either building something less good, or not building things on the web at all. That's much much worse.