- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Oct 2020 15:34:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `treat all-neutral lines same as empty ones for plaintext alignment`, and agreed to the following: * `RESOLVED: All-netural paragraphs have the alignment of the previous paragraph when unicode-bidi is plaintext.` <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: treat all-neutral lines same as empty ones for plaintext alignment<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4405<br> <myles> fantasai: This was a request for a change that was brought up by aharon<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4405<br> <myles> fantasai: I don't know what the best thing to do with it at this point. Hopefully we can discuss with him.<br> <myles> addison: Is there a quick summary?<br> <myles> aharon: This is a bidi text issue. Currently, we have one of hte values of unicode-bidi is plaintext. This means that each paragraph of the content of an element is evaluated for its directionality (RTL or LTR) independently by the usual first strong character algorithm.<br> <myles> aharon: That's what unicode-bidi: plaintext does. it's great.<br> <myles> aharon: If the text-align property is start, then each paragraph of the context will have its alignment also evaluated independently. So if it's an LTR paragraph it will be left aligned, and RTL will be right aligned.<br> <myles> aharon: However, there is an exception: if a paragraph is empty, then it has the same alignment as the preceding paragraph. Why? Because if this is a text area, and the person is entering text, and I just typed a RTL paragraph, so it's sitting there aligned to the right, and everything is great, and I type enter to start a new paragraph, my cursor goes all the way to the left, because the default alignment of a paragraph, incl. empty paragraph, is LTR><br> <myles> aharon: So, we made the default be whatever the previous paragraph was.<br> <myles> aharon: The proposal is to broaden the exception so that not only will that be the case for an empty paragraph, it will also be the case for an all-neutral paragraph: One that does not contain any strong LTR or RTL characters according to the first strong algorithm.<br> <myles> aharon: So it's directionality will still be LTR, but its alignment will be according to the previous paragraph.<br> <myles> aharon: The reason is flipping alignment from one paragraph to another looks ugly, and because there is a number of common cases of all neutral paragraphs, such as a date (just numbers) or time, phone number, entering text, the beginning of a list with the list header (dash, plus, star, 1.)<br> <myles> aharon: So while i'm typing, and I haven't started typing the text of the list item, currently it's aligned left, even though everything up to that is aligned to the right.<br> <florian> q?<br> <florian> q+<br> <myles> aharon: it's ugly, so i'm proposing the existing exception of an empty paragraph be broadened to an all neutral paragraph<br> <myles> aharon: A counter case: Emoji. If I have a paragraph that is several emoji characters, there is no clue for which direction they should be read, but alignment is a strong clue. Single character, and ascii emoji don't matter.<br> <myles> aharon: I don't think that's a very important case, and I'd rather deal with the ones that are more important to me. I don't feel strongly about it. But I think it would be an overall plus. I don't have any data to back up my proposal.<br> <Rossen_> ack florian<br> <myles> florian: the rationale makes sense to me. Do you have reasoning that this won't break sites? I would like to support it, but we need reasons why this won't break things<br> <myles> fantasai: This only occurs on a multiline element that has dir=auto.<br> <myles> aharon: Or unicode-bidi: plaintext<br> <myles> fantasai: yes, but most people don't do that.<br> <myles> aharon: It is the default for a text area with dir=auto<br> <myles> aharon: It won't break things because this is a corner situation. It isn't a widely used thing.<br> <myles> aharon: Already when you have lines with unicode-bidi:plaintext, lines can switch alignment from one to the other, sometimes it looks good and sometimes it doesn't. This may make things look more ugly perhaps, but if it does, it's not a big deal. it won't *break* anything<br> <jfkthame> +1<br> <Rossen_> ack r12a<br> <myles> r12a: It makes sense to me. I've been playing with arabic in my arabic picker. It's strange that you type a line of arabic and you hit the return key and it goes to the left side. I think it will fix more things than it breaks.<br> <Rossen_> ack fantasai<br> <myles> aharon: It shouldn't go to the left side. If it does, the browser you're using doesn't implement it properly.<br> <myles> fantasai: It sounds like there are good arguments in favor of this, do implementors want to implement?<br> <fantasai> myles: It's not difficult to implement.<br> <fantasai> myles: If we're scanning for first-strong, we can scan for strong at all<br> <fantasai> aharon: Look-behind aspect, have to look at preceding line?<br> <fantasai> myles: This proposal doesn't change that<br> <fantasai> Rossen_: Any other implementer feedback or pushback?<br> <myles> Rossen_: Any other feedback?<br> <myles> Rossen_: sounds like there is no pushback<br> <myles> florian: jfkthame said "+1". What was it about?<br> <myles> jfkthame: "+1" b/c this sounds like an improvement. I can't guarantee timeline for implementation. But it's a good proposal.<br> <myles> Rossen_: There's enough support, aharon, so for the time being we should adopt it.<br> <myles> RESOLVED: All-netural paragraphs have the alignment of the previous paragraph when unicode-bidi is plaintext.<br> <fantasai> s/netural/neutral/<br> <fantasai> ScribeNick: fantasai<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4405#issuecomment-709407490 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 October 2020 15:34:18 UTC