Most of the web has received a major upgrade the last few years. HTML finally got some love with HTML5; CSS is beginning to come out of the dark ages with efforts like SASS to explore what's possible and then standardizing them back into CSS itself like CSS variables. Even JavaScript has gotten upgraded with ES 6 so that it continues to stay productive.

One key part of the web that hasn't received any attention since it's founding is the plain old hyperlink, you know, the URL that lets you point at and talk about anything on the web. We still have exactly the same hypertext we had when the web booted up in the early 90s. We've got the same old 8-bit hypertext while the rest of the web's foundations have rapidly zoomed beyond. Just to keep this in perspective, the hyperlink we know predates Windows 95. Yikes.

Why should we care about hyperlinks and evolving them? Well, first, hyperlinks are at the heart of Google's search engine algorithm, Page Rank. Literally the way that we actually find almost everything on the web depends on the hyperlink; if we make the hyperlink just a little bit better we should therefore also help make search better.

Second, the hyperlink is how we talk about things. Douglas Engelbart has a term that he calls granular addressability. This refers to the ability to talk about everything that's out there using hypertext. As a side note, it's thanks to Doug (and Ted Nelson too) that we have hypertext at all, as they are the original inventors of it.

So, how can we make hypertext better? I think two very simple things would make hypertext much more powerful on the web; one of them is a small little technical piece and the other is a small user facing feature:

• the ability to point to any piece of content on an HTML page using a very simple boiled down syntax
• the ability for a user to right-click or, on a touch device, hold and get a little menu on any part of a webpage and copy a small link right to that piece onto the clipboard.

Basically, both of these would bring granular addressability to the web.

Let's start with the user facing feature first. On a desktop machine, a user could right-click on a paragraph or any part of the page and they would see a new menu option that might say something like "Copy Link to". If they select this then it will be copied to the clipboard as a URL that would directly go to this block on the page. They could then copy this into an email, a tweet, or a Google Doc document that they're working on in order to directly point someone else to this other part of the page.

Since multitouch devices like the iPad don't have a right-click menu, we would need to have an equivalent way to copy a link on those devices. Perhaps you could hold your finger down on an object in the web browser and that would allow you to get a menu to copy it to your clipboard.

So that's the user facing side what does one of these links look like?

The link would have a normal HTTP link on the left side going to the page itself followed by an anchor hash. After this, if the object that the user had right-clicked on had an ID attribute, then the hash would just have the ID attribute afterwards like a normal standard named anchor link today:

http://example.com/somepage.html#some_id

If there is no ID attribute, after the hash would be a very simple numerical offset going through the structure of the document until it hits the element in question. Very simply, basically this would have the DOM order of this element in relation to what's above it. It would be a kind of slash offset telling you how to count over to the element. It would start from one rather than zero as most users understand going from one. Also note that it would only be counting real elements in the DOM (i.e. markup) rather than whitespace or other nodes like comment nodes. Here's an example of what one might look like:

http://example.com/somepage.html#path(5/2/5/2)

Also, we are not trying to boil the ocean and have these paths be resistant to changes in the remote page; we are just giving you the ability to point to the remote page and the offset will take you to it as a best effort, just like the original web hyperlinks didn't try to protect you from 404s. If the remote page has changed or if an element is not visible the browser would do nothing if it can't resolve the path and the browser would stay at the top of the page. If the path resolved to a visible element then it would scroll to the element just like a normal named anchor does today.

Those are the only two things, short and sweet. They probably would be very straightforward to implement and could be built with basically features that are already in the browser. Just having these two things would really help give hypertext more addressability in a way that's accessible to end users and could really help in a deep way.

We need to implement these natively into the browser. I'm focusing on Chrome because I really think Chrome is the browser actually moving the web forward today in my opinion. They really are the vanguard of pushing all of the pieces of the web stack forward into new directions, except for hypertext so far. Chrome is the place this would happen first.

A common criticism is that we don't need to implement this in the browser as this could just be done as a browser plug-in or as JavaScript running in the page. Unfortunately, hypertext is one of those cross-cutting features that has a real chicken and egg problem: if it's not across the web infrastructure itself, no one will use it because you don't know whether the page you are pointing at even supports this feature and it becomes very difficult to get a critical mass if it doesn't show up in enough places to be interesting.

Imagine if the web itself had chosen to make links optional. Perhaps the page itself had to somehow have JavaScript or a plug-in to make links happen; obviously this would be very silly and links never would've taken off on the web. Notice that this is exactly what happened to Flash; Flash had an optional linking feature that no one ever used since it was optional and hard to surface to users; this was one of the things that helped contribute to the death of Flash since it turned them into big opaque binary blobs that didn't always play nice with the rest of the web.

I do believe that most new technical end-user facing features on the web should start out as JavaScript and browser plug-ins. However I think that the small new feature of hypertext I'm proposing is unique in the fact that it would not be able to really make a presence on the web without native support.

Let's see web hypertext finally get a little bit of cleanup and the ability to do granular addressability. I would love to see Chrome be the first browser to make this possible. Tell me what you think.

Subscribe to my RSS feed and follow me on Twitter to stay up to date on new posts.

Please note that this is my personal blog — the views expressed on these pages are mine alone and not those of my employer.