Published
It’s been a little over four months since B arrived. These are some of my experiences or things I’ve learned so far, plucked at random.
I’d say that the books, conversations, and classes prepared me pretty decently in theory, but the physical and emotional reality is almost impossible to prepare for. Being a parent has been much more visceral than I expected.
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
Read “There’s More Than One Way to Share Your Design Work: Four fresh takes on the portfolio” on AIGA Eye On Design.
They spoke to Carly Ayres, Prem Krishnamurthy, David Reinfurt, and Gemma Copeland about their approaches to an online portfolio / website. Gemma spoke a bit about how we designed and built her site together, it was a lot of fun. See her site gemmacope.land, or take a look at the GitHub repo. BIG thanks to Howard Melnyczuk for fixing a bug I totally missed. 🤦🏻♀️ 🙏
Published
Our little one is here, and life will never be the same.
🌱
It has been a whirlwind month, really a whirlwind few months. I was trying to wrap everything up prior to maternity leave and just about got there, then was suddenly faced with a same-day induction following a routine prenatal appointment at 38w + 4d, three days before my leave was due to start. So close!
I’m not going to go in to detail about the birth in public here, it is too intimate of an event. I will say that besides the shock of the sudden induction and a few other blips, the birth itself went just about as close as I could hope to my “ideal” scenario. I’m so thankful for that. Remembering that the pain is temporary and intentional helped a lot, and Sam’s support was vital, as were our nurses Amy and Lukas and doula Taylor. “Ready, present, relaxed” was on repeat in my head.
The days following the birth involved ups and downs in terms of my health, including a readmission to hospital unfortunately, but have gone fairly smoothly otherwise. Not sleeping as well as we did previously, but that’s to be expected!
And most importantly, our little lad. He’s perfect, gorgeous, and so funny already. He won’t appear often in public photos on this site or elsewhere online, but like most parents, I’m happy to share copious pictures with friends and family via text.
The one-on-one conversations I’ve had with more experienced friends, family, collaborators, clients, and acquaintances about this stuff are some of the moments from my pregnancy that I hold most dear, small acts of selflessness and vulnerability on their part that made me feel so much more prepared for this process and what is to come. I’m thankful to have been able to ask so many people about so many things: what it’s like to be self employed with a young child, navigating how to divvy up responsibilities with your partner, the million different paths that feeding a baby can take, how your sense of identity shifts, what equipment is useful and what is pointless, and so, so many birth stories.
So thank you so much to those people that have reached out, and to those that have kindly opened up when I prodded a bit. It has meant everything.
Along those lines, an invitation: if you’re expecting or even just considering kids and want to talk about what it is like, please don’t hesitate to reach out to me.
Published
I’m working on an Eleventy site at the moment, the first Eleventy site I’ve done that’s been complex enough CSS-wise to warrant using Sass. I’ve turned to Phil Hawksworth’s Sass + Eleventy technique for the job. It’s a great, simple way of using Sass with Eleventy with a little bit of preprocessing courtesy of Gulp.
Hit a wall at one point though, it was smooth sailing and then my CSS updates just stopped working.
Turns out I had added /_includes/main.css (the compiled styles) to my .gitignore file since I prefer not to commit compiled files, but I forgot that Eleventy uses the .gitignore file + the .eleventyignore file to decide what not to compile. So Eleventy was just ignoring it. 🤦🏻♀️
I did this .gitignore change as an end-of-day commit, tidying things up before closing my laptop. When I picked the project back up days later, it took me longer than I’d like to admit to figure out what was going on!
To sort it, I just had to opt out of using .gitignore by adding eleventyConfig.setUseGitIgnore(false); to the .eleventy.js config file, and then adding the necessary files listed in .gitignore to .eleventyignore. Then I re-ran gulp watch & npx eleventy --serve, and all was well.
Separate but related to static site generators: Check out Astro. Would be curious to see a detailed comparison of Eleventy vs Astro since Eleventy is currently top-of-the-list for me in terms of static site generators.
Published
I missed these two articles by Tom MacWright from last year.
Second-guessing the modern web, 10 May 2020
If not SPAs, What?, 28 October 2020
In both, he outlines few upsides and downsides about the single page app (SPA) approach to websites and has a few points that I have really struggled to articulate in the past.
From “Second-guessing”:
There is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are trying to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.
I’ve dabbled with React and Vue in small side projects and experiments. But the point above is the big reason I’ve never taken the time to sit down and learn either of them properly. For almost every client site I’ve ever done, it just didn’t make sense to make it an SPA.
And I’m not 100% sure, but I think this might contribute to longevity. Some of my clients are still working with the same sites I built for them nearly 10 years ago, a few with just minor security-related updates in the meantime and no other maintenance strictly required. That’s not to say that those sites couldn’t use a “lick of paint” to bring them in to the 2020s; the point is that they work. And for organizations working on really tight budgets, or budgets that fluctuate wildly due to public funding, stability is really important. They can’t afford a developer on retainer to keep things running smoothly.
But of course the SPA vibe is pretty attractive, particularly for cultural orgs. MacWright has some decent alternatives suggested in “If not SPAs” including Turbolinks, Barba.js, and instant.page. Will also mention MoOx/pjax since I’ve used it before for page transitions with very good results, but probably won’t use it in the future as it hasn’t been updated in a while.
And again, there’s the rub. The more non-native scripts, plugins, etc I use in a project, the more likely that it’s going to be a major headache (and thus major time/money for the client) for me to change things down the line if or when that bit of tech is no longer supported or has changed significantly.
So it’s not even so much about being wary of React or Vue, it’s about not making assumptions, being cautious and cognizant of future needs or restrictions when proposing a tech stack. Any tech stack you choose will ultimately become a ball-and-chain, not just those based on JavaScript frameworks. It’s just that the ball can sometimes be heavier than it needed to be, and you can anticipate that with a little foresight.
Published
This Q&A is compiled from conversations I have had with many, many clients and collaborators who have had a hard time navigating things like the GDPR, privacy policies, cookie notices, consent messaging, and other related topics.
Here are all the questions covered below:
Published
This was originally written as a bit of a guide for my clients and collaborators, an aggregation of similar tips I have given to many of them individually in the past in so many shorter emails and conversations. Since it is relevant to most website owners though regardless of their relationship with me, I decided to share it more broadly here.
Websites require maintenance, even those with the smallest of footprints.
This is what I would consider “bare minimum” website-related maintenance tasks including checking your payment methods and contact details, reviewing your login and security practices, performing updates and taking backups, and checking your privacy policy.
If you do fall behind on maintenance (it happens to the best of us!) and something goes wrong, at the very bottom you’ll find some tips on what to do if your site goes down suddenly.
The vast majority of these tasks do not require a web developer or IT person, almost anyone can perform this maintenance so long as you have access to necessary logins, can follow instructions, and are willing to set aside the time.
I say “almost anyone” because some people are understandably uncomfortable with wading in to this stuff, they may get confused or a bit daunted by the user interfaces they have to use. In that case, just be sure that you are working with someone that can hold your hand through it or can simply do it for you. Also, not everyone has access to all of their service providers. If you’re in a different situation, for example if you retain a web developer, design studio, or IT person to continuously maintain your website, then these are worthy topics to discuss with them but ultimately they will probably need to complete these tasks for you.
Of course there are other maintenance tasks that are super worthwhile. For example it might be worth checking search performance or 404 pages with Google Search Console if search engine optimization (SEO) is important to you, or to check analytics if that’s relevant to your site. And it’s worth speaking to your web developer about front-end maintenance. CSS and JavaScript gets better all the time, as do browsers, so old front-end behavior can really date a site.
But that’s all just the cherry on top. If you complete the tasks below I’d say you’re pretty golden, probably a step ahead of 80% of the site owners I’ve come across.
Published
I woke up early this morning to get some work done before a call and suddenly my local dev environment stopped working without warning and with seemingly no reason. The root issue was that MySQL wouldn’t work, /usr/local/opt/openssl/lib/libssl.1.0.0.dylib was not loading.
TL;DR: This may have been related to some automatic cleanup on Homebrew’s part. But regardless, a simple restart sorted it. If this happens again and restarting doesn’t sort it, try uninstalling and reinstalling MySQL.
The rest of the detail is below for posterity if I run in to this in the future.
Published
There’s an ocean of difference between “could it exist?” and “should it exist?”.