26 Matching Annotations
- Nov 2022
-
github.com github.com
-
Use a :global rule to only expose parts of the stylesheet:
-
- Mar 2021
-
www.jackfranklin.co.uk www.jackfranklin.co.uk
-
but I like that Svelte comes with a good CSS story out the box.
comes with a good CSS story out the box
-
- Nov 2020
-
medium.com medium.com
-
Any “unused” css will be stripped out when compiling, and since the compiler correctly sees that we have no p tags in App.svelte , it throws out that bit of css.
-
-
github.com github.com
-
If your Svelte components contain <style> tags, by default the compiler will add JavaScript that injects those styles into the page when the component is rendered. That's not ideal, because it adds weight to your JavaScript, prevents styles from being fetched in parallel with your code, and can even cause CSP violations. A better option is to extract the CSS into a separate file. Using the emitCss option as shown below would cause a virtual CSS file to be emitted for each Svelte component. The resulting file is then imported by the component, thus following the standard Webpack compilation flow.
-
-
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
- who should have control over this? (programming)
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
- workarounds
- Svelte: how to affect child component styles
- maintenance burden to explicitly define/enumerate/hard-code possible options (explicit interface)
- 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)
- Svelte: components are their own boss (encapsulation)
- forking to add a desired missing feature/change
- ugly/kludgey
- component/library author can't consider/know ahead of time all of the ways users may want to use it
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
- key point
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- Svelte: how to affect child component styles
- +0.9
- important point
- Svelte: CSS encapsulation
- arbitrary limitations leading to less-than-ideal workarounds
- missing out on the benefits of something
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
-
-
The problem with the export { className as class } approach is that the classes defined in the parent/calling component still have to be marked as being global otherwise they get removed.
-
-
github.com github.com
-
In my mind, the primary argument for this is that it's a very common thing to need and cleaner than the current alternative of string manipulation or wrapping the child component in a <div class:active><Child /></div>.
-
-
css-tricks.com css-tricks.com
-
style="--columns:{cols}"
-
-