Known elsewhere as “routes.”

<route path="/plays" to="plays" />
<route path="/plays/{play}" to="play" />

“The plays” is an interesting and special location in willshake. As things stand, “the plays” is just the sign that nominally stands between the entryway and the individual plays, and is of much less interest per se than either. But it is the jumping off point for almost forty featured paths.

It is the one place where we are strongly compelled to show all the plays together.

The plays page has two main purposes:

1. Navigation to a particular play
2. Help understand the plays as a whole in various aspects.

Currently, the /plays path is what you might call a “no-op.” It doesn’t do anything. The only thing that changes is the title.

<title>Shakespeare’s plays</title>

Otherwise, it’s identical to its parent page (also known as the “home page”).

It’s odd to have a “pointless” path like this, but there are a number of things to consider. The existence of /plays is driven largely by the logical structure: it does make sense to have the plays under a dedicated “directory.”

And it’s not hard to imagine how that might translate into a spatial structure—indeed, it may be too easy to think of what the “plays” part of an exhibit might look like. But ultimately, the important function

The play resides in the document layer. The document layer is a layer separate from the main exhibit.

#document-layer <append>

<article id="play-{play}" class="play" data-play="{play}">
  <div id="scene-text" class="scene-text">
    <a id="top-of-scene" />
  </div>
</article>

<<play entryway>>
</append>

Note that the play entryway layer is in the document layer, when you might expect it to be right under body with the other layers. This is because (as ought to be discussed in layers), there’s only one way for a full-screen, gesture-scrollable but partly-transparent layer to allow click-through to another layer—and that is for it to be the default overflow container, i.e. the document element.

When you visit a play, the experience is in many ways like the main entryway. Just like the main entryway, there’s a large backdrop establishing the space, a large sign pointing to the main content, and one or more “sheets” serving as an overview of that content.

<div id="play-{play}-entryway-layer" class="play-entryway-layer scroll-layer">
	<site_beacon to="the_works" />
	<div class="play-entryway-content">
		<a id="top-of-{play}" />
		<<play entryway sign>>
		<div class="play-entryway-pane">
			<a id="play-{play}-top" />
			<<play sheets>>
		</div>
	</div>
</div>

(There’s also an anchor that lets you link to the top of the entryway.)

Also like the main entryway, this one is a definite size. There’s one screen’s worth of “open” space at the beginning and the end. In the middle is a compact “sheet” representing the play as a document. This will be two screens high, so the whole thing together will be four screens high.

.play-entryway-pane
	dock-top()
	height 100vh
	transform translate3d(0, 0, 0)

	.play-entryway-layer.active &
		height 400vh
		transform translate3d(0, 100vh, 0)

Now, we have to get ahead of ourselves a bit here. When you actually enter the play—that is, go into a scene—the arrangement changes a bit. The entryway layer stops being scrollable, showing only the top “sheet” of the play, as a reference. Thus, the open space at the bottom and top cannot be reached directly. That’s why we have different rules above based on whether or not the entryway is considered a scroll-layer.

There’s a bit more discussion of this change in the section play “sheets”.

It’s difficult to do this transition seamlessly. The present solution is a compromise that prioritizes the most common cases.

When you go from the play entryway into a scene, two main things happen: the scene text slides in from “stage right”, and the play’s main sheet “docks” into the window, and the entryway layer is no longer scrollable. Usually, the latter change is not noticeable, since the main sheet will already be “snapped” into view when the provided links (such as the entryway sign) are used. If not, the sheet does “jump” into place, but it’s usually not by much. Besides, there’s so much else going on, that the transition would not reliably be smooth anyway.

But when you leave a scene and return to the main sheet, the transition can be distractingly jumpy. This is because the entryway layer is suddenly scrollable again, and the sheet is “pushed down” again. And because the provided links have anchors pointing to the main sheet, it will be scrolled back into place, adding to the vertigo of the effect. As it stands, the existing transition is carefully chosen to avoid a bug in Chrome for Android, where the overflow height of the play-entryway-layer is simply not recalculated at the end of the change, leaving it in an invalid state.

The simplest way to avoid this “jump” is to apply all changes—the style changes and the scrolling—at once. getflow allows you to bypass scroll animation for a target by setting a special attribute.

<a id="back-to-{play}-choices" getflow-scroll-behavior="auto" />

So for links that are coming back to the play from within a scene, this anchor should be used instead of #play-{play}-choices, which is otherwise the same place. See getflow for the rationale behind this approach.

The following section elaborates a bit more on this structure, particularly the need for a site_beacon.

We think of the play loosely as a document, comprising a number of sheets.

The notion of sheets is introduced as an “expansion joint,” though—something that can be used by other feature that come later. To start with, there is only one sheet.

<section id="play-{play}-sheets" class="play-sheets">
    <<play main sheet>>
