This element works perfectly fine in just HTML, which is the foundation of progressive enhancement.

And now, in your JavaScript, the functionality this button provides isn’t really necessary anymore, and your plan is to hide this element.

What is the best way to accomplish this?

A “js” Class

A classic approach to this is hiding the button when you know JavaScript is available. You put something like this pretty early in your HTML:

<script>
  document.documentElement.classList.add("js");
</script>

If this executes, you’ve proven that JavaScript is available, so you hide the button:

html.js {
  .save-button {
    display: none;
  }
}

As appealing as this looks, it may not be the catch-all perfect solution.

Downsides:

• You’ve proven here that JavaScript is available, but you aren’t checking if the particular JavaScript that does the auto-saving is loaded and has run successfully. You can probably account for that by applying a more specific class just for this situation and applying it after the code that implements auto-saving.
• The longer you (necessarily) have to wait for the JavaScript to be done, the longer the button is visible on the screen. This is likely to cause a “flash” of the button being there where is doesn’t need really need to be.

On States

This question came up for me from a ShopTalk Show listener Tibor Leupold writing in asking about it. He was concerned about layout shift as a result of hiding the element(s) as well as the awkward UX.

Let’s get this one out of the way: couldn’t you just… leave the interactive elements there but change their functionality when the JavaScript loads? Maybe? Probably? That’s skirting the question though. Let’s assume the web is a big place with an unknowable amount of situations and that this particular situation of needing/wanting to hide an element with minimal impact is a reasonable one.

A way to think about our needs here is that there are three states to concern ourselves with:

1. JavaScript is unavailable entirely
2. Before the relevant JavaScript has loaded and executed
3. The relevant JavaScript is loaded and executed successfully

No JS

We’re probably not going to hide the button by default, as we don’t have a mechanism for un-hiding it in a no-JS situation. So we basically don’t need to do anything to accomplish this state, just have the interactive element on the page and functional in HTML.

In the reverse situation, where you have an element on the page that only works with JavaScript, you can hide it in a no-JS situation like:

<noscript>
  <style>
    .js-only-interactive-element {
      display: none;
    }
  </style>
</noscript>

Before JS Loaded

This is the hardest state. In this state, perhaps we know that JavaScript is available, but we don’t know how long it’s going to take or even if the JavaScript we care about is going to execute successfully.

It seems like the ideal behavior would be “hide the interactive element for a brief period, then if the relevant JavaScript isn’t ready, show the element.” But how?! We can’t count on JavaScript for this behavior, which is the only technology I’m aware of that could do it. Rock and a hard place!

Maybe there is some extremely exotic technique involving HTML streaming that could delay the “send” of the interactive element down from the network for that brief blocking period? That’d be wild.

Another thing I think of is the behavior of font-display: block;. This is about the behavior of loading custom fonts via CSS @font-face. It can tell the browser how to behave while the custom font it loading. Do you want the browser to wait to see if the custom font loads and then “swap” to it? You’ve got options. The block value says:

Gives the font face a short block period and an infinite swap period.

Seems related! Maybe there is a way to bring this kind of behavior to progressive enhancement elements to mimic the behavior we want: “hide the interactive element for a brief period, then if the relevant JavaScript isn’t ready, show the element.” Help us, web platform.

JS Ready

This is a fairly straightforward state, but it’s the cause of the “flash” and potential layout shift.

function setUpInfiniteScroll() {
  // do all the work

  // at the end, say it's ready
  document.documentElement.classList.add("infinite-scroll-ready");
}

.infinite-scroll-ready {
  .load-more-link {
    display: none;
  }
}

The problem here is: how long is that “Load More” link going to be on the page before it disappears? Is it fairly instant? A few hundred milliseconds? Eight seconds? Never? (You really can’t know.)

Also: will the layout shift it triggers cause the user to potentially click on something they didn’t mean to? Maybe hiding can be done without the layout shift?

.infinite-scroll-ready {
  .load-more-link {
    visibility: hidden;
  }
}

Is there a better way?

I feel like people have been thinking about progressive enhancement for a couple decades now. Is there an extremely clean/simple way to do this that I’m just not seeing?

Deane Barker writes:

What if you want a Markdown-friendly way to represent a feedback form, or a tabbed UI, or a mortgage calculator, or something else way beyond the scope of text formatting.

For these situations, what you really want is to put a token or a placeholder in your Markdown, and have something else expand it later on into a larger, more complicated HTML construct.

What you sort of need is… Markdown for More Complicated HTML™.

Enter Custom Elements.

If you want to put React components into Markdown, you’ve got MDX, but MDX can get Very Complicated™. If you just want to use Web Components in Markdown, well, Dave really said it best.

Your goal is to be able to send someone to that page with one particular details element open.

I was doing just this recently, and my first thought was to do it server-side. If the URL was like website.com/#faq-1 I’d see if faq-1 matches an ID of the details element and I’d put the open attribute on it like <details id="faq-1" open>. But no, you don’t get to have the #hash as part of the URL server side (for whatever reason 🤷‍♀️).

