6 ms·

I like the simplicity provided by scoped CSS, and I tend to name classes in a way that essentially accomplishes scoping. However, there's this nagging feeling

I like the simplicity provided by scoped CSS, and I tend to name classes in a way that essentially accomplishes scoping. However, there's this nagging feeling at the back of my mind that if every component in your app has its own stylesheet, your style is maybe not consistent? It just seems like the ideal website with a consistent and good UI design should be able to have a single stylesheet (probably written in Stylus/SASS). I don't know if this ever happens in practice, but it's just something I think about. Less on-topic, I feel like the title of this article is wrong: you're not "Just Writing CSS" if you're writing scoped CSS, which requires some sort of build system.

abritinthebay 9y ago
I’m writing scoped CSS in SASS - I’d postulate that that is the maximum you should require (and most sass systems will have a way build on request to your server).
rich_harris 9y ago
I debated whether to title it something else for that exact reason. But I went with 'just writing CSS' because the code you're writing is just CSS, with all the benefits it entails — it's basically just like writing JS inside an IIFE rather than polluting the global namespace. You make a good point about consistency. Personally I'll often have a small global stylesheet that implements basic typography/colour/etc rules — it's more important to ensure that your component styles don't leak out than avoiding global styles leaking in, in my experience.
monfera 9y ago
An example may be, graphic designer shop gets a contract to update the company 'style guide'. It gets done and there are a lot changes that are cross-cutting w.r.t. components, starting with fonts, borders, margins, border styling etc. Also, what's not fully clear to me, what if - as usually is the case - the components are nested? Changing eg. font in the outer component would leave inner components fully intact? A side note, I'm wondering how the Svelte approach relates to `isolation` in cycle.js https://github.com/cyclejs/cyclejs/issues/259 https://github.com/cyclejs/cyclejs/issues/259 -
- rich_harris 9y ago
  Totally — I'll often have a small global CSS file for that exact reason. (Scoped CSS is about preventing your components from clobbering each other rather than preventing the desirable aspects of the cascade.) If components are nested, inheritance still happens (unless you're compiling to web components with Shadow DOM, which Svelte allows), but cascading doesn't unless you opt-in per-selector with the global:(...) modifier borrowed from CSS modules. Re isolation, if I've understood correctly, then state in components is indeed isolated.
marcosdumay 9y ago
> which requires some sort of build system I don't get what you are trying to say. If you put your stile inside a div, and set the "scoped" attribute, it's scoped. What build system is required? About the overall consistency, yes, some things must be global. It would be best if CSS allowed you to define those in one place and apply in another one. Yet it doesn't, so you must keep all the declarations touched by global data at a global style. That's bad, but what is even worse is putting the local declarations there too.
- dfabulich 9y ago
  The "scoped" attribute is not what this article recommends, nor would I recommend that anyone else use it. MDN describes it as deprecated. [1] It was dropped from Chrome in v35. Instead, the article calls for using Svelte and its build tools to automatically add unique attributes to HTML elements and add corresponding selectors to CSS. Svelte is awesome, but there's no doubting that it is a build tool, and I think it's fair to argue that if you're committing to a build tool either way, maybe you'd be just as happy using a richer build tool based on TypeScript and styled React components or whatever floats your boat. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style https://developer.mozilla.org/en-US/docs/Web/HTML/Element/st...
  - spankalee 9y ago
    The "scoped" attribute is deprecated, but CSS scoping is alive and well inside ShadowRoots. No build tool needed.
    - dfabulich 9y ago
      There's no Shadow DOM support in Firefox or IE/Edge, and Safari support is buggy. http://caniuse.com/#feat=shadowdomv1 http://caniuse.com/#feat=shadowdomv1 The client-side polyfill for Shadow DOM requires executing JS before paint, which is slow. For optimum performance, you have to polyfill it server side, with a build tool. At that point, you might as well just pre-process it for all browsers, at which point, maybe you'd enjoy something more flexible than Shadow DOM, e.g. something that lets you share styles between components.
