- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Sep 2020 16:16:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-logical] Mapping of logical values in 'resize'`, and agreed to the following: * `RESOLVED: have the logical value of resize that of the element itself` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-logical] Mapping of logical values in 'resize'<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3281<br> <dael> oriol: The thing is that as css logical spec added logical values for existing properties. For each question of if they should resolve using writing mode of element or its containing block<br> <dael> oriol: Some past resolutions on this. text-align we resolved we should use writing mode of element. Float and clear which effect element we use writing mode of containing block.<br> <dael> oriol: Question is on resize property<br> <dael> oriol: Impl don't agree with this.<br> <dael> oriol: FF doesn't obey previous resolutions. For float, clear, and resize they use writing mode of element.<br> <dael> oriol: They shipped<br> <dael> oriol: In Chromium I used containing block for these three properties but it's behind a flag<br> <dael> oriol: In issue fantasai provided some points to consider. resizing can effect size of box but also available space for contents. You can see it both ways and it's not clear which we pick<br> <dael> oriol: No strong opinion, just want to decide on something<br> <dael> Rossen_: Don't know if folks have read through 3 points from fantasai. Wanted to hear if there are strong opinions<br> <dael> florian: Weak opinion to favor element<br> <dael> TabAtkins: same<br> <dael> smfr: Any version where those are physical?<br> <dael> florian: Yeah, you can. Quesiton is when you say inline.<br> <dael> Rossen_: Also more inclined to element<br> <dael> Rossen_: Anyone who prefers to have inline refer to containing block?<br> <dael> Rossen_: Some of fantasai points are that layout and resize of element usually effect containing block and might make sense to have this as function of containing block. That's why other option is considered<br> <fantasai> I think I have a mild preference to containing block.<br> <fantasai> Use cases are things like sidebars and textarea<br> <dael> Rossen_: Still hear if we resize based on element's inline for same purpose I think that although this is layout effecting it makes sense to be element itself<br> <dael> smfr: Logical versions of overflow-x and -y? I can't find it.<br> <dael> florian: I think so.<br> <fantasai> https://www.w3.org/TR/css-overflow-3/#logical<br> <emilio> q+<br> <dael> smfr: Was thinking resize should match overflow.<br> <dael> oriol: Overflow uses element writing mode<br> <dael> smfr: Argument for resize to do same<br> <Rossen_> ack emilio<br> <dael> emilio: Did we decide...for float and clear computed value needs to be logical. What FF impl is these logical properties where logical value is computed to phsyical at computed time which doesn't work for containing block. Where we use writing mode of containing block computed value needs to be logical value<br> <dael> fantasai: Yeah. Value is always itself and never computes phsyical<br> <dael> emilio: Makes sense. Could effect inheritence<br> <dael> Rossen_: Obj to have the logical value of resize that of the element itself?<br> <dael> RESOLVED: have the logical value of resize that of the element itself<br> <fantasai> s/inheritance/inheritance, but most of these don't inherit/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3281#issuecomment-693512638 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 September 2020 16:16:59 UTC