[web-animations-1] CSS parsing context for the procedure to process a keyframes argument ?

[stephenmcgruer]

Spec link: https://drafts.csswg.org/web-animations-1/#process-a-keyframes-argument

Step 8.1 of the "procedure to process a keyframes argument" says:

For each property-value pair in frame, parse the property value using the syntax specified for that property.

If the property value is invalid according to the syntax for the property, discard the property-value pair. User agents that provide support for diagnosing errors in content SHOULD produce an appropriate warning highlighting the invalid property value.

My understanding is that to parse a CSS property value and check whether it is syntactically correct requires an associated Document or similar context for the parsing. For example, it will likely be possible in the near future for web-developers to define custom syntaxes for CSS values - https://drafts.css-houdini.org/css-properties-values-api/#registering-custom-properties

This raises two related issues with the spec as is today:

1. What Document/context should be used for step 8.1 of the "procedure to process a keyframes argument", especially if the |target| is null?
   i. Note that the later procedure to produce computed keyframes specifies this clearly, in that the target (which has to be non-null in that procedure) is used as the context.

2. What should the user-agent do if the "procedure to process a keyframes argument" is called in a context where (say), "foo: bar" is a valid CSS property/value pair, but the target is then changed to a context where "foo: bar" is not a valid CSS property/value pair?
   i. The procedure to produce computed keyframes assumes that the CSS property/value pair are syntactically valid for the current target.

3. Same as the previous point, but for the reverse scenario - a property/value pair which is dropped when processing the keyframes argument but would be valid for the later target. This is less of an issue as you just end up dropping the pair when processing the keyframes argument and that's probably ok.

Thoughts? :D

[birtles]

We discussed this at our telcon in 2018-03-06:

Suggestion (smcgruer): use the CSS context from the target if non-null, otherwise use the CSS context from the same document as the execution environment for the JS?

birtles: Firefox does the latter: Uses the current realm document from when the KeyframeEffect was created. (See Bug 1277456)

flackr: Can we always use the current realm from when it was created?

But need to decide what to do about the case where a given (property, value) pair are valid in the execution context where we parse the keyframes, but not in the context where the keyframes are used.

Note that the context for computing the property value is based on the target element:
"For each property specified in keyframe, calculate the computed value specified on keyframe using the target element as the context for computing values"[1]
[1] https://drafts.csswg.org/web-animations-1/#calculating-computed-keyframes

This is strictly about the context used for parsing.

We want to avoid having to store the original string values--implementations should be able to store these values using a more compact form.

Thoughts: Security implications? Same origin frames only though, right?

Imagine switching a target from a secure context to a non-secure context (is this possible?); should we re-parse and drop CSS properties that are no longer valid (e.g. PaintWorklet).

Also quirks mode; if you enable/disable this it can change CSS property parsing we believe?

[birtles]

Discussed on 2018-04-12:

• We prefer the simplicity of always parsing using current realm document from when the KeyframeEffect was created.
• Can't target non-secure context from secure context
• Would prefer to be able to target content in iframes (birtles thinks this is common)
• Need to spec if we use quirks mode or not (birtles thinks Firefox might match the mode of the document of the current realm of the KeyframeEffect) -- but it doesn't have a big impact on quirks mode, basically supporting unitless lengths or not. Probably prefer to require always parsing in strict mode.
• For custom properties there is a potential mismatch between the set of allowed values in different contexts (depending on where the property is registered and with what type).
  • One option is for implementations to store the original string for custom properties and re-parse when the document of the target element changes and produce a suitable console warning at that point.
  • flackr would strongly prefer we just parse using the original context and if different documents define different types for properties then the value becomes invalid in the new context.