The web page is the basic unit of delivery, and if users only know how to do one thing on the web, it is to view pages.

But where does the notion of a web “page” come from?

The HTTP 1.1 specification (RFC 2616) uses the term “resource” to refer generally to anything supported by the protocol, and as such sits “below” the level at which we would talk about pages.

For one thing, this is needlessly complicated. But wait, we just argued that space is inherently more intuitive! Yes, but the space has to be organized somehow. If anything is possible, then there are too many ways to look for something. By establishing certain constraints up front, we limit the search space to something much more tractable. Ideally, those constraints would be the natural consequence of the domain’s “natural” organization; or, since most subjects are naturally messy, some artificial topology will do. As long as the structure is meaningful, the very act of navigating the space can be instructive. This is the argument from the merits (as opposed to necessity): that even if you had completely immersive interaction, you’d still choose some limiting structure.

On a more practical level, though, we do not have completely immersive interaction. The devices that people use stand between them and virtual spaces. In particular, the use of flat screens for both output and input creates a gap between what we might like to do and what we can actually do right now.

There is a tension between space and documents. Documents (as we know them) are a close-up affair—you bring them towards you to look at them. Whereas in space, you tend to look at things at some distance. We can’t effectively be in both modes at once. Yes, a music director can follow a score while looking out over the players—but this is a professional trained in a specialized task; such exceptions prove the rule.

Thus, we will assume that you are either looking at a document or not—and that if you are, then it is your main focus. Just as in space, this does not mean that it blocks everything else from view.

HTML is called a “document” format. But let’s not confuse “documents” for our purposes with the HTML that we use to deliver them. HTML is only a document format if you use it that way. Now it is used in many other ways, some of them very non-document-like. We intend to use it as a container for space, which as we’ve already observed, is not like a document.

That said, we’ll try to make good HTML documents, anyway. Not because of some notions about a “semantic web,” which we have yet to see, but because it has practical benefits. Screen readers, terminal browsers, and search engines are all essentially user agents without stylesheets.⁶, whose job is easier when your HTML document is not nonsense.

Special consideration may be given to the annotation of documents. I’ll have much more to say about this. For the moment, we note that, while a document may itself be “standalone,” its scope for annotation (particularly from outside sources) is unbounded. This open-endedness may be expressed graphically, for example, by presenting annotations on a material that never comes fully into view—the edges of which, in other words, are never all seen at once.

We disable horizontal scrolling of the main viewport.

For one thing, it causes a problem with “vertically fit” elements, since 100vh does not take into account a horizontal scrollbar (at least in Gecko).

But mostly, we just don’t use horizontal scrolling, as a general matter.

html, body
	overflow-x hidden

But wait, what if something really does extend out of the viewport on on side or the other? Won’t that mean that it’s unreachable? Yes, and that’s probably what we want. We’ll use these areas—"stage left” and “stage right,” if you will—to stash things that need to be ready to appear at any time. Without that hidden rule, browsers will adjust the size of the viewport to include that content, meaning that you can pan over to it. It also screws up the width of everything, including fixed-position elements with full width.

This has to be done on both html and body, because browsers are not consistent about which element is considered responsible for scrolling overflow content.

This doesn’t mean that we can never use horizontal scrolling; but if we did so, it would be on a different scrolling container.

Use the entire viewport. This is space, not a document.

margin 0                        // beat user agent default

The web spent its first fifteen or so years on decent-sized screens. When handheld web browsers came along, many web sites were based on the assumption that the screen was at least as wide as a sheet of paper. Such extravagant assumptions are not easy to un-make, and yet mobile vendors—all right, Apple—desperately wanted to show that you could view the “real” web on their little screens. Their solution was to show a shrunken version of what it would look like on a large screen, letting the user “pinch” to zoom to the portion of interest (assuming the user could discern some interest). They accomplished this by setting an initial scale factor between CSS pixels (those seen by your layout) and device pixels (those seen by the user).

As soon as people started designing web sites with small screens in mind, they wanted a way to turn off the browser’s uncharitable assumption. The solution was the viewport pragma, which is specified as a meta value. The initial-scale=1 setting tells the browser not to scale your web page. The chief impact of this is that text is a normal size, and to the extent that your layout is based on em’s or rem’s, everything will be cool.

head <append>
	<meta name="viewport" content="initial-scale=1" />
</append>

According to MDN, “This pragma is used by several mobile devices only."⁹

Note that we don’t disable user zooming, even though we could do so with this tag. Yes, you can make a royal mess of the page by zooming it—even moreso than by scaling the font (which you can’t disable). But trying to prevent these built-in features is generally user-hostile and incurs their hostility in return.¹⁰

I think these @viewport rules essentially duplicate what’s in the meta viewport pragma.¹¹

@viewport
	width extend-to-zoom
	zoom 1.0

@-ms-viewport                // Not provided by autoprefixer
	width extend-to-zoom
	zoom 1.0

This is an extremely minimal set of “intents” related to the great variety of screen sizes. It’s a tough problem which I haven’t given much thought because support for handheld screens (where this becomes an issue) is a relatively low priority for me.

narrow-screen(width = 50rem)
	@media screen and (max-width: width)
		{block}

wide-screen(width = 50rem)
	@media screen and (min-width: width)
		{block}

short-screen(height = 35rem)
	@media screen and (max-height: height)
		{block}

very-short-screen(height = 27rem)
	+short-screen(height: height)
		{block}

The same thing for adapting type size to the viewport. Should only be used for special cases. And maybe should be called scale_type.

@import typesetting                                     // for reading width

constrain-font(threshold, size)
	@media screen and (max-width threshold)
		font-size size

boost-font(threshold, size)
	@media screen and (min-width: threshold)
		font-size size
		{block}

