Some thoughts on responsive design for the new tables. Assuming we use the latest design, it is somewhat expansive horizontally. It should have a sensible progression of shifts at any screen size. Here are my thoughts on the sequencing:
As usual, use no-break spaces for IDs and vol/page, as these rapidly become incomprehensible if broken. On the other hand, use soft hyphens for long titles.
The first shift should be title wrapping and/or stacking the text buttons vertically, and/or putting the title on the next line in the 'root" column. (Stacking the text buttons works currently, but requires that they be within the same <td>.)
So that’s all pretty basic and more or less what happens already. Next, we should lose the vol/page column.
Next, lose the description of the relation types, just have a plain connector with a title element.
Finally, lose the table-cell display for the “related” column elements. Instead of having them vertically aligned, just have them collapse to their natural spacing, using display:inline-block, I guess.
If that’s not sufficient for small mobile screens, make the final collapse to a “full-vertical” layout, where both the left and right columns stack all elements vertically. Not sure if this will be necessary, though.
I was just looking at SuttaCentral and noticed that everything is done double here. So such things need to be taken out.
It has to do with the fact that these are mentioned twice in the parallels.json file (I did this on purpose so it is not necessary any more to do any inferences).
It makes it easier to read the parallels.json file without having to go through all the possible inferences. So just an adjustment to the programming is needed.
I have created a list of all the pts and other numbers that correspond with sc numbers in the pali texts. I realised that for the most of the Taisho texts this does not need to be done because the url#id already show the t-linehead numbers. Only the Dhammapada texts are different because they have sc-verse numbers.
This list only shows sc numbers where other pts or ms numbers are mentioned in the same line also.
To be honest, it is probably just as easy for @Blake to just draw the right number out of the html text when it is needed so no separate lists like these are necessary. It is just a very straightforward bit of python code to do that.
What about cases where we are not in a text? I’m thinking of the Dictionaries, for example. It would be great to linkify all the v/p references there. Would it not be simplest to use a json file for this?
It’s usually not a good idea to have the same data in two different places.
Right now only the PTS numbers of the start of the sutta are mentioned in sutta.csv and this is what shows up in the Vol/Page references in the sutta list of that Nikaya. Inside the text we have all the numbers for instance in MN1 we have <a class="pts" id="pts1.1"> to <a class="pts" id="pts1.6">.
These numbers I retrieved in a csv list (can easily be converted to JSON) and matched them up with the corresponding SC paragraph numbers. However, there are far more SC paragraph numbers in between and that makes those a more precise reference for use with parallels.
Blake is currently working to change the whole system to JSON so also sutta.csv will have to be converted into the new system.
When you have a page that lists parallels, you are not in the text either.
My take was primarily the parallels pages, but yes, Dictionaries would also be good to have linkified. So Blake can either use my list or use a small python script to search for the respective number in the text. The first option is probably a bit quicker loading, but the second safer if our own numbering system changes, even slightly.
When I started working on the parallels, I found that a lot of the cross references did not work any more because our own numbering systems have evolved over time. At least with the pts numbers you know they won’t change: they keep being linked to the same text.
On the other hand, the parallels.json file now uses the sc paragraph numbers for link-ids because these are more precise. So if things change, so should the parallel’s notation.
So just some thoughts on this. Blake can see what he feels is the most appropriate method.
That’s the beauty of standoff properties. You keep the text purely as plain text, and everything else is separate.
See the files I recently shared. The data is preserved in a separate json file, which has essentially three kinds of information for any given piece of markup:
the start point (i.e. number of Unicode glyphs from a previously defined point)
the length (in Unicode glyphs)
the type (which could include data we treat under class and id in CSS)
Using just these three pieces of information it’s possible to replicate without loss anything that can be done in traditional hierarchical markup like XML/HTML. It’s also possible to do many things that they can’t do, one of which is exactly the problem we’re facing here: overlapping hierarchies.
“Possible” is of course a theoretical term. The tools aren’t mature enough to achieve this yet. You need, at a minimum, an editor that will reliably push any changes to the source text into all relevant standoff files. To guard against corruption, run everything through Git.
But this is what Yap is working on (full time!) Ultimately we’d like to work towards making SC texts interoperable with CBETA, which isn’t possible as long as we have a different hierarchy (i.e. we use suttas, they use volume/juan/page).
I have an even more radical idea: assign every character in the texts a blockchain ID. That way any changes to the texts are public, permanent, and incorruptible.
Sure, but if you use a layered approach, you need to have some way of being able to link the layers together. If you just have a text and a file with pts numbers, you still need to have a system to make sure you know where in the text the pts numbers belong because pts numbers don’t have the same logic (vol/page). You can give each sentence (or even character) an id, but you still need to have a file that tells you which pts number goes with which sentence id.
In theory we could already do that now: i.e. just leave the sc numbers in the html text and then use an external file that tells you what pts, ms and other numbers should go with which sc number.
Attached a new version of the lists (pts list now also has sc-verse numbers in it).ptstaishonumbers.zip (567.4 KB)
This is precisely the problem that standoff properties solve. You don’t need IDs, you just need the offset and range to tell you where things belong.
The only extra thing you need is something to tell you where it all starts, ie. coordinating the overall text. But that can be as simple as including them in the same folder (as is done in the samples Yap shared).
You can, but it wouldn’t be lossless, as the granularity isn’t fine enough. You’d only get an approximation, because some of the v/p numbers appear in the middle of a paragraph.
Totally off topic, but actually as of this year, checking whether the photo is of a bird can also take a couple of hours. Apparently the Google Cloud Vision API can even give you the breed of a dog in a picture.
I’ve been messing around for a bit creating another mockup. This one is done with bootstrap, just to get an idea but the same is possible with css (other than tables) but I just have to figure out how. I just like the whole idea of the grid-system. It makes life very easy. The css of the attached is a bit of a mess and the design is by no means ideal, but have a look.
Ayya, this looks fine, but I should warn you: the whole approach is a non-starter. These are tables, and we will use table markup to express them. This is one of the fundamental principles on which I built SC: always use valid, semantic markup.
Tables are much more difficult to deal with when you want something to be responsive.
But fine, I will adapt your table-based mockup with the ideas for the responsiveness that I showed here as well as another connector.
Now can you just make it work on the whole site? 
