Icon conventions

[jasongitmail]

I'd like to see more conventions in SvelteKit.

Conventions 1.) help devs move faster, 2.) help the ecosystem grow faster by reducing waste researching/trying/rebuilding the same wheel, and 3.) in this case, improve composability of components, which will become especially useful with AI generation and as more devs build re-usable component libraries (e.g. Shadcn Svelte, Aceternity Svelte, etc) (to allow direct component usage, prevent duplicate loading of the same icon due to different icon loading methods, avoid requiring different setup, etc).

Icons are an opportunity for a convention (in official docs and create-svelte-app template) because they seem to be a solved problem given the below strategy (credit to Anthony Fu).

Set up

1. Install dependencies: npm add -D unocss @iconify/json
2. Set up vite.config.ts

import { presetIcons } from "unocss";
import UnoCSS from "unocss/vite";

export default defineConfig({
  plugins: [
    UnoCSS({
      presets: [
        presetIcons({
          prefix: "i-",
          extraProperties: {
            display: "inline-block",
          }
        }),
      ],
    }),
    sveltekit(),
  ],
});

3. In src/routes/+layout.svelte, add:

<script lang="ts">
  import "uno.css";
</script>

Usage

<div class="i-logos-svelte text-2xl"></div>

Benefits of this icon approach

1. Iconify provides a standard interface to icons
2. You can still side load icons not published on Iconify or customize icons.
3. presetIcons converts SVG into CSS (so it doesn't increase JS bundle size like unplug-icons does)
4. perfect DX (no need to import anything before using an icon--just specify the icon where used).
5. Efficiency - the CSS containing each icon is included–at most once–sitewide in a far-futures cached CSS file. No unused icons are included.

Background

• https://antfu.me/posts/icons-in-pure-css Anthony Fu explains what lead to this approach; he was using unplug-icons that he also created.
• https://unocss.dev/presets/icons

The ask

I'd like to see this as a convention in SvelteKit templates and docs. It's easy to set up, once a person knows how, but having conventions provides important benefits noted in the intro.

CC @benmccann For his Twitter thread where I originally saw Anthony Fu's response.

[benmccann]

It sounds to me like you're asking for svelte-add/svelte-add#315

[dominikg]

agree discovery of these options could be easier, but a category for "icons" in svelte-add would do that, combine it with talking about these more. Like I did a few svelte summits ago in a mini series called "sveltable vector graphics".

[jasongitmail]

If discovery were the only goal, a section on the official docs would be more effective.

But that misses out on most the other benefits: devs will still be obligated to spend time evaluating different libs before choosing, it prevents sharing of the Svelte team's opinion on current best practice for SvelteKit to save others this time researching, inhibits knowledge bubbling about current known best practice, (in this case) prevents standardization around a given strategy that would help the component libs ecosystem grow in a compatible way, etc.

Lacking this, it relegates icons (& sitemap, SEO metadata, etc) to the same era of image plugins prior to enhanced:image, where half a dozen partially-broken solutions exist.

This doesn't mean everything needs to be core. It means the team would serve the community better by providing an opinion in the docs on the pieces that it is known to lack, & in some cases, also including those pieces as part of the project templates. For common pieces.

[benmccann]

create-svelte/svelte-add is largely meant to be our recommendations of good defaults. That's why we offer vitest/playwright, but not other testing libraries. We've talked about adding docs for those CLIs to svelte.dev, which might help with discoverability via Google.

I wasn't aware of Tailwind with the Iconify plugin until now, but if I had to make a recommendation for something that's probably what it would be after having tried a few of these out now. I do like the CSS approach and unocss seems nice, but Tailwind is just way more popular than unocss.

svelte-add also offers a Tailwind integration. There's been some discussion of having it ask a question about plugins. Right now it just asks yes/no for typography, but we could instead make it a longer list of plugins with a checkbox for each of typography, forms, iconify, etc.

[aloker]

+1 for more tailwind plugins in svelte-add (including icobify)

[jasongitmail]

(Thanks everyone. I appreciate you hearing me out on the importance of conventions & I'll leave it at that. I'd welcome sharing other areas I have experienced in svelte spending time where I wish it hadn't been necessary and hope to help others can skip researching & rebuilding some of these wheels unless they choose to.)

I wasn't aware of Tailwind with the Iconify plugin until now, but if I had to make a recommendation for something that's probably what it would be after having tried a few of these out now. I do like the CSS approach a

Appreciate the opinion!

An ideal solution would:

1. use iconify (standardizes interface to icons)
2. be performant (no JS icons)
3. be agnostic of the styling framework (for community benefits)

Pros/Cons of @iconify/tailwind:

• 🟢 Uses Iconify

• 🟢 Similar performance (SVG converted into CSS)

• ❌ Not agnostic of the styling framework b/c requires tailwind.config.js

• ❌ TailwindCSS v4 intends to move to a CSS-based configuration by default; this would lock users into the JS config.

• ❌ Weird syntax (for "dynamic" font family imports):

  <!-- using @iconify/tailwind -->
  <span class="icon-[mdi-light--home]"></span>
  
  <!-- using @egoist/tailwindcss-icons -->
  <span class="i-[mdi-light--home]"></span>

• ❌🟢 weird syntax (for specific icon family imports), but egoist's is good:

  <!-- Usage with @iconify/tailwind -->
  <span class="iconify mdi-light--home"></span>
  <span class="iconify-color vscode-icons--file-type-tailwind"></span>
  
  <!-- Usage with @egoist/tailwindcss-icons -->
  <span class="i-mdi-light-home"></span>

I still see unocss' version as more optimal for SK (primarily b/c it's a Vite plugin):

• 🟢 Uses Iconify
• 🟢 Similar performance (SVG converted into CSS)
• 🟢 Agnostic of the styling framework in the sense that it's a Vite plugin, ❌ although requires importing uno.css so not as ideal as it could be. almost!
• 🟢 Nice syntax (i-mdi-light-home or i-mdi:light-home)

[dominikg]

I wasn't aware of Tailwind with the Iconify plugin until now, but if I had to make a recommendation for something that's probably what it would be after having tried a few of these out now. I do like the CSS approach and unocss seems nice, but Tailwind is just way more popular than unocss.

at least tailwind v3 is technically inferior to unocss in vite and might be harder to integrate because you need a custom extractor for it.