> Passage de LESS à Libsass : SASS est aujourd'hui le compileur préprocesseur CSS le plus utilisé avec plus de 70% de part de marché. C'est donc en toute logique que Bootstrap s'y mette aussi. Le parti est pris de passer directement à Libsass, un compilateur SASS (alternative à Ruby) développé en C++ pour toujours plus de rapidité
> Des nouvelles unités : L'utilisation des unités em et rem relative au font (1em = une fois la taille du font du parent, 1rem = une fois la taille du font de l'html), même pour les média queries !
> Les mixins, permettant toujours plus de possibilités dans notre code SCSS ! À noter que nous pouvons utiliser
min-width ET max-width dans les mixins de Bootstrap 4 pour les besoins précis.
> Autoprefixer, du code plus compact on ne dit pas non
> L'ajout de col-xl pour les gros écrans (width >= 75em), permettant de cibler de plus petits écrans avec xs ( width <= 34em).
La version alpha 2 date de novembre/décembre 2015, et il faut encore passer par les betas et les RC. Donc tu as encore le temps avant de basculer tes projets sur Bootstrap 4.
En revanche, le tester et suivre son évolution sont de bonnes choses.
Autant pour moi alors, je viens de la voir maintenant (j'avais vu la 1 il y a maintenant un certain temps...).
Pour moi l'avantage c'est surtout les mixins... J'ai commencé à tester et c'est tellement pratique que je sais même plus comment je codais en responsive avant dans certaines situations... haha
Un nouveau palier de responsive design pour les téléphones de faibles résolutions, le passage intégrale à Sass, l'intégration du système de cards, le passage à Reboot et surtout le système de grille flex... Franchement je l'attends avec impatience. En revanche l'abandon total du support d'IE 8 va me forcer à conserver Bootstrap 3 sur certains projets.
Je n'ai pas compris le SASS et l'auto-prefixer peut-on m'expliquer ?
le SCSS (SASS étant le préprocesseur CSS numéro uno en ce moment devant LESS) et l'auto-prefixer permettent de donner plus de fonctionnalités au CSS. Vas voir la doc de SASS c'est le paradis.
Le langage du code source CSS et du système de compilation utilisé par Bootstrap 3 est LESS, un langage dynamique de génération de feuille de style. Bootstrap 4 utilisera Sass, une version améliorée du SCSS. Sass est plus simple (à mon goût) et permet d'utiliser le système de compilation Libsass qui permet une compilation plus rapide.
En revanche l'abandon total du support d'IE 8 va me forcer à conserver Bootstrap 3 sur certains projets.
Sur l'ordinateur environ 6% des utilisateurs utilisent encore IE8 (4% en europe) et c'est sans prendre en compte les appareils mobiles et les tablettes. En rajoutant le fait que ceux qui l'utilisent sont des utilisateurs n'allant souvent pas plus loin que google, j'ai déjà abandonné le support sur tous mes projets..
Sur mes projets persos, je ne vois aucun inconvénient à abandonner ce support. Surtout qu'on pourra utiliser pleinement jQuery 2.0. Mais j'ai certains projets en entreprise utilisant Bootstrap qui nécessitent une comptabilité IE 8 (l'horreur...).
Mais pour en revenir au sujet, ils avaient annoncé plusieurs versions alpha, deux bêta et deux RC avant la sortie définitive de Bootstrap 4, donc on a le temps.
Surtout qu'on pourra utiliser pleinement jQuery 2.0
On peut aussi pleinement se passer de jQuery, c'est tout aussi bien. Mais quitte à l'utiliser, autant passer en version 3.0.
Bref, des nouveautés certes, mais pour moi la question reste toujours sur la pertinence d'utiliser bootstrap… Y a un côté modulaire, mais pas assez propre et sous-exploité. S'ils passaient à BEM, ça pourrait éventuellement le faire, mais là pour la moindre surcharge on se retrouve obligés de donner dans le sale.
Autant pour une interface admin ou une webapp je peux trouver son emploi pertinent, autant pour du webdesign je trouve ça contre-productif.
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Surtout qu'on pourra utiliser pleinement jQuery 2.0
On peut aussi pleinement se passer de jQuery, c'est tout aussi bien. Mais quitte à l'utiliser, autant passer en version 3.0.
Bref, des nouveautés certes, mais pour moi la question reste toujours sur la pertinence d'utiliser bootstrap… Y a un côté modulaire, mais pas assez propre et sous-exploité. S'ils passaient à BEM, ça pourrait éventuellement le faire, mais là pour la moindre surcharge on se retrouve obligés de donner dans le sale.
Autant pour une interface admin ou une webapp je peux trouver son emploi pertinent, autant pour du webdesign je trouve ça contre-productif.
ça fait gagner énormément de temps en plus de rendre responsive ton site... Je ne vois pas ce que tu veux dire par "pour la moindre surcharge on se retrouve obligés de donner dans le sale"
Ben non justement, je trouve que ça en fait perdre énormément : dès qu'on veut sortir un tout petit peu des rails de bootstrap, il faut surcharger une blinde de propriétés.
Et ce que j'entend par sale, c'est ça :
.navbar-default .navbar-nav>li>a { }
Si je veux changer le style des liens de la navbar, je suis obligé de réécrire un sélecteur inutilement lourd. Encore plus si je veux gérer le hover ou autre :
Si je veux intervenir sur le comportement de la navbar, je dois intervenir sur une bonne dizaine de classes, à chaque fois avec des sélecteurs pachydermiques.
Et si pour X ou Y raison je dois faire quelque chose d'un peu exotique par rapport à la grid, c'est mort ; d'autant que la modification des breakpoints pose parfois certains soucis à des éléments dont la taille est fixe.
En bref, c'est anti-pattern, c'est limitatif, c'est lourd, c'est plein de mauvaises pratiques (encore que ça s'améliore un peu), ça oblige à se conformer à un type de design… Et vu son poids, si c'est juste pour avoir une grid responsive, on a beaucoup, beaucoup plus léger et mieux pensé dans des Framework dédiés aux grids. Et pour utiliser les modules JS, ça nécessite d'avoir jQuery (double lourdeur).
Après, certes, on peut se faire un custom build avec uniquement les modules qu'on souhaite. Mais je ne parierai pas d'avantage sur le gain de temps.
Donc pour moi, c'est très cool pour faire un mockup, une interface applicative, mais pas pour un design.
- Edité par EmmanuelBeziat 16 juin 2016 à 14:58:45
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Ben non justement, je trouve que ça en fait perdre énormément : dès qu'on veut sortir un tout petit peu des rails de bootstrap, il faut surcharger une blinde de propriétés.
Et ce que j'entend par sale, c'est ça :
.navbar-default .navbar-nav>li>a { }
Si je veux changer le style des liens de la navbar, je suis obligé de réécrire un sélecteur inutilement lourd. Encore plus si je veux gérer le hover ou autre :
Si je veux intervenir sur le comportement de la navbar, je dois intervenir sur une bonne dizaine de classes, à chaque fois avec des sélecteurs pachydermiques.
Et si pour X ou Y raison je dois faire quelque chose d'un peu exotique par rapport à la grid, c'est mort ; d'autant que la modification des breakpoints pose parfois certains soucis à des éléments dont la taille est fixe.
En bref, c'est anti-pattern, c'est limitatif, c'est lourd, c'est plein de mauvaises pratiques (encore que ça s'améliore un peu), ça oblige à se conformer à un type de design… Et vu son poids, si c'est juste pour avoir une grid responsive, on a beaucoup, beaucoup plus léger et mieux pensé dans des Framework dédiés aux grids. Et pour utiliser les modules JS, ça nécessite d'avoir jQuery (double lourdeur).
Après, certes, on peut se faire un custom build avec uniquement les modules qu'on souhaite. Mais je ne parierai pas d'avantage sur le gain de temps.
Donc pour moi, c'est très cool pour faire un mockup, une interface applicative, mais pas pour un design.
- Edité par rhooManu il y a 16 minutes
----
Euh... On parle bien de Bootstrap 4 là, donc dans ton exemple ce serait:
Euh... On parle bien de Bootstrap 4 là, donc dans ton exemple
C'est parfaitement le même résultat en sortie. Bootstrap 3 utilisait déjà Sass, mais il n'empêche que le selecteur est long et donc lourd, même avec du nesting pour le faciliter.
Après, si tout a été modifié en em/rem, c'est très bien. Mais ce n'est pas toujours le cas :
Je n'ai pas tout fouillé, mais il reste visiblement quelques éléments. Ils n'ont pas l'air graves à première vue. Mais qu'ils soient en relative ou pas n'est pas la question : Le fait est que des tailles sont définies sur des éléments, et que si cette taille ne me convient pas, je suis obligé d'aller surcharger le sélecteur, et je prend le risque d'entrer en conflit avec d'autres configurations du même élément (par exemple inclus à l'intérieur d'autres éléments qui s'attendent à ce qu'il ait une certaine taille — fut-elle relative).
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Je suis d'accord avec Manu : Bootstrap c'est bien pour faire du back ou des interfaces admin propres. Par contre, pour faire du front, tu peux oublier. Je me fais régulièrement la remarque en visitant des sites : "tiens, il est fait avec Bootstrap ce site". Et puis, à la base, Bootstrap a été conçu comme outil pour le design du back-end de Twitter.
Il existe plein d'autres frameworks responsives qui sont beaucoup plus faciles à surcharger que Boostrap et qui ont sensiblement la même courbe d'apprentissage que Bootstrap.
Je suis d'accord avec Manu : Bootstrap c'est bien pour faire du back ou des interfaces admin propres. Par contre, pour faire du front, tu peux oublier. Je me fais régulièrement la remarque en visitant des sites : "tiens, il est fait avec Bootstrap ce site". Et puis, à la base, Bootstrap a été conçu comme outil pour le design du back-end de Twitter.
Il existe plein d'autres frameworks responsives qui sont beaucoup plus faciles à surcharger que Boostrap et qui ont sensiblement la même courbe d'apprentissage que Bootstrap.
Je suis intéressé, pourrais-tu me donner leurs noms ?
Euh... On parle bien de Bootstrap 4 là, donc dans ton exemple
C'est parfaitement le même résultat en sortie.
Certes mais on ne perd pas autant de temps en écrivant le code que tu penses le penser.
Sinon tu critiques beaucoup bootstrap, mais bon je pense que c'est surtout une question d’appréciation... Que les personnes aimant coder façon bootstrap le fassent, que les autres ne le fassent pas et tout le monde est content
PS: Certes c'est lourd comme tu le dis, mais le passage à libsass augmente grandement les performances !
Certes mais on ne perd pas autant de temps en écrivant le code que tu penses le penser.
Je m'inscris en faux. Surcharger le design d'une navbar de Boostrap, pour l'avoir fait plusieurs fois, c'est l'enfer. Quand tu finis par écrire 7 classes/éléments à la suite, c'est que quelque chose ne va pas.
Certes c'est lourd comme tu le dis, mais le passage à libsass augmente grandement les performances !
Aucun rapport. "lourd" veut dire "difficile à surcharger", on ne parle pas des performances de compilation.
Pas d'aide concernant le code par MP, le forum est là pour ça :)
@rhooManu : depuis que j'ai commencé l'intégration, et surtout l'apprentissage de Bootstrap, je me posais beaucoup de question et ton post vient de me confirmer ce que je pensais depuis longtemps : Bootstrap devient très compliqué dès que l'on veut être créatif.
On veut changer la couleur d'une navbar et on se retrouve à devoir fouiller tout le code car ça ne change pas comme on l'aurait voulu et on perd un temps fou à essayer de trouver ce qui ne va pas (j'ai encore eu le tour récemment). Entre le navbar simple, le navbar > li > a... au bout d'un moment, on se perd tellement qu'au final on sait plus ce que l'on change.
En plus, je sais pas pour vous mais je trouve que c'est le foutoir leur fichier (que ce soit la version 3 comme la 4). Pour essayer de dompter la bête, je parcours le fichier pour essayer de le comprendre et il y a le même sélecteur un peu partout dans le fichier et sans qu'il soit inclus dans un but précis (genre pour un media queries ou un print). Il y a même des contradictions :
Fichier Bootstrap V4
Ligne 76 à 79 sur Notepad :
h1 {
margin: .67em 0;
font-size: 2em;
}
Ligne 340 à 344 :
h1, h2, h3, h4, h5, h6 {
margin-top: 0;
margin-bottom: .5rem;
}
Ligne 513 à 515 :
h1 {
font-size: 2.5rem;
}
Alors, déjà, en premier, on définit la taille à 2 rem puis à 2.5. Ensuite dans le premier h1, on définissant avec 2 valeurs le margin, si je ne me trompe pas, on définit en même temps "margin-top = margin-bottom = 0.67em et ensuite on rechange ces valeurs. J'ai revérifié avant de poster et ces sélecteurs sont techniquement les mêmes, il n'y en a pas un qui concerne un @ et un autre la feuille principale ou je ne sais quoi. C'est clairement de la contradiction.
Personnellement, je n'utilise bootstrap que pour ses plugins comme les carousels et autres mais même là dès qu'on veut faire une mise en forme particulière, c'est ...
Et puis je me pose une question, pourquoi 12 colonnes?? Ils définissent la taille des colonnes en % avec des chiffres à "virgule" extrêmement long. Pourquoi pas 10? Au moins ça fait des pourcentages précis?? Si quelqu'un a la réponse, je la veux bien svp.
Je trouve ça dommage car dans le principe est pas mal. Pour ma part, là je suis en train de créer mon propre "bootstrap" en essayant de le simplifier (avec mes modestes connaissances, en l'organisant d'une part, et en omettant certaines ligne dont je n'ai pas encore eu l'utilité).
Certes mais on ne perd pas autant de temps en écrivant le code que tu penses le penser.
Je m'inscris en faux. Surcharger le design d'une navbar de Boostrap, pour l'avoir fait plusieurs fois, c'est l'enfer. Quand tu finis par écrire 7 classes/éléments à la suite, c'est que quelque chose ne va pas.
Certes c'est lourd comme tu le dis, mais le passage à libsass augmente grandement les performances !
Aucun rapport. "lourd" veut dire "difficile à surcharger", on ne parle pas des performances de compilation.
Perso mes projets se chargent en une centaine de millisecondes (avec une connexion moyenne), j'appelle pas ça "difficile à surcharger". Et pour la navbar, comme je l'ai expliqué avec sass c'est déjà plus simple.
Sinon, le but de ce sujet est le passage de Bootstrap 3 à 4, et pas la pertinence d'utiliser boostrap. À la base j'ai créé ce sujet pour discuter des nouveautés et on se retrouve avec un débat sur les défauts de bootstrap 3...
@Dipeeh : tu parles des nouveautés, en présentant les avantages et défauts de cette nouvelle version. Donc, pour certains, c'est normal qu'ils te présentent les défauts qui n'ont pas été corrigés selon eux ou qui mériteraient de l'être (comme le nombre de classe à écrire pour lamecarlate).
En ce qui concernent ce que tu appelles un débat, à mon sens, il est nécessaire pour permettre à des débutants qui auraient des difficultés (moi par exemple), de voir qu'ils ne sont pas les seuls et surtout de voir qu'il y a d'autres solutions dans un premier temps plus simple mais qui seront un bon point de départ (vélo avec roulettes) avant de prendre en main bootstrap (vélo 2 roues). Tout le monde ne jure que par bootstrap mais il reste relativement complexe à maîtriser même avec le cours.
@Dipeeh : tu parles des nouveautés, en présentant les avantages et défauts de cette nouvelle version. Donc, pour certains, c'est normal qu'ils te présentent les défauts qui n'ont pas été corrigé selon eux ou qui mériteraient de l'être (comme le nombre de classe à écrire pour lamecarlate).
En ce qui concernent ce que tu appelles un débat, à mon sens, il est nécessaire pour permettre à des débutants qui auraient des difficultés (moi par exemple), de voir qu'ils ne sont pas les seuls et surtout de voir qu'il y a d'autres solutions dans un premier temps plus simple mais qui seront un bon point de départ (vélo avec roulettes) avant de prendre en main bootstrap (vélo 2 roues). Tout le monde ne jure que par bootstrap mais il reste relativement complexe à maîtriser même avec le cours.
C'est sur, vu comme ça au moins ça refoulera les moins motivés
Je suis un grand fan de bootstrap et ne suis donc pas toujours impartial dans mes réponses, je l'avoue !
Perso mes projets se chargent en une centaine de millisecondes (avec une connexion moyenne), j'appelle pas ça "difficile à surcharger". Et pour la navbar, comme je l'ai expliqué avec sass c'est déjà plus simple.
Encore une fois, c'est une question de travail humain et non de temps de chargement.
Et même avec Sass c'est chianf à faire. (et le code généré - parce que oui, il faut s'en préoccuper un peu - est tout moche)
Et puis je me pose une question, pourquoi 12 colonnes?? Ils définissent la taille des colonnes en % avec des chiffres à "virgule" extrêmement long. Pourquoi pas 10? Au moins ça fait des pourcentages précis?? Si quelqu'un a la réponse, je la veux bien svp.
C'est une "vieille" habitude des grilles : 12 se divise par 2, par 3, par 4, et par 6 ; quand 10 se divise seulement par 2 et par 5. Du coup, on a une meilleure flexibilité quant aux largeurs de blocs (qui font x colonnes de large). Exemple : je veux séparer un élément en trois parties de largeur égale. Avec une grille à douze colonnes, je fais "4 colonnes" + "4 colonnes" + "4 colonnes". Avec une grille à 10 colonnes, je fais comment ?
Pas d'aide concernant le code par MP, le forum est là pour ça :)
lesjoiesducode / Les points-virgules en JavaScript
lesjoiesducode / Les points-virgules en JavaScript
lesjoiesducode / Les points-virgules en JavaScript
lesjoiesducode / Les points-virgules en JavaScript
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Pas d'aide concernant le code par MP, le forum est là pour ça :)
Pas d'aide concernant le code par MP, le forum est là pour ça :)
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !