[css-ruby] visibility:collapse on ruby annotations

[frivoal]

TL;DR: visibility:collapse could serve a very useful role in ruby.

Ruby, in its standard use as a pronounciation aid, is at its core an accessibilty tool: it enables readers with different levels of proficiency to read the same text. But while ruby on characters that someone doesn't know how to read is very helpful, more ruby isn't always better, otherwise, all Japanese texts would be full of ruby, and they're not. To readers who already know the reading of the annotated character, ruby can be distracting. In learning situations, it can also be desirable to hide the annotations over the characters that you're supposed to know to make sure you actually practice reading them. For some people with dislexia, ruby can even make text harder to read.

In printed materials, you get what the author prepared for you, and that's that. But in digital formats, being able to customize how much ruby you see is highly desirable. Marking up a piece of text with full ruby annotations, and then providing controls to hide away some of it depending on the wants and abilities of the reader is a very friendly thing to do.

But what is the best way to achieve that?

Let's say we have this markup, where all kanji are annotated, and the middle one which is taught in first grade, is annotated as "easy":

<ruby><rb>昆<rb>虫<rb>記<rt>こん<rt class=easy>ちゅう<rt>き</ruby>

Default styling shows the fully annotated text (colors added in to help non readers of Japanese to track the various parts):

But how should you go about hiding the annotation on the easy one?

• rt.easy { display: none; } doesn't work, as it messes up the pairing
  

• rt.easy { visibility: hidden; } will sort of work, but unecessary spacing is added around the second character to make room for it's (invisible) annotation. That's not only ugly, it can also impair readability, as adding spaces in the middle of words for no app arent reason can conf use people into thin king they're looking at separ ate words. (See what I did there?)
  

• rt.easy { visibility: hidden; font-size: 1px; border:none; margin:0; padding:0;} or something like that would likely work, but it's clearly a cumbersome hack.
  

There's currently no reliable and clean way to do it, but we could very easily add one through existing syntax that's pretty much made for this: rt.easy { visibility: collapse; }

