Beyond the tooltip (2): variant readings

Meta dev
1

Note, ignore this, it is all wrong and bad!

Following on from my previous post on removing tooltip for lookup:

The next candidate for reconsidering is the variant readings. These are currently in a bit of a mess, and as with the lookup, we are trying to do too many things; loading a whole <table> into a tooltip. :scream:

So there are a number of possibilities.

  • Keep as tooltip, just do it better.
    • Same problems as before; too much info, complex info, inaccessible.
  • Just display the variants inline
    • Okay, this is robust. But it seriously interrupts the flow of reading.
  • Make marginal notes
    • There’s no margins on mobiles

Rejecting all those, I suggest we have right-floated notes.

  • Float the variants to the right of the text column
  • use both color and text style italic to match source with variant.
  • add an icon (this will help with differentiating variants, corrections, and the like.)
  • The variant appears on the same line as the root, or if there is not enough room, the next line.
  • Use title attribute to list editions. (Knowing the edition for a variant is unusually uninteresting: the main thing is that the variant exists.)
  • This approach means that variants can be visually scanned.

Here is a mockup.

variant-reading-redux-desktop
variant-reading-redux-desktop1915×1215 237 KB

For markup, I propose the HTML <var> tag. This is intended for variables in mathematics. But the usage is not too dissimilar, and it is a nice handy inline tag.

The markup can be done with a simple pair of <var> tags:

<var class="mainline">right</var><var class="alternative">wrong</var>

A more elegant solution might be to use data-variant and insert the content as a pseudo-element in CSS.

<var data-variant="wrong">right</var>
<style>var:before{content: attr(data-variant) ""}</style>

This has the advantage being cleaner and more semantic. Also, if the CSS fails it defaults to showing just the mainline text. A disadvantage is that the variant cannot be selected. On the whole, though, I prefer this.

If this approach proves suitable, it should probably be extended to other information currently displayed via tooltip, such as corrected text, etc.

2 Likes
2

This might create complexity for Voice HTML stripping. Voice strips HTML as decorative and retains all text content. Therefore Voice would incorrectly present “right wrong” to the user for the proposed use of <var>. :thinking:

Voice doesn’t use a robust parser–it lacks context sensitivity and is at best just a lexical analyzer. It certainly is possible to look for the <var class="alternative">, but that is a bit of a slippery slope to maintenance hell. Note that this may be a secondary concern given that Voice is currently focused on primary, supported translations rather than variant readings.

2 Likes
3

Variant readings concern the root texts rather than translations. Like for example (just a text where I know there are some “var” examples):

https://suttacentral.net/snp1.8/pli/ms#1

Variants are displayed in dark purple font color, so if you have the dark theme you will hardly see them; or the actual variant will be displayed only when you hover with your mouse over the purple text (btw, this too doesn’t work on Firefox).

I don’t remember Aditi ever saying anything about variant readings.

1 Like
4

I’ve searched all the suttas used by Voice and only see things like <i> (which is italics). I don’t see any <var...> elements–perhaps they are filtered out during presentation. Voice looks at the delivered HTML, not the authored HTML. If <var...> does show up in the presented HTML, then Voice will start misrepresenting the Buddha or the translators by concatenating all the local variations. Voice also doesn’t display variant root texts, so perhaps this is also something to consider.

1 Like
5

This is tangential to the topic, but what is the thinking about the Taisho’s alternate readings? CBETA embeds them into their XML files, so I would think they could be processed in an automatic fashion, but I see they aren’t included on Sutta Central. The next question after that regards the corrections that CBETA made to the Taisho, which I guess represents another layer of alternate readings.

2 Likes
6

Yeah, sorry to create confusion for y’all, I realized after posting that this is all wrong! A new, bigger and better post is coming!

They should be there, although perhaps there is a display bug. My aim in transforming the CBETA texts was to not lose any information.

The more long-term issue here is the ongoing improvements to Unicode and removal of gaiji. When this is (reasonably) complete we should redo all the Chinese texts, and can consider these points anew then. But I don’t have a roadmap for this as yet.

2 Likes
7

Now that I look at the html files in sc-data, I see that you do have the CBETA corrections documented with span tags, and it pops up the tool tip. But the Taisho footnotes aren’t there.

I bring it up only because the alternate readings can be important when working with the Taisho. It incorporated later editing that scholars sometimes discard in favor of older editions, and the Taisho editors scrupulously footnoted their text to indicate the older edition readings.

1 Like