Add a way to indicate the semantics of ruby annotations

This issue is a copy of https://github.com/w3c/htmlwg/issues/27 and https://github.com/w3c/ruby-t2s-req/issues/34 in the repository that holds the current definition of the Ruby elements. Copying @cookiecrook's summary/interpretation of @murata2makoto's requirements document:

This following comment does not represent a consensus view of any organization (WG, employer, etc). It's just a collection of ideas that may be helpful in your progress to find a workable solution.

You mentioned three functional distinctions in your use cases, but I see several more semantic content types in the User Requirements page. I'll attempt to outline them here, including similar examples in English. Note that category 2 (phonetic-optional) incorporates both a speech use case, as well as the mainstream use case you mentioned today. To allow the user to toggle the visible display of these optional groupings.

The bolded names categories are just suggestions to help me keep them straight. I'm not particular to the names.

1. phonetic-required: Phonetic usage where the rt should always be visibly displayed and pronounced, as it defines an uncommon pronunciation that most would not know.

   • your unusual people and place names example
   • As a similar place example from the US, there is a road in Austin spelled both "Manchaca" and "Menchaca" but is pronounced by most locals as "Man-Chack."
   • possibly your Dewanai example, which as I understood it, is equivalent to the English "My name is Knotnot" which means "My name is Knot" but may be misspoken by TTS (and misunderstood) as "My name is not Knot."

2. phonetic-optional: Phonetic usage where the rt provides a pronunciation hint to less-experienced readers. Toggling the visible display of these may be be context dependent, as experienced readers would not need them and may find them distracting. Text-to-speech may(?) pronounce the base text as it is sometimes less ambiguous than the rt, but in most cases, the TTS pronunciation of the rt or base will be identical.

   • Beginning to intermediate readers, such as your furigana examples
   • Difficult-to-pronounce Species or Pharmaceutical names may be appropriate to include here, such as oxoerythromycinoxo-eur-ithro-mycin or oxoerythromycin/ɒk.sə(ʊ).ɪˌɹɪθ.ɹə(ʊ)ˈmʌɪ.sɪn/. Some readers may find the pronunciations helpful, where a domain expert may prefer to hide the pronunciation.

3. phonetic-complementary Phonetic usage where the both the rt and the base should be spoken.

   • Some of your Gikun examples such as 背景バック (HAIKEIback). These are a type of phonetic usage, but in this context, the phonetic rt kana does not define the pronunciation of the base, so the text-to-speech user would miss out on some context if only one were spoken.

4. notes Interlinear notes, a non-phonetic usage where the both the rt and the base should be spoken. Similar usage to a parenthetical in western languages.

   • 徳川家康1543-1616 江戸幕府最後の将軍, effectively "Tokugawa Ieyasu (1543-1616, the last shogun of the Edo shogunate)"

5. wordplay? another non-phonetic usage where the both the rt and the base should be spoken. (I'm not certain "wordplay" describes all similar uses)

   • Your example of enemyfriend meaning frenemy (I could not copy the Japanese text out of your images)
   • Another example from a colleague: 丁度良い所に常連カモが来たよ (look, here comes a regular customer now) where 常連 (regular customer)’s ruby says カモ (easy target/victim)

The semantic categories 3, 4, and 5 equate to the same functional category: "always display and speak both" so they might be combined (parenthetical) if there's no other functional need to keep them separate.

What about proposing a new type attribute on the <ruby> element with values [phonetic-required | phonetic-optional | parenthetical]?

Once the Ruby/HTML working group agrees on a specific attribute, we could map it to accessibility and speech APIs to achieve the correct pronunciations, and use it for the other education use case of a visibility toggle on optional Ruby.

Start by reading the linked W3C HTMLWG and Ruby T2S requirements issues, then compare their use cases with the proposal in this issue. The work is not ready for a focused implementation until the working group agrees on the semantic categories and the attribute design; done would be a documented, agreed specification direction.