From: Maciej Stachowiak [mailto:[email protected]]
> I have sketched a solution to it (including publicly in the last Web Apps WG > meeting). I believe the following set of primitives would be sufficient for > implementing built-in elements or their close equivalents: I think this is great, and am sorry I did not see those meeting notes. It would be excellent if they were implemented. I seem to have mischaracterized your position as being solely for type 2 encapsulation, without noting that that was simply a smaller piece of the five-part plan you outline. Thus my 1/2/3 division in reply to Brendan was misguided since it does not reflect that 2 would be a strict subset of 3, in your plan. I appreciate you taking the time to recap your solution-sketch despite my misunderstandings. I am hopeful that in my time on Google I can find enough interested people to work on making that vision, or something like it, a reality. > Unfortunately, Shadow DOM doesn't provide (1) and HTML Imports doesn't > provide (4). Thus, merely adding (2) and (3) won't be enough; we'll need to > create parallels to API that Google has already shipped and frozen without > addressing this problem. Right, but again the "how bad is it?" can be relative, depending on how different the versions end up needing to be. "Parallels" is hopefully the worst case. > However, I feel that my efforts to give feedback, both to nudge in this > direction and otherwise, have been rejected and stonewalled. With Google > controlling editorship of all the Web Components specs, shipping the only > implementation so far -- unprefixed, freezing said implementation, and not > being very open to non-Google input, and making all decisions in private via > "consensus within Google", it is hard to see how to meaningfully participate. > If there is any possibility of some of those factors changing, I think it's > not too late to end up with a better component model and I'd be interested in > helping. :( I think the Google team driving web components has tipped the pendulum very far toward the "good" side of "good is the enemy of perfect," in favor of shipping something sooner. This might even be the right decision for the web as a whole, given how badly we are behind on productive developer tooling and abstraction-building, and how much the existing web components specs improve this situation. (I imagine you have heard these arguments before and are not necessarily convinced. But I am sympathetic to them.) Nevertheless, as you can probably tell from this thread, by nature at least I lean more toward the "perfect" side. I hope I can help shift things thataways over time, both directly by helping with spec development/evolution/prototyping/implementation, and indirectly by changing minds. Easier said than done, of course.
