Implementing an editor for interlinear glossed text

In this chapter we begin to design and implement an editor for interlinear glossed text. For the initial implementation, we will define an “interlinear glossed text” as a data structure which contains at least (1) basic metadata about the text, and (2) a list of sentences with transcription, translation, and morphologically analyzed glossed words. This basic data structure is sufficiently detailed for the design of the editor, but as we shall see in subsequent chapters, it is extensible to any other data types that the linguist deems useful. In later chapters we will explore how to combine interlinear texts created with this tool into both a corpus (by combining multiple texts) and a lexicon (by extracting words from texts), and how to carry out detailed searches over those aggregate structures.

The primary task of the editor is to assist the linguist in efficiently creating and using documentary data in structured as text as defined above. As we shall see, the amount of code necessary to carry out that task is fairly small: on the order of perhaps a dozen or so pages of HTML, CSS, and Javascript. (The content representing actual content — to be stored as JSON — may be much longer than the application code used to create it.) This is possible because the web platform is already both standardized and robust. Its capabilities include text encoding (@kesteren_encoding_2019), text formatting (@etemad_css_2019), interface layout (@atkins_css_2017), media playback and processing (@adenot_web_2018), user interaction (@le_hegaret_document_2003), network connectivity (@kesteren_fetch_2019), video and audio subtitling (@pfeiffer_webvtt_2019), among many others. For the purposes of designing the editor, we will use only a very restricted subset of those capabilities, bearing in mind that many avenues are open to future contributors who wish to explore the application of other functionalities. We will introduce the necessary programming skills as we go. That this is feasible is evidence of both the power and robustness of the web platform: put simply, we suggest that it is feasible for working documentary linguists to learn to understand this sort of software development within a timescale which is short enough that it can benefit ongoing research.

At this point it is worth looking forward briefly, in order to orient ourselves within a fairly complex web of what may be unfamiliar technologies. While the set of technologies that constitute the web platform as a whole (see above) is vast, here we be making use of just four key web technologies:

  1. Hypertext Markup Language (HTML) A markup language, which allows information to be arranged hierarchically and labeled in a granular way that makes reference to specific components of the document easy.
  2. Cascading Style Sheets A style language, which makes it possible to declare how particular parts of a structured HTML document should be displayed, and how interfaces should be laid out.
  3. JavaScript Object Notation (JSON) A data interchange format, which may be used to store and transmit hierarchically structured data (in the form of objects and arrays as per the previous chapter) without reference to how it should be displayed. It is lightweight and designed to be human-readable. Perhaps the simplest way to think of JSON is as a format which can record precisely the sorts of objects and arrays we described in the previous chapter. As we shall see in chapter 4, the mapping between the abstract tabulations described in chapter 2 and JSON syntax is quite direct.
  4. Javascript Javascript is a programming language. A programming language is a strict set of syntactic rules for encoding plain-text instructions which can be ‘run’ or ‘executed’ within some context. In our case, the execution context is a web browser: all web browsers contain a Javascript interpreter which can “read” code written in the language and carries out those instructions in order to generate, modify, or otherwise interact with the content of documents that the browser is displaying.

This ordering also corresponds to the stages of development our implementation will follow.

Outline of Editor Development by Chapter
Chapter Capabilities Technologies
3 Formatting documents as Interlinear Text Format HTML + CSS
4 Dynamically generating Documents HTML + CSS + JSON + Javascript
5 Interactive Applications with persistence HTML + CSS + JSON + Object-Oriented Javascript + Events

The guiding principle of this arrangement is learnability for working documentary linguists. The robustness and utility of the editor will increase as we progress. But note that this orientation results in a kind of misleading impression in the early chapters. For instance, the current chapter advises that the reader try hand-coding HTML in a text editor. This process is quite painstaking, even tedious, and can be error-prone. (It is for this reason that we will be dealing with a short text extract in this chapter.) Chapter 4 will generate the same kind of markup dynamically from a JSON data file, and also introduce the basics of search. By Chapter 5 the editor will begin to serve as a truly interactive application which supports efficiently inputting a significant amount of data by the linguist.

Sample text extract

In order to explore how an interlinear text can be represented in HTML, we will work with a transcription from the author’s own fieldwork experience with the Hiligaynon language (Visayan) of the Philippines. The text was transcribed from a public YouTube video by a YouTuber who went by “Ilonggo Boy”. The video, a humorous narrative about education in the Philippine city of Iloilo, is entitled School Memories! 1, and is reproduced below with subtitles in Hiligaynon, English, and bilingual form.

