Non classé – DesireLabs

Créer un menu off-canvas entièrement en css

Franck — Thu, 22 Dec 2016 13:07:20 +0000

Ce que j’aime par dessus tout avec CSS3, c’est cette capacité qu’il offre de nous affranchir de javascript pour tout ce qui touche aux animations. Après m’être penché sur une solution de menus accordéons en full css (dont je parlerai bientôt), je vous propose une version revisitée du menu « off canvas » via css3, sans javascript.

See the Pen Pure css off-canvas menu by Franck (@neovea) on CodePen.

Cette solution m’a été inspirée par csswizardry et ses filtres de contenu en full css grâce au sélecteur « :target ». Je pense que les possibilités offertes par ce sélecteur sont nombreuses, et je me suis dit que j’en testerais bien une.

Pour commencer, que propose ce sélecteur au juste ? D’après Mozilla Developer Network :

La pseudo-classe:target permet de cibler l’unique élément (s’il existe) dont l’attribut id correspond au fragment d’identifiant de l’URI du document.

En clair, cela signifie que je peux cibler un élément identifié comme c’est le cas avec une ancre. Je clique sur un lien qui pointe vers une ancre (exemple href= »#mon-id »), je serai à même d’appliquer à l’élément ciblé par cette ancre un style… ou un comportement dans notre cas

Je tiens à préciser que j’utilise massivement sass dans cet article. Je met le code complet à la fin de l’article, avec la feuille de style css compilée

Démonstration

Considérons le code qui suit pour la partie html :




	
	Pure off canvas css menu
	
	
	


	
  
    
      Lorem.
      Suscipit!
      Sapiente.

J’ai créé un menu portant l’id « menu » ainsi qu’un double bouton permettant de l’ouvrir et le fermer.

Remarquez au passage ce qui suit : Dans la balise portant la classe « button-group » nous avons en réalité 2 liens. Cet artifice permettra par la suite d’avoir un bouton pour fermer le menu. Je vous donne plus de détails dans la partie consacrée à css.
autre chose, le menu porte un id, car pour designer son comportement, nous allons faire appel au pseudo élément :target, ce qui en simplifiant, revient à créer une ancre.

A présent que notre structure html est prête, passons à la partie amusante : la css

Voici comment on va procéder : lorsque le bouton sera cliqué, l’élément ciblé via son attribut href sera sélectionné. A ce moment, le menu s’ouvrira, et par la même occasion, le second bouton passera en premier plan de manière à nous permettre de le rendre cliquable et de refermer le menu.

Commençons par opérer un « reset » sur notre page :

* {
  box-sizing: border-box;
}

html, body {
  margin: 0;
}

Ainsi nous aurons bien un menu bord à bord avec notre fenêtre. Ajoutons à cela le design de notre menu :

#menu {
  position: absolute;
  height: 100vh;
  width: 300px;
  margin: 0;
  background-color: #000;
  transform: translateX(-100%); /* Rend le menu invisible */
  a {
    color:#fff;
    font-family: Cutive Mono;
    text-decoration: none;
  }
}

Rien d’exotique ici, nous avons seulement placé le tout en position absolue, stipulé une translation négative de 100% de la largeur de l’élément afin de masquer le menu.

Passons aux boutons :

.button-group{
  position: absolute;
  width: 65px;
  height: 65px;
  top: 0;
  left: 0;
  margin: 8px; /* histoire de ne pas avoir le bouton collé */
}

.menu-button {
  width: 100%;
  height: 100%;
  position: absolute;
  display: flex;
  justify-content: center;
  align-items: center;
  background-color: #000;
  text-align: center;
  color: #fff; 
  border-radius: 50%;
  left: 0;
  top: 0;
  span {
    display: block;
    width: 100%;
    height: 20px;
    position: absolute;

    .fa-times {
      display: none;
    }
  }
  
  &.off {
    z-index: -1;
  }
}

Ce qui est important ici est le positionnement absolu de notre groupe de boutons, mais aussi et surtout ce dont je parlais plus tôt : le second bouton est placé derrière le premier grâce à un z-index négatif. Ainsi, lorsque nous cliquerons la première fois, nous ne risquerons pas de cibler le mauvais bouton.

Désormais, tout est près pour accueillir notre comportement. Il suffit d’utiliser le sélecteur css :target sur le menu pour jouer notre astuce.

#menu:target {
  transform: translateX(0);
  +.button-group {
    left: 300px;
    
    .menu-button:first-child {
      span {
        .fa-times {
          display: block;
        }
        .fa-bars {
          display: none;
        }
      }
    }
    
    .off {
      z-index: 0;
      background-color: transparent;
    }
  }
}

On a donc ajouté notre sélecteur qui dit que s’il est ciblé, notre menu opérera une translation vers la droite. On en profite au passage pour faire passer notre second bouton – celui qui ferme – au premier plan, en redéfinissant sont z-index à 0. Pour le cibler, rien de plus simple : notre groupe de boutons se trouve exactement après le menu dans le DOM. Du coup, on peut agir sur ses enfants simplement en utilisant le sélecteur +. On re-style aussi ce dernier pour se positionner à 300px du bord gauche du document.

Pas encore satisfait ? Allons un peu plus loin en tirant parti des facultés de css en termes d’animation et rendons tout cela un peu plus touchy’

Et puisque nous faisons du scss, créons une petite @mixin qui se chargera de créer nos transitions :

* {
  box-sizing: border-box;
}

html, body {
  margin: 0;
}

@mixin animation() {  
  transition-duration: 0.5s;
  transition-timing-function: cubic-bezier(0.65, 0.05, 0.36, 1);
}

.button-group{
  position: absolute;
  width: 65px;
  height: 65px;
  top: 0;
  left: 0;
  margin: 8px; /* just to give some space*/
  @include animation();
}

.menu-button {
  width: 100%;
  height: 100%;
  position: absolute;
  display: flex;
  justify-content: center;
  align-items: center;
  background-color: #000;
  text-align: center;
  color: #fff; 
  border-radius: 50%;
  left: 0;
  top: 0;
  span {
    display: block;
    width: 100%;
    height: 20px;
    position: absolute;

    .fa-times {
      display: none;
    }
  }
  
  &.off {
    z-index: -1;
  }
}

#menu {
  position: absolute;
  height: 100vh;
  width: 300px;
  margin: 0;
  background-color: #000;
  transform: translateX(-100%);
  a {
    color:#fff;
    font-family: Cutive Mono;
    text-decoration: none;
  }
  @include animation();
  
  &:target {
    transform: translateX(0);
    +.button-group {
      left: 300px;
      
      .menu-button:first-child {
        span {
          .fa-times {
            display: block;
          }
          .fa-bars {
            display: none;
          }
        }
      }
      
      .off {
        z-index: 0;
        background-color: transparent;
      }
    }
  }
}

Je trouve cette expérimentation – à défaut d’être respectueuse des règles d’accessibilité – très intéressante dans la mesure où elle remet en question l’usage de javascript pour des usages d’ordre fonctionnel ou esthétique. Ceci tend à rendre la frontière entre css et javascript un peu plus floue en rendant css auto suffisant lors de traitements fonctionnels un tantinet complexes.

En revanche, attention ! rechargez votre page et l’état du menu ne sera pas réinitialisé. En effet étant donné que nous utilisons une ancre, celle ci reste dans la barre d’adresse. De plus, l’état de votre menu est de fait enregistré dans votre historique.

Télécharger les sources

L’article Créer un menu off-canvas entièrement en css est apparu en premier sur DesireLabs.

Ajouter enclosure dans le flux RSS de WordPress pour les newsletters MailChimp

Franck — Fri, 29 Jul 2016 11:50:33 +0000

Si comme moi vous utilisez mailchimp, vous avez surement dû trouver rageant le fait de ne pas avoir la main sur les images par votre flux RSS WordPress dans votre newsletter. Qu’à celà ne tienne, voici un petit script à insérer dans le fichier functions.php de votre thème (via duogeekdev – GitHub Gist)

Merci à Sushi l’auteur du script