</section>

I’m not 100% sure what this is for.

#Shakespeare <class remove="plays-path" />

On #exhibit, this is just for the keyboard hack. See load script. scroll-layer is also primarily for scrolling to anchors.

#play-{play}-entryway-layer <class add="active" />
#exhibit <class remove="active" />
#document-background-layer <class add="active" />
#document-layer <class add="active" />

When we open a document, we have to explicitly indicate the change in scrolling layer.

html <class add="not-scroll-layer" />

#play-{play}-entryway-layer <class add="active scroll-layer" />

Of course, the plays have to be available for use on the web site.

In order to use the plays on the web site, we have to copy the text there.

# The first set is just indexes.
: foreach $(PLAYS)/*.xml |> !copy_to |> $(SITE_PLAYS)/%b

These indexes of the plays may change. The best way to make sure that they’re up-to-date is to version them, as described in the web server’s discussion about coherence.

: foreach $(SITE_PLAYS)/* | $(PROGRAM)/<hash> \
|> ^o hash %b ^ %<hash> %f > %o \
|> $(ROOT)/hashed/%b

Instead of copying each section individually, I’ll just symlink the entire directory.

: $(ROOT)/Tupfile.ini |> ln --symbolic --relative $(PLAYS)/sections %o |> $(SITE_PLAYS)/text

I’m not versioning the sections, because there are 900 of them. It wouldn’t be worth adding these to the prologue, since they shouldn’t have any breaking changes. But the indexes might.

/ play sections : the container in the play page for play section overview and, / on the section’s page, its full content

@import colors
@import docking
@import paper
@import play
@import scene
@import transition-timings

Layers.

The play resides in the document layer, which is completely dedicated to whatever document is open. Except the “beacon,” nothing else will be visible when a play is open.

The play is a document comprising various sheets.

The play area contains three top-level layers: the entryway, the timeline, and the document.

The entryway is a fixed-size area where you can see the main ways that you can go from here. All of the substantive areas are in front the entryway.

The timeline layer is a navigational underlay which is also independently browsable in a dedicated path.

The document contains the text of the play as well as its marginal annotations.

@import layers
.play-entryway-layer
	// Regarding the compositor argument, see note in the "beacon" section
	// below.
	scroll-layer(compositor: false)

The play description.

This is like the region messages in #Shakespeare and upstream/downstream.

@import centering
@import scene
@import responsive
.site-play-description
	color rgba(#111, .9)
	text-align center
	centered-block(width: 20em)
	max-width 100%
	padding 2em
	box-sizing border-box
	//border 4px solid yellow
	+wide-screen()
		font-size 200%
	p
		// Ensure that the scene text covers this when it's open.
		max-width $sceneTextWidth

One convenient way to add features is through stylesheets. You’d be surprised how much you mileage you can get out of generated CSS. There’s already a pipeline for adding stylesheets to the site, but that’s really for generic styles. I’m talking about styles specific to each play.

head <append>
<link rel="stylesheet" href="/static/style/{play}.css" />
</append>

It should be trivial for features to get styles into that file. With the following rule, you can write stylesheets in the form {play}--* to the css/plays directory and have them automatically bundled.

: foreach $(PLAYS)/* \
  | $(CSS)/plays/<all> \
|> ^o (alternate) bundle play styles %B ^ \
   cat $(CSS)/plays/%B--* > %o \
|> $(SITE_STYLE)/%B.css

That will probably break if you remove all of the features that use it (i.e. write play styles to be bundled), because the shell will take the glob pattern literally, producing an error. But the advantage of the above method over scanning the whole group list is that Tup will only rebuild the necessary styles when a play’s source changes, rather than all of them.

Should this be under “the roles”?

We’ll count the lines with a little Python program:

"""Reads the given play document and writes roles section with line counts."""

import sys
from lxml import etree

index = {}
playDoc = etree.parse(sys.argv[1])

play = playDoc.getroot()
for speech in play.findall('.//speech'):
    lines = len(speech.findall('.//line'))
    for speaker in speech.findall('speaker'):
	role = speaker.get('role')
	index[role] = index.get(role, 0) + lines

for role in play.findall('.//role'):
    role.set('line-count', str(index.get(role.get('key'), 0)))

roles = play.find('roles')
roles.set('play', play.get('key'))
sys.stdout.write(etree.tostring(roles, pretty_print=True).decode('utf-8'))

Then we’ll call that for all of the plays:

: foreach $(PLAYS)/* \
  | $(PROGRAM)/index-roles \
    $(ROOT)/collated/plays/<all> \
|> ^o index roles for %B^ \
   $(PROGRAM)/index-roles $(ROOT)/collated/plays/%b > %o \
|> $(SITE_PLAYS)/%B-roles.xml