Définir ses points de rupture - commentaires Définir ses points de rupture 2014-10-12T17:08:17Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment2561 2014-10-12T17:08:17Z <p>Merci Philippe d'être passé par là. Cette discussion devenait presque un débat phylosophique sur la théorie de la complexité. Triste aussi de constater le déclin de la créativité graphique sur le web.</p> Définir ses points de rupture 2014-08-03T08:39:19Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment2495 2014-08-03T08:39:19Z <p>Même si cet article date un peu, il apporte énormément, j'ai enfin réussi à lire un article qu'il parle du sujet sans me faire couper la page au bout de 5 minutes, la demo m'a aussi énormément aider à trouver des repères, le responsive est pour moi un massacre de l'originalité d'un site design et artistique, tout les sites se ressemble et n'ont plus de personnalité, mais il semble que la fin du site graphique à sonnée et je dois mis plier, bien sur ma première réaction à été de me pencher sur les format media query et très vite je me suis dis mais quesque ont fait !!! "Ont repart en arrière ou quoi", "encore une mode de webmaster qui va prendre fin dans 2 ou 4 ans", mais la ; non cet article me semble tellement logique qu'il va surement être la base même de mon entré en matière dans le responsive.</p> <p>Merci pour cet article riche et logique Nicolas</p> Définir ses points de rupture 2014-04-01T17:23:41Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment2254 2014-04-01T17:23:41Z <p>Ah oui, en relisant attentivement je me rends compte que j'ai choisis "bêtement" 312px qui correspondaient à une largeur réelle que j'obtenais sur mes différents palliers. Donc les prévoir plus grandes comme tu le suggères (800px à 30%, ou 1200px à 15%, ou autre) aurait été en effet une meilleure solution.</p> Définir ses points de rupture 2014-04-01T13:06:52Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment2253 2014-04-01T13:06:52Z <p>Nicolas H : Un peu de recul voyons ;)</p> <p>L'article est tout à fait valable et pas du tout "vieux", il explique avant tout <strong>comment penser le responsive avec le contenu</strong>, comme l'a expliqué l'auteur. Les paliers en pixels peuvent tout à fait s'accommoder de valeurs en em (vivent les préprocesseurs pour les calculs), idem pour les colonnes qui peuvent être transformées en pourcentages, etc. Quoi qu'on en dise, les pixels sont bien pratiques pour se faire comprendre.</p> <p>ThomasF : ça s'appelle les Elements queries, c'est en "super-early draft" :) pour le moment (en général, c'est fait via JavaScript). Ceci dit, en dehors de ça, bon nombre de sites complexes ont cette approche, le côté responsive est géré directement par module, et non de manière globale.</p> <p>Cela a ses avantages et ses inconvénients : c'est un peu tricky à penser hors du contexte (des fois impossible), mais par contre, c'est plus simple à maintenir : en somme le module contient son layout, ses mediaqueries, etc.</p> Définir ses points de rupture 2014-04-01T10:49:25Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment2252 2014-04-01T10:49:25Z <p>Merci Nicolas pour ta réponse !</p> <p>Pourquoi pas 14px pour la taille de texte ? Parce que l'utilisateur a peut-être besoin d'une autre taille. Cf <a href="https://vimeo.com/79204119" class="spip_out" rel='nofollow external'>ma conf Paris Web</a> et <a href="http://www.24joursdeweb.fr/2013/lachez-prise-sans-perdre-le-controle-grace-a-l-unite-css-em/" class="spip_out" rel='nofollow external'>mon article 24 jours de Web</a>.</p> <blockquote class="spip"> <p>L'intérêt ici n'est ni la maquette, ni les valeurs, mais le principe de fond</p> </blockquote> <p>OK, je comprends. De toute façon, comme je le disais, faire des paliers en <code class="spip_code" dir="ltr">em</code> alors que la taille de texte est bloquée en <code class="spip_code" dir="ltr">px</code> n'aurait pas beaucoup de sens… ;-)</p> <p>OK pour l'explication du « padding fixe », même si la formule reste étrange… ;-)</p> <blockquote class="spip"> <p>- Pour les images, 312px est simplement le résultat obtenu une fois mes ajustements typographiques effectués et mon nombre de colonnes défini. <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Pour la question sur les images de 400px, je vous invite à relire l'article car c'est expliqué.</p> </blockquote> <p>J'ai relu l'article au moins 3 fois avant de poser la question, je ne comprends toujours pas cette valeur de 312px plutôt que 400px. Une image de 624px (prévue pour un conteneur de 312px en Retina) ne sera sans doute pas très agréable à regarder dans un conteneur 30% plus grand, surtout si elle exploite la technique « Compressive Images ».</p> Définir ses points de rupture 2014-03-28T11:12:10Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment2242 2014-03-28T11:12:10Z <p>Effectivement, cet article date un peu, mais voici des éléments de réponse : <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> La taille est fixée à 14px, pourquoi pas ? Il fallait bien choisir une valeur, je n'incite personne à choisir cette valeur. <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Les paliers en pixels sont un parti-pris au vu de ce que implique des paliers en em : ils sont basés sur la taille de texte par défaut, et donc il aurait fallu faire des mises à l'échelle par rapport à la taille de typo rendue, ce qui aurait compliqué les calculs. L'intérêt ici n'est ni la maquette, ni les valeurs, mais le principe de fond. <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> <code class="spip_code" dir="ltr">box-sizing: border-box;</code> permet d'inclure les marges internes dans la valeur du width, ce qui signifie qu'on peut spécifier des width en % tout en appliquant des marges internes fixes (par exemple, également à 1.5em pour s'harmoniser avec la ligne de base). <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Pour les images, 312px est simplement le résultat obtenu une fois mes ajustements typographiques effectués et mon nombre de colonnes défini. <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Pour la question sur les images de 400px, je vous invite à relire l'article car c'est expliqué. <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Enfin, mon exemple ne répond pas à tout, mais est juste là pour sensibilisé à la problématique des points de ruptures, qui à l'époque étaient posés trop hasardement. Cela-dit, je reste persuadé qu'une approche "content first" peut répondre aussi à une adaptation des composants les plus réticents. Aux designers de mettre tous leurs composants en équation et trouver la solution optimale.</p> Définir ses points de rupture 2014-03-28T10:38:58Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment2241 2014-03-28T10:38:58Z <p>Bonjour,</p> <p>Je relis cet article suite à un tweet qui le remettait en avant, et je reste toujours autant sur ma faim. L'article permet bien entendu d'avoir une approche un peu plus universelle du Responsive Web Design que celle qui s'appuie sur des tailles de points de rupture fixés par rapport à certaines tailles d'écran populaires il y a quelques années, mais cela ne suffit pas à mon avis.</p> <p>Je comprends que cet article n'est plus tout jeune, mais il y a un an et demi, je me faisais déjà les mêmes remarques, et puisqu'il est de nouveau mis en avant, je pense nécessaire de signaler mes réserves : <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Il manque à mon avis une présentation au début du type de site et contenu(s) que l'on cherche à mettre en place. <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Pourquoi fixer arbitrairement la taille de texte à 14px ? (oui, celle-là je ne pouvais vraiment pas m'en empêcher… ;-) ) <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Et bien sûr, mais c'est lié, dommage de fixer les paliers en px… <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Que signifie le commentaire « pour appliquer un padding fixe » de l'instruction <code class="spip_code" dir="ltr">box-sizing: border-box;</code> ? <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> De quel chapeau sort la taille de 312px des images ? <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> S'il est question d'afficher ces images dans des conteneurs de 399px (avant palier à 400px), 288px (2 images dans <code class="spip_code" dir="ltr">max-width: 600px</code> moins les gouttières, avant palier à 800px), puis effectivement 312px (3 images dans <code class="spip_code" dir="ltr">max-width: 984px</code> moins les gouttières), pourquoi ne pas plutôt avoir des images de 400px (x2 pour le Retina) ? <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> Enfin, comme suggéré par ThomasH, penser les points de rupture de façon globale à la page ne permet pas d'adapter au cas par cas chaque composant, alors qu'ils n'ont pas forcément les mêmes besoins d'adaptation par rapport à l'espace qui les entoure.</p> <p>Peut-être serait-il pertinent de faire une mise à jour de l'article, ou d'en publier un autre abordant les pratiques actuelles de RWD.</p> Définir ses points de rupture 2013-10-21T09:44:38Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment2031 2013-10-21T09:44:38Z <p>Du coup, pour pousser plus loin le principe, ne faut-il pas des points de rupture par éléments (ou modules) plutôt que pour l'ensemble de la page ? Je m'explique : <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> un point de rupture dédié pour verticaliser la navigation quand la place horizontale n'est plus suffisante <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> un point de rupture dédié pour ajouter une colonne de droite quand la place devient disponible à droite. <br /><img src='https://openweb.eu.org/squelettes-dist/puce.gif' width="8" height="11" class="puce" alt="-" /> ...<br class="autobr" /> Ce qui impliquerait de ne pas prévoir x feuilles de styles pour x largeurs d'écran mais plutôt une feuille de style par module avec ces déclinaisons pour ces points de rupture propres.<br class="autobr" /> Une approche réaliste selon vous ?</p> Définir ses points de rupture 2013-05-07T17:22:09Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1622 2013-05-07T17:22:09Z <p>Bonjour. M'intéressant aux media queries depuis seulement un an ou deux, je ne connaissais pas vraiment les habitudes des pros et j'ai naturellement tourné mes points de rupture en fonction de ma grille : une 12 colones 1000px, que j'ai divisée en 3 points de rupture, le point le plus bas convertit les div en pourcentage. Un peu simpliste comme solution, je me pencherai sur la vôtre.</p> <p>J'aime bien votre solution sur les images. Je testerai.</p> Définir ses points de rupture 2013-05-06T22:39:38Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1621 2013-05-06T22:39:38Z <p>Merci pour cet article ! Pour une fois qu'on a du contenu pertinent sur un blog français :) Je m'en vais creuser dans cette direction pour rendre mon approche du responsive web design plus pertinente...</p> Définir ses points de rupture 2013-04-18T12:38:48Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1601 2013-04-18T12:38:48Z <p>Merci pour cet article. En tant qu'<a href="http://www.pole-integration.fr" class="spip_out" rel='nofollow external'>intégrateur web</a> et dans le cadre de <a href="http://www.pole-integration.fr/integrateur-responsive-web-design.html" class="spip_out" rel='nofollow external'>responsive web design</a>, j'ai plutôt le réflexe d'appliquer un design flexible en deçà d'un seul et unique point de rupture défini par le chef de projet.</p> Définir ses points de rupture 2012-12-10T18:52:01Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1307 2012-12-10T18:52:01Z <p>@Raphaël : merci, autant pour moi !</p> <p>@Mathieu Avons : au final, tu ajustes tes breakpoints en fonction de ton contenu, au sens large du terme — header, navigation, publicités en font partie, même s'ils ne sont pas de l'information principale. Mon exemple paraît simple, mais en réalité, il m'a fallu revenir une ou deux fois sur mes points de rupture. L'article n'a pas été écrit d'une traite ;). Donc oui, c'est un travail qui peut nécessiter plusieurs passes.</p> Définir ses points de rupture 2012-12-10T12:33:14Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1306 2012-12-10T12:33:14Z <p>Je ne suis pas certain que le choix des breakpoints doivent uniquement être déterminé par les contenus (images et textes). Pour les petits sites à faible contenu, peut-être qu'on peut se le permettre dans la mesure ou l'on est capable de déterminer la taille des images, des paragraphes et des titres. Mais quand est il pour un site de news ? pour un site e-commerce ? Dans le cadre de plusieurs refontes de sites en responsive, j'ai rencontré de nombreuses problématiques qui m'ont contraintes à changer plusieurs fois mes breakpoints au cours d'un même projet. J'ai dû prendre en compte les contenus, bien évidemment mais aussi les éléments de navigation (filtres, tris, pagination...) , le header (taille du logo, navigation principale, méga-menu...), du footer et même des formats de publicité pour finalement décider de la position exacte de mes breakpoints... Je pense qu'il est difficile de faire un choix arrêté pour les breaks points au début d'un projet. Je pense qu'on peut les définir grossièrement au départ, mais qu'ils s'affinent au fur et à mesure qu'on avance (lors de la conception, lors du design et lors du code).</p> Définir ses points de rupture 2012-12-10T07:42:33Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1305 2012-12-10T07:42:33Z <p>Nicolas : l'unité "rpx" (pour real pixel) que tu évoques dans ton blog existe déjà : il s'agit de dppx :)</p> Définir ses points de rupture 2012-12-08T19:59:29Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1302 2012-12-08T19:59:29Z <p>Merci Raphaël pour ces précisions et ressources. L'unité em est en effet beaucoup plus pertinente à l'égard du texte. Cela dit on perd un peu le contrôle sur les paliers d'appréciation des images. Dans un soucis de vulgarisation, j'ai fait un choix et me suis tourné vers la solution la plus communément usitée.</p> <p>Je suis également d'accord qu'il y a un réel travail d'amélioration à faire sur les unités de CSS. Il en manque indéniablement, et certaines comme le "px" n'ont plus de sens, <a href="http://bit.ly/11Nea8D" class="spip_out" rel='nofollow external'>comme j'essaie de l'expliquer ici</a>.</p> Définir ses points de rupture 2012-12-08T17:18:07Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1301 2012-12-08T17:18:07Z <p>Salut Nicolas. Joli article en effet :)</p> <p>En le relisant tranquillement, j'ai l'impression que tu ne vas pas au bout de la logique et ton raisonnement.<br class="autobr" /> Je suis entièrement d'accord qu'il est nécessaire de raisonner en terme de contenu et de facilité de lecture, comme tu l'expliques très bien en introduction.</p> <p>Par contre, dans ce cas, pourquoi choisir de se donner des repères en pixel et non dans l'unité parfaitement adaptée pour des tailles de polices... l'unité em ?<br class="autobr" /> C'est ce que HTML5boilerplate a fait et c'est bien expliqué sur cette ressource : <a href="http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/" class="spip_url spip_out auto" rel="nofollow external">http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/</a></p> <p>Au final, ton design sera *vraiment* basé sur le contenu.<br class="autobr" /> Attention, pour moi ce n'est pas une solution magique car dans beaucoup de maquettes graphiques, il faut bien se rendre à l'évidence, le seul critère universel compréhensible à la fois par Photoshop et un être humain demeure le pixel. Mais dans l'absolu, oui pourquoi pas.</p> <p>Pour moi, cet article rejoint celui de Hteumeuleu : <a href="http://www.hteumeuleu.fr/le-probleme-du-responsive-design/" class="spip_url spip_out auto" rel="nofollow external">http://www.hteumeuleu.fr/le-probleme-du-responsive-design/</a><br class="autobr" /> Et selon moi l'unité idéale que l'on cherche existe depuis longtemps : elle s'appelle le cm ou le mm (voire l'inch) et devrait correspondre exactement à ce qu'on attend d'elle.<br class="autobr" /> Sauf que les navigateurs n'en ont cure, même quand on les force à afficher 1px = 1px CSS.</p> <p>Peut-être qu'un jour, quand les unités vh ou dppx seront implémentées, on pourra enfin se tourner vers celle qui est vieille comme le monde : le millimètre.</p> Définir ses points de rupture 2012-12-07T17:07:40Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1300 2012-12-07T17:07:40Z <p>Très bel article, comme je le disais sur twitter, merci d'avoir créé une jolie référence en Français pour ce que je pense depuis un petit moment : placer les points de rupture en fonction du contenu et non en fonction de la taille des périphériques. <br class="autobr" /> J'avais tendance à essayer d'expliquer qu'il vaut mieux placer les breakpoints "quand le layout casse". C'est en fait dire exactement la même chose que de parler du nombre de caractères par ligne, qui sont au final, une manière de "mesurer" (avec de gros guillemets ici, comme tu le dis, ce n'est pas une mesure exacte) quand le contenu sera illisible, et donc que notre layout actuel n'est plus adapté à la taille et disposition du contenu.</p> Définir ses points de rupture 2012-12-07T16:12:44Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1299 2012-12-07T16:12:44Z <p>Très bon article.</p> <p>Moi j'aime bien me représenter les points de ruptures comme des limites de segments. Et je les fixe en fonction du contenu, comme toi, pour m'assurer que tout soit bien lisible et que rien ne casse.</p> <p>C'est là également que la grille fluide prend tout son intérêt, pour ceux qui ne jurent que par les points de rupture.</p> Définir ses points de rupture 2012-12-07T11:41:44Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1298 2012-12-07T11:41:44Z <p>Il est bien de garder en tête un minimum les tailles récurrentes de devices pour ne pas afficher d'aberrations. Mais le contenu prime, quitte à avoir de légères marges latérales. À prendre en compte la cible du site également pour, pourquoi pas, faire un pallier spécifique pour iPad par exemple. Mais si le device importe plus que le contenu, c'est qu'il faut peut être songer à une application native :).<br class="autobr" /> Heureux que cet article te sois utile :) !</p> Définir ses points de rupture 2012-12-07T08:06:21Z https://openweb.eu.org/articles/definir-ses-points-de-rupture#comment1297 2012-12-07T08:06:21Z <p>Super article ! Ça change mon travail sur les images : on peut leur donner un ratio taille/compression optimal puis jouer avec leurs dimensions dans css.</p> <p>En outre, c'est bien mieux de travailler avec des paliers, même si on peut sans doute trouver des "fourchettes" qui englobent un maximum de devices à peu près similaires.</p>