L’article Ajouter enclosure dans le flux RSS de WordPress pour les newsletters MailChimp est apparu en premier sur DesireLabs.

Designers: earn your seat at the table – InVision Blog

Franck — Tue, 09 Feb 2016 07:21:02 +0000

Design is a critical skillset for operating in the business world, but it’s up to you as the designer to show and tell this to your stakeholders.

Source : Designers: earn your seat at the table – InVision Blog

L’article Designers: earn your seat at the table – InVision Blog est apparu en premier sur DesireLabs.

Utiliser SASS dans ses projets WordPress

Franck — Sun, 10 Jan 2016 20:05:15 +0000

Sass est devenu pour moi un outil du quotidien. Je l’utilise dans presque tous mes projets. Le fait est que je travaille beaucoup avec WordPress. Il est donc devenu évident qu’il fallait que je développe une méthodologie pour le faire entrer dans ces projets-ci. Aujourd’hui je vous propose de découvrir de quelle manière intégrer Sass dans vos projets WordPress.

Un thème WordPress nécessite normalement 1 seul et unique fichier CSS, à la racine : style.css. Mais tout mettre au kilomètre dans ce fichier c’est la garantie de rendre le projet difficile à maintenir et à faire évoluer. C’est pourquoi on préfèrera découper son design en modules. Plusieurs méthodologies existent, mais celle qui fait sens à mes yeux se rapproche de SMACSS. Je vous invite à aller faire un tour sur leur site, on y apprend des choses très intéressantes sur les manières possibles de découper son design CSS.

La puissance des préprocesseurs CSS n’est plus à démontrer : ils nous permettent de s’affranchir des préfixes vendeurs, d’apporter de la logique dans nos feuilles de styles, de séparer proprement notre architecture, bref, de tout calibrer au plus juste sans se répéter. C’est la méthode DRY (Don’t repeat yourself). Globalement, on gagne en productivité, en stabilité, on limite les régressions et en plus on s’éclate. Que demander de plus ?

Sass embrasse parfaitement cette philosophie du DRY et de la scalabilité. Mais pour l’installer sur WordPress comment ça se passe ?

Premièrement, il faut avoir déjà installé et configuré les outils sur sa machine. Dans mon cas, j’utilise le framework COMPASS. Il est réputé pour être l’un des plus complets avec une palette de mixins très étendue, et même si pas mal lui reprochent d’être assez lourd / lent à la compilation, de mon point de vue c’est à la marge. Car si vous n’avez jamais utilisé SASS / COMPASS, il faut savoir que le code que vous générez est compilé à la volée en fichier css standards.

Je pars du principe que les personnes qui lisent cet articles ont déjà COMPASS d’installé et sont prêts à se lancer.

Pour démarrer le projet (thème ou plugin) en mode SASS, il suffit d’initialiser un projet COMPASS à la racine. Si je construit un thème, j’ouvrirai le terminal à la racine de mon thème et je taperai :

compass init

A la suite de quoi, je me retrouve avec un fichier config.rb, ainsi que 2 nouveaux dossiers : sass et stylesheets. Le dossier sass est celui dans lequel on va travailler à l’avenir, mais avant, il faut aller un peu plus loin :

Les fichiers scss contenu dans le dossier sass vont entrainer la création / modification de leur alter égo css contenu dans le dossier stylesheets, à chaque fois que j’ajouterai / modifierai un fichier scss. Je vais donc devoir demander à compass de se mettre en « écoute », de manière à catcher les modifications au fur et à mesure. Je tape donc dans mon terminal, toujours à la racine de mon thème :

compass watch

Le watcher est à présent en mode « écoute », et toutes les modifications effectuées dans le dossier sass seront automatiquement compilées dans le dossier stylesheets. Mais cela ne suffit pas. Il faut dès maintenant indiquer à WordPress comment récupérer / lire les fichiers css créés.

Voici la logique que j’applique :

Mon fichier style.css à la racine de mon thème va dès à présent me servir de passerelle, en appelant un seul et unique fichier contenu dans le dossier stylesheets. Bien sûr, la création de ce fichier se passe d’abord dans le dossier sass : je créé un fichier nommé « main.scss », et automatiquement, son copain « main.css » est créé. Il me suffit alors d’importer ce fichier css dans mon « style.css » :

