- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Aug 2023 17:02:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `text-spacing: trim-all`, and agreed to the following: * `RESOLVED: Add trim-all value` * `ACTION fantasai, florian to ask i18n about distinguishing between brackets and non-brackets` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: text-spacing: trim-all<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/8482<br> <fantasai> -> https://github.com/w3c/csswg-drafts/issues/4246#issuecomment-1416647486<br> <TabAtkins> fantasai: Think it woujld help to look at, there's a comment here<br> <TabAtkins> fantasai: If you look at these pics, you'll see there, typically CJK punctuation like commas, brackets, are full-width, like normal charcters<br> <TabAtkins> fantasai: Half of it is glyph and half is blank<br> <TabAtkins> fantasai: Sometimes people want to remove that spacing<br> <TabAtkins> fantasai: Sometimes stylistic, sometimes to convey inclusion (comment in a list of numbers)<br> <TabAtkins> fantasai: We have text-space-trim property that allows trimming half spaces in certain contextual cases where it looks bad to keep<br> <TabAtkins> fantasai: For example, at the beginning of a line you don't want to start with a half-empty glyph, you want the opening bracket to start flush<br> <TabAtkins> fantasai: Or if you have two closing parens, the inner shoudln't have the extra space after it<br> <TabAtkins> fantasai: So we have a bunch of values to control these things. But they remove the space conditionally, based on position of the glyph in the line or wrt other characters<br> <TabAtkins> fantasai: But5 that doesn't solve these problems, where we want to remove the extra space unconditionally<br> <TabAtkins> fantasai: There are two reasons. One is stylistic, we shoudl handle that in CSS<br> <TabAtkins> fantasai: the other is semantic, unicode should handle that<br> <TabAtkins> fantasai: Proposal is a trim-all value, which removes all these extra half spaces<br> <TabAtkins> fantasai: You *can* use it to hack things around, like putting spans around numbers and rmeoving spaces within each. Not ideal but possibl.<br> <florian> q+<br> <astearns> ack florian<br> <TabAtkins> fantasai: So should we add a trim-all that unconditionally trims full-width down to the half-width of actual glyph?<br> <TabAtkins> florian: I thought I knew this already but I'm confused<br> <TabAtkins> florian: When you say sometimes stylistic, sometimes semantic<br> <astearns> q+ to ask how this interacts with text-spacing-trim: trim-auto<br> <TabAtkins> florian: For stylistic we have contextual trim - do we have a stylistic need for trim all?<br> <TabAtkins> florian: I think you said so but I didn't realize that was the case<br> <TabAtkins> fantasai: Murakami-san posted some examples of it<br> <TabAtkins> florian: Which is stylistic?<br> <TabAtkins> fantasai: The first one<br> <TabAtkins> florian: Yeah that's true<br> <TabAtkins> florian: Okay in that case I think we should add it<br> <TabAtkins> florian: I was unsure because, for semantic reasons this shoudl be solved in Unicode, or else in HTML. If it's in HTML it's *reasonable* to have a CSS property explaining the behavior change, but if it's Unicode there's no need to invoke CSS at all.<br> <TabAtkins> florian: But if we need it for stylistic reasons *anyway*, then it does make sense to have it in CSS.<br> <TabAtkins> fantasai: A related question might be, do we need to distinguish between brackets and.. I'll call them pauses - commas and periods and whatnot<br> <astearns> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property<br> <TabAtkins> astearns: How is this different than trim-auto value already in there?<br> <TabAtkins> florian: That's context-dependent, it doesn't remove them always.<br> <astearns> ack a<br> <Zakim> astearns, you wanted to ask how this interacts with text-spacing-trim: trim-auto<br> <TabAtkins> florian: In particular, it wouldn't do it for the comma in the middle of a number<br> <TabAtkins> florian: Or around angle brackets in example 3.1.2 that Murakami-san showed<br> <TabAtkins> florian: So if you want to force trim regardless of context we need aqnother value<br> <chrishtr> q+<br> <TabAtkins> fantasai: So proposed resolution is to add a trim-all, and I also want to ask if we want to ask the i18n WG if we need to distinguish between "trim brackets" and "trim pauses"<br> <TabAtkins> chrishtr: So trim-all removes all extra whitespace regardless of character?<br> <TabAtkins> fantasai: No matter *where* it is, there's a list of affecte characters<br> <TabAtkins> chrishtr: Where?<br> <astearns> https://drafts.csswg.org/css-text-4/#fullwidth-collapsing<br> <TabAtkins> florian: It's specific CJK puncturation, there's a list<br> <TabAtkins> chrishtr: okay, that list makes sense<br> <TabAtkins> chrishtr: Next question si implementability<br> <TabAtkins> chrishtr: Do other systems ahve this?<br> <TabAtkins> florian: Yes, it's not harder than doing it contextually which is already implemented<br> <TabAtkins> florian: This is only a question of "when do you do it", now "how", so it's not harder than existing implemented features.<br> <TabAtkins> astearns: Yeah that's the existing trim-auto value I asked about<br> <TabAtkins> florian: I think browser engines currently dont' but other CSS engines (like Antenna House) do, and they work on a similar font stack even if their impl is different.<br> <TabAtkins> florian: Non-web like InDesign too, their layout engine works differently but their font system doesn't<br> <TabAtkins> chrishtr: jfkthame, opinions from impl pov?<br> <TabAtkins> jfkthame: It's not something I've looked into personally so I'm not very confident atm<br> <TabAtkins> jfkthame: I guess I have some questions about how easily this can be implemented across all potential fonts, whether they have the related OpenType features or not. If they don't you might need some tricky heuristics to decide what to do<br> <TabAtkins> florian: In theory yes, in practice no. These fonts are very square and where the whitespace occurs is very predictable.<br> <TabAtkins> florian: Fancy unusual fonts might do something unusual, but the vast majority of standard fonts will have precisely the left or right half blank.<br> <TabAtkins> jfkthame: I've seen some fonts where the fullwidth glyph appears in the middle of the square rather than at one edge, which makes trim harder<br> <TabAtkins> fantasai: That doesn't generally happy except for...<br> <TabAtkins> fantasai: there's a set of punctuation where they're eitehr on one side or in the middle, like period or semicolon. Those are little more difficult to manage, tends to be language-dependent. Chinese tends to go in the middle, Japanese to a side.<br> <TabAtkins> fantasai: There's a note in the spec about that.<br> <TabAtkins> fantasai: This isn't ideal, it woudl be great to use font features to do this trimming. But this is a pretty important part of typesetting in Japanese text, and it not being done on the web looks wrong and ugly. Pretty much any non-web system doing Japanese text is going to do this propertly, so we need to figure out how to do it<br> <astearns> +1 to having this done properly on the web would be good<br> <TabAtkins> florian: Back to impl, the question is interesting but orthogonal.<br> <TabAtkins> florian: Whether or not we add trim-all we already have the trim system in the spec, so adding this doesn't change that<br> <TabAtkins> florian: Might want to open an issue in general about whether there are hard cases, etc.<br> <TabAtkins> chrishtr: Given no browser implements trim-auto yet I would like confirmation that it's implementable. I've message Koji who's working on similar things in Blink.<br> <TabAtkins> fantasai: Back to florian's point, if the objection is to trimming at all you're objecting to the whole feature, not this value.<br> <TabAtkins> chrishtr: I'd like to not add new things to this before confirming that.<br> <TabAtkins> astearns: Yes and no. We can make progress on this feature even if it's only for non-web processors.<br> <TabAtkins> astearns: I'd like to have a r4esolution to add this value to *complete* this feature, then ahve a separate issue about whether it's implementable.<br> <TabAtkins> astearns: Is that okay?<br> <TabAtkins> chrishtr: Sure.<br> <TabAtkins> jfkthame: Fine with me.<br> <TabAtkins> astearns: So proposed resolution is to add trim-all value which will do puncturation trimming in all cases. Objections?<br> <TabAtkins> RESOLVED: Add trim-all value<br> <TabAtkins> astearns: Also fantasai asked for an action on the editors to ask the i18n WG if we need a distinction between brackets and other punctuation.<br> <TabAtkins> astearns: Not entirely sure, but suspect this might open a big can of worms. I recall Japanese publishing houses having definite and disparate rules on punctuation layout. To satisfy everyone we might need an explosion of things. But happy to ask and see what we get.<br> <TabAtkins> fantasai: I think we're less likely because the bracket/non-bracket distinction is pretty clear.<br> <TabAtkins> fantasai: Looking at murakami's examples, some didn't trim commas but did trim all brackets.<br> <chrishtr> q+<br> <TabAtkins> fantasai: Another use-case is decimal points and commas in a number, if there's a <number> HTML element or just a <span class=number>, trim all commas and periods, but if you happen to use parens for negatives or something you might not want them trimmed.<br> <florian> q+<br> <TabAtkins> fantasai: So being able to make a distinction between these sets might help with proper semantic markup<br> <TabAtkins> chrishtr: I heard back from Koji, it does seem implementable but maybe not for all fonts.<br> <TabAtkins> chrishtr: Might need to be an allowlist of fonts where it's allowed to work. Does the spec allow for that?<br> <TabAtkins> fantasai: I think that's a separate issue.<br> <TabAtkins> astearns: The section that talks about which characters are affected does mention various opentype features you may use, or must not use<br> <TabAtkins> astearns: If it's not already there we could probably add to that section<br> <TabAtkins> chrishtr: Yeah might be as simple as using SHOULD rather than MUST.<br> <astearns> ack chrishtr<br> <astearns> ack florian<br> <TabAtkins> florian: For impl we should have another issue and look into the details.<br> <TabAtkins> florian: If you can't reliably detect that the browser's gonna do it or not, this is problematic.<br> <TabAtkins> florian: Right now they'll put spans in and use negative margins to simulate. If browsers do it *sometimes* they won't know whether ot correct or not.<br> <TabAtkins> florian: So if we can't make it work everywhere, at least make it predictable.<br> <TabAtkins> florian: Also I think it doesn't hurt to ask the i18n WG but I do suspect different people will want different things.<br> <TabAtkins> florian: And people who are very specific will be okay with preprocessing their text with markup to get exactly what they want<br> <TabAtkins> ACTION fantasai, florian to ask i18n about distinguishing between brackets and non-brackets<br> <TabAtkins> astearns: We can have a new issue on implementability and intearction with font features.<br> <TabAtkins> astearns: How it's implemented and whethe rit's feature detectable.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8482#issuecomment-1680966172 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 August 2023 17:02:50 UTC