- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Aug 2017 10:12:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `text-spacing fullwidth punctuation collapsing`, and agreed to the following resolutions: * `RESOLVED: Accept change matching JLReq's punctuation spacing, put a note into the spec about maybe needing more complex stuff, follow up with JLReq about the topic.` <details><summary>The full IRC log of that discussion</summary> <Rossen> Topic: text-spacing fullwidth punctuation collapsing<br> <Rossen> github topic: https://github.com/w3c/csswg-drafts/issues/1668<br> <TabAtkins> Florian: In CJK, full-width punct takes a full-width box, but they visually fill half o fit<br> <TabAtkins> Florian: Japanese expects that when they're next to each other (like two close-parens), there will be a big space.<br> <TabAtkins> s/there will be a big space/there will not be a big space, they'll be collapsed visually/<br> <TabAtkins> Florian: The font contains spaces, but it needs to be canceled out in some cases.<br> <TabAtkins> Florian: We have a rule in Text 4 that says when to do this.<br> <TabAtkins> Florian: One rule is overcomplicated. We did it wrong because JLReq wasn't specific enough.<br> <TabAtkins> Florian: Case is where you have a closing punct followed by an opening one: `)(`.<br> <TabAtkins> Florian: If you did nothing it's 2em long, we want 1.5em long.<br> <TabAtkins> Florian: Closing, half-space, opening.<br> <TabAtkins> fantasai: Collapse away the adjacent half space.<br> <TabAtkins> Florian: We specced that each is .75em long.<br> <TabAtkins> Florian: Proper is to keep all space on closing one, remove all space from opening.<br> <TabAtkins> Florian: Difference is barely observable, we should match.<br> <TabAtkins> fantasai: Did the people working on those things consider the case of different-sized fonts?<br> <TabAtkins> fantasai: Second paren is half the size of the first one, then what should happen?<br> <TabAtkins> Florian: That's where it becomes observable.<br> <TabAtkins> fantasai: I think probably 75% on each side isn't the right answer, so we should change it, but also not convinced we should always use the first.<br> <TabAtkins> Florian: Unsure. Murakami says to do it the other way, and InDesign does it the other way, so we should match.<br> <TabAtkins> fantasai: One thing we often do is look at print examples, and find where they're not handling cases.<br> <TabAtkins> fantasai: I think we should choose one or the other; we could use innermost or outermost...<br> <TabAtkins> Florian: They're same level.<br> <TabAtkins> fantasai: Always use bigger one?<br> <TabAtkins> myles_: That'll cause space to change when font-size animates?<br> <TabAtkins> TabAtkins: It'll do that no matter what.<br> <TabAtkins> Florian: I think we should match pubs, with a note about if someone has cases not considered, let us know.<br> <TabAtkins> fantasai: Korean mixes font sizes a lot; rather than ruby they just reduce font-szie<br> <TabAtkins> Florian: But they use latin punctuation, not full-width, so this doesn't apply.<br> <TabAtkins> myles_: I think it makes the most sense to do what everyone else does as a first pass.<br> <TabAtkins> fantasai: Happy with that if we follow up with JLReq to make sure they think about this case.<br> <TabAtkins> Rossen: ARe you current JLReq laiason?<br> <TabAtkins> Florian: Not yet, I have something later about that.<br> <TabAtkins> koji: I think previous spec is ambiguous, just says "put a half space between them".<br> <TabAtkins> Rossen: So can we resolve to accept change, put a note in, and follow up with JLReq?<br> <TabAtkins> RESOLVED: Accept change matching JLReq's punctuation spacing, put a note into the spec about maybe needing more complex stuff, follow up with JLReq about the topic.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1668#issuecomment-320212394 using your GitHub account
Received on Friday, 4 August 2017 10:14:54 UTC