15427 2007-10-08 09:59:31 -0700 much of the CSS system should be autogenerated 2007-10-08 10:40:58 -0700 1 1 1 Unclassified WebKit CSS 523.x (Safari 3) Mac OS X 10.4 RESOLVED DUPLICATE 12159 P2 Normal --- 1 eric webkit-unassigned darin hyatt sam oldest_to_newest 58103 0 eric 2007-10-08 09:59:31 -0700 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. 58108 1 mitz 2007-10-08 10:40:58 -0700 *** This bug has been marked as a duplicate of 12159 ***