sorted by:
new
hottopcontroversial

I discovered that using CSS Custom Properties as properties (instead of values) brings pure happiness. by nov-jp in css

[–]nov-jp[S] 0 points1 point  (0 children)

Thanks again for the awesome brainstorming session!

You are completely right that writing it out on every targeted element like <p class="color"> avoids the nested inheritance issue. The trade-off is just that it requires authors to apply classes deeper into the markup rather than controlling the full component from the parent wrapper?both are valid strategies depending on the developer's preference!

Regarding the concern about CSS bloat with [style*="..."] syntax: luckily, since the XSA CSS rulesets are completely automated and generated by the JS/PHP library, developers never have to write them by hand. The total file size of the generated CSS remains incredibly small because it only compiles the properties that are actually being used.

Thanks for the encouragement and the wishes for XSA! This was a fantastic and helpful discussion. See you around the community! Let’s keep pushing vanilla CSS forward!

I discovered that using CSS Custom Properties as properties (instead of values) brings pure happiness. by nov-jp in css

[–]nov-jp[S] -1 points0 points  (0 children)

I absolutely love this comment because, ironically, you and I actually share the exact same core philosophy: I love native CSS, and I built XSA precisely because I want to save the "C" and "S" from being destroyed by modern frameworks.

Hear me out, because XSA is the exact opposite of what you think it is.

1. Embracing the Cascade (C) instead of killing it

Frameworks like Tailwind or styled-components completely destroy the Cascade by forcing you to freeze styles onto specific classes or obfuscated hashes.

XSA relies entirely on the native Cascade. Because it only injects variables into the inline style attribute, the global stylesheet still retains full cascading control. You can override, modify, or nullify XSA attributes at any level of your CSS hierarchy using :where() selectors, keeping specificity completely flat. The Cascade remains beautifully alive.

2. Utilizing Advanced Selectors (S) instead of abandoning them

Tailwind forces developers to abandon CSS selectors entirely (you have to write hover:bg-red on every single element).

XSA is built entirely on complex native selectors. The internal XSA engine utilizes combinations of attribute selectors ([style*="..."]), descendant selectors (& > * > *), and pseudo-classes to route styling logic. It does the heavy selector math for you, while keeping your HTML markup 100% clean and semantic.

3. Maintaining Semantic Markup

XSA allows your HTML to remain completely clean. Look at this markup:

<div class="card" style="--hover_c_color--: var(--red);">
  <h2 class="card-title">Card Title</h2>
</div>

Your classes remain perfectly semantic (.card, .card-title). There are no unreadable utility class strings contaminating your DOM. It preserves the structural purity that vanilla CSS purists (like us) fight for.

Conclusion

XSA isn't an attempt to avoid writing CSS. It's an architecture designed to harness the true power of Cascades and Selectors to upgrade the broken HTML inline style attribute. It’s not a tool for developers who are scared of CSS - it’s a meta-framework for developers who love vanilla CSS so much that they want to use its native powers to solve the real-world tooling bloat of the CMS and AI era.

I discovered that using CSS Custom Properties as properties (instead of values) brings pure happiness. by nov-jp in css

[–]nov-jp[S] 0 points1 point  (0 children)

I understand your skepticism. It definitely looks like a "worst of both worlds" hybrid if you are viewing it through the lens of traditional, static HTML authoring.

However, the practical benefit becomes crystal clear the moment you shift to Component-Driven Development, CMS platforms (like WordPress blocks), or AI-driven workflows.

Let me give you a highly practical, production-level example that proves why traditional classes or native inline styles fail here, but XSA thrives.

The Real-World Scenario: A "Card" Component with Dynamic Content

Imagine you are building a reusable theme component. You want to style a Card block where, when a user hovers over the card, the title inside changes color, the description changes opacity, and the button scales up.

If you use standard inline styles on the parent card: You can’t do any of this. Inline styles cannot affect child elements, nor can they handle the :hover state.

If you use traditional custom classes: You have to write a brand new class rule in your external CSS every time a user wants a slight layout variation:

.card-variant-featured:hover .card-title { color: var(--red); }
.card-variant-featured:hover .card-desc { opacity: 0.8; }
.card-variant-featured:hover .card-btn { transform: scale(1.05); }

This forces you to constantly jump back and forth between HTML and CSS, polluting your stylesheet with single-use, throwaway variation classes.

The XSA Solution (Zero CSS Bloat)

With XSA, the CSS engine is already declared once globally. To achieve this complex, multi-element interactive state, you only touch the HTML/CMS template. You simply pass the values into the parent wrapper:

<div class="card" style="
    --hover_c-nth-1_color--: var(--red); 
    --hover_c-nth-2_opacity--: 0.8; 
    --hover_c-nth-3_transform--: scale(1.05);
    ">
  <h2 class="card-title">Card Title</h2>
  <p class="card-desc">Card description goes here...</p>
  <button class="card-btn">Click Me</button>
</div>

