A Contact page with a customized Letterbird form.


A Contact page with a customized Letterbird form.

Over the weekend I signed up for Letterbird, a free contact form by the folks at Good Enough. I began configuring the options and testing out the functionality and considering how I might want to use it.

Currently, the only way to contact me on one of my sites is via email through a mailto: link. I have a different email address for each one, though they all end up in my Fastmail Inbox. I set it up this to way to better understand where mail comes from. I am also providing a unique address for every blog post on weblog to tie a "reply by email" to a specific blog post. This is all well and good and has worked out just fine, save for the occasional spam, but has not been as bad as I envisioned in the beginning. I've started blocking domains that keep spamming me and that's knocking them out with bigger swings than when just blocking each one individually.

However, while pursuing slash page totality (a phrase I coined just now to define when you provide every single slash page listed on Slash Pages), I realized I need a Contact page. A contact page with my current method of contact, via email only, would be a pretty sad page. I can embed the Letterbird form as-is with a free account but it wouldn't look very slick without some custom CSS. I upgraded to Pro for $25/yr and added the embed code to the newly created Contact page.

Screenshot of a Letterbird contact form in a dark color theme with custom styling.
The Letterbird contact form page with my custom CSS in a dark theme.

The Letterbird settings get a little boost when upgrading to Pro: you can remove the Letterbird branding from the form, you can customize the form with CSS, you can customize the confirmation message, and possibly other things I'm not recalling right now. I chose to do all three of those things and the standalone page with your Letterbird form can also show an avatar or image at the top, a name of your choosing, and a short blurb or paragraph about yourself. Also worth mentioning is that you can customize the URL of the form from the generated string that it defaults to. I only tried one slug, my username, so I'm not sure of what happens when you try to use one that may already exist or be in use.

Screenshot of a Letterbird contact form in a light color theme with custom styling.
The Letterbird contact form page with my custom CSS in a light theme.

Embedding the form in another page is via a <script> tag which expects to output the embed in the same location in the document. You can alternatively pass an attribute to the <script> tag pointing to any valid CSS selector to instead have the embed output inside that target element. Additional attribute options allow you to: remove the header of the form, which contains the avatar/image, your name, and about blurb; and set a width other than the default width, any valid CSS width is accepted.

The Letterbird form has a nice default set of custom properties that you can hook into to override for you light and dark theme. My custom CSS is comprised mostly of redefining values for these custom properties, with a small handful of class targeting to add some styles not already applied. I increased the font size on the label elements and gave them a heavier weight to help legibility and I overrode the border radius on most elements to match my parent theme. Finally, on the standalone page I added the same avatar treatment as all my sites use with a small padding + border + a slightly transparent background color.

Screenshot from Safari of a Letterbird contact form in a dark color theme with custom styling embedded in a Contact page on weblog.
The Letterbird contact form embedded in the Contact page on weblog with my custom CSS in a dark theme, correctly displayed in Safari with a transparent canvas.

The HTML gets embedded in an <iframe> and a color-scheme meta tag is included defining light dark so the iframe passes through the the preferred scheme from the containing page. This means that on my weblog, when "auto" is set for the color scheme to use whatever the system is using, that is passed through to the iframe and also set on the form. The same goes for explicitly choosing the light or dark theme manually via weblog's theme controls.

Screenshot from Safari of a Letterbird contact form in a light color theme with custom styling embedded in a Contact page on weblog.
The Letterbird contact form embedded in the Contact page on weblog with my custom CSS in a light theme, correctly displayed in Safari with a transparent canvas.

This works flawlessly in Firefox. The embedded document adheres to the selected theme or system default of the parent page with the embed also using a color-scheme meta tag. The current W3C CSS Working Group Editor's Draft for CSS Color Adjustment Module Level 1: 2.2. Effects of the Used Color Scheme specifies that this is the expected behavior and that the canvas of the <iframe> should be transparent unless the selected color schemes are mismatched.

In order to preserve expected color contrasts, in the case of embedded documents typically rendered over a transparent canvas (such as provided via an HTML iframe element), if the used color scheme of the element and the used color scheme of the embedded document's root element do not match, then the UA must use an opaque canvas of the Canvas color appropriate to the embedded document's used color scheme instead of a transparent canvas.