School Memories! by “Ilonggo Boy”

An interlinear text such as this can grow to quite an intimidating amount of HTML code. For example, the full HTML rendering of School Memories! — which runs to some 150 sentences and about 1000 words — takes up almost 6000 lines of HTML markup. Of course, hand-editing that amount of HTML is hardly feasible. Nonetheless, the best way to become acquainted with HTML syntax is to write it by hand. For expository purposes we will work with a three-sentence extract from the complete text, which will be rendered completely in the next chapter. Those sentences are rendered below in the target interlinear format, which will serve as the basis for the interlinear text editor.

HTML rendering of Hiligaynon extract.

HTML does not have a difficult syntax — unlike the more complex Javascript programming language, HTML is intended only to record the content of a structured document.2 In the next section, corresponding to the first stage of the development of the editor, we will introduce the basics of HTML, beginning with how to create and edit an HTML file.

Interlinear Text as an HTML Document

For the remainder of the chapter we will build up the same HTML rendering shown in the previous figure, step-by-step. The key concept is in HTML is the HTML “element”:

A diagram of the parts of an HTML element.
The parts of an HTML element.

An HTML file is just a text file with content which is wrapped in “tags” such as the one shown above. In this case the tag is of the p type (it could also be spelled <P> — HTML tag names are case-insensitive). This stands for ‘paragraph’. Note that only the “content” of the tag—in this case, the first sentence of our sample text, arí na estudyánte nyo hu.—is visible in the browser in the preceding diagram. This is a general principle in HTML: only the contents of tags are visible in the browser, not the tags themselves. By default, unsurprisingly, a <p> tag is rendered with the default text size and typeface.3 Other tags have other default styles: an <h1> tag, where h1 stands for “first-level heading”, has a large, bold typeface. However, it is a mistake to equate particular tags with particular presentational styles: HTML represents the structure of documents, not presentational characteristics. Thus, it is more accurate to think of a <p> tag as corresponding to “normal text content”, and an <h1> as the “highest-level heading of the current section of the document.” Neither of those characterizations makes any explicit reference to presentational features.4 In all, there are about 150 HTML tags defined in the HTML specification. In this work we will only use a small fraction of those.5

Editing HTML

HTML files are not edited within the web browser itself — the browser is used for viewing (“browsing”) HTML content.6 An HTML author edits HTML in another application, a plain text editor. It is important to note that text editors are quite distinct from word processing applications such as Microsoft Word or other office-style word processing software. Those tools are sometimes referred to as “What You See is What You Get” (WYSIWYG, pronounced [ˈwɪzɪwɪɡ]) tools, because the author interacts directly with presentational information such as font weights, underlining, italicization, and general page layout. That is to say, presentation and content are intertwined in a manner which is somewhat difficult to disentangle. In an HTML document, which consists of plain text which encodes structural information, nothing is styled. There is no bold text (by definition) in a plain text editor.7 Rather than editing “styled” text directly in as one does in a WYSIWYG editor, the HTML author uses a text editor and browser at the same time, and it is the browser that actually applies styling to the structured HTML content. The process of editing and saving in the text editor, followed by viewing in the web browser to view the effect of changes, is the first web development cycle we will employ here.

The best way to internalize how one goes about creating an HTML page is simply to experiment with writing, changing, and viewing an HTML document. The basic steps in the development cycle are as follows:

  1. Use a text editor to edit a file with HTML syntax.
  2. Save the file with an .html suffix.
  3. View the rendered .html file in a web browser.
  4. Return to 1.
The process of using a text editor and web browser to create an HTML page.
A typical HTML development cycle. A single .html file is edited in an (external) text editor, and viewed in a web browser.

Notice that this process can be done without any networking involving the internet. Just as a word processing program can open and edit a file in a word processing format such as .docx or .odf, a web browser can open and view HTML file — which is in fact just a text file saved with the suffix .html. But again, browsers are not themselves used to edit the HTML text file.

