- 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>
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 data? 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 browsers? Best regards Mike Wilson
Received on Monday, 7 December 2009 22:41:02 UTC