/*
 * Per-library icon rendering rules (icon-libraries follow-up to
 * SKILLS-EDITOR-PLAN.md WP6/WP2). Every vendored sprite's `<symbol>`s carry
 * ONLY path data — no `fill`/`stroke` — exactly like lucide-static's own
 * sprite always has (see the top-level PROVENANCE.md note this bug started
 * from). Rendering (fill vs stroke, stroke width, caps/joins) is therefore a
 * per-LIBRARY rule, not a per-icon one, and it has to ship as a CSS asset
 * next to the sprite rather than live in the renderer (`packages/renderer`
 * has no idea which icon library a given `<use>` came from, and shouldn't
 * need to).
 *
 * Selectors key on the `<use href>` value actually rendered
 * (`renderElement` in packages/renderer/src/tree.ts emits it verbatim once
 * resolved) — `:has()` is supported in every browser this project targets
 * (Chrome/Edge 105+, Safari 15.4+, Firefox 121+).
 */

svg:has(> use[href*="/icons/2.0.0/lucide/sprite.svg#"]) {
  fill: none;
  stroke: currentColor;
  stroke-width: 2;
  stroke-linecap: round;
  stroke-linejoin: round;
}

/* Legacy pre-2.0.0 lucide URL — `icon-sweep` re-points these, but a page
   that hasn't been swept yet (or a hand-authored tree that still names the
   old path) should not render as an unstyled black blob in the meantime. */
svg:has(> use[href*="/icons/1.45.0/lucide-sprite.svg#"]) {
  fill: none;
  stroke: currentColor;
  stroke-width: 2;
  stroke-linecap: round;
  stroke-linejoin: round;
}

svg:has(> use[href*="/icons/2.0.0/heroicons-outline/sprite.svg#"]) {
  fill: none;
  stroke: currentColor;
  stroke-width: 1.5;
  stroke-linecap: round;
  stroke-linejoin: round;
}

svg:has(> use[href*="/icons/2.0.0/heroicons-solid/sprite.svg#"]) {
  fill: currentColor;
  stroke: none;
}

svg:has(> use[href*="/icons/2.0.0/tabler/sprite.svg#"]) {
  fill: none;
  stroke: currentColor;
  stroke-width: 2;
  stroke-linecap: round;
  stroke-linejoin: round;
}

svg:has(> use[href*="/icons/2.0.0/phosphor/sprite.svg#"]) {
  fill: currentColor;
  stroke: none;
}

/* Generic layout for every icon sprite reference, whichever library —
   verified against the feature-card layout (`.mb-3` etc: this rule sets
   nothing that competes with margin utilities). `vertical-align` is kept:
   it only affects inline-flow alignment (icon-next-to-text rows), which is
   exactly where a default `baseline`-aligned inline SVG looks wrong, and it
   does not affect block-level spacing utilities like `mb-3`. */
svg:has(> use[href*="/assets/skills/icons/"]) {
  display: inline-block;
  vertical-align: middle;
}