There are a relevant details to note in the diagram. Note that the URL-bar in the mock web browser on the right has a URL which begins with file://. This is an indication that the HTML file that the browser is rendering is located on the user’s computer, not on the internet. The path to the file refers to the user’s own file system: the nested hierarchy of folders on their hard drive. Were the file hosted by an website, the browser’s URL bar would contain a URL beginning with http:// (or its more secure variant, https://), followed by the domain name (such as linguistics.ucsb.edu or archive.org, and then a reference to where that file is on that host computer. We will discuss the meaning of those acronyms, and of “hosts”, “servers”, and so forth, later. Thus, for our purposes, we may think of a web browser as a program for viewing HTML documents. It is also important to note that the development cycle described above is distinct from the workflow that users of the editor application will be using! We are using the web platform to build a user interface for editing interlinear texts within the browser interface exclusively.

At this point we have learned enough about the very basics of HTML to begin carrying out some rendering. We will begin with a single short sentence from the Hiligaynon extract, which is represented below in two complementary formats. First is a familiar “four-line” interlinear gloss presentation of the sentence, and the second is the more abstract “tabulation” format used in previous chapters.

“4-line” interlinear view of first Hiligaynon sentence.
Abstract tabulation of first Hiligaynon sentence.

Reviewing the the sentence object, we may enumerate three attributes, two simple and one complex:

  1. A transcription (a string in Hiligaynon orthography)
  2. A translation (here, represented by a string in English)
  3. An array of word objects, each with:
    1. A form (a string in phonetic orthography)
    2. A gloss (a string)

In order to render this information as HTML, we will make use of three HTML tags. These include:

  1. <p> paragraph: textual content (for transcriptions, translation, forms, glosses…)
  2. <div> generic container (for grouping other elements)
  3. <article> a unit of content which can “stand alone” as a self-contained composition (to represent a complete text)

In the sentence, both transcription and translation are attributes whose values contain orthographic text, with sentence-initial capitalization and sentence-final punctuation. For these reasons a paragraph tag is an appropriate choice. Other tag choices for these attributes could have served equally well or nearly so. Choosing which HTML tag to use to contain particular kinds of content is often more art than science. In what follows I will prioritize keeping the number of tags that we use as small as possible, so as to not overwhelm the reader with many tags. (For some kinds of content, however, particular tags are clearly the best choice, those tags will be introduced as necessary.)

Here, then, are the transcription and translation of the example sentence:

<p>arí na estudyánte nyo hu</p>
  <p>Here’s your student now!</p>

Although the choice of tag for rendering each attribute is appropriate (as each contains running text), when the two elements are juxtaposed together, there is no indication in the markup which indicates what is unique about each. Both are “paragraphs”, but in the context of our interlinear text editor we will want to distinguish paragraphs that contain transcriptions from those that contain translations. Fortunately, the HTML language allows authors to add further custom information to tags via the use of HTML attributes. HTML attributes are a part of the HTML syntax which allow tag-specific properties and values to be encoded directly within the opening tag of an element. One such property is class, and it may be used to add an arbitrary classification to an HTML element.

Thus, the previous two lines may be rewritten as HTML with class attributes as follows:

<p class="transcription">arí na estudyánte nyo hu</p>
  <p class="translation">Here’s your student now!</p>

Note that adding these class attributes to the paragraph tags will do nothing to affect the appearance of the HTML markup when rendered in the browser, as yet. We will see later that such classes may act as “hooks” for adding style rules via CSS, but it is worth noting that even aside from questions of rendering, this markup is more self-describing — that is to say, if a human reader were to inspect the HTML directly, the fact that the author had considered the contents of these two elements to be of distinct kinds would be plainly apparent. Another way to conceptualize these HTML class attributes is to think of them as domain-specific classifications of content, whereas the particular HTML tag itself is more of a generic, document-level description of the content. As we design markup for other documentary structures such as texts, words, etc, we will make use of HTML class attributes consistently.

For instance, if we shift our focus from the sentence to one if its constituent words, we might use a tag structure of two paragraphs, identical to the one we used to mark up the sentence. In order to specify that these paragraphs contain aspects of a word and not a sentence, we will use simple HTML class attributes:

<p class="form">estudyánte</p>
  <p class="gloss">student</p>

I have added class attributes corresponding to the roles of each of these values, in the same way that the sentence-level paragraph tags were marked up as containing transcription and translation. This seems straightforward enough, but the question immediately arises as to how to mark up the remaining three words of the sentence. The following HTML markup is poor, because we have lost the correct hierarchical structure of the sentence.

<p class="form">arí</p>
  <p class="gloss">here</p>
  <p class="form">na</p>
  <p class="gloss">already</p>
  <p class="form">estudyánte</p>
  <p class="gloss">student</p>
  <p class="form">nyo</p>
  <p class="gloss">2PL.ERG2</p>
  <p class="form">hu</p>
  <p class="gloss">EMPH</p>

