- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Oct 2020 15:30:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `css logical properties ordering`, and agreed to the following: * `RESOLVED: inheritance of logical properties inherts the corresponding logical proeprty on the parent` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: css logical properties ordering<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3029<br> <TabAtkins> fantasai: Probably best to look at this diagram at the bottom<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/3029#issuecomment-712953765<br> <TabAtkins> fantasai: We've got a set of logical props and physical props<br> <TabAtkins> fantasai: So if we ltr parent and rtl child<br> <TabAtkins> fantasai: ltr parent has some set of properties on it that give it margins on either side<br> <TabAtkins> fantasai: and the child has specified "margin-start: inhert"<br> <TabAtkins> fantasai: So what does that mean<br> <TabAtkins> fantasai: From the parent's left margin (the parent's start) or the right amrgin (the child's start)<br> <myles> ```<br> <TabAtkins> fantasai: Currently impls map start/end to a physical side on the child, using the child's writing mode, then inherit from the parent's corresponding physical margin<br> <TabAtkins> fantasai: The other possible behavior, which is possibly better, is that the child inherits its start value from the start value of the parent<br> <myles> <div id="outer" style="padding-left: 20px padding-right: 30px;" dir="ltr"><br> <myles> <div id="inner" style="padding-inline-end: inherit" dir="rtl"></div><br> <myles> </div><br> <TabAtkins> fantasai: Note taht by the time we ahve computed values, which is what we inherit, the left&start margins are set to the same value, and the right&end are set to the same, regardless of how they were specified<br> <TabAtkins> florian: We don't have any property that is logical & inherited where this shows up without you explicitly saying 'inherit', right?<br> <TabAtkins> fantasai: Right, not so far.<br> <myles> q?<br> <TabAtkins> fantasai: But if we did, I suspect we'd want the start margin of the child to inherit from the start margin of the parent, not from the amtching physical side<br> <myles> q+<br> <TabAtkins> fantasai: That's my suspicion, at least<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <TabAtkins> fremy: That's also my assessment<br> <myles> q+<br> <TabAtkins> fremy: If you wanted to inherit the right margin, you'd have said "margin-right". If you say margin-start, you want the start margin<br> <TabAtkins> fremy: If you had text-indent, you want the text-indent value, whether it's ltr or rtl.<br> <astearns> ack myles<br> <TabAtkins> myles: We're positive on this change to have the writing mode resolved based on the parent, not the child, for inheritance<br> <TabAtkins> myles: Two reasons for this<br> <TabAtkins> myles: fremy gave an argumen tfrom the author's perspective<br> <TabAtkins> myles: But i think the user wants it too - if they're reading a book where paragraphs have a padding on one side, and one paragraph is on a different side, the padding should probably flip sides<br> <TabAtkins> s/on a different side/has a different wm/<br> <TabAtkins> myles: Second is that it makes logical props more of a first-class citizen<br> <TabAtkins> myles: This means inheritance doesn't "prefer" physical props, you inherit what's specified<br> <TabAtkins> myles: That's good for the world and authors, but also good for impls<br> <TabAtkins> myles: Right now our code is a little more complicated than it could be to make it prefer physical props<br> <fantasai> s/specified/specified, so that logical properties are more of a first-class citizens/<br> <TabAtkins> astearns: I'm assuming, r12a, that you're okay with this proposal?<br> <fantasai> /citizens/citizen/<br> <TabAtkins> r12a: Yes, I think I suggested this in the first place, so I'm happy with it<br> <emilio> q+<br> <astearns> ack emilio<br> <TabAtkins> proposed resolution: inheritance of logical properties inherts the corresponding logical proeprty on the parent<br> <TabAtkins> emilio: A bit skeptical that this is easier to implement. you only store one value in the computed style, a physical one<br> <TabAtkins> emilio: So this breaks some computed-style optimizations<br> <myles> qq+<br> <TabAtkins> emilio: When two props map to one value, you have to choose one or the other, and right now impls agree with using the physical one, which they store in the style<br> <TabAtkins> emilio: So this means you have to add a pass after applying declarations, to know if your writing mode is different, you should inherit them differently<br> <TabAtkins> astearns: So you're saying the impl may be more difficult than stated, but are you objecting?<br> <astearns> ack myles<br> <Zakim> myles, you wanted to react to emilio<br> <TabAtkins> emilio: I think it woudl be unfortunate, especially given current interop, but I dont' think I have an objection until I try to implement and it's gross<br> <TabAtkins> myles: So you mentioned that we only store one set of values. That's true; netiehr proposal requires us to store multiple values<br> <TabAtkins> emilio: Right, but when you inherit a style you have a coypable part of the style which is what inherits<br> <TabAtkins> emilio: All impls separate inherited data and non-inherited<br> <TabAtkins> emilio: So if any of them come from a logical prop, you'll need to do the work and inherit it specially with the writing mode of the parent<br> <TabAtkins> emilio: So it breaks the simple "pointer bump" impl<br> <TabAtkins> myles: I agree that would be an issue if this was a common thing<br> <TabAtkins> emilio: Right. So I think maybe your'e just moving a special case from on eplace to another, but...<br> <TabAtkins> astearns: So, any objections?<br> <myles> q?<br> <TabAtkins> RESOLVED: inheritance of logical properties inherts the corresponding logical proeprty on the parent<br> <TabAtkins> <br until=":30"><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3029#issuecomment-715414021 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 October 2020 15:30:34 UTC