"Hello, Browser!" - Part 2

Part 2 - Manipulating the browser environment

In my previous article, I discussed the notion that HTML, as a document markup language, is ultimately intended to aid in the creation & configuration of HyperText/HyperMedia documents in the browser's environment. It does this by providing tags, tag attributes, and style properties through which a page author might specify formatting & layout rules for how that page will display in a browser.

To avoid confusing readers by jumping between disparate browsers, I'm going to focus first on Firefox and explore its environment as it relates to page authors & programmers.

Let's make a document!

It's not strictly necessary to use anything beyond a single empty text file and a browser to get started building a page and be able to manipulate the browser in incredibly powerful ways. You don't even need to write a lick of HTML to get started.

Let's try it!

In your file manager, create a new, empty file somewhere, rename it to "HelloBrowser.html", right click it to get a file context menu, and use your system's "Open File with..." to open it in Firefox.

At this moment, you see nothing. This shouldn't surprise anyone, as the input HTML file is empty. Note, however, that an empty HTML file, does not mean the resulting document is similarly empty. It's not.

When the browser opened the file, it created a document for you, complete with its own DOM, interfaces to major I/O systems and databases, permissions configured, a security model chosen, and policies set, everything ready and fired up. You didn't even have to write code!

This is an artifact of the intent of a browser and HTML's role. The goal of HTML is to initially configure, and then subsequently specify interactions with a document in the browser. So that's exactly what happened, just without any configuration.

The empty space on your screen, while being devoid of visible content, is an interactive document. You can interact with the single "visible" element that is currently on the screen, even though it has no background. This element will still react to mouse & keyboard events and other events like resizing the screen. Right-clicking this element, will give you a context menu that should include a few options that look similar to this:

Clicking on View Page Info will bring up a window like this:

Here, we start to see some of the browser's internal complexity surface. When opening an empty file, we see that the browser has made some assumptions about things. In the absence of information to the contrary, the title is 'Untitled Page', text-Encoding is UTF-8, its current content-type is text/html, and its render mode is "Quirks".*

* The render mode of the browser controls whether it complies with strict standards or allows "quirks" that are included for backwards-compatibility with older HTML specifications, and the behavior that was expected from browsers for those elements.

N.B. To avoid the overuse of "document" ad nauseam, the terms page and document will both be meant to refer to either the running DOM object, the document file on disk, or the data located at a remote resource. In other words, more or less the same things, depending on context.

Clicking on the "Permissions" tab, we see something like this:

This list of items represents the browser's existing permissions model, as it understands it for THIS document, in relation to what internal systems of this computer the document has access to. By default, we see that browser wants the document to ask the user for permission to use a particular resource. If we uncheck "Use Default", we can specifically configure what this document has access to. The browser has the ability to keep track of that setting, for that page address, independently of the document file, which as we know...is empty.

The browser tracks every visit to a page address including local files. Local file visits are converted to a file:///drive/path URL format for history purposes. Even if we deleted this file now, the browser will keep track of the history of this initial visit and be able to persist all of the page's initial defaults, as well as any changes made to those default permissions.

Clicking on the security tab, we see this:

Here we can see some more details about the page itself, and specifically a few more things the browser has assumed about the page, including Identity, and Privacy & History. The browser can, from here, allow you to save a password for this page.

As we can see, when we open any file in the browser, regardless of the page content, the browser is going to make some fairly serious and limiting decisions about that page and what interfaces it can reach, if the document's security & permissions models aren't deliberately respected.

The browser's permissions & security models can be troubling to fully understand at best, and a nightmare to manage at worst, leading to newer standards like Cross-Origin Resource Sharing(CORS). CORS is an example of a technical "workaround" to various permissions-and-security methodologies at work in the browser/server interaction models to protect against accidental and actual malfeasance.

All of this, from an empty file. Moving on...

Down the rabbit hole - The Element Inspector

Right clicking on the empty page again, and clicking on "Inspect Element" should bring up Firefox's Developer Tools interface. You should land on the Inspector tab, and it should look something like this:

Here, the browser presents a few different views of the state of the DOM, including the layout rules the currently selected element is respecting in this particular view. When we clicked "inspect", the browser selected the top-most, mouse-responsive element beneath the mouse pointer as the current element. This turns out to be the <html> root element of the document itself.

On the lower-left, we can see a representation of the DOM element tree, with elements presented in the familiar <tag> format, displayed as an expandable hierarchy, as the browser currently understands it. We have exactly 3 elements in this page's DOM, an <html> element, a <head> element, and a <body> element.

At risk of belaboring the point, we can see right here, that we get a lot of stuff from literally nothing. It's about time we said "hello!" to it.

The HTML title element

N.B. Unless otherwise stated, all element types are HTML, will be distinguished using the familiar tag syntax, will be compliant with the current HTML 5 spec and refer to the element as it's understood by the latest version(s) of Firefox as of this writing.

The <head> element functions as a metadata container for the page, where-in a page author might put extra, hidden information to configure the page, that a typical audience has no ability to see without looking under the hood.

The browser will typically NOT display anything in the <head> directly. Elements used in the <head> are expected to carry extra settings, styles, configurations, and scripts, and only these things. One of these, is the <title>.

Among the elements that can be used in the <head> to configure the browser, <title> stands out for its simplicity. According to the spec, this element has no attributes, and accepts only text of the configured document encoding, within its DOM/XML-provided implicit TEXT node.