Then I started writing JavaScript to do it, where you definitely can access the hash (window.location.hash). I’d just querySelector for the hash and if I found a matching details element, I’d open it up.

Then I was reminded you don’t need to do this at all. What you need is (drumroll)… HTML.

The trick is hash-linking to an element inside the <details>. So like:

<details>
  <summary>What was Rosebud in Citizen Kane?</summary>
  <div id="faq-1">A sled.</div>
</details>

Now, if you hash-link to #faq-1, the browser will know that it has to open that <details> in order for it to be seen, so it does. You don’t normally need a <div> wrapper or anything inside the details element, but we’re doing it here as it’s obviously handy.

Here’s a demo of a page that is set up in this way:

It’s probably more interesting to just visit this hash-link URL and see it open right up and work.

This came up for me while working on this documentation page where I wanted to be able to link to specific things that were otherwise “buried” in details elements.

As a bit of an enhancement, you might want to consider CSS like this:

:target {
  background: yellow;
  scroll-margin-block-start: 4rem;
}

That will apply some styling to the element that matches the hash in the URL, as well as push it away from the top edge of the browser window a little bit. In this case, it helps make sure the FAQ question is actually visible, not just the answer.

First, there are actually three kinds of popovers. There is the normal kind, which close when you click away (or ESC). If you don’t want that, there is the “manual” kind which requires very explicit closing and lives an isolated life, not affecting other popups. The new kind, “hint”, is an in-betweener where it can be opened without closing other normal popups, yet retains the light dismissal properties.

Second, it doesn’t have to be a click to open a popover. You could bind whatever you want in JavaScript naturally, but with a new interestfor attribute (and CSS friends) you can cause a trigger on essentially a hover (with a mouse) or focus (with a keyboard). All experimental stuff, but ✨cool✨.

Hot off the presses! Firefox Nightly adds the new :heading pseudo! Easily style all headings, or use nth-child-like AnB syntax to select a range of headings! Needs layout.css.heading-selector.enabled flag enabled.

Demo.

We’ve covered the very fastest way to get those files turned into a deployed website on the internet already, using Netlify’s tool. That totally works, but we can take things a little further to make things easier on our future selves.

Websites tend to need to be updated. Technically, you can keep using that tool to drag-and-drop your entire site again. But since we’re here to learn to be a better developer, let’s do better than that. We’re going to start using Git and GitHub. Let’s do the steps.

Git?

Git is the name of the technology we’ll use, which is what they call a VCS or Version Control System. We’ll put our files in Git, then when we change anything, Git will know about it. Git allows us to “commit” those changes, which gives us a history of what changed. That alone is a great feature. But crucially, Git allows us to work with others (they can “pull” those commits) and most importantly for us today: connect other apps to Git. For example, when changes are pushed up, “deploy” the changes to the live website.

1) Make sure you have a GitHub account

There is a 99.99% chance you’ll need/want a GitHub account in your developer career. If you don’t already have one, get one:

2) Get the GitHub Desktop App

We’re baby-steppin’ here, and I think it will be easier for us to use the official GitHub app than it will be to use what developers call “the command line” to work with Git (but someday you can level up).

Honestly, I’ve been using Git for a hot long while and I still use GUI apps like this (literally this) to work with Git as I prefer the visual nature of it. This is true of many of the talented developers I work with, who are are very capable of command line usage as well.

3) Make a Repo

“Repo” is just short for “repository”. You could make one locally and push it up to GitHub as a second step, but for whatever reason I prefer making it on GitHub, “pulling it down” and going from there.

4) Pull the Repo from GitHub to your Local Computer

One reason to use the GitHub Desktop app we downloaded is that the GitHub website is nicely integrated with it, giving us a quick button to click:

This folder will essentially be empty. (In truth, it has a .git folder inside of it, but most operating systems and code editors hide folders and files that start with a . by default so you don’t see it while browsing files.)

5) Put your static files in the folder you just pulled down

Now you can drag your static files into that “empty” folder that is your repo. When the files are in there, GitHub Desktop (and really, Git itself) will “see” those files as changes to the repo. So you’ll see this:

(That .DS_Store file is just an awkward thing macOS does. Try right-clicking that file and ignoring it and seeing what that does.)

6) Push your static files to the Repo

All those files are now selected (see the checkmarks). Type in a commit message (where it says “Summary (required)” in GitHub Desktop) and then clicking the blue Commit button.

After committing, you will no longer see any local changes, but you’ll see that “commit” you just did under the History tab. Your job now is to click the Publish branch button on in the upper right.

After you’ve done that, you’ll see the files you “pushed” up right on GitHub.com in your repo URL:

7) Now that your website files are on GitHub, we can deploy them to a live website

Just so you’re aware, GitHub has a product called GitHub Pages where we could just make GitHub itself the home of your website. Jen demonstrates this in her course.

