
DSS, a deterministic way to manage CSS - ggurgone
https://survivejs.com/blog/dss-interview
======
supernintendo
What problem is this trying to solve? I don't see what benefit there is to
generating a unique CSS class for each individual style; it just seems like a
reimplementation of inline styles.

 _In addition to that with atomic CSS your application bundle size grows,
i.e., at some point, you can keep adding CSS, but the file size of your CSS
bundle won 't change (increase)._

It should be noted that this is absolutely not true if your application uses
static rendering. Sure, you might be able to avoid multiple references to the
same CSS rule in your stylesheet but now your compiled HTML is even more
bloated. A button from any given CSS framework takes 5-12 CSS rules to look
decent. Now imagine creating a unique class name for each rule and applying
that to every button on the page.

There's also the issue of swapping styles in the browser to get a sense of how
things look. I maintain an internal admin UI where the navbar is styled
differently depending on the environment to avoid a developer accidentally
affecting production data. It's a lot easier to swap `.dev` with `.prod` on an
element than it is to swap out all of these class names or restart my web
server, overriding the environment. DSS also means that your developers will
have to sift through a lot of useless noise when inspecting the DOM; pull up
[https://dss-lang.com/](https://dss-lang.com/) in your browser's DOM inspector
and tell me if that's something you'd enjoy working with.

~~~
ggurgone
> it just seems like a reimplementation of inline styles.

In a way it is but with some important differences:

\- You still write styles in regular files instead of inline. You then
reference those in your templates and the library replaces them with the
corresponding atomic CSS classes. \- See my reply to CGamesPlay.

> with atomic CSS your application bundle size grows, i.e., at some point

your application bundle size grows "logarithmically"! Probably
"logarithmically" got accidentally deleted.

In a way CSS is an "append only" language (or at least that's how it ends up
being used) and the more features you add the more your bundles grow. With
atomic CSS classes this is not an issue.

> A button from any given CSS framework takes 5-12 CSS rules to look decent.
> Now imagine creating a unique class name for each rule and applying that to
> every button on the page.

Just to make sure that it is clear enough, you as developer don't
generate/apply unique classes by hand. Instead you reference rules which map
to sets of atomic classes.

> HTML is even more bloated

True, but I believe that this approach is fairly gzip friendly. So repetition
is not an issue.

> There's also the issue of swapping styles in the browser to get a sense of
> how things look.

Controlling things globally could be handy but it won't scale. I don't think
that it is a deal breaker to toggle some state in your app and hit refresh.

> DSS also means that your developers will have to sift through a lot of
> useless noise when inspecting the DOM

DSS already allows to include readable class names and I am planning to use
those to add source maps.

-

All your concerns and comments are valid however atomic CSS has its benefits
(companies like Linkedin, Facebook and Twitter use solutions that compile to
those kind of classes).

The main feature of DSS is deterministic styles resolution anyway, atomic CSS
classes are only the medium to achieve that with plain old static CSS.

~~~
supernintendo
_True, but I believe that this approach is fairly gzip friendly. So repetition
is not an issue._

Ok, that's true. But what about browser caching? Using traditional CSS, users
only have to visit one page and they've downloaded the stylesheet for the
entire site. They can navigate to 100 other pages and never have to re-
download the stylesheet because it's cached. With DSS, our CSS files are
smaller but our HTML bodies are larger due to all of these class names. That
means every time we load a new page, we're downloading thousands of bytes of
class names that we already have. For static rendering this is a no-go,
regardless of gzip.

 _Controlling things globally could be handy but it won 't scale. I don't
think that it is a deal breaker to toggle some state in your app and hit
refresh._

It's a deal breaker for me because my designer doesn't know Elixir. You act
like toggling "some state" within an application is trivial. Maybe it is to
you or me but it might not be to one of your team members who is only
concerned with the CSS. I don't know what you mean by "won't scale". We're
talking about changing styles in the browser. This is a developer workflow
issue, not a technical issue.

 _The main feature of DSS is deterministic styles resolution anyway, atomic
CSS classes are only the medium to achieve that with plain old static CSS._

Not true. There's another way to achieve that: good CSS.

~~~
ggurgone
Typically this is a concern only for server side rendered and dynamic pages.

When you render on the client you don't have these kind of issues (only pros).

When pages are fully static (e.g. a landing page) you can configure your
server (or proxy) to also send the right headers so that even the HTML is
cached.

In the case of dynamic SSR pages instead you lose caching but that's not an
issue imho. You should optimize for initial rendering and delivery a small
amount of CSS (critical CSS) is a recognized best practice. Again gzipped the
HTML is fine dss-lang.com's heaviest page is 6kb.

> It's a deal breaker for me because my designer doesn't know Elixir. You act
> like toggling "some state" within an application is trivial. Maybe it is to
> you or me but it might not be to one of your team members who is only
> concerned with the CSS. I don't know what you mean by "won't scale". We're
> talking about changing styles in the browser. This is a developer workflow
> issue, not a technical issue.

As I said you can add readable class names and can tweak styles in the browser
and then copy/paste to the .css file. I am also going to add source maps
support.

If designers are authoring production or dev styles they should be able to
control simple states like that (the same way they should be able to add a css
class to an html element in your templates).

An escape hatch could be introducing a `:global` pseudo class like in css
modules - it'd allow to add the dev and prod classes you are talking about but
it would break deterministic styles resolution (unless everything is wrapped
with one or the other).

> Not true. There's another way to achieve that: good CSS.

Define "good". Even if you have a reasonable definition, experience has taught
me that it is very hard to do so (specially when you work in teams) see this
thread:
[https://twitter.com/giuseppegurgone/status/10285952078251868...](https://twitter.com/giuseppegurgone/status/1028595207825186816)

------
CGamesPlay
Why not just switch to inline style attributes? It seems like moving those
styles into a CSS class is an unnecessary level of indirection.

~~~
ggurgone
It is an option and some have tried that but eventually switched to a similar
model as the one described in the article because inline styles were
underperforming when compared to class names (I imagine that React could be
also part of the problem). See [https://github.com/necolas/react-native-
web/pull/283#issueco...](https://github.com/necolas/react-native-
web/pull/283#issuecomment-266484275) for example.

Another cons of using inline styles is that you cannot use pseudo classes (eg
:hover) and media queries.

~~~
CGamesPlay
Interesting, thanks for the response. How do you handle pseudo classes and
media queries now? Does the pseudo class get transformed into a portion of the
class name? If so, do pseudo classes override the determinism, or is it still
done right-to-left?

~~~
ggurgone
> Does the pseudo class get transformed into a portion of the class name?

Yes. I assume that a state eg .foo:hover { color: red } is always more
specific than the idle state .foo {}

Atomic CSS classes are sorted so that states and media queries are at the
bottom of the bundle and always override basic styles.

There is a comprehensive list of supported css features here [https://dss-
lang.com/supported-css-features/](https://dss-lang.com/supported-css-
features/)

