And at that point, generally the programmer will start to hold their head in their hands and realise what they've got themselves into...

A wonderful recap of why you should just never try to support timezones in any program ever. And that's before you even get into calendar fallacies 😭

(Also, I love that my birthday used to be the British New Year in the middle ages 👍)

A fun list of the all the irritating edge cases that can crop up once you start dealing with dates and timezones. I'm a particular fan of the more obscure information on the Hebrew Calendar, with leap months, months that change length depending on how cloudy it is (moon visibility), and one month that can be shorter than a standard week. Talk about a headache 😂

The <datalist> element is super useful for autocomplete-like functionality, but there's no native way to automatically submit a form when an option is selected. Jeremy has come up with a neat logic flow that can enhance the element to do just that:

1. Store the input element's character count and keep it updated;
2. Each time an update occurs, compare the new count to the previous value;
3. If the new count is greater than the previous one by > 1 it means the user has either pasted in additional characters or has selected something from the datalist, so compare the string to the datalist options;
4. If there is a match, submit the form.

There are some issues. Jeremy points out that a selection that is only one character different won't trigger the autosubmit, which seems fair. I can also see potential issues with substring matching that could occur in certain situations. But as he says, it's a great enhancement to native functionality that provides plenty of fallbacks if needed.

He also provides a rough outline of his code, plus there's a Gist if useful:

document.querySelectorAll('input[list]').forEach( function (formfield) {
  var datalist = document.getElementById(formfield.getAttribute('list'));
  var lastlength = formfield.value.length;
  var checkInputValue = function (inputValue) {
    if (inputValue.length - lastlength > 1) {
      datalist.querySelectorAll('option').forEach( function (item) {
        if (item.value === inputValue) {
          formfield.form.submit();
        }
      });
    }
    lastlength = inputValue.length;
  };
  formfield.addEventListener('input', function () {
    checkInputValue(this.value);
  }, false);
});

Parents can do their children a favor if, from an early age, kids hear them say “famous college” instead of “good college.”

Because there’s very little data that shows that colleges with big football programs or lots of Nobel prize winners are actually good at doing what a college should do for an undergraduate.

I had no idea that the music lyrics website, Genius, also operated a tool that allows you to comment/annotate on any website, but apparently it does and apparently it's not even that new. It also turns out that some people have used that tool to harass and target others. The lack of a report feature is certainly problematic. Beyond that, I'm not sure what side of the fence I fall on here. Do I like the idea that people may be having secret conversations "on" my website or blog posts? Not particularly, but I also don't see the difference between what an annotation tool like Genius is doing versus reposts to sites like Twitter or Reddit. I also agree that the web could benefit from a "fact-checking" layer, something much like how Genius lyrics work with expanded context, historical information, explanations etc. That element I think is great and only wish it wasn't tied behind a login/restricted service. Though on that last note, apparently a web annotation standard is in the works.

Don’t color in the dark with a yellow crayon and call it criticism.

The law is what people who don’t know how to behave themselves turn to in disputes. Grown-ups find ways to get along.

A wonderfully illustrated and deeply informative article on responsive images on the web. 👏 Also, Eric's worries about "none of this being implemented in any browser yet" are no longer relevant – hooray for living in the future!

The gist is that media queries are terrible for picking images to display. Part of the reason is that image width on the page is only determined after CSS, so you have to do a fair bit of calculating to pseudo-predict what you need in time for a media query to work. And even if you work out all those lengthy calculations, the resultant <picture> element won't be flexible or easily extensible. Any minor change = total recalculation. Headache!

The solution is to combine srcset with sizes. The root of the problem above is that the developer and the browser implicitly know exactly the opposite bits of the equation to one another. The browser knows the viewport width; the developer doesn't. The developer knows the available image widths, the browser doesn't. Media queries seek to solve this by feeding the browser rules to apply to viewport widths, which is messy. Instead, srcset supplies the browser with the stuff the developer knows and lets it to do the rest. Eric sums this up really neatly with this table (lifted verbatim):

Here's the final example code (which I believe is still pretty accurate):

<img src="small.jpg"
     srcset="large.jpg 1024w,
             medium.jpg 640w,
             small.jpg 320w"
     sizes="(min-width: 36em) 33.3vw,
            100vw"
     alt="A rad wolf" 
