Monthmai 2017

[jQuery] Les méthodes Detach et Attach

Source: Detach / Attach en jQuery.

[RBS Change 3.6.x] Détecter un choix utilisateur via l’élément HTML Select/Option avec jQuery

Cas du bloc Switchlanguage dans Change 3.6.x

Objectif: au choix de la langue via l’élément <select />, on redirige vers la page traduite.

Côté template, on boucle sur les langues disponibles. On stocke l’URL de la page de destination via l’attribut value de l’élément option.

En jQuery, on détecte un choix d’option via l’élément HTML <select />, on récupère la valeur de l’attribut value (l’URL de la page de destination) et on lance la redirection.

[jQuery] Un mega-menu en dropdown en quelques lignes de code

Astuce rarement (jamais?) aperçue dans les différents plugins que j’ai pu utiliser jusqu’à présent: au hover sur un élément du niveau principal, on supprime la classe .hidden sur le sous-menu correspondant. Pour détecter que le curseur de la souris sors du sous-menu, on place une div à 100% en largeur et en hauteur sous le menu via z-index. Ensuite, on ne se pose pas de question: à partir du moment où le curseur de la souris survole cette div, on masque tous les sous-menus.

[Gulp][SASS] Exploiter l’option includePaths de gulp-sass pour définir, en cas de surcharges, un ordre de priorité des chemins vers lequels Gulp ira regarder quand il rencontrera un @import

(Ma question) gulp-sass includePaths parameter and import of partial files declarations that are not in the main.scss issue sur Stack Overflow.


Problème: I’m using gulp-sass and would like to define a load_path so that I don’t have to have really long @import rules voor bower dependencies e.g..

…à la place de:

Quel serait le meilleur moyen pour parvenir à ce résultat en utilisant gulp-sass?

Exemple d’utilisation de l’option includePaths de gulp-sass avec les sources SCSS de Foundation 6 for Sites

ATTENTION: gulp-sass semble ne pas digérer le globbing dans les chemins.

gulpconf.json

  • config.paths.styles.src: le chemin vers vos SCSS custom
  • config.paths.styles.srcIncludePaths: dans mon exemple ci-dessous, on répète le chemin vers les SCSS custom, puis on déclare le chemin vers les surcharges de SCSS relatives aux sources de Foundation ("src/style/vendor-override/foundation-sites/scss/") puis pour finir on déclare le chemin vers les sources out-of-the-box de Foundation qui seront utilisées si Gulp ne trouve aucune surcharge (les surcharges doivent respecter l’arborescence, les noms des dossiers et des fichiers de l’original pour être prises en compte!).

gulp-sass ne supportant pas le globbing dans les chemins, il faudra déclarer des chemins très précis vers vos vendors et vos vendors-override ici. Le dossier vendors-override devra toujours respecter la même arborescence que le dossier vendor pour que l’héritage fonctionne.

gulpfile.js

main.scss

Cette partie de ma main.scss comporte un copier/coller du contenu du fichier foundation.scss qui met en place les bases du framework côté SCSS.

Je n’ai rien modifié mise à part l’ajout de mon propre fichier settings :

Gulp va d’abord chercher les fichiers à importer dans src/style/ (il n’y trouvera rien pour ce qui est de Foundation) avant de se rabattre sur src/style/vendor-override/foundation-sites/scss/, puis sur src/vendor/foundation-sites/scss/.


  • sass-include-paths – Generates include paths for node-sass for packages from popular package managers like npm, bower, ruby gem, ruby bundler.
  • What does Gulp’s includePaths do?

    The SASS compiler uses each path in loadPaths when resolving SASS @imports.

    Note that the compiler resolves each @import by considering each path in loadPaths from left-to-right (similar to $PATH in a UNIX environment). An example scenario could be:

    There was no _x.scss file in styles/i, so it moved on to look inside styles/ii. Eventually it found an _x.scss file in styles/iii and finished the lookup. It looks at each folder in loadPaths starting from the first element in the array and moving right. After attempting all paths, if we can’t find the file, then we declare that this @import statement is invalid.

    Load paths is useful if you have a external library (like bournon/neat). The external library is large and will use lots of @import statements. However they won’t match your project folder structure and so won’t resolve. However, you can add an extra folders to the loadPaths so that the @imports inside the external library do resolve.

  • gulp-sass work around for load_path support?

    After struggling with this myself I found a option in gulp-sass :

    Example:

  • Import and globbing in SASS

[Foundation 6] Réinitialiser les styles par défaut pour l’élément HTML de formulaire Input

Source: Cleanest way to customize input[type=’text’] styles, codewise.

Depuis quelques semaines (et deux projets en cours de production), je décortique avec grand intérêt le framework front-end responsive Foundation 6 for sites créé et maintenu par Zurb. J’utilise Bootstrap 3 depuis sa première release stable (et Bootstrap 2 avant ça). Mais Bootstrap 4 étant encore en version Alpha j’ai décidé, pour voir, de me tourner vers une solution que je considère comme étant son principal challenger (la première version stable de Foundation 6 ayant vu le jour il y a plus d’un an).

Les possibilités offertes par Foundation 6 en terme d’habillage des champs de formulaire

Dans Foundation 6, les styles de l’ensemble des champs de saisie textuelle des formulaires (text, password, date, datetime, datetime-local, month, week, email, number, search, tel, time, url, color mais aussi l’élément HTML textarea) sont générés à partir d’une fonction text-inputs.

Cette fonction est déclarée dans le fichier /scss/util/_selector.scss du framework et se présente comme ceci:

C’est ensuite à l’aide d’un mixin foundation-form-text déclaré dans le fichier /scss/forms/_text.scss du framework que toute la batterie de styles par défaut pour l’élément input, l’ensemble de ses itérations
et l’élément textarea sont générés. Ce mixin se présente comme ceci (extrait) :

Le code CSS qui en résulte ressemble à ceci (extrait) :

Annuler les styles par défaut sur une sélection d’éléments

A ce stade, nous pourrions avoir besoin d’annuler les styles par défaut sur une sélection d’éléments pour repartir from-scratch (le bon vieux concept de reset CSS) et habiller un ou plusieurs champs de notre charte qui se démarquent visuellement des standards (un champ « Recherche » dans le bandeau de votre site ou un champ d’inscription à la « Newsletter » en pied de page par exemple; cette contrainte se présente quasi systématiquement).

Pour annuler les styles standards pour l’élément de formulaire input, nul besoin d’écrire un reset. Il faut surcharger le mixin foundation-form-text en passant en paramètre $modifier une pseudo-classe :not() à laquelle on attribuerait une classe générique, mais au libellé suffisamment parlant (par exemple, .is-unstyled (extrait):

La sortie CSS sera alors la suivante (extrait):

Désormais, un <input type="text" class="is-unstyled" /> ne sera plus affecté par les styles standard de Foundation 6. Pas besoin d’alourdir son code CSS avec quantité de styles reset pour annuler les déclarations par défaut. On peut se concentrer sur notre habillage custom.

Petit conseil: n’utilisez cette classe .is-unstyled que pour signifier, dans votre code HTML, quels éléments input ne doivent pas hériter des styles standards de Foundation 6. Pour les styler différemment, ajoutez une classe supplémentaire. Exemple:

Pour finir, sachez que vous pouvez faire appel à la fonction text-inputs à (quasiment) n’importe quel endroit dans votre code SCSS pour déclarer des styles spécifiques pour un élément donné ou toute une batterie d’éléments à la fois.

Quid des possibilités offertes par Bootstrap 4 en terme d’habillage des champs de formulaire?

De prime abord, on peut trouver ça déroutant que les styles soient appliqués à des attributs d’éléments plutôt que sur les éléments eux-mêmes via des classes, surtout si on est habitué à la logique Bootstrap 3 ou 4 et à ses classes .form-group et .form-control à appliquer sur des <div> englobantes ou sur les éléments eux-mêmes. Les styles Foundation 6 habillent d’office l’ensemble des champs de formulaires et c’est embêtant quand on veut s’affranchir de la patte graphique « Foundation » pour afficher certains formulaires.

Mais dans la pratique et avec les contraintes du terrain, la décision s’avère extrêmement pertinente (surcharge de toute la batterie de champs de formulaires d’un coup !).

Il faut le reconnaître, les formulaires sont c$%!§£s à habiller. J’ai voulu faire un test très simple: j’ai récupéré le code HTML d’un formulaire sur un site réalisé avec Drupal 7 (donc n’intégrant ni Bootstrap, ni Foundation pour que la structure HTML reste totalement neutre) et le module Webform. J’ai ensuite appliqué tour à tour la CSS sortie-de-la-boite de Bootstrap 4 et de Foundation 6 sans modifier de code ni HTML, ni CSS.

N’hésitez pas à agrandir/réduire la fenêtre en largeur pour tester l’aspect Responsive.

Avec Foundation 6, la mise en page est propre. Les champs sont habillés de manière minimaliste et le tout est parfaitement Responsive. Si votre client ne souhaite pas investir trop d’argent dans les formulaires, vous n’avez quasiment aucun travail à faire (minus peut-être les boutons à habiller) sur ce point pour obtenir un affichage convenable.

Avec Bootstrap 4, rien n’est habillé. Rien n’est Responsive. Et pour cause, les classes .form-group et autre .form-control doivent être rajoutées dans le code HTML pour obtenir un résultat (on peut aussi passer par SASS pour faire pointer les styles des classes Bootstrap sur les classes déjà en place). Au travail les développeurs front-end!!

Conclusion

A partir du moment où on décide d’aborder Foundation 6, on ne peut échapper à la comparaison avec Bootstrap 4. Chaque fois que j’en parle autour de moi, mes interlocuteurs veulent savoir si c’est mieux.

Comme je le disais en introduction, j’ai utilisé Bootstrap pendant des années. J’en connais ses points forts et ses points faibles et force est de constater que ces derniers n’ont pas été gommés avec l’arrivée de la version 4. Et l’habillage des formulaires ne reste qu’un tout petit exemple. Essayez de passer d’un menu accordéon en vue Mobile à un menu horizontal déroulant en vue Desktop… Le markup HTML est toujours (passage de la version 3 à la 4) différent d’un composant à l’autre, toujours pas de prise en charge des mediaqueries via JS, toujours pas de méthode .destroy() selon les cas.

En revanche, on sent dans la logique de fonctionnement et d’articulation du code de Foundation 6 que ses concepteurs sont des développeurs front-end chevronnés. Le framework est conçu pour être facile à utiliser et à étendre. Ses composants sont étudiés pour répondre aux contraintes quotidiennes du développeur. Avec les composants de navigation Responsive inclus, passer d’un menu accordéon en vue Mobile à un menu horizontal déroulant en vue Desktop se fait avec des classes et des data-attributes à ajouter au bon endroit dans le code HTML. Même pas besoin d’écrire de JS! Et on voit avec l’exemple donné dans ce billet que le code natif est pensé pour s’adapter immédiatement à l’environnement dans lequel il est parachuté.

Je ne peux que vous motiver à tenter de produire un site avec Foundation 6. Vous m’en direz des nouvelles 😉



Hello,
this is not an issue, but more of a concern about how to make the best out of Foundation 6 out-of-the-box SCSS components for custom website design.
So, I hope some skilled Foundation users will read this and share their opinions. 🙂

I’ve found some of the mixins to either:

  • include too much CSS properties for custom needs (core and skin properties are often merged within a same mixin),
  • prevent developer to custom-skin HTML elements (with skin values being forced rather than being included as mixin parameters).

As an example, here’s the dropdown-container mixin that includes both core and skin CSS properties :

Let’s assume I have 10 elements on my website that would use the dropdown component. 9 of them would have the same design. I can set the $dropdown- variables in the _dropdown.scss file to my regular needs.

But what if I want to take profit of the dropdown component for 1 specific element, but don’t want to show a border or need custom padding compared to the regular dropdown ?
Solutions I came up with include:

1. Make use of the regular mixin and override skin properties

(I guess I could use a Gulp plugin to remove duplicated properties within the same declaration… => Gulp clean-css with removeDuplicateRules option. Or CSS nano with discardDuplicates option).

Edit: even with a good Gulp CSS cleaning plugin, I can see a couple of issues doing that way :

  • You’ll still need to reset each and every property included in the mixin and that you don’t want to use :

2. (heavier and not so good idea IMO) Split standard mixin in 2.

3. Creating an SCSS placeholder that includes mixin core properties.

Third solution is the one I prefer so far. I might dig for a Gulp plugin that removes duplicate properties and first solution might become my favourite in the end.
What would you do?

Thanks.

[SASS] Accéder à un élément contenu dans une map (tableau ou liste de variables)

Sources:

Générer une Map SASS

Comment récupérer une valeur qui se trouve à l’intérieur de notre Map?

…sera compilé en :

Je veux accéder à « pony »:

Protégé : [Gulp-flow Change 3.6.x] Exploiter une ressource vendor dans un thème

Cette publication est protégée par un mot de passe. Pour la voir, veuillez saisir votre mot de passe ci-dessous :

[Polices d’icônes] Ressources en ligne, astuces, bonnes pratiques

Bibliothèques gratuites

Outils et techniques pour extraire des icônes d’une police

Requiert la source au format SVG.

Outils et techniques pour créer et/ou éditer une police d’icônes

Polices d’icônes déjà splitées en sources SVG

1 icône = 1 fichier. Pas forcément intéressant lorsqu’on sait utiliser font blast (voir plus haut).

© 2020 devfrontend.info

Theme by Anders NorénUp ↑