URL – CSS-Tricks

(Hyper) Links About (Hyper) Links

Geoff Graham — Fri, 02 Aug 2024 16:41:54 +0000

Heydon on the virtues of hyperlinking hypertext in an anchor element:

Sometimes, the is referred to as a hyperlink, or simply a link. But it is not one of these and people who say it is one are technically wrong (the worst kind of wrong).

[…]

An is an interactive element (well, it is if it has an href). The text inside an interactive element is sometimes referred to as a label since it should tell you what the element does. Since anchors take you places on the web, the text should tell you where you would be going or what you can do there.

[…]

Web developers and content editors, the world over, make the mistake of not making text that describes a link actually go inside that link. This is collosally [sic] unfortunate, given it’s the main thing to get right when writing hypertext.

As far as where that anchor hyperlinks to, Jim Nielsen back in 2003 discussed a bunch of considerations that go into designing URLs. More recently, he’s mused on the the potential of well-designed URLs to change — or more accurately, the potential of humans to change things:

If a slug is going to be human-friendly, i.e. human-readable, then it’s going to contain information that is subject to change because humans make errors.

Swapping the contents of a URL is a breaking change. If we were to start with a wonderful URL like, say:

…but decide that we now like “Docs” instead of “Almanac” then we might do this:

Naturally, we’d drop some sorta redirect on the server so that anyone attempting to hit /almanac is automatically directed to /docs instead. But now we’ve got a form of technical debt to maintain that may not be any more dangerous than walking and chewing gum at the same time, but could become a mouthful much later. We’ve got a gazillion redirects on CSS-Tricks for a gazillion different reasons, most often for totally human reasons like typos. Remember the CSS-Tricks Chronicles we used to write? Botching the Roman numeral numbering system on those was standard fare. Look at the very last edition from 2001, titled “CSS-Tricks Choronicles XLI” and its URL:

https://css-tricks.com/css-tricks-chronicle-xxxxi/

🥸

I’ve been thinking about this a lot while attempting to organize the 7,000 some-odd articles on this site. For years, we’ve maintained a “flat” structure in the sense that the title of an article becomes the URL (after, perhaps, with some light editing):

But I’m starting to think about the content on this site in terms of type rather than title alone. For example, we’ve always had “articles” on this site with a smattering of “links” sprinkled in alongside Almanac “entries” and “guides” among other categories of content. We’ve just never reflected that in our URLs because, well, the design is flat. Adding another layer for the type of content borks the original URL!

Jay Hoffman has been thinking about this, too.

A dead link may not seem like it means very much, even in the aggregate. But they are. One-way links, the way they exist on the web where anyone can link to anything, is what makes the web universal. In fact, the first name for URL’s was URI’s, or Universal Resource Identifier. It’s right there in the name. And as Berners-Lee once pointed out, “its universality is essential.”

[…]

Time and time again, when the web goes into crisis and part of it is lost, the Internet Archive and similar efforts come to the rescue. But even the Internet Archive is having a hard time protecting against a barrage of link rot we can’t seem to get away from.

All of this dovetails into recent reporting that Google has decided to sunset its URL shortener. All of those goo.gl URLs accumulated since the shortener was introduced in 2018?

Any developers using links built with the Google URL Shortener in the form https://goo.gl/* will be impacted, and these URLs will no longer return a response after August 25th, 2025. We recommend transitioning these links to another URL shortener provider.

There’s some minutiae of consolation for Google itself:

Note that goo.gl links generated via Google apps (such as Maps sharing) will continue to function.

To be clear, this move is less a form of link rot than it is a straight-up pruning to cut things off. If link rot is akin to allowing your hair to go gray, then deprecating Google’s URL shortener is a total head shave. Nick Heer believes there’s a good side to it, however:

In principle, I support this deprecation because it is confusing and dangerous for Google’s own shortened URLs to have the same domain as ones created by third-party users. But this is a Google-created problem because it designed its URLs poorly. It should have never been possible for anyone else to create links with the same URL shortener used by Google itself.

I tend to agree. The whole situation is a Rosemary’s Baby predicament presenting two terribly uncomfortable choices. The right uncomfortable decision was made, but we still have to deal with the repercussions of wiping out part of the web’s context.

Heydon’s post led me down this rabbit trail, so I’ll link it up here for you to take a hike with it.