Specifically, there is no explicit indication in this markup that the first form and first gloss, together constitute a single word. It is the pairs of “form” paragraphs and “gloss” paragraphs that correspond to the documentary object we are calling a “word”. As diagrammed below, the word has coherence as a documentary object. It could stand on its own as documentation, albeit a very simple one. Our HTML markup should reflect this identity.

Abstract tabulation of a single Hiligaynon word.

The basic way to mark up an entity in HTML is to give it its “own” element. But the form and gloss of the word are already represented as independent elements with appropriate <p> tags which are appropriate to their textual content. Fortunately, HTML tags may be nested, and we may simply wrap the <p class="form"></p> element and the <p class="gloss"></p> element together under a shared “parent” element corresponding to the word as a whole. The official description of the <div> tag will show that it is an appropriate choice here:

The div element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements. It can also be used in a dl element, wrapping groups of dt and dd elements.

The div element

This is precisely what we need to wrap our word. We can simply add a custom HTML element class to indicate that the <div> represents a word:

<div class="word">
    <p class="form">estudyánte</p>
    <p class="gloss">student</p>
  </div>

…will be rendered:

estudyánte

student

Again, as yet, there is little visual indication of the custom classes we have added to these elements. We will add another level of nesting with a wrapping <div> to contain the sequence of <div>s representing words:

<div class="words">
    <div class="word">
      <p class="form">arí</p>
      <p class="gloss">here</p>
    </div>
    <div class="word">
      <p class="form">na</p>
      <p class="gloss">already</p>
    </div>
    <div class="word">
      <p class="form">estudyánte</p>
      <p class="gloss">student</p>
    </div>
    <div class="word">
      <p class="form">nyo</p>
      <p class="gloss">2PL.ERG2</p>
    </div>
    <div class="word">
      <p class="form">hu</p>
      <p class="gloss">EMPH</p>
    </div>
  </div>

At this point we are ready to insert the <div class="words"></div> element between the <p class=transcription></p> and <p class=translation></p> elements to represent the entire sentence. The reader will not be surprised that these three elements, too, will be wrapped in a containing element, <div class="sentence"></div>. Here, then, is the complete markup for the sentence with transcription, translation, and glossed words:

<div class="sentence">
   <p class="transcription">arí na estudyánte nyo hu</p>
   <div class="words">
    <div class="word">
     <p class="form">arí</p>
     <p class="gloss">here</p>
   </div>
   <div class="word">
    <p class="form">na</p>
    <p class="gloss">already</p>
   </div>
   <div class="word">
    <p class="form">estudyánte</p>
    <p class="gloss">student</p>
   </div>
    <div class="word">
     <p class="form">nyo</p>
     <p class="gloss">2PL.ERG2</p>
    </div>
    <div class="word">
     <p class="form">hu</p>
     <p class="gloss">EMPH</p>
    </div>
   </div>
   <p class="translation">Here’s your student now!</p>
  </div>

We shall see that the familiar format presented at the beginning of this section may be achieved through the judicious application of a few CSS styling rules. But before proceeding to the next section, there is one final modification which we will want to add to this markup: we want to capture the fact that the transcription, words, and translation themselves correspond to a higher-level documentary object, which we are referring to as a “sentence”.

Two steps remain to completely mark up the three-sentence extract as HTML: firstly, this sentence structure must be repeated with the content of the other sentences, and secondly, that sequence of marked-up sentences should themselves be wrapped in a single element to indicate their status as a unified whole. For this purpose we will make use of the <article> tag, which is described as follows in the HTML specification:

The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

The article element

This tag will thus be used here to contain a text. The term ‘text’ is used with a fairly broad range of meanings in language documentation, and here it will be defined generically: here, a “text” is an object which has a property sentences whose value is an array of sentences. We impose no explicit constraints on how those sentences relate to each other: a “text” could contain a complete narrative, a transcript of a conversation, a song, a series of extracted examples from a published grammar, or any other collection of sentences that a linguist deems useful or interesting. While more information will be added to this general scheme later in the development of the editor (including especially structures for managing and rendering metadata about the text), for now this level of detail is sufficiently granular to continue development.

Adding metadata