@import url(stylesheets/main.css);

Mais alors, et les autres fichiers aussi il va falloir les importer ? Oui et non. En fait ce qu’on va faire c’est créer uniquement des fichiers scss qui ne seront pas compilés en fichiers css. Le but n’est pas de remplir le dossier stylesheets, mais de le maintenir avec un seul fichier : notre fameux main.css, et de dire à ce dernier de faire tous les imports des fichiers qu’on va créer par la suite.

Du coup on va préfixer tous nos nouveux fichiers scss avec un underscore « _ ». Par exemple, si je veux un fichier scss dédié à la navigation et un autre à mes modules, je vais les nommer respectivement « _navigation.scss » et « _modules.scss ». De cette manière je suis tranquille, je sais qu’ils ne seront pas compilés en css. Il ne reste plus qu’à les importer dans l’ordre qui nous convient, dans le fichier main.scss (qui lui ne possède pas d’underscore, et est donc compiler en main.css).

Voici ce que j’écris dans mon main.scss :

@import "compass";
@import "navigation";
@import "modules";

Première chose à noter, j’importe les fichiers en les appelant par leur nom, sans l’underscore et sans leur extension. C’est tout à fait normal. De plus je n’utilise pas « url(nom du fichier) », je met directement le nom de mon fichier entre guillemets, et c’est tout ! L’import de « compass » est nécessaire mais non obligatoire : le fait d’utiliser le compilateur de COMPASS ne vous oblige nullement à utiliser les mixins fournies, mais bon, ce serait dommage de se priver Pour ma part je recommande de ne pas importer COMPASS entièrement, mais de sélectionner les outils qui vous intéressent. Je vous laisse jeter un oeil à la documentation de compass à ce sujet.

Si on récapitule :

j’ai un fichier style.css qui importe le fichier main.css, qui lui même est issu de la compilation de main.scss, et c’est dans main.scss qu’on importe autres feuilles de style scss. C’est aussi simple que ça ! Les modules importés sont préfixés d’un underscore, de manière à ne pas générer un fichier css pour rien, mais de tout centraliser grâce à un seul et unique fichier : main.scss

C’est ainsi que je procède dans mes projets, une fois que tout est en place, il ne me reste qu’à lancer mon watcher et tout se fait dans le dossier sass à la racine du thème. On ne peut faire plus simple, enfin pas tant que les navigateurs ne parleront pas autre chose que du css

L’article Utiliser SASS dans ses projets WordPress est apparu en premier sur DesireLabs.

Pourquoi trouver un bon développeur frontend est si difficile ? [en]

Franck — Sun, 29 Nov 2015 19:24:14 +0000

View story at Medium.com

L’article Pourquoi trouver un bon développeur frontend est si difficile ? [en] est apparu en premier sur DesireLabs.

En finir définitivement avec les problèmes de permissions de WordPress

Franck — Thu, 08 Oct 2015 15:38:59 +0000

Bonjour à toutes et tous, cet article fait écho à celui que j’avais écrit il y a un petit moment de ça, et qui expliquait comment installer son dossier www dans le home. Le gros soucis est que lorsqu’on procède ainsi, il y a un conflit de droit pour l’écriture des fichiers et dossiers entre le user qui possède le dossier dans home, et le user apache. Mais ça c’était avant !

Quelques explications

Avant de commencer il faut savoir que lorsque l’on effectue une opération via WordPress, comme installer un thème, un plugin ou uploader un fichier dans la bibliothèque de médias, c’est le user Apache qui écrit sur le disque. De fait, si le dossier www de notre site est installé dans le home, la chose devient impossible et on est forcé : soit de lui donner tous les droits (genre 777), soit de le rendre propriétaire du dossier, et dans ce cas là adieu la possibilité de faire des modifications directement en ftp par la user.

La solution

On va procéder par étape et dire que le user qui exécute Apache ne sera plus www-data, mais un user intermédiaire que l’on nommera « wordpress ». On créé donc le user :

sudo adduser wordpress