mrighele 9y ago
> However, there's this nagging feeling at the back of my mind that if every component in your app has its own stylesheet, your style is maybe not consistent? I think we can distinguish two orthogonal uses for CCS styles. One is applying a global style to the page/app ("theming", "branding", etc) and the other is for defining the layout of a component. For technical reasons they have lived together, but with shadow DOM One can put the former on a global CSS and the latter togheter with the component. By doing this I think you can remain consistent, in fact I suspect that it may improve consistency since it is better clear what is part of the style (and thus should be respected/changed with care) and what is an implementation detail of a single piece of a page. Of course the risk of a component "going rogue with styles" exists, but maybe (and now I am just speculating) by adding CSS variables to the mix we can help the single components to be more consistent with the rest of the app.
jasim 9y ago
You can use a global set of variables for typography, colors, borders, box-shadows, and spacings. This could be CSS variables, SASS, or Javascript variables in CSS-in-JS. Typography and colors are something almost everyone tries to keep within a bounded set, but spacings are often overlooked. If the designer has defined a clear set of spacings - like 8px for small, 24 for medium, and 48px for large, then we can build consistent interfaces by using that as a primitive. Button paddings will be $small-spacing, while sections can be separated by $large-spacing etc. The stylesheet at this point is just an application of all these base values to the HTML structure of the particular component, and that arrangement can be unique to each component depending on how its HTML is laid out. http://tachyons.io http://tachyons.io does this really well - @mrmrs_ has teased out a universal set of base values that can cover most designs, and has built out a complete UI kit out of it. There are many experience reports online, here's how DNSimple went about it - https://blog.dnsimple.com/2017/01/CSS-journey/ https://blog.dnsimple.com/2017/01/CSS-journey/.
- jacobr 9y ago
  Has anyone in practice updated brand colors without needing other major style changes?
  - aplummer 9y ago
    Yep, changing government department colours in my case. About 6 departments wanted the same components and each had small themeing changes, really just colour and font.
- spookyuser 9y ago
  Tachyons is so good that I would find it difficult to go back to plain css. I usually cringe looking at non Tachyons stylesheets. I'm not even totally sure how I worked before it.
madeofpalk 9y ago
Instead of thinking of it as a 'single stylesheet' for consistent UI, but instead a 'library of styles', just like if you were writing code (JS or whatever). When you need to DRY and reference something in your library, just import it. CSS Modules does this really smartly with `composes`.
jbreckmckye 9y ago
Yes, but consistency of design should be enforced by the design process, not the technology. By the time the developer is implementing the feature the (inconsistent) design has already been signed off. All global styles achieve is to make it difficult to break out of conventions when our layouts and designs diverge on purpose.
deleted 9y ago
[deleted]

abritinthebay 9y ago

I’m writing scoped CSS in SASS - I’d postulate that that is the maximum you should require (and most sass systems will have a way build on request to your server).

rich_harris 9y ago

I debated whether to title it something else for that exact reason. But I went with 'just writing CSS' because the code you're writing is just CSS, with all the benefits it entails — it's basically just like writing JS inside an IIFE rather than polluting the global namespace. You make a good point about consistency. Personally I'll often have a small global stylesheet that implements basic typography/colour/etc rules — it's more important to ensure that your component styles don't leak out than avoiding global styles leaking in, in my experience.

monfera 9y ago

An example may be, graphic designer shop gets a contract to update the company 'style guide'. It gets done and there are a lot changes that are cross-cutting w.r.t. components, starting with fonts, borders, margins, border styling etc. Also, what's not fully clear to me, what if - as usually is the case - the components are nested? Changing eg. font in the outer component would leave inner components fully intact? A side note, I'm wondering how the Svelte approach relates to `isolation` in cycle.js https://github.com/cyclejs/cyclejs/issues/259 https://github.com/cyclejs/cyclejs/issues/259 -

rich_harris 9y ago
Totally — I'll often have a small global CSS file for that exact reason. (Scoped CSS is about preventing your components from clobbering each other rather than preventing the desirable aspects of the cascade.) If components are nested, inheritance still happens (unless you're compiling to web components with Shadow DOM, which Svelte allows), but cascading doesn't unless you opt-in per-selector with the global:(...) modifier borrowed from CSS modules. Re isolation, if I've understood correctly, then state in components is indeed isolated.

marcosdumay 9y ago

