Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Evolution of Scalable CSS

frontendmastery.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: The Evolution of Scalable CSS

#21

Post by c-smile »

FYI, component styles in Sciter can be placed directly in JS module using `CSS.set` string literal (gets compiled at runtime to special style set object).

The style set is a collection of styles rules local (rooted at) to the component. :root denotes the component to which styleset is applied.

The style set definition is strictly local to the component - rules inside it do not pollute global style table. That is close to to anyone who remember such thing.

Here is how styled component.js module looks like:

    const padding = "12px";

    const styleset = CSS.set`
      :root {
         color: var(--theme-color);
         padding:${padding};
         background: var(--theme-back);
      }

      :root > em {
        color: gold;
      }`

    export class TestComponent extends Element {
      render() {
        return 
          Hello Embedded Style Set
        ;
      }
    }
IMHO, that's the best of two worlds - components may have local styles principal for their operation, and to use global styles that define macro properties like themed colors, etc.

Re: The Evolution of Scalable CSS

#22

Post by spankalee »

c-smile wrote: post #21

FYI, component styles in Sciter can be placed directly in JS module using `CSS.set` string literal (gets compiled at runtime to special style set object). The style set is a collection of styles rules local (rooted at) to the component. :root denotes the component to which styleset is applied. The style set definition is strictly local to the component - rules inside it do not pollute global style table. That is clos…

This is almost exactly how Lit works in browsers. CSS is included with a css`` template string, that contains standard CSS. :host is used to select the host element, as is standard.

    @customElement('simple-greeting')
    class SimpleGreeting extends LitElement {
      static styles = css`
        :host {
          display: flex;
        }
        p {
          color: blue;
        }
      `;

      render() {
        return html`
Hello, World!
`;
      }
    }
So you get CSS that loads with components, is scoped, and bundles without plugins. It's pretty great.

Re: The Evolution of Scalable CSS

#24

Post by alwillis »

azangru wrote: post #2

> The Evolution of Scalable CSS The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? T…

There’s also no mention of CSS Cascade Layers [1].

[1]: https://css-tricks.com/css-cascade-layers/

Re: The Evolution of Scalable CSS

#26

Post by c-smile »

spankalee wrote: post #22
c-smile wrote: post #21

FYI, component styles in Sciter can be placed directly in JS module using `CSS.set` string literal (gets compiled at runtime to special style set object). The style set is a collection of styles rules local (rooted at) to the component. :root denotes the component to which styleset is applied. The style set definition is strictly local to the component - rules inside it do not pollute global style table. That is clos…

This is almost exactly how Lit works in browsers. CSS is included with a css`` template string, that contains standard CSS. :host is used to select the host element, as is standard. @customElement('simple-greeting') class SimpleGreeting extends LitElement { static styles = css` :host { display: flex; } p { color: blue; } `; render() { return html` Hello, World! `; } } So you get CSS that loads with components, is sco…

Yes, that's close.

Only one thing: that static styles construct shall eventually go into a separate DOM element inside shadow root. Probably not a big deal if there are not that many such components.

Re: The Evolution of Scalable CSS

#28

Post by achairapart »

Eduard wrote: post #23

I never understood this with BEM: .nav { &__link { } } Why not this?: .nav { a { } }

To avoid CSS inheritance & specificity, the "Cascading" part of CSS is the actual root of all evil. If you think about it, all the modern approaches to CSS (BEM, Atomic CSS, OOCSS) try to avoid it all cost.

Re: The Evolution of Scalable CSS

#29

Post by tln »

alwillis wrote: post #24
azangru wrote: post #2

> The Evolution of Scalable CSS The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? T…

There’s also no mention of CSS Cascade Layers [1]. [1]: https://css-tricks.com/css-cascade-layers/

The article does mention them... I'm just finding out about this, it could be very useful!

https://frontendmastery.com/posts/the-evolution-of-scalable-....

Re: The Evolution of Scalable CSS

#30

Post by krono »

ozten wrote: post #25

Is there a resource designed for both designers and developers to aid adopting design tokens?

This W3C Design Tokens working group might be of interest to you: https://github.com/design-tokens

Ever so slightly more details in my own top-level comment https://news.ycombinator.com/item?id=33575191

Post reply on HN