Bug 15427
Summary: | much of the CSS system should be autogenerated | ||
---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | darin, hyatt, sam |
Priority: | P2 | ||
Version: | 523.x (Safari 3) | ||
Hardware: | Mac | ||
OS: | OS X 10.4 |
Eric Seidel (no email)
much of the CSS system should be autogenerated
CSSParser::parseValue
CSSStyleSelector::applyProperty
CSSComputedStyleDeclaration::getPropertyCSSValue
Could all be autogenerated. Instead of using a switch, a function table keyed off the autogenerated CSS_VAL_ defines. The actual main body for each parseValue, applyProperty, getPropertyCSSValue function would be completely autogenerated in each case. Most sub-functions (for simple values, like enums) could be autogenrated, but this would provide an easy override point for more complicated value/property handling. An example subfunction which could be autogenerated:
PassRefPtr<CSSValue> CSSComputedStyleDeclarationFunctions::getTextAnchor(RenderStyle* style, ...) {
if (svgStyle->textAnchor() == TA_START)
return new CSSPrimitiveValue(CSS_VAL_START);
else if (svgStyle->textAnchor() == TA_MIDDLE)
return new CSSPrimitiveValue(CSS_VAL_MIDDLE);
else
return new CSSPrimitiveValue(CSS_VAL_END);
}
Also, due to bug 15422, we no longer have very good compile-time checking (on SVG enabled builds) for all the necessary switch statements for CSS handling. This would add that back by either auto-generating all the needed subfunctions, or leaving them empty (and thus causing a compile failure).
We could even make CSSValueKeywords.in autogenerated from some more complicated file.
One possible source file:
CSSPropertiesAndValues.in:
stroke-miter-limit: <number>
alignment-baseline: [prefix: AB_] auto | baseline | before-edge | text-before-edge | middle | central | after-edge | text-after-edge | ideographic | alphabetic | hanging | mathematical | inherit
fill # custom
stroke # custom
That's obviously not a complete specification above, but some things to note:
1. inherit could be explicit or assumed depending on what's more common
2. some sort of custom value handling *by default*
3. automatic enum handling (note the use of a prefix for specifying how to convert enums for the Impl)
4. handles different value types (just like the CSS grammar does)
5. Note that CSS_VAL defines become automatic and implicit. Only if your overriding behavior do you ever know they exist. They become an implementation detail of the CSS system hidden from most coders.
I'd be curious to hear others thoughts. I think it'd be relatively straightforward to break the existing switch statements into subfunctions and autogenerate the parent function today. Then slowly we could add enum support, and other more advanced sub-function support.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
mitz
*** This bug has been marked as a duplicate of 12159 ***