- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 14:52:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-text] Reconsidering the CSS letter-spacing model`, and agreed to the following: * `RESOLVED: add this new method of letter spacing with line-edge trimming, with a note saying we're trying this out and will come back with compat data` <details><summary>The full IRC log of that discussion</summary> <emeyer> jfkthame: We've talked about letter-spacing before, but never made progress<br> <dbaron> ScribeNick: emeyer<br> <emeyer> …Current situation: browxser all implement letter-spacing by adding extra width to every character<br> <emeyer> …But inconsistently: Safari does it to the right, FF to the framing box of each character<br> <emeyer> …Neither is good, as the issue shows<br> <dbaron> s/Safari does/Blink and WebKit do/<br> <dbaron> s/FF to the framing box/FF to the inline-end side/<br> <emeyer> …For RTL text, the Blink implementation isn't good, but Gecko isn't good for mixed directions<br> <emeyer> …The spec implements something difference<br> <emeyer> …A few years ago, the compat risk of changing the behavior was felt to be too great<br> <florian> q+<br> <emeyer> …So we should take a different direction than the spec<br> <emeyer> …We should make letter spacing symmetrical instead of all on one side<br> <astearns> ack emilio<br> <emeyer> …That removes all the problems that current implenetations have, and the bidi issues that make it all ugly<br> <emeyer> …Because there's null effect on the overall layout, the compat risk is much lower than doing what the spec currently describes<br> <astearns> q+<br> <emeyer> …There are a many ideas and syntax proposals in the issue, but that's a little different than whether or not we should address the underlying problem by adopting symmetrical expansion<br> <emeyer> …A font designer asked for looser tracking would expand to both sides of characters, not all to one side<br> <emeyer> …Another point is that a couple of months ago we enabled this in FF Nightly<br> <jfkthame> https://bugzilla.mozilla.org/show_bug.cgi?id=1892262<br> <emeyer> …We've gotten a couple of bug reports<br> <dbaron> s/A font designer/If a font designer/<br> <emeyer> …See the screenshots in the linked bug report for some fascinating approaches<br> <iank_> q+<br> <florian> q- later<br> <emeyer> …I'm curious if other engines are willing to consider this change<br> <emilio> q-<br> <dbaron> (I feel like that's what 10% of OTP fields look like already!)<br> <emeyer> astearns: In terms of line-start and line-end spacing, I'm surprised trimming this at line-start is an optional thing<br> <emeyer> jfkthame: I’m not sure I understand why you'd get a ragged left edge<br> <emeyer> astearns: If you applied letter spacing to a range inside a paragraph, and any characters were at the beginning of a line, that would create raggedness<br> <emeyer> jfkthame: I suspect in practice that spacing used on a range within a paragraph would be small<br> <emeyer> astearns: Is the trimming at the line edges a factor in the web compat problems that were seen with the spec?<br> <emeyer> jfkthame: I think that's one issue<br> <dbaron> jfkthame: trimming at the line edges would mean that you would affect the overall layout<br> <emeyer> …The bigger issue is probably that authors assume they can wrap every character in a span, apply spacing, and get a result<br> <emeyer> astearns: To your point of applied letter-spacing being small, I think German emphasis has relatively high letter spacing<br> <dbaron> astearns: ... and is applied to spans in paragraphs<br> <emeyer> jfkthame: Okay, I've not seen that as a problem in practice but I can see it could be an issue<br> <astearns> ack astearns<br> <astearns> ack iank_<br> <emeyer> …I'm not sure whether having the space at the beginning of a line would be seen as bad or a natural consequence<br> <emeyer> iank_: Might have been koji who was in the original assessment, but the bug report breaking Zoom would make me very nervous to ship this<br> <emeyer> …If we got a couple of breakages on major sites in Canary, we wouldn't ship this<br> <emeyer> …The fact that it's breaking stuff in Nightly for you make me very nervous here<br> <emeyer> …That said, if you can work with Zoom to fix, I'd be less nervous<br> <astearns> trimming at line-start would fix the zoom issue<br> <emeyer> jfkthame: If you can ship this in Canary, Zoom would probably be more likely to fix it<br> <emeyer> dbaron: Having worked on both FF and Chrome, the FF bug reporting ratio between Nightly and stable is substantially different than Canary/Chrome<br> <emeyer> …Getting that level of bug reporting on FFNightly seems a much weaker signal to me than it would be on Canary<br> <astearns> ack florian<br> <Zakim> dbaron, you wanted to react to iank_ to respond to Ian about breakage<br> <emeyer> florian: I continue to think the currently specced behavior is better<br> <emeyer> …But if that's impossible, this is probably better than what's currently shipped, so I'd like to explore this<br> <kizu> q+<br> <emeyer> …Maybe addressing Alan's concern about trimming line edges would help<br> <emeyer> …It would vary text metrics a little bit, but these sorts of things are already dangerous and not very realiable<br> <emeyer> …Keeping the current behavior as an opt-in would be nice as I think it's better, but what's shipping now is bad<br> <astearns> ack fantasai<br> <emeyer> fantasai: My recollection is that people tend to hack around the trailing-space problem by putting in negative stuff to compensate<br> <emeyer> …My concern is the pages that care too much are the most likely to break<br> <emeyer> …I do think the glyph centering is probably better in most cases<br> <emeyer> …I don't think we should have a property to opt into current shipping behavior<br> <emeyer> …I also think trimming at line edges is better<br> <emeyer> …Authors go to great lengths to make things line up<br> <florian> q+<br> <emeyer> …I'm inclined to say let's try centering with line trimming<br> <kizu> https://codepen.io/stoumann/details/bGQdgpw<br> <astearns> ack kizu<br> <emeyer> kizu: The first random CodePen I found to do what Zoom does indicates a lot of people do like Zoom does, and it does break in Nightly<br> <emeyer> …I like the centering behavior more, but with the jagged edge, I wonder if it's possible to register when you need to trim to the left or right<br> <emeyer> fantasai: I think you just want to trim that space rather than redistribute it to the end of the line<br> <emeyer> kizu: I think it will be better visually than keeping it this way<br> <astearns> ack florian<br> <emeyer> florian: I think the workaround Koji mentioned using negative margins to get rid of terminal space is usually used at the end of inline boxes, not usually the end of a line<br> <emeyer> …So the end of an <em> gets a negative margin<br> <emeyer> fantasai: The trimming would interfere in the sense that if we center things, there would be too much trimming<br> <dbaron> s/gets a negative margin/gets a negative margin... but the proposal here is to trim at the ends of lines, not at the ends of inline boxes/<br> <emeyer> florian: At the margin, yes, but I think it's much less bad than the previous problem we had<br> <emeyer> …The scope here seems a lot more limited and I suspect won't be that bad in practice<br> <emeyer> jfkthame: The proposal to create trim at line edge is preferable<br> <emeyer> …Should that be under author control, and should it be oopt in or out?<br> <emeyer> fantasai: I suspect there won't be a lot of demand to not have line edge trimming, except maybe in compat situations<br> <emeyer> …I doubt that we'll get a lot of demand for that control; usually people want to get rid of extra space at line edges, so I think we should just do it<br> <emeyer> …Running it through all the experimental browsers would be a good way to flush out any problems<br> <emeyer> astearns: Agree with Elika about all that<br> <emeyer> …If we did have a switch, I suspect the default would be to opt out<br> <emeyer> …This may make things more complicated, but for left justified text, we could trim at the line starts only<br> <emeyer> astearns: Is there anyone who has concerns about trying this way of distributing letter spacing with trimming at the line ends?<br> <emeyer> iank_: I wouldn't object to trying it, but the compat still makes me very nervous<br> <emeyer> fantasai: I propose we adopt this into the spec with a note that we're trying it for compat analysis<br> <emeyer> astearns: Okay with you, Florian?<br> <emeyer> florian: Yes, but Elika, how do you mean your proposal?<br> <emeyer> fantasai: We can do it for the next six months or something<br> <emeyer> florian: So you want to spec it out with a warning on top?<br> <emeyer> fantasai: Yes, to see where we're at once we have more prototypes and compat data<br> <astearns> ack dbaron<br> <emeyer> astearns: Proposed resolution is to add this new method of letter spacing with line-edge trimming with an issue saying we're trying this out and will come back with compat data<br> <emeyer> dbaron: One other thought is might be useful to enable feature detection for this<br> <emeyer> …I don't know if there's a natrual way to do that, but we should think about it<br> <emeyer> astearns: That might be informed by the compat data; we might be something we need to do that for<br> <emeyer> fantasai: It might be that if we can release in a coordinated fashion, people will decide to all drop their hacks<br> <emeyer> astearns: Can't depend on that<br> <dbaron> s/should think about it/should think about it... it might be an @supports feature() or something else/<br> <emeyer> florian: Right, but this being largely cosmetic, you can drop the hacks and your page might be slightly uglier in old browsers<br> <emeyer> iank_: There are Chromium browsers that release on a six month cadence that it would be nice for their users not to be broken for six months<br> <fantasai> You can always use JS to detect<br> <emeyer> astearns: Objections to the proposed resolution?<br> <emeyer> (silence)<br> <emeyer> RESOLVED: add this new method of letter spacing with line-edge trimming, with a note saying we're trying this out and will come back with compat data<br> <fantasai> s/new/space-around/<br> <ChrisL> q+<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10193#issuecomment-2163247458 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 June 2024 14:52:46 UTC