Attention : bac-à-sable foireux !!
Pensez également à bien vérifier la mise à jour des URLS vers les jsfiddles.
Source YouTube : AngularJS Fundamentals in 60 Minutes.
CategoryBac à sable
Divers tests… Pas forcément des choses ré-utilisables.
Exemple de solution mise en place : http://www.despetitshauts.com/fr/t-shirtsm-courtes-25.html.
Tentative en exploitant la fonction outerHeight de jQuery
La solution ci-dessous semble fonctionner 🙂
Simulation : http://jsfiddle.net/frontenddeveloper/2s0s1eag/29/.
Même chose mais à partir de Bootstrap : http://jsfiddle.net/frontenddeveloper/51xxem3p/6/.
Tentative avec la propriété columns de CSS3
Simulation : http://jsfiddle.net/frontenddeveloper/5doayaa5/5/.
Pour :
- On conserve un markup HTML cohérent (les éléments de la liste sont déclarés dans un ordre logique d’apparition)
- On ne surcharge pas le serveur par l’emploi de JavaScript
Contre :
- Pas compatible à partir d’IE9 (
<a href="http://caniuse.com/#search=columns">columns</a>) (voir pour l’existence d’un polyfill qui gère les contraintes responsive) - Le contenu n’est pas ordonné de gauche à droite (rangée après rangée), mais de haut en bas (colonne après colonne)
- Pas de contrôle sur le comportement lorsqu’il n’y a pas le nombre exact d’éléments (2 looks + 16 produits) dans la page, notamment en responsive
- Comportement responsive pas terrible…
Tentative avec Bootstrap 3 et Masonry
Inspiré de : http://codepen.io/anon/pen/eIxCp. Simulation : http://jsfiddle.net/frontenddeveloper/rbgsypLm/2/.
Pour :
- Le contenu est ordonné de gauche à droite (rangée après rangée)
Contre :
- On est obligé de surcharger légèrement Bootstrap (
.container { padding-left:0; padding-right:0; }) et le framework CSS peut poser problème lorsqu’il est couplé à Masonry… - On ne conserve pas un markup HTML cohérent (les éléments de la liste ne sont pas déclarés dans un ordre logique puisque le deuxième look est intercalé entre le produit 13 et le produit 14)… Avec tous les ennuis que cela comporte de gérer son imbrication au sein de la liste et de conserver un affichage cohérent (y compris en responsive) lorsque le nombre d’éléments change !
- Toujours pas de contrôle sur le comportement lorsqu’il n’y a pas le nombre exact d’éléments (2 looks + 16 produits) dans la page
- Comportement responsive catastrophique
Conclusions :
A moins de partir dans un dev JS très lourd qui prend en compte le nombre d’éléments à afficher pour replacer le 2ème look dans le DOM à chaque fois :
- qu’on agit soit sur la largeur de la fenêtre (problématique responsive),
- ou qu’on agit sur le nombre de produits à afficher (design prévu pour 2 looks et 16 produits – il peut y avoir moins de produits dans le rayon ou suite à un tri effectué par l’utilisateur)
…c’est pas possible d’avoir un affichage cohérent :/
Outil de conversion image vers SVG : Online CSS Sprite Generator (output base64 in CSS)
Simulation : http://jsfiddle.net/frontenddeveloper/fL4nB/
Source partielle du texte ci-dessous : http://www.johanbleuzen.fr/blog/encoder-images-base64-css
Le gain en nombre de requête peut être intéressant si l’on a beaucoup de petites images et reste pour moins le principal attrait de cette technique. Je l’utilise pour mes images de fonds dans le design de ce blog.
Avantages :
- Diminution du nombre des requêtes HTTP,
- Solution adaptée aux petites images,
- Les images tirent partie du GZip puisqu’elles sont encodées au format texte,
- Pas de markup HTML supplémentaire pour afficher des icônes dans vos pages (exit les
<i class="mon-icone"></i>), - Positionnement au pixel près dans les blocs avec CSS, repeat-x et y possible, background-multiple possible (voir ma simulation).
Inconvénients :
- Le fichier CSS est plus lourd,
- A chaque modification d’une image il faudra mettre à jour le fichier CSS,
- N’est pas supporté par IE6 et IE7 (mouarf !), mais les icônes et autres pictogrammes qui feraient l’objet d’une conversion en Base64 utilisent souvent la transparence PNG qui n’est pas plus prise en charge par ces navigateurs préhistoriques…
Et pour la forme voici, quelques petits conseils qui peuvent être intéressant de rappeler si vous voulez gagner quelques précieux kilo-octets :
- Utilisez cette image pour des images que l’on ne modifie pas souvent
- Optimisez vos images avec Smushit (par exemple) avant l’encodage en base64
- Les images ne doivent pas dépasser 3 kilo-octets
- Placez les attributs CSS en début de fichiers pour que l’affichage soit le plus rapide possible
Quelques essais suite à la publication de l’article d’Alsacréations Le modèle tabulaire en CSS.
Simulation : http://jsfiddle.net/frontenddeveloper/qbpxg/56/
© 2020 devfrontend.info
Theme by Anders Norén — Up ↑