- From: Mike Champion <mcc@arbortext.com>
- Date: Tue, 19 May 1998 21:58:41 -0400
- To: "Ray Whitmer" <ray@corel.com>, www-dom@w3.org
At 07:32 PM 5/19/98 -0400, Ray Whitmer wrote: >It seems to me the "splice" method of text is lacking definition: > >What happens if the element in question already has children? Are they >deleted? > >What happens if the text in question has no parent so it can have no >siblings? > >It seems that an exception would be called for (and I am beginning to >think most of these exceptions should be "run time" exceptions when they >represent a programming error because programmers would rarely have >alternate behavior for programming errors). That sounds reasonable ... > >For that matter, what if the specified element is already a child of >some other element? I have always thought that an insert or replace (or >splice) should remove first from the existing parent/sibling order, but >I haven't seen that spelled out. I agree; I'll propose that language to make it explicit. > >Another natural question is, how about providing the reverse of a splice >operation, which yanks the element out making the children into siblings >of the prior siblings, and joining any ajacent texts back together. Yes, we've discussed that; I'm not sure why it's not in the spec, but I agree it should be. > >But I guess "splice" type functionality might not be considered so >important a functionality for the core to worry that much about. Well, if it's not well-specified, we won't have interoperability, so it needs to either go in properly or come out! > >Otherwise, I might go on about the need for symetrical functionality >between element iteration and PCDATA iteration. Splice is just as >useful for elements with children as for text with characters. For that >matter, iterators are at least as useful for text with characters as in >their current form for elements with children. Could you elaborate, and perhaps make a more concrete suggestion? This sounds reasonable ... Thanks, Mike Champion
Received on Tuesday, 19 May 1998 22:02:10 UTC