Le problème avec inline-block c'est que ton bloc est considéré un peu comme du texte, donc comme tu as un retour à la ligne entre tes deux blocs, c'est considéré comme un espace et ça fait merder le calcul des dimensions. Si tu colles les deux balises entre elles ça devrait aller.
Si tu tiens à garder ton indentation, tu peux utiliser float à la place, ou display: flex (attention à la syntaxe pour les versions préfixées), mais pour deux balises c'est pas très grave.
Note que tu ne devrais pas utiliser la balise Section comme tu le fais. Utilise un div.
Bof, ce serait foncièrement inutile ici, et je suis contre l'ajout de balises sémantiques inutiles.
En fait je ne vois que très peu de cas où on pourrait utiliser main et section. À chaque fois que je vois main, c'est l'unique contenu de la page (un genre de conteneur global) ce qui n'est pas ce à quoi il devrait servir et n'a pas de sens (c'est le contenu principal comparé à quel contenu secondaire ?). Et dans tous les autres scénarios que je m'invente, j'utiliserais aside pour identifier le contenu secondaire plutôt que main pour identifier le "vrai contenu pour de vrai". Quant à section c'est pareil : c'est censé être une section d'un élément indivisible (dans le sens où, présenté en dehors de son contexte, le contenu de section n'aurait pas de sens)... va trouver un cas où diviser un élément indivisible est plus pertinent avec section qu'avec un simple div. Je ne vois qu'une réplique dans une conversation éventuellement. (genre Openclassrooms a tout faux, il te met un section.comments dans un section.mainSection dans un section.mainContent... bravo)
Je pense que, à moins d'avoir un besoin particulier, réel, qui saute vraiment à la gueule, il vaut mieux se contenter de article, header, aside et éventuellement footer. Il faut arrêter de mettre des balises kikou juste parce qu'elles existent.
Élimine tout de suite cette horreur de ton code, et de tes habitudes.
@ConcombreRouge: main est juste le bloc référent du contenu principal d'une page. Je ne vois pas ce qui te gêne là-dedans ? Définir ce qui est le contenu principal ?
OK pour le one-page, je n'y avais pas pensé, c'est vrai que ce sont des parties distinctes mais qui, sorties du contexte de la page, perdraient de leur sens.
Par contre pour main c'est pas compliqué : elle ne sert à rien cette balise. On n'en a jamais eu besoin. Si le but est de remplacer les div#center ou div#container à la racine des sites c'est pas une raison suffisante pour créer une nouvelle balise. Si tu dois parser une page, c'est pas dur de trouver où est le contenu principal : c'est celui qui est dans le body et puis c'est tout. S'il y a plusieurs contenus (genre "les clients qui ont acheté ce produit on aussi regardé ces produits" ou "lire les autres résultats de recherche pour « j'ai un drôle de bouton sur le zizi »") c'est qu'ils sont secondaires, et on a une balise pour dire qu'un truc est secondaire : aside, donc pas besoin de main non-plus.
Non, le contenu "principal" n'est pas "tout ce qui se trouve dans body", sinon on part du principe que le footer est le contenu principal. Main a pour rôle de définir le corps de la page, tout simplement.
Du reste, aside ne sert pas à définir du "contenu secondaire", mais à définir un élément en corrélation avec le contexte. Par exemple, les infobox à droite sur les articles wikidedia sont de parfaits aside.
- Edité par EmmanuelBeziat 3 septembre 2016 à 17:22:35
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Pour rappel, section et article doivent contenir un titre (hn, pourquoi pas dans un header), ce qui n'est pas le cas de main. Ça en dit long sur ce qu'est réellement main : ce n'est pas un contenu (qui aurait besoin d'un titre), ce n'est pas un "super-article" qui serait le principal, c'est un bête conteneur qui, certes, englobe un contenu, pour définir que le contenu qu'il englobe est le principal. En tout cas c'est comme ça que je l'ai compris.
Deuxième chose, header et footer ne sont pas des contenus : le header est l'en-tête d'un contenu, le footer donne des informations supplémentaires sur ce contenu. Donc il faut bien que ces balises se rapportent à quelque chose. Elles n'ont pas de sens seules, elles sont définies par le fait qu'il existe un contenu auquel elles se rattachent. En l'absence de article ou section, ce contenu c'est body, ce qui veut dire en fait qu'il s'agit du header et du footer du site, en fait.
(avec autant de divs où tu veux, pour des questions de mise en pages, ça n'a pas d'intérêt de le noter)
C'est tout à fait valide, et c'est tout à fait suffisant. La balise article indique que ce qu'il y a dedans est un contenu complet (et pourrait être extrait du reste de la page tout en gardant tout son sens). Si body a un seul article comme premier enfant (significatif) c'est bien, de facto, le contenu principal de la page (et, pour le coup unique, mais dans ton exemple aussi il n'y a qu'un seul contenu complet). S'il n'y a pas d'article du tout, c'est body le contenu principal. Il n'y a pas à tortiller.
Si tu veux un contenu secondaire maintenant, tu peux faire ça
Je ne dis pas qu'il est faux d'utiliser main, mais dans ton exemple main ne sert à rien du tout parce que header et footer ne sont pas des contenus, il n'est pas utile de filter ce contenu par rapport au "vrai contenu pour de vrai". En fait les cas où main a un intérêt sont probablement quasi inexistants.
Autre point : je ne pense pas (à confirmer) que main puisse se substituer à article, donc si je devais accepter l'usage de main dans ton code, j'écrirais ça
À noter qu'il est bizarre d'utiliser une class, ou même un id, sur la balise main, puisque main doit être par définition unique. Il peut être sélectionné par son nom de balise.
Bon désolé j'ai édité 50 fois et je vais m'arrêter là parce que je m'arrache les cheveux avec l'éditeur de code, c'est vraiment de la #°@_!
- Edité par tabouretBleu 3 septembre 2016 à 19:05:52
En aucune façon, non. Ça n'a absolument rien d'obligatoire.
Donc il faut bien que ces balises se rapportent à quelque chose
Oui, à body comme tu l'as dit. Ça ne veut pas dire qu'il faut nécessairement qu'ils en soient un descendant direct.
Si tu veux un contenu secondaire maintenant, tu peux faire ça
Là non. Tu pourrais très bien avoir un aside dans chaque section. Voire plusieurs par section.
dans ton exemple main ne sert à rien du tout parce que header et footer ne sont pas des contenus
Main n'a pas à "servir" à quelque chose. Son rôle, c'est de se trouver à cet endroit de la page, tout simplement. Comme toutes les autres balises sémantiques, rien ne t'oblige à les utiliser, mais rien ne t'en empêche non plus, à partir du moment où leur utilisation est légitime par rapport à leur rôle. Le rôle de main, c'est d'encadrer le contenu principal de la page. Si tu as des doutes sur son utilité, rien ne t'empêche de soumettre ton avis au W3C (chacun peut être acteur au sein du web !) ; mais en attendant, la norme suggère son utilisation de telle façon, alors on l'utilise de telle façon.
html est une balise facultative, ça n'empêche personne de la mettre.
À noter qu'il est bizarre d'utiliser une class, ou même un id, sur la balise main, puisque main doit être par définition unique. Il peut être sélectionné par son nom de balise.
C'est le principe de "separation of concern". Le CSS n'a pas à se soucier de quelle balise il s'agit. "main" pourrait être une balise main, une div, un article, un tableau ou n'importe quoi. Ce n'est pas son problème, c'est le problème du html. C'est (entre autres) sur ce genre de principe que reposent BEM, OOCSS, et d'autres conventions de nommage. On n'appelle une balise générique que pour lui définir des comportements de base. Tout "style" est défini via des classes.
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Donc il faut bien que ces balises se rapportent à quelque chose
Oui, à body comme tu l'as dit. Ça ne veut pas dire qu'il faut nécessairement qu'ils en soient un descendant direct.
Je ne comprends pas ta remarque. Si ils sont descendant d'une autre balise dite de "sectioning content" (article, section, nav) ils se rapporteront à cette balise. Dans tous les cas, qu'ils se rapportent à body ou autre chose, et c'est mon propos : ce n'est pas du contenu, c'est du méta-contenu si tu préfères, il n'y a pas de risque de "confusion" avec du contenu. Si je développe dans mon coin un navigateur qui parse du HTML et que je cherche à identifier du contenu, je ne risque pas de confondre le header avec un contenu.
rhooManu a écrit:
Si tu veux un contenu secondaire maintenant, tu peux faire ça
Là non. Tu pourrais très bien avoir un aside dans chaque section. Voire plusieurs par section.
S'il fallait une preuve qu'on n'est pas sur la même longueur d'onde c'est celle là : aside prend pour référence le contenu qui l'encadre, donc si tu mettais un aside dans chaque section, ce serait du contenu secondaire relatif à chaque section, ce qui n'empêche pas d'avoir un contenu secondaire relativement à la page : c'est ça qui est génial avec aside et qui rend main complètement inutile. Tu ne peux avoir qu'un seul main dans une page pour dire que c'est ton "vrai contenu principal pour de vrai", mais en fait il suffit d'avoir un article au premier niveau de la page et un aside à côté pour que le article soit considéré comme un main et le aside comme un contenu secondaire qui n'a rien à voir avec article (puisqu'il n'est pas dedans : il est relatif à son parent). main est rigoureusement inutile dans ce cas particulier.
rhooManu a écrit:
dans ton exemple main ne sert à rien du tout parce que header et footer ne sont pas des contenus
Main n'a pas à "servir" à quelque chose. Son rôle, c'est de se trouver à cet endroit de la page, tout simplement. Comme toutes les autres balises sémantiques, rien ne t'oblige à les utiliser, mais rien ne t'en empêche non plus, à partir du moment où leur utilisation est légitime par rapport à leur rôle. Le rôle de main, c'est d'encadrer le contenu principal de la page. Si tu as des doutes sur son utilité, rien ne t'empêche de soumettre ton avis au W3C (chacun peut être acteur au sein du web !) ; mais en attendant, la norme suggère son utilisation de telle façon, alors on l'utilise de telle façon.
html est une balise facultative, ça n'empêche personne de la mettre.
Bien-sûr que si main doit servir à quelque chose : on n'invente pas des balises qui ne servent à rien. la balise main a été crée pour le cas où une page aurait de multiples contenus différents et où l'on souhaiterait mettre en valeur celui qui, par exemple, correspond à l'URL. Le fait qu'une page contienne des contenus différents est en soit une connerie d'après moi mais passons, dans certaines applications ça peut avoir du sens, en tout cas pas dans une page web classique. Si on me donne un lien pour voir un truc, je ne veux voir que ce truc là et pas autre chose, même si j'apprécierai effectivement que, s'il y a autre chose dans la page, ce ne soit pas complètement le bordel et que je puisse retrouver rapidement ce que j'étais venu chercher parce qu'il aura été mis dans un main.
Ensuite, une balise sémantique n'a pas à se trouver à un endroit dans la page. Il ne faut pas appeler footer tous les blocs qui se trouvent en bas, header ceux qui se trouvent en haut et aside ceux qui se trouvent sur le côté : ces balises ont une signification qui n'a rien à voir avec la position qu'on leur donne généralement. La balise main n'est pas une exception. Ce n'est pas parce que tu as un conteneur qui te sert à centrer ton site (ou que sais-je) que ça justifie l'usage de la balise "main". La balise main a été inventée pour autre chose.
html a beau être facultatif pour faire plaisir aux auteurs, les navigateurs l'ajoutent quand même pour avoir un élément documentElement, qui lui est nécessaire. Heureusement que les valises xml et svg ne sont pas facultatives aussi parce qu'on devrait se fier au type mime pour identifier le document. C'est pas des plus pratique, moi je préférais quand la balise html était obligatoire, ça rendait l'identification de documents html plu simple.
rhooManu a écrit:
À noter qu'il est bizarre d'utiliser une class, ou même un id, sur la balise main, puisque main doit être par définition unique. Il peut être sélectionné par son nom de balise.
C'est le principe de "separation of concern". Le CSS n'a pas à se soucier de quelle balise il s'agit. "main" pourrait être une balise main, une div, un article, un tableau ou n'importe quoi. Ce n'est pas son problème, c'est le problème du html. C'est (entre autres) sur ce genre de principe que reposent BEM, OOCSS, et d'autres conventions de nommage. On n'appelle une balise générique que pour lui définir des comportements de base. Tout "style" est défini via des classes.
Bon ça c'est ta popote. Pourquoi pas. Personnellement je trouve plus pertinent d'utiliser un id quand l'élément doit être unique, ou rien du tout quand la balise doit être unique. Que des frameworks ajoutent une couche d'abstraction en plus, c'est leur problème mais ça amène aussi à des dérives, notamment dans les systèmes de grille, où on va donner 50 classes à une balise pour définir un style précis, ce qui est en rupture avec le principe de séparation du code HTML et CSS vu que finalement l'attribut HTML class contient un "raccourci" vers du CSS, raccourci qu'il faut changer quand on veut changer l'aspect du document.
Note que, j'ai beau avoir un avis très.. euh.. "épidermique" sur le sujet, j'apprécie la qualité de l'échange
- Edité par tabouretBleu 3 septembre 2016 à 21:05:50
Ben ton lien est très clair sur ce sujet : " Each section shouldbe identified ". Ça n'a rien d'obligatoire, donc. C'est un conseil de "bonne utilisation" ; ce qui est le même principe que pour main : on "conseille" de l'utiliser.
Je ne comprends pas ta remarque. Si ils sont descendant d'une autre balise dite de "sectioning content" (article, section, nav) ils se rapporteront à cette balise.
Oui, mais ta remarque portait sur la balise div que j'avais mise, à laquelle tu substituais un article, non ? Ou alors, je n'ai pas compris de quoi tu voulais parler.
Dans tous les cas, qu'ils se rapportent à body ou autre chose, et c'est mon propos : ce n'est pas du contenu, c'est du méta-contenu si tu préfères, il n'y a pas de risque de "confusion" avec du contenu. Si je développe dans mon coin un navigateur qui parse du HTML et que je cherche à identifier du contenu, je ne risque pas de confondre le header avec un contenu.
Tout à fait. Mais je ne vois toujours pas en quoi ça pose un problème ? Ce n'est pas pour une question de risque ou de confusion, c'est pour une question de rôle.
ce qui n'empêche pas d'avoir un contenu secondaire relativement à la page : c'est ça qui est génial avec aside et qui rend main complètement inutile. Tu ne peux avoir qu'un seul main dans une page pour dire que c'est ton "vrai contenu principal pour de vrai", mais en fait il suffit d'avoir un article au premier niveau de la page et un aside à côté pour que le article soit considéré comme un main et le aside comme un contenu secondaire qui n'a rien à voir avec article (puisqu'il n'est pas dedans : il est relatif à son parent). main est rigoureusement inutile dans ce cas particulier.
Non, je n'arrive toujours pas à voir en quoi une balise aside rendrait main inutile. Il n'y a pas d'histoire de "contenu vrai de vrai" : main, c'est comme body : body indique le contenu affichable, main indique l'élément de contenu principal du site. Je ne vois pas pourquoi tu t'entêtes à le comparer avec un article. Mettre toute une page dans un article n'aurait aucun sens, ça voudrait dire "le contenu de cette page est indépendant de cette page".
la balise main a été crée pour le cas où une page aurait de multiples contenus différents et où l'on souhaiterait mettre en valeur celui qui, par exemple, correspond à l'URL.
Ben, non ? Elle a été créé pour mettre le contenu de la page. Il n'est à aucun moment question de "contenu différents" ou "multiples".
Je cite le w3c : "The main element formalises the common practice of identification of the main content section of a document using the id values such as 'content' and 'main'.". En un mot comme en cent : la balise main a été créée pour remplacer le fait d'avoir une div sans aucun sens sémantique à laquelle on attribuait généralement un rôle d'accessibilité. (http://www.w3.org/TR/2012/WD-html-main-element-20121217/)
Bon ça c'est ta popote. Pourquoi pas. Personnellement je trouve plus pertinent d'utiliser un id quand l'élément doit être unique, ou rien du tout quand la balise doit être unique. Que des frameworks ajoutent une couche d'abstraction en plus, c'est leur problème mais ça amène aussi à des dérives, notamment dans les systèmes de grille, où on va donner 50 classes à une balise pour définir un style précis, ce qui est en rupture avec le principe de séparation du code HTML et CSS vu que finalement l'attribut HTML class contient un "raccourci" vers du CSS, raccourci qu'il faut changer quand on veut changer l'aspect du document.
Alors non par contre, ce n'est pas "ma" popote ; c'est celle de très nombreux devs, qui ont travaillé à résoudre les problèmes inhérents à la structure même du CSS, et ont cherché une façon la plus optimale possible de produire du code maintenable et réutilisable. Tout le monde n'a pas fourni la même réponse à ces problématiques (c'est notamment de là qu'est né l'extrême "Atomic CSS"), alors plusieurs "guidelines" ont été éditées, testées, améliorées, approuvées. Je n'ai rien inventé, j'ai adopté ces pratiques.
J'ai mis du temps à comprendre moi-même leur intérêt, ayant appris à "l'ancienne école" où on faisait des déclarations CSS à rallonge avec deux ID, trois classes et 5 balises imbriquées, et j'ai soutenu que c'était une bien meilleure façon de faire, que le CSS avait ces possibilités pour une raison, et qu'il suffisait d'une bonne organisation pour s'en sortir convenablement. Mais à force de travailler sur des projets de plus en plus important et d'être confronté de plus en plus souvent aux problèmes soulevés, j'ai fini par essayer. Aujourd'hui, je ne pourrais plus faire autrement. Je commence à me mettre au scope de CSS que permettent les frameworks comme React ou Vue, afin d'éliminer progressivement toute trace de ces problèmes en "modularisant" complètement les différentes portions d'une app.
Ces syntaxes sont d'autant plus importantes aujourd'hui, alors que la plupart des fichiers CSS sont découpés en différents fichiers Sass / Less / Stylus / PostCSS, et qu'il est d'autant plus complexe de vérifier un problème d'héritage. Ce le sera d'autant plus dès que les variables natives de CSS, qui ont un grand pouvoir d'héritage, commenceront à être massivement adoptées.
J'ai fait un condensé de mes découvertes, avec les problèmes et leur solution, pour aider mes co-workers à comprendre et adopter BEM eux aussi, si ça t'intéresse : Guidelines/CSS/BEM.
Note que, j'ai beau avoir un avis très.. euh.. "épidermique" sur le sujet, j'apprécie la qualité de l'échange
La même pour moi
- Edité par EmmanuelBeziat 4 septembre 2016 à 4:57:46
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Pas du tout d'accord sur les titres dans les section et article : tu passes directement à la fin de la page en sautant le plus important sections and articles with missing headings result in an outline with a malformed heading hierarchy. Les éléments body, article, section, nav et aside sont des balises qui structurent le document et qui constituent un arbre hiérarchique. Même si tu t'en fichais que les niveaux de titre soient mélangés, une synthèse vocale va identifier ces éléments par un titre qu'elle va annoncer. Si body n'a pas de titre, elle dira "document sans titre", ce qui est emmerdant (mais bon c'est rare qu'on oublie le header principal), si nav n'a pas de titre, elle dira un truc genre "navigation" (ça encore ça va) par contre si une section, article ou aside n'a pas de titre elle va dire un truc comme "barre latérale" ou "section sans titre" ou "contenu sans titre" et là, comment veux-tu avoir une vision d'ensemble de la page ? Ça servait à quoi d'ajouter des balises sémantiques de sectionnement si c'est pour rendre la page moins accessible que quand elle n'en avait pas ?
Si tu penses que ta section n'a pas besoin de titre c'est que ce n'est pas une section. Si je reprends le template de one page que tu m'as montré, toutes les sections ont un titre, et à raison.
rhooManu a écrit:
Je ne comprends pas ta remarque. Si ils sont descendant d'une autre balise dite de "sectioning content" (article, section, nav) ils se rapporteront à cette balise.
Oui, mais ta remarque portait sur la balise div que j'avais mise, à laquelle tu substituais un article, non ? Ou alors, je n'ai pas compris de quoi tu voulais parler.
Non, en fait j'ai aucun problème avec les divs. Au niveau sémantique les divs et spans n'existent pas, je les ai enlevé de ton code machinalement pour mettre en valeur les niveaux hiérarchiques. Le but n'était pas de la remplacer. On est d'accord que header et footer ne se rapportaient pas au div mais à body.
rhooManu a écrit:
Dans tous les cas, qu'ils se rapportent à body ou autre chose, et c'est mon propos : ce n'est pas du contenu, c'est du méta-contenu si tu préfères, il n'y a pas de risque de "confusion" avec du contenu. Si je développe dans mon coin un navigateur qui parse du HTML et que je cherche à identifier du contenu, je ne risque pas de confondre le header avec un contenu.
Tout à fait. Mais je ne vois toujours pas en quoi ça pose un problème ? Ce n'est pas pour une question de risque ou de confusion, c'est pour une question de rôle.
En fait si : le rôle "main" a pour objectif de remplacer les liens "skip navigation" en identifiant ce qui est le contenu, en opposition au header et à la barre de navigation du site, car il y avait un vrai risque de confusion : tu allais sur une page, il y avait un titre (celui du site), une liste (des liens de navigation) que tu n'avais pas besoin de lire à chaque fois que tu changeais de page. Et le navigateur ne pouvait pas juste ignorer le premier titre et la première liste de la page (qui auraient pu être du vrai contenu), donc on avait réellement besoin de balises de sectionnement pour identifier ce qui est un contenu, un header, une barre de navigation, etc. Le risque de confusion existait réellement.
Sauf qu'on a une balise pour identifier un contenu (article), un header (header) et une barre de navigation (nav). Si je programme un navigateur maison et que je veux permettre à l'utilisateur de passer la navigation et d'aller directement au contenu (ce que fait la balise main), je n'ai qu'à ignorer les header et nav qui sont au premier niveau hiérarchique du site. Aujourd'hui, c'est facile, il n'y a pas besoin de main (dans une page normale).
Je sais que tu pètes et répètes qu'il n'est pas utile d'avoir "besoin" d'une balise pour l'utiliser. Je ne suis pas d'accord : quand on définit un langage, la nécessité d'un élément du langage n'est pas un point de détail, ici il y a quelque chose de redondant et qui peut pousser à négliger la hiérarchisation correcte de la page parce qu'on se repose sur main pour faire le boulot.
rhooManu a écrit:
ce qui n'empêche pas d'avoir un contenu secondaire relativement à la page : c'est ça qui est génial avec aside et qui rend main complètement inutile. Tu ne peux avoir qu'un seul main dans une page pour dire que c'est ton "vrai contenu principal pour de vrai", mais en fait il suffit d'avoir un article au premier niveau de la page et un aside à côté pour que le article soit considéré comme un main et le aside comme un contenu secondaire qui n'a rien à voir avec article (puisqu'il n'est pas dedans : il est relatif à son parent). main est rigoureusement inutile dans ce cas particulier.
Non, je n'arrive toujours pas à voir en quoi une balise aside rendrait main inutile. Il n'y a pas d'histoire de "contenu vrai de vrai" : main, c'est comme body : body indique le contenu affichable, main indique l'élément de contenu principal du site. Je ne vois pas pourquoi tu t'entêtes à le comparer avec un article. Mettre toute une page dans un article n'aurait aucun sens, ça voudrait dire "le contenu de cette page est indépendant de cette page".
la balise main a été crée pour le cas où une page aurait de multiples contenus différents et où l'on souhaiterait mettre en valeur celui qui, par exemple, correspond à l'URL.
Ben, non ? Elle a été créé pour mettre le contenu de la page. Il n'est à aucun moment question de "contenu différents" ou "multiples".
Je cite le w3c : "The main element formalises the common practice of identification of the main content section of a document using the id values such as 'content' and 'main'.". En un mot comme en cent : la balise main a été créée pour remplacer le fait d'avoir une div sans aucun sens sémantique à laquelle on attribuait généralement un rôle d'accessibilité. (http://www.w3.org/TR/2012/WD-html-main-element-20121217/)
Bon, là on arrive au coeur du problème et il y a eu effectivement mécompréhension.
Pour commencer, tu ne cites pas le W3C en entier : remplacer un div par main juste parce qu'on a la flemme de mettre une class (surtout quand des gens comme toi lui mettent de toute façon une class), ça aurait été encore plus bête pour le coup, et je sais que cette seule raison n'aurait pas poussé le W3C à créer une balise. C'est bien pour lui endosser par défaut le rôle "main".
Le discours du W3C ne reflète pas les débats qui ont eu lieu pour ajouter la balise main (parce qu'on a eu article, section, aside et nav avant d'avoir main, et ça fonctionnait très bien comme ça).
Il n'était pas juste question de skipper le menu de navigation (qu'on mettait de toute façon le plus souvent après le contenu dans le HTML pour des questions de référencement, et aussi effectivement de tab index, et qui était maintenant clairement identifié grâce à nav). La question était de tenir compte d'applications qui présentaient plusieurs contenus en même temps, ce qui posait des problèmes de référencement et d'accessibilité (les mêmes qu'avec les frames en fait, mais de façon opposée : au lieu de tomber sur une section de contenu en dehors de son contexte, on tombe parfois sur un méli-mélo et on a du mal à trouver l'information qu'on avait pourtant vu dans la description du lien dans le moteur de recherche).
C'est un problème qui est toujours d'actualité, qui a de multiples causes (pratiques douteuses de référencement et mauvaise utilisation du JS en général) et qui n'est pas prêt de disparaître, mais au moins j'aurais compris qu'il pousse le W3C à faire quelque chose parce que ça a un impact réel sur l'accessibilité du web.
À noter quand même que, bien que main ne soit effectivement pas présenté aujourd'hui comme une réponse à ce problème (my bad, je n'ai mêm epas eu l'idée de vérifier), il le règle quand même partiellement en forçant le focus sur une partie de la page. Donc OK, j'ai tort de penser que, si une page n'a pas plusieurs contenus, elle n'a pas à utiliser main, cette balise a une acception plus large, mais j'espère avoir montré que le rôle "main" est redondant avec les balises de sectionnement du HTML5.
Du coup, je ne sais pas si je dois développer mon point sur aside vu que ça répond finalement à une problématique qui dépasse la définition actuelle de main, mais pour résumer : il y a toujours une ambiguïté (qui n'est même pas réglée par main, c'est navrant) quand tu balises une page, sur le fait que le titre de premier niveau soit considéré comme le titre du site ou le titre du document. Par convention, les enfants directs de body concernent le site, et puisque les enfants direct d'une balise de sectionnement (comme article) vont concerner cette balise de sectionnement, ça implique que la balise article située au plus haut niveau dans la page soit considérée comme le contenu de la page, et pas du site entier (si on mettais un nav dans ce article, ce serait par exemple le sommaire de la page et pas le menu de navigation du site).
Donc si, ça a du sens d'avoir un article comme premier enfant de body, au même niveau que le header, nav et footer. Ça lève une ambiguité. Dans ton exemple de one page, je ne dirais pas qu'il est faux de ne pas mettre de article parce que le site et la page sont confondus (c'est un one page) mais c'est quand même un cas particulier.
rhooManu a écrit:
Bon ça c'est ta popote. Pourquoi pas. Personnellement je trouve plus pertinent d'utiliser un id quand l'élément doit être unique, ou rien du tout quand la balise doit être unique. Que des frameworks ajoutent une couche d'abstraction en plus, c'est leur problème mais ça amène aussi à des dérives, notamment dans les systèmes de grille, où on va donner 50 classes à une balise pour définir un style précis, ce qui est en rupture avec le principe de séparation du code HTML et CSS vu que finalement l'attribut HTML class contient un "raccourci" vers du CSS, raccourci qu'il faut changer quand on veut changer l'aspect du document.
Alors non par contre, ce n'est pas "ma" popote ; c'est celle de très nombreux devs, qui ont travaillé à résoudre les problèmes inhérents à la structure même du CSS, et ont cherché une façon la plus optimale possible de produire du code maintenable et réutilisable. Tout le monde n'a pas fourni la même réponse à ces problématiques (c'est notamment de là qu'est né l'extrême "Atomic CSS"), alors plusieurs "guidelines" ont été éditées, testées, améliorées, approuvées. Je n'ai rien inventé, j'ai adopté ces pratiques.
J'ai mis du temps à comprendre moi-même leur intérêt, ayant appris à "l'ancienne école" où on faisait des déclarations CSS à rallonge avec deux ID, trois classes et 5 balises imbriquées, et j'ai soutenu que c'était une bien meilleure façon de faire, que le CSS avait ces possibilités pour une raison, et qu'il suffisait d'une bonne organisation pour s'en sortir convenablement. Mais à force de travailler sur des projets de plus en plus important et d'être confronté de plus en plus souvent aux problèmes soulevés, j'ai fini par essayer. Aujourd'hui, je ne pourrais plus faire autrement. Je commence à me mettre au scope de CSS que permettent les frameworks comme React ou Vue, afin d'éliminer progressivement toute trace de ces problèmes en "modularisant" complètement les différentes portions d'une app.
Ces syntaxes sont d'autant plus importantes aujourd'hui, alors que la plupart des fichiers CSS sont découpés en différents fichiers Sass / Less / Stylus / PostCSS, et qu'il est d'autant plus complexe de vérifier un problème d'héritage. Ce le sera d'autant plus dès que les variables natives de CSS, qui ont un grand pouvoir d'héritage, commenceront à être massivement adoptées.
J'ai fait un condensé de mes découvertes, avec les problèmes et leur solution, pour aider mes co-workers à comprendre et adopter BEM eux aussi, si ça t'intéresse : Guidelines/CSS/BEM.
Bon là on est davantage sur la même longueur d'onde que tu ne penses, mais je trouve que ta guideline est un peu malhonête dans le sens où elle oppose le BEM à un homme de paille : tu présente des comportements d'intégration qui sont absolument débiles. Il est évident que n'importe quelle pratique vaut mieux que mettre une class "blue" à un élément HTML. Je trouve bien des intérêts à ta pratique : la facilité que l'on peut avoir à surcharger un sélecteur vu qu'il n'y a qu'un sélecteur par style par exemple, c'est vrai que c'est un problème en CSS, mais je suis moins convaincu par le reste parce que tu n'opposes pas de contre-exemple crédible.
Le principe de séparation du HTML et du CSS a été violé avec certains frameworks CSS : les systèmes de grille par exemple, qui vont mettre des classes pour identifier des colonnes, lignes, etc. ce qui fait que si tu veux changer le nombre de colonnes, tu es obligé de modifier le HTML en changeant de class, et si tu veux utiliser une media query... bah tu peux pas à moins de la détecter en JS et de changer la class. c'était déjà une mauvaise pratique au moment même où ça a été inventé, ça n'aurait jamais dû exister, personne n'aurait jamais dû l'utiliser, mais c'est là et ça a encouragé des comportements qui sont pénalisants pour la maintenance et pour la lisibilité du code.
Bon par contre, je ne comprends pas en quoi c'est mal d'écrire ".humain .main .gauche" (hormis le fait que sur une page HTML tu pourrais décider que l'élément qui est à gauche serait finalement plus joli à droite, ce qui devrait décourager l'utilisation d'adjectifs dans les noms de classe, mais là on parle d'un humain latéralité et qui a bien un côté gauche et un côté droit qui sont fixes).
Je comprends l'argument qu'un bout de CSS peut être décontextualisé et que tu perds la notion de qui est dans quoi mais en fait pas vraiment : il suffit de ne jamais écrire ".gauche" tout seul (à moins qu'il y ait une propriété que .gauche aura dans absolument toutes les situations, pourquoi pas). C'est ça qui provoque le besoin d'écraser des styles en surchargeant : le fait qu'il y ait un style inapproprié par défaut.
Et puis tu dois sûrement dupliquer des propriétés en n'utilisant pas l'héritage, ce qui rend le code moins maintenable si tu fais une modification (qu'il faut reporter ailleurs).
Mon métier c'est directeur artistique, je conçois des chartes graphiques à longueur de temps. la notion d'héritage est essentielle. Quand je lis des trucs comme ceci dans ta guideline, ça me titille :
.article.title {
margin-top: 20px;
}
Par définition un h3 et un h4, et à fortiori si le h4 est en plus descendant d'un bloc (qui doit sûrement donner un autre contexte de mise en page) doivent avoir, intrinsèquement, des marges différentes. Il ne fallait pas écrire cette règle au départ et c'est tout.
Dans mon logiciel de mise en pages (indesign) il n'y a pas de sélecteurs. Je sais ce que ça fait de bosser avec un truc qui n'a pas la flexibilité du CSS, et c'est une horreur. Je suis obligé de faire ce que tu fais : j'ai par exemple un style "h2", "p + h2", "h1 + h2", "img + h2", etc. juste pour définir le style d'un titre de niveau 2 (heureusement un style peut hériter d'un autre, donc je ne suis pas obligé de redéfinir la taille de la police pour "p + h2", je peux demander à "p + h2" d'hériter de "h2" et simplement changer la marge supérieure) mais je suis quand même obligé d'appliquer à tous mes titres de niveau 2 le bon style, manuellement, en fonction de la situation pour avoir les bonnes marges ! C'est MERDIQUE. Vraiment, tu ne te rends pas compte. J'ai essayé une fois d'écrire un script pour que ça se fasse tout seul, mais ça équivaut à écrire un parseur HTML (en pire parce que Indesign ne fonctionne pas vraiment pareil), c'est trop de taf, j'ai autre chose à faire...
Peut-être que tu n'as pas les mêmes exigences de mise en pages que moi mais ta méthode serait extrêmement limitante pour moi parce que, évidemment, je n'imposerai à personne de baliser le HTML avec autant de précision, ce serait un merdier sans nom, donc je créerais des règles moins précises et le résultat sera moins bien. Ton système a des limitations créatives que tu sous-estimes je pense (ou alors j'ai pas compris un truc)
Aussi, il y a un problème avec les IDE : en programmation orientée objet, ton IDE te donne des infos sur l'objet, les propriétés qu'il a hérité d'autres objets, etc. il y a souvent une représentation hiérarchique des objets dans le script, ou des éléments dans une page HTML, mais en tout cas dans Komodo IDE je n'ai rien trouvé de tel pour le CSS : il m'affiche tout au même niveau (ça permet quand même de retrouver une règle relativement rapidement mais ce serait 50 fois mieux avec un arbre).
Ta solution de noms à rallonge peut régler ça sur un mauvais IDE comme le miens en classant les class par ordre alphabétique, ce qui va naturellement regrouper les parents entre eux, mais sur un bon IDE qui serait capable de faire une vrai hiérarchie, ça casserait au contraire cette fonctionnalité et on perdrait un outil précieux.
Je suis convaincu que c'est du côté logiciel qu'il faut régler ces problèmes de représentation hiérarchique des règles CSS. On a une notion de projet dans les IDE, ils pourraient compiler toutes les feuilles de style liées au document et représenter les niveaux hiérarchiques. Je suis convaincu que ça règlerait tous les problèmes de maintenance.
Là par contre, ça devient trop long, je ne suis plus.
Juste, pour en revenir sur BEM, le problème d'écrire .humain .main .gauche : le poids de la déclaration. Avoir des déclarations à rallonge oblige à créer d'autres déclarations encore plus lourdes pour pouvoir surcharger le CSS. C'est exactement à cause de ça qu'on se retrouve avec des :
#main #content .bloc-left .widget.top h2
Juste pour pouvoir rajouter un border ou une couleur différente à
#main #content .bloc-left .widget h2
C'est de la surenchère permanente, et encore une fois, si pour une raison X ou Y le markup change, alors toute ces déclarations sautent.
Les mecs de putaindecode.io sont un peu extrêmes dans leur discours, mais le problème est très bien résumé ici (et avec des exemples que tu trouveras peut-être moins "malhonnêtes" que ceux que j'ai utilisés) : http://putaindecode.io/fr/articles/css/stop-css/
Mais encore une fois, ce n'est pas un truc sorti de nulle part pour faire plaisir à deux ou trois intés qui ne "comprennent pas bien" le CSS et ses notions :
Ah mais plus j'en lis plus j'ai l'impression qu'ils n'ont rien compris. La spécificité par exemple, c'est le truc le plus utile qui existe en CSS : une charte graphique ça s'établit toujours du cas général au cas particulier, c'est providentiel que le CSS fonctionne comme ça aussi.
Par exemple, tu vas dire des choses telles que "un titre doit commencer par une lettrine" "sauf lorsque le corps de texte est trop petit, dans ce cas là, la première lettre sera en gras" (je dis n'importe quoi mais tu vois le principe). On a bien un cas général qui est le cas recommandé, et un amendement au cas général quand il n'est pas adapté. De cette façon, à chaque fois que j'écris un titre il a toujours sa lettrine sauf quand c'est pas adapté. Pas besoin d'aller spécifier pour chaque élément de la page comment doit s'afficher le titre. C'est charté, on n'a pas à y toucher, et si on y touche c'est dans la définition la moins spécifique possible, et l'effet de "régression" sera justement celui recherché.
Alors, je ne dis pas que dans un design tout se conçoit relativement à la charte graphique, mais regarde les exemples que tu me donnes : à quel moment ça semble une bonne idée d'écrire "#main #content .bloc-left .widget.top h2" ? C'est une entité logique qu'on doit cibler en CSS, pas un aspect visuel (positionnement avec .bloc-left et .top) ou un élément HTML en particulier (#main et #content représentent quoi comme type de document ? un Q&R ? une publicité ? un catalogue ? non, des éléments de page qui effectivement peuvent disparaître).
Moi je pense que si les intégrateurs ont des problèmes avec la spécificité c'est bien parce que ce sont des intégrateurs et pas des designers. Ils n'ont aucune idée de comment on conçoit une identité visuelle, ils ne font que du cas particulier, bloc par bloc, et le fait de préférer des sélecteurs directs en est la preuve.
- Edité par tabouretBleu 4 septembre 2016 à 19:39:47
Ben non, justement : ils font l'ensemble du site, et c'est précisément parce qu'ils le font qu'ils se rendent compte des problèmes liés à ça.
Après, tu tiques à chaque fois sur un exemple de code, mais ce sont des exemples, juste des exemples. Ils sont volontairement exagérés (encore que, pas toujours) pour mettre en lumière le problème.
Après, je ne sais pas où tu bosses, je ne sais pas sur quoi, je ne sais pas comment ; je ne peux pas me permettre de juger des problématiques que tu rencontres (et ce n'est pas mon but). Mais je serais curieux de voir ton approche sur le boulot que je fais moi, et sur les problèmes qui m'ont amenés à comprendre où tous ces gens voulaient en venir.
Ah mais plus j'en lis plus j'ai l'impression qu'ils n'ont rien compris.
Ça, c'est très rarement bon signe.
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Ben non, justement : ils font l'ensemble du site, et c'est précisément parce qu'ils le font qu'ils se rendent compte des problèmes liés à ça.
Ce n'est pas ce que je voulais dire : oui, ils font toute la page ou tout le site, mais ils pensent le code de façon séquentielle, bloc par bloc alors qu'ils utilisent un langage qui fonctionne par héritage. Ce n'est ni idiomatique du langage, ni en harmonie avec la logique d'une charte graphique. Pour moi le principe même de cette méthode n'est pas adapté au job, et ça c'est un mauvais signe aussi.
C'étaient pas des guignols ceux qui ont pensé au CSS. C'est vrai qu'il y a eu des erreurs de parcours (notamment concernant les animations et autres nouveautés CSS3), mais le principe de base est très puissant. Quand je lis l'auteur de putaindecode, il fait ce que tu me reproches : plus il se renseigne plus il trouve que rien ne va et qu'il faut tout changer. Sauf que lui va à contre-courant.
Ce n'est pas une question de guignol, mais d'évolution. Le CSS, quand il a été inventé, n'était pas pensé pour la complexité des webapps d'aujourd'hui.
Pourquoi les animations et nouveautés CSS3 seraient des erreurs, d'ailleurs ?
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
C'est pas un argument, c'est une conclusion. Je ne peux pas être convaincu par une conclusion. J'émets de sérieux doutes quant à la complexité graphique des webapps, et je parle en tant que designer. Les webapps sont peut-être très compliquées, mais dans leur fonctionnement. Par contre, c'est vrai qu'il manque encore des fonctionnalités en CSS, qui sont ajoutées. Les flexbox sont un très bon exemple de mise à jour du CSS pour faciliter le responsive design.
Si c'est pas clair : le div devrait commencer à grossir et à tourner dès le début. Et si tu passes la souris dessus quand il se remet à tourner (j'aurais pu trouver une autre transformation pour le :hover mais je manquais d'inspiration) tu vois que ça annule aussi la rotation (mais bizarrement pas le scale)
Il y a une incompatibilité entre les deux animations et la transition qui a lieu en :hover parce que transform peut prendre plusieurs transformations, mais du coup si elles ont une origine différente tu ne peux pas les concaténer correctement, donc transform est écrasé.
Et c'est pareil pour plein d'autres propriétés qui peuvent se chaîner : par exemple, les multiple backgrounds c'est génial sur le principe, mais en pratique tu ne peux pas enrichir un élément avec un deuxième background à un autre endroit du code (par exemple avec un background généré côté serveur ou par canvas).
En bref c'était une mauvaise idée de chaîner comme ils l'ont fait, mais ils ne voulaient / pouvaient pas implémenter un genre d'array dans lequel tu peux ajouter et supprimer des valeurs dynamiquement par un identifiant (un genre de addEventListener en CSS).
C'est pas dramatique parce qu'en Javascript, justement, tu peux créer un tel array et prendre en compte une foule d'intéraction utilisateur pour le mettre à jour et additionner plein de transformations de façon totalement indépendante, sauf que ça demande de la bidouille.
Là je pense que le groupe de travail sur le CSS a merdé.
Autre problème (beaucoup plus grave, et là je pense qu'en tant qu'utilisateur de framework tu seras d'accord) : les media queries sont daubées parce qu'elles tiennent compte de la taille de l'écran et pas de la taille du bloc, ce qui ne permet pas d'écrire des modules puisque le code est relatif à la page et pas au module en question. C'est franchement dommage.
Aussi, elles encouragent de très très mauvaises pratiques en définissant des "stop" arbitraires ou dépendant d'un device précis, ce qui n'est pas pérenne parce que la résolution et la taille d'écran des devices évolue, donc ces dimensions fixes finiront par être obsolètes.
Il y a des projets pour palier à ça basés sur du JS qui interprète la feuille de style : https://github.com/marcj/css-element-queries c'est un problème qui n'a rien de trivial donc on peut comprendre que ce ne soit pas arrivé tout de suite mais, enfin, ça fait un moment qu'on a les media queries et ce script s'en sort bien...
Autre erreur de parcours : dès le départ, le CSS a décidé que la résolution d'un écran était de 72 ou 96 dpi (je sais plus), ce qui fait qu'on ne pourra jamais utiliser de dimensions en cm dans une feuille de style parce que la conversion en cm est codée en dur et ne variera sans doute jamais pour des questions de retro-compatibilité.
Ça a pourtant beaucoup plus de sens aujourd'hui de travailler en cm puisqu'on a des écrans de taille et de résolution très variée et que c'est beaucoup plus naturel de penser un design en fonction de sa taille d'affichage réelle plutôt qu'en pixels.
Alors on a dppx mais il y a encore un souci : la valeur de grandissement donnée par les navigateurs rétina est souvent mauvaise parce que, pour être compatible avec les media query (on se mort la queue...) ils annoncent une taille de viewport qui n'est pas réelle (le développeur du téléphone décide arbitrairement quelle taille sera donnée au viewport), et le relation est calculé d'après cette taille plutôt qu'en fonction de la densité de pixels réelle du device. En gros, ça donne une vague idée du grossissement, mais jamais avec dppx on pourra afficher une photo d'un objet qui fait 5cm par exemple et dire "quelque soit le device sur lequel tu regardes cette photo, l'objet fera 5 cm, règle en main", ce qui pourrait être très intéressant, mais non, ça a mal été pensé dès le départ et on est un peu bloqué.
Enfin tout ça c'est relativement mineur comparé à la puissance du CSS. Je me répète mais, pour utiliser des logiciels qui n'ont pas ce système, je me rends vraiment compte de son intérêt et ça m'attriste de voir des projets de framework qui chient sur tout ce que je trouve bien dans ce langage.
Du coup, dans ce que tu décris, ce n'est pas l'idée de faire des animations en CSS qui pose problème, c'est juste la façon dont c'est implémenté. Ta phrase n'était pas claire en ce sens, d'où ma question.
Autre problème (beaucoup plus grave, et là je pense qu'en tant qu'utilisateur de framework tu seras d'accord) : les media queries sont daubées parce qu'elles tiennent compte de la taille de l'écran et pas de la taille du bloc, ce qui ne permet pas d'écrire des modules puisque le code est relatif à la page et pas au module en question. C'est franchement dommage.
Euh, je n'utilise pas de frameworks… ?
Par contre, oui, c'est dommage que les media queries ne permettent pas davantage de choses. De là à dire que c'est daubé, c'est aller un peu loin. Rien ne dit qu'une amélioration à ce niveau n'est pas possible, voire à l'étude. On ne peut pas trouver "le" truc parfait sans mettre en place des éléments petit à petit d'abord. Du reste, il est très rare que je me dise "c'est vraiment dommage que je ne puisse pas appliquer le responsive sur la taille de l'élément lui-même". Ça a dû m'arriver deux fois en 6 ans, et c'était parce que le graphiste qui avait fait la maquette l'avait pensé façon print ; mais il est vrai que quand le cas c'est posé, le fait de le gérer était compliqué.
- Edité par EmmanuelBeziat 5 septembre 2016 à 0:06:20
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
C'est parce que tu es habitué aux media query, mais si tu y réfléchis, on n'aurait jamais dû en avoir besoin. La taille du navigateur n'a aucune importance en soit puisque tout est dynamique. Ce qui importe c'est que les éléments que tu mets dedans aient assez de place en toute circonstance, et ça, ça se décide au niveau de du module. Ce n'est pas du tout une logique print, qui elle est centrée sur des dimensions fixes, au contraire.
Plus tôt tu me parlais de modules réutilisables (ou c'est un de tes liens, pour le coup je ne sais plus). La définition actuelle des media query est à 100% contradictoire avec ce principe, parce que tout ce que tu fais dans ton media query est relatif à la la mise en page du reste du document et var devoir être refait sur un autre projet. Tu ne peux pas, comme en OOP, fournir ton module auto-suffisant qui se prend en charge tout seul, qui met à jour sa mise en page, etc. (enfin, pas sans JS).
Centrer le responsive design sur la taille du navigateur est d'après moi une erreur de conception, c'est pour ça que j'utilise un vocabulaire un peu abusif.
Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.
Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre. En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.
Au lieu de déterrer un sujet il est préférable :
soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"
soit de créer un nouveau sujet décrivant votre propre contexte
ne pas répondre à un déterrage et le signaler à la modération
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 !
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 !