- From: Philip Taylor <pjt47@cam.ac.uk>
- Date: Sat, 07 Jun 2008 04:03:48 +0100
- To: "Bonner, Matt (IPG)" <matt.bonner@hp.com>
- CC: "public-html@w3.org" <public-html@w3.org>
Bonner, Matt (IPG) wrote: > Hola, > > [...] > > First topic is <datatemplate>. I see that this is marked > as "Being considered for removal" in the WHATWG draft, so > I welcome any guidance on its likely fate. That said, it's > in the WD, so HP must review it. Questions: > > 1. Are there publicly available examples or explanatory > text for this feature? Also of interest would be any > discussion of its genesis or motivation from the HTML > or WHATWG mailing list archives. I couldn't find any. http://philip.html5.org/demos/datatemplate/experimental/ has the only public examples I'm aware of. They should be considered highly experimental (i.e. definitely wrong in certain ways (like it'll only work properly in XHTML, not HTML), and probably wrong in subtle ways), since I just wrote them in the evening after <datatemplate> was first added to the spec, and then I was happy to abandon them :-) There's no explanatory text, and I'm not sure anybody other than Hixie ever really understood the feature. It was never directly discussed on any lists - http://krijnhoetmer.nl/irc-logs/whatwg/20070508#l-134 says it was "[06:00] <Hixie> an idea hyatt and i came up with this afternoon", and there was some IRC discussion around http://krijnhoetmer.nl/irc-logs/whatwg/20070919 when it was added to the spec, and I don't remember there being much else. > 2. This section cites the "Levenberg data node algorithm" > and "Levenberg data template algorithm". Could someone > please point me to a reference outside the WD for these? As far as I'm aware, that's named after somebody who privately suggested that part of the algorithm to Hixie, so there's no external reference. (But I'm not at all certain about that, so it'd be good to check.) > 3. What are the allowed values for the "mode" attribute? For <rule>, it's a set of space-separated tokens. For <nest>, it's a single token. The individual tokens are just arbitrary text, like class names. The modes are used to tie <rule>s and <nest>s together: In the datatemplate, you define a set of rules, each of which will apply only in a certain set of modes (defined by its 'mode' attribute); and then you use <nest> where you want to instantiate DOM nodes, giving it a single mode (in its 'mode' attribute), which selects the subset of rules that match that mode and then applies the first matching rule to the data. E.g. http://philip.html5.org/demos/datatemplate/experimental/001.html uses <nest mode="details">, which will match all the rules of the form <rule mode="... details ...">, and the first of those rules that isn't excluded will be applied to the data. Then it uses <nest mode="summary"> to present exactly the same data using a totally different set of rules, as a second mode of presentation. > 4. The "condition" attribute definition says: The condition > attribute, if specified, must contain a valid selector. It > specifies which nodes in the data tree will have the > condition's template applied. [SELECTORS] But the link > on SELECTORS points to References, which is empty. What > kind of selectors are these? > > (The link in the WHATWG draft is broken, btw.) CSS selectors - I presume the link would point to http://www.w3.org/TR/css3-selectors/ (or whatever the latest version will be) once the references section is written. (The references are intentionally not written yet, because Hixie doesn't want to have to keep updating them whenever the referenced documents change or move.) > 5. The definition of <nest> says "The nest element represents > a point in a template where the user agent should recurse > and start inserting the children of the data node that > matches the rule in which the nest element finds itself." > Could you please say more precisely what recurses here? Extremely roughly, I think the algorithm is: 1) Start with the root data node (i.e. the data that the template is being applied to), and the root destination node (i.e. the place where the instantiated template will be put). 2) Find the first <rule> child of the <datatemplate> node that matches the current data node. 3) Take the matching <rule>'s descendants, and the current data node, and apply the text expansion rules (to replace the placeholders in the <rule> with data from the data node), and insert the result into the destination node. 3b) Every time you encounter a <nest> in the <rule> while text-expanding, recurse back to step 2, traversing down the two tree structures in parallel: set the desination node to be where the <nest> would have been put in the destination, and set the current data node to be each child node of the current data node in turn. (Except it's more complicated because e.g. it doesn't regenerate the destination tree each time since it needs to preserve the existing elements (like form inputs with user-entered values) as much as possible, and it recurses down the data nodes implicitly when there's no matching rules. And I don't currently remember/understand all the details. But hopefully this is more helpful than nothing :-) ) So the <nest> causes the algorithm to recurse down the data and output trees, so it can apply the template matching/expansion rules inside the results of the previous template match. E.g. http://philip.html5.org/demos/datatemplate/experimental/002.html starts with the <shop> data node, and selects the <rule condition="shop"> rule. It applies that rule to that data node, and encounters the <nest filter="categories"> in the rule, so it finds the <shop> node's child nodes that match the nest's filter (i.e. the the single <categories> node), and (recursively) applies the datatemplate to that <categories> node, which eventually causes all the category names to be inserted into the output where the <nest> was. > thanks, > Matt > -- > Matt Bonner > Hewlett-Packard Company -- Philip Taylor pjt47@cam.ac.uk
Received on Saturday, 7 June 2008 03:04:27 UTC