18 Matching Annotations
- Nov 2020
-
github.com github.com
-
class: '' - A CSS class string.
-
- Oct 2020
-
github.com github.com
-
For the sake of best compatibility we convert the className attribute to class for svelte.
Svelte refuses to standardize on any way to pass a CSS class. I thought className was actually the most common name for this prop though even in Svelte...
-
- Sep 2020
-
-
Most simple example: <script> import ChildComponent from './Child.svelte'; </script> <style> .class-to-add { background-color: tomato; } </style> <ChildComponent class="class-to-add" /> ...compiles to CSS without the class-to-add declaration, as svelte currently does not recognize the class name as being used. I'd expect class-to-add is bundled with all nested style declarations class-to-add is passed to ChildComponent as class-to-add svelte-HASH This looks like a bug / missing feature to me.
-
-
color: red; //doesn't apply this rule, because scoping doesn't extend to children
-
Say I want to style this javascript routing anchor tag on various pages (some may be buttons, plain links, images) it makes it incredibly difficult. Eg:
-
Having to wrap everything in a selector :global(child) { } is hacky
-
-
github.com github.com
-
There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.
-
Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
-
This allows passing classes to child components with svelte-{hash} through the class prop and prevents removing such classes from css.
Tags
- component/library author can't consider/know ahead of time all of the ways users may want to use it
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- Svelte: how to affect child component styles
- forking to add a desired missing feature/change
- ugly/kludgey
- workarounds
- maintenance burden to explicitly define/enumerate/hard-code possible options (explicit interface)
- who should have control over this? (programming)
- forced to fork/copy and paste library code because it didn't provide enough customizability/extensibility / didn't foresee some specific prop/behavior that needed to be overridable/configurable (explicit interface)
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
- Svelte: components are their own boss (encapsulation)
Annotators
URL
-
-
github.com github.com
-
The problem with working around the current limitations of Svelte style (:global, svelte:head, external styles or various wild card selectors) is that the API is uglier, bigger, harder to explain AND it loses one of the best features of Svelte IMO - contextual style encapsulation. I can understand that CSS classes are a bit uncontrollable, but this type of blocking will just push developers to work around it and create worse solutions.
Tags
- missing out on the benefits of something
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- key point
- arbitrary limitations leading to less-than-ideal workarounds
- +0.9
- Svelte: how to affect child component styles
- important point
- Svelte: CSS encapsulation
Annotators
URL
-
-
svelte.dev svelte.dev
-
-
However, we've another unresolved problem - passing parent's styles to child components.
-
-
svelte.dev svelte.dev
-
github.com github.com