[css-typed-om] [css-paint-api] What happens to unsupported property names in the registered paint styleMap?

[darrnshn]

Suppose we specify unsupported property names calling registerPaint:

registerPaint('bleh', class {
    static get inputProperties() {
        return [
            'invalid', // invalid CSS property
            'border', // shorthand
        ];
    }
    paint(ctx, geom, styleMap) {
        const properties = styleMap.getProperties().sort();
        console.log(properties); // ??
   }
});

The paint spec says it's legal to have invalid properties in inputProperties() for forwards compat, but do these properties actually get returned by the style property map? Would the above output [] or ['invalid', 'border']? Note that normally (using just the Typed OM API), a StylePropertyMap can't contain unsupported property names.

[tabatkins]

Hmm, we do need to accept invalid properties, but reflecting them is problematic - what would they reflect as? The best we could do is treat them like untyped custom properties, and return a token list; this is weird tho, and seems just as likely to break naive code that assumes the property exists as just not returning the property at all in the map.

So, we should filter the list of input properties and store the filtered list as the set of listened-to properties that get reflected in the StylePropertyMap. That also matches up with the existing behavior of StylePropertyMap, as you cited.

[darrnshn]

On a related note, what would be the behaviour of iterating over unregistered custom properties that were not specified? E.g. inputProperties has --bar but --bar is never referenced anywhere in the file, and then we get all property/value pairs in styleMap.

They're not "unsupported", e.g. styleMap.get("--bar") doesn't throw an error, but returns null. I see two options:

1. Just ignore them like invalid properties.
2. Return (--bar, null) as the entry.

[tabatkins]

Hm, they shouldn't return null, they should return an empty CSSUnparsedValue object, as that's the type for all unregistered properties.

[darrnshn]

Oh interesting! Do you think we should clarify this in StylePropertyMap.get? Wording-wise, I guess we could either explicitly handle unregistered custom properties in the algorithm, or say that the property model implicitly contains an entry for every unregistered custom property?

[tabatkins]

Oooh, probably, yeah.

[bfgeek]

@nainar @darrnshn What needs to happen in the Paint API spec for this?

[darrnshn]

I think the paint API just needs to silently filter out invalid properties (CSS properties which are not implemented by that particular browser) from inputProperties (like foo). Not sure if the spec already mentions this.