- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 20:43:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ruby] ruby-overhang:none is too agressive`, and agreed to the following: * ``RESOLVED: Add `spaces`, alias `none` to `spaces` `` <details><summary>The full IRC log of that discussion</summary> <emilio> florian: [brief reminder of ruby overhang]<br> <emilio> [diagram in https://drafts.csswg.org/css-ruby/#ruby-overhang]<br> <emilio> ... aesthetically it's nicer when things are compact, but for readability isn't<br> <emilio> ... so the default the browser thinks about it and does something smart (auto)<br> <emilio> ... but some readers try to master the notion of reading, and people with dyslexia and want "screw aesthetics", and they prefer not overhanging<br> <emilio> ... it's been shipping in Safari<br> <emilio> ... chrome is about to implement<br> <emilio> ... probably Kindle supports it<br> <astearns> I think the example might be clearer if the spacing was consistent in the compact case and inconsistent in the overhang:none case<br> <emilio> ... and problem is that we might be too aggressive with the definition overhang is none, even if the thing on the side is a space<br> <emilio> ... if they're spaces it's fine to overhang, but right now that's not allowed by spec<br> <emilio> ... in CJK some characters have space built-in like parenthesis<br> <emilio> ... and you're not allowed to overhang over the space part of the parenthesis<br> <emilio> ... we should tweak the value to allow overhanging over spaces and space in punctuation<br> <emilio> ... we could have a really-none value that didn't allow that but I don't think it'd be used in practice<br> <TabAtkins> q+<br> <Rossen> ack fantasai<br> <emilio> fantasai: I think it makes sense to have this behavior<br> <emilio> ... not sure tying it to none is that obvious<br> <emilio> ... maybe we should have an `spaces` value?<br> <emilio> q+<br> <emilio> ... I don't have a very strong sense but it's easier to implement `none` than `spaces`<br> <florian> q+<br> <emilio> ... so as a path to make this work it might make sense to allow these<br> <fantasai> Kida-san's point:<br> <fantasai> First of all, could you clarify the intended purpose of the value “none”?<br> <fantasai> It seems that changing its behavior in this way may contradict the meaning of “none.”<br> <fantasai> As an alternative, would it be reasonable to introduce a new value, such as “simple,” and align it with the behavior of simple ruby?<br> <Rossen> ack TabAtkins<br> <emilio> TabAtkins: only question re. the examples, is the fact that F1/F2 is there<br> <emilio> ack emilio<br> <Rossen> ack florian<br> <emilio> florian: we could define a `simple` / `spaces` value<br> <emilio> ... if we had `none` and `simple` nobody would use `none`<br> <emilio> ... because what you're doing is that in order to know that 8 is annotating a space you're going to push the space out with another space<br> <emilio> ... so if we want to make it simpler for impls we could allow for the `none` to never overhang<br> <emilio> ... but I don't think having both values is useful<br> <emilio> ... it was introduced for learners / dyslexic features and I don't see `none` being preferrable<br> <oriol> q+<br> <emilio> ... so alternative would be to make this behavior a SHOULD not a MAY<br> <Rossen> ack oriol<br> <emilio> oriol: don't know much about ruby but I wonder if some people could want it to ensure that the space would be respected between the annotations<br> <emilio> ... but not sure if it makes sense<br> <emilio> florian: I don't _think_ so<br> <emilio> ... the think approaching what you say is that sometimes you want to have a strict rythme<br> <emilio> ... and to avoid alignment, but the amount by which your ruby sticks out doesn't agree with this grid<br> <emilio> ... but the precise alignment wouldn't be the case<br> <emilio> oriol: you mentioned learners / kids<br> <emilio> ... I was wondering if the spaces in the text below is important to separate different things might also be important to separate the annotations<br> <emilio> florian: the annotation overhanging actual text would be bad but that's why you introduce spacing<br> <emilio> ack dbaron<br> <Rossen> ack dbaron<br> <emilio> dbaron: two qs<br> <astearns> for background, there appears to be an “overhang compatible” character list in InDesign: (in ruby overhang) “For Japanese, character types compatible with Overhang comply with the JISx4051‑1995 specification.”<br> <emilio> ... is it straight-forward for an implemntation to figure out which characters count for "which part of the character you can ignore" and "how much space to ignore"? Is this metrics or is this going to look at glyph classes and char boundaries?<br> <florian> q+ to answer dbaron<br> <emilio> ... second question, are there any cases where people would use this for preventing annotations from overlapping each other? Or is that handling by something else?<br> <Rossen> ack florian<br> <Zakim> florian, you wanted to answer dbaron<br> <emilio> fantasai: should be handled by something else<br> <emilio> florian: there are not reliable font metrics, character class<br> <emilio> ... as for the amount this would be fully specified but for punctuation it'd be half the character<br> <emilio> ... a bit of an approximation for some fonts<br> <emilio> ... but not to a degree that matters<br> <emilio> dbaron: so there'd be a set of characters and you can use up to half the width?<br> <emilio> florian: for some subset you can use the left half, for other subset the right half, I think there are others where you'd use up to a quarter (a center dot where the left quarter and right quarter are spaces)<br> <emilio> dbaron: I presume this all gets repeated for vertical where there's top and bottom right?<br> <emilio> florian: yes<br> <emilio> q+<br> <Rossen> ack emilio<br> <fantasai> emilio: A third option could be to introduce the new value that is more semantically correct and have none alias to that value.<br> <fantasai> emilio: Not sure if it makes sense, but could be nicer in the long term<br> <fantasai> emilio: Feels weird to write 'none' to mean something that is "none except spaces"<br> <fantasai> emilio: But aliasing means that you progress behavior for existing content but also people can later type what they mean.<br> <fantasai> florian: I'm ok with that<br> <emilio> florian: so I think that'd be to have a value called spaces, overhang is only allowed for spaces, and UAs may simplify into not overhanging, and having a value that is an alias of it<br> <emilio> emilio: which value we want, `spaces` or `simple`?<br> <emilio> fantasai: spaces actually describes what it does<br> <emilio> ... there's other thing `simple` could mean<br> <emilio> florian: yeah I think I prefer `spaces` because `simple` is the name of the note<br> <emilio> PROPOSED: Add `spaces`, alias `none` to `spaces`<br> <emilio> RESOLVED: Add `spaces`, alias `none` to `spaces`<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5912#issuecomment-4180375625 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 20:43:21 UTC