We’re also fans of Netlify here and generally think that’s the best option for projects like this, so sign up for a free account at Netlify if you don’t have one.

8) Make a New Projects on Netlify

One you’re in, go to Projects and add a new one by selecting Import an existing project.

Then select GitHub as that’s where our project lives.

You may need to grant Netlify permissions on GitHub:

Once Netlify is authorized, you’ll see a list of your repos. Find the porfolio one we’re working with and click it.

Now you pick the URL for it, which for now will be your-chosen-name.netlify.app. You don’t need to change any other settings, so scroll down and Deploy it.

9) Your Website will Go Live

Netlify will work on deploying it, which should be pretty fast probably. Maybe a few minutes at worst.

Then it will be live!

You can click that green link like you see above to see the website.

You can share that URL with anyone in the world and they’ll be able to see it. That’s the power of the world wide web. It’s awesome. Here’s a view of the files I uploaded:

10) Make Some Changes

Another wonderful part of working on websites is you can easily change them at any time. That’s part of why we’re working with Git, because we can push up those changes and keep track of them. We can also efficiently deploy only changed files and such.

If I change the files locally, the GitHub Desktop app will show me what has changed. I can check out those changes, confirming it’s exactly as I want, then type in a commit message and commit them, then click Push origin to both push the changes to GitHub and deploy the site on Netlify.

You really are a web designer and front-end developer now!

Next time we’ll take things just a smidge further, adding in a tool to help us build slightly more complex websites, which will make more clear why we’re using Netlify. And we’ll use a “real” domain name entirely of our own.

Anybody can translate the website though. There are a variety of site translation tools. I don’t have any data on popularity, but I gotta imagine Google Translate is up there, which is a website and Chrome Extension and, to some degree, automatic translation is just built into Chrome (and other browsers).

So let’s say I translate my website from English to Arabic, a right-to-left language (RTL). Here’s what I get:

It’s the exact same layout, it’s just the words are in Arabic now. Which is not terribly surprising, I guess? But even the alignments have stayed the same, so this RTL language is still being show in an LTR way.

Google Translate, aside from the text node translation, makes a few other changes that are notable here. What used to be:

<html lang="en">

Becomes:

<html lang="ar" class="translated-rtl">

Those changes do not actually change the direction to RTL. It could have, like:

<html 
  lang="ar" 
  class="translated-rtl" 
  dir="rtl"
>

Or it could have injected CSS like:

.translated-rtl {
  direction: rtl;
}

/* or */

[lang="ar"] {
  direction: rtl;
}

But it doesn’t. I don’t know for sure, but my guess is that it intentionally doesn’t do that, because it jacks up more layouts than it helps.

But let’s say you’re me (perfect, handsome) and you’ve changed your muscle memory for writing a lot of CSS properties to using logical properties. That is, stuff like padding-inline-start instead of padding-left, and the like. That, plus using layout like flexbox and grid, will reflow naturally with direction changes. So if you change the direction to rtl on my site, you get:

So the question is:

Is that “better”?

Meaning: does it read better for native Arabic speakers? Does it generally feel better or more native? Or is it worse, in that it’s unexpected or unnatural somehow?

I have a friend who speaks/reads Arabic, just for one anecdotal bit of data. I showed them a site and translated it, and they were like “it’s fine”. But then I showed them a tweaked one where things like the header and hero text and stuff was actually flipped, and they thought it was better. They were like “I never actually see this done, but it’s better this way.”

It’s likely that this no One True Answer here. Even if you’ve done a good job with a layout that flips and looks sensible. Alda Vigdís told me:

As someone who has worked on bi-lingual content, dir=”rtl” should of course be indicated for textual content, but the layout question depends on a lot more factors.

Arabic and Hebrew speaking power users often prefer to have a ltr-oriented layout, while some other groups prefer rtl-oriented layout.

So it may just be a matter of preference of individuals, which is more evidence for why Google Translate doesn’t go there (for layout). Perhaps they should be trying to find more fine-grained text nodes and flipping the dir there, but they don’t do that either.

If you land on “leave the layout alone, but flip the dir for text”, like Alda suggests, it would be a bring-your-own-CSS situation. You could use Google Translate’s class and flip just the text you need to, like:

.translated-rtl {
  p, li, dt, dd, td, th, h1, h2, h3 {
    direction: rtl;
  }
}

That feels a little 😬 to me, like you’ll miss some and make it worse instead of better or something. (I just picked those selectors randomly quick, to illustrate.) So much testing needed.

A flipped layout can be preferable even here though, as Naman told me:

There are somethings that work both ways. The sidebar can be on either side and it makes sense.

But something like the search bar makes a lot more sense with the layout flipped. [Also: headings in the sidebar are also a lot better with the layout flipped]

On balance, I think yes, flipping has an overall better result.

So if you’re looking for a straight answer, I’m afraid I can’t give you one. Except, ya know, do a good job.