It is good practice to always ensure that some kind of metadata is included at every step of digital documentation. As any working linguist knows, versions of files tend to multiply, and it can be all too easy to find oneself wondering where a particular file “came from”. We will take some simple steps at this point to include very basic metadata. For now we will include a title, the name of the language, and a brief citation of the source of the materials. (Later we will see a much more flexible approach where arbitrary metadata may be stored in a data file, even if only part of that metadata is shown in the editor.) We will make use of three tags to construct the header for the text:

As usual, each tag will be given a class attribute with a label that will be useful when styling the content. The skeleton structure of the markup for the text, then, is as follows (the content of sentences two and three have been elided for brevity):

<article class="text">
    <header class="text-header">
      <h1 class="text-title">A short extract from “School Memories!”</h1>
      <p class="text-language">Hiligaynon</p>
      <p class="text-source">Transcription by Patrick Hall and Joshua De Leon of <a
          href="https://www.youtube.com/watch?v=cUqMWG4QJMk">School
          Memories!</a>, speaker “Ilonggo Boy” (YouTube.com)</p>
    </header>
    <div class="sentences">
      <div class="sentence">
        <p class="transcription">arí na estudyánte nyo hu</p>
        <div class="words">
          <div class="word">
            <p class="form">arí</p>
            <p class="gloss">here</p>
          </div>
          <div class="word">
            <p class="form">na</p>
            <p class="gloss">already</p>
          </div>
          <div class="word">
            <p class="form">estudyánte</p>
            <p class="gloss">student</p>
          </div>
          <div class="word">
            <p class="form">nyo</p>
            <p class="gloss">2PL.ERG2</p>
          </div>
          <div class="word">
            <p class="form">hu</p>
            <p class="gloss">EMPH</p>
          </div>
        </div>
      </div>
  
      <p class="translation">Here’s your student now!</p>
    </div>
    <div class="sentence"></div>
    <div class="sentence"></div>
    </div>
  </article>

A complete HTML page

So far we have built up the HTML version of the text from the inside-out, beginning with the internal structure of sentences with their word lists, and then proceeding to sequences of sentences contained in an <article> tag. While this content is valid HTML, it does not yet itself constitute a complete HTML page.

<!DOCTYPE html>
  
  <html lang=en>
  
    <head>
      <title>
        Sample page
      </title>
  
      <meta charset=utf-8>
    </head>
  
    <body>
      <p>Page content here</p>
    </body>
  </html>

This “skeleton” document contains several elements we have not yet seen. The first, curiously formatted “document type declaration” contains the text <!DOCTYPE html>. Technically it is not a tag, but a directive to the browser which tells it to parse the content of the page with the most recent version of the HTML standard. (Older web content used more complex doctype declarations, but these are no longer standard.) It is easiest to think of the doctype declaration as nothing more than a boilerplate preamble.

structure of a basic HTML page
Diagram of the structure of a basic HTML page (View in a separate tab)

<html>, <head> and <body> lay out the highest levels of the document. As such, they occur once and only once in every HTML page. If they are missing the browser will insert them automatically, but we will always include them explicitly. The <html> element is the “root” element of the entire page. Its closing tag </html> should always be the last text in an HTML file. In the example file the <html> tag is shown with the lang attribute set to the value en, which is the (ISO 639-1) language code for English. Setting this HTML attribute is recommended, as it tells the browser what the default language of the page is.

Below the <html> tag are two child tags, the <head> and the <body>. <head>8 contains metadata about the page. In this case we have added two tags below <head>. The first of these is the <title> tag, which contains the title of the HTML document and appears in the page’s tab in the browser. Note that the content of the <title> tag cannot contain nested tags: it must contain only plain text. Next is a means of indicating that the page contains content which is encoded as Unicode. This looks like: <meta charset="utf-8">. The <meta> tag is used for several purposes, but here the attribute charset is used to specify the character encoding of the page. In the past HTML documents where encoded with several different systems, but practice has strongly converged on the use of utf-8 as the only encoding for web content.9 Like the doctype, then, think of the the <meta> tag as required boilerplate for every web page. (In the next section we will see how a <style> tag, may also be added under the <head> tag, which is where Cascading Style Sheet rules may be inserted.)

