Version: 1.8 (Sept 2025)
Philosophy: Robust structure, flexible content.
The ISO methodology solves the "decision tax" and fragility inherent in collaborative web development, where diverse teams (internal, freelancers, agencies) often waste hours debugging conflicts or deciphering inconsistent naming conventions. By enforcing a rigid three-part structure separated by underscores—[WHERE]_[WHAT]_[WHICH]—but allowing total flexibility within those bounds, ISO creates a "firewall" around every section of a website. This ensures that a freelancer working on a "Hero" section can move at maximum speed using their preferred naming style without fear of breaking the "Footer," eliminating the cognitive load of strict naming dogma while guaranteeing the structural consistency required for scalable, high-speed production.
Why did we call it like that? ISO stands for Isolation, Structure, Object. We wanted to refer to isolating code to prevent conflicts, enforcing a simple structure for consistency, and clearly defining the HTML object being styled.
This methodology doesn't seek to impose how to name things, but help how to structure them so they don't break. It is a robust and simple system:
As long as everyone respects the Sacred Structure, the system can handle any style without breaking.
To avoid reading extensive manuals, there is only one law: Your class must have 3 parts, separated by underscores.
The underscore (_) is the containment wall. It allows flexibility to exist without causing chaos.
Defines the section. It is the isolation bubble. Total freedom: Use whatever your team decides is clearest.
Golden rule: Everything inside that section must start with this same prefix.
What is the HTML element? Keep this simple so any developer understands it quickly.
The surname. Be as specific as the design requires.
The system adapts to the team, not the other way around.
For example, a "speed" team might prefer typing less, choosing a class like hro1_text_intro. This works perfectly because the underscore maintains the structural order even with short codes.
A "clarity" team, on the other hand, might prefer reading clear English and opt for hero-home_text_intro. The underscore separates the concepts just the same, ensuring readability.
Finally, an "enterprise" team might need to be extremely specific, using something like srv-new-design_card_dark. The system supports that level of detail without breaking the structure.
See the pattern? No matter the style, the visual structure _ _ always tells you where to cut.
Ideal if collaborating with agencies that don't know your internal codes.
<section class="landing-page_wrap">
<div class="landing-page_grid_hero">
<div class="landing-page_col_content">
<h1 class="landing-page_head_main-title">We do more</h1>
<div class="landing-page_wrap_buttons">
<a href="#" class="button-primary">Start</a> <!-- Global -->
</div>
</div>
</div>
</section>
Ideal for rapid iteration and daily maintenance.
<section class="srv1_wrap">
<div class="srv1_grid_list">
<div class="srv1_card_item">
<h3 class="srv1_head_card">Relia</h3>
<p class="srv1_text_desc">Subscription.</p>
</div>
</div>
</section>
Result: hero-main_text_title
atQuo is a creative partner that operates at the intersection of design, technology, and marketing strategy. Our **Insights and Talks** exist to demystify this intersection, sharing the expert knowledge required to make smarter decisions about the tools and tactics that drive growth. This same expertise fuels our services, where we execute on that strategy to build powerful digital experiences that help brands scale with clarity and confidence.
Today's most successful brands are built on a complex ecosystem of software, apps, and AI. In Stack Decoded, the experts at atQuo cut through the noise, demystifying the critical digital tools that power growth.
Version: 1.8 (Sept 2025)
Philosophy: Robust structure, flexible content.
The ISO methodology solves the "decision tax" and fragility inherent in collaborative web development, where diverse teams (internal, freelancers, agencies) often waste hours debugging conflicts or deciphering inconsistent naming conventions. By enforcing a rigid three-part structure separated by underscores—[WHERE]_[WHAT]_[WHICH]—but allowing total flexibility within those bounds, ISO creates a "firewall" around every section of a website. This ensures that a freelancer working on a "Hero" section can move at maximum speed using their preferred naming style without fear of breaking the "Footer," eliminating the cognitive load of strict naming dogma while guaranteeing the structural consistency required for scalable, high-speed production.
Why did we call it like that? ISO stands for Isolation, Structure, Object. We wanted to refer to isolating code to prevent conflicts, enforcing a simple structure for consistency, and clearly defining the HTML object being styled.
This methodology doesn't seek to impose how to name things, but help how to structure them so they don't break. It is a robust and simple system:
As long as everyone respects the Sacred Structure, the system can handle any style without breaking.
To avoid reading extensive manuals, there is only one law: Your class must have 3 parts, separated by underscores.
The underscore (_) is the containment wall. It allows flexibility to exist without causing chaos.
Defines the section. It is the isolation bubble. Total freedom: Use whatever your team decides is clearest.
Golden rule: Everything inside that section must start with this same prefix.
What is the HTML element? Keep this simple so any developer understands it quickly.
The surname. Be as specific as the design requires.
The system adapts to the team, not the other way around.
For example, a "speed" team might prefer typing less, choosing a class like hro1_text_intro. This works perfectly because the underscore maintains the structural order even with short codes.
A "clarity" team, on the other hand, might prefer reading clear English and opt for hero-home_text_intro. The underscore separates the concepts just the same, ensuring readability.
Finally, an "enterprise" team might need to be extremely specific, using something like srv-new-design_card_dark. The system supports that level of detail without breaking the structure.
See the pattern? No matter the style, the visual structure _ _ always tells you where to cut.
Ideal if collaborating with agencies that don't know your internal codes.
<section class="landing-page_wrap">
<div class="landing-page_grid_hero">
<div class="landing-page_col_content">
<h1 class="landing-page_head_main-title">We do more</h1>
<div class="landing-page_wrap_buttons">
<a href="#" class="button-primary">Start</a> <!-- Global -->
</div>
</div>
</div>
</section>
Ideal for rapid iteration and daily maintenance.
<section class="srv1_wrap">
<div class="srv1_grid_list">
<div class="srv1_card_item">
<h3 class="srv1_head_card">Relia</h3>
<p class="srv1_text_desc">Subscription.</p>
</div>
</div>
</section>
Result: hero-main_text_title

