On a related note, Yannick Clybouw recently hit a similar quirk where his deploy onto GAE would fail because of a commit hash that looked a wee bit too much like a number:
I've just hit a remarkable bug when deploying to Google App Engine. My version id was the short hash of my commit: "367e5893". Somewhere deep at Google, this was parsed as float 367·10⁵⁸⁹³ and made my deploy fail. 🤨#GoogleCloud#Serverless
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!
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!
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.
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.
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).
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:
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.
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.
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).
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).