- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Mon, 4 Jan 2010 23:21:03 -0800
- To: Patrick Garies <pgaries@fastmail.us>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, www-style list <www-style@w3.org>
On Jan 4, 2010, at 9:43 PM, Patrick Garies <pgaries@fastmail.us> wrote:
> On 2010-01-04 12:46 AM, Brad Kemper wrote:
>> On Jan 3, 2010, at 9:02 PM, Boris Zbarsky wrote:
>>> Simple example #1:
>>>
>>> <!DOCTYPE html> <body> <script>
>>> document.body.appendChild(document.createTextNode("ba"));
>>> document.body.appendChild(document.createTextNode("r")); </script>
>>
>> I see. I would treat that as if it were all one node, since there
>> would seem to be little advantage to not doing so.
>
> If you assign each of these statements to a variable, there's going to
> be a problem getting and altering nodes that don't exist because
> you've
> arbitrarily merged them with other nodes.
I'm not merging them in the DOM; I'm just treating then as merged for
the sake of matching them with the string in the pseudo-element
function.
> There can be advantages (other than variables) to having separate text
> nodes as well.
I don't doubt that, ad I'm not proposing that the selector changes the
DOM.
>>> Simple example #2:
>>>
>>> <!DOCTYPE html> <body> ba<!--comment, so the textnodes aren't even
>>> quite adjacent in the DOM-->r
>>
>> Hmm. It is a bit murkier, but I think that treating the comment as
>> though it were utter nothingness and as if "bar" was all part of the
>> same node would be the right thing to do.
>
> There's been a comment node type since DOM1, so you can't arbitrarily
> scrap the node to merge the text nodes.
I'm not. I'm just ignoring it when determining what ::text() would
match. It would still be there for all other purposes.
>
Received on Tuesday, 5 January 2010 07:21:43 UTC