Hacker News Reader

Comment by dlbucci | Hacker News Reader

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.

View on HN

> 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.

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 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/.

Has anyone in practice updated brand colors without needing other major style changes?

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.

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.

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.

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.

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`.

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 -

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.

> 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.

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/st...

The "scoped" attribute is deprecated, but CSS scoping is alive and well inside ShadowRoots. No build tool needed.

There's no Shadow DOM support in Firefox or IE/Edge, and Safari support is buggy. 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.

I'd double check your performance assumptions. Polymer-based sites are usually at the top of the list for perf shootouts, even though they tend to be purely runtime rendered. The key is only executing very little JavaScript and very carefully managing DOM creation.

The ShadyDOM/ShadyCSS Shadow DOM shims are quite fast, and the benefit is that you don't need them when you have native Shadow DOM, vs a compile-time solution that you're likely married to and is proprietary. Shadow DOM gets faster automatically as browsers adopt standards, and portable and lasting knowledge is worth a lot.

Safari's Shadow DOM implementation has improved a ton over the last year. Polymer 2.0 defaults to using it over the polyfills. caniuse.com needs to be updated - the second bug listed is fixed now.

It depends on what you measure. Google argues that "time to interactive" is the correct number to optimize for; that's where Polymer-based sites shine.

But nobody can beat streaming server-rendered (or ServiceWorker-rendered) HTML + CSS on a "time to paint" basis. Google claims that "time to paint" is the wrong measure, but if you're using progressive enhancement, TTP is all you need.

Shadow DOM mostly sucks anyway for lack of a good way of sharing styles between shadow roots. (It's awesome that we can encapsulate CSS with shadow DOM, but that was too much encapsulation.)

Oh, wait. A sane components system for the web? That's almost unbelievable.

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).

Reply on news.ycombinator.com