@property

[andruud]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: @property (part of CSS Properties and Values API Level 1, CSS Properties and Values API Level 1 #318)
• Specification URL: The @property rule
• GitHub issues: https://github.com/w3c/css-houdini-drafts/issues, use [css-properties-values-api] prefix in the title of issues.
• Tests: Blink-specific test (will "upgrade" to WPT).
• Primary contacts (and their relationship to the specification): @andruud (Chrome implementor), @tabatkins (editor)
• I added a (very) brief description of this feature near the bottom.

Further details:

• Relevant time constraints or deadlines: Dec 1st 2019. I will attempt to ship this in December, or as soon as possible after December.
• I have read and filled out the Self-Review Questionnare on Security and Privacy. I can't think of any Security and Privacy issues related to this feature.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: CSSWG (Houdini TF).

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

Description:

The @property rule is briefly put a way to register a custom property in pure CSS.

For example, the two pieces of code (JS and CSS respectively) are equivalent, and result in exactly the same property registration:

CSS.registerProperty({
  name: '--x',
  syntax: '<length>',
  inherits: false,
  initialValue: '0px'
});

@property --x {
  syntax: "<length>";
  inherits: false;
  initial-value: 0px;
}

Authors often just want make a custom property animatable, and having to resort to JS just for this is not always desirable or possible (e.g. JS may be disabled).

See also the amount of exceitement on the original proposal (reactions at the bottom of the first post).

Notable resolved issues:

• @property vs registerProperty
• @property in shadow trees

[hober]

Note to TAG colleagues: provisionally assigning to the same folks as #318 during triage. Please feel free to un-assign yourself. :)

[dbaron]

We just filed two issues; since it's not 100% clear what direction the spec was intending to go on those issues (especially 942) it would be useful to get responses to those before reviewing further (although it might be, depending on the response, that we don't have further comments).

[dbaron]

We (me @alice @hober @plinss) are looking at this in Cupertino.

We're happy with the responses to those two filed issues.

One thing @plinss was curious about is, given that all the @property rules are separate from the registerProperty data, it seems like there's no API for getting the set of things registered via @property... or for that matter, the set of things registered at all. We were wondering if maybe there should be.

Our understanding is that the current model is that @property doesn't have any effects until computed value time. I recall a bunch of issues with the previous model -- and it does seem like a reasonable way out, so I think we're OK with this. Though we'd like to double-check that our understanding of the situation is correct.

So at this point I think we're happy to close this issue.

[andruud]

Thank you for the review. :-)

there's no API for getting the set of things registered

I don't think anything prevents us from adding that in the future if we need it.

Our understanding is that the current model is that @Property doesn't have any effects until computed value time. I recall a bunch of issues with the previous model -- and it does seem like a reasonable way out, so I think we're OK with this. Though we'd like to double-check that our understanding of the situation is correct.

That's correct, but note that the same actually applies to registerProperty. (It's true that in an earlier iteration of the spec, registerProperty would have an effect on non-computed-value-time APIs, but that was dropped due to the "bunch of issues". See also w3c/css-houdini-drafts#902)

[plinss]

there's no API for getting the set of things registered

I don't think anything prevents us from adding that in the future if we need it.

Aside from general developer ergonomics I don't see a need for that API just yet. The question came up in the context of wondering if such an API would include @property registrations or would be exclusive to properties registered via registerProperty. Given that the API doesn't exist, we don't need to answer that at this point.