- From: Robin Berjon <robin@w3.org>
- Date: Mon, 24 Jun 2013 14:54:22 +0200
- To: Rafael Weinstein <rafaelw@google.com>
- CC: Anne van Kesteren <annevk@annevk.nl>, Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>, Dimitri Glazkov <dglazkov@chromium.org>, Tony Ross <tross@microsoft.com>, Travis Leithead <Travis.Leithead@microsoft.com>, Ian Hickson <ianh@google.com>
Hi, On 19/06/2013 04:05 , Rafael Weinstein wrote: > Note that this doesn't cover monkey-patches other specs: > > https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#node-clone-additions I believe that's covered. If you look at the last paragraph in: http://www.w3.org/html/wg/drafts/html/master/templating.html#the-template-element This plugs into step 5 in: http://www.w3.org/TR/domcore/#concept-node-clone which is precisely the extension point that's required. I'm happy for suggestions as to how to make this clearer. > https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#innerhtml-on-templates Yes, that's why I copied Travis. Travis? One option is that we could have a similar extensibility point in innerHTML, rather than change it directly. > https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#parsing-xhtml-documents I've added the relevant text here: http://www.w3.org/html/wg/drafts/html/master/the-xhtml-syntax.html#parsing-xhtml-documents (just below the note on document.write()). Is that okay? > https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#serializing-xhtml-documents Likewise, I've added the text at the bottom of: http://www.w3.org/html/wg/drafts/html/master/the-xhtml-syntax.html#serializing-xhtml-fragments > Here are the issues I see: > > Section name: Again, I suggest "HTML Templates" rather than "HTML > Templating" to minimize confusion. Yup, done. (Though it's just "Templates" since pretty much everything in there is "HTML".) > 4.4 Templating > > -Typo, 4th paragraph: "and its contents be any content" => "and its > contents CAN be any content" Fixed. > 4.4.1 Defs: > > -Typo, "The template contents are be a DocumentFragment whose" => "The > template contents must be a DocumentFragment whose" Fixed. > 4.4.2 The template element: > > -I'm not sure the "Contexts" defined as metadata and flow content is > sufficient. For example, the children of <table> are not "flow > content", but <template> is allowed within those contexts. Indeed, I'm unsure why I changed that. Fixed. > -The NOTE here is trying to prevent DOM hierarchy cycles. The WHATWG > DOM has addressed this here: > http://dom.spec.whatwg.org/#mutation-algorithms by checking the > host-inclusive ancestor. I don't see equivalent language in the W3C > DOM spec. It may still be worth an editorial note, but I think it's > better to point to the pre-insert language which prevents the cycle. Right, but I've been operating under the assumption that the WHATWG DOM and the W3C DOM would be the same, if not now at least soon. That would address this concern, right? (In which case we can drop this note.) I'd really rather we didnt' make our specs defensive against such disparities but instead made sure our dependencies are aligned. Currently the W3C HTML spec refers to the WHATWG DOM anyway, so I think we're covered :) Or am I missing something? > 8.2.5.4 Template Parenting > > I think "parenting" suggests that the template will get a new parent > (e.g. with "fosterparenting"). How about "template content kidnapping" > (only half-joking -- we do have "call the foster agency"). Another > idea "Template Content Parenting" or "Template Content Redirection" "Template content kidnapping" was very tempting, but there may be such a thing as enough of a good joke and I reckon the thread of children jokes in the parsing algorithm might fall in that category :) I went with "template content parenting". > 8.2.5.3 Foster Parenting > > I think the foster parenting description is now complex enough that it > should be factored into an algorithm which selects the foster parent. > As it is right now, it's not clear whether the steps apply in order or > not (if they apply in order, I think they might be wrong). I agree, but I reckon that's a separate issue. Do you mind filing a bug? -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 24 June 2013 12:54:33 UTC