A sutta garden: page layout for segmented texts

Following on from:

Now let’s look at how to achieve various layout designs. These are all responsive, so to see how they work, download the attached folder and open sn1.1-new.html in your browser.

sc-ux.zip (12.8 KB)


  • This is about the segmented texts only, I have no idea if anything will apply to legacy texts.
  • I will discuss the tooltip in another thread.
  • See here for the distinction between “main” and other references. (Note: not visible in latest design)
  • This about page layout, not UI, the buttons are only there to help showcase possible layouts.
  • The CSS is obviously not production-ready, nevertheless it uses SC styles for the most part. It should be refactored to apply per function, not per page.

Basic concepts

  • Typography remains similar to currently.
  • As now, the default view is a single language.
  • Comments and Variant readings (collectively, “notes”) are available via tooltip by default.
  • User may enable references.
  • Design of reference “chips” is the same regardless of position (unlike currently)
  • The views labelled “Plus” show the Notes.
  • These are in the margin where there is enough room, otherwise inline.
  • Notes in margin may overlap. In this case, click to raise an obscured Note.
  • Side by side plus view makes great use of a wide screen.
  • One change in the typography is that verses are now indented rather than centered. It keeps things simpler.
  • In “Plus” views, each segment is on a new line.
  • Unlike current site, segment lines are not vertically separated. Thus you get a better picture of the paragraphs. Each view is optimized for best vertical layout.
  • Notes have icons + color to differentiate them.
  • Current ability to show Pali segments with tooltip is removed. (Not the Pali lookup!)


The secret sauce is CSS Grids. These didn’t exist when we did the original layout, and even when we made the revised site they were just starting to get mainstream. However they have 93% browser support these days.

Grids are an extremely powerful layout tool, as they let you declaratively assign elements to grid columns and rows. So we can simply use CSS to tell the page how many columns, what goes in which column, and how wide it should be.


For the UI, I envisage letting the user select:

  • SC references show/hide
  • Legacy references show/hide
  • Notes show/hide
  • Plain / Side by side / Line by line


The overlapping notes are my main concern. Essentially this arises because they must be made position:absolute so that they can span multiple rows, otherwise long notes would force the grid to have big empty spaces.

One thing that should be done, when clicking it raises the note, but this should be sticky, which is not possible in CSS and must be done in JS.

More complicated, and probably best left for now, I wonder if we can use JS to detect a collision between two absolutely-positioned notes, and cut short the upper note, leaving, say, a jagged edge to indicate it has been truncated. Then click would raise and reveal the whole note.

Icons must be done properly, this is just for demo.

Apart from that, the main thing is just to test them in a wide variety of texts.


I can’t see any attached folder… :eyes:

Ahh yes, post the message without the attachment: we’ve all been there, many times!

Now fixed.

1 Like

I’d say it’s pretty … COOL! :snowflake: :penguin: :heart:

My preferred reading is Line by line +. :star_struck: (When working on it; when just reading I’d perhaps prefer a simpler view.)

Will change of settings be available from any place on the page, or does one have to scroll all the way to the top in order to change it?

1 Like

Indeed, that’s what the different layouts are for. They all have uses, I think. But on a big screen, side by side plus is pretty cool. It’s rare these days to find a layout that really makes use of a wide screen.

We will make the controls more accessible than they are currently. Not sure of exact solution yet.

1 Like

*Whistling while admiring the sky, mentions quietly under breath* I think it’s just called “CSS Grid”

Overall it’s great, I particularly appreciate the ability to read notes as I often find them very helpful/fascinating. I’m also fond of the reference options.

As an aside on notes; from a cursory Google I’m guessing the whole web annotations thing you where interested in before died a death…?


One detail I think could be worth considering is how notes are linked to the references in the “+” views. As it currently is, it’s not quite clear exactly what text part a note is connected to. Maybe something similar to the grey highlight on the current site used when an anchor ID is included in the URL, eg https://suttacentral.net/sn1.1/en/bodhi#sc4.

Very cool! Curiously, though it doesn’t work in FF 69.0 (64-bit)

Works in Chrome.

In fact, I think there might be a number of differences in the browsers render the page. At least this one:






While appreciating the fact that the paragraph is being honoured, having text smushed together so densely hurts my brain to the point that in most cases I’d elect not to read it.


Not at all, in fact I am thinking of this as a method of enabling annotations. I am still not sure of the details, but I imagine that a set of notes would be simple JSON (or any tuples really) with form segment ID : note. They could be made on Bilara or elsewhere.

The comment is decorated with metadata for language, author, and (optionally in JSON config on bilara) type (say, “beginners”, “atthakatha”, “linguistic”, “meditators”). This feeds in to the HTML, eg.:

<span class="comment" lang="en" data-author="sujato" type="linguistic">

A user then can choose to see notes based on author, type etc.

Good point. But it seems we can only do this by adding a class such as has-note to the parent .translation or sibling .text class; we can’t inherit “up” the tree. It’s not difficult to do so, but let’s leave it for now and see if it is really needed.

Ahh, no, that’s how it’s supposed to look. The quote is not in a new paragraph.

Notes will overlap or not depending on how much room they have. Window width, zoom size, line-height etc. will affect this. The two examples have different fonts, for example. Let’s wait until we have alive version before tweaking this. Any browser based differences should, I think, be minor.

Yes, a bit of extra room wouldn’t hurt. But just note, this too is a font thing. Skolar leaves a bit more vertical space. Looking at the CSS, I can’t see anything that creates this problem; for some reason the .root segment appears more cramped. Let’s leave it for now and see how it looks on the site.