paceaux's comments

On: HTML Lists

[paceaux]

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?

[vivzkestrel → paceaux]

no i am talking about a page like this

- https://www.seangoedecke.com/page/2 or

- https://mmapped.blog/posts this or

- https://kevinpatel.xyz/posts/ this

[paceaux → vivzkestrel]

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.

On: HTML Lists

[paceaux]

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

On: HTML Lists

[paceaux]

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

On: HTML Lists

[paceaux]

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.

[zamadatix → paceaux]

The reply was meant to be on the GP, I must have-mis tapped, but since we're here now :D

> No need to ask AI for a summary; I’ll just give you the ending up front.

It's easy to miss how often we bring AI up about in conversation or writing given just how dominating a topic it can be in every circle these days.

[paceaux → zamadatix]

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.

On: HTML Lists

[paceaux]

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

On: HTML Lists

[paceaux]

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.

On: America by Design

[paceaux]

It's like a dumpsterfire caught in a hurricane

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

On: America by Design

[paceaux]

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

On: Show HN: Turn Markdown into React/Svelte/Vue UI at runtime, zero build step

[paceaux]

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.

On: A small guide for naming stuff in front-end code

[paceaux]

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.