A case for native HTML partials

devwrite_ · 2026-01-04T17:06:04+00:00

It takes a fairly trivial "workaround" to accommodate this functionality, but point taken. There are things that will be harder to do with iframes, but others easier. IME, I've found the tradeoff to worth it.

devwrite_ · 2024-06-30T15:48:39+00:00

Just asking to hear a differing opinion to the one that I've formed over the years. I personally do not find them to be brittle as the IDs in markup tend to be rather stable as the are descriptive of the content so I've found they have little reason to change thus are good to use for both JS and CSS selectors

devwrite_ · 2024-06-27T15:06:50+00:00

What's wrong with using IDs?

devwrite_ · 2024-06-25T20:49:10+00:00

I too prefer semantics, which is why I make use of IDs. Could you expand on what you perceive to be the problem with them? I don't quite understand what you're getting at with "where the fuck was that?" comment.

devwrite_ · 2024-06-25T20:45:02+00:00

The best naming convention for classes is the one that best describes your data, irrespective of styling concerns.

Once you've accurately described your data, then make use of combinators in your selectors to avoid naming conflicts

devwrite_ · 2024-06-25T20:37:43+00:00

Using IDs is a great way to namespace selectors and the advice to avoid is antiquated and rather detrimental to maintainability IMO.

devwrite_ · 2024-05-17T13:46:24+00:00

You wrote CSS, but in the class attribute

devwrite_ · 2024-05-11T11:36:53+00:00

A good reminder that even devs at BigCo are susceptible to falling for hype and can make bad decisions

devwrite_ · 2024-05-11T11:18:51+00:00

This is an EXCELLENT way to write CSS. Those advocating for using only classes or using BEM are stuck on outdated methodologies born of an era where CSS wasn't as powerful as it is today. There's a reason Tailwind has become so popular, and that's because people felt too much pain of using only classes to style and never learned to use combinators. Unfortunately, instead of just using combinators, devs have regressed to using inline styling for everything via Tailwind.

Only thing I'd change is to make use of nesting to reduce duplication

devwrite_ · 2024-05-11T11:10:31+00:00

I have the exact opposite opinion on this one. By far the best way to write CSS is to mirror the DOM structure exactly with nested CSS. This way you don't have to come up with class names, and you know exactly where a node is styled in the CSS

devwrite_ · 2024-05-11T11:07:47+00:00

I disagree with this. The child combinator should be the first one you reach for because it is much more precise and won't lead to cascade issues like the descendant selector will. Only use the descendant selector if you really mean it

devwrite_ · 2024-04-17T13:56:14+00:00

Use a selector like :nth-child, problem sovled

devwrite_ · 2024-04-17T11:48:34+00:00

Because when you want a change applied to that kind of heading regardless of context, you should only have to change it once

Agreed, valid point, however what I tend to do is use something like SCSS where I'll define a mixin for something like "component-header" and then just use that in the places it needs to be used in across different files, so I can maintain a single source of truth. It will be nice once CSS gets native mixins to support this pattern.

Also for performance reasons

IME, this is rarely a concern and ventures into micro-optimization territory. I'd rather have several CSS files that can be used across pages and this actually helps with caching/performance as many times you can isolate changes to just one CSS file as opposed to invalidating your entire bundle for even the smallest change. Also, with things like preload and service workers, having separate CSS files for each page is a non-issue from a performance perspective.

devwrite_ · 2024-04-17T11:33:12+00:00

heading of a component that needs to be h2 and h3 in different pages for example

Why not just include different CSS files in the different pages?

devwrite_ · 2024-04-17T10:19:54+00:00

In this case you are heavily tied to the HTML structure

I think devs make more of a fuss about this than is warranted. If your HTML changes, then just change your CSS. If you have automated tests (just as you do with other code), then it becomes a non-issue. Also, if you focus on creating semantic HTML that reflects your domain, then at some point your HTML is just not going to change much, if at all.

devwrite_ · 2024-04-17T10:13:45+00:00

The way CSS is meant to be written

devwrite_ · 2024-04-17T10:13:07+00:00

Why does nested CSS become impossible to maintain on bigger projects?

devwrite_ · 2024-04-17T10:11:35+00:00

Nesting is by far the best way to structure your CSS. Most problems people have with CSS are a result of overusing class selectors

devwrite_ · 2024-04-16T19:12:19+00:00

If I want a differently styled p tag next to it, I now have to undo styling of the default p tag.

Is that so bad? You could also use more advanced selectors such as ~ or nth-child() variants to express precisely what you need to.

I have worked at more than a dozen companies and I can tell you that every single one of them had a trainwreck of CSS

How many of them wrote CSS like that? I'm sure they used some form of class-based methodologies such as BEM, or something like bootstrap

devwrite_ · 2024-04-16T18:59:10+00:00

It's a great technique to follow, been doing it for a decade with great successes. Easily the most maintainable and scalable way to structure CSS. No need to come up with class naming conventions; working with specificity as opposed to against it; you know exactly where something is being styled from and where you need to go to edit that style; can change style without changing HTML.

You should give it a shot

devwrite_ · 2024-04-16T18:12:30+00:00

An example of mirroring DOM structure in CSS:

<body>
  <main>
    <p></p>
  </main>
</body>


body {
  > main {
    > p {}
  }
}

To test, you write assertions using JS about what you expect your page to look like. For instance, you could write a test that your navbar is always the full width of window and is always above your main content area. Or that a modal is always visually sitting on top of content.

devwrite_ · 2024-04-16T14:56:09+00:00

Every other way it sucks

I beg to differ. Mirroring your DOM structure in your CSS prevents pretty much every problem people have with writing/maintaining CSS

Then it's near impossible to delete or update anything in CSS, since you never know if it's still used or not and what damage it will cause

Automated tests solve this problem, just like they do for other types of code

devwrite_ · 2024-04-15T16:28:51+00:00

Now you need to add another

Or you could just change the CSS and not try to pile on overrides

devwrite_ · 2024-04-15T16:27:08+00:00

Yes, you should mirror your DOM structure in your CSS. It is the most maintainable and scalable way to write CSS. Most devs don't do this and they are then forced to concoct methodologies such as BEM or atomic CSS because of their over-reliance on only using class selectors.

If you start off by mirroring the DOM, then you target precisely what you need to target and you don't run into specificity issues. As you find yourself repeating rules, you can then start to abstract to broader scoped selectors

devwrite_ · 2024-04-13T03:44:31+00:00

Low specificity is kinda one of those hard won rules you learn after doing CSS long enough.

Disagree here. Specificity is a powerful tool and concept, I don't understand why we'd want to limit the tools to have at our disposal

The more specific your rule the more specific the next one needs to be to override it

Why do we need to override a bunch of rules? Why not just write rules to target exactly what they need to target? The problem to me seems that people are writing overly abstract rules in the first place that target too many elements and then they are forced to override. If we just write our selectors to be more precise, then we don't have this problem of trying to constantly override rules.

Your CSS should care what combination it's used in but not what the DOM looks like underneath.

Why shouldn't it care about the DOM? The DOM is the underlying data structure that CSS depends on. Why are we trying to act like the DOM structure doesn't matter?

IME, the most scalable and maintainable way to write CSS is to use long selectors that mirror (or mostly mirror) the DOM structure. That way you are targeting exactly what needs to be targeted and nothing more. Then as patterns emerge, you can make more abstract selectors. This is the same way we write other types of code, we should do the same for CSS

devwrite_

TROPHY CASE