Snippets

It hurts me when I hear them say things like “you don’t need jQuery”. They don’t remember how dark it was before your light. We needed you then and we still need you now. I like the way you do things and although the years have passed, for certain tasks, you still do what you do better than anyone else could. I trust you. I know you and you know me. There will always be other ways we could do things, but I know I can rely on you and you’re always there when I need you to be.

It turns out that there’s an industry out there making money by algorithmically mashing up kids videos in ways to manipulate search rankings, without much apparent care about how their content could potentially traumatize some children. This is well worth a read, if only as another piece of evidence that algorithms often do not have human ethics baked in and the unintended effects this can have.

I’ve just converted my Sass code to use this, and I can safely say it’s pretty excellent.

include-media is a Sass library for writing CSS media queries in an easy and maintainable way, using a natural and simplistic syntax.

[…]

Why another library?

I spent quite some time experimenting with different libraries and mixins available out there, but eventually all of them failed to do everything I needed in an elegant way. Some of them wouldn’t let me mix set breakpoints with case-specific values, others wouldn’t properly handle the CSS OR operator and most of them had a syntax that I found complicated and unnatural.

include-media was the result of that experience and it includes all the features I wish I had found before, whilst maintaining a simplistic and natural syntax.

I wrote an article on CSS-Tricks about this experience, where I explain in detail the problems I found with each of the solutions I experimented with. I also wrote on David Walsh’s blog about the implementation details of include-media.

Example usage:

Want to know which ECMAScript features are supported by which transpilers, browsers, and other environments? This seems like an excellent resource for that.

This seems like a useful resource: a list of test results for various screen readers and browser combinations, in what they support and how they behave when encountering certain elements, attributes, etc.

[S]upport aside, it’s still not a particularly good choice as a consistent means to convey accessible information. Because while the title does provide an accessible name to elements in the absence of other sources, it is considered a fallback. Outside of some notable exceptions (more on this later), other mechanisms will always be preferred.

[…]

While the title attribute can be used on any HTML element, it’s essentially wasted on most inline, text level elements. As these elements aren’t typically included in the accessibility tree, there’s no reason for a screen reader to look for a title on these elements to announce.

Block-level wrapping elements can get some usage out of the title attribute. JAWS, NVDA and VoiceOver will all announce a title on elements like landmarks (header, footer, main, etc.) but support may vary on other elements depending on your browser pairing. For example, JAWS will not announce a title on a div without additional role updates.

Other wrapping elements, like lists and paragraphs, are announced in JAWS and VoiceOver, but NVDA ignores the attribute on these elements. But honestly, using title tooltips on these elements is highly suspect. Why would you want to have a tooltip constantly appearing over a large chunk of content? Unless you are purposefully trying to hide content, which isn’t helpful, there’s little need for using the title in this manner.

Images, form fields, and anchor links are the elements one is most likely to associate with the title attribute. In regards to screen readers, the title attribute essentially gets a “B” grade when reviewing publicly available screen reader support charts from powermapper.com.

titles are meant to serve as descriptive text. And largely only in situations where there is no accessible name for an image, form field, or anchor element, the title will be promoted to the accessible name.

Here’s a thing I didn’t know you could do with var(): like font stacks, you can specify a fallback value if the specified custom property isn’t defined, like so:

Mind you, this only applies to browsers that understand custom properties. To provide a fallback for browsers that don’t, use the tried and tested method of defining the fallback first and then the newer property declaration:

Want to see a really interesting use of media queries? Open Lynn Fisher’s site in a desktop browser and resize the window, or watch this (crappy and choppy) video I took of myself doing that: