These snippets are my attempt to save and organize various bits of code, best practices, and resources relating to web development and design. They also function as a to do list of sorts, for things I want to implement in my own code, but haven't yet. The concept is inspired by Jeremy Keith's links and CSS-Tricks, among other things. Enjoy.

Excluding Microsoft Edge's old CSS Grid implementation with feature queries

The challenge is Microsoft Edge, the only modern browser that, as of this writing, still uses the old grid specification. It returns true for @supports (display: grid) {}, even though its grid support is spotty and non-standard. Most relevant for our example is the lack of support for the grid-template-areas and grid-area properties and for the minmax() function. As a result, a feature query targeting display: grid would not exclude Microsoft Edge, and users of this browser would be served a broken layout. To resolve this issue and serve up grid layouts to Microsoft Edge only when the browser gets full support for the specification, target one of the unsupported features instead:


@supports (grid-area: auto) {}


An event for CSS position: sticky

Here's a secret: You may not need scroll events in your next app. Using an IntersectionObserver, I show how you can fire a custom event when position:sticky elements become fixed or when they stop sticking. All without the use of scroll listeners.


One of the practical limitations of using CSS sticky position is that it doesn't provide a platform signal to know when the property is active. In other words, there's no event to know when an element becomes sticky or when it stops being sticky.


Inclusive Tooltips & Toggletips

Most of the time, tooltips shouldn't be needed if you provide clear textual labeling and familiar iconography. Most of the time toggletips are a complex way of providing information that could just be part of the document's prose content. But I see each of these components all the time in auditing websites, so I wanted to provide some guidance on how to make the most of them.


  • If you have space, don't use tooltips or toggletips. Just provide clear labels and sufficient body text.
  • If it's a tooltip you are looking to use, decide whether the tip's content should be provided as the label or description and choose ARIA properties accordingly.
  • Don't rely on title attributes. They are not keyboard accessible and are not supported in many screen reader setups.
  • Don't describe toggletips with aria-describedby. It makes the subject button non-functional to screen reader users.
  • Don't put interactive content such as close and confirm buttons or links in tooltips or toggletips. This is the job of more complex menu and dialog components.


Developer-facing implementation errors

This is a great way to guide other developers who may use your code or components to use the correct elements for accessibility and other reasons:

In our script, we can detect the element nodeName and return an error message if it is not BUTTON. We use return to stop the remainder of the IIFE (Immediately Invoked Function Expression) from executing.


if (toggletip.nodeName !== 'BUTTON') {  
  console.error('Toggletip buttons need to be <button> elements.')
A screenshot of a browser's developer console with the error message 'Toggletip buttons need to be button elements.' shown.

CSS tests and error messages

In Inclusive Design Patterns I write about creating deliberate visual regressions to highlight code errors, and providing error messages in the developer tools CSS inspector.

The error we caught with JavaScript earlier can be caught using the CSS selector [data-tooltip]:not(button). We can highlight the erroneous element with a red outline, and provide an error message using the made-up ERROR property:


[data-tooltip]:not(button) {
  outline: red solid 0.5em;
  ERROR: Toggletip buttons need to be <button> elements.

Despite being an invalid property, the ERROR will appear in dev tools when the element is inspected.


Windows High Contrast Mode

Windows users are offered a number of high contrast themes at the operating system level — some light-on-dark like our inverted theme. In addition to supplying our theme switcher feature, it's important to make sure WHCM is supported as well as possible. Here are some tips:

  • Do not use background images as content. Not only will this invert the images in our inverted dark theme, but they'll be eliminated entirely in most Windows high contrast themes. Provide salient, non-decorative images in <img/> tags with descriptive alt text values
  • For inline SVG icons, use the currentColor value for fill and stroke. This way, the icon color will change along with the surrounding text color when the high contrast theme is activated.
  • If you need to detect WHCM to make special amendments, you can use the following media query:


@media (-ms-high-contrast: active) { 
  /* WHCM-specific code here */


Light/Dark Theme Switcher using CSS Invert Filter

Here's a really straightforward dark theme switcher for light designs. It uses the CSS invert() filter and minimal JavaScript to switch it on and off.

Screenshots of The Boston Globe and The Independent with the CSS invert filter applied.
The Boston Globe and The Independent with the CSS invert filter applied.


:root { 
   background-color: #fefefe;
   filter: invert(100%);
* { 
   background-color: inherit;
img:not([src*=".svg"]), video {  
   filter: invert(100%);


Breaking the Grid

Dave Rupert has encountered some confusing not-actually-bugs with grid item widths in CSS Grid, and provided this as a fix:


 _______  ___   _______    _______  ______    ___   ______  
|       ||   | |       |  |       ||    _ |  |   | |      | 
|    ___||   | |_     _|  |    ___||   | ||  |   | |  _    |
|   |___ |   |   |   |    |   | __ |   |_||_ |   | | | |   |
|    ___||   |   |   |    |   ||  ||    __  ||   | | |_|   |
|   |    |   |   |   |    |   |_| ||   |  | ||   | |       |
|___|    |___|   |___|    |_______||___|  |_||___| |______| 
by Dave Rupert
Read More:
 * Remove `min-width: auto` from Grid Items
 * Fixes overflow-x items.
.fit-grid > * { min-width: 0; }
/* Apply max-width to Replaced Elements and Form controls */
.fit-grid img,
.fit-grid video,
.fit-grid audio,
.fit-grid canvas,
.fit-grid input,
.fit-grid select,
.fit-grid button,
.fit-grid progress { max-width: 100%; }
/* Make file and submit inputs text-wrap */
.fit-grid input[type="file"],
.fit-grid input[type="submit"] { white-space: pre-wrap; }
/* Fix Progress and Range Inputs */
.fit-grid progress,
.fit-grid input[type="range"] { width: 100%; }
/* Fix Number Inputs in Firefox */
@supports (--moz-appearance: none) {
  .fit-grid input[type="number"] { width: 100%; }


Is it really safe to start using CSS Grid Layout?

The really short version? Absolutely. Slightly longer version:

Grid is new! Surely it has terrible browser support?

CSS Grid Layout shipped into Chrome, Firefox, Opera and Safari in March of this year. Microsoft Edge currently have an updated Version of Grid available behind a flag in Preview builds. At the time of writing, Can I Use indicates a global availability of CSS Grid Layout of 65.64%, rising to 70.75% if you include the prefixed version in IE10, 11 and current Edge. This is a rate of adoption we’ve never seen before for such a huge feature. It isn’t surprising that people don’t realise how many visitors will have support.


And non-supporting browsers?

CSS has the solution for you. To start with, defined in the Grid and Flexbox specifications are exactly how those specifications overwrite older layout methods.

Therefore if you want to use floats, inline-block, multiple-column layout, flexbox or even display: table as a fallback for your grid layout then the spec has you covered. You can overwrite those methods in a safe and predictable way. I made a cheatsheet explaining the fallbacks. I also cover several of these in my talk which was recorded at Render Conference earlier this year.

CSS also has Feature Queries. These have really great browser support, and the nice thing about Feature Queries is that you don’t need to concern yourself with the browsers that don’t support feature queries. There is no browser supporting Grid Layout and not supporting Feature Queries.


Generally you will then have a few things in the fallback CSS that will “leak through” to the grid layout. This is often widths on items as we need to assign widths to items in legacy layout to fake something that looks like it is using a grid. Therefore we use a simple feature query, checking for support of Grid Layout, and there we perhaps set widths back to auto.