Published
See Dave Rupert’s post on scroll shadows with animation-timeline. Browser support isn’t quite there yet so it’s more of a progressive enhancement, but this is a great use case example.
He wrote that off the back of Bramus’s scroll-driven animation exploration, and wow. So many of those behaviors would have been useful on past projects…
Published
I’ve been using a fluid type and spacing system on the most recent builds I’ve completed. Here’s why I use it, and how I approach it. I mainly use SCSS (a Sass syntax), but it’s also very do-able with plain CSS.
The example above demonstrates the result on gortscott.com, resizing the window from about 2300px down to about 640px and back again. The type and spacing across the page begins scaling down when the window is 2095px wide and stops shrinking at 1047px wide. At that point the text begins to reflow as the CSS Grid layout continues to shrink. Eventually at 703px wide the layout shifts, and again at 543px wide.
Published
I’m working on a site with a complex entanglement of blend modes, SVG backgrounds, gradient backgrounds, positioning, and transitions. I’ve run in to a bunch of issues with mix-blend-mode not working as expected, and it almost always has to do with an inappropriate stacking context.
For posterity, this StackOverflow answer is a really good run-down of CSS combos that create new stacking contexts.
Now to see what I can do about browsers rendering color profiles slightly differently… 💀
Edit: UGHHHHHH it’s different in different browsers. Check out this CodePen in Chrome and Firefox vs Safari. This is why we can’t have nice things.
Edit 2: See the answer to the cross-browser problem from the previous CodePen, via Gregory Cadars (view thread). So Safari is actually behaving correctly, but it’s still a stacking context issue.
To recap: I’m trying to display a “fixed” gradient background with content that scrolls over the top of it. Within this content, only the images have mix-blend-mode: overlay. In the original CodePen, I’m achieving this via a fixed position, 100% width + 100% height element with a linear gradient. This is within the same wrapper as the content.
My example is working in Chrome and Firefox. In Safari, it is effectively as if the blend mode hasn’t been applied. Though I’m not sure why the difference between browsers, it does make sense that a fixed position element would still create a new stacking context regardless of its parent.
In Gregory’s example, he’s removed the fixed position element with the gradient and instead applied the gradient background to the wrapper, as well as background-attachment: fixed via the background shorthand. This achieves the exact same effect, without stacking context issues.
The only thing that gives me pause is performance… I remember running in to some issues when I considered using background-attachment: fixed for Elizabeth Peyton’s Eternal Return. I can’t remember what it was exactly but it had to do with repainting on every scroll event (so, a lot!). I think that this article may give some context, but I’ll have to dig in to it further.
Related: See this CSS gradients resampling tool by Rutherford Craze for smoother gradients, shared by Gregory in the thread.
Twitter is a crappy place a lot of the time, but I love it for things like this.
Published
I’m currently working on a site that uses CSS Scroll Snap to frame some of the content nicely as you scroll through. In Chrome though, I was getting weird overflow issues at the top and bottom of the screen. If I scrolled to the bottom and then kept attempting to scroll down, it would gradually add more and more length to the page. Same with scrolling back up.
Adding overscroll-behavior-y: none; to the body element sorted it out. Read more about overscroll-behavior on MDN.
I originally tried to add this property to the html element since that’s the element with scroll-snap-type: y mandatory;. This didn’t work though, it seems that overscroll-behavior has to be on body.
Published
The Open-weather website is online. A bit about Open-weather:
Open-weather is a project by Sophie Dyer and Sasha Engelmann probing the noisy relationships between bodies, atmospheres and weather systems through experiments in amateur radio, open data and feminist tactics of sensing and séance.
The site is pretty straightforward, a static hub for a bunch of resources hosted in various places including their PublicLab wiki and archive of amateur radio-generated weather data. The homepage is currently a large scrollable nowcast produced in collaboration by people across the globe. We decided to embed the Google Sheet archive directly in the site for now, though that may change in the future. We may do the same for pages such as methodology, to come later on. We’ll see!
The site is hosted on Netlify and the code is in a GitLab repo. Pls excuse sub-par commit messages and the very minimal README.
Sasha and Sophie are giving a talk at 14:30 UTC-4 Toronto as part of Our Networks distributed festival. Definitely worth grabbing a ticket, it’s super well priced considering how much Our Networks is putting on and absolutely worth supporting that org.
Published
I’ve been gradually updating the WordPress theme that powers this site with the help of a very talented designer and thinker, my friend Bec Worth.
It began with conversations about overhauling her own site. She had a few disparate Tumblrs with a ton (and I really do mean a ton) of great references, photos, and more that had accumulated over the years. All of them had fallen in to disuse for one reason or another, but she still felt like some sort of outlet for collecting these sorts of snippets and longer-format writing would be really useful. She brought up the Commonplace book as a particular inspiration. I’d never come across it before but it really resonated.
We continued talking about her site, and I started to restructure my old color-heavy Notebook theme (view in Wayback Machine) to strip out the less necessary functionality, improve the accessibility, etc. I wanted to make it something that could be more widely useful to not just me and Bec, but others as well. The early version of this new theme used variable Work Sans (view in Wayback Machine)
She liked where it was going, so we got her set up on a WordPress instance and used the Tumblr importer to pull in all of that old content. Since then, we’ve been using her log and my site to test out ideas and continue pushing the idea of what a Commonplace Book could be on the web. For more along these lines, I recommend reading her post “What would a Commonplace Book feel like on the web?”
It’s far from finished. The type is nowhere near as tight as Bec’s designs, I need to spend a bit more time on that! Amongst other things, I need to clean up the table of posts, add a thumbnail view, and improve the gallery block styles. We’re also going to figure out a way of highlighting work and other projects, something that draws a bit more attention than normal posts.
And color! We’d like to make it possible for people to select preferred text colors, maybe on a post-by-post basis or per category. Color is tricky though, I’d like to preserve some baseline of legibility and I’m not sure how much I could do as the developer to enforce that. Also, how do we handle this if we introduce dark mode support? The HSL or LCH color spaces might be helpful.
I’m not planning to submit this to the WordPress theme directory. Right now, this means that installation and updates are pretty manual, the theme has to be uploaded via FTP before it can be installed. Because of that, I’ll eventually set up an update server so that anyone using the theme can perform one-click updates from the WordPress admin area. Note to self: see this article for more on how to do this.
Realistically, people using the theme might want to change up certain aspects of the theme to be more “them”. Instead of adding a ton of theme options like font pickers and that sort of thing, I’d like to encourage people to tinker with it themselves. This is going to require a bit of documentation to point people in the right direction. I’ll probably start with how someone with little-to-no CSS experience could go about changing the font (i.e. upload font files in the Media library then add the necessary CSS lines in the Customizer, or setting up a child theme).
Clearly, it’s a work in progress!
But anyone is welcome to give it a try for themselves. I recommend it if you’ve been looking for a place to keep important references or get thoughts out of your head. Head to the commonplace-wp-theme GitHub repository to download it and read a bit more.
If you do end up using it, we’d love to know.
Published
Jake Dow-Smith just announced Publish Something Online ↗, a resource geared towards students. It’s super worthwhile and a very fun browse. From the intro:
Building websites is often seen as an uncreative, mathematics-based task undertaken by coders. This library encourages you to learn how to design and build interactive experiences and to consider this a tool in your design toolkit. A person is only a
coderas much as you are an InDesign-er or Microsoft Word-er.This library will introduce you not just to code resources, but also to examples of alternative forms of screen-based interaction and the technologies they are based on.
Published
Note to self: position:fixed; is not respected if the fixed element is within a transformed element.
See a very old meyerweb.com article on the topic. Apparently this is expected behaviour, not a bug, hence why people are still encountering this funkiness nine years after Eric Meyer’s article. As he suggests, it’s a little counter-intuitive!
In my case, it related to a fixed element within a <div> that was being transitioned from off screen to on the screen. I was able to get around it by reversing the transform so that when the element needed to be fixed, I set the containing element to transform: none;. That wouldn’t work in every case though, so YMMV.
Published
Lea Verou just published a blog post about the LCH color space. This is super exciting, see her post for detail. Specifically, the improvement has to do with the perceptual uniformity and lightness being visually consistent no matter the hue.
The best way to get a feel for this is to experiment with her LCH color picker. Drag the hue value back and forth, and you’ll see that the tonality of the background remains consistent. It doesn’t suddenly feel a lot lighter in yellow than it does in blue. Do the same thing in an HSL color picker and you’ll feel the difference.
This would help a lot with the color on my site. I’ve never been 100% happy with how the color is handled because it is too hard to control the lightness and thus the legibility. See the List page for a clear example of this, posts in June and February are particularly hard to read. LCH would solve this!
Published
A short two-parter
I’m doing a few coding-for-designers workshops with the students in the MA Graphic Media Design programme at the LCC, the first one was this past Thursday.
We’re focusing on web stuff since that’s what they expressed the most interest in and it’s in my wheelhouse. We started with a broad and brief overview of code, about how we use human-readable programming languages to communicate with computers. But 99% of the time, when we say “human-readable” we really mean “English-based”. More on this later.
After my short intro, we put together a simple webpage with HTML and CSS. A few of the students ran in to a small-but-mighty bug that I’ve never encountered before.
We were working on a basic CSS rule set, something like:
body {
background-color: linear-gradient(blue, pink)；
}
And for one of the students, it just wasn’t working. I checked it a bunch of times, it was all typed perfectly. No missing spaces or characters, spelling was fine. VSCode indicated that the background-color declaration wasn’t finished, which seemed weird. I looked really closely at it and noticed that the semicolon seemed a little thinner than the others in the file.
Turns out that the student had typed a full-width semicolon (U+FF1B) instead of a semicolon (U+003B). The full-width semicolon is used in Chinese to “demarcate parallel structures in a paragraph”. Another student ran in to the same problem a few minutes later, using a full-width left curly bracket (U+FF5B) instead of a left curly bracket (U+007B).
I had asked them to type in a semicolon, to type in a curly bracket, and so they typed the characters the way they normally do in their native languages. Super understandable.
If you were just starting to learn what code is and how it works, I can’t imagine how hard it would be to debug this sort of language-based problem on your own.
Gretchen McCulloch wrote a very worthwhile Wired article titled “Coding Is for Everyone—as Long as You Speak English”. I feel like every programmer / dev should read it.
Programming doesn’t have to be English-centric. As McCulloch puts it:
The computer doesn’t care. The computer is already running an invisible program (a compiler) to translate your
IFor<body>into the 1s and 0s that it functions in, and it would function just as effectively if we used a potato emoji 🥔 to stand forIFand the obscure 15th century Cyrillic symbol multiocular O ꙮ to stand for<body>.
How would we go about implementing non-English HTML tags? W3C has an FAQ on the topic where they state that “HTML or XHTML tags are all pre-defined (in English) and must remain that way if they are to be correctly recognized by user agents (eg. browsers).”
Since browsers just implement the standards set by W3C (I’m pretty sure that’s right?), I’m guessing that W3C would have to approve it if we wanted native non-English HTML support. It seems like it would be a bit of a mountain to climb but if we take something like Wikipedia’s translation efforts as an example, surely there are tons of people out there that would help with translation?
Gonna keep an eye on this. Need to find a book or good article on the history of ALGOL.