Blog: Eliminating Javascript requirements?

I’ve been informed that my blog does require Javascript - without it, it simply doesn’t fade in.

Unfortunately, I’m not quite familiar enough with HTML/CSS/etc anymore to really have a good sense of how to fix it, and muddling around for a bit didn’t resolve anything.

In js/common.js:

  /* =======================
  // Animation Load Page
  ======================= */
  setTimeout(function(){
    $('body').addClass('is-in');
  },150)

Ok, easy enough, adds “is-in” to the body class.

is-in is referenced in the main css (which is apparently minified into the top of each page). Relevant chunk from the templates:

body {
  font-family: $base-font-family;
  font-size: $base-font-size;
  line-height: $base-line-height;
  color: $text-color;
  background-color: $background-color;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  overflow-x: hidden;
  &.is-in {
    &::after {
      visibility: hidden;
      opacity: 0;
      pointer-events: none;
    }
  }
  &::after {
    content: "";
    position: fixed;
    left: 0;
    top: 0;
    width: 100%;
    height: 100%;
    background-color: $dark;
    z-index: 999;
    transition: 1s;
  }
  input, textarea {
    border: 1px solid $light-gray;
    outline: none;
  }
  
  @media only screen and (max-width: $mobile) {
    font-size: 16px;
    line-height: 29px;
  }
}

Presumably, if I apply whatever is-in does by default, or disable whatever it reverts, this will prevent the page from being blank on load.

Suggestions? :slight_smile:

There’s also lazy-loading images, but I think I can probably boggle that out myself.

//EDIT: For lazy loading without JS, there’s just a new extension that does it!

https://caniuse.com/loading-lazy-attr

Not fully supported in everything yet, but falls back to images loading. I wonder if that works with picture sets…

So what I would do (and I don’t program shite remember) is set it so it’s normal, and then use JavaScript to blank it and fade in.

The problem then becomes it might flicker.

The problem is that .is-in may not be applying the effect you’re talking about at the body level but it might be applying in a nested div or other component which takes that hierarchical attribute. What I’d recommend is to use the web inspector, look at the final CSS properties (computed) of the body, and by hand-editing the is-in attribute into or out of the body text, looking at what changes in the final computed attributes. You can often turn them on and off individually to see which is having the effect you want, then you can try modifying that specific property wherever it is originating (it may not be in that template, it may be being provided by another inclusion, etc… CSS has no authoritative final source and can always be overridden by a later stylesheet or JS-injected style). You can also go the other direction: remove the JS that sets the is-in attribute and remove computed style designators until the page becomes visible, then eliminate those directives from their respective sources.

CSS and page style, being dynamic, are not easy or direct to troubleshoot and there are absolutely no patterns shared across tools, developers, projects, or dependencies, so it’s really a nightmare to try to figure out how to “fix correctly” as there is no really useful definition of “correct” and zero reference point to try to base one on.

Hi, seasoned web-developer here :wave: (I think they call us senior software engineers, but that feels like too grandiose of a title, I always liked webmaster the best)

Kind of a clever effect. The main bit is this:

body::after {
    content: "";
    position: fixed;
    left: 0;
    top: 0;
    width: 100%;
    height: 100%;
    background-color: #09080f;
    z-index: 999;
    transition: 1s;
}

It’s creating a pseudo-element, that’s positioned over everything, and makes the entire page black. The key attribute here is transition: 1s;

So after 150 milliseconds the is-in class is added to the body, and the following CSS takes precidence:

body.is-in::after {
    visibility: hidden;
    opacity: 0;
    pointer-events: none;
}

You can see it takes the black pseudo-element covering everything and set’s it’s opacity to 0. By having the transition property set to 1 second, you get a cool fade-in effect for your content.

See screen-capture: fade in effect Screencast 2021 10 14 10:49:34 - YouTube

Removing this effect is fairly strait-forward. Remove the pseudo-element body::after. Then the is-in class that nullifies it can also be removed. Then you can remove the JS that adds the nullifying class to the now removed pseudo-element.

Hope that helps.

1 Like

Thanks! I’ll try those changes out tonight!

… and actually push them to production some months later.

To the best of my knowledge, I’ve eliminated Javascript requirements for my blog. I got rid of the transition fade in for page load, removed lazy loading from images, and refactored stuff to actually load the images (it was using the “data-src” element in the “img” tag, and then lazy loading, so I had to convert those to “src” so a non-JS browser would properly load the images, I just don’t care about lazy load that much).

The only real “not working” bit is that on the main page, you can’t load more posts with the “more posts” button, because that’s JS loading new content. However, all the posts are still accessible from the “All Posts” link up at the top, so it’s not a functionality breaking bug. Search doesn’t work either, but, again… it’s a JS based search, I literally don’t care if it doesn’t work without JS.

Any other obvious bugs people notice with JS disabled?