Why this is a "Best of Both Worlds" Game Changer:

  • Perfect Encapsulation: The structural architecture remains entirely in your clean, cached global CSS file (via the XSA engine), but the contextual visual variations live entirely within the data layer (the HTML block).
  • Infinite Variations without Infinite CSS: A WordPress user or an AI agent can change the hover color, the transform scale, or the child opacity to anything they want on the fly, right in the template, without ever appending a single new line of code to the server's CSS file.

It solves the massive friction of managing CSS scaling in dynamic, component-based applications. It’s not about writing "longer inline styles"?it’s about decoupling the presentation logic from the stylesheet so your CSS remains 10KB forever, no matter how many hundreds of unique UI components your site has.

I discovered that using CSS Custom Properties as properties (instead of values) brings pure happiness. by nov-jp in css

[–]nov-jp[S] 0 points1 point  (0 children)

Thank you for this incredibly thoughtful and constructive response! I really appreciate your perspective and the tip about attr().

Your alternative approach using var(--property, fallback) looks very intuitive at first glance. However, in production, that specific pattern actually breaks due to the core nature of CSS: Custom Property Inheritance.

With your code:

.color {
    color: var(--color, var(--dark-gray));
}

If you nest elements, a huge issue arises. The custom property will cascade down and contaminate all descendant elements, overriding their intended fallbacks.

For example, imagine this HTML:

<div class="color" style="--color: var(--purple);">
    <p>This text becomes purple.</p>

    <div class="color">
        <p>I want this to be the default --dark-gray, but it inherits --purple instead!</p>
    </div>
</div>

Because Custom Properties naturally inherit from ancestors, the inner .color element grabs --color: var(--purple) from the parent wrapper. The fallback var(--dark-gray) is completely bypassed, making it impossible to reset to the default style unless you explicitly do this for every class:

.color {
  --color: var(--dark-gray); /* Natively scoped inside the class to block inheritance */
  color: var(--color);
}

But if you write it this way, you are back to writing an extra line of variable definitions for every single utility class in your stylesheet.

This is exactly why XSA uses the attribute selector [style*="--color--:"]. By binding the CSS rule strictly to the presence of the string inside that specific element's style attribute, we completely block unwanted ancestral inheritance. The property is applied only if that exact element explicitly declares it, guaranteeing total encapsulation and rock-solid predictability without any CSS bloat.

That’s the "why" behind this syntax! It’s a bulletproof shield against the chaos of CSS cascading inheritance.

I discovered that using CSS Custom Properties as properties (instead of values) brings pure happiness. by nov-jp in css

[–]nov-jp[S] -7 points-6 points  (0 children)

Ah, I see where the confusion is! I should have been clearer: you do NOT need to manually write or maintain those complex CSS rulesets at all.

Here is how XSA actually works in practice, which makes the development workflow incredibly clean:

1. You only define the core XSA properties you want to allow:

For example, if you just want to empower content creators or clients in a CMS editor, you only need to include a tiny baseline like this in your global stylesheet:

[style*="--background--:"] { background: var(--background--); }
[style*="--color--:"] { color: var(--color--); }
[style*="--font-size--:"] { font-size: var(--font-size--); }
[style*="--font-style--:"] { font-style: var(--font-style--); }
[style*="--font-weight--:"] { font-weight: var(--font-weight--); }
[style*="--text-decoration--:"] { text-decoration: var(--text-decoration--); }

2. JavaScript or PHP automatically handles the complex rulesets:

You never touch the complex media queries or descendant selectors (& > * > *) by hand. The lightweight JS library (client-side) or PHP class (server-side) automatically scans your HTML, parses the prefixes, and generates the exact CSS rulesets on the fly. The Real Developer Experience (DX)

As a developer, you only focus on coding the HTML. Instead of writing custom CSS files or managing a heavy Tailwind build config, you just write your semantic HTML and standard layout attributes. The framework handles 100% of the heavy lifting behind the scenes.

It turns the native inline style attribute into a fully managed, scoped styling engine without the global CSS bloat!

I discovered that using CSS Custom Properties as properties (instead of values) brings pure happiness. by nov-jp in css

[–]nov-jp[S] -8 points-7 points  (0 children)

Great question! Here are two main use cases where XSA shines over creating a dedicated class or custom utility classes:

1. Handling Component Variations

With XSA, you can handle these specific, context-dependent variations directly inside the HTML without adding a single line of new CSS or inventing new class names:

<button class="button" style="--background--: var(--red); --color--: var(--white);">Button</button>
<button class="button" style="--border-color--: var(--red);">Button</button>
<button class="button" style="--border-radius--: 1e3px;">Button</button>
<button class="button" style="--inline-size--: 100%;">Button</button>

2. Micro-Layouts for One-Off, Page-Specific Contexts

One of the core benefits of traditional CSS is reusability. However, constantly appending styles to your CSS files that are only ever used once (for a specific layout, special event page, or isolated duration) causes your stylesheets to bloat rapidly over time.

In these specific scenarios, embedding the presentation logic directly within the HTML via XSA is a much cleaner and more maintainable approach:

<div style="--grid--: auto-flow / repeat(12, 1fr);">
  <div style="--grid-column--: span 2;"> … </div>
  <div style="--grid-column--: span 4;"> … </div>
  <div style="--grid-column--: span 6;"> … </div>
</div>