This post opens Problems Cotomy Set Out to Solve. This first looked like a styling problem. It turned out to be a structural one.
For the web applications I saw around me when I started working, this was never really about styling. It was about whether a system could survive change.
Cotomy is not a UI framework in the usual sense. It is a response to structural failures that make long-term business UI maintenance brittle. The earliest and most persistent problem was not JavaScript. It was CSS.
How the Web Got Here
When I started working, the web systems around me were still primitive compared with desktop applications. Before Ajax became common, most screens were request and response flows with full page reloads. JavaScript existed, but it was not yet a comfortable foundation for building rich business interaction.
At that time, web development itself was still far less common than it is now, so I did not have many chances to work on it directly. I was mostly watching it from nearby while doing more C++ and VB work.
As CSS and JavaScript became more capable, web systems gradually became more interactive. Screens could add elements, replace sections, and react to user input in more fluid ways. That progress solved one problem, but it also exposed another: structure, appearance, and behavior had evolved through different historical layers. HTML described the document, CSS lived elsewhere, and JavaScript started mutating the result afterward.
Why This Matters
In business systems, screens live for years. Sometimes decades. They do not scale like consumer products where redesigns reset the surface. In this world, CSS is not a cosmetic layer. It is a boundary definition. If that boundary is vague, the entire system becomes fragile.
Here, boundary means the place where change is allowed to stay local: where ownership is clear, scope is explicit, and one screen can change without silently affecting others.
Rich screens inevitably need dynamic behavior. They add rows, open panels, replace fragments, and change the visible state in response to user operations. But for a long time, the web made this awkward compared with desktop software. Even after dynamic manipulation became more practical, the visual definition of the added elements often remained somewhere else as CSS, detached from the place where the structure was created or changed.
That separation is not just inconvenient. It makes the screen harder to reason about. If the structure is produced in one place, the behavior lives in another, and the appearance is defined somewhere else again, the cost of safe change rises immediately.
The question was never “how do we make pages look better.” It was “how do we make pages safe to touch after hundreds of screens exist.”
The Reality I Saw
Large business applications inevitably need a large number of screens because the breadth of the target domain turns into tables, forms, search views, and maintenance pages. In that kind of development, the highest priority is often not elegance. It is how to build that large set of tables and screens without collapsing the design, without losing control of the schedule, and without creating a system that becomes unmaintainable before delivery.
Once that becomes the real objective, UI decisions change. The more screens you have, the more dangerous CSS becomes. The impact radius is unclear, and as a result teams avoid touching UI at all. The safest option becomes a conservative, unambitious interface because ambition increases risk.
In systems originally built for the early 2000s browser world, especially with Internet Explorer as the operational baseline, even CSS-based visual design was often minimal. Many screens were built as plain white pages with primitive table-based layouts and double-line cell borders. Those screens were not visually impressive, but that was often a rational tradeoff. Instead of wasting limited resources on fragile visual refinement, teams prioritized something that worked, shipped on time, and created obvious business value.
This is one of the quiet reasons many business UIs in Japan look plain. It is not a lack of taste. It is fear of unintended cross-screen breakage.
Razor Pages and Scoped CSS
After years of building systems in PHP, Razor Pages felt immediately right to me when I encountered it. One of the biggest reasons was scoped CSS. It was probably the moment that gave me the clearest relief in web UI development. Before that, working with globally applied CSS meant constantly managing selectors, classes, and document structure with extreme caution just to avoid breakage. You could keep things barely stable, but only by spending mental energy on areas that were not the actual screen problem you were trying to solve.
When CSS is scoped to a page, that burden changes immediately. The applicable range is explicit. The area you have to think about becomes dramatically smaller. You can improve a screen without worrying about a chain reaction across unrelated areas.
That experience made the root cause obvious to me. CSS was becoming dangerous not because styling itself was difficult, but because it introduced a cross-cutting structure that cut across the page’s real structure and consumed my limited mental resources. Once I saw that, I became convinced that CSS safety is architectural, not stylistic.
This principle aligns with Cotomy’s design model, where HTML is the primary structure and CSS is scoped at the same boundary (see Cotomy Reference – First UI (CotomyElement) ).
At the same time, I also felt that page-level scoped CSS was still not enough. If the frontend behavior layer kept operating outside the same boundary, the structural problem would return in another form. That is why I eventually came to think that the frontend side also needed the same kind of explicit unit: HTML, CSS, and behavior had to stay aligned around one screen boundary.
What Existing Approaches Missed
HTML is structure. CSS is a structural boundary. Treating CSS as an external, loosely attached asset breaks the unity of the screen.
If you want rich UI on the frontend, then adding, changing, and removing elements is unavoidable. Screens need to open sections, append rows, replace blocks, and respond to user interaction with real structural changes. Modern component-oriented frameworks are strong in exactly that area. Tools such as React support this style of implementation very well by hiding direct DOM handling behind component structure and TSX-like syntax.
In a SPA-style application, that can be a reasonable tradeoff. The whole application is often treated as one continuous screen model, so the pain caused by CSS being separated is not always felt in the same way as in server-rendered business systems with a large number of independent CRUD screens.
But that difference in pressure matters. In large business systems, the real problem is not only how to build one rich screen. It is how to build and maintain hundreds of screens without letting change radius expand everywhere. In that context, once the visual rules live outside the boundary of the screen unit, mismatches become hard to avoid completely. Of course some shared rules are necessary. That is normal. But styles begin applying where they are inconvenient, local changes require broader caution, and the clean mental model of the UI starts weakening again.
Many approaches address this pain, but their goals are different. Global CSS optimizes for reuse more than safety. CSS Modules reduce collisions but can still feel detached from structure. Inline styles are too limited for long-term maintenance. TSX is powerful but heavy for simple stable screens. Styled components bring structure and style closer, but also move more control into JavaScript than I wanted.
These are not bad tools. They simply optimize for different problems. If a screen unit is supposed to own structure, appearance, and behavior together, then CSS cannot remain a loosely attached sidecar. It has to belong to the same boundary that HTML defines, while TypeScript manages behavior within that boundary.
What I Needed to Solve
The requirement was simple and strict, but it was not about styling convenience.
I needed structure, appearance, and behavior to stay aligned around the same screen boundary. I needed a screen to remain self-contained even when it became more interactive. I needed dynamic UI changes to be possible without forcing me to think about unrelated screens. And I needed that model to keep working when the system grew into hundreds of CRUD pages.
That is why CSS could not be treated as a sidecar file. HTML and CSS had to form a single unit, and the impact radius of change had to stay local to that unit.
This is what makes UI sustainable in business systems. The independence of a screen is not a visual preference. It is operational survival.
This Is Not a Styling Debate
This topic is easy to misread as a discussion about design taste or how rich a screen should look. It is not.
The real issue is whether a business system can evolve without breaking itself. The question is not whether UI should be plain or visually ambitious. The question is whether rich behavior can be introduced without destroying maintainability. In that sense, CSS is not an aesthetic concern here. It is a boundary concern.
The first visible symptom happened to be CSS, but the deeper problem was that the structure of the screen and the boundaries of change did not line up.
Cotomy’s Approach (Briefly)
Cotomy starts from HTML as the primary screen structure. CSS is scoped at that same unit, so the visible boundary of the screen and the styling boundary match each other. TypeScript then handles behavior inside that same screen boundary instead of redefining the whole UI through a rendering abstraction.
In practical terms, the screen unit is the HTML-defined unit itself. Style and behavior close around that same unit instead of being owned somewhere else. The important part is not the file layout. It is that ownership, scope, and change radius are aligned around one screen boundary.
In other words, the screen is defined as an HTML unit, style is scoped to that structure, and behavior attaches to that same unit. That is the concrete shape of “closing” the boundary in Cotomy.
That does not make Cotomy a replacement for SPA frameworks. It reflects a different priority. The goal is to keep large numbers of business screens stable, local, and understandable while still allowing richer interaction where it is needed.
Details will come later. The important point in this first article is the boundary problem. I came to see HTML and CSS as one unit because, in the business applications I build, their separation was one of the earliest causes of UI fragility.
Problem Series
This article is part of the Cotomy Problem Series, which examines recurring structural failures in business UI design.
Series articles: HTML and CSS as One Unit, Form Submission as Runtime , Screen Lifecycle and DOM Stability , Form State and Long-Lived Interaction , API Protocols for Business Operations , Runtime Boundaries and Operational Safety , UI Intent and Business Authority , and Binding Entity Screens to UI and Database Safely .
