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 clever browser extension that uses rel="me" links to find people's Mastodon/Fediverse accounts from their personal websites.

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.

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.)

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!

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.

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: "";
}

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?

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.

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.

Remy has some good arguments for why TypeScript can be just as much of an issue as it is a benefit. I've personally got a love/hate relationship with the abstraction, so it's always good to have some of my own feelings validated 😉 And it's good to hear from someone working "at scale" that these issues only compound, rather than smooth out, as that had been what I would have guessed.

On the confusing semantics:

A "well crafted" definition, type or interface (still no idea when I should use each), is often a huge cognitive load on me.

On one of the greatest frustrations:

Having to rewrite correctly and infallible JavaScript so that it was friendly enough for TypeScript to understand

A useful single-purpose site that implements most (if not all) currently spec'd PWA APIs and lets you play around with them. Good for testing cross-browser quirks and for seeing a quick overview of what you can actually achieve natively, right now.