Bug 106175 - Split CSSValues into separate internal and CSSOM types
Summary: Split CSSValues into separate internal and CSSOM types
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dave Hyatt
Depends on:
Reported: 2013-01-05 07:04 PST by Antti Koivisto
Modified: 2016-12-13 10:37 PST (History)
9 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Antti Koivisto 2013-01-05 07:04:49 PST
The current CSSValue subclasses are used both as internal types and as externally visible CSSOM types. The internal and external instances are never the same. When a CSSOM instance is needed it is created by CSSValue::cloneForCSSOM(). Only a few value types are actually externally exposed, the rest are represented by instances of TextCloneCSSValue which just grabs the cssText of the value.

We should split the internal and external types similar to what has already been done with the other style data structures. The new internal types would be prefixed by "StyleValue" (consistent with StyleRules etc):

CSSValue -> StyleValue
CSSPrimitiveValue -> StyleValuePrimitive
CSSValueList -> StyleValueList
CSSFontFaceSrcValue -> StyleValueFontFaceSrc

For those few types (~10) that are exposed via CSSOM we would still also have the corresponding CSSValue type. Those would never be used internally, they would be instantiated on API access only.

This would be good because

- We want to split our internal types off the API types everywhere. This gives us freedom to optimize our internals for memory and performance.
- CSSValue::cloneForCSSOM() is hacky and confusing.
- It is also (security) bug-prone. It is easy to accidentally leak internal instance via API. We protect against that with asserts but compile time protection is way better.
- The externally visible CSSValues won't be memory critical so they can use normal virtual functions etc.
- This would complete our new style data structures, making that portion of the codebase consistent.
Comment 1 Antti Koivisto 2013-01-05 07:06:36 PST
If someone wants to tackle a big refactoring, here is one. It is relatively mechanical though there are some architectural issues to solve too. You can definitely learn a lot about how things work by doing this.
Comment 2 Antti Koivisto 2013-01-05 07:12:41 PST

- Internal types can have interface that matches our coding style, instead of being mandated by the spec