- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Dec 2023 00:16:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-values-4] Resolve `<percentage>` representing `<number>` or `<angle>` at parse time``, and agreed to the following: * `RESOLVED: % that are resolved against numbers do that at parse time` <details><summary>The full IRC log of that discussion</summary> <dael> TabAtkins: Pointed out that while the spec says we simplify trees at computed and used time. There's significant browser interop at resolving percents of numbers at parse time. Calc(50%) in opacity and you read back immediately you get .5<br> <dael> TabAtkins: I don't have much of an opinion. I'm fine leaving spec as-is or with modifying spec to say % resolved against numbers are resolved at parse time. Either is okay with me, so question of what do browsers want to do<br> <dael> fantasai: Another relevent question is would authors have an opinion on it<br> <dael> TabAtkins: I've never heard anyone have an opinion. I haven't looked deeply, but haven't spotted it<br> <dael> fantasai: I think tend to keep specified values as specified. Ex a lot of color stuff could be at parse time, but we don't. Same with bg position stuff<br> <dael> astearns: If we decide we want that behavior is it likely that all the browsers will change their current code to adapt?<br> <dael> TabAtkins: Given I'm not seeing anyone say anything, I suggest we resolve to match browser behavior<br> <dael> florian: Only thoght against that direction is the more you preserve the easier it is for browser tools that work off OM. But not sure if we've followed that enough for it to be practical<br> <dael> TabAtkins: Agree. And if you want high quality you have to do it like dev tools<br> <dael> astearns: And there is now a dev tools API<br> <dael> TabAtkins: It is very important to get access to the invalid stuff and you cannot get it from the OM. I'm not super symathetic to needing values for an editor concern. Author surprise would be different, but I don't see that.<br> <dael> fantasai: Situation is we're kind of inconsistent where some things can resolve and some can't?<br> <dael> astearns: For things that do resolve against a number, only exception is filter arg.<br> <dael> florian: That suggests it's reasonable<br> <dael> TabAtkins: Can drop some tests and highlight that filter effect needs a change<br> <dael> fantasai: Just put a warning where you write the thing that it's not always going to resolve like line-height<br> <florian> s/That suggests it's reasonable/Anyway, I think Tab's suggestion is reasonable.<br> <dael> astearns: An example of something that looks like it would work but doesn't would be reasonable to put in spec<br> <dael> TabAtkins: I think line-height is most reasonable thing. Good idea<br> <dael> astearns: Prop: % that are resolved against numbers do that at parse time<br> <dael> astearns: And we'll have an example of something that doesn't quite fit the pattern and we'll add wpt for this<br> <dael> astearns: Obj?<br> <dael> RESOLVED: % that are resolved against numbers do that at parse time<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9395#issuecomment-1843924568 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 December 2023 00:16:09 UTC