Re: [csswg-drafts] [css-text-4] Make ideograph-alpha and ideograph-numeric part of text-spacing: normal (#6950)

The CSS Working Group just discussed `[css-text-4] Make ideograph-alpha and ideograph-numeric part of text-spacing: normal`, and agreed to the following:

* `RESOLVED: accept the text-spacing values for spacing adjustments?`
* `RESOLVED: non-zero padding disables text-spacing adjustement for spaces`

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> fantasai: text-spacing allows to adjust the spacing automatically at punctuation and between scripts<br>
&lt;fremy> fantasai: there are two values that ajdust of add spaces between CJK and alphabetic characters<br>
&lt;fremy> fantasai: and between CJK and numbers<br>
&lt;fremy> fantasai: typically, there is a little bit of spacing when this happens in practice<br>
&lt;fremy> fantasai: but this is not the current default behavior in browsers<br>
&lt;fremy> fantasai: the internationalization working group would like this to be the default<br>
&lt;fremy> fantasai: but there might be compat issues<br>
&lt;florian> q+<br>
&lt;fremy> fantasai: so, maybe we will have to force authors to change the default if they want this<br>
&lt;astearns> ack florian<br>
&lt;fremy> florian: I think this is desirable<br>
&lt;fremy> florian: if you try making a book and you don't to this, you won't find a publishers<br>
&lt;fremy> florian: adding spans is possible but tedious<br>
&lt;fremy> florian: but compat can be problem<br>
&lt;fremy> florian: not really in paragraphs<br>
&lt;fremy> florian: but in buttons or menus, this might be an issue as the text might no longer fit<br>
&lt;fremy> florian: it is wrong for this to create a compat issue<br>
&lt;fremy> florian: but I expect this to be common unfortunately<br>
&lt;fremy> florian: but I don't know how to verrify it<br>
&lt;florian> s/but I expect this to be common unfortunately/but I worry this might to be common unfortunately<br>
&lt;fremy> astearns: &lt;x> has a comment in the issue that says the behavior is desirable<br>
&lt;florian> s/it is wrong for this to create a compat issue/I hope I'm wrong, but I am concerned about compat<br>
&lt;fremy> astearns: but that they understand the compat issue and are willing to accept 0-space as the default<br>
&lt;fremy> astearns: so, can we move forward here?<br>
&lt;astearns> s/&lt;x>/JLREQ/<br>
&lt;fremy> fantasai: I think we should do this, and use a very conservative spacing<br>
&lt;florian> s/no longer fit/no longer fit tightly sized components/<br>
&lt;fremy> fantasai: which will not change things too much by default<br>
&lt;fantasai> s/a very/the more/<br>
&lt;fremy> fantasai: but we need to see if browers are willing to do this, and how to handle any compat<br>
&lt;fremy> astearns: is there any implementation willing to try this out?<br>
&lt;fremy> astearns: pdf processors would probably agree, but they are were the compat issues don't exist<br>
&lt;fremy> florian: correct<br>
&lt;fremy> florian: antenna house has it<br>
&lt;fremy> heycam: so, is the experiment chaning the default behavior, and see if something breaks?<br>
&lt;florian> s/antenna house has it/antenna house very likely has it, would be surprised if not/<br>
&lt;fremy> fantasai: doing it with text-spacing would be great<br>
&lt;fremy> fantasai: so we could disable it for a few elements<br>
&lt;fantasai> s/great/better/<br>
&lt;fremy> heycam: webkit does not support the property<br>
&lt;fantasai> s/elements/elements, e.g. pre and code/<br>
&lt;fremy> iank_: it's difficult to determine the compat risk<br>
&lt;fremy> iank_: I worry that changing the default and then using UA stylesheets to opt out<br>
&lt;fremy> fantasai: no, only opt out special elements like &lt;pre> and &lt;code><br>
&lt;fremy> fantasai: we would not want to opt out the entire page<br>
&lt;fremy> fantasai: otherwise, I agree we should not fold it into "normal"<br>
&lt;fremy> iank_: okay<br>
&lt;fremy> heycam: do you support text-spacing in blink?<br>
&lt;fremy> iank_: no<br>
&lt;fremy> heycam: if no one has an implementation, then experimenting would require implementation first<br>
&lt;fremy> astearns: we could add a note that we are waiting for implementation interest<br>
&lt;fremy> florian: the issue is that pdf renderers will happily use the new default<br>
&lt;PaulG> q+<br>
&lt;fremy> florian: and if we later find out it doesn't work for the web, we forked CSS<br>
&lt;fremy> astearns: we could have "auto" depending on the type<br>
&lt;fremy> florian: it's still a fork<br>
&lt;astearns> ack PaulG<br>
&lt;fremy> iank_: or we decide that print agents enable this in their user agent stylesheet<br>
&lt;fremy> PaulG: one usecase important to note, is AAC with "adapt module" extension makes things easier to read for other people<br>
&lt;fremy> PaulG: this might cause "script changes" that are not really true in practice<br>
&lt;fremy> PaulG: so this would affect their rendering<br>
&lt;fremy> astearns: this is likely true for people to have mixed scripts today<br>
&lt;fremy> astearns: and they will have double spacing if we change the default<br>
&lt;fremy> astearns: but they could detect and change<br>
&lt;PaulG> the demo I mentioned: https://matatk.agrip.org.uk/personalization-semantics-explorations/module1-2020-01.html<br>
&lt;RRSAgent> logging to https://www.w3.org/2022/11/30-css-irc<br>
&lt;fremy> fantasai: punctuation does not trigger this<br>
&lt;fantasai> s/punctuation/symbols and punctuation/<br>
&lt;fremy> florian: if there is a span with padding, does the separation the padding causes text-spacing to be disabled?<br>
&lt;fremy> fantasai: we did not think of this yet, but we have other cases where we have some rules, so we could add one up<br>
&lt;fremy> florian: I think we should do it, so we don't cause double-spacing for existing content<br>
&lt;fremy> fantasai: yes<br>
&lt;fremy> florian: I would still like browser implementations before going further, but I'm okay with just moving forward<br>
&lt;astearns> ack fantasai<br>
&lt;fremy> fantasai: second point I want to cover, if there is non-zero padding we should disable this behavior<br>
&lt;fremy> fantasai: third point, if you insert extra spaces to get this behavior today, we should take this spacing into account so it gets correct in the end<br>
&lt;fremy> florian: for CJK this seems rare<br>
&lt;fremy> florian: but for French, this might be something we want indeed<br>
&lt;fremy> florian: because you need a special space for some cases<br>
&lt;fremy> florian: but keyboards don't have the right keys so people use the wrong spaces<br>
&lt;fremy> florian: so we might want to replace them indeed<br>
&lt;fremy> (some discussion about keyboard being wrongs)<br>
&lt;fremy> astearns: any objection to accept this?<br>
&lt;fremy> RESOLVED: accept the text-spacing values for spacing adjustments?<br>
&lt;fremy> astearns: any objection to the second point about paddings?<br>
&lt;fremy> RESOLVED: non-zero padding disables text-spacing adjustement for spaces<br>
&lt;fremy> astearns: what about the third?<br>
&lt;fremy> fantasai: let's do it too<br>
&lt;fremy> astearns: so, the suggestion is to take spaces into account at the boundaries?<br>
&lt;fremy> fantasai: no, replace it<br>
&lt;fremy> astearns: I think there might be cases where the choice is intentional<br>
&lt;fremy> astearns: let's open a separate issue on that<br>
&lt;fantasai> ACTION: Open separate issue on space replacement<br>
&lt;fremy> fantasai: maybe this shouldn't be a default, but something we can ask explicitely<br>
&lt;fremy> astearns: let's go to 1 / 8<br>
&lt;fremy> florian: should we resolve on that?<br>
&lt;fremy> astearns: we should have an action for that<br>
&lt;fremy> florian: up the editors<br>
&lt;fremy> astearns: anything else on this issue?<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 30 November 2022 16:58:02 UTC