- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 11 May 2012 01:29:46 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>
On Fri, May 11, 2012 at 1:19 AM, Ian Hickson <ian@hixie.ch> wrote: > On Thu, 10 May 2012, Rafael Weinstein wrote: >> On Thu, May 10, 2012 at 4:01 PM, Ian Hickson <ian@hixie.ch> wrote: >> > On Fri, 11 May 2012, Tab Atkins Jr. wrote: >> > >> > But ok, let's assume that the use case is "create an element and its >> > subtree so that you can insert dynamically generated parts of an >> > application during runtime", e.g. inserting images in a dynamically >> > generated gallery [...] >> >> [...[ but here's one that comes to mind which is valid markup: What's >> the output for this >> >> myDocFrag.innerHTML = "<option>One<option>two<option>three"; > > My proposal would return a single option element with the value "One". Ah, I didn't get that you were making that distinction. Sorry, then, in that case your suggestion isn't quite right. > But the example here suggests a different use case. There are presumably > three elements there, not one. If this is a use case we want to address, > then let's go back to the use cases again: what is the problem we are > trying to solve? When would you create a document fragment of some > options, instead of just creating a <select> with options? For something like this: $("<p>Example "+exnum+":</p><p><img src="+exsrc+">").appendTo(container); (Presumably, this is run in a loop that generates the exnum and exsrc variables programmatically.) The fragment is two sibling elements, but it's conceptually a unit. There's no container separating the units from each other. ~TJ
Received on Thursday, 10 May 2012 23:30:36 UTC