W3C home > Mailing lists > Public > www-style@w3.org > October 2005

Re: [css21] parsing of comment and element nodes inside style declaration

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 17 Oct 2005 14:13:15 -0500
Message-ID: <4353F7CB.4010707@mit.edu>
To: Stanimir Stamenkov <stanio@myrealbox.com>
CC: www-style@w3.org

Stanimir Stamenkov wrote:
> I wonder how much faster it would be if the data is processed from a 
> stream

Given that the stylesheet needs, in general, to be reparsed when the 
<style> DOM node is moved in the DOM, the only way the style data is 
processed "from a stream" is if there are two separate codepaths for the 
two cases...

> and the tree is going to be crawled anyway, at least to detect 
> the well-formed end of the 'style' element (I didn't understand the 
> "error handling behavior" part)

Per the XHTML DTD, elements are not allowed as children of <style>.  So 
a document that has such markup, while well-formed, is not valid.

> or you point the text content for the 
> style sheet is processed only from already built DOM nodes?

The latter (getting the text to be parsed as CSS from the DOM) is what 
Gecko does, for what it's worth.

> IMO, the 'textContent' property being property implies (to some possible 
> extent) the DOM implementation would optimize the storage of the 
> represented value

Why?  There's nothing special about properties as opposed to methods. 
The things that should be optimized are the ones that are used often; 
.textContent is almost never used, ergo not worth the memory impact of 

> to be retrieved directly and not as part of some 
> computation (and possible allocation of new resources in this case, 
> concatenating the values of text nodes).

The latter is exactly how Gecko does it.  I tried to check what webcore 
does, but it doesn't seem to implement .textContent (at least the code I 
got from http://developer.apple.com/darwin/projects/webcore/ doesn't). 
No idea what Opera does.

Received on Monday, 17 October 2005 19:11:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:21 UTC