I want to annotate atom positions in the SMILES string. I currently do this with ("pip install smiview") text over the string, as this example using phenol.
SMILES is a lovely standard, really simple and easy enough to write by hand, but powerful enough to describe real molecules in detail. Not long ago, i saw a chemical structure used as part of an illustration, and wondered what it was. I transcribed it as SMILES, put it into a chemical search engine, and found out what it was (nothing interesting!).
D'oh! Yup. You think I would know that by now. I'll attribute it to trying this out being the weekend, in the down times between the kids' bedtime routine.
As far as I can tell, the only content inside of a ruby tag should be annotated text or its annotation, the 1 that should not be annotated should not be inside the <ruby> tag.
But it's not as useful as I hoped it would be. Copy&paste captures the numeric annotations. I probably should have expected that, but didn't.
And highlighting is wonky. In Safari and Firefox, I seem to get a character and the ruby annotation for the character next to it, more often than I do the one overhead.
> Copy&paste captures the numeric annotations. I probably should have expected that, but didn't.
That's very likely a browser bug. Think about the accessibility implications (for e.g. screen readers) if ruby text was supposed to be modelled in the DOM as being interpolated into the text it's annotating.
I'm not sure what the standard says about how it should be treated, but my guess is that each annotation should be thought of as alternative for the text it annotates — ala the image "alt" and "srcset" attributes, or ala videos with multiple audio tracks in the same language, where one of those is Described Video or director's commentary or whatever.
In other words, the "correct" behavior would likely be that your browser knows the user's language prefs, and then chooses to select (or copy, or speak, etc.) either the text or its annotation, depending on which one the user is more likely to be able to read/understand.
> Think about the accessibility implications (for e.g. screen readers) if ruby text was supposed to be modelled in the DOM as being interpolated into the text it's annotating.
The <rp> tag exists explicitly for the purpose of interpolating the annotations into the text. So e.g. <ruby>漢字<rp>（</rp><rt>かんじ</rt><rp>）</rp></ruby> will look like 漢字（かんじ） to a client that doesn't support ruby text and a screenreader could read it the same way it would read any other text with parenthetical annotations in it.
The standard doesn't actually say what screenreaders are supposed to do, so I guess they could also try something fancy. But they don't have to.
My guess is that only the paste is broken, not the copy.
If the box you were pasting into supported annotations then it would paste perfectly. Pasting into a plain text text-area field leaves the browser with a hard choice to make on how to interpret the data in the clipboard when transliterating it into plain text.
It's something I've toyed with putting into my toy font renderers but it always seemed like it had a lot of edge cases. Length of the ruby text overflowing the width of the parent, in some to most cases a little overflow is ok but it's certainly not guaranteed. Scaling down the ruby text isn't the ideal solution because it quickly becomes unreadable. The other option is to scale the spacing in the parent text, which seems to be done for <ruby>境界面<rt>インターフェース</ruby> in the specification https://html.spec.whatwg.org/multipage/text-level-semantics.... but then that's going to impact the line wrapping and so on. Kudos to the implementators!
Weirdly I’ve only used this in anger outside of Japanese text, to replicate a semantic layout in the original printing of Tristram Shandy for Standard Ebooks (see book 3, chapter 11, the Latin version: https://standardebooks.org/ebooks/laurence-sterne/the-life-a...).
The `<rp>` tag showed in the examples, isn't explained on the page but is a fallback - something that should be rendered if the ruby tag is not understood.
Sadly, the rp page doesn't show any examples of what fallback behavior might look like.
In general, browsers will just drop tags they don't understand, while still rendering the tags' contents (as normal in-line text). So if, like in the example, you did:
But the browser didn't have support <ruby>, it would just render as:
明日 (Ashita)
The idea is that a <ruby>-supporting browser wouldn't need to render the parentheses, because it's going to display "Ashita" in a special way that sets it off from the regular text (so you "annotate" the parens with <rp>). But in a browser that doesn't support <ruby>, you'd want it to still display in a sane, understandable way, where it would still be easy to understand that the added text is a pronunciation hint.
I assume this was added as a way to implement language features such as Furigana, which is a minor, but useful, feature of written Japanese:
https://en.wikipedia.org/wiki/Furigana
Would this make sense for putting romanized text above non-roman languages?
I used it in my old and free iOS web browser to put translation (Spanish, French…) or Pinyin on top of English or Chinese words https://apps.apple.com/app/id932996489
For those studying a language that might use benefit from this, I have this CSS in my Anki cards. I use the ruby tag to remind me of readings for things that aren't the main focus of the card I'm working with. For example, if a vocab word is used in an example sentence, but one of the other words in the example is unfamiliar to me.
It shows the rt tag on hover or focus and works for me for both mouse and touch on Anki and AnkiDroid. Maybe this or some variation might help others as well.
Although Ruby element is basically a Japanese thing, it can be used to display both original text and translated text. I think using ruby rather than two-column-view is far better.
For example, this script[1] will show original English word above Japanese loan words, using the ruby element.
> Although Ruby element is basically a Japanese thing
It's commonly used in textbooks for different Chinese languages. I have ministry of education textbooks from Taiwan, and ruby characters are used for both Hokkien and Mandarin (the Hokkien one has two different ruby character scripts which is quite visually busy).
I would imagine it would be handy for Hindi learners as well. And probably hundreds of other languages, though I can't speak if it is used.
This is neat, and immediately made me think of the annotations that show up when you hit the play button on https://lowerquality.com/gentle/ , but it turns out those are made with absolutely-positioned divs and a lot of offline-precalculated px math.
> The <ruby> HTML element represents small annotations that are rendered above, below, or next to base text, usually used for showing the pronunciation of East Asian characters.
I got a little worried that browsers were going to support that horrible programming language with the same name as a script tag or something.
I noticed "It can also be used for annotating other kinds of text" and wanted to experiment with being able to number specific letters in a string.
More specifically, SMILES is a linear molecular structure notation. "O" is water, "COO" is ethyl alcohol, "c1ccccc1" is a benzene ring, and much more. (See https://en.wikipedia.org/wiki/Simplified_molecular-input_lin... .)
I want to annotate atom positions in the SMILES string. I currently do this with ("pip install smiview") text over the string, as this example using phenol.
I wanted to try it with ruby so I used: The "2" is located over the center of "1c" instead of over the second "c" like I wanted.How do I get it to center only over the "c"?
I tried changing the CSS too, using this catch-all:
No luck. I also tried wrapping things in a span, like: but got the 3 as a new ruby line, centered over the "1cc", itself with a ruby "2" between the second and third "c".I tried other combinations of <span>, to no avail.