Do you often come across a truly static Web page in the wild? I do, but that's because I seek these things out. The unfortunate reality is that most of what we read on the Web is delivered to us in some kind of dynamically generated template or container that gives a site its uniform appearance and style – and that template can change at any time.
If the site that we're reading our two-paragraph document on inserts a header on every page, our document structure changes:
We don't need to worry about what's in the header. What matters is that its presence has changed the child number of the first <p> element, and every element after it.
I've numbered the children in the graph to make it easier to read. The child sequence to the "Goodbye, world!" text node is now 1/3/1 .
If anything else is inserted before the <body>, or before the second <p>, or before the text node that we want, then the child sequence changes again. For example, the author might revise the document after deciding that they wanted "Goodbye" to be italicized, to indicate snark or sarcasm or whatever:
<html><body><header>...</header><p>Hello, world!</p><p><i>Goodbye</i>, world!</p></body></html>
Our graph now looks like this:
Before we change our HTML document code anymore, we should format it a little differently, because reading that all on one line is getting a bit tough. Something like this is easier for our human eyes to parse:
But guess what? We've just changed the graph again.
The line breaks and extra spaces in this code – the white-space – have added text nodes to the graph. The elements are the same, the way that this would render in the browser is the same, but the graph is now:
And so, by making our source code more readable, we have changed the child sequence to "Goodbye" once again, to /2/6/1/1
What do you think the likelihood is that in an actively maintained Web site, the styling and layout of pages will continuously be undergoing changes of significantly greater complexity than this?
How can we precisely address the content in an HTML document when everything around the content affects the addressing?
SOLUTION #1: NAMED ELEMENTS
Fortunately, elements within an HTML document can be named. The benefit of this is that when we need an address to a named element, we don't need to worry about child sequences at all. We just name the name, and we're there.
Nowadays, elements are named via the "id" attribute:
<p id="intro">Hello, world!</p>
And they're referenced by using a fragment identifier at the end of a URL: http://example.site/document.html#intro
These bare name pointers have been extremely handy from the beginning days of the Web. They allow you to place links in a document that tell the browser to "jump" (scroll) to a different place within the same document, and they allow you to tell your browser to "jump" (scroll) to a particular area in another document after it's loaded. And, of course, we can use them as addresses to link annotation documents to.
If I want to make a note about something that someone said in a named paragraph in an HTML document, it's as easy as saying:
"I think the author is being a real ignoramus when he says: https://author.site/articles/new_article.html#the_offending_paragraph".
Sadly, named paragraphs aren't much of a thing. Go ahead and hunt around on the Web for them. You will find them here and there – but they're scarce.
Instead, named elements are chiefly used in two ways: section headings are named to facilitate in-document jumps, and then user-interface people use a lot of named elements so that it's easier to style and script pages.
I don't find a lot of reasons to annotate the navigation elements of Web pages, so this isn't very useful for me as a reader. And naming section headings is great for jumps, but... the section headings don't contain the text we want to annotate.
However, named elements do one other thing nicely: they isolate sections of the document, so that the child sequences to the elements of the named node's children stay valid even when the document outside of the named element changes.
Here's our code from the last example, but we're going to give our paragraphs 'id' properties – unique names in the document.
We can use these named nodes as root nodes in a child sequence, so "p2"/1/1 points at the text node inside of the <i> element in the second paragraph. Everything outside of that paragraph is now irrelevant.
<html>
┌────────┼─────────┐
│(1) │(2) │(3)
# <body> #
│
┌──────┬────────┼───────┬───────┬──────┬─────┐
│(1) │(2) │(3) │(4) │(5) ┊(6) │(7)
# <header> # <p#p1> # ┊ #
│ │ ┊ this is its
... │(1) <p#p2> own world now
#Hello, world! ├────────┐
│(1) │(2)
<i> #, world!
│(1)
#Goodbye
This is great! Now, as long as a Web page has a named <main> element or some other kind of container where the actual content of an article is, we can get a somewhat reliable reference via child sequences to any content inside of that named element, even if the rest of the site theme/template changes.