paceaux

ahhh.

Yeah I put it there just to discourage folks from asking some LLM to summarize it.

I really don't want my content fed to Sam Altman.

Good for them. I build my website around topics. If you just want a raw list of everything I've written, that's the sitemap. Otherwise, just browse by topics or even the tags on the posts.

You mean a sitemap? Because you're talking about a sitemap. Most blogs have a sitemap.xml that lists all of the posts.

Also, why would you want to go through all 235 posts?

<ruby> is going to be featured in my next article: You don't know HTML…Semantics.

I'm debating whether that one will be one or two articles because I'm going to be covering everything from <ruby>, <bdi>, <bdo> all the way through <var>, <kbd>, <samp>, <cite>, and <q>.

After that one, I'll probably have something like, "You don't know HTML interactions" or something to cover <dialog>, <popover>, and the Invoker API.

So sit tight; it's all coming.

This is called out explicitly in the article as a shift from HTML4 to HTML5.

I'm not quite sure what you mean about that… I do have a disclaimer in the sidebar that makes it clear that I'm not using AI — but that's solely so that people can appreciate that I put actual effort into writing it.

I'm writing articles like this just because I think the internet deserves some humanity for a change. Thanks for noticing.

I will probably write an entirely separate article just on the CSS options for lists. So ... don't hold your breath. But that will come. Eventually.

It's like a dumpsterfire caught in a hurricane

https://blog.frankmtaylor.com/2025/08/28/america-by-design-i...

I'm 100% convinced this was vibecoded

I was doing a write-up on it from looking at the code and about 3/4's of the way through I realized, "there's no possible way a human was this bad."

https://blog.frankmtaylor.com/2025/08/28/america-by-design-i...

You really might want to look into what the DOM is and how it works.

When HTML reaches the browser, all the markup is parsed, and the browser creates a Document Object Model (https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...). That object model is an extremely robust API that's loaded with tons of functionality, not the least of which is working with events (https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...).

The browser itself brings so much functionality that you can do stuff like check the status of the battery; create, save, and access files; get someone's precise lattitude and longitude; and _create and subscribe to streams_.

I'm not sure what you mean by, "html does not allow for event handling," ... but if HTML exists in a browser at all, there's plenty of event handling to go around.

So, worth explaining (as I've told other folks here), my experience is in enterprise content management, usually building good ol' fashioned websites that are running on .net and getting content from a CMS. For the entirety of my career, I never ONCE worked with a CSS library. Every single one of my clients (who were on the Fortune 500 list, usually) had too unique of a design and too many different types of pages for us to bring in an external CSS library.

So, for that reason, when I wrote these guidelines internally some years ago, we weren't concerned in the least with what CSS libraries were doing because we didn't use them. We were concerned with consistency, more than anything

We went with camelCase because we liked that it was the same convention we followed in our JavaScript, AND it was easy to select stuff in the IDE.

Even WITH there being a VSCode extension, I still wouldn't change my reasoning because that kinda breaks the guidance of, "least disruptive to the team." I wouldn't want to have a project that required some IDE extension to keep teammates productive the way they want.

ALL THAT SAID, as I explained in the start of the guidelines, they are just that...guidelines. The goal is to be consistent and not have teammates present or future curse your name. So developers should really favor team cohesiveness over my opinions based on my specific experience.

To be totally honest, I originally didn't have any guidance around having a class name for .qa (this was a gist long before I made it a blog post and I'd been sharing the gist with teams for years). I had a boss point out that sometimes for [reasons] he would have to add selectors to things just for Selenium tests, and when that happened, he like using .qa because then it was obvious to him and anyone else it had to be deleted later.

BTW, the _reason_ he had to add classnames was because we worked in enterprise content management and there were all sorts of situations where, for WHATEVER reason, we couldn't change the markup, or we could only modify the markup in VERY specific ways via the CMS. So finding a way to stick `qa` on an element was a more straightforward path than writing some ridiculous selector like `body > div > div > header ~ article:first-child`

Suffice to say, YES, I agree that adding a class just so you can run a test is bad, but, we hit situations where we had to, and when that happened, it was worth while to have a convention for knowing how to identify classes that served just that purpose.

I've tried that approach in the past. The reason I didn't promote it in the guide is because data attributes, in my experience, were more verbose than what we needed.

They were useful in cases where we needed to pass in additional information (e.g. data-qa="onClick"). But what we found was

- whether class or attribute, it was the same dependency on markup - selecting with [data-qa] was the same specificity as .qa - selecting with [data-qa] was just a little more verbose than the teams liked

But, this isn't me arguing against data attributes. I'm just stating that my experience went in the direction where we didn't see any huge benefit.

They're guidelines so, by all means, take what works, throw away the rest. This was a small guideline about how to name stuff, not build entire apps. So if that's the thing that doesn't work for your workstream, my feelings aren't hurt. Thanks for reading it, though, and sharing your thoughts.

When I wrote the guidelines, it really was all about, "be consistent". camelCase is my preference, but really, go with what makes sense and is least disruptive.

I actually REALLY like SuitCSS' recommendation and I definitely wouldn't object to it.

I intentionally didn't address project architecture (folder names, file names) because ... to be honest... I still haven't quite figured that out.

But I'm going to think on it and maybe add something to the guidelines that echos your suggestion.

Thanks. That's one of those where I have probably 100 cases in code I've written over the years and I can't find a single one when I actually needed it. I'm open to better examples.

I'm the original author.... and what I can say is that my area of specialization is content management; creating the CMS and the websites that consume from the CMS. So I'm not doing "app development"; I'm doing traditional website development and scoped CMS is not on the table. This little guide for naming things is something I used with teams for YEARS as we were building very large websites for very large companies.

Suffice to say, the SuitCSS convention is extremely close to what we've put into use over the years.

That's a really valid criticism. I'll update it. Thanks!

I'm the original author.

Somewhere else on my blog is an article about using BEM with content management systems (which is my area of specialization). I basically endorsed your exact practice, but with __content models__.

The idea being that a content model could have multiple presentations (views), but still relies on a single core .... data model. So the Block is that data model and the modifier is the view.

So your practice is 100% what I would endorse. This is a sample of the CSS guidelines I'd produce for my teams where you'll see that I explain it a bit more: https://gist.github.com/paceaux/f31e278613ab29b74a412a7eb504...

I'm the original author

All of the examples are within the last 2 years. My area of specialization is enterprise content management; I build the CMS AND the front-end for very large companies that use decoupled CMSs and web sites. And very often, the web app is a typical server-side .net app where a front-end team has written static HTML and handed it off to back-end developers to be sliced into views. So all of this stuff kinda comes from over a decade of doing THAT; it's fair to say that maybe this doesn't all apply if you're an app dev.

But even when I DO build SPAs (like I am for one client), I still use CSS in traditional stylesheets as much as possible because any inline styling that doesn't invoke the CSSOM directly like it should seems like a massive waste of DOM resources ... and also I feel like I lose out on reusability that way.

That "clean code for typescript" is really good. I may drop a link to it in mine. I wasn't trying to be exhaustive. I was just trying to set a good baseline for where to go ;)

original author here:

That's valid and maybe I'll update the guide to explain a bit more when/where I have found getProperty() useful:

I often do it when I end up having to have parity in API request: a get AND a set. If there's more than one thing i'm doing with temperature, it's helpful to show WHAT I'm doing with it, specifically. I'll noodle on your thoughts a bit and see how I can incorporate them.

Whoa. Don't know how this got here (I'm the presenter)

I'm doing a write up of each of these 7 deadly sins. Will share links when I'm finished.