Re: [csswg-drafts] [css-inline-3] Shift top | bottom | center values from alignment-baseline to baseline-shift (#5180)

The CSS Working Group just discussed `[css-inline-3] Shift top | bottom | center values from alignment-baseline to baseline-shift`, and agreed to the following:

* `RESOLVED: accept change as proposed by fantasai unless strong impl argument`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-inline-3] Shift top | bottom | center values from alignment-baseline to baseline-shift<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5180<br>
&lt;dael> fantasai: top bottom and center values. center is new, top and bottom have been since css 1.<br>
&lt;dael> fantasai: When we pulled in alignment-baseline and basline-shift we made them longhands for vertical-align<br>
&lt;dael> fantasai: Weren't sure what to to with top and bottom b/c don't spec baseline or a shift exactly. put under alignment-baseline.<br>
&lt;dael> fantasai: Seemed to make more sense to go under baseline-shift property. Alignment baseline is a concept that exists for a lot of other boxes but top and bottom don't have a meaning.<br>
&lt;Rossen_> q?<br>
&lt;dael> fantasai: I was thinking would make more sense on baseline-shift which is how much to shift afte ryou align. In which case we ignore baselines b/c top and bottom don't care. THey use top and bottom of align subtree<br>
&lt;dael> florian: PoV from insie element top and bottom values don't combine with either, they take over. From PoV of element reltationship with parents it does make sense to continue applying alignment-baseline even if top and bottom shifted. Am I getting that right?<br>
&lt;dael> fantasai: Yeah. Prob only case for both is table cells where top and bottom values trigger behavior on align-content. In that case if you have a table with a single table cell and if you veritical=align top the baseline still has a meaning to allowt able to align to. In which case we have to export a baseline so there's a meaning to having both values<br>
&lt;dael> fantasai: Within inline layout top and bottom has no ability to combine with aligned baseline or baseline shift.<br>
&lt;dael> florian: Another approach is from cascade and setting. Most of the time you set in shorthand. If set separate having some feeling that align-baseline is based on broad context and you could be doing this for whole doc but locally switch to top and bottom<br>
&lt;dael> florian: It's a good fit for neither, but I weak lean toward your proposal<br>
&lt;dael> AmeliaBR: What's our impl status? Are we asking impl to change shipped things or is all still new stuff adding extra vertical-align keywords<br>
&lt;dael> florian: I don't think impl have switched to long hands except in SVG which doesn't have these keywords.<br>
&lt;dael> fantasai: I don't think alignment-baseline is in FF<br>
&lt;dael> AmeliaBR: THat' smy only concern. If we're changing after something has shipped not worth changing. If nothing has shipped I agree with fantasai this makes more sense<br>
&lt;dael> florian: MDN doesn't seem to know these have shipped, but it has a ?<br>
&lt;dael> fremy: We can check<br>
&lt;dael> fantasai: I can't get FF to do anything with alignment-baseline<br>
&lt;dael> Rossen_: Doesn't sound like strong impl constraints<br>
&lt;dael> fremy: Not able to get FF to do something and I'm in FF dev.<br>
&lt;dael> florian: Alternative would be spawn another long hand but I'm not sure I'm excited about it<br>
&lt;dael> AmeliaBR: I suggested if these override both longhands but it gets confusing from cascade PoV<br>
&lt;dael> florian: It can't do something in the shorthand without doing something in long hand<br>
&lt;AmeliaBR> Confirmed that Chromium doesn't support these keywords in alignment-baseline<br>
&lt;dholbert> according to this code, alignment-baseline is indeed not currently supported in Firefox: https://searchfox.org/mozilla-central/rev/eef39502e08bcd3c40573c65a6827828dce4a032/dom/svg/SVGElement.cpp#974-975<br>
&lt;dael> fantasai: Values are mutually exclusive with baseline-shift. You can't do shift and do top and bottom. B/C mutually exclusive might as well be same property<br>
&lt;dael> fantasai: Does anyone have other comments or should we accept and move on? There's arguments in favor of change and none against<br>
&lt;dael> dbaron: Seems only sort of exclusive. You can do top and down but not top and up<br>
&lt;dael> faceless2_: Spec says you can't combine them<br>
&lt;dael> florian: Browsers haven't impl syntax. But even if they did does it mean anything?<br>
&lt;dael> fantasai: Can't really combine. If you want to shift there's a lot of other ways.<br>
&lt;dael> dbaron: Okay with it. Makes sense to forbid it<br>
&lt;dael> Rossen_: Seems like leaning toward forbidding it.<br>
&lt;dael> Rossen_: astearns pointed out....<br>
&lt;dael> florian: Have clarity, but not enthusiasm. Everyone leaning in that direction<br>
&lt;faceless2_> Test: https://jsbin.com/hodevav/edit?html,output<br>
&lt;dael> AmeliaBR: Resolve to accept change as proposed by fantasai unless strong impl argument?<br>
&lt;dael> Rossen_: That's the proposal, yes<br>
&lt;dael> Rossen_: Objections?<br>
&lt;dael> RESOLVED: accept change as proposed by fantasai unless strong impl argument<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5180#issuecomment-645471523 using your GitHub account

Received on Wednesday, 17 June 2020 16:14:13 UTC