- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2020 11:24:37 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Line grid and tests`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Line grid and tests<br> <TabAtkins> ScribeNick: TabAtkins<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/938#issuecomment-575499518<br> <TabAtkins> koji: we discussed quite a bit on issues for rhythm sizing last time two years ago<br> <TabAtkins> koji: as far as i understand, this issue was the most blocking for the feature<br> <TabAtkins> koji: Since then, Blink shipped LayoutNG. I didn't reimplement this in LayoutNG yet.<br> <TabAtkins> koji: Currently this test fails in all browsers.<br> <TabAtkins> koji: I don't see a way to solve this properly<br> <TabAtkins> florian: We talked about multiple solution for the double-sizing. What is the test assuming?<br> <TabAtkins> koji: We just have tests for rhythm-sizing in general.<br> <TabAtkins> florian: We have a spec, and tests; you fail because you don't ipmlement. That's normal, right?<br> <heycam> fantasai: what are the tests for? there's block step sizing and line step sizing<br> <TabAtkins> fantasai: Were the tests for block step sizing, or line step sizing?<br> <TabAtkins> koji: line step sizing<br> <TabAtkins> koji: Question isn't about that, tho. I have to admit that I've got not great confidence on how I understand this accidental double-spacing issue.<br> <rego> are these the tests? https://wpt.fyi/results/css/css-rhythm?label=experimental&label=master&aligned<br> <TabAtkins> koji: But if I understand correctly, florian and astearns consider this a critical blocking issue.<br> <TabAtkins> koji: From my perspective, any solution can't avoid accidental double-spacing in some cases.<br> <astearns> q+<br> <TabAtkins> koji: So if we say accidental double-spacing fundamentally breaks the feature, we're basically saying CSS won't have this feature. Is that correct?<br> <TabAtkins> florian: Problem here is we want a vertical rhythm where the lines are the same size, and what to do when you can't have that.<br> <TabAtkins> florian: So either you break the rhythm and let some lines get bigger, or you double size the line to keep the rhythm.<br> <TabAtkins> florian: Can't avoid one or the other. What you can avoid is double-size when you don't need them to be.<br> <TabAtkins> florian: So if we have a mode where we double-size some of the time, making sure it doesn't happen gratuitiously, or in a brittle UA-dependent way, is the essential issue.<br> <TabAtkins> florian: So it's not "we can never have double sizing", it's "we have to be careful and make double-sizing happen consistently and predictably"<br> <tantek> rather than "that would be bad", can you state the desired fallback behavior?<br> <TabAtkins> hober: Isn't there a third option?<br> <TabAtkins> hober: Enforce the rhythm, and let the line overlap slightly.<br> <TabAtkins> florian: I think it's a bad one, but yes.<br> <TabAtkins> hober: I think some would prefer that.<br> <TabAtkins> florian: Circling back to koji's question, we ahve multiple specs addressing this problem.<br> <TabAtkins> florian: My feeling is that the most realistic part of this story is block-step-sizing; easiest and least brittle.<br> <fantasai> TabAtkins: Not going to break your layout if all your blocks are slightly larger in one browser than another<br> <fantasai> TabAtkins: but very broken if every line is double-spaced<br> <fantasai> faceless2: This only applies when line-height is normal?<br> <TabAtkins> faceless2: This only applies when line-height is normal, correct?<br> <TabAtkins> florian: Different concepts here. block-step-sizing ahs the problem without line-height.<br> <TabAtkins> florian: So they overlap to varying degrees.<br> <TabAtkins> fantasai: I think neither of these specs should be actively tested or implemented yet; I don't think we have great consensus on this as the correct solution yet.<br> <TabAtkins> fantasai: block-step-sizing doesn't have this sensitivity to inline layout or font rendering.<br> <TabAtkins> fantasai: So I think we could point to a wpt revision that had those tests, but I don't think we shoudl highlight failures before we have agreement on the concept at all.<br> <astearns> q?<br> <TabAtkins> fantasai: I think we need to handle font fallback in a more robust way. I think there's a lot of work to do to solve rhythmic sizing well, and a lot of that is solving inline layout problem generally.<br> <TabAtkins> koji: We could just set line-height and it works, tho.<br> <TabAtkins> fantasai: Right, but baseline-to-baseline spacing is still inconsistent.<br> <TabAtkins> fantasai: So because we have this discrepancy, almost all the time we trigger the double-spacing.<br> <TabAtkins> fantasai: So we want to clear this up, make the lines naturally rhythmic, so then when we need to *interrupt* the rhythm with something significantly different we can invoke rhythmic sizing.<br> <TabAtkins> koji: True for Latin, I don't think it's true for CJK.<br> <faceless2> q+<br> <TabAtkins> koji: Really just want to know if we should even be thinking about imlementing right now.<br> <TabAtkins> fantasai: I don't think so, no. If you remove those tests, drop a link to the last revision with them into the spec.<br> <TabAtkins> koji: Ok. But even block sizing has these problems too.<br> <TabAtkins> fantasai: I don't think so, no. rhythmic sizing *will* increase the size of blocks sometimes.<br> <TabAtkins> koji: We will have the same problems as text tho.<br> <TabAtkins> florian: How?<br> <TabAtkins> TabAtkins: If we have rendering differences in line heights, and the block height is based on text content, we'll have the same UA-dependent differences!<br> <TabAtkins> florian: If you size with lh unit, then...<br> <TabAtkins> florian: Really my issue is just about line-step-height. I don't think it's about block-step-height, but if you think there is, go ahead and open an issue about that.<br> <Rossen__> ack astearns<br> <TabAtkins> astearns: Elika went over a bit of my comment, but if th efeature isn't in active dev, I think it's perfectly fine to remove tests from WPT. I just approved a PR to remove all the Regions tests for this reason.<br> <TabAtkins> astearns: I'd prefer if there *was* active development - I don't think this issue is a blocker to doing work at all.<br> <TabAtkins> koji: So I hear consensus to remove the tests, and add warning to line-height-step and line-grid; block-step is fine.<br> <Rossen__> ack faceless2<br> <TabAtkins> faceless2: RealObjects have implemented this; I can't speak for how well.<br> <Rossen__> ack fantasai<br> <Rossen__> ack faceless<br> <TabAtkins> faceless2: AH have an implementation as well.<br> <TabAtkins> faceless2: We've got it too.<br> <TabAtkins> faceless2: I think this is all about the differences in what line-height:normal means between impls.<br> <Rossen__> q?<br> <TabAtkins> TabAtkins: I'll note that the ".tentative" substring in the filename is designed for this - tests that shouldn't be considered normative yet, but are in development.<br> <TabAtkins> Rossen__: So current proposal is to remove tests, add warnings to line-height-step and line-grid.<br> <TabAtkins> myles: What will the warning say?<br> <TabAtkins> florian: In line-height-step it can link to this issue.<br> <TabAtkins> florian: For line-grid, there are concerns, but no issue yet.<br> <TabAtkins> astearns: I can add the warning.<br> <TabAtkins> astearns: "We haven't figured everything out yet, but don't try to ipmlement blind assuming it's stable. Please give feedback if you're okay with working on bleeding edge."<br> <fantasai> <br><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/938#issuecomment-577640685 using your GitHub account
Received on Thursday, 23 January 2020 11:24:39 UTC