- From: <bugzilla@jessica.w3.org>
- Date: Wed, 05 Sep 2012 23:10:15 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18672
Adam Klein <adamk@chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adamk@chromium.org
--- Comment #1 from Adam Klein <adamk@chromium.org> 2012-09-05 23:10:14 UTC ---
I don't think the argument to cloneNode() should have any effect on what
happens to the "content" property; its meaning should be limited to whether the
template's children are cloned (though of course template won't normally have
any children, unless they've been added by script).
As for what cloneNode should do about "content", it seems like sharing the
original template's content DocumentFragment (Rafael's option (3)) is at odds
with the whole idea of "cloning". It would be quite surprising if changes to a
cloned node affected the node it was cloned from. (1) seems wrong, since the
clone is semantically very different from the original. The closest existing
HTML element here is <input>, which copies its "value" property (along with a
few others). So I think that Rafael's option (2) is the right answer.
The objection seems to be about memory efficiency in the case of a templating
library. Perhaps we need to make content settable, rather than readonly? That
would allow a library to clone templates manually, e.g., by creating a new
<template> and setting its content property to that of the original.
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 5 September 2012 23:10:16 UTC