Both Safari and Chrome get this wrong, but only in specific instances. I had a hard time even consistently finding a pattern for the issue in Safari. What I finally landed on was:

  • when the page loads for the first time, it defaults to the system option for the theme picker and matches the OS theme with no issue
  • when you then choose to use the light theme, both the parent page and the embed change to the proper theme without issue
  • if you then refresh the page, the parent theme is still selected as light but Safari has now applied an opaque canvas (black) to the <iframe>
  • now switching to the dark theme in the parent page with the theme picker will also show the opaque canvas in the <iframe>
  • another page refresh will fix the opaque canvas and reapply the transparent canvas
Screenshot from Safari of a Letterbird contact form in a light color theme with custom styling embedded in a Contact page on weblog showing an opaque canvas.
The Letterbird contact form embedded in the Contact page on weblog with my custom CSS in a light theme, wrongly displayed in Safari with an opaque canvas.

It is quite bizarre behavior. When I first started investigating this I was also encountering the opaque canvas while toggling open devtools, but this may have been due to a page refresh that occurs when they open. I'm not entirely sure at this point. Regardless, I can't rely on Safari (or Chrome) to apply the canvas correctly and therefore needed to alter how I was styling the form elements. Rather than the elements being uniquely dark or light as my Styleguide dictates, they all remain the same: a light background with dark text. This is also the treatment I applied to my search form, so it isn't entirely foreign to the site.

Now I'm in the position to decide whether I want to file a bug with either Safari or Chrome. I've never filed a bug with either of them before and I'm not entirely sure how I would define the issue since I am still slightly fuzzy on what Safari is trying to do, as it gets it right initially. I am also still not positive on the toggling of devtools being involved, so I would need to further test some scenarios. Either way, it is a bug, and if the draft becomes a recommendation these issues will need to be resolved by both Safari and Chrome eventually. It might be kind of cool or interesting to get something filed now, assuming someone hasn't already done so.

Update: This issue is now resolved in both Safari and Chrome from what I can tell in testing. The change I made was to remove the containing component and apply the styling previously targeting it directly to the <iframe> along with background-color: transparent with !important. This forces the <iframe> to always have a transparent canvas regardless of color-scheme and I no longer get an opaque canvas in any of my tests toggling between color theme via the controls on weblog, though I now get it via devtools in Firefox for only the light theme. This is a bit of a hammer and works around the issue of what the browser thinks it needs to apply to the <iframe> canvas, but I'm satisfied for now.

Post info

Links in this post:

POSSE copies:

Share this post on social media.

Discuss on Mastodon


Apple Annie's Weblog

19 Jun 2024 at 01:08

Refresh complete

(222) All feeds

Last 24 hours
Download OPML
A Very Good Blog by Keenan
A Working Library
Alastair Johnston
Andy Sylvester's Web
Anna Havron
annie mueller
Annie Mueller
Apple Annie's Weblog
Artcasting test feed
Articles – Dan Q
Austin Kleon
Baty.net posts
Bix Dot Blog
Brandon's Journal
Chris Coyier
Chris Lovie-Tyler
Chris McLeod's blog
CJ Chilvers
CJ Eller
Colin Devroe
Colin Walker – Daily Feed
Content on Kwon.nyc
Dave's famous linkblog
Dino's Journal πŸ“–
E L S U A ~ A blog by Luis Suarez
Flashing Palely in the Margins
Floating Flinders
For You
Frank Meeuwsen
Hello! on Alan Ralph
Human Stuff from Lisa Olivera
Into the Book
Jake LaCaze
James Van Dyne
Jan-Lukas Else
Jim Nielsen's Blog
Jo's Blog
Kev Quirk
lili's musings
Live & Learn
Lucy Bellwood
Maggie Appleton
Manton Reece
Manu's Feed
Meadow 🌱
Minutes to Midnight RSS feed
Nicky's Blog
Notes – Dan Q
On my Om
One Man & His Blog
Own Your Web
Paul's Dev Notes
reverie v. reality
Robin Rendle
Robin Rendle
Sara Joy
Scripting News
Scripting News for email
Sentiers – Blog
Simon Collison | Articles & Stream
the dream machine
The Marginalian
Tracy Durnell
Winnie Lim
yours, tiramisu
Žan Černe's Blog

About Reader

Reader is a public/private RSS & Atom feed reader.

The page is publicly available but all admin and post actions are gated behind login checks. Anyone is welcome to come and have a look at what feeds are listed β€” the posts visible will be everything within the last week and be unaffected by my read/unread status.

Reader currently updates every six hours.



Colin Walker Colin Walker colin@colinwalker.blog