To Shared Link — Permalink on CSS-Tricks

(Hyper) Links About (Hyper) Links originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Trailing Slashes on URLs: Contentious or Settled?

Chris Coyier — Fri, 25 Feb 2022 21:13:08 +0000

A fun deep dive from Zach. Do you have an opinion on which you should use?

1) https://website.com/foo/
2) https://websites.com/foo

The first option has a “trailing slash.” The second does not.

I’ve always preferred this thinking: you use a trailing slash if that page has child pages (as in, it is something of a directory page, even if has unique content of its own). If it’s the end-of-the-line (of content), no trailing slash.

I say that, but this very site doesn’t practice it. Blog posts on this site are like css-tricks.com/blog-post/ with a trailing slash and if you leave off the trailing slash, WordPress will redirect to include it. That’s part of the reason Zach is interested here. Redirects come with a performance penalty, so it’s ideal to have it happen as infrequently possible.

Performance is one thing, but SEO is another one. If you render the same content, both with and without a trailing slash, that’s theoretically a duplicate content penalty and a no-no. (Although that seems weird to me, I would think Google would smart enough not to be terribly concerned by this.)

Where resources resolve to seems like the biggest deal to me. Here’s Zach:

If you’re using relative resource URLs, the assets may be missing on Vercel, Render, and Azure Static Web Apps (depending on which duplicated endpoint you’ve visited).
on /resource/ resolves to /resource/image.avif
on /resource resolves to /image.avif

That’s a non-trivial difference and, to me, a reason the redirect is worth it. Can’t be having a page with broken resources for something this silly.

What complicates this is that the site-building framework might have opinions about this and a hosting provider might have opinions about this. As Zach notes, there are some disagreements among hosts, so it’s something to watch for.

Me, I’d go with the grain as much as I possibly could. As long as redirects are in place and I don’t have to override any config, I’m cool.

To Shared Link — Permalink on CSS-Tricks

Trailing Slashes on URLs: Contentious or Settled? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

“Killing the URL”

Chris Coyier — Fri, 07 Sep 2018 23:05:37 +0000

It was Safari who first started hiding the complete URL. Here’s what CSS-Tricks looks like even when you’re on an article page by default in Safari:

The full URL path is hidden.

You can only fix it (YES, FIX IT) by checking “Show full website address” in settings.

Preferences > Advanced

We’ve already damaged the sanctity of URLs in a way with URL shorteners. Thankfully, those are used less and less with social networks, like Twitter, not counting the URL toward the total tweet character count anymore.

Now, Lily Hay Newman reports Chrome sees problems as well:

“People have a really hard time understanding URLs,” says Adrienne Porter Felt, Chrome’s engineering manager. “They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity. So we want to move toward a place where web identity is understandable by everyone—they know who they’re talking to when they’re using a website and they can reason about whether they can trust them. But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity.”

I’m not seeing the same research they are. Anecdotally, I’m not sure I’ve met anyone who doesn’t understand a URL. I wonder if there is something else weird afoot here. URLs are the single greatest feature of the web. I know nobody is arguing about removing them (just visually hiding them by default), but it doesn’t feel like a step in the right direction. It also seems slightly at odds with the celebration of the web in Chrome’s 10-year anniversary post by Paul Kinlan:

We can thank all the browser vendors for their continued work to create and iterate on specs, using streamlined processes like those defined by the WICG and based on the principles in the Extensible Web Manifesto. We’ll continue our commitment to work with browser vendors and the developer ecosystem to prioritize features that users need, and to ensure that those capabilities arrive in a “webby” way.

I’d say seeing URL’s is pretty “webby.”

“Killing the URL” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Guidelines for URI Design

Jacob Gillespie — Mon, 02 Aug 2010 12:42:35 +0000

This is a guest post by Jacob Gillespie who started an interesting thread on Forrst about this topic. I invited him to post it here, to which he graciously accepted.

Over the past several years, I have taken an interest in usability and web design. One of the areas that seems to be often overlooked when it comes to design of a site is the design of the URIs on that site. Modern CMS systems allow for varying degrees of URI customization, but the defaults are often not as usable as they could be, and URIs are often placed last in the design process.

Clean URIs are one component of a clean website, and it is an important one. The majority of end-user access to the Internet involves a URI, and whether or not the user actually enters the URI, they are working with one nonetheless.