> which requires some sort of build system I don't get what you are trying to say. If you put your stile inside a div, and set the "scoped" attribute, it's scoped. What build system is required? About the overall consistency, yes, some things must be global. It would be best if CSS allowed you to define those in one place and apply in another one. Yet it doesn't, so you must keep all the declarations touched by global data at a global style. That's bad, but what is even worse is putting the local declarations there too.

dfabulich 9y ago
The "scoped" attribute is not what this article recommends, nor would I recommend that anyone else use it. MDN describes it as deprecated. [1] It was dropped from Chrome in v35. Instead, the article calls for using Svelte and its build tools to automatically add unique attributes to HTML elements and add corresponding selectors to CSS. Svelte is awesome, but there's no doubting that it is a build tool, and I think it's fair to argue that if you're committing to a build tool either way, maybe you'd be just as happy using a richer build tool based on TypeScript and styled React components or whatever floats your boat. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style https://developer.mozilla.org/en-US/docs/Web/HTML/Element/st...
- spankalee 9y ago
  The "scoped" attribute is deprecated, but CSS scoping is alive and well inside ShadowRoots. No build tool needed.
  - dfabulich 9y ago
    There's no Shadow DOM support in Firefox or IE/Edge, and Safari support is buggy. http://caniuse.com/#feat=shadowdomv1 http://caniuse.com/#feat=shadowdomv1 The client-side polyfill for Shadow DOM requires executing JS before paint, which is slow. For optimum performance, you have to polyfill it server side, with a build tool. At that point, you might as well just pre-process it for all browsers, at which point, maybe you'd enjoy something more flexible than Shadow DOM, e.g. something that lets you share styles between components.

mrighele 9y ago

> However, there's this nagging feeling at the back of my mind that if every component in your app has its own stylesheet, your style is maybe not consistent? I think we can distinguish two orthogonal uses for CCS styles. One is applying a global style to the page/app ("theming", "branding", etc) and the other is for defining the layout of a component. For technical reasons they have lived together, but with shadow DOM One can put the former on a global CSS and the latter togheter with the component. By doing this I think you can remain consistent, in fact I suspect that it may improve consistency since it is better clear what is part of the style (and thus should be respected/changed with care) and what is an implementation detail of a single piece of a page. Of course the risk of a component "going rogue with styles" exists, but maybe (and now I am just speculating) by adding CSS variables to the mix we can help the single components to be more consistent with the rest of the app.

jasim 9y ago

You can use a global set of variables for typography, colors, borders, box-shadows, and spacings. This could be CSS variables, SASS, or Javascript variables in CSS-in-JS. Typography and colors are something almost everyone tries to keep within a bounded set, but spacings are often overlooked. If the designer has defined a clear set of spacings - like 8px for small, 24 for medium, and 48px for large, then we can build consistent interfaces by using that as a primitive. Button paddings will be $small-spacing, while sections can be separated by $large-spacing etc. The stylesheet at this point is just an application of all these base values to the HTML structure of the particular component, and that arrangement can be unique to each component depending on how its HTML is laid out. http://tachyons.io http://tachyons.io does this really well - @mrmrs_ has teased out a universal set of base values that can cover most designs, and has built out a complete UI kit out of it. There are many experience reports online, here's how DNSimple went about it - https://blog.dnsimple.com/2017/01/CSS-journey/ https://blog.dnsimple.com/2017/01/CSS-journey/.

jacobr 9y ago
Has anyone in practice updated brand colors without needing other major style changes?
- aplummer 9y ago
  Yep, changing government department colours in my case. About 6 departments wanted the same components and each had small themeing changes, really just colour and font.
spookyuser 9y ago
Tachyons is so good that I would find it difficult to go back to plain css. I usually cringe looking at non Tachyons stylesheets. I'm not even totally sure how I worked before it.

madeofpalk 9y ago

Instead of thinking of it as a 'single stylesheet' for consistent UI, but instead a 'library of styles', just like if you were writing code (JS or whatever). When you need to DRY and reference something in your library, just import it. CSS Modules does this really smartly with `composes`.

jbreckmckye 9y ago

Yes, but consistency of design should be enforced by the design process, not the technology. By the time the developer is implementing the feature the (inconsistent) design has already been signed off. All global styles achieve is to make it difficult to break out of conventions when our layouts and designs diverge on purpose.

deleted 9y ago

[deleted]