[cssom] Should font descriptors and such appear as properties in CSSStyleDeclaration?

[emilio]

See #3588 (comment).

Right now, per spec, they shouldn't:

https://drafts.csswg.org/cssom-1/#cssstyledeclaration says:

For each CSS property property that is a supported CSS property, the following partial interface applies where camel-cased attribute is obtained by running the CSS property to IDL attribute algorithm for property.

https://drafts.csswg.org/cssom-1/#supported-css-property doesn't say anything about descriptors. And indeed Blink at least returns true for 'unicodeRange' in document.documentElement.style, which is really weird.

But Blink and WebKit implement this. It feels a bit weird that 'unicodeRange' in document.body.style would return true... But on the other hand it is weird that 'color' in fontFaceRule.style would return true as well. So maybe we should expand the concept of "Supported CSS properties" to "Supported CSS properties and descriptors", or something.

Opinions?

[upsuper]

I don't think we should keep CSSStyleDeclaration style in CSSFontFaceRule. This is a mistake.

IIRC, previously when CSS Fonts spec initially introduced this interface, CSSStyleDeclaration only contains the methods, and at that time all the property accessors were defined in a separate interface, probably CSS2Properties? In that model, it probably makes some sense to use CSSStyleDeclaration with a separate set of descriptors. Later, some changes to CSSOM spec merges the aforementioned two interfaces, and consequently CSSFontFaceRule.style incorrect gains all the properties in the perspective of the spec, which makes no sense.

Gecko still has separate CSSStyleDeclaration and CSS2Properties mainly because of this problem.

Given that I haven't heard any webcompat report regarding Gecko's current behavior on this, I pretty much believe we can move away from this weirdness. I propose that we define a separate interface for CSSFontFaceRule, probably something like CSSFontFaceDeclaration, and put all font-face descriptors into that interface, then we also copy all the methods from CSSStyleDeclaration into the new interface for backward compatibility.

I don't propose creating a common interface for CSSStyleDeclaration and CSSFontFaceDeclaration to inherit from because I think those methods should be considered legacy, as well as this style of declaring interface for at-rule (i.e. having an indirection style property just to access its content). Any new at-rule with descriptors should follow CSSCounterStyleRule to have all descriptors listed on the top level.

[emilio]

Maybe @zcorpan has a bit more background on the historical context here?

[emilio]

Also cc @lilles / @rniwa, in case they have any strong opinions?

[zcorpan]

I don't know why it is like this.

I recall that maybe @tabatkins specified a different design for font descriptors somewhere. This maybe?

https://drafts.csswg.org/css-font-loading/#fontface-interface

Would it work to return a FontFace instance for CSSFontFaceRule.style, or is that weird?

[upsuper]

Would it work to return a FontFace instance for CSSFontFaceRule.style, or is that weird?

I don't think so unless you duplicate some of the fields with the way they are currently in CSSFontFaceRule.style, e.g. font-family and family, and also adding those methods. IIRC there was data somewhere showing that websites do use things like getPropertyValue on CSSFontFaceRule.style, so we may have to live with that.

[gsnedders]

This is effectively a dupe of #5649, given that contains a resolution for this, which essentially boils down to having subtypes of CSSStyleDeclaration where properties and descriptors appear. Closing this as a forward dupe.