[csswg-drafts] [css-anchor-position-1] `CSSTryRule.style.setProperty` can set disallowed properties in a `@try` rule (#9042)

xiaochengh has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-position-1] `CSSTryRule.style.setProperty` can set disallowed properties in a `@try` rule ==
The [spec](https://drafts.csswg.org/css-anchor-position-1/#fallback-rule) currently blocks disallowed properties of a `@try` rule at parse time:

> The [`@try`](https://drafts.csswg.org/css-anchor-position-1/#at-ruledef-try) rule only accepts the following [properties](https://drafts.csswg.org/css-cascade-5/#css-property):
> - [inset properties](https://drafts.csswg.org/css-logical-1/#inset-properties)
> - [sizing properties](https://drafts.csswg.org/css-sizing-3/#sizing-property)
> - [box alignment properties](https://drafts.csswg.org/css-align-3/#box-alignment-properties)

However, with the CSSOM API, we can still smuggle a disallowed property into a `@try` rule, and then completely break position fallback:

```js
tryRule.style.setProperty('position', 'static');
```

Proposal:

We should also block the disallowed rules at used value time.  In paticular, in step 2.1 of the [determine the position fallback styles](https://drafts.csswg.org/css-anchor-position-1/#determine-the-position-fallback-styles) algorithm, change

> Apply the styles in *fallback styles* to *el*

into

Apply the values of the properties that are accepted by `@try` rules in *fallback styles* to *el*

---

This issue is not entirely new, but existing ones don't cause issues other than changing the result of `cssText`. For example:
- `CSSFontFaceRule.style.setProperty` can add an unrelated property (e.g., `color`) into a `@font-face`, which however doesn't do anything
- `CSSKeyFrameRule.style.setProperty` can add an important declaration into a keyframe. However, it's treated as a normal declaration in the cascade because there's no important animation origin

However, allowing `position` in a `@try` rule completely breaks positioned layout.

There's currently no mechanism to stop `CSSStyleDeclaration.setProperty` from setting a property based on the parent rule type. An alternative solution is to patch it there, but I don't think it's a good idea to modify a long-established spec for this new feature.

And it seems generally safer (and less work to do) to just follow the exsting pattern: disallowed declarations can be added, but they won't do anything.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9042 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 7 July 2023 01:36:33 UTC