- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Jan 2020 15:06:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `all-neutral lines`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: all-neutral lines<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4405<br> <TabAtkins> fantasai: Issue raised by Aharon<br> <TabAtkins> fantasai: When you have a plaintext block, like a <pre> with unicode-bidi:plaintext<br> <TabAtkins> fantasai: It resolves the para base direction of each "paragraph" (things separated by forced line breaks) according ot the first strong character in the paragraph.<br> <TabAtkins> fantasai: This is a heuristic, not always accurate, but it's what the plaintext bidi algo does.<br> <TabAtkins> fantasai: Interesting to Aharon is alignment<br> <TabAtkins> fantasai: We take advantage of a para-based direction, that's not 'direction' proper, but we use that direction per-line to decide what "start" text-alignment means.<br> <TabAtkins> fantasai: Problem arises if you ahve a paragraph that's completely neutral chars, like punctuation.<br> <TabAtkins> fantasai: Or numbers.<br> <TabAtkins> fantasai: What he noticed is that you have a document that's entirely arabic, but it has a line of text with no letters in it, it ends up being aligned to the left (wrong side for arabic)<br> <TabAtkins> fantasai: We already make an exception for empty line boxes; we take the direction from preceding line. Suggestion is to apply that exception to all-neutral lines too.<br> <TabAtkins> florian: Currently it's udnefined?<br> <TabAtkins> fantasai: Currently the defualt is ltr if you can't find a direction.<br> <TabAtkins> jfkthame: I think the terminology is a little wrong; numbers are weak, not neutral.<br> <TabAtkins> fantasai: Sure. I don't recall the exact spec wording, it's probably more accurate.<br> <TabAtkins> fantasai: So if you have arabic text and underlined it with a line of hyphens, for example<br> <TabAtkins> s/fantasai/faceless/<br> <TabAtkins> fantasai: Yeah, that's a case here<br> <TabAtkins> koji: So I guess options are previous paragraph, or 'direction' property. Any reason you chose preivous para?<br> <TabAtkins> fantasai: That was the suggestion from Aharon.<br> <TabAtkins> fantasai: We're specifically in a unicode-bidi:plaintext context, which imlpies the 'direction' doesn't know what it should be.<br> <TabAtkins> koji: But then 'direction' should specify the ui or document direction, so it's a more natural fallback to me.<br> <TabAtkins> florian: Not necessarily - if writing content like an email, the UI might be in English but the context is Arabic. Using 'unicode-bidi:plaintext' on the email textarea because you know the lang direction is unknown.<br> <TabAtkins> koji: Agree, this is heuristic, we could argue both cases.<br> <TabAtkins> koji: I just think author intention is more natural fallback.<br> <TabAtkins> myles: Not sure I agree with that.<br> <TabAtkins> myles: If there's a quote snippet, you might want to remove some middle paragraphs, replacing with [...] to indicate it's been snipped<br> <TabAtkins> myles: If you do that as currently described, it'll be on the other side of the screen and look wrong.<br> <TabAtkins> koji: If you have English quote in arabic text, and there's underline, you want it on arabic direction<br> <TabAtkins> koji: If you ahve hyphens *above*, it'll be arabic-aligned; if you ahve hyphens *below*, it'll be English-aligned.<br> <TabAtkins> koji: So it's a question of which is better heuristic.<br> <TabAtkins> fantasai: I think you're both making good points.<br> <TabAtkins> fantasai: It's not clear which is clearly better.<br> <TabAtkins> fantasai: I think what is clear is that we shouldn't use ltr as the generic default.<br> <TabAtkins> koji: Have you tested what browsers do today?<br> <TabAtkins> faceless: My understanding of "plaintext" is that you really can't rely on the direction property.<br> <fantasai> testcase - http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cpre%20dir%3Dauto%20style%3D%22direction%3A%20rtl%22%3E%0A%5E__%24%0A%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9%0A%5E__%24%0Aabcde%0A%5E__%24%0A%3C%2Fpre%3E%0A<br> <TabAtkins> TabAtkins: My intution says that most of the time you'll be looking at single-language text, so the neutral para should align with that, and the heuristic will work. When you ahve mixed text, Koji's argument that it's uncleaer and might be wrong is valid, but the "previous para" heuristic should be right about half the time. So that's not bad!<br> <TabAtkins> fantasai: Testcase shows that each paragraph is handled individually; if it's all neutral, it's treated as ltr even if "direction:rtl" (this is exacty what the spec currently specifies).<br> <TabAtkins> fantasai: Interesting case - neutral text like ASCII art in a "plaintext" context, and there's some rtl preceding it, you don't want it swapped direction.<br> <TabAtkins> myles: ASCII art is pretty niche. I don't think it should affect this decision.<br> <TabAtkins> fantasai: So I think if the *entire paragraph* is neutral, we shouldn't look at previous para; we should just use the "previous line".<br> <TabAtkins> koji: What do you do at the beginning of the block?<br> <TabAtkins> fantasai: Probably just default to what unicode says, which is ltr<br> <TabAtkins> myles: I'm sure we're not the first ot have this idea. Do we know why Unicode gives this advice?<br> <TabAtkins> fantasai: Unicode doesn't define alignment.<br> <TabAtkins> fantasai: They do require that the *base diretion* is ltr (affecting bidi reordering); we don't want to touch that. This is just about alignment.<br> <TabAtkins> koji: Unicode bidi l1 requires applying reordering to trailing spaces; without bidi l1 and l0 affects reordering.<br> <florian> q?<br> <florian> q+<br> <TabAtkins> fantasai: We can tweak the alignment; I don't think we should be making tweaks to the ordering of characters.<br> <astearns> Zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <florian> q+<br> <TabAtkins> koji: I'd rather fix paragraph level rather than fix text-align<br> <TabAtkins> fantasai: So that would be to close this issue no-change?<br> <TabAtkins> fantasai: The issue is just about text-alignment; saying it's wrong for these cases.<br> <TabAtkins> fantasai: You're saying let's not do that. Taht's an okay proposal!<br> <TabAtkins> koji: No, just say that text-align uses base direction, and CSS can just say that if there's no strong characters we inherit from the previous line.<br> <TabAtkins> fantasai: bidi reordering relies on base direction, that'll change the ordering of characters.<br> <TabAtkins> fantasai: Like base direction determines where your period goes at the end of your sentence.<br> <TabAtkins> jfkthame: Not sure I'm totally comfortable with changing base direction for reordering purposes and for alignment.<br> <TabAtkins> fantasai: I'm just relaying fro mthe issue<br> <TabAtkins> fantasai: We can decide to reject the proposal.<br> <astearns> ack florian<br> <TabAtkins> florian: Originally I was enthusiastic, and maybe given it's from Aharon my concerns are unfounded; in Unicode there of course is no alignment, it comes from *somewhere*. Currently in plaintext applications everything is effectively start-aligned.<br> <TabAtkins> florian: So aren't those apps already effectively doing the same for alignment and base direction?<br> <TabAtkins> koji: The feedback is from 2016, mind checking with Aharon again?<br> <TabAtkins> koji: He's been responsive to me more recently.<br> <TabAtkins> fantasai: Ok, I'll summarize and take it back to himl<br> <TabAtkins> fantasai: I'm opening some plaintext editors, and it looks like alignment is based on the whole file.<br> <TabAtkins> fantasai: Even having differing-direction entire paragraphs doesn't affect it.<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-578168077 using your GitHub account
Received on Friday, 24 January 2020 15:06:14 UTC