Salut, personnellement j'ai déjà eu des clients qui ne m'embauchaient que pour refaire leur front-end à cause de la mauvaise utilisation de bootstrap par l'agence web employée en premier lieu. Je m'explique, bootstrap semble être un outil efficace pour qui sait l'utiliser, dans les mains d'un non initié j'ai vu les dégâts, notamment des pages qui galéraient à charger du fait de leur poids (mes pages codées main chargeant jusqu'à 100 fois plus rapidement). Plus précisément, bien que je ne connaisse pas ça me parait quand même un ramassis de mauvaises pratiques ce framework.
Personnellement je travaille tout à la main pour faire mon responsive, après tout est question de conception. J'ai déjà du faire l'intégration responsive cross-browser d'un site qui n'avait pas du tout été réfléchi responsive par le designer, mon fichier css fait plusieurs milliers de lignes pour palier à cette erreur. En revanche lorsque le site est conçu convenablement il devient aisé de l'adapter en responsive, je pense à de nombreux designs ou l'intégralité de mes media-queries représente une centaine de lignes max.
Pour une approche non professionnelle je ne sais pas trop quoi dire de bootstrap, certains frameworks sont utiles mais la plupart de ceux qui fournissent un grid responsive sont des usines à gaz d'après ce que j'ai compris. En revanche dans un contexte pro, je trouve que bootstrap est à proscrire. Pour moi le css c'est comme tout language il faut de la précision, de l'optimisation et de la lisibilité, et les frameworks css lourds sont les ennemis de ces trois caractérstiques.
Ensuite concernant l'accessibilité web on peut parler de l'amélioration progressive ou dégradation élégante ce qui nous emmène à casser les idées reçues du web aujourd'hui. L'amélioration progressive dans le même esprit que l'approche mobile first vise à développer son site de manière à obtenir la meilleur compatibilité cross-platform sans oublier de gérer la désactivation de javascript, les navigateurs antiques... On utilise souvent du nesting appliquant des styles moyennement supportés par les navigateurs à des div qui sont supportés et qui seront chargés en cas de besoin. Ce que j'appelle idées reçues c'est cet amour du HTML5 / CSS3. En passant par le validateur prototype du W3C on peut tester la rigueur de son HTML5, problème principal si on utilise les balises html5 on va vite se retrouver à nester des divs reconnues par les navigateurs anciens. On verra notamment que les balises nav et header ne sont supportées qu'à partir de IE9. On connaît également des incohérences dans les positions sur FF et aussi des erreurs d'inline... Des variations avec la gestion des border, des quirks de Safari...
Niveau cohérence web je trouve ça donc idiot d'utiliser du HTML5 juste pour faire cool ce qui pour avoir un site compatible cross-browser donnerait par exemple <div="#header"><header></header></div>. Là y'a un choix à faire entre modernité et accessibilité. Plus encore, je suis un fervent défenseur du responsive mais il y à des cas ou c'est une erreur. On va décrier les sites qui proposent des sheets différentes en fonction des supports, mais c'est la solution assurée pour certaines interfaces qui doivent juste être totalement repensées pour l'expérience utilisateur plutôt que pour les chevilles du designer. Je pense que certains jeux entreront dans cette catégorie. Quand y'a des milliers de lignes responsive autant charger une sheet différente.
Bon j'ai écrit un sacré pavé mais je parlerais juste rapidement de ma méthode. Lorsque j'ai le choix j'utilise du HTML4 principalement couplé à du CSS2 et 3 appliqué de manière à obtenir un résultat propre peu importe le contexte. Je précède toutes mes interfaces d'un reset.css simple. J'utilise des annulations de liens js pour obtenir une navigation fluide qui sera remplacée par une navigation classique par rechargement en cas de désactivation de js. Ensuite je teste mes travaux sur un navigateur pour mal-voyants pour en juger l'accessibilité pour ces personnes mais aussi pour travailler sur le SEO.
Dans le cadre de ma professionnalisation on pourrait parler de SASS et des préprocesseurs CSS. Des outils très puissants, utiles sur de gros projets. Le sujet divise parmi les designers, je n'ai pas vraiment d'avis sur la question mais sur mes projets perso je n'en vois pas l'utilité si y'a 4 ou 5 codes valeurs que je stockerais en variables je les mémorise quand on travaille 1 mois sur un projet c'est pas si difficile surtout que le css est une pratique solitaire en général.
Enfin je parlerais d'un outil très simple qu'il m'arrive d'utiliser : http://daneden.github.io/animate.css/
Une petite bibliothèque d'animations css très bien faite qui peut éviter pas mal de prises de tête.
Globe qui attend l'adoption de srcset avec impatience =)
Personnellement je travaille tout à la main pour faire mon responsive, après tout est question de conception. J'ai déjà du faire l'intégration responsive cross-browser d'un site qui n'avait pas du tout été réfléchi responsive par le designer, mon fichier css fait plusieurs milliers de lignes pour palier à cette erreur. En revanche lorsque le site est conçu convenablement il devient aisé de l'adapter en responsive, je pense à de nombreux designs ou l'intégralité de mes media-queries représente une centaine de lignes max.
Pour une approche non professionnelle je ne sais pas trop quoi dire de bootstrap, certains frameworks sont utiles mais la plupart de ceux qui fournissent un grid responsive sont des usines à gaz d'après ce que j'ai compris. En revanche dans un contexte pro, je trouve que bootstrap est à proscrire. Pour moi le css c'est comme tout language il faut de la précision, de l'optimisation et de la lisibilité, et les frameworks css lourds sont les ennemis de ces trois caractérstiques.
Ensuite concernant l'accessibilité web on peut parler de l'amélioration progressive ou dégradation élégante ce qui nous emmène à casser les idées reçues du web aujourd'hui. L'amélioration progressive dans le même esprit que l'approche mobile first vise à développer son site de manière à obtenir la meilleur compatibilité cross-platform sans oublier de gérer la désactivation de javascript, les navigateurs antiques... On utilise souvent du nesting appliquant des styles moyennement supportés par les navigateurs à des div qui sont supportés et qui seront chargés en cas de besoin. Ce que j'appelle idées reçues c'est cet amour du HTML5 / CSS3. En passant par le validateur prototype du W3C on peut tester la rigueur de son HTML5, problème principal si on utilise les balises html5 on va vite se retrouver à nester des divs reconnues par les navigateurs anciens. On verra notamment que les balises nav et header ne sont supportées qu'à partir de IE9. On connaît également des incohérences dans les positions sur FF et aussi des erreurs d'inline... Des variations avec la gestion des border, des quirks de Safari...
Niveau cohérence web je trouve ça donc idiot d'utiliser du HTML5 juste pour faire cool ce qui pour avoir un site compatible cross-browser donnerait par exemple <div="#header"><header></header></div>. Là y'a un choix à faire entre modernité et accessibilité. Plus encore, je suis un fervent défenseur du responsive mais il y à des cas ou c'est une erreur. On va décrier les sites qui proposent des sheets différentes en fonction des supports, mais c'est la solution assurée pour certaines interfaces qui doivent juste être totalement repensées pour l'expérience utilisateur plutôt que pour les chevilles du designer. Je pense que certains jeux entreront dans cette catégorie. Quand y'a des milliers de lignes responsive autant charger une sheet différente.
Bon j'ai écrit un sacré pavé mais je parlerais juste rapidement de ma méthode. Lorsque j'ai le choix j'utilise du HTML4 principalement couplé à du CSS2 et 3 appliqué de manière à obtenir un résultat propre peu importe le contexte. Je précède toutes mes interfaces d'un reset.css simple. J'utilise des annulations de liens js pour obtenir une navigation fluide qui sera remplacée par une navigation classique par rechargement en cas de désactivation de js. Ensuite je teste mes travaux sur un navigateur pour mal-voyants pour en juger l'accessibilité pour ces personnes mais aussi pour travailler sur le SEO.
Dans le cadre de ma professionnalisation on pourrait parler de SASS et des préprocesseurs CSS. Des outils très puissants, utiles sur de gros projets. Le sujet divise parmi les designers, je n'ai pas vraiment d'avis sur la question mais sur mes projets perso je n'en vois pas l'utilité si y'a 4 ou 5 codes valeurs que je stockerais en variables je les mémorise quand on travaille 1 mois sur un projet c'est pas si difficile surtout que le css est une pratique solitaire en général.
Enfin je parlerais d'un outil très simple qu'il m'arrive d'utiliser : http://daneden.github.io/animate.css/
Une petite bibliothèque d'animations css très bien faite qui peut éviter pas mal de prises de tête.
Globe qui attend l'adoption de srcset avec impatience =)