- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Apr 2025 13:30:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-align] `justify-items` and block splitting inline``, and agreed to the following: * `RESOLVED: if parent is inline, then justify-self:auto computes to normal` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> oriol: when justify-self:auto, spec says it should resolve to the value of justify-items of the parent box<br> <TabAtkins> oriol: there's one exception - when finding the position of an abspos item<br> <TabAtkins> oriol: this implies that "parent box" means containing block<br> <TabAtkins> oriol: with one exception - a block inside an inline. the inner block splits the inline<br> <TabAtkins> oriol: and the inline does not establisha containing block<br> <TabAtkins> oriol: so from which element should we take justify-items, if any?<br> <TabAtkins> oriol: taking it from parent inline seems weird to me<br> <TabAtkins> oriol: so not fond of the current spec text<br> <TabAtkins> oriol: another otpion is taking it from the CB<br> <TabAtkins> oriol: or Ian mentioned saying that, currently jsutify-items applies to all elements, we can say it doesn't apply to inline elements<br> <TabAtkins> oriol: so if the parent is inline, we'd treat justify-self:auto on the child as "normal"<br> <TabAtkins> oriol: no strong opintion, i think spec just didn't consider the case<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: you're right the spec didn't consider this case<br> <TabAtkins> fantasai: i think the intent of "look at the parent" was to do something simple<br> <TabAtkins> fantasai: which is why we didn't look at the CB<br> <TabAtkins> fantasai: two things that shoudl remain true are...<br> <TabAtkins> fantasai: i think we need to ignore anonymous boxes for this purpose<br> <TabAtkins> fantasai: for flex and grid they need to look at their parent, for abspos they dont' look at anything<br> <TabAtkins> fantasai: for here, probably shoudl do whatever is simplest<br> <TabAtkins> fantasai: whether it's look at parent element (doable during style resolution) or look at something else<br> <TabAtkins> q+<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: agree with fantasai , we should do the simple thing<br> <fantasai> TabAtkins: block-splitting-inlines are weird<br> <fantasai> TabAtkins: I would compute to normal, i.e. it doesn't take from it's parent if its parent is inline<br> <fantasai> TabAtkins: seems like easiest thing to do<br> <florian> q+<br> <astearns> ack florian<br> <TabAtkins> florian: in agreement, the msot intuitive thing is to walk up the tree until you find a block<br> <TabAtkins> florian: but this is a weird situation and doesn't really matter, so going to "normal" seems fine too<br> <iank_> i'd prefer "normal"<br> <TabAtkins> astearns: so proposed resolution from Tab is to have "auto" compute to "normal" if the parent is inline<br> <TabAtkins> oriol: i'm fine. not sure if it's actually simpler or not, in Servo we have the style fo the CB but not necessarily the parent. This sounds good to me tho<br> <TabAtkins> astearns: and interpreting Ian's comment as agreeing with TAb<br> <TabAtkins> astearns: objections?<br> <TabAtkins> florian: so this happens at style resolution time, right? so the fact that the inlne box isn't a parent of the block box at tree-building time doesn't matter, correct?<br> <TabAtkins> iank_: incorrect, i think we're the only one that *does* respect the parent/child relationship (we get filters correct, for example)<br> <TabAtkins> iank_: but i don't think it actually matters that much for this<br> <TabAtkins> astearns: so objections again?<br> <TabAtkins> RESOLVED: if parent is inline, then justify-self:auto computes to normal<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11462#issuecomment-2769372616 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 April 2025 13:30:46 UTC