CSS-TAG Houdini Task Force Specifications
This is the repository containing the CSS/TAG Houdini Task Force specifications.
In addition to this git repository, a Mercurial mirror is maintained at
https://hg.css-houdini.org/drafts, if for whatever reason you prefer Mercurial.
Specification issues are raised and discussed in GitHub Issues in this repository.
We also maintain the public-houdini mailing list for general-interest topics.
New specifications are generally first incubated in the WICG, in particular:
For normative changes, a corresponding web-platform-tests PR is highly appreciated. Typically, both PRs will be merged at the same time. Note that a test change that contradicts the spec should not be merged before the corresponding spec change. If testing is not practical, please explain why and if appropriate file an issue to follow up later. Add the
type:missing-coverage label as appropriate.
Maybe as part of https://github.com/whatwg/html/pull/2518 or a follow-up.
cc @bakulf @domenic @lars-t-hansen
[worklets] dynamic import()
I thought we already had an issue for this somewhere. If worklets cannot have
fetch(), I don't think it makes sense for them to have dynamic
import(). That would cause the same kind of execution problems.
cc @domenic @nhiroki @bfgeek
[css-properties-values-api] Interaction with setProperty is unfortunate.
The reasoning for that is intentional apparently:
But I think it's still weird that:
Behaves differently to:
Is this behavior up-for-discussion? I think it is really unfortunate.
cc @andruud @tabatkins
[css-paint-api] Rename paint(name, args) to paint-name(args)
The way the Paint API currently works is that it gives authors a
paint()function, whose first argument is an
<ident>for the name of painting operation.
However, putting the name of painting in the function call has several benefits:
Compare (examples from the spec):
Isn't the latter much easier to read? Doesn't it immediately communicate what it's doing?
Also, as a polyfill author it is much easier to explain to my users that my script adds a new
paint-rainbow()function that they use with x, y, z arguments, than to explain that they have to use this generic
paint()function, where the first argument is fixed to
rainbowand the rest are the actual arguments they provide.
I recall mentioning this in person to some Houdini folks ages ago, and they agreed, but I never made an issue so I guess it was forgotten.
[css-typed-om] What does lack of range restriction imply about serialization?
The section on CSSNumericValue says:
(It then proceeds to give an example demonstrating this.)
What this doesn't seem to address is what implications this has for CSS's existing object model APIs that involve serialization. It's long been a principle of these APIs that they always give output that is valid CSS. This means that, for example, getting
element.style.cssText, modifying it, and setting it back to
element.style.cssTextshould change only the thing that was modified. Likewise for
setProperty, or the
element.style.propertyNamethat is equivalent to them. However, the rules for these setters require following the rules of CSS parsing and dropping any declarations that are not valid. This means that serializing things that don't round-trip correctly would break anything that depends on this round-tripping.
It seem like there are a bunch of bad options here (listed in the order that seems best to worst to me at first glance, although I'm sure I'm missing many considerations):
CSSNumericValues when they're set in some cases
I tried to look through the spec to see if one of these options was specified later, but I didn't see anything. If there is something I missed, it would be good to have a pointer to it from this section.
It's also entirely possible that the WG has discussed this and I've forgotten (or missed it).
[worklets] (bikeshedding time!) import() name is potentially confusing...
So the import function has been noted as potentially confusing.
Other names which have been discussed at some point are:
For additional context the other way to invoke scripts will be via the script tag most likely, e.g.
Which is the same as
From https://github.com/w3c/css-houdini-drafts/issues/373 originally.
[css-properties-values-api] Allow custom property descriptors with a CSS @-rule
The incredible flexibility of CSS Variables / Custom Properties introduces limitations compared to regular properties. By default they:
The CSS Properties Values API addresses all these limitations, but requires script to run to do so. This will cause async issues (CSS having to be re-parsed after script runs) and is no use at all in cases where scripts are disabled for security reasons (e.g., SVG-as-image).
While the general argument for using JS APIs for Houdini has been discussed in #86, I think property declarations are a special case. This isn't about declaring functionality that needs to be represented as script functions; it's merely declaring a data object. An @-rule of descriptors and values seems a perfect fit:
It would of course be preferable to always have
@propertyrules earlier in the CSS parsing sequence than any declarations using those properties. However, since it is also going to be possible to set property declarations asynchronously with the API, I don't think this would need to be an enforced syntax rule, just a performance recommendation.
The effects of this declaration would be the same as for a declaration via the API. E.g., If
initial-valueisn't specified, it would get the "nothing" initial value described in CSS Custom Properties, with the resulting implication for
The API currently advises throwing an error if the provided initial value doesn't match the provided syntax. For a
@propertydeclaration, I would recommended simply dropping the non-conforming initial value declaration. This could allow multiple declarations with standard CSS fallback methods, e.g., for new functions that might not be recognized:
[css-properties-values-api] Should property registration be scoped?
The fact that property registration is document global makes it impossible to use a custom property privately in a shadow tree. Maybe registration should be scoped somehow, optimally to a style sheet or shadow scope.
[css-typed-om] Will need to handle min()/max()
I haven't added it to the spec yet, but the CSSWG resolved to add min()/max() to the V&U spec at the Seattle 2017 f2f. This'll need a new class to represent it properly.
Ban data URL worklets
Although I thought data URL worklets would be fine, per #506 and implementation reality, static imports are supported, which means worklets have some means of networking. In that case it would be better for data URLs to create their own agent cluster (see also https://github.com/whatwg/html/pull/5476), but that would be kind of pointless, especially for audio worklets. So it makes more sense to network error data URL worklets (to me).
cc @padenot @nhiroki
[css-paint-api] Running author function without proper preparation.
In short, invoke a paint callback does not follow Web IDL nor HTML specs. The CSS Painting API spec and its algorithms are defined using ECMAScript directly, and it violates Web IDL and HTML specs.
I cannot list up all the places that are conflicting with Web IDL and/or HTML, so let me show an example.
In invoke a paint callback, step 5.3. "Let paintInstance be the result of Construct(paintCtor)."; this step invokes an author function |paintCtor| without performing prepare to run script nor prepare to run a callback. This is NOT allowed in Web IDL nor HTML. |paintCtor| will run without the Incumbent realm having been set up, so we cannot tell what would happen if |paintCtor| invoked an Web API that uses the Incumbent realm.
I originally reported the same issue to Animation Worklet. It seems better to report this to CSS Paint API, too, so I'm now reporting here.
Ideally, each Web API spec should not be defined with ECMAScript. Web IDL provides all the necessary abstraction and it's easier with Web IDL to make each spec consistent.
Dependency Cycles via Relative Units with unit algebra
#315 was fixed without considering "unit algebra". CSS Values 4 allows dividing by dimensions, so we may have
That's a dependency cycle! It's not addressed by https://drafts.css-houdini.org/css-properties-values-api/#dependency-cycles, since that only handles registered properties with a syntax of
The example above uses
<number>, but other dimensions like
<angle>are also affected:
[css-animation-worklet-1] Broken references in CSS Animation Worklet API
While crawling CSS Animation Worklet API, the following links to other specifications were detected as pointing to non-existing anchors:
This issue was detected and reported semi-automatically by Strudy based on data collected in webref.
[css-typed-om] "create a sum value" behavior is undefined for CSSMathClamp type
"create a sum value" behavior is undefined for CSSMathClamp type:
This section deals with many types but not CSSMathClamp. I couldn't find anywhere the spec text for what the behavior should be for a CSSMathClamp.
should paint() take
rather than ?
I think the paint() function should perhaps take
<ident>, and forbid the CSS-wide keywords, etc. (This is what Blink implements.)
initial value for universal ("*") syntax definition should not allow CSS-wide keywords
Right now the steps for registering a custom property appear to allow the initial value for registered properties that use the universal syntax definition ("*") to be a CSS-wide keyword (such as
initial, etc.). Since these values are treated specially in custom properties I think they probably shouldn't be allowed in the initial value of a registered property.
I think it's possibly also allowed in the non-universal case as well, depending on how you interpret "computationally independent".
I think these rules should throw an error in step 4 if the value given is a CSS-wide keyword. (It's possible they should also reserve
defaultwhich is disallowed from being a
<custom-ident>, but is not a CSS-wide keyword.)
[css-typed-om-1] Handle `
` and ` `
4.3.2. Numeric Value Typing:
Is there any particular reason for not supporting
<decibel>seems to be used in the value definition of
<semitones>seems to be used in the value definition of
voice-range(CSS Speech). Both properties are marked as at-risk:
<semitones>are defined as
They are missing in CSS Values but generally speaking, wouldn't it be better to refer to the dimensions defined in CSS Values, and avoid explicitly listing the supported dimensions?
To be honest, I'm also creating this issue to ask a question. I would like to know the reason why type entries must be ordered according to the order of the base types:
I'm trying to find a test case that would fail if they were defined in a different order.