Some thoughts for discussion...

[codylindley]

1. Wouldn't this be better named h5facades, h5shield, h5glue, h5mediator, h5secure. Really anything that would help people understand that its not a polyfill and its used to abstract the underline interface not fill it so as to work in situations that the interface is not supported.
2. The "example-driven development" should eventually be replaced with some sort of test's. And the test can be require upfront.
3. As Nicholas points out in his article facades should include anything in the DOM or BOM, but should be very careful not to stray from the original api too far. Yes, this means that the DOM should be included here. If you think that would be too jQuery-ish just remember that jQuery is a facade, but one that concerns itself not only with abstracting the api but supporting browsers where the api is not available. In this project the facade would only be concerned with the abstraction and not bringing support to browsers that lack the api natively. All this to say, that html5 and friends includes the DOM and a good deal of API's on the document node. The more I think about it, the more I believe the reality is this project is exactly like the api abstractions found in jQuery except, h5ive is thinner and not concerned with supporting browsers that don't attempt to support the native api. I suppose, then that these thin layers could/should be used by libraries like jQuery that then decide to bring support for new api's in old browsers. Basically, the use of the code found in h5ive is valuable for library authors as well as for developers who are not concerned with bring support to older browsers but instead concerned with application code quality.

[getify]

Thanks, Cody! Great feedback. Here's some thoughts:

#1 I don't believe the name is misleading. I want a simple (but uniquely distinguished) name with a simple twitter and simple .com domain. h5ive was available and fit the bill. BTW, prior to h5ive, I called it h5api, but then I realized that THAT name actually could be misleading in certain contexts.

#2 I don't agree with "replaced" necessarily, but certainly "augmented". I want for part of the ethos of this project to be about creating useful APIs, not just APIs for the sake of them. By focusing first on how the API should look and feel, we keep the focus on actual usage and not on more esoteric questions like its suitability for standardization (it appears that a pre-requisite for standardization is basically a few WTF's baked in). :)

#3 I agree. As I said in our verbal discussions, I'm ok with a DOM module, as long as its restrained in its approach and not all about either: a) backward compatibility -- not a goal b) convenience function soup -- a hindrance and bloat.