/>

Also:

And again let me emphasize that while you can attach 1x/2x resolution descriptors to sources in srcset instead of w descriptors, 1x/2x & w do not mix. Don’t use both in the same srcset. Really.

To explain that sizes syntax:

sizes="[media query] [length], [media query] [length] <em>... etc</em>"

So yes, still technically using media queries, however now to tell the browser about the breakpoints it should expect rather than trying to work around them once they've happened. And yes, you can use calc and any unit combinations in there too.

A great overview of techniques to help improve text legibility, working with the browser rather than against it to be as inclusive as possible:

• Use rem and em units for margins and white-space around text so that it "preserves the vertical rhythm" if a user changes text size;
• The new (and not yet fully supported) font-size-adjust property is excellent for both preserving optical design and preventing webfont loading "flashes" by ensuring fallback fonts use the same optical height (this calculator can be used to quickly determine the ideal ratio for a system font):

@supports (font-size-adjust: 1;) {
    article {
        font-size-adjust: 0.5;
    }
}

• Set an optimal line-height by using x-height (height of the x character); the browser default standard is 1.2 but that's optimised for Times New Roman (TIL 🤯). Instead a combination of calc and the ex unit can be beneficial:

p {
    line-height: calc(1ex / 0.32);
}

In the right reading contexts, this rule sets an optimal line height for both serif and sans-serif fonts, even when typographical tools are not available or when a user has set a font that overwrites the one chosen by the designer.

• The calc value can then be combined with a scale to determine type hierarchy e.g. h1 could be calc(1ex / 0.42) and so on;
• Allowing users to dynamically control properties like letter-spacing, word-spacing, font-size etc. with sliders or other input options can be beneficial, particularly for people with difficulties reading text (dyslexia, vision impairment etc.);
• Optimal reading flow is achieved by ensuring travel for the eye between the end and start of lines isn't too extreme. Roughly 60-70 characters tends to be the sweet spot, so setting a width using the ch unit is ideal:

p {
    width: 60ch;
    max-width: 100%;
}

I think it's cool to see GitHub embracing calls to move away from "master branch" terminology and doing so in a way which provides further flexibility and power to its users. That's a win-win no matter how you feel about the surrounding debate. As of October 1st, all new depositories will default to use main unless otherwise specified, but you can define your own default however you please. For me, that means I've switched to use trunk moving forward by changing the settings in my repo settings page. There are options for enterprise and organisation owners too 👍

I didn't know that the <a> element had a download attribute, nor that it could rename the file on download for you e.g:

<a href="/files/ugly-file-name.xyz" download="nice-file-name.xyz">download</a>

On top of which, I didn't know that redirects using Netlify's _redirects file (which I do know about 😀) would allow for same-domain downloads (which the download attribute requires):

/download/*  https://clearleft-audio.s3.amazonaws.com/podcast/:splat  200

Basically, this whole article is a TIL.

SVG OMG is a brilliant (and free) web tool for sanitising, standardising, and minifying SVG assets. It's brilliant and has saved me a few times already.

There are two browser engines in the world. Dave considers what might be lost if that were to become one. He argues that browser diversity forces the standards process to be slow – and therefore deliberate and considered – and non-corporate. A single browser means whoever controls it has an outsized influence on how the web works.

There’s a lot of value in slow thinking. You use the non-lizard side of your brain. You make more deliberate decisions. You prioritize design over instant gratification. You can “check” your gut instincts and validate your hypothesis before incurring mountains of technical debt.

To make good platform features requires consensus, not competition, and the web’s potential is born out of cooperation, not a single corporation.

If the Web is governed by a single corporation, it will start looking like that corporation’s vision of the Web, ultimately limiting its own potential. Trading short term gain on new shiny features for long term

If we do see a major reduction in browser diversity, I think we lose the intentional slowness and the cooperation mechanisms we have in place. Who knows what will happen, but my hope is that just like iron can sharpen iron, maybe chromium can sharpen chromium.

Another great overview of how to use the `react-hooks` extension for the Testing Library suite, with some more complex examples than many other tutorials.