We’re developing “publications” a process to publish full sets of SC translations as “books” in HTML, EPUB, PDF, and paper.
This is a specific question that I am ruminating on, and would appreciate some feedback. @Snowbird @Brahmali @Suvira @Charlotteannun @cdpatton
And others!
We have stacks of references per sutta. On SC, we can enable or disable these according to user preference. These are highly dependent on the user’s location; someone in a canadian University will want to see the PTS editions; a yodi in a Sri Lankan retreat center will want to see the Buddha Jayanthi; while someone in a Thai forest monastery might want to see the Culalongkorn edition.
When we publish books, the user interface is largely static, and the user cannot select what they want to see. But if you see all of them, the text is unreadable. Indeed, the readability is reduced each time you add a reference series.
So what to do?
option a: just leave them out.
Simple, effective. Someone who wants to check cross-references will do so on the website.
option b: select a few useful ones
This is what we’re doing so far: include the SC main references, the BJ, and the PTS. Both too much and too little IMHO.
It looks something like this.
Now, if we don’t want to display them all by default—and I don’t—we can then add a user config in the CSS. Hide all the references by default, then add a CSS knob like this:
/*
.sc-main.ref
{
display: inline;
}
*/
Users can enable whatever they want. This would work in both standalone HTML and EPUB. Obviously it requires a degree of user tech savviness.
option c: define references per edition
We could add a configuration option to add references per edition. If I’m publishing a book in Sri Lanka, for example, I could add the BJ references. But this would multiply editions unnecessarily, adding a complex process to the build chain.
option d: embrace the madness, include them all
The problem is there are quite a few, and the markup for each is somewhat verbose. For example, in the case above the first three references look like this:
<a class="sc-main ref" id="mn30:4.1" href="#mn30:4.1">MN 30:4.1</a>
<a class="bj ref" id="bj10.480" href="#bj10.480">BJ 10.480</a>
<a class="pts-vp-pli ref" id="pts-vp-pli1.199" href="#pts-vp-pli1.199">PTS-VP-PLI 1.199</a>
In the Majjhima file, there are about 30,000 such references, even though we only have the three types! If we included all references, it’d be maybe 50,000. That means 50,000 DOM nodes on a single page, for the references alone. Google recommends no more than 1,500 DOM nodes in total. So.
option e: include the first reference per paragraph as data attributes
This is an idea I just had, and I’m leaning towards it. The idea here is that we can use the pre-existing paragraph tags, and add the references to them. Select the first instance of each type of reference, and put it there.
<p data-ref='sc-main-mn1:1.11, bj10.2, cck12.1, csp1ed9.1, csp2ed9.1, dr12.1, ms9M_2, msdiv1, ndp9.3, nya1, pts-vp-pli1.1, sya12.1, vri12.1'>So have I heard …
Now, these remain inert, they don’t add to DOM so they don’t affect page loading or performance. But they can be made use of by a user in various ways.
- For an occasional check you can inspect the source in the browser.
- if you want to display one set, you can do a regex and make visible references.
- someone who wants, for example, to make their own book can manipulate these as they like before adding the HTML to Word or whatever.
- And so on
Or slightly more verbose, each reference could be its own data-attribute, that way they could still be styled in CSS.
Any thoughts?
