Solving a Mystery Behavior of parseInt() in JavaScript

Dmitri Pavlutin digs into why parseInt(0.0000005); evaluates to 5:

parseInt(0.5);       // => 0
parseInt(0.05);      // => 0
parseInt(0.005);     // => 0
parseInt(0.0005);    // => 0
parseInt(0.00005);   // => 0
parseInt(0.000005);  // => 0
parseInt(0.0000005); // => 5 🤯

Solving a Mystery Behavior of parseInt() in JavaScript →

Remix v1 Beta Launch Video

Michael Jackson and Ryan Florence recently launched the v1 beta of the aforementioned Remix.

Through lots of live code, Ryan and Michael will tell you all about where Remix started, where it’s at now, and what this v1 Beta launch means for one of the most exciting web frameworks today.

If you’re into React, be sure to watch this — especially the part at the 31 minute mark … you’ll love the final code to solve that specific problem 😍

What’s especially to love is that Remix embraces the fundamentals of the web: fetch API, Request, Response, URLSearchParams, etc.

DiggyDB – Amazon Route53 as a blazingly fast and reliable database

Building further upon a “wild story” by Corey Quinn, Nicholas Martin describes how to (ab)use DNS TXT records by storing data in them, as if it were a database:

When you think about it, DNS configuration is actually a very rudimentary NoSQL database. You can view and modify it at any time quite easily through your domain provider’s website, and you can view each “record” just like a row in a database table.

To easily do this, he created DiggyDB

DiggyDB goes one step further than simple a key/value TXT record by allowing you to use (or indeed abuse) DNS TXT records by storing JSON data, almost as though it was a MongoDB or AWS DynamoDB!

Apparently, You Can Use Route53 as a Blazingly Fast Database →
DiggyDB – Amazon Route53 as a blazingly fast and reliable database →

💵 This linked article is stuck behind Medium's metered paywall, which may prevent you from reading it. Open the link in an incognito window to bypass Medium's ridiculous reading limit.

Performance-Testing the F1 websites

Jake Archibald has published a nice series in which he has been been performance-testing all F1 sites. Not only does he dig into waterfall charts, he also points out a few simple things that could be applied in order to improve overall loading performance.

As a bonus he also tested the Google I/O site, which uses an SPA approach. After 9 seconds of showing nothing, eventually a spinner is shown. At the 26 second mark (!) all data was prepared and done, and the page got rendered. As Jake puts it:

Imagine you went to a restaurant, took a seat, and 20 minutes later you still haven’t been given a menu. You ask where it is, and you’re told “oh, we’re currently cooking you everything you might possibly ask for. Then we’ll give you the menu, you’ll pick something, and we’ll be able to give you it instantly, because it’ll all be ready”. This sounds like a silly way to do things, but it’s the strategy the I/O site is using.

I really recommend you to read all posts thoroughly, as there’s a ton to learn from all this!

Who has the fastest F1 website in 2021? Part 1 →
Performance-testing the Google I/O site →

Smooth Scrolling Sticky ScrollSpy Navigation, with CSS fixed backgrounds

Davor Suljic created a fork of my Smooth Scrolling Sticky ScrollSpy Navigation that — instead of using IntersectionObserver — uses some background magic to highlight the active navigation items. The result is a “Pure CSS” implementation:

~

If you turn on an outline on one of the content sections it becomes clear how it exactly works:

  • The content sections also appear underneath the navigation
  • The content sections have background set, which has the exact same dimensions as their linked navigation item.
  • The backgrounds are positioned visually underneath their linked navigation item using background-position: fixed;

It’s a delicate combination, but I’m pretty excited that this actually works 🙂

Do note though:

  • You’ll need to add an extra wrapper whose width is limited around the section’s content, to prevent the content from appearing underneath the navigation.
  • Active state is a bit tricky:

    • Items high up the navigation list — such as Authentication — will become active pretty late, whereas items lower in the navigation bar — such as Expanders — will get their active state applied quite early. This is because the active state of nav items “starts” when the top of its linked container intersects with the nav item itself.
    • For small content-sections — such as Links – the nav item will become inactive too early, even before its linked section has left the viewport (and even when it still entirely in view). This is because the content itself is not that big and the nav item is pretty low in the navigation list.
  • You’re limited to background effects only. No making the nav items bold/italic, or changing their color.

Optimizing web content for Reader Modes and Reading Apps

Sara Soueidan, thinking about the different ways we consume web content:

The more I consume content in reading apps, the more I am reminded of the importance and the power of progressive enhancement as a strategy to create resilient and malleable experiences that work for everyone, regardless of how they choose to consume our content. The more we think about the Web in layers, the more robust experiences we can design.

The perfect example which Sara covers are the beautiful content dividers on her blog. They’re simply <hr /> elements, spiced up with CSS.

To hide content which not essential to the article in Reader Mode, Sara — again — turns to HTML by tapping into the hidden attribute.

Ah, Progressive Enhancement at its finest 🤩

Tips for optimizing content for Reader modes and reading apps →

Lazy loading JavaScript using IntersectionObserver

Jonathan Neal dissects the Islands Architecture approach behind Astro.

