[css-mixins-1] Flesh out CSSFunctionRule

[andruud]

CSSFunctionRule has so far ignored the existence of a prelude in the @function rule. This adds CSSOM support for the function name, return type, and parameters.

[tabatkins]

I presume we'd want to represent the body as well, right? As a .style/.childRules pair, like style rules do?

(The rest looks good on a quick skim.)

[andruud]

I presume we'd want to represent the body as well, right? As a .style/.childRules pair, like style rules do?

It's there, it's just not easily visible: we get childRules by inheriting from CSSGroupingRule. (Should probably be made more easily visible.)

.style

There is intentionally no style attribute on CSSFunctionRule. The "leading" block of declarations (if any) is just wrapped in a CSSFunctionDeclarations rule and put in childRules. This is consistent with other grouping rules affected by nested declarations, i.e. nested grouping rules, and even @scope top-level as of #10389. I think it's more consistent this way, vs. treating the leading block as special.

CSSFunctionDeclarations has a style attribute, though. :-)

(The rest looks good on a quick skim.)

Like briefly discussed elsewhere, should we be using a CSSOMString? return value for attributes that possibly have no value? (And return null instead of "" when there is no value?)

[tabatkins]

Like briefly discussed elsewhere, should we be using a CSSOMString? return value for attributes that possibly have no value? (And return null instead of "" when there is no value?)

Yup, an empty default and no default are definitely distinct values, and need to be represented differently in the OM. I've gone ahead and made the default CSSOMString? to accommodate.

[andruud]

Like briefly discussed elsewhere, should we be using a CSSOMString? return value for attributes that possibly have no value? (And return null instead of "" when there is no value?)

Yup, an empty default and no default are definitely distinct values, and need to be represented differently in the OM. I've gone ahead and made the default CSSOMString? to accommodate.

Right, looks like we already did represent it differently: no default = no entry in the dictionary; empty default = empty CSSOMString.

I take it we then prefer an explicit null entry if there is no default?

[tabatkins]

no default = no entry in the dictionary; empty default = empty CSSOMString.

Yeah, much better to have a consistent object shape with a null-valued property.