I’ve started using circles more and more. For lack of a better place, I’m putting it here, since it’s hard to imagine making something circular and not a signifier.

circle(width)
	width width
	height width
	border-radius 50%

You can see that this is halfway reasonable in CSS—/if/ you’re able to specify a width. You can get away with that when the text is short.

CSS was invented so that designers could remove the default underline from links. We also don’t want the user agent’s default color.

Just kidding. But seriously, why do we do this? Because space. Although we don’t see the space at large as a document, we do still see hyperlinking as a principal mode of travel. In space, links are more like signs: they are standalone affordances, and they don’t need underline or coloring to distinguish them from the surrounding text. In cases where we do want to use links in text, we’ll set the styles explicitly based on the situation.

Besides all that, we have a somewhat subversive view of hyperlinking, which we’ll discuss elsewhere. Anyway, we oppose default hyperlink styles on both grounds.

a
	text-decoration none
	color inherit

Browsers care about users, too. Typical defaults include some rules that are intended to enhance usability and accessibility. Sometimes we don’t want those defaults.

common-rules()
	a
		&
		&:focus
		&:active
			outline 0
			-webkit-tap-highlight-color rgba(0,0,0,0)

The :focus and :active rules above prevent reflows caused by the focus rectangle, which extends outside of the link and can thus invalidate neighboring elements. We should indicate focus in some other way, but that will have to be done per-element using a repaint-only property.

As for -webkit-tap-highlight-color, this just disables a default behavior on mobile browsers that gives users visual feedback when they touch links and such. Why would we disable this useful feedback? Because we take pains to provide the same kind of feedback, only in a way that we control. Note that that rule will (supposedly) not take effect unless the element also has at least a nominal touchstart handler. As it is, we use that handler as part of said alternative. See pointing.

Note also that the above is done into a separate file. This is because we can (and do) use the same rules on SVG objects.

The rule from Firefox’s ua.css uses the following selector:

*|*:-moz-any-link:-moz-focusring

Because you sometimes inadvertently select text, but never (and never conceivably) do so intentionally.

Since the text of the link is provided (using the ::before pseudo-element), an exit link can be empty. Of course, stylesheet-generated content won’t be visible on non-stylesheet viewers. If you want to support exit links on non-stylesheet viewers, just wrap it in an element with class exit-link-text, and it will be hidden:

.exit-link-text
	display none

| How your data is linked   |
|---------------------------|
| x                         |
| listen                    |
| all's well that ends well |
| henry v                   |
| julius caesar             |
| More »                    |

Note that we sometimes “pre-render” the exit link; that is, render its markup before it is applicable, and use styles to show and hide it. This can help make transition smoother by reducing the number of reflows needed. In such cases, it would be better not to use exit link text, since that would be confusing on non-stylesheet viewers.

Exit links are usually used in association with a title, with a structure something like this:

<h1>
  <a href="/some/place">this page's title</a>
  <a href="/some" class="exit-link">...</a>
</h1>

By making some assumptions about the situations in which exit links are used, we can increase their uniformity.

@import centering
has-exit-link()
	position relative    // support positioned children

	// Assume that the title text is contained in a single element.
	> :first-child
		padding-left 1em  // get past the exit link

	> .exit-link
		left -.25em
		vertically-center()
		margin-top -.25em

When used in conjunction with a title, the exit link should affect the centering and clipping (via text-overflow) of the title. In other words, the the title’s container should not overlap with the exit link. We’ve found that flexbox is the only way to accomplish this.

This is an old, though. Maybe it’s not the case anymore. I assume it was a flexbox thing, whatever I saw.

As of this writing, we still have two main ways of pointing at virtual things: via mouse and touch screens. While touch screens are gradually replacing the mouse for gesture inputs, they will both be around for a while, and we need to make sure they both work as expected.

Although touch screens have been around for a long time, they were not mainstream until the “mobile revolution” of the mid 2010’s. Many people find touch screens much more natural to use, but for software designers raised in the mouse era, touch screens are a major curve ball.

Hands are capable of an infinite range of expressiveness.¹² If the mouse reduced this infinite range to a thin trickle, touch screens reduced it significantly less so. Naturally, it took browser vendors a long time to agree on how exactly to model this “new” thing.¹³ In the meantime, browsers basically mapped touch events to whatever seemed like the closest mouse equivalents. This was a stopgap. The mouse pointer, for example, is always on the screen, whereas fingers can go onto the screen and come off again. And so on. Those differences are a problem for the people working on the web platform itself.

But for our part, we’d rather not think about it. When we’re making things that might get pointed to, we don’t care what the pointing method is. We only wish to express the intention that something change in a certain way when the user is pointing at it. If we can do that without reference to the mechanism, that’ll cover us most of the time. So we define a notion called user_pointing_at:

user_pointing_at(also = '')
	when = '&:hover, &.active, &.pointing'
	when += ',' + also if also
	{when}
		{block}

This allows us to treat the “hovered” state as equivalent to the “touched” state—more or less. A touch stops being considered a pointing gesture when it moves (while still on the screen), since this is generally interpreted as an intention to scroll. We cover this exception in the script below.

We also include :active here, meaning that links will retain the “pointing” style while they are being processed, even after the touch is over. This provides additional feedback that something is happening.

Now, wherever we want to give feedback that a thing knows it’s being pointed to, simply use it like so:

#some-thing
	+user_pointing_at()
		background $special_color

(Note that block mixins must be prefixed with a plus sign.)

Generally this will be used for links (a.k.a. signs), which are the only thing in the space that responds to pointing. In fact, the following script assumes as much.

Now all we need to do is set the pointing class on links while they are being touched.