Finally we reach the content of the page itself. Only tags within the <body> tag are actually visible within the main browser window. In the diagram a single paragraph containing the text Page content here is shown. In the case of our interlinear text, in order to create a complete page, we can carry out the following steps:

  1. Copy the skeleton content above into a new text file in your text editor.
  2. Change the content of the <title> tag — here we will use ‘School Memories!’ Extract.
  3. Delete the paragraph containing Page content here.
  4. In that location, paste the markup of the text as we have developed it thus far.
  5. Save the file with a useful name, here I will use hiligaynon-text-extract-version-1.html.
  6. Open the file in the browser.

It is worth trying to carry out these steps, but a completed stand-alone version of the text may be viewed at hiligaynon-text-extract-version-1.html. Note that the page will still appear in a strange format, with the individual words of each sentence rendered in a numbered list in vertical format. We will correct this in the next section by introducing a few key concepts from CSS.

Stage 2: CSS — Layout and Styling

Cascading Style Sheets (CSS) is a language for describing the presentation of an HTML document. In this section, we progressively apply CSS rules in order to present the HTML markup developed in the previous section in standard linguistic notation. Thus far, the visual rendering of the sample content has been almost useless: every element of the text is presented on its own line, with no visual indications of the hierarchical struture of the interlinear text. This is because the default presentation for all of the HTML tags we have used thus far (<article>, <div>, <h1>, <header>, and <p>) is block level. A block level element always gets its own line in the document, somewhat comparable to pressing enter in a plaintext document. In the demonstrations below, the sentence will be presented first with a green-on-black set of CSS rules, followed by the results of applying those rules to the HTML markup of the sentence. The result of applying those rules to the CSS rules is presented in with a dashed container which you may think of as a browser window. (We will see later how to actually incorporate CSS rules into a stand-alone HTML document — for now the goal is simply to study the effects of the application of rules to marked-up content.)

In the first example, no CSS rules are applied at all. The block-level nature of each element is apparent, and results in a very unreadable document. The transcription line, the form and gloss line of each morphologically analyzed word, and the translation line are all rendered on an independent “new” line:

  /* no rules applied */
   

arí na estudyánte nyo hu

arí

here

na

already

estudyánte

student

nyo

2PL.ERG2

hu

EMPH

Here’s your student now!

no rules

While there is no visual indication of hierarchical relationships as yet, just three CSS rules are sufficient to show the hierarchy embedded in the markup visually.

  * {
    border: 3px solid gray; 
    padding: 5px;
    margin: 10px;
  
    /* try removing the comments below */
      background-color: #00000022;   
  }
    

arí na estudyánte nyo hu

arí

here

na

already

estudyánte

student

nyo

2PL.ERG2

hu

EMPH

Here’s your student now!

A CSS Rule consists of a CSS selector and one or more CSS declarations. In this case, we have used the most general selector of all, the star or asterisk *, which is called the “universal” selector. It selects all elements on the page. For this reason, the three declarations are applied to every element in the sample markup: every <div> and <p> has had its border, padding, and margin set. In fact we shall shortly remove these declarations, but they are useful for inspecting the markup structure “behind” the plain presentation. The border declaration has the value 1px solid black, sets several characteristics of the border at once: the 3px value refers to the width of the border in pixels, whereas the solid value refers to the border style (other possible values are dashed, dotted, or double).

The CSS code is editable, you can try editing the values and observe the outcome. Here are a few easy changes to experiment with:

  1. Change 3px to 10px in the border declaration.
  2. Change solid to dashed or double in the border declaration.
  3. Change the size of the margin and padding values.
  4. Choose a different color name for the border value: try fuchsia or rebeccapurple.
  5. Uncomment the background-color declaration by removing the /* and */ strings. This will add a semi-transparent gray shade which becomes deeper for elements which are “deeper” in the hierarchy.

Note in particular that this presentation shows how the div.words10 element is at the same depth as the p.transcription and p.translation elements — they are siblings under the div.sentence “parent”.

Obviously, colors and borders are not helping bring us closer to readable linguistic notation, but they do drive home a key fact about how layout works in the web platform: every element in the page is rendered in its own box, whose size and other visual dimensions can be modulated through the use of CSS rules. The changes we have just made make the boxes themselves visible. Because these elements are by default block-level, they “march down” the page in the same order in which they appear in the HTML source code. Adding padding, margins, and borders as we have here makes both the size and the nested arrangement of the boxes visually apparent.

