4 ms·

DSS, a deterministic way to manage CSS

21 points by ggurgone 8y ago

originalsimba 8y ago
This is a terrible idea. Anyone who wants a career in development should learn how to write properly using the languages they're going to use. SASS/SCSS makes sense because it's practically CSS syntax, but this is not.
CGamesPlay 8y ago
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 8y ago
  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#issuecomment-266484275 https://github.com/necolas/react-native-web/pull/283#issueco... for example. Another cons of using inline styles is that you cannot use pseudo classes (eg :hover) and media queries.
  - ggurgone 8y ago
    For the record I like the authoring experience of inline styles because of the same reason you brought up :) It is slightly harder to enforce static CSS and do composition but definitely doable. In fact I would like to build a CSS in JS library that is as powerful and allows static extraction. Waiting for Facebook to open source their solution first (so that I don't reinvent the wheel) https://twitter.com/sebmck/status/1036018032336822273 https://twitter.com/sebmck/status/1036018032336822273
  - CGamesPlay 8y ago
    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 8y ago
      > 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/
supernintendo 8y ago
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.
- TheDong 8y ago
  Indeed, there's no way this reduces total size of the full content delivered to a user's browser. The full style for a button on that page is: DSS-6s7ra7ruauhgs1p418889953wr DSS-7ntue76nuangdx9rpn9qj5qt1r dss_zwfkme-4y1s1i dss_1l2fjdf-4y1s1i dss_18pw31d-kb7nvz dss_1i43vt4-kb7nvz dss_14e3233-fkmc3a dss_1uacqdt-m23pbg dss_hsg9lc-6hioi1 dss_17gxg2d-3b2xjc dss_2w3qqg-kpf7b0 dss_17ivt7s-6r0uxk dss_1aj8hfn-iu2jf4 dss_itsfbh-kb7nvz dss_rfc3hq-1jm7nmq dss_36r1g7-t94yts dss_5b4my1-18gtugd dss_1cskmy3-6r0uxk dss_1gss4ms-t94yts dss_1496ft4-t94yts dss_ik5ixr-t94yts dss_nmh4m5-t94yts dss_28mnjz-t94yts dss_1mkfkum-t94yts dss_xa3mwb-t94yts dss_1j1jkdq-t94yts dss_gbyv8j-iu2jf4 dss_1sgye3s-x2w3rg dss_1yzcwad-x2w3rg dss_py4k60-iu2jf4 dss_1q9w8i1-irswps dss_rwa454-4clis7 dss_1ot5qnt-1dvrs12 dss_1bix7jo-1v6z61t dss_107cujk-1v6z61t dss_19r5tdc-1v6z61t dss_ez733i-1v6z61t dss_igbmbv-kb7nvz dss_1qu7vtx-kb7nvz dss_1swntt0-kb7nvz dss_1x63vd7-kb7nvz
- ggurgone 8y ago
  > 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.

21 points by ggurgone 8y ago

This is a terrible idea. Anyone who wants a career in development should learn how to write properly using the languages they're going to use. SASS/SCSS makes sense because it's practically CSS syntax, but this is not.

CGamesPlay 8y ago

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 8y ago
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#issuecomment-266484275 https://github.com/necolas/react-native-web/pull/283#issueco... for example. Another cons of using inline styles is that you cannot use pseudo classes (eg :hover) and media queries.
- ggurgone 8y ago
  For the record I like the authoring experience of inline styles because of the same reason you brought up :) It is slightly harder to enforce static CSS and do composition but definitely doable. In fact I would like to build a CSS in JS library that is as powerful and allows static extraction. Waiting for Facebook to open source their solution first (so that I don't reinvent the wheel) https://twitter.com/sebmck/status/1036018032336822273 https://twitter.com/sebmck/status/1036018032336822273
- CGamesPlay 8y ago
  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 8y ago
    > 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/

supernintendo 8y ago

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.

TheDong 8y ago
Indeed, there's no way this reduces total size of the full content delivered to a user's browser. The full style for a button on that page is: DSS-6s7ra7ruauhgs1p418889953wr DSS-7ntue76nuangdx9rpn9qj5qt1r dss_zwfkme-4y1s1i dss_1l2fjdf-4y1s1i dss_18pw31d-kb7nvz dss_1i43vt4-kb7nvz dss_14e3233-fkmc3a dss_1uacqdt-m23pbg dss_hsg9lc-6hioi1 dss_17gxg2d-3b2xjc dss_2w3qqg-kpf7b0 dss_17ivt7s-6r0uxk dss_1aj8hfn-iu2jf4 dss_itsfbh-kb7nvz dss_rfc3hq-1jm7nmq dss_36r1g7-t94yts dss_5b4my1-18gtugd dss_1cskmy3-6r0uxk dss_1gss4ms-t94yts dss_1496ft4-t94yts dss_ik5ixr-t94yts dss_nmh4m5-t94yts dss_28mnjz-t94yts dss_1mkfkum-t94yts dss_xa3mwb-t94yts dss_1j1jkdq-t94yts dss_gbyv8j-iu2jf4 dss_1sgye3s-x2w3rg dss_1yzcwad-x2w3rg dss_py4k60-iu2jf4 dss_1q9w8i1-irswps dss_rwa454-4clis7 dss_1ot5qnt-1dvrs12 dss_1bix7jo-1v6z61t dss_107cujk-1v6z61t dss_19r5tdc-1v6z61t dss_ez733i-1v6z61t dss_igbmbv-kb7nvz dss_1qu7vtx-kb7nvz dss_1swntt0-kb7nvz dss_1x63vd7-kb7nvz
ggurgone 8y ago
> 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.