My revisit of HTML since 2002
Most people who learn to build websites are taught the same thing early: separate your HTML, your CSS, your JavaScript. One file for structure. One for style. One for behaviour.
In large engineering teams, this is correct. It enables collaboration, version control, modularity. The logic holds.
But most websites are not built by large engineering teams. And applying the same structure to a different context is not discipline — it is a mismatch.
The best practice for a team of twenty is not the best practice for a team of one.
Observation, Apr 2026
That was enough. The friction was small, but repeated. Repeated friction is not a minor inconvenience — it is a design problem.
The real question
When I started thinking about this, the question I was actually asking was not:
Should HTML and CSS be separated?
The question was: For a small website — maintained by one person, assisted by AI, updated in real business time — what structure is actually the most maintainable?
These are different questions:
1. It has a textbook answer.
2. It requires judgment.
What locality does
It makes the scope of change visible
When a section's HTML and its corresponding CSS sit close together, changing a button colour means reading one block — not navigating between a stylesheet and a template, losing context twice.
The structure becomes: see where you are, change what you see. That is not a shortcut. It is a design decision.
For small websites, maintainability is often about visibility, not abstraction.
It improves AI collaboration
LLMs work best on things that are locally coherent — where the HTML, the relevant CSS, and the interaction logic sit close enough to be understood together.
When structure is highly distributed — styles in a separate file, components spread across imports, class names shared across contexts — the model is more likely to change the wrong thing, affect an unrelated section, or optimise for the wrong scope.
Locality reduces that surface area. Not because the AI cannot handle complexity, but because smaller, clearer units are easier to modify correctly.
It survives time
For SME sites and personal projects, the real test of a structure is not whether an engineer would approve of it today. It is whether you can still read it six months from now, open it cold, and know exactly what to change.
If that is true, the structure is working.
The fair caveat
This is not an argument against modular CSS. At scale — with multiple contributors, shared component libraries, design systems that span dozens of pages — separation is the right call.
The point is not that one approach is correct and the other is not. The point is that the decision should follow from context, not from convention.
The question to ask is not: what is the standard way? The question is: who is going to maintain this, and what makes that easiest for them?
Redefining maintainability
In formal engineering, maintainability means abstraction — systems that are decoupled, modular, independently testable.
For small websites, it means something else. It means: the next person who opens this file — whether that is a collaborator, a client, an AI, or yourself — can understand it, locate what needs changing, and change it without breaking anything else.
That is a different definition. But it is not a lesser one.
The best structure is not the most architecturally pure. It is the most appropriate — for the site, the stage, and the person doing the work.
