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 

> 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.


Reply via email to