On ajoute le user « user » au groupe « wordpress »

sudo usermod -a -G wordpress user

On va à présent modifier le user qui exécute apache. On édite le fichier envvars d’apache

sudo nano /etc/apache2/envvars

on repère les lignes

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

et on remplace « www-data » par le user « wordpress » comme ceci

export APACHE_RUN_USER=wordpress
export APACHE_RUN_GROUP=wordpress

puis on redémarre apache

sudo service apache2 restart

A présent on se rend dans /home et on modifie le propriétaire du dossier www

cd /home/user
sudo chown -R user:wordpress www/

Le propriétaire est bien configuré, il ne reste plus qu’à configurer les droits sur les fichiers et dossiers

sudo find ./www -type d -exec chmod 0755 {} \; # applique 755 sur les dossiers 
sudo find ./www -type f -exec chmod 0644 {} \; # applique 644 sur les fichiers

Et c’est tout ! Fini les problèmes d’écriture à la fois par apache et votre user.

L’article En finir définitivement avec les problèmes de permissions de WordPress est apparu en premier sur DesireLabs.

WordPress 3.9, ou la sublimation des contenus

Franck — Fri, 18 Apr 2014 08:07:18 +0000

Ca y est c’est fait, WordPress débarque en version 3.9 avec au menu quelques améliorations loin d’être superflues ! Et c’est surtout au niveau des contenus de la médiathèque que le lifting s’est opéré. Et ce n’est pas pour déplaire !Parmi les évolutions qui méritent le détour selon moi :

La possibilité de faire un glisser déposer de ses médias directement dans l’éditeur de texte pour les uploader
La prévisualisation de galeries directement dans l’éditeur de texte, ça donne un véritable aperçu du résultat final
L’arrivée des listes de lecture pour la musique et la vidéo
Un nouvel écran de prévisualisation des thèmes, avec possibilité d’éditer la position et le contenu de ses widgets directement dans la fenêtre de prévisualisation du thème
L’intégration de la bibliothèque javascript Masonry 3

Il y pas mal d’autres petits détails sympas, mais je vous laisse aller faire un tour ici pour les découvrir, ou mieux, les tester par vous même

L’article WordPress 3.9, ou la sublimation des contenus est apparu en premier sur DesireLabs.

Transférer des fichiers d’un ftp à un autre

Franck — Thu, 09 Jan 2014 10:35:44 +0000

J’aime bien pouvoir m’installer des instances de test des sites sur lesquels je travaille, mais en conditions réelles, soit sur un vrai serveur de production et non en local. Du coup, si je veux récupérer l’intégralité d’un site via ftp, j’utilise une petite astuce.

Cette petite astuce n’en est pas vraiment une en fait et nécessite d’être exécutée en ligne de commande sous Linux Debian.

Donc faisons le point :

j’ai d’un côté mon serveur de test, une Debian 6 avec proftpd d’installé (serveur ftp) ET lftp, qui lui est un client ftp.

De l’autre, un serveur de production avec dessus, le site que je veux aspirer.

Je passerai sur la configuration de proftpd et lftp. Ça fera peut être l’objet d’un article dédié un de ces jours

La solution

Une seule ligne de commande à exécuter côté serveur de test, soit, ma Debian :

sudo lftp ftp://login_prod:pass_prod@host_prod -e "mirror /chemin/du/dossier/a/aspirer/prod /chemin/du/dossier/de/destination/debian ; quit"

où login_prod correspond au login ftp du site de prod, pass_prod correspond au pass ftp du site de prod et host_prod correspond au domaine ftp du site de prod.

Le -e commande à lftp d’exécuter ce qui est entre guillemets.
Le mirror crée une copie exacte.

L’avantage de cette commande exécutée avec mirror, c’est qu’on récupère toute l’arborescence et les contenus des dsssiers.

Si on veut récupérer seulement un fichier, on utilise get au lieu de mirror, et si ou souhaite envoyer, on utilisera put.

Sources : http://doc.ubuntu-fr.org/lftp

L’article Transférer des fichiers d’un ftp à un autre est apparu en premier sur DesireLabs.