W3C home > Mailing lists > Public > www-style@w3.org > December 2009

RE: [cssom] unrecognized rules and properties

From: Mike Wilson <mikewse@hotmail.com>
Date: Mon, 7 Dec 2009 23:40:18 +0100
To: "'Boris Zbarsky'" <bzbarsky@MIT.EDU>
Cc: "'Anne van Kesteren'" <annevk@opera.com>, <www-style@w3.org>
Message-ID: <01db01ca778e$41129a40$0a01a8c0@mikedeskxp>
Boris Zbarsky wrote:
> On 12/7/09 3:13 AM, Mike Wilson wrote:
> > It seems to me that retaining unrecognized 
> > properties is quite trivial
> That really depends. For example, Gecko's property 
> storage is optimized for low memory use and speed of 
> certain access patterns.  Properties aren't stored 
> as strings, but as packed parsed values (effectively 
> a "compiled" format).  Not only that but they're 
> identified by numeric identifiers (again as a 
> performance optimization; this allows looking up 
> information about them via array indexing).

This sounds nice and efficient. Just to be clear, I'm
making the argument that it would be quite possible 
to keep the unrecognized properties in the CSSOM, but
I'm not saying it will not consume resources. Compared
to your compiled data structures, and if keeping the 
unrecognized properties as plain string names and 
values, they will consume more memory per property.

> It's not quite obvious to me how to sanely store 
> unrecognized properties in this setup, and it would 
> certainly require a good bit of reworking of the 
> current code and data structures.

I wouldn't have thought so, as the unrecognized
properties wouldn't need to participate in your
optimized code paths that I guess have to do with 
layout and the cascade. My naive solution would be
to keep the unrecognized properties in their own
area, but still connected to the owner rule, as the
only access pattern is coming from user script and
not from browser internal code. From a quick look at 
the Mozilla codebase I would think that a simple
key-value store added to the nsCSSDeclaration class
would do the trick, in addition to the compiled 
properties carried by this class. Then augmenting 
nsCSSDeclaration::ToString() [for cssText 
serialization] and other methods with code for this 
new member would be straight-forward.
I realize I might be missing heaps of details here,
but are you really saying that you would have to
rework large parts of this code to accomodate this

Anyway, enough said about that. Switching back to the 
more theoretical subject, I'd be very interested in 
hearing your (and any other browser implementor's) 
view about the use case I mentioned; being able to
implement new standards through script in old

Best regards
Mike Wilson
Received on Monday, 7 December 2009 22:41:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:41 UTC