4 ms·

It's not inevitable. I love Svelte partly because it solves the problem by compartmentalizing CSS to the UI component I'm working on. It feels natural that if I

It's not inevitable. I love Svelte partly because it solves the problem by compartmentalizing CSS to the UI component I'm working on. It feels natural that if I write CSS in a file for a component it shouldn't be seen by other components in general.

ravenstine 5y ago
Even without Svelte, most of the problems people have with CSS go away if you do the following: - Avoid cascading (i.e. no nested selectors except when there's "no other way") - Implement separate selectors for styling and page/component layout (separation of concerns) - Using a good naming convention and stick with it The first point can also be achieved with using style attributes if that floats your boat, although Svelte kind of gives you the best of both worlds just by compartmentalizing the CSS, not necessarily by preventing cascading. I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse.
- bobbylarrybobby 5y ago
  Points 1 and 2 sound a bit like CSS's new "layer" feature
- xiphias2 5y ago
  I believe that Svelte is so natural extension to the current web that - just like with CoffeeScript and ES6 - some of it should be adopted. Importing HTML files as modules with localized CSS+JS as web components would be one such option for example.
  - deleted 5y ago
    [deleted]
  - replygirl 5y ago
    this is called an html module: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
    - xiphias2 5y ago
      Thanks, it looks great. I'm happy that they didn't rush it. They don't talk much about compatibility with current web frameworks, I think they should. I really hope that it will be featureful enough to support being a target for compiling Svelte components (or even maybe React / Vue components) to HTML modules to be imported at some point, but still stay simple enough to be useful.
- reactor 5y ago
  Mind telling a bit more on this second part "Implement separate selectors for styling and page/component layout (separation of concerns)"? Are you referring to classes (for styles) and probably id's for Javascript?
  - adamauckland 5y ago
    Layout is the structure of the page, grids, master breakpoints etc. eg. .grid .row .column .banner Styling is setting colors/fonts/padding etc on a specific component. eg. .sign-up-form .delete-button .accept-button
- ratww 5y ago
  > I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse. Yep. I find of the usage of !important I see daily is failure of the programmer to understand precedence rules, which, as you pointed towards, is mostly due to cascading.
alskdjflaskjdhf 5y ago
On the other hand, I find Svelte's handling of this half-baked, as there's no way to pass scoped classes to a component, only to a HTML element. [1] In fact, I find this so frustrating that I have actually given up on Svelte's CSS scoping entirely and I use Tailwind instead, which also solves the same problem by almost [2] completely disregarding the cascade altogether. [1] Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element? [2] Of course Tailwind supports modifiers, which do cascade, but everything is still local to a single element.
- xiphias2 5y ago
  One of the questions for passing scoped classes to a component is why you want to do it. If you have complex selectors, it would effect the implementation of the component, so I think that would be an anti-pattern. Just modifying the root would be great, but in Svelte I believe one component can translate to multiple root nodes, so all of them would need to get the styles, which again would increase the coupling between the component usage and implementation. I think there's just no clean way to do what you want.
  - alskdjflaskjdhf 5y ago
    I already said why in my first comment: > Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element? Yes, it's nothing something you'd want to do willy-nilly or all the time, but there are perfectly valid use cases. This issue has been one of the single most-commented in the Svelte repos with tons of back and forth and a lot of demand so this isn't just an obscure complaint either. As for how to resolve it, there are plenty of clean ways to do it. Svelte's style scoping is done via a unique class per component. It suffices to simply provide some way to pass this class from a parent to a child, for example, and let the child component decide what to do with it. There are many possible variations on this theme. The obstacle to resolving this problem isn't technical infeasibility, it's that to date the maintainers just haven't cared.
    - 5y ago

ravenstine 5y ago

Even without Svelte, most of the problems people have with CSS go away if you do the following: - Avoid cascading (i.e. no nested selectors except when there's "no other way") - Implement separate selectors for styling and page/component layout (separation of concerns) - Using a good naming convention and stick with it The first point can also be achieved with using style attributes if that floats your boat, although Svelte kind of gives you the best of both worlds just by compartmentalizing the CSS, not necessarily by preventing cascading. I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse.

bobbylarrybobby 5y ago
Points 1 and 2 sound a bit like CSS's new "layer" feature
xiphias2 5y ago
I believe that Svelte is so natural extension to the current web that - just like with CoffeeScript and ES6 - some of it should be adopted. Importing HTML files as modules with localized CSS+JS as web components would be one such option for example.
- deleted 5y ago
  [deleted]
- replygirl 5y ago
  this is called an html module: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
  - xiphias2 5y ago
    Thanks, it looks great. I'm happy that they didn't rush it. They don't talk much about compatibility with current web frameworks, I think they should. I really hope that it will be featureful enough to support being a target for compiling Svelte components (or even maybe React / Vue components) to HTML modules to be imported at some point, but still stay simple enough to be useful.
reactor 5y ago
Mind telling a bit more on this second part "Implement separate selectors for styling and page/component layout (separation of concerns)"? Are you referring to classes (for styles) and probably id's for Javascript?
- adamauckland 5y ago
  Layout is the structure of the page, grids, master breakpoints etc. eg. .grid .row .column .banner Styling is setting colors/fonts/padding etc on a specific component. eg. .sign-up-form .delete-button .accept-button
ratww 5y ago
> I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse. Yep. I find of the usage of !important I see daily is failure of the programmer to understand precedence rules, which, as you pointed towards, is mostly due to cascading.

alskdjflaskjdhf 5y ago

On the other hand, I find Svelte's handling of this half-baked, as there's no way to pass scoped classes to a component, only to a HTML element. [1] In fact, I find this so frustrating that I have actually given up on Svelte's CSS scoping entirely and I use Tailwind instead, which also solves the same problem by almost [2] completely disregarding the cascade altogether. [1] Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element? [2] Of course Tailwind supports modifiers, which do cascade, but everything is still local to a single element.

xiphias2 5y ago
One of the questions for passing scoped classes to a component is why you want to do it. If you have complex selectors, it would effect the implementation of the component, so I think that would be an anti-pattern. Just modifying the root would be great, but in Svelte I believe one component can translate to multiple root nodes, so all of them would need to get the styles, which again would increase the coupling between the component usage and implementation. I think there's just no clean way to do what you want.
- alskdjflaskjdhf 5y ago
  I already said why in my first comment: > Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element? Yes, it's nothing something you'd want to do willy-nilly or all the time, but there are perfectly valid use cases. This issue has been one of the single most-commented in the Svelte repos with tons of back and forth and a lot of demand so this isn't just an obscure complaint either. As for how to resolve it, there are plenty of clean ways to do it. Svelte's style scoping is done via a unique class per component. It suffices to simply provide some way to pass this class from a parent to a child, for example, and let the child component decide what to do with it. There are many possible variations on this theme. The obstacle to resolving this problem isn't technical infeasibility, it's that to date the maintainers just haven't cared.
  - 5y ago