Explore My Notes

Complex images can paint a thousand words | Paul Watson

What is the best way to provide descriptive text for images that are both complex and the main focus of a page? Paul has tried to tackle this on pages dedicated to their personal art, and found that the advice isn't necessarily that clear. The tl;dr would be: move the text onto the page itself and reference it from the image (using ARIA or alt attributes, or a combination).

I hadn't realised that the WAI has outlined seven image "types", nor that they have different suggested approaches based on the "type". I initially thought Paul's use of the "complex image" type felt wrong, but reading over the spec I agree; it's weird, but that's the best fit for these kinds of pages/content.

On disproving the weirdly common belief that you can't have more than 140 characters in alt text (this isn't Twitter!):

Myth busted: there is no character limit on “alt” text.

On concerns with overly long alternative text:

So you’re free to use as many characters in your
alt text as is necessary to describe an image, but it’s also worth remembering that someone using a screen reader apparently cannot skip listening to the alt text if it feels like it’s going on forever, so try not to be unnecessarily verbose.

On the official guidance from WAI (taken from the WAI tutorial on images):

In these cases, a two-part text alternative is required. The first part is the short description to identify the image and, where appropriate, indicate the location of the long description. The second part is the long description – a textual representation of the essential information conveyed by the image.

On how to deal with "Complex Images":

The general advice is to make long descriptions available to everyone to reach a wider audience with your content. For example, show the description as part of the main content.

Inclusive glasses frames | Reframd

I've always struggled to find glasses or sunglasses that fit my weird head, so I was intrigued by a company explicitly targeting body shapes that aren't well catered for. Unfortunately, the selection is pretty narrow and likely won't work with my level of prescription, but saving to check back in the future.

Bidirectional text in HTML | @samgai

Today's obscure HTML element: <bdi>. It stands for "bidirectional" and refers to text that can include both RTL and LTR languages (does not appear to care about other variations).

Looking on MDN, the exact order is quite complex, but thankfully the browser does most of the heavy lifting for you.

Usernames and other user-provided values should be directionally isolated from their surrounding inline text, if there is any.

In HTML, this can be done with the <bdi> element.

Not only does this stop people messing with text direction using directional overrides (sorry for ruining your jokes), it also makes sure that an English sentence still ends on the right even when starting with an Arabic name.

A global documentation platform | Andy Bell

Andy brings up a very valid and very scary point: what happens when Mozilla shuts down MDN? Why is one of the most important sources of web knowledge not under community stewardship? And what can we do about it?

These are all solid questions and worth thinking about. I'm not so sure that the funding model proposed here would work, but I think a hybrid approach – one with corporate subscriptions, Patreon style personal donations, and big ticket sponsorship – might. It'll just be about building the right team in the first place, and hitting that critical mass of funding to make them financially secure.

On Mozilla versus MDN:

I want to be absolutely clear that I wholeheartedly support MDN. I think it’s fantastic. I think it’s under the wrong stewardship though.
I think MDN core documentation content needs forking and an alternative platform needs to develop from that forked, attributed content that has a sustainable funding and leadership model. Mozilla ain’t providing that.

On the lacklustre demos (some seem actively problematic these days):

Often, on MDN, demos are too abstract from real world use cases and frankly uninspiring

On Mozilla's odd (and problematic) priorities:

Mozilla could invest in this work — y’know, improving the docs so they help as many people as possible — but they instead introduce an “AI” helper that lies to people. Unforgivable.
The point I’m making is we as a collective can do so much better and importantly, look after an extremely valuable resource better. Something that’s focused on what it is, rather than something that’s good, but frequently gets enshittified by terrible leadership decisions.

On Andy's proposed funding model:

In community organisations the onus is often on generous individuals and corporate sponsors. I think the onus should be on companies that rely on web documentation for profit.

On the problems of open source and why it isn't a good fit here:

Open source is unfortunately treated as free, including lots of free labour. It’s free at the point of use, but people’s time and wellbeing is often exploited to achieve that.

On why we need to act now, rather than later:

MDN isn’t safe in Mozilla’s hands and the thought of it disappearing is terrifying. We can organise though and get something positive going before we have to because MDN has been rug-pulled. Fix the roof when it’s sunny and all that.

The two Reacts | Dan Abramov

A very well written overview of when client-side functionality and server-side functionality make sense to use for a website.

Frustrating to read, though, because not only have people been saying this for years (and saying this to the author, in particular, for years, which is not acknowledged here at all), but they've also been solving this for years. There are many competing patterns out there, so I wouldn't call this a problem with a definitive answer. But positing the question and then effectively shrugging your shoulders and saying "but who could ever possibly dream of such a world" is a little trite when solutions do, in fact, exist.

Though is it trite, or is it simply worrying that someone who has supposedly been thinking around solutions to this problem themselves seems so unaware of the space they are considered a thought leader within..?

For example:

Is there some way we could split components between your computer and mine in a way that preserves what’s great about React? Could we combine and nest components from two different environments? How would that work?

Yes, Islands Architecture. Or Web Components. This is neither a "hard" problem (at a conceptual level) nor an unsolved one.