Styling every element on the page in the same way is not terribly useful: after all, we want to use CSS to make the components of the document more visually distinct, not more similar. We can do this by moving from the universal selector (*) to more specific selectors. The simplest selector is simply the name of an HTML tag. Thus, to make the contents of all paragraph (<p>) tags bold, we can write a rule where the selector is p to rather than *, and use the font-weight declaration with a value of bold:

  p {
    font-weight: bold;
  
    /* more declarations to try uncommenting: */
    /* font-style: italic; */
    /* color: gray; */
    /* font-family: monospace; */
  }
   

arí na estudyánte nyo hu

arí

here

na

already

estudyánte

student

nyo

2PL.ERG2

hu

EMPH

Here’s your student now!

Now, because we wrapped every bit of text in a paragraph tag in our markup, every individual paragraph matches the rule, and thus has been set in a bold font. In the previous section the notion of HTML class attributes being added to elements was emphasized, and the utility of this effort will now be demonstrated: we can use a special syntax in CSS to select only those paragraphs which also have a particular class.

  p.form {
    font-weight: bold;
  }
   

arí na estudyánte nyo hu

arí

here

na

already

estudyánte

student

nyo

2PL.ERG2

hu

EMPH

Here’s your student now!

As is apparent from this example, the syntax for matching elements with a particular value in their class attribute is to use a period followed by the class name of interest. Here, the selector p.form selects only those paragraphs that also have their class attribute set to form. (Note that care must be taken with regard to spaces in CSS selectors: p.form and p .form are two different selectors.) The reader might be interested to try changing the class selector above from form to gloss. In this way we can “target” particular subsets of our document for helpful styling.

It is tempting to continue to adjust the typographical details at this point, but let us first solve the more pressing problem: the layout of the individual analyzed words. Put simply, the problem here is that block-level rendering is inappropriate for the analyzed words. We want each individual div.word “box” to behave as though it were a single word in a line of text—to flow horizontally and wrap when necessary. Just as we selected the paragraphs containing a word form with the selector p.form, we can select the <div> tags with a class of word — each of which is a “parent” of a pair of paragraphs corresponding to the form and the gloss in a single word. Adding borders around each div.word, and a distinct border around their container div.words, will help us to keep track of what’s going on as we adjust the layout of the sequence of words.

  div.word {
    border: 1px solid black;
    margin: 10px;
    padding: 10px;
  }
  
  div.words {
    border: 3px dotted lightblue;
    margin: 10px;
    padding: 10px;
  }
   

arí na estudyánte nyo hu

arí

here

na

already

estudyánte

student

nyo

2PL.ERG2

hu

EMPH

Here’s your student now!

Now that we have visual distinctions between div.words and each div.word, we can proceed to adjust the layout. There is, as is often the case, more than one possible solution for this problem using various combinations of CSS declarations. In this approach we will make use of a technique known as “flexbox”, which changes the way in which the direct children of a given element are arranged. Using flexbox we can write just two declarations matching div.words.

  div.words {
    border: 3px dotted lightblue;
    margin: 10px;
    padding: 10px;
  
    /* flexbox declarations added below */
    display: flex;
    flex-wrap: wrap;
  }
  
  div.word {
    border: 1px solid black;
    margin: 10px;
    padding: 10px;
  }
  

arí na estudyánte nyo hu

arí

here

na

already

estudyánte

student

nyo

2PL.ERG2

hu

EMPH

Here’s your student now!

The declaration display: flex overrides the default display value for a <div>, which is block. The flex-wrap: wrap; declaration requires a bit of explanation: flex display, by default, squeezes all the children of an element whose display is set to flex into a single row.11 This can be useful for other layout problems such as fitting a logo, a wide search box, and a “search” button into a navigation bar at the top of a web page. But in the case of our div.words, the number of div.word children is unpredictable: although our sample sentence has just a few words, we can expect to deal with sentences with many more words. Setting flex-wrap to wrap tells the browser to wrap words onto new lines as necessary.

Now that we have resolved the layout problem, we can return to improving typographical presentation. Here are the remaining steps:

  1. Remove the borders.
  2. Slightly increase the font size of p.transcription and p.translation
  3. Italicize p.translation
  4. Adjust margins and padding throughout.
  p.transcription {
    font-size: 1.2em;  
    font-weight: bold;
  }
  
  p.translation {
    font-size: 1.2em;  
    font-style: italic;
  }
  
  div.words {
    display:flex;
    flex-wrap: wrap; 
    padding-left: 3em;
  }
  
  div.word {
    margin-right: 1em;
  }
  
  p.form {
    margin: 0; 
    font-weight: bold;
  }
  
  p.gloss {
    margin: 0; 
  } 
  

