- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Aug 2022 15:30:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `don't provide a lang param for word boundary`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> topic: don't provide a lang param for word boundary<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/7193<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7193<br> <fantasai> florian: In Text L4, we have a property to detect boundaries<br> <fantasai> florian: and another property to use boundaries<br> <fantasai> florian: e.g. in Japanese might want to word-break headings<br> <fantasai> florian: If not marked up in the source, can use this property to auto-detect the word breaks<br> <fantasai> florian: In CSS, ask for detection through this property<br> <fantasai> florian: and say which languages you want to auto-detect<br> <ChrisLilley> q+<br> <fantasai> florian: Implementers also want to not specify the language<br> <fantasai> florian: Problem is as an author, how do you know what's supported?<br> <emilio> q+<br> <fantasai> florian: e.g. if you say autodetect Thai, how do you fall back if the browser doesn't support auotdetection for Thai?<br> <Rossen_> q<br> <fantasai> florian: In Japanese, normally you can break everywhere. If you turn that off, and only break at word boundaries, you will not wrap anywhere if you fail detection<br> <fantasai> florian: If you turn off normal line-breaking, and turn on one that requires word boundaries to be inserted, and you fail to insert them, the result will be very bad<br> <fremy> q+<br> <Rossen_> ack ChrisLilley<br> <fantasai> ChrisLilley: I think what I see the i18n group is to combine this with actual use of lang attributes in markup, and if you don't do that you get what you get<br> <fantasai> ChrisLilley: I think they're trying to push for "use proper lang tags"<br> <fantasai> florian: Specced to require markup lang tagging as well<br> <fantasai> florian: You have to match on both sides. If you ask for "auto-break Japanese", it will only apply that to elements that are also tagged as Japanese<br> <fantasai> florian: Browsers can maybe guess, but ...<br> <fantasai> ChrisLilley: Has this been articulated to the i18nwg?<br> <fantasai> florian: I can write it up in the issue<br> <fantasai> emilio: It's weird to make syntax parse depend on something that may be system dependent<br> <Rossen_> ack emilio<br> <fantasai> emilio: e.g. if you make system API to do the line break, then can only line-break if the system supports it<br> <fantasai> emilio: ...<br> <fantasai> emilio: It's a bit of a hassle to pass that back through the CSS parsing layer<br> <Rossen_> ack fremy<br> <fantasai> fremy: For the fallback, seems extremely dangerous that you would depend on this<br> <fantasai> fremy: it seems to be more prudent to say, if the UA is not able to find breaks in the text, then don't apply<br> <fantasai> fremy: doesn't mean you don't parse, but if you're supposed to break, and cannot find a place to break, sounds lie a bug<br> <fantasai> florian: This property doesn't control line-breaking<br> <fantasai> florian: if you want to control line-breaking, you use the usual properties<br> <fantasai> florian: and you can put Unicode chars to indicate line breaks<br> <fantasai> florian: What this does is to effectively inject into the markup the Unicode characters you didn't put yourself<br> <fantasai> florian: We could change to make the property to autodetect and also control line-breaking, but already so complicated<br> <fantasai> florian: Also this property is not just for line-breaking,<br> <fantasai> florian: can detect word boundaries to insert spaces<br> <fantasai> florian: can insert spaces, or line break, or both<br> <fantasai> florian: If you don't have the characters in the markup and they fail to be auto-injected, then you won't wrap anywhere, and that's a big problem<br> <fremy> q?<br> <fantasai> florian: Maybe we can find a different way to do fallback, but if there's a risk of content overflowing instead of wrapping, people can't use this property<br> <fantasai> dbaron: Want to echo what Chris says, which is we shouldn't do too much based on this feedback until we make sure r12a understands why we did this in the first place<br> <fantasai> dbaron: it's not clear in the spec text, and not clear in the issue<br> <Rossen_> ack dbaron<br> <fantasai> dbaron: so go back and explain why you did it this way first<br> <fantasai> fantasai: Sounds like the plan is for FLorian to go back and explain why this works the way it does in the issue, and also clarify in the spec<br> <fantasai> Rossen_: Anything else on this issue?<br> <dbaron> (r12a might still disagree, but we should find out first, and then perhaps discuss again)<br> <fremy> @ fantasai Thanks, this was a misconfiguration at my mike level, I had set gain to minimum ^_^<br> <fantasai> florian: I'll clarify<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7193#issuecomment-1201356151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 August 2022 15:30:11 UTC