A rather simple way to specify it would be that an annotation with visibility: collapse does generate a ruby annotation box (so unlike display:none it won't mess up the pairing`), but for layout and painting purposes, that box is rendered the same as auto-hidden annotations (thus providing an explicit way to get the same effect).

[css-meeting-bot]

The CSS Working Group just discussed [css-ruby] visibility:collapse on ruby annotations.

The full IRC log of that discussion

<astearns> topic: [css-ruby] visibility:collapse on ruby annotations
<astearns> github: https://github.com//issues/5927
<fantasai> s/???/nicole/6
<fantasai> fantasai^: And make sure it works on slow connections
<dlibby> florian: ruby has a number of use, but primary use is Japanese/Chinese annotation of ideographs for pronunciation
<dlibby> florian: different preferences based on how experienced you are with the language
<dlibby> florian: printed - in school you get most annotations, others not
<fantasai> s/language/language, and what reading disabilities you might have
<dlibby> florian: but on digital media, can you hide bits that you don't want to see?
<fantasai> florian: display:none doesn't work because it breaks pairing
<fantasai> florian: visibility:hidden doesn't work because the annotation still takes up space in the layout
<dlibby> florian: display:none fails because removes the box, box pairing is necessary, visibility:hidden doesn't work, pairing works fine, but still takes up space
<myles> q+
<dlibby> visibility:hidden may expand spacing made room for but it's not visible so that's not great
<dlibby> florian: visibility:collapse is another keyword, is a natural use here
<dlibby> florian: hids the annotation, but keeps a box preserving alignment
<astearns> ack myles
<dlibby> myles: two examples - people that don't want pronunciation and those who are dyslexic and may get confused, wouldn't author hide all?/
<dlibby> florian: maybe, maybe not. children-targeted annotations may only hide the 'easy' ones
<dlibby> florian: or perhaps you're practicing and you don't want the help for certain characters
<dlibby> myles: could this be a browser feature instead of individual webpages?
<dlibby> fantasai: but authors do need the ability to customize this
<dlibby> fantasai: also can autohide things that are not perfect matches for the text
<dlibby> fantasai: might need an exact string comparison to achieve this, but having some way to accomplish autohiding seems like a good thing
<dlibby> myles: use case is perhaps a bit narrow - this is yet another 'make it invisible'
<dlibby> florian: it's an existing mechanism
<dlibby> myles: but you're creating something new for ruby
<fantasai> s/achieve this/do auto-hiding/
<fantasai> s/seems like/manuall seems like/
<dlibby> florian: visibility:hidden almost does what you want, but the box consumes space, you could make it small via !important but is not great
<dlibby> dholbert: what about contain:size with visibility:hidden?
<dlibby> dholbert: does that cover all the use cases?
<dlibby> florian: contain:size does not apply to ruby boxes, if we're going to make new things apply, visibility:collapse makes more sense and is probably more scoped
<dlibby> astearns: is anyone using these hacks? do we know what things are easier/harder?
<dlibby> astearns: if no one is performing hacks today to solve this, do we need support in browsers
<dlibby> florian: there have been requests from ??? organiziations in Japan
<dlibby> florian: they want to write all possible ways to display and have the user/author choose, but current implementations of ruby make it such that it is unreliable
<fantasai> s/???/DAISY/
<dlibby> fantasai: we did get requests from a11y orgs in Japan, didn't make it up
<dlibby> astears: curious if exisitence of hacks can estimate how much people are running into this?
<dlibby> iank: does visibility:collapse influence the container size?
<dlibby> iank: mental model is that it affects the container, but removes itself at the last minute
<dlibby> iank: doesn't seem to be the case here
<florian> q+
<dlibby> iank: that's what happens with table and flex, i beileve
<dlibby> fantasai: flex affects one dimension but not the other
<dlibby> fantasai: we could specify it similarly for ruby
<dlibby> fantasai: it's a layout model specific thing - collapse the thing to see the layout without it, but dont' remove the box from the tree, but re-show in a dynamic way w/o disturbing
<dlibby> fantasai: this means different things in different models
<dlibby> fantasai: in flexbox affects space in one, but not the other. ruby proposal is to treat the same as autohidden ruby
<fantasai> s/re-show/have ability to re-show/
<dlibby> florian: riffing on 'yet another way to hide' - it already hides, the way in which proposed hiding is already a thing in ruby
<dlibby> florian: just marrying an existing property/value to existing behavior - don't need to invent anything new
<dlibby> astears: we're over time, perhaps can bring up again in the future
<dlibby> s/astears/astearns/

[frivoal]

Note: implementation wise, this ought to be pretty simple: both the syntax (visibility:collapse) and the behavior (the type of hiding performed in ruby auto-hiding) already exist.

[frivoal]

More use-cases that would be addressed by this were previously raised in https://lists.w3.org/Archives/Public/www-style/2016Dec/0108.html

[patrickdark]

Since an email I authored was cited, it's probably worth noting the use case:

I had a list of official song titles in English for many songs that had lyrics and titles in other languages, particularly Japanese. As ruby annotations, I provided the official song title in the native language of the song on a word for word and punctuation for punctuation basis. However, this would cause autohiding (i.e., text equivalency) problems because, for example:

• the Japanese script titles used fullwidth variants of characters such as the wave dash instead of the tilde and the fullwidth asterisk instead of the (regular) asterisk.
• the Japanese script titles were missing spacing around (e.g., mathematical) punctuation expected in English script.
• the Japanese script titles would need extra punctuation such as middle dots to separate transliterated names where English would instead use a space character.
• the Japanese script titles would need extra words such as the Japanese particle "の" to join adjectives to nouns in Japanese where English, again, uses space characters.
• the Japanese script titles would use different punctuation structures; for example, in the "Main Title: Subordinate Title" format of English versus "Main Title〜Subordinate Title〜" of Japanese. In this case, one would have a colon and space equivalent to a wave dash and nothing (i.e., an empty ruby base) equivalent to a wave dash.
• the English script titles would use hyphens, but these weren't present in the Japanese script or were replaced by middle dots.

Also keep in mind that these were official titles being documented, so changing the punctuation to match in a way that worked better inter-language by, for example, omitting spaces in one of the matching titles wasn't acceptable.

Additionally, I later wrote a polyfill script that would auto-merge annotations (a feature currently missing from browser implementations), so simply omitting the punctuation from the annotations was out of the question since this punctuation would need to magically reappear when ruby bases and annotations were merged.

Obviously, this solution doesn't address all of these cases, though I can see how removing noise by hiding punctuation in annotations could be useful. For example, for the Japanese song title "✱〜アスタリスク〜", one might just want to use the English word "Asterisk" as an annotation without the punctuation while fully annotating the text as *~Asterisk~* anyway to futureproof the code in case stylistic preferences change at a later date.

(*I had to mark this song title as code since GitHub apparently uses tildes to invoke the strikethrough text style.)

[johnfoliot]

Hello CSS WG,

The Accessible Platform Architecture (APA) WG have discussed this, and have a few comments to offer:

Toggling: While the requested feature has value to users with disabilities, there will need to be a simple toggling feature to 'collapse' or 'expand' the Ruby annotation (think Details & Summary), ideally authored on the page, or provided via a clear and easy to access toggle in the browser UI. While applying this in a fashion similar to 'prefers-reduced-motion' and using browser-based user-settings is useful, we anticipate a more time-sensitive context of application by some users (i.e. the 'toggling' need).

Relationship to Personalization TF activities: Currently the Personalization Task Force has some draft ideas around a similar use-case, which may work either as an alternative-to, or possibly in concert with this CSS proposal. Relevant information can be found at: https://www.w3.org/TR/personalization-semantics-content-1.0/#simplification-explanation

(NOTE: The Task Force welcomes the CSS WG's feedback on this, or other aspects of our Draft Spec.)

[css-meeting-bot]

The CSS Working Group just discussed [css-ruby] visibility:collapse on ruby annotations, and agreed to the following:

• RESOLVED: Add this defined hiding behavior to spec and ping engines to impl it

The full IRC log of that discussion

<dael> Topic: [css-ruby] visibility:collapse on ruby annotations
<dael> github: https://github.com//issues/5927
<nicole> fantasai thanks, makes sense
<dael> florian: When you have ruby and base is identical to annotation we have auto-hiding behavior. This needs to be impl
<dael> florian: What's not nice is it's only auto-applied. No way to manually invoke that hiding behavior. Only auto
<dael> florian: There are use cases to do it
<dael> florian: Since we have behavior, use cases, and syntax that would match to the behavior- proposal is map the syntax to the behavior
<dael> astearns: I brought up if this can interact with real world markup, but I'm not that concerned. Happy to go witht he proposal
<dael> astearns: Other opinions?
<dael> astearns: We could resolve to spec this up and see how it goes
<dael> florian: Spec is easy. Behavior is spec, just need to say this syntax matches the behavior
<fremy> I really like that the behavior in a browser that does not implement this is decently good
<fremy> So
<fremy> I don't see harm in adding this, worst case we remove later
<dael> fantasai: It gives you control over the hiding. You can hide things that wouldn't be hidden
<dael> astearns: Any idea if any engine is interested in impl this?
<dael> fantasai: Seems like easy to do in FF b/c they already impl auto-hiding. Wouldn't require a lot to make it work
<fantasai> s/be hidden/be auto-hidden/
<dael> florian: And we're not at CR yet. If we were close maybe, but at that point I don't think it's worth adding that noise
<dael> astearns: Worth adding bugs to systems to please try to impl?
<dael> florian: Sure
<dael> astearns: Prop: Add this defined hiding behavior to spec and ping engines to impl it
<dael> RESOLVED: Add this defined hiding behavior to spec and ping engines to impl it

[fantasai]

@johnfoliot Wrt toggling, I think that has to be handled by either the UA or the page because it requires some kind of UI affordance. The proposal here however enables the ruby layout support that such an affordance would require.

Wrt data simplification, it might be relevant to remove some annotations in response to that, but removing annotations generally (particularly those required as a pronunciation aid) does not seem appropriate.

[michael-n-cooper]

APA is ok with the disposition but wants to see test results demonstrating keyboard accessible collapse / expand.

[r12a]

I'm only just now reading this, and surprised that the CSS can't simply be .easy { display: none; }, but then i tried it out and was surprised that the layout renderer gets the pairings out of synch. Shouldn't the pairing be established before the relevant rt element is undisplayed?