(Though perhaps the issue here is the "preserves what's great about React", because based on React's attempts to solve these issues, I'm not sure the React team and the general developer community agree on what that is.)

The good, the bad, the web components | Zach Leatherman

An excellent overview of the current state of web components, including suggestions on how they could be improved.

On the current popularity (and success) of web components:

In August 2023, Chrome Platform Status reports that 19.4% of page loads in Google Chrome were using a web component (via the CustomElementRegistryDefine key). For comparison <img loading>

On the simplest form of web component, a Custom Element (or HTML Web Component):

Custom Elements allow you to attach a JavaScript class to any custom element you define on your page, to add behaviors and JavaScript-generated content to any element instances on the page.

On the downside to Custom Elements (not very DRY):

Multiple instances of the same component need to repeat the same nested content and any changes to nested content need to be applied manually to all instances.

On the Shadow DOM, the next step up in terms of complexity:

Shadow DOM is the next level of our web components evolution. It solves the developer experience problem with repetition in authoring markup at the expense of clientside rendering 😭.

On how Declarative Shadow DOM is just several Custom Elements in a trench coat:

[Declarative Shadow DOM] solves the clientside rendering dependency for Shadow DOM but at the expense of repetition in authoring markup! The ol’ switcheroo (in some ways) feels like a de-evolution back to the approach we discussed in Custom Elements!

Quickly check Core Web Vitals | Page-Speed.dev

A quick way to check for PageSpeed metrics, Lighthouse scores (are those the same thing these days?), and Core Web Vitals, all in one place.

📆 05 Mar 2024  | 🔗

  • Frontend
  • core web vitals
  • page speed
  • Lighthouse
  • web performance 

Removing list styles without affecting semantics. | Manuel Matuzović

A simple tweak that simplifies the common approach to "lists that don't look like lists" with HTML/CSS and sidesteps any semantic/accessibility concerns. Neat!

you can use a string as the value of the `list-style-type` property.
ul { 
    list-style-type: "";
}

A history of painting (with dinosaurs) | Mark Witton

Ultimately, this is a book review, but it's a very good one that helps dissect the topic of where palaeoart fits in with the wider canon of art itself. It certainly gave me pause for thought on how even I (with a growing palaeoart collection) think about displaying and enjoying the medium.

On the snobbery and cultural conditioning of dinosaurs as "childish" and therefore not worthy of artistic expression (itself a quote from Lescaze 2017):

“Throw an engraving of an egret above the mantelpiece and no one balks. Hang a painting of a *T. rex* in the same spot, and the decision screams nerd stuck in second childhood.”

On the core question of the book and, arguably, of palaeoart itself:

And, more broadly, it asks why must art of dinosaurs be useful? Can it not be art for the sake of being art, or created purely for aesthetic value?

What is utility-first CSS? | Heydon Pickering

As acerbic and cutting a critique of utility-first CSS (and that particular framework) as you would expect from Heydon, but hidden amongst the humour are some (also equally expected) jewels of wisdom. It's not that Tailwind and utility-first CSS are automatically bad; they have their place. But when taken as the end-all solution for CSS, they cross a line that becomes hard to ignore.

On how utility-first CSS both requires a solid knowledge of CSS to work well, and is least appealing to those that have that knowledge in the first place:

However, paradoxically, the more you learn about CSS, the less you may appreciate utility-first CSS. You might begin to question why it should exist at all.

On inheritance and the cascade, and how they can save you a huge amount of code if embraced:

In fact, I believe there’s a kind of CSS 80/20 rule wherein about 80% of your styling should be done with just 20% (or less!) of your CSS.

On where utility classes are most beneficial:

Where utility classes come in is they allow you to make occasional exceptions to these generalized styling rules.

On the innate paradox at the core of "utility-first CSS":

Utility-first CSS is exception-first CSS. And that’s not how exceptions work, in CSS or in general.

On how utility-first CSS is really only beneficial when there are a lot of design differences across an interface, and how that's probably a big ol' red flag:

To put it another way, show me a design for an interface that benefits from being coded using utility-first CSS and I will show you an interface that is fundamentally f**ked.

On Tailwind and utility-first frameworks:

So what is Tailwind really? It’s just CSS with extra steps and a brand name. Then again, you can say that about most any CSS framework.

On the fallacy of chasing the new and shiny, and believing that more recent ideas are automatically better:

But CSS isn’t new, it’s only good. And in this backwards, bullshit-optimized economy of garbage and nonsense, good isn’t bad enough.

📆 04 Mar 2024  | 🔗

PWA quickstart | Pure PWA

An interesting – albeit flawed – attempt at a zero-dependencies, web standards focused, PWA based UI framework, and a potentially useful quick-start template for using web components and native APIs to build a lightweight web app. I will caution that the author has some odd ideas about both HTML and front end development in general. For example: they advocate the use of <label> wrappers for <input>, but fail to understand that you still need the id attribute for accessibility purposes. They also chose to use a range slider as the basis for a switch component 🤷‍♀️ So, I like the underlying principles and general idea, but wouldn't recommend using this as-is or copying code verbatim; it's definitely not reliable, and as the author doesn't even have their own personal website, it's hard to know how experienced they are in actual front end development.

Made By Me, But Made Possible By:

CMS:

Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.