continuing (or not) to mint new integer constants for existing IDL attributes

We've previously discussed what to do with IDL attributes whose values 
are numeric constants, where we want to extend the set of things that 
the attribute represents.  I think the first case that came up was in 
Transforms, where we needed to reflect the new transform types that come 
from CSS Transforms into an SVGTransform object.  Since integer 
constants are considered an API anti-pattern these days, we decided to 
not introduce new numeric values for the SVGTransform::type attribute, 
but to use SVG_TRANSFORM_UNKNOWN for those new types.  We did a similar 
thing recently with the new value for SVGMarkerElement::orientType (for 
orient="auto-start-reverse".

I'm having second thoughts on this.  I don't think we're making things 
worse by adding new numeric constants to use for existing IDL 
attributes.  By not introducing new values for the new attribute values, 
we make it harder for the author.

(We obviously don't want to introduce new attributes that take numeric 
constants; we should be using IDL enums -- string values -- instead.)

I'd like to hear people's opinions on this.  As a single data point, I 
notice new CSS at-rules get new numeric constants for CSSRule::type.

Received on Wednesday, 10 July 2013 00:32:29 UTC