First, I would like to talk about the guiding principles behind URI design, then talk about the practical implementation of the principles.

Note: Originally, I wrote this article draft using the term “URL,” but since “URL” has been mostly deprecated by “URI,” I’ve updated to use the term URI. More information from W3C.

Principles

First, let’s take a look at some of the general principles of URI design.

A URI must represent an object, uniquely and permanently

One of the most fundamental philosophies behind a URI is that it represents a data object on the Internet. The URI must be unique so that it is a one-to-one match – one URI per one data object.

While this is always the goal, there are times at which it is very difficult or impossible to accomplish. Canonical URL tags were invented to help reduce the amount of duplicate content seen by a search engine. While not a final solution, canonical URLs are strongly recommended as large search engines like Google are now paying attention to them. For more information about canonical URLs, check out this article by SEOmoz.

URIs should also be permanent (i.e. choose the URI once and leave it at that). This speaks to good URI design before a site is launched, with the URIs being carefully planned. There will come a time when you do want to make improvements to your choices or otherwise must change URI structure. When this becomes a necessity, be sure to set up HTTP 301 moved permanently redirects on your server. This tells browsers and search engines the new location of the content and will also preserve any PageRank that the old URI has accumulated.

Be as human-friendly as possible

This is the most fundamental driving factor behind URI design (or it should be). URIs should be designed with the end user in mind. Search Engine Optimization (SEO) and ease of development should come second.

One way to keep a URI user-friendly is to keep it short and to the point. This means using as few characters as possible while still maintaining usability. So, /about is better than /about-acme-corp-page. While striving to be as short as possible, it should not sacrifice that user-friendliness by using URIs like /13d2 as this holds no meaning for the end users.

Conversely, using a shortlink whenever sharing a URI is encouraged. This is great for tweeting links on Twitter, or otherwise sharing on social sites like Facebook or Google Buzz. It is great if you can control your own URI shortener for SEO reasons, although a site like Bit.ly is good too. I personally use PrettyLink Pro (a WordPress plugin) to create my short URIs. An alternative is the Short URL plugin.

WordPress provides a button to get a shortlink to a post based on WordPress’ own /?p=XXX format which is likely to be shorter than your chosen permalink structure. The advantage being that will work as long as your site is around. The disadvantage is the shortness of the link is dependent on the length of your domain name.

The URI should not rely on information that is not important to the content or the user. A common example of this is using the database ID as the URI, as in /products/23. The end user does not care that the product is database record number 23, so a URI like /products/ballpoint-pen is much better. It can be tempting to resort to such poor URI structure as it is often easier on the backend to query the database with an ID rather than have to do a lookup on an alias to find the object.

One good test to see if a URI is a user-friendly URI is the “speech-friendly” test. You should be able to mention a URI in a conversation with a friend, and it should make sense. For example:

My bio’s at domain dot com slash jim

instead of

My bio’s at domain dot com slash page slash g g 2 3

Consistency

URIs across a site must be consistent in format. Once you pick your URI structure, be consistent and follow it! Having good URI structure for part of the site means that you still have poor structure overall. In order for a user to trust that URIs work a certain way on a site, the format must be consistent. If you must switch structure (maybe you’re updating a poorly-designed site), use 301 redirects as previously mentioned.

“Hackable” URIs

Related to consistency, URIs should be structured so that they are intelligibly “hackable” or changeable. For example, if /events/2010/01 shows a monthly calendar with events from January 2010, then:

/events/2009/01 should show an events calendar for January 2009
/events/2010 should show events for the entire year of 2010
/events/2010/01/21 should show the events for January 21st, 2010

Keywords

The URI should be composed of keywords that are important to the content of the page. So, if the URI is for a blog post that has a long title, only the words important to the content of the page should be in the URI. For example, if the blog post is “My Trip to Best Buy for Memory Cards,” then the URI might be /posts/2010/07/02/trip-best-buy-memory-cards or something similar.

As a side benefit, using important keywords in the URI will improve SEO. My personal SEO philosophy is that, rather than optimize for search engines, optimize for good content. Search engines have made it their goal to find the best content on the web, so doing everything possible to create an easy-to-use site with great content and opportunities for further information (links) will, in my opinion, yield the best long-term results for search engine visibility.

Technical Details

