- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Apr 2024 16:28:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-anchor-position-1] Define `CSSPositionTryRule.style` as `CSSPositionTryProperties` ``, and agreed to the following: * `RESOLVED define a new interface type for position-try similar to how page descriptors are defined, with every allowed property included` <details><summary>The full IRC log of that discussion</summary> <chrishtr> TabAtkins: the CSSOM interface for position-try has a CSSStyleDeclaration object to hold the properties at present.<br> <emilio> q+<br> <chrishtr> TabAtkins: however, some similar @ rules like page rules, have been done by exposing the properties valid on it directly<br> <chrishtr> TabAtkins: do we want to follow that same pattern?<br> <chrishtr> TabAtkins: currrently only spec prose prevents exposing all CSS properties since the type allows it<br> <chrishtr> TabAtkins: but page rules only accepts the properties specified by what that spec accepts<br> <chrishtr> TabAtkins: should we go with the page rules approach and settle that as as a precedent as well for future patterns?<br> <TabAtkins> https://drafts.csswg.org/cssom/#the-csspagerule-interface<br> <chrishtr> TabAtkins the page rules object has a CSSPageDescriptors interface that explicitly lists the allowed properties<br> <chrishtr> emilio: page is different because there are some properties that don't exist in CSSStyleDeclaration<br> <chrishtr> emilio: a better comparison to try rules is keyframe rules, which disallow some properties<br> <chrishtr> TabAtkins: yes that's similar but since they exclude some of the properties and copying that mechanism could be annoying (?)<br> <chrishtr> emilio: prefer to be consistent with keyframe rules for consistency<br> <Rossen__> ack emilio<br> <chrishtr> emilio: if we did that then also future extensions to position-try would be more easily feature detectible<br> <chrishtr> dbaron: another thing to keep in mind is whether properties that do not apply in position try should be parsed and stored in the CSSOM object.<br> <chrishtr> dbaron: not sure whether this happens for animation properties in keyframes<br> <chrishtr> fantasai: seems unlike that developers will rely on whether these properties are stored on keyframes, so we could likely change that<br> <chrishtr> fantasai: think position try should be more like keyframes, because both apply to regular elements. but page descriptors are a special context that is not quite like visual display on the screen.<br> <chrishtr> emilio: don't want another interface with hundreds of properties on it just to prevent animation properties in keyframes, that seems not useful<br> <chrishtr> emilio: this would be a waste because there would be some basically useless generated code and spec to maintain<br> <fantasai> that's a fair point, dbaron<br> <chrishtr> dbaron: the part that is more like page descriptors than keyframes is that position-try has a short list of properties allowed whereas keyframes has a very long list<br> <chrishtr> emilio: that would be fine<br> <fantasai> s/visual display on the screen/regular box layout/<br> <chrishtr> TabAtkins: it seems people think that aligning with page descriptors makes more sense because it's a small subset of properties<br> <chrishtr> proposed resolution: define a new interface type for position-try similar to how page descriptors are defined, with every allowed property included<br> <chrishtr> RESOLVED define a new interface type for position-try similar to how page descriptors are defined, with every allowed property included<br> <Rossen__> s/RESOLVED/RESOLVED:/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10108#issuecomment-2047997941 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 April 2024 16:28:31 UTC