- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2020 21:59:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `vertical-align on ruby bases`. <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: vertical-align on ruby bases<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4987<br> <TabAtkins> florian: verticla-align on ruby bases, shoudl it do something?<br> <TabAtkins> florian: dbaron suggested a while back that it shoudln't<br> <TabAtkins> florian: This simplifies things later<br> <TabAtkins> florian: And afaict, no use-case for it having an affecting<br> <TabAtkins> florian: There's use-cases for aligning, but seems that selecting dominatn baseline works there<br> <TabAtkins> xidorn: Currently in FF it's implemented differently<br> <TabAtkins> xidorn: I think dbaron's point is that vertical-align would affect height of the base container<br> <TabAtkins> xidorn: An alternative is to say base container's size is based on ruby base *without* ver4tical-align applied<br> <TabAtkins> xidorn: Because vertical-align needs to apply only after line is fully laid out, otherwise you don't know where things hsould be<br> <TabAtkins> xidorn: So when drawing ruby you're still in progress of laying out line, so yo udon't know where it ends up anyway<br> <TabAtkins> xidorn: So I think we can just say base container ignores the base's vertical-align for sizing<br> <TabAtkins> florian: Then ver4tical-align just visually shifts it at the end?<br> <TabAtkins> xidorn: Yes. Taht's what ff currently does, doesn't seem to create lots of complexity\<br> <TabAtkins> florian: I think i'm okay either way<br> <TabAtkins> stantonm: I've never seen it in ebooks<br> <TabAtkins> Rossen_: So sounds like added complexity overall. Implemented in ff, but no real content use-cases. Perhaps we could skip?<br> <koji> q+<br> <TabAtkins> xidorn: I think FF's way isn't adding impl complexity.<br> <TabAtkins> xidorn: Makin it not do that would need some actual code to turn it off.<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: What do yo umean by "vertical-align doesn't apply", it always applies?<br> <TabAtkins> florian: EVerything besides "baseline" value<br> <TabAtkins> fantasai: How's that different from any other value?<br> <TabAtkins> florian: They'd all shift together<br> <TabAtkins> fantasai: Not if they're different font sizes<br> <TabAtkins> fantasai: Two parts to vertical-align: what you're alinging, and what you're aligning to<br> <TabAtkins> fantasai: Could say baseline-shfit doesn't apply<br> <TabAtkins> fantasai: But that creates a discrpeancy<br> <TabAtkins> dbaron: I think elika's right, it's probably simplest to just say that vertical-align happens at the end, and still have all the existing rules to say what aligns to what<br> <fantasai> s/discrpeancy/discrepency, where we are already dealing with differing positions/<br> <TabAtkins> koji: Having trouble understanding the proposed resolution<br> <TabAtkins> koji: Haven't tested our impl yet. But if this doesn't have use-cases and there's no compat issues, is it reasonable to not define this in level 1?<br> <TabAtkins> Rossen_: My question was mostly if there are use-cases you're aware of<br> <TabAtkins> koji: None that i know<br> <TabAtkins> Rossen_: But also not disagreeing with elika and dbaron that this could just be a last step<br> <TabAtkins> Rossen_: You could wrap it in an inline-blcok and align it that way<br> <Rossen_> ack koji<br> <TabAtkins> fantasai: REal problem here is the top and bottom values, which are relative to the whole line<br> <TabAtkins> fantasai: Doesn't make a lot of sense for a base to align to the top of the line<br> <TabAtkins> fantasai: If we could say that those values are treated as baseline or something, that would be fine<br> <TabAtkins> fantasai: But everything else is fine; you're *always* vertical aligning text in a line<br> <Rossen_> ack fantasai<br> <TabAtkins> dbaron: And it needs to be clear that the anno moves with the base<br> <heycam> q+<br> <TabAtkins> xidorn: In verticla-align case, the anno doesn't move with the base. The anno is part of the anno container, it doesn't move with the base itself<br> <TabAtkins> florian: The position of the anno does dpend on where the base ends up being, unless we make an exception here to say that v-a is a visual thing<br> <TabAtkins> heycam: elika, you said v-a:top doesn't make sense.<br> <Rossen_> ack heycam<br> <TabAtkins> heycam: What if you wrap that on a span, is that equally nonsensical?<br> <TabAtkins> fantasai: I think v-a on a span around and on the container itself, don't see why that shouldn't work.<br> <TabAtkins> fantasai: Probably need some dfn for it tho<br> <TabAtkins> fantasai: But v-a:top on the *base* doesn't make sense, can't shift the base to the top if it has stuff on top of it that's supposed to grow the line<br> <TabAtkins> fantasai: So we probably want to define what edges are used for aligning the ruby container<br> <koji> q+<br> <dbaron> q+<br> <TabAtkins> fantasai: For for bases, just want to apply it as normal, except that top/bottom/center (which are all relative to the line itself, not relative to the baseline) should be treated as 'baseline'<br> <TabAtkins> heycam: And what about v-a on an anno?<br> <TabAtkins> fantasai: I think they should align with respect to each other<br> <TabAtkins> florian: So no motivation for making it work, tho<br> <TabAtkins> fantasai: MOtivation is that, if it doesn't work, that's a special exceptional behavior already<br> <TabAtkins> fantasai: And you *still* have to vertical-align *anyway*. You can't not do that. "Removing it" is just preventing you from *altering* the alignment.<br> <Rossen_> ack koji<br> <TabAtkins> koji: Reason I prefer not defining v-a is that our current impl is pretty similar to wk, and in our layoutNG one, we're treating ruby base more similar to inline-block than inline.<br> <TabAtkins> koji: We wanna preserve our flexibility to make it more like inline boxes in the future<br> <TabAtkins> koji: If we make that change, this will affect how v-a works<br> <TabAtkins> koji: So unless there's an author need or compat issue, would prefer not to define this<br> <TabAtkins> florian: Reason I'm concered with not defining things, is that back to the first issue, there is a need for authors to control alignment and spacing.<br> <TabAtkins> florian: But if it works in some browsers, authors can depend on that, and we'll get frozen in behavior anyway. But v-a might not be that risky anyway.<br> <florian> q?<br> <Rossen_> ack dbaron<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to respond to koji<br> <Rossen_> q+ dbaron<br> <TabAtkins> fantasai: I think, to th eextent tha we can define where we intend to go, we should do that in level 1. Can mark it optional or at risk.<br> <TabAtkins> fantasai: But for people working on their impl or drafting from scratch, I think it's useful to know what we're aiming for, so they can make approparite decisions for the fruture.<br> <Rossen_> ack dbaron<br> <TabAtkins> dbaron: I'd add to that, since the beginning of this spec the idea is that ruby boxes act more like inlines than inline blocks. It was known at the time that this wasn't how Chrome/WK worked. We're N years down the path, and I'd prefer not to abandon that path over this issue.<br> <TabAtkins> dbaron: In response to elika's comment about v-a<br> <TabAtkins> dbaron: Talking about top/bottom/center, CSS2 has the idea of "aligned subtree", which defines what set of stuff that top/bottom/center *is*<br> <TabAtkins> dbaron: May want to adjust the dfn to include ruby annos, or might not. But should make it clear.<br> <TabAtkins> fantasai: agree<br> <fantasai> myles: Wrt 6 yrs ago Chrome / WebKit...<br> <TabAtkins> myles: In response to dbaron, we're interested in changing our impl to more closely align with the ruby spec<br> <fantasai> myles: We are interested in changing our impl to more closely align with CSS Ruby<br> <TabAtkins> florian: So do we have a proposed reoslution?<br> <TabAtkins> Rossen_: Hearing that v-a on ruby base/anno is independent of the container<br> <TabAtkins> dbaron: I think it's different fro different ruby parts<br> <dbaron> dbaron: we've been talking about bases<br> <TabAtkins> Rossen_: So let's scope to base. vertical-align affects bases same as any other inline box.<br> <TabAtkins> fantasai: Except top/bottom/center are treated as baseline<br> <TabAtkins> xidorn: Can we leave that unspecified?<br> <TabAtkins> koji: Is that due to current impls?<br> <TabAtkins> fantasai: All of the other values align the box wrt the line.<br> <TabAtkins> fantasai: But top/bottom/center align with respect to the line box.<br> <TabAtkins> florian: For the other values, you align things wrt each other, then wrap a line around them.<br> <TabAtkins> florian: For these three, you have to figure out th eline box, then shift relative to it.<br> <AmeliaBR> A test case if people want to look at what browsers currently do… https://codepen.io/AmeliaBR/pen/c3d360bb400822287b2650f607d66fec<br> <dbaron> dbaron: I'm not convinced there's circularity for top/bottom/center.<br> <TabAtkins> fantasai: And then the anno moves, changing the line size<br> <TabAtkins> xidorn: But the anno doesn't move<br> <TabAtkins> fantasai: For the other values it does need to mvoe tho<br> <TabAtkins> Rossen_: Xidorn says it doesn't move for any of the values, it's like relpos<br> <TabAtkins> fantasai: I disagree with that behavior<br> <TabAtkins> dbaron: Another proposal: v-a affects ruby bases like other inline boxes. We open another issue on top/bottom/center to deal with those.<br> <TabAtkins> florian: I don't disagree, but it doesn't answer Xidorn's question - layout or paint time?<br> <TabAtkins> fantasai: I think it should work by laying out the boxes, aligning them, draw the base container aroudn the aligned text. It can't work any other way<br> <TabAtkins> fantasai: Things shift relative ot each other based on teh dominant baseline anyway, no reason to not let v-a do the same<br> <TabAtkins> xidorn: ruby anno is positioned based on the base container and anno container base. *not* on specific bases.<br> <TabAtkins> xidorn: So that makes me thing v-a on the base shouldn't affect the anno position.<br> <TabAtkins> fantasai: So when doing layout, ignoring v-a. If you have three bases, all different sizes, you have to align them.<br> <koji> q+<br> <TabAtkins> fantasai: Then you have to draw a ruby base container. Which box do you draw around? All of them? Or all of them?<br> <TabAtkins> fantasai: Whichever, no reason not to v-a there too<br> <TabAtkins> dbaron: I think someobody needs to write down the steps for this<br> <TabAtkins> dbaron: In terms of sizing and positioning base container vs anno container, etc<br> <koji> q-<br> <TabAtkins> xidorn is also signing up<br> <dbaron> I wonder if we should continue the ruby issues on a more-APAC-timed call?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4987#issuecomment-622138320 using your GitHub account
Received on Thursday, 30 April 2020 21:59:55 UTC