arí na estudyánte nyo hu

arí

here

na

already

estudyánte

student

nyo

2PL.ERG2

hu

EMPH

Here’s your student now!

So, with just six CSS rules and eleven declarations, we have a serviceable approach to rendering interlinear text. What remains is to actually incorporate these rules into the complete HTML page. One way to do this is to insert the rules as they are written into a <style> tag in the <head> of the HTML document. (See diagram of the basic structure of an HTML page, above.) For the sake of simplicity, we will not modify the default formatting on the h1.text-title, p.text-language, and p.text-source elements.

The final presentation is available here:

hiligaynon-text-extract-version-2.html

Note that a more elaborate set of CSS can change the appearance of the text quite substantially. While the details of how these rules work is beyond the scope of developing the interlinear text editor, the following demonstration may begin to give some idea of the sorts of variation possible. Note custom (dynamically loaded) typefaces, decorative background and borders, and some interactivity. CSS alone (without Javascript) is sufficient to enable interactivity to a certain limited degree — in this demo, hovering the cursor over a form will reveal the gloss. It is not difficult to imagine useful pedagogical tools along these lines for language revitalization purposes; it is shared here as a simple example of possibilities. Note that no changes whatsoever have been made to the HTML markup in this variation. Only CSS has been changed.

hiligaynon-text-extract-version-3.html

Even so, the combination of HTML and CSS explored in this chapter has its shortcomings as well. HTML, while a useful format for documents, is not necessarily a good canonical format for the storage of language documentation. For that purpose, we will begin to explore how to use Javascript Object Notation (JSON) 12

For now, however, we will continue to work with the CSS in version-2, above. In the next chapter we will being to address the task of dealing with data more dynamically, by generating content dynamically from a data file. This will involve three new topics: , the Document Object Model (DOM), and finally Javascript itself, a complete programming lanugage which is embedded in browsers.

References

{ “title”: “Engineering Language Documentation”, “author”: “Patrick Hall”, “date”: “2019-06-14” }


  1. Hiligaynon is spoken especially in Panay, Mindanao, Negros Occidental, parts of Palawan, Romblon, and Northern Mindanao, as well as expatriate and immigrant communities in the United States. The transcription was a collaboration between the author and Joshua De Leon, Sr, speaker in the 2014 field methods class at UCSB and resident of Santa Barbara. Conventiently, De Leon attended the same high school as Ilonggo Boy, and thus was thus privvy to many details of the school campus environment.

  2. Interestingly, HTML has its origins in the context of academic documents: it was first designed Tim Berners-Lee for the purpose of making technical documents more readily shareable at CERN, a particle physics laboratory.

  3. There is some variation from browser to browser in defaults such as text size.

  4. For a convenient introduction to this form/content distinction in the context of language documentation, see Thieberger and Berez 2011:94-96.

  5. A complete catalog of current HTML tags has been added to this chapter as an appendix.

  6. It is possible to edit the content of an HTML page from Javascript, and we shall see that such manipulation is a crucial part of the approach to creating the editor.

  7. Rather confusingly, some “programmer’s text editors” do automatically add formatting to plaintext content. This sort of formatting, called syntax color highlighting, might be thought of as a kind of meta-typography: when the author writes code which is invalid according to the syntax of the language, highlighting can help to reveal such errors early. Nonetheless, what such an editor actually saves is precisely the same as a less specialized editor would save: plain text. Note that the HTML examples in this document have syntax highlighting added.

  8. The <head> tag should not to be confused with the distinct <header> tag, which indicates the header of a section within the <body>.

  9. If an HTML file appears to contain encoding errors when it is loaded in the browser, (such as SmörgÃ¥s instead of Smörgås), one possibility is that the text editor has not been set to save content in UTF-8. Try adjusting that setting in the editor, re-saving the file, and reloading it in the browser.

  10. It is convenient to refer to sets of HTML elements by using a CSS selector which matches them. Thus, the phrasing “each div.word” is equivalent to “all <div>s with a class of word.

  11. More precisely, the default value for the flex-wrap property of an element with display set to flex is nowrap. For a useful interactive demonstration of how display: flex and flex-wrap: nowrap or flex-wrap: wrap interact, see: https://developer.mozilla.org/en-US/docs/Web/CSS/flex-wrap.

  12. JSON is pronounced /ˈdʒeɪsən/ by its specifier, Douglas Crockford.