- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 25 Jun 2025 16:08:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom][css-position] Resolved value of over-constrained percentages in inset properties`, and agreed to the following: * `RESOLVED: Overconstrained insets return their used value prior to adjusting for the overconstraint` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> (7 years ago!)<br> <TabAtkins> oriol: CSSOM, when ti's defining the resolved value for t/r/b/l<br> <TabAtkins> oriol: it says that if the property is over constrained, the resolved value is the computed value<br> <TabAtkins> oriol: that's a problem with relative positioning<br> <TabAtkins> oriol: with relpos you can only set one of them in a given axis<br> <TabAtkins> oriol: if you set left and right, only one works, the other is ignored<br> <TabAtkins> oriol: so it's over constrained. per spec, you get the computed value<br> <TabAtkins> oriol: but if the value is a %, then no browser gives the %. they all just resolve it to a px<br> <TabAtkins> oriol: so i had a proposed change in the issue<br> <TabAtkins> oriol: if the element is not positioned, or computed value is a length, resolved value is computed value<br> <TabAtkins> oriol: othewise, if proeprty is not over constrained, resolved value is used length<br> <TabAtkins> oriol: otherwise, resolved value is the length that would result from resolving the computed value, handling the over-constrainment<br> <TabAtkins> oriol: i think this matches browsers and covers cases<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask why we have this condition, and if we can remove it<br> <dbaron> I'd replace "over-constrainment" with "over-constraint"<br> <TabAtkins> oriol: so if you're over-cosntrained, instead of returning computed value, you resolve the computed value as if it weren't over constrained<br> <dbaron> but otherwise I think the proposal sounds reasonable if it matches implementations<br> <TabAtkins> fantasai: so computing it thru to a used value but not handling the over-constrained adjustments, that makes sense<br> <TabAtkins> fantasai: consistent with the model in level 3. in level 2 we actually changed the value of the weaker inset, now we keep it and use alignment props to positioning within that space. so i think that's better.<br> <TabAtkins> astearns: so is that actually interoperable? any impls that differ?<br> <TabAtkins> oriol: well this is from 2018 and i haven't checked recently. but i believe it matched impls back then<br> <TabAtkins> astearns: i think we could resolve on "have the spec match impls, using what Oriol outlined in their second comment". is that good enough?<br> <fantasai> PROPOSED: Overconstrained insets return their used value prior to adjusting for the overconstraint<br> <TabAtkins> oriol: i guess that works, yeah<br> <TabAtkins> RESOLVED: Overconstrained insets return their used value prior to adjusting for the overconstraint<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3059#issuecomment-3005344400 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 June 2025 16:08:59 UTC