On Apr 28, 2011, at 5:46 AM, Alex Russell wrote: > On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak <m...@apple.com> wrote: >> >> On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: >> >>> >>> I agree with much of this. However it's hard to judge without a bit >>> more meat on it. Do you have any ideas for what such primitives would >>> look like? >> >> That's best discussed in the context of Rafael explaining what limitations >> prevent his proposal from working as well as it could purely as a JS library. > > The goal for this work is explicitly *not* to leave things to > libraries -- I'd like for that not to creep into the discussion as an > assumption or a pre-req.
I introduce this not as a pre-req or assumption but rather as my view of the best approach to addressing templating use cases, at least as a first step.I would also like it not to be a pre-req that templating must be addressed by a monolithic solution. But I am willing to hear out arguments for how it is better. > Libraries are expensive, slow, and lead to a tower-of-babel problem. That is all potentially true. But the tower-of-babel problem already exists in this area. Adding a new solution won't make the existing solutions disappear. The best way to mitigate the costs you describe is to provide primitives that enable the existing solutions to improve their quality of implementation. > On the other hand, good layering and the > ability to explain current behavior in terms of fewer, smaller > primitives is desirable, if only to allow libraries to play whatever > role they need to when the high-level MDV system doesn't meet some > particular need. That is a reasonable line of thinking. But in addition to modularity, I would also suggest a particular ordering - first add the right primitives to enable efficient, convenient DOM-based templating, then look for libraries to adopt it and/or promulgate new libraries, and only then standardize the high-level bits if they turn out to be high-value at that point. I had many particular supporting arguments for this approach, which your comments do not address. > >> The one specific thing I recall from a previous discussion of this proposal >> is that a way is needed to have a section of the DOM that is inactive - >> doesn't execute scripts, load anything, play media, etc - so that your >> template pattern can form a DOM but does not have side effects until the >> template is instantiated. > > Right. The contents of the <template> element are in that inactive state. > >> This specific concept has already been discussed on the list, and it seems >> like it would be very much reusable for other DOM-based templating systems, >> if it wasn't tied to a specific model of template instantiation and updates. > > Having it be a separately addressable primitive sounds like a good > thing...perhaps as some new Element type? I'm glad we agree on this aspect. I'm not sure what you mean by new Element type, but nothing prevents us from simply defining a new ordinary element (HTML element or otherwise) that has this semantic. Note that HTML elements generally already have the desired inactive behavior in viewless documents (as created by createDocuemtn or XMLHttpRequest) so an element that introduces such behavior should be quite modest in terms of spec and implementation burden. Regards, Maciej