N.B. A little-realized feature of the browser is that it can natively handle pure XML files, and create a HyperText, style-aware document to display, with its own complete DOM, if valid XML style-sheets and links exist in the file. That said...

While the HTML 5 specification does not provide for the <title> to have attributes of its own, the DOM "global" attributes are still available and the underlying XML specification that HTML is based on does allow any well-formed XML entity named 'title' to have attributes, and any attributes specified will make their way into the DOM in one fashion or another, becoming directly queryable from the document. This means that advanced authors can(and will) use/abuse title attributes and XML's other language features to convey extra metadata into the page about the <title> itself that other types of HTML processors can then extract for other purposes. However, this isn't typical of <title>, as doing so unwarily may invalidate an HTML/XHTML document's HTML 5 compliance and subsequently change the rendering mode of the browser.

What's interesting about <title> is that specifying the document title normally doesn't affect the document's display in the browser. Rather, the document title affects how the browser advertises itself to your computer, and how the browser labels the tab. The title of the page you are looking at will show up in your system taskbar, or as tool tips over the application while in use. Other applications also have access to this information. When saving bookmarks, the browser will use the current page's title as the name of the bookmark.

The <title> also has other, equally important uses in realms of interest beyond the browser, as document titles are often used to create lists, tables, indexes, and short, permanent URLs(often called slugs) based on the title content, allowing them to function as signposts for search engines, and influence SEO results, among other things.

Back to the browser, the <title> accepts text in whatever encoding the page is currently configured, and will attempt to display that text in the browser's title bar, and advertise it elsewhere. We could see from the page info, that the current/default encoding is UTF-8. This means even for plain text, it's capable of handling the entire range of Unicode-basic emojis, and then some number of the extended ones if default system fonts are used. Just in the title. So let's have fun with that! We'll not just say "Hello, Browser!", we'll also wave at it(??).

N.B. If you use a Windows or Linux machine with a custom display theme that overrides application title, tool tip & system taskbar fonts, this might not work for you. If this happens to you, find a better font. There are thousands of technical, symbolic, cultural, mathematical and other symbols in the Unicode table, not just emojis. Beyond this, many of the current Unicode emojis aren't a single character, but multiple independent glyphs and formatting characters tied together in a formatted character run. To not be able to display all of these, well, you're missing out. Being able to compose almost any possible glyph using Unicode's building blocks is what it's about!

So back to <title>. This document, doesn't actually have one. We can see looking at the <head> that it's empty. What title does it think it has? The "View Page Info" panel said it was "Untitled Page", but glancing at the Firefox tab, we can see it's actually displaying the name of the file.

N.B. This is the default behavior, for a document with no <title>, since the file path can serve as a unique identifier for the document to at least locate it, where the phrase 'Untitled Page' cannot.

The <title> is only allowed as a 'child element' of a <head>. Therefore, let's select the <head>, and right-click it, to see what's available:

As it would so happen...quite a bit! We can edit this element as HTML, and seemingly do basic CRUD operations on it.

There's a lot of stuff here to talk about, but we're primarily interested in just adding a <title> to our document for the moment. So setting aside even more provocative examples of complexity for a moment, let's go ahead and hit "Create New Node", and observe results.

N.B. DOM elements are also referred to by DOM functions/documentation as 'nodes'. This reflects the DOM's tree-like structure and how it is navigated programmatically.

This will create a new element within the <head>, that it initially assigns as a <div>, a standard building block element of HTML. Double-clicking this new element, will give you the ability to edit its HTML class. Type in 'title', replacing the 'div', and just hit enter.

Visually, you'll see no change at this point. We've created an element for the title, but to have an effect, the <title> has to contain some text. The title will remain the same.

Copy the quoted text below, including the emoji. Or, use your favorite quote, just be sure to put a suitable replacement emoji in place:

"Hello, Browser! ??"

Click on the new <title> you just created, right-click, go down to 'Paste', and select 'Paste Inner HTML'.

You will notice that: Nothing visually changed on the page. What changed, is in the browser's description in the taskbar, and the title displayed on the tab. From this, we can see that the <title> element functions as a direct interface to our browser for how it labels a window.

Hovering over the Firefox tab in your system's taskbar, we can see that even in the system taskbar, the content of that <title> now appears. With the emoji! On some systems, the system taskbar will display the emoji in a reduced, black-and-white format, but it will still be visible.

Using a single, simple element, we've reached into our computer and affected how the browser is presenting itself to the operating system! We also know, if we treat even that simple element incorrectly, the browser might not work properly...but by following the specification, we can avoid that. And as yet, we've written no real, "proper" HTML. This simple technique that we used, exposes a wide range of utility in the browser.

Going back to the context menu, we see that it has a few options for working with "Attributes", "DOM Properties" and "Accessibility Properties". Attributes, especially have relevance, because this menu allows you to extend simple tags with attributes that modify their behavior. As almost all <head> oriented tags in the specification require attributes to be configured correctly, we'll be visiting this functionality a lot in this and the following sections.

N.B. It's interesting to note at this point that the context menu surfaces a lot of the functionality of the DOM's HTMLElement interface. In fact, Firefox's developer tools are themselves written in HTML/CSS/JavaScript, and use all the same interfaces we will be working with.

Now that we've covered a handful of basics about the browser and how to twiddle with elements, we're ready to tackle building up some actual page structure and content. Next up, we'll look at what we can do with the <body>, in "Hello, Browser!" - Part 3 - The <body> element