We have covered some of the guiding principles behind URI design. Now, let’s look at some technical implementations of those guidelines.

No evidence of the underlying technology

The URI should not have .html, .htm, .aspx (a big annoyance), or anything else attached to it that is only designed to show the underlying technology. No end user cares that your site was written in ASP.NET (.aspx), ColdFusion (.cfm), or uses Server Side Includes (.shtml) – or at least most end users don’t. The extra info is just extra typing and extra room for error and frustration.

The one exception to this rule is appending a URI with a postfix like .atom, .rss, or .json to request that the certain format be returned. Alternatively, the format could be requested with the Accept HTTP header.

No WWW

The www. should be dropped from the website URI, as it is unnecessary typing and violates the rules of being as human-friendly as possible and not including unnecessary information in the URI.

Many users, however, will still type in the www. prefix, so www.domain.com should 301 redirect to domain.com. The same goes for 301 redirecting www.subdomain.domain.com to subdomain.domain.com.

Format

URIs should be in the format:

domain.com/[key information]/[name]/?[modifiers]

Key information is information that is not the object identifier (like the post title), but is still key to the object being accessed. This may include:

the type of thing (i.e. posts)
the overall parent category (i.e. technology)
key data members (i.e. the date posted)

Modifiers modify the view, not the data model being represented, and thus they are part of the query string and not the URI itself.

The amount of “key information” should be kept to a minimum, as URIs should not be overly nested. Each item placed in the key information section must really be key to addressing the page.

In the end, the URI should represent a descending hierarchy. For example

domain
type
category
title

Example: http://domain.com/posts/servers/nginx-ubuntu-10.04. In the case of items with dates, the format should follow the descending hierarchy:

year
month
day

Example: http://domain.com/news/tech/2007/11/05/google-announces-android.

Google News has some interesting requirements for webpages that want to be listed in the Google News results – Google requires at least a 3-digit unique number. Due to the fact that they will ignore numbers that look like years, a 5 or more digit number is preferred. Also recommended is a Google News sitemap. This is one of those cases where if you absolutely must target Google News, you must conform to this inferior URI structure. But, if you must, make sure that you are consistent and that it is still hackable (for example, use the format yyyymmdd like 20100701).

All lowercase

All characters must be lowercase. Attempting to describe a URI to someone when mixed case is involved is next to impossible.

If someone types the URI in mixed-case, they should be 301 redirected to the lowercase page. That sounds really nice, but in practice, I’m not exactly sure if that is possible… using a CMS that rewrites all requests to a single file would be the easiest way to accomplish it as the script could issue the 301 to lowercase, but I’m not sure if there’s an easier way (.htaccess rules or something).

Actions appended to the URI

Actions may be appended to the URI, like show, delete, edit, etc. Non-destructive actions (those that do not change the object) should be requested with a HTTP GET, while destructive actions should be POSTed to the URI. Run a Google search for REST URI Design for more information.

URI identifiers should be made URI friendly

A URI might contain the title of a post, and that title might contain characters that are not URI-friendly. That post title must therefore be made URI friendly. For example

All uppercase characters are made lowercase
Characters like é should be converted to e (etc.)
Spaces should be replaced with hyphens
Unknown characters (!, @, #, $, %, ^, &, *, etc.) should be replaced with a hyphen
Double hyphens (–) should be replaces with a single hyphen
Probably more rules I’m forgetting

Characters can be URI escaped (like %20 for the space character), but this is generally a bad idea for many of the above reasons (shows technology, unnecessary typing, etc.)

Fun idea

Use a sentence like structure (credit to Chris Shiflett):

chriscoyier.net/authored/digging-into-wordpress/
chriscoyier.net/has-worked-for/chatman-design/
chriscoyier.net/likes/trailer-park-boys

jacobwg.com/thinks/this-post/is/basically-done

If you know of any more URI guidelines that I missed or have any comments about those I did remember, I’d love to hear them!

Credits

Many thanks to the Forrst community who saw the initial (very) rough drafts of this post and contributed many insightful comments. Special thanks to @chriscoyier, @caludio, @steerpike, and @mattthehoople for directly contributing to the guideline list and to all the other Forrst commenters for providing helpful discussion.

Thank you to my dad for proofreading and review! Thank you also to Chris for being kind enough to offer to post this on CSS Tricks!

Guidelines for URI Design originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.