Single Element #CSS Spinners
▻http://projects.lukehaas.me/css-loaders
Single Element #CSS Spinners
▻http://projects.lukehaas.me/css-loaders
Z63 | Vertical align anything with just 3 lines of #CSS | zerosixthree
►http://zerosixthree.se/vertical-align-anything-with-just-3-lines-of-css
The CSS property #transform is usally used for rotating and scaling elements, but with its #translateY function we can now vertically align elements. Usually this must be done with absolute positioning or setting line-heights, but these require you to either know the height of the element or only works on single-line text etc.
PrettyCSS - fidian.com
▻http://www.fidian.com/prettycss
This program is a JavaScript based #css pretty printing / beautification tool that also does structure validation. It can run in a browser (as seen below) or on a server with node.js or Rhino. You can tie into it so that your CSS is minified or is always in a readable format. If you add this to your SCM system as some sort of hook so that every time someone commits CSS to a repository, it can get automatically validated and massaged into the way you want it to look.
@nicod_ pour grunt je ne sais pas, mais oui j’ai joué avec et ça me permet de remplacer avantageusement le service en ligne que j’utilisais avant (▻http://procssor.com).
Seul problème, la version en ligne de commande ne permet pas pour l’instant d’utiliser un fichier de config perso, j’ai ouvert un ticket à ce sujet et on peut y trouve la config que j’utilise de mon côté :
Pour info, maintenant il est possible d’utiliser un fichier de conf perso pour prettycss en shell :)
prettycss -c /home/bb/.config/prettycss.conf --ignore-all vilain.css > mignon.css
Mon fichier de conf est dispo sur ce gist :
CSS3 Patterns Gallery
The Style Guide Guide
▻http://vinspee.me/style-guide-guide
Tags : #styleguide
Ah merci, ça me fait des bases intéressantes pour imaginer ma résolution du même besoin mais appliqué à SPIP spécifiquement (générer un guide à partir d’un dossier de snippets + des styles appliqués).
Je dis « spécifiquement » car des librairies à part, je trouve ça utile quand on est par exemple dans une « grosse » boite, et qu’il y a des compétences séparées, genre une personne qui fait spécialement le HTML/CSS mais sans l’intégration CMS. Quand on est moins de monde, moins de moyens, ou encore quand il y a des délais plus serrés, on fait fort souvent de l’intégration continue directement à partir de l’outil final (souvent SPIP en l’occurrence pour moi :D). Bon voilà, donc c’est peut-être un truc qui pourra être utile.
#intégration #web #html #css
#Assets #framework 2.0, like Bootstrap, but with semantic markup and WAI-ARIA
▻http://assets.cms.gov/resources/framework/2.0/Pages/index.html
“Assets 2.0 is a cross-browser compatible, 508 compliant and responsive framework that can be used to kick-start your web project.” Tags: Assets #CSS framework accessibilité #clavier
Il a l’air sympa celui la, c’est plus orienté accessibilité et pour permettre aux devs de manipuler les objets (par exemple pour les tableaux : ▻http://assets.cms.gov/resources/framework/2.0/Pages/datatables.html)
Y a même les #responsive datatable dont tu avais parlé :
▻http://assets.cms.gov/resources/framework/2.0/Pages/rwdtable.html
J’aime bien les champs date aussi ▻http://assets.cms.gov/resources/framework/2.0/Pages/maskedinput.html
avec UI + des —/—/---- dans les input :)
Ça me semble basé sur bootstrap 2 ou j’ai mal compris ? (voir les fichiers à inclure ▻http://assets.cms.gov/resources/framework/2.0/Pages/gettingstarted.html)
Et le code du site :
<div class="row-fluid">
<div class="span3">
<div class="span9">
</div>
Trianglify by qrohlf
▻http://qrohlf.com/trianglify
Trianglify is a #javascript library for generating colorful triangle meshes that can be used as SVG images and #CSS backgrounds.
Quelles mesures #CSS, pour quel usage ?
▻http://www.pompage.net/traduction/css-unites-et-usages
Confrontés au foisonnement des systèmes de mesure CSS, les développeurs web peuvent avoir du mal à comprendre quelles unités il faut utiliser dans leurs pages, et à quel moment. On peut être tenté de toujours utiliser les mêmes mesures, mais ce choix risque de limiter sérieusement l’aboutissement de vos designs. Je propose ci-dessous une liste de suggestions, mais non pas de règles absolues : libre à vous de vous en écarter si vous le jugez préférable.
Motion Ui #Design Principles — Beyond Kinetic
▻http://www.beyondkinetic.com/motion-ui-design-principles
This blog is a quick look at some simple Ui #motion_design principles. There isn’t too much documented about this area of mobile ui design and I thought there would be some value in expressing my views.
Sur la même thématique (via @iamvdo) :
▻http://fr.slideshare.net/dgeerts/the-animated-gui-lessons-from-disney
(cité dans ▻http://www.ui-transitions.com)
Font Size Idea: #px at the Root, #rem for Components, #em for Text Elements | #CSS-Tricks
▻http://css-tricks.com/rems-ems
Tags : em #font-size CSS rem px
Understanding #CSS #3D-Transforms | Pencil Scoop | #Web_Design & Development
▻http://www.pencilscoop.com/2014/04/understanding-css-3d-transforms
3D transforms can be a bit of a mind-boggling concept at first, particularly given that the HTML canvas (your screen) is a 2D space. While most of us understand the most commonly used 3dtransform - transform: translate3d(x, y, z), there are other values that can effect 3D rendering such as rotating, backface-visibibility, perspective and lots more.
Let’s take a look at better understanding the spectrum of css 3d transform properties.
Punaise, le mec il aurait pu écrire ses exemples en utilisant les standards... marre des démos qui marchent que sur chrome (alors que la majorité marchent sur les autres navigateurs (récents) aussi).
Pas mal, pour tester certaines interactions (perspective, preserve3D, backface visibility) : ▻http://thewebrocks.com/demos/3D-css-tester
Une #vidéo d’arrière-plan sur toute la page en HTML et #CSS
▻http://www.alsacreations.com/tuto/lire/1620-une-video-arriere-plan-sur-toute-la-page.html
Tags : vidéo #HTML5 #fond #background CSS
/CSS TAJ MAHAL/
/By: Jan Dennison @jannypie/
▻http://codepen.io/jannypie/pen/kbdDg?editors=110
#css
Preface — Magic of #CSS — Adam Schwartz
▻http://adamschwartz.co/magic-of-css/chapters/preface
CSS is a mess. We all love it, but it’s a mess. I liken it to English: there are a bunch of rules, and you can learn them. But sometimes you’re better off just trying shit and seeing what works and what doesn’t. Magic is a codification of what I’ve learned in that crazy process.
The material in this textbook is intermediate-to-advanced. It assumes an understanding of the CSS syntax, cascading and inheritence, and commonly used selectors. It also assumes you’ve had enough experience with CSS to have learned not to make these common mistakes anymore.
Scoped Media Query #Sass Mixin
▻https://github.com/filamentgroup/scoped-media-query
“An element query workaround. A Sass mixin for scoping #CSS styles to apply only within given selector/media query pairs.” Tags: Responsive Web Design (RWD) #Element_Queries Sass CSS #todo:formation:rwd
#IE-friendly mobile-first #CSS with #Sass 3.2
▻http://jakearchibald.github.io/sass-ie
Tags: IE #Mobile_first CSS Responsive Web Design (RWD) Sass
#WTF, #HTML and #CSS ?
▻http://wtfhtmlcss.com
Reasons HTML and CSS might make you say what the fuck. A curated list of commonly frustrating HTML and CSS quandaries, miscues, and dilemmas.
Suite de ▻http://seenthis.net/messages/238470#message238530
Je me suis limité à ►http://www.knacss.com
▻http://www.knacss.com/img/knacss-350.svg
KNACSS is a minimalist, responsive and extensible #CSS framework to kick-start any professional web project no matter its size.
Designed by #Alsacreations web agency and used on a daily basis in production, KNACSS relies on common best practices and experience on the topic, provides CSS reset, helpfull snippets, grids and layout tricks even on old browsers.
Leveling Up With #flexbox
▻http://zomigi.com/blog/leveling-up-with-flexbox
“Today I spoke at Smashing Conference in Oxford, England, on “Leveling Up With Flexbox.” The talk was based off my earlier flexbox presentation, but I focused less on the basic syntax, since I think most of us have already read at least a bit about that by now, and dove right into more code examples. I talked about how to actually put it to use in the real world—today. I demonstrated a bunch of practical ideas for how to use flexbox as progressive enhancement, adding it in bits and pieces on individual page components with simple fallbacks.” Tags: #CSS flexbox #présentation (...)
Drowning in Tools in the Web Development Industry
▻http://www.sitepoint.com/drowning-in-tools-web-development-industry
Since late July, I’ve curated a weekly newsletter focused on tools called Web Tools Weekly. Throughout each week, when going through my feeds (yes, RSS is alive and well) and doing various forms of other research, I’m constantly bookmarking new apps, scripts, #plugins, libraries, #CSS frameworks, productivity tools, testing tools, and more.
In fact, I could probably release that newsletter daily and I’d still have enough content. As of this writing, I have a categorized list of approximately 500 different apps, resources, scripts, libraries, plugins, etc. that I haven’t yet included in any issue. And let’s not forget about the 500+ tools that have made the cut in the first 30+ issues.
Tout à fait d’actualité en ce qui me concerne car je dois faire (humblement) un site et entre responsive, ajax, javascript, css, l’offre est pléthorique ... Foundation ou Bootstrap ? Et backbones, j’en ai besoin ? (a priori, non).
Bref, ça fait une semaine que j’essaye de comprendre dans toutes ces propositions lesquelles vont m’aider et lesquelles vont me noyer.
Dans les commentaires :
This was very helpful advice and encourages me to continue striving to make sure my basic HTML, CSS, and JavaScript skills are solid instead of chasing every new thing just because it’s new.
Ce doit être ce dont j’ai besoin ;-)
Organisation des SCSS.
Je cherche à mieux structurer mes dossiers de styles, maintenant que je suis définitivement en pré-processeur (et en SCSS), que j’essaye de découper au maximum en petits morceaux réutilisables, et que donc je suis censé avoir à la fois plein de fichiers modulaires, et d’autres propres au site en cours.
J’ai donc lu diverses ressources qui abordent le même problème.
D’abord, hors pré-processeur, en relisant le rangement de @tetue avec Daisy
▻http://romy.tetue.net/methode-daisy
En relisant aussi les trois proches méthodes de structuration des styles que sont OOCSS, Smacss et Atomic design. Une intro mêlant les trois en français ici :
▻http://www.24joursdeweb.fr/2013/le-design-atomique
Puis :
▻http://smacss.com/book
Et :
▻http://pattern-lab.info/about.html
Mais cela ne parle pas des dossiers et fichiers, donc enfin en cherchant des propositions de rangement réels :
Sur un des sites de la communauté Sass
▻http://thesassway.com/beginner/how-to-structure-a-sass-project
Par un mec qui a écrit un livre sur Sass
▻http://gist.io/4436524
Par le designer en chef de OneHub, sur Medium
▻https://medium.com/p/7fe19ab647fa
Avec tout cela, je n’ai pas encore choisi définitivement comment MOI je préfère ranger mes fichiers.
D’abord parce que je parle français et que tous mes collègues sont francophones, et que 99% de nos clients aussi. Donc pourquoi faire le mec à la mode en mettant de l’anglais partout ?
Inversement, le fait d’utiliser des mots que l’on trouve ailleurs, fait que les futurs lecteurs du code s’y retrouveront plus facilement. Et moi-même aussi, car lorsque je décide d’utiliser tel ou tel framework, je retrouve des termes similaires pour les dossiers, donc même tout seul ça aide.
De plus, une partie des termes vient aussi des langages utilisés, comme HTML5 par exemple. Donc peut-être mieux de ne pas mélanger.
(Par contre une idée : utiliser le français pour tous les trucs qui sont uniquement propre au site en cours (lorsque c’est un site fr bien sûr). Par exemple le nom des variables de couleurs, ou encore le noms des objets propres à ce site-là. Ainsi je distinguerai encore plus vite ce qui est commun, en anglais, de ce qui est propre au site, en français.)
Je suis intéressé par le découpage de Brad Frost, mais je trouve que les termes analogiques ne sont utiles que lorsqu’on explique le principe. Pour les vrais noms des dossiers ou fichiers de travail, je n’ai pas envie de mettre « atoms » ou « organisms », je trouve cela confus.
Les mots propres à un outil ou à une communauté précise me dérange un peu aussi. Par exemple le mot « partials » peut bien évidemment être utilisé autre part, mais il est surtout présent dans la communauté Sass car c’est le terme qui désigne les fichiers avec un « _ » devant (ceux qui ne sont pas compilés en CSS mais qui doivent uniquement être inclus).
Je n’ai donc pas trop envie d’utiliser ce mot non plus.
Pour l’instant, les premiers mots que j’ai retenu sont :
– frameworks/
pour les librairies externes, comme TinyTypo ou Bourbon
– sections/
ou zones/
(pas choisi encore mais « section » est déjà utilisé donc mieux) pour les styles propres à des zones précises (mais communes) des pages, comme header
, firstnav
, footer
, etc
– templates/
pour les styles qui seraient propres à des grands types de pages comme sommaire
, rubrique-galerie
– pages/
pour les styles propres à une page précise
Chaque morceau est censé être de plus en plus rarement utilisé, bien sûr !
Vous devriez avoir noté qu’il manque encore des choses. Car là-dedans je ne range pas encore les objets réutilisables, qui doivent forcément être avant « sections ». Ce sont les « organismes » dans le vocabulaires de Frost, qui ont une cohérence ensemble quelque soit la page et quelque soit la section dans laquelle on les insérera. Il faut un mot pour ça.
Peut-être patterns/
.
Il me manque aussi les choix graphiques généraux, pas dans une section particulière : c’est à dire en gros la surcharge de TinyTypo mais avec les couleurs, typos, tailles, etc, qui sont propres à ce site-là. Je ne sais pas encore vraiment pour ce point-là.
Dans mon vrai « theme.scss », j’aurais donc à peu près l’ordre d’importation :
– frameworks
– styles de base (personnalisation de tinytypo + ajouts)
– objets réutilisables
– styles de sections
– styles de templates
Il me reste aussi à définir si les gabarits ("layouts" en anglais) par défaut du site (pas ceux propres à un template), c’est-à-dire le placement sur les grilles des zones principales, doivent être définis dans chaque section (le section/header
défini son placement, le section/content
défini son placement, etc) ou bien plutôt dans un unique fichier ensemble. (Par contre les surcharges du layout par défaut seraient à priori bien dans templates/
.)
Si vous avez tout lu, vous êtes courageu⋅x⋅ses, mais il me fallait aplanir tout ça par écrit pour y voir plus clair. Ça peut vous aider, ou m’aider moi après commentaires.
Bisous. :)
#conception #design #HTML #CSS #SCSS #Sass #framework #structure #bonnes-pratiques #styleguide
Waow, bravo pour ce défrichage dans la jungle !
dès que j’ai du courage, promis, je re-teste !
Pour les libs/framework externes, j’utilise « vendors » comme beaucoup dans les développements côté serveur.
Pourquoi n’appliques-tu tout simplement pas le vocabulaire d’Atomic Design ? Par exemple, pourquoi nommer « patterns » les « organisms » ?
Pour « vendor(s) », je ne sais pas. Je n’aime vraiment pas ce terme. « Fournisseur(s) » en français. Ça fait très import-export. Je n’arrive pas à m’y faire… :D
Par ailleurs « framework » est un mot qu’on utilise désormais couramment dans plusieurs langues (en français nous n’avons pas de terme immédiat d’un seul mot pour ça), et donc je le trouve plus passe-partout, en disant bien ce qu’il veut dire.
Pour Atomic je l’ai expliqué plus haut : je trouve qu’utiliser des termes « par analogie » est super pour expliquer le concept. Mais pour le concret, les vrais dossiers et fichiers quotidiens, je ne trouve pas ça très intuitif. patterns
n’est qu’une idée, ça pourrait être modules
aussi… (mot multilingue en plus).
Je préfère en tout cas utiliser des termes qui ne sont pas en rapport avec un outil précis : ceux utilisés par Brad Frost sont uniquement utilisés par sa méthodologie. Ils ne sont pas compréhensibles « en eux-mêmes », sans explications en amont. Tu comprends ?
Ce n’est pas le premier post que je lis sur le rangement des fichiers SCSS : qu’a donc ce langage pour tant inciter à ranger ?
Ça me semble induire de l’arborescence, ce qui me semble quelque peu surdimensionné (mais pourquoi pas) pour ranger du CSS. Est-ce que ça ne complexifie pas inutilement ?
La seule raison qui me fait arborer des styles est motivée par l’humain, non par le besoin de ranger : ça permet, par exemple, d’isoler le code de base dans un « dossier sacré » intouchable, et de pouvoir facilement le désigner comme tel aux différents intervennant·e·s. Du coup, y’a 3 dossiers maximum , qui servent à ne pas se marcher dessus et à préserver la robustesse du projet. Dans ce cas, c’est au préprocesseur de ranger ensuite par logique d’héritage, par rôle/fonction dans le site.
D’un point de vue macro, j’utilise toujours le même découpage #Daisy, en 3 parties (qui peuvent être 3 dossiers, 3 feuilles ou 3 séries de feuilles, peu importe) :
1. Base CSS : base pour l’intégration. Cette première partie regroupe les trucs qui servent partout, dans chaque projet web.
2. Modules : interviennent ensuite les styles optionnels, généralement importés/imposés, associés à une fonctionnalité, un script ou un plugin.
3. Spécifique : si nécessaires, les styles spécifiques au projet, en dernier.
Merci en tout cas, pour le partage de ta réflexion et tes recherches.
D’abord une courte réponse à @tetue, puis là où j’en suis. :)
qu’a donc ce langage pour tant inciter à ranger ?
Pas spécialement ce langage, mais n’importe quel pré-processeur a sa fonction d’importation (mais qui importe dans une feuille unique au final). Et donc ça aide à découper en fichiers cohérents ne contenant qu’une seule fonctionnalité.
C’est comme pour le code fonctionnel : c’est plus facilement maintenable et lisible quand on a pas un fichier de centaines de lignes. Par exemple un fichier ne contenant que les styles des boutons et leurs variantes (gros boutons, petits boutons, différentes couleurs). Puis un fichier contenant uniquement les styles des commentaires et leur agencement. Etc.
Cela dépend bien entendu des équipes, mais je connais pas mal de gens qui préfèrent des petits fichiers cohérents (on sait qu’on trouvera tous les styles des boutons dans le fichier des boutons).
–----
En ce qui me concerne, voilà où j’en suis.
Pour les fichiers et dossiers
css/
\_ frameworks/
\_ modules/
\_ sections/
\_ templates/
\_ theme.scss + les trucs généraux (variables, layouts, …)
On notera que les noms de dossier que j’ai choisi sont utilisés aussi bien en anglais que dans les conversations francophones. De plus, le tri alphabétique correspond déjà à l’ordre d’importation de ce qu’ils contiennent : du plus général au plus particulier. Pratique !
Pour l’ordre d’importation dans la feuille principale
/**
* Variables et fonctions de base
*
* Ces imports ne génèrent aucun style CSS, ce sont des utilitaires
*/
@import "variables";
@import "bourbon";
@import "grid-settings"; // config de Neat, après Bourbon car utilise em()
@import "neat";
@import "omega-reset"; // complément à Neat pour le responsive
@import layoutgala // mixins LayoutGala, si on en a besoin
@import "hashgrid"; // mixin de visualisation de la grille pour aider
/**
* Base CSS
*
* Styles de premier niveau pour les éléments de base, la plupart sans classes
*/
@import "tinytypo"; // Typographie de base, pour n'importe quel site
@import "typo"; // Choix graphiques de base propres à ce site (couleurs de base, tailles, polices, etc)
/**
* Gestion des gabarits
*
* Placement des blocs principaux, colonnes, etc
*/
@import "layouts";
/**
* Modules
*
* Ce sont des modèles cohérents, réutilisables quelque soit l'endroit où on les place
*/
@import "modules/buttons"; // Tous les boutons et leurs variantes
@import "modules/forms"; // Les formulaires
@import "modules/lists"; // Les différentes listes du site
@import "modules/illustrations"; // Les images et légendes
@import "modules/comments" // Les commentaires
// ...
/**
* Sections
*
* Styles spécifiques à des morceaux de pages, mais dans tout le site
*/
@import "sections/access"; // Accès rapide
@import "sections/header"; // Entête du site
@import "sections/firstnav"; // Navigation principale
@import "sections/footer"; // Pied de page
// ...
/**
* Templates
*
* Styles spécifiques à des pages ou groupes de pages
*/
@import "templates/sommaire"; // Styles propres à la page d'accueil
@import "templates/rubrique-agenda"; // Pour l'agenda
// ...
On est d’accord sur l’approche globale, du général au particulier à la Daisy : 1. base puis 2. modules puis 3. spécifique.
Par contre, le découpage de ta dernière partie par section et templates, j’en suis revenue : d’expérience, ça tient mal sur la durée, parce qu’on ré-organise les pages, les renomme, les recompose, etc. C’est vraiment une mauvaise idée.
Je découpe cette dernière partie par profil d’intervenants (qu’ils soient potentiels ou réels, peu importe), ou plutôt par type d’intervention, parce que ça correspond mieux à la réalité de la vie d’un projet. Parce qu’un projet ça vit, ça passe entre plusieurs mains, de talents divers, qu’on le veuille ou non, et c’est seulement en prévoyant cela qu’on s’assure de la robustesse et de la pérennité d’une intégration. Concrètement, ça donne qqch comme ça, dans cet ordre :
– theme (habillage graphique général)
– skin (si besoin de « skin » par exemple saisonnières)
– color (si besoin de variantes de couleurs, par exemple par rubrique)
– debug (feuille de débug, désactivable)
– custom (personnalisations, yes, toutes ; livré par le développeur front, interne ou externe)
– team (surcharges de l’équipe exploitant le site, en cours de vie)
– temp (surcharges à l’arrache, par les autres mains passant sur le projet, en CSS à la truelle, à vocation temporaire)
Cela permet de passer des consignes claires :
– si t’as besoin de modifier le look (t’as un miminum de sensibilité graphique et de connaissance en variables), va dans « theme », sinon si t’as juste besoin de rustiner un truc, vas dans « team » (et touche pas au reste, auquel t’as pas accès d’ailleurs, comme ça on casse pas le site)
– pas besoin d’avoir la connaissance de l’ensemble du projet, de comprendre quels sont les gabarits, pour intervenir
– d’expérience, la démultiplication de « petits fichiers cohérents » ne doit pas déborder l’étape de fabrication et être imperceptible des suivants, sinon ça rend fou le webmestre en bout de chaîne qui, peu rompu aux pré-processeur &co, préfère qu’on lui indique un seul fichier où poser ses rustines CSS.
En suivant un lien de @nhoizey :
▻http://seenthis.net/messages/384093
je remarque que Hugo Giraudel a décrit sa méthode, qui a quasiment le même principe découpage :
►http://sass-guidelin.es/#the-7-1-pattern
Les termes ne sont pas les mêmes (components VS modules, etc) et lui fait encore plus de dossiers : notamment pour y mettre ce que moi j’ai toujours en bazar à la racine à côté de mon fichier principal, ce qui est un point que je dois encore améliorer. Mais sinon les principes sont vraiment les mêmes.
Comme je dis dans l’autre seen, je préfère quand même mon nommage, car
1) chaque terme (frameworks, modules, sections, templates) est utilisé aussi bien en anglais qu’en français, ce qui en fait un découpage passe-partout ;
2) l’ordre alphabétique des dossiers suit scrupuleusement l’ordre d’importation, donc quelque soit où l’on travaille (dans l’explorateur de fichiers, dans l’IDE, etc) on sait encore plus facilement où l’on se trouve, tout est toujours affiché dans le même ordre.
jxnblk/geomicons-open
▻https://github.com/jxnblk/geomicons-open
Open Source Icons for the Web
#CSS polyfills from the future | GSS
▻http://gridstylesheets.org
J’ai rien compris mais ça a l’air super…
GSS reimagines CSS layout & replaces the browser’s layout engine with one that harnesses the Cassowary Constraint Solver — the same algorithm Apple uses to compute native layout.
Une application en ligne pour construire sa police d’icônes, super simple.
Présentation :
►http://icomoon.io
et l’application :
▻http://icomoon.io/app
– On peut choisir parmi plusieurs sets de pictos, dont en licence libre, en tout des milliers de pictos possibles.
– Puis on sélectionne lesquelles on veut (on peut donc mélanger des icônes venant de plusieurs sources).
– On peut aussi importer ses propres images !
– On assigne ensuite chaque icône à un caractère unicode, on peut donc même choisir le vrai lorsqu’il existe (ce qui est souvent le cas).
– Hop on télécharge un ZIP avec tout, y compris la super CSS qui va permettre d’insérer l’icône uniquement avec class="icon-truc".
Encore plus fou :
– On peut créer un compte en ligne et sauver ses projets de font, pour les retrouver plus tard sans tout refaire à zéro.
– Et on peut même télécharger les projets en JSON sans aucune inscription, et les réimporter ensuite sans compte en ligne.
#icône #icon #picto #webapp #font #développement #web #intégration #accessibilité #responsive #CSS