28172 sujets

CSS et mise en forme, CSS3

[Résolu] Importer un SVG dans un pseudo-élément via le HTML

EDIT : j'ai modifié le titre du sujet pour que ma question soit plus claire et qu'elle ne vous embarque pas sur une fausse piste. Je reformule donc :

En 2023, peut-on, dans un pseudo-élément, importer autre chose qu'un caractère unicode à partir du HTML ? Je cherche en particulier à injecter des SVG en sprites.

____________________________________________________________

Bonjour,

Pour la réalisation d'un switch j'ai vu que, désormais, on pouvait se passer de la solution de contournement "masquer les inputs et styler les labels", comme je fais encore ici par exemple : Toggle Switches.

Je me suis donc remis à l'ouvrage, mais je coince toujours au même endroit qu'il y a quelques années en arrière, c'est lorsque l'on veut personnaliser les symboles avec autre chose que des caractères unicodes. J'ai tenté d'injecter des SVG via des data attributes ou des variables CSS, mais la solution est généralement dégeu et surtout difficile à styler (pour les couleurs par exemple). Vous avez des pistes pour 2023 ?

Voilà où j'en suis pour l'instant (en partant sur du propre) : CodePen.

Y'a pas d'urgence, ma première solution fonctionne toujours très bien, c'est juste pour ma recherche et ma veille techno.
Modifié par Olivier C (13 Nov 2023 - 07:53)
Modérateur
Bonjour,

C'est pénible ces exemples en pug, stylus et autres langages hétéroclites. Tu perds en route 90% de gens qui pourraient répondre à tes questions.

Bien sûr on peut afficher les versions compilées, puis changer ton "pug" et "stylus" en "none" et "none". Et comme codepen me semble buguée, il faut en plus auparavant pour le html faire un copier du code html compilée pour le remettre dans la fenêtre html une fois qu'on a changé le "pug" en "none". Et évidemment, il faut refaire ça à chaque fois qu'on revient sur l'exemple codepen.

Brrrr !

Amicalement,
Y'a vraiment des gens qui perdent du temps à taper des chevrons, des doubles quotes et tout le b*** dans la vraie vie ? Même avec l'autocomplétion... les pauvres...

Non, je rigole, je comprends. Voici une version plus safe pour tout le monde : ReCodePen.
Modérateur
parsimonhi a écrit :
Bonjour,

C'est pénible ces exemples en pug, stylus et autres langages hétéroclites. Tu perds en route 90% de gens qui pourraient répondre à tes questions.

Bien sûr on peut afficher les versions compilées, puis changer ton "pug" et "stylus" en "none" et "none". Et comme codepen me semble buguée, il faut en plus auparavant pour le html faire un copier du code html compilée pour le remettre dans la fenêtre html une fois qu'on a changé le "pug" en "none". Et évidemment, il faut refaire ça à chaque fois qu'on revient sur l'exemple codepen.

Brrrr !

Amicalement,


+100000.....

@Olivier C : utilise du code standard. De mon côté, je peux te confirmer que tu es le seul que je connaisse à utiliser le pug, stylus ou autres trucs exotiques. Dans le milieu pro, je n'ai jamais vu ce type d'outil. N'est ce pas un truc venant du Ruby ?

Tu t'embêtes trop avec les data-quelque-chose. Tu n'as pas besoin de ça. input:before ou :after, il me semble que ce soit casse-gueule.

Que ce soit avec cette syntaxe (je suis adepte de celle-ci pour certains types de projets) : 

<div class="input checkbox">
    <label>
        <input type="checkbox" class="yes-no" name="choix[]" value="bleu">
        <span>bleu</span>
    </label>
</div>

ou celle là: 

<div class="input checkbox">
    <input type="checkbox" class="yes-no" id="choix-bleu" name="choix[]" value="bleu">
    <label for="choix-bleu">bleu</label>
</div>


tu fais ceci (petite piste):
exemple 1(plus intéressant sur beaucoup de point. exemple : placement message erreur champ):

.yes-no + span:before{
    content: 'no';
    /* etc. */
}
.yes-no:checked + span:before{
    content: 'yes';
    /* etc. */
}

exemple 2 (plus léger, donc plus simple à lire)

.yes-no + label:before{
    content: 'no';
    /* etc. */
}
.yes-no:checked + label:before{
    content: 'yes';
    /* etc. */
}


Tu remarqueras que j'utilise les class input/checkbox. Pour mieux définir mes parents, ce sera : input/checkbox/radio/textarea/select/text/email/phone/date/submit/etc.
exemple : 

<div class="input radio">
<div class="input text">
<div class="input select">
<div class="input submit">

Modifié par niuxe (13 Nov 2023 - 00:05)
Merci Niuxe,

Mais toutes ces techniques je les maîtrise déjà. Je les ai utilisé longtemps d'ailleurs, avant de passer à des sprites SVG. En fait je n'aurais pas dû parler des switchs qui noient ma vraie question :

En 2023, peut-on, dans un pseudo-élément, importer autre chose qu'un caractère unicode à partir du HTML ? Je cherche en particulier à injecter des SVG en sprites.

Je vais changer le titre de ce topic pour refléter cela.

______
PS : des SVG injectés directement via le CSS, ça je sais faire :
input[type=month] {
    background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='%23777'><path d='M19 3h-1V1h-2v2H8V1H6v2H5c-1.11 0-1.99.9-1.99 2L3 19c0 1.1.89 2 2 2h14c1.1 0 2-.9 2-2V5c0-1.1-.9-2-2-2zm0 16H5V8h14v11zM7 10h5v5H7z'/></svg>");
}

Mais ce n'est pas ce que je veux ici : je veux que ce soit le HTML lui-même qui permette de personnaliser l'input. Et via une variable CSS ce n'est pas terrible car l'image ainsi importée ne sera pas modifiable (que ce soit en `content` ou en `background-image`), pour ses couleurs par exemple.
Modifié par Olivier C (13 Nov 2023 - 07:49)
Modérateur
Au temps pour moi.

Mais au fait, pourquoi ne pas directement un svg dans le node ? D'un point de vue sémantique, il me semble que ce ne soit pas dégueu. D'ailleurs, en faisant un webcomponent, tu auras un bien meilleur résultat Smiley cligne . Le SVG avec le currentColor, ça aide pas mal.

Soit, tu reprends le comportement d'un checkbox/radio/etc. (attention, ça peut être casse-gueule), soit tu fais un cache-misère (la technique décrite plus haut). J'en conviens que la dernière technique ne soit pas la meilleure, mais ce n'est pas si dégueu que cela.
Modifié par niuxe (13 Nov 2023 - 12:37)
Un petit retour : au final j'ai gardé deux solutions, la solution via des caractères récupérés via data-* (ma toute première solution que j'avais abandonné depuis un bail) et une solution avec des SVG (que j'ai déjà utilisé mais révisé). Dans mon CSS la dernière solution est une customisation de la première.

Dans les deux cas le changement majeur est que je ne cache plus l'input au profit du label, solution largement utilisé jusqu'alors mais nécessaire en raison du support des anciens navigateurs. J'en ai aussi profité pour revoir mes checkboxes et radios personnalisés basés sur le même concept.

Un article pour comprendre de quoi je parle : One last time: custom styling radio buttons and checkboxes

Maintenant je m'appuie vraiment sur les inputs sans les cacher, ce qui simplifie (un peu) le code et surtout rend plus souple l'utilisation des labels qui sont désormais désolidarisables de l'ensemble.

Une démo en ligne : Checkboxes, Radios Buttons & Toggle Switches.
Prévenir un modérateur
Répondre au sujet
Aller à