Sì — è proprio il punto. Avvolgi il markup reale in <Skeletonizer> e il motore deriva lo skeleton dal DOM renderizzato. Sono disponibili anche le primitive manuali Skeleton*, per quando vuoi un controllo esplicito.

No. Gli elementi vengono stilizzati sul posto e mai rimossi, quindi il layout è identico prima e dopo il caricamento.

Sì. I componenti manuali Skeleton* vengono riconosciuti dal motore e lasciati intatti.

Sì, automaticamente tramite .dark / [data-theme="dark"], più setTheme() a runtime.

Sì. Il motore gira sul client dopo l'idratazione, quindi non ci sono mismatch di idratazione. Vedi SSR.

Il runtime è minuscolo e tree-shakeable — componenti e composable che non usi vengono rimossi dal bundle.

Sì. Opera sul DOM renderizzato, quindi è agnostico rispetto al framework all'interno di Vue — Nuxt UI, PrimeVue, Vuetify, markup semplice, ecc.

SVG si mappa perfettamente sul bounding box dell'host: il motore misura ogni nodo ed emette un <rect> (o un <circle> per gli avatar) alle coordinate giuste. Un singolo overlay <svg> mantiene il conteggio dei nodi DOM quasi piatto per quante ossa ci siano a schermo, lo shimmer è un'animazione CSS/SMIL nativa guidata da un solo gradiente (nessun thrashing CSS per elemento in fase di render) ed è SSR-safe e idratabile perché un <svg> è semplice markup serializzabile. preserveAspectRatio scala l'intero overlay al resize senza ricalcolare nulla, e l'accessibilità arriva gratis con role="img" + aria-label.

Canvas è stato scartato: non è serializzabile in SSR, richiede un redraw imperativo a ogni resize e rompe l'accessibilità (è un bitmap opaco senza albero semantico).

No. L'id del gradiente shimmer di ciascun overlay è namespacato per host: sk-shimmer-{uid}. Più host <Skeletonizer> sulla stessa pagina ricevono ognuno un gradiente univoco, quindi nessuna collisione in <defs>.

Sì. Un <svg> è semplice markup serializzabile, quindi le primitive manuali Skeleton* (che sono <svg> inline) vengono renderizzate dal server normalmente. L'overlay automatico viene iniettato lato client dopo l'idratazione — esattamente quando gira il resto del motore — quindi il render iniziale del server e del client coincidono e non c'è mismatch di idratazione. Vedi SSR.