During the presentation, Fred demonstrates dynamically loading JS using “Islands Architecture”,a strategy where small HTML placeholders are progressively upgraded with dynamic or interactive content as-needed.

The demonstration involves waiting on the viewport visibility of a div placeholder before loading some JS.

Using an IIFE an IntersectionObserver is attached to keep an eye on a preceding a DOM Node. Once in view it’ll disconnect the IntersectionObserver and run whatever JS you want it to run (such as loading and rendering a React App).

Lazy loading JS by visibility →

CSS Full-Bleed Scroll-Snapping Carousel with Centered Content and Visible Overflow

For a project I’m working at, we’re building in some carousels (aka content sliders). While building a scroll-snapping carousel in itself is no rocket science nowadays, there was an extra variation that made my eyes sparkle: a full-bleed carousel that spans the entire page, with its focussed slide anchored to the center column of the page, and with the other slides “overflowing” outside of that column.

~

To jump right in, let’s take a look at the final result:

The first carousel shown is a regular/typical one: all slide-wrappers (.slidewrapper) are as big as the carousel (.slider) itself. They slide-wrappers are laid out on one row using CSS Flexbox. Because they have the same size, the carousel will only show one slide after having scroll-snapped.

The second carousel is the variation I mentioned in the intro: it also visually aligns the focussed slide with the center column — just like the first carousel — but the carousel itself does span the entire width of the page. This leaves the non-centered slides of the carousel also visible, making it look like they’re overflowing outside of the center column.

~

The code for this 2nd type of carousel uses the same markup and CSS as the 1st one, but with some CSS additions. As it’s not as easy as simply adding overflow: visible; to the .slider — as that would remove the scroll container — I adjusted the CSS as follows:

  1. The carousel-wrapper (.slider) spans the entire width of the page by means of the .full-bleed utility class.

    .full-bleed {
      width: 100vw;
      margin-left: 50%;
      transform: translateX(-50%);
    }
  2. There’s a gap between each .slidewrapper. This is done using margin-right instead of gap, as older browsers don’t support the property in combination with Flexbox.

    .slider.full-bleed .slidewrapper {	
      margin-right: var(--slider-fullbleed-gap);
    }

And now, the key part:

  1. The first .slidewrapper is given a padding on its left edge so that it appears centered on load. The last .slidewrapper is given a padding on its right edge so that it appears centered watching the last item.

    .slider.full-bleed .slidewrapper:first-child {
      margin-left: 0;
      padding-left: calc(50vw - (var(--slider-size) / 2));
    }
    
    .slider.full-bleed .slidewrapper:last-child {
      margin-right: 0;
      padding-right: calc(50vw - (var(--slider-size) / 2));
    }

    To make this work, the .slidewrapper elements need box-sizing: content-box; to be applied.

💡 An alternative approach would be to add this padding to the .slider itself. For that to work though — as otherwise the padding on the right will bleed out — you’ll need to lay you the children differently, using a combination of white-space: nowrap; (on .slider) and display: inline-block; (on .slidewrapper). I took this approach in my Pure CSS Cover Flow with Scroll-Timeline demo.

~

To grasp this padding-trick better and to see what’s going on, I’ve added a “Show Debug Outlines” option in the CodePen embed above. Take a close look at the green boxes that wrap the first and last slide contents.

🗺 Legend:
  • Slider Wrapper / Carousel Container = .slider = hotpink
  • Slide Wrapper = .slidewrapper = lime
  • Slide Contents .slide = grey

I like the fact that I was able to re-use the same markup for both variations, with their only difference being the .full-bleed class. Nice and DRY 🙂

~

🔥 Like what you see? Want to stay in the loop? Here's how:

Scroll-Linked Animations with CSS Scroll-Timeline (CSS Café)

Yesterday I was invited to speak at CSS Café, with a talk covering Scroll-Linked Animations with CSS @scroll-timeline. The meetup was organised using Zoom, and I think about 50-ish people attended (must say I wasn’t keeping track of that whilst speaking).

~

# Slides

You can find the slides embedded below:

~

# Source Materials & Demos

Source materials for the slides are my two posts on Scroll-Linked Animations:

  1. Part 1: Intro + Basic Scroll-Linked Animations
  2. Part 2: Scroll-Linked Animations with Element-Based Offsets

All shown demos and visualizations can be found on CodePen, and are gathered in these collections:

  1. Scroll-Linked Animation Demos: Visualizations
  2. Scroll-Linked Animation Demos: Part 1
  3. Scroll-Linked Animation Demos: Part 2

~

# Video

The whole talk was recorded too, and is embedded below. Unfortunately my camera feed wasn’t recorded along with that, so there’s some small loss of information as you can’t see my hands move as I explain some things (such as rotations).

~

# In-Closing

Thanks to organisers Schepp and Nils for having me, and thanks to the attendees for watching me speak. Based on the initial feedback, it seems many of you liked it 🙂

Apart from getting a positive vibe from presenting itself, it was also great to finally meet some people who I’ve been following on Twitter for quite a while now.

💁‍♂️ If you are a conference or meetup organiser, don’t hesitate to contact me to come speak at your event.

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.