Grid 960 etc...

(reprise du message précédent)

Je viens apporter ma pierre à l'édifice qu'est ce topic...

Pour ma part j'adore les grids, souvent comparé aux carrures et mesures en musique, il permettent d'offrir du rythme et de la prédictabilité. Plus qu'une série de lignes imaginaires, je vois l'emploi des grids comme un moyen de concevoir le placement de tout le contenu d'un site de façon à le rendre homogène, équilibré et lui donner du sense. En d'autres termes, chaque chose a sa place et chaque place a sa chose, et ce de façon réfléchie en amont.

Ensuite je d'accord le fait que ça ajoute de la précision, et que ça facilite le travail d'équipe et la productivité d'avoir un jeu de tailles définies, pas besoin de tout mesurer au pixel prés ou autre...

Là ou je suis moins d'accord c'est par rapport à l'emploi des css frameworks comme 960gs (en production) qui vont à mon avis complètement à l'encontre du but de CSS. Ici on met dans le markup du code qui va changer l'apparence... Un peu comme utiliser <center> quoi et même si ça facilite le travail à première vue, le jour où on veut changer, il faut plonger dans le markup pour aller passer un élément de 3 à 4 colones, alors que l'idée de CSS est justement de ne pas avoir à faire ça...

Celà dit avec des pré-processeurs comme LESS ou SASS par exemple on peut bénificier de ces classes pré-faites sas pour autant "polluer" son markup de .grid_10 tout moches. Et là je dis oui (et je dis même que l'idéal c'est de faire une fonction qui calcule la taille des éléments en fonction du nombre de colones voulues... Tant qu'à faire

D'ailleurs un framework de ce type a fait parler de lui sur le Smashing Magazine il y a peu : http://semantic.gs/ il est présenté comme révolutionnaire, la réalité c'est que j'en avais fait un comme ça avant (rétablissage de vérité) et que je connais beaucoup d'autres développeurs qui l'avaient fait aussi, m'enfin bref c'est pas une catastrophe, ce qui compte c'est qu'il y ait une solution facile d'accès pour ceux qui sont intéressés

Sinon l'idée de grid ça vient pas forcément du print, ça remonte facilement à plus loin, dans une forme plus simple, la règle des tiers est utilisée par exemple dans Mona Lisa et de nombreuses autres techniques utilisant les chiffres en architecture comme le nombre d'or pour Notre-Dame de Paris... Bref utiliser des "limitations" et des chiffres supposés naturels et beau n'est pas une révolution qui vient du print même si ils ont beaucoup contribué à leur évolution...

D'ailleurs pour ceux qui aiment bien sortir leur calculette, on peut aussi avoir des grilles et rythmes typographiques, c'est tout aussi fun.

Enfin pour terminer, créer ses propres grids n'est pas forcément le plus simple, mais c'est pourtant ce qui est le plus sensé à mon goût : designer le contenu, et non pas le faire rentrer dans des cases... Concevoir sa grille en fonction de ce que l'on met dedans plutôt que l'inverse.

Pour ceux que ça intéresse, le livre Grids : Ordering Disorder est assez bien sur le sujet et permet d'apprendre une méthodologie simple mais efficace pour créer ses grids soit même plus les premiers paragraphes qui discutent de l'intérêt d'une telle pratique.

Et pendant que je suis lancé, il y a aussi modularscale.com qui permet de créer des grilles modulaires en utilisant des ratios assez connus, si vous voulez jouer aux scientifiques du pixel... Bref y'a de quoi faire avec les nombres et le design !

a écrit :
Par exemple sur Le monde, si tu regarde bien les photos qui illustrent les articles, elles sont toutes proportionnelles(pour éviter d'avoir à les rogner) et déclinées en 3 tailles(grande, moyennes et petites).

Et à vue d'oeil, largeur = hauteur * 1.618 le Golden Ratio étant 1:1.618 je doute que ça soit un hasard

De nombreux sites utilisent des formats prédéfinis, il y en a vraiment beaucoup... Si ce sujet intéresse quelqu'un qui, en plus, aime bien les graphiques ou a prévu de bosser sur des tableaux et trucs du genre, Designing with Data chez Five Simple Steps traite du sujet (de façon divertissante et poussée) et un joli chapitre est consacré à l'utilisation des maths dans le design en général... Suite de Fibonacci, Silver Number, formats de papier internationaux, j'en passe et des meilleures...

Vue que je suis parti à balancer des liens, on trouve aussi http://www.webdesignerdepot.com/2010/07/using-landmarks-makes-page-layout-easy/ qui est plus sur l'utilisation d'images avec les grids mais c'est intéressant à lire... Bref y'a trop à dire pour caser le tout dans un seul post sans provoquer une hécatombe due à l'ennui des éventuels lecteurs donc je vais m'arrêter là
Modifié par HammHetfield (04 Sep 2011 - 21:04)

Il faut quand même prendre un peu de recul vis à vis la sacro-sainte culture de la sémantique HTML/CSS.

Et surtout, je crois qu'il faut être en mesure de considérer différentes avenues dans la manière d'utiliser la sémantique.

Tout d'abord, oui les grilles incluent du code non - ou peu - sémantique. Ceci serait nuisible puisque l'idée de base des CSS est que nous pourrions construire n'importe quelle site à partir d'une feuille CSS - et au final ne changer que la CSS lors de multiples refontes.

Mais dans la réalité, les choses ne se passent pas réellement ainsi. Si on peut totalement changer le design d'un site en changeant les CSS, cela n'est pas aussi vrai pour la structure d'un site.

La manière dont les blocs sont structurés et présentés est intrinsèquement lié à la disposition des nos éléments HTML. On ne pourra pas ramener une sidebar de manière propre dans le footer sans modifier notre fichier .html

Et mon constat sur ce point est que la structure d'une page (l'emplacement des blocs et son layout général) est directement lié à la structure du HTML. À partir de là, est-il réellement correct de s'opposer à l'ajout de classes à des blocs HTML gérant l'affichage ? Je ne le crois pas, et c'est un peu dans ce sens que va le principe d'OOCSS (Object-Oriented CSS) de Nicole Sullivan.

J'étais assez froid au début au principe de créer plus de sémantique en produisant un code HTML moins sémantique. Mais en y regardant de plus près, plusieurs principes tombent sous le sens et me semblent au final répondre à plusieurs besoins de base de l'intégrateur.

Je vous invite vivement à en lire un peu plus sur le projet. Ce dernier propose une feuille de style de base, c'est plus ou moins intéressant, mais c'est le principe qui est très important!

http://oocss.org/
https://github.com/stubbornella/oocss/wiki/faq

Je suis d'accord sur le fait qu'il faille prendre du recul... Néanmoins je pense qu'avec l'arrivée des nouvelles balises HTML5 et les nouveautés css3, on se rapproche de plus en plus d'un markup "sans" ajout qui n'a pas besoin d'être fait en fonction du design final, mais tout simplement comme il devrait être codé de façon sémantique...

Ca veut dire moins d'éléments qui ne servent qu'à la déco, facilité de placer les éléments autrement qu'ils n'apparaissent dans le markup etc etc... A partir de là, je ne vois pas pourquoi l'idée de gérer toute l'apparence dans le css et le contenu dans le html ne serait pas possible.

Et puis en fonction des sites sur lesquels on bosse, on a pas toujours à tout refaire, parfois ce n'est qu'une partie qui a besoin d'un petit coup de frais ou d'une amélioration... Si y'a pas besoin de toucher au contenu, je trouve ça dommage de le faire pour changer des class dans le markup.

En fait, je suis d'accord avec toi, sauf au niveau de la structure/layout.

Dès qu'on veut changer un élément de place, on devra modifier son code HTML. (on s'entend, pas si on veut changer une sidebar de gauche à droite, mais une modification un peu plus complexe)

Oui, cela se fera en CSS (table-header-group, etc), mais ce sera sans aucun doute beaucoup plus complexe à la relecture que le simple fait de changer un bloc div d'endroit dans sa page HTML.

Cela dit, le principe de l'OOCSS n'amènera pas nécessairement l'intégrateur à retravailler le code HTML. Mais à retravailler un "objet CSS", un module indépendant de ses voisins en autre mot.

Et les classes seront évidemment le plus sémantique possible. Par exemple, les couleurs pourraient être gérés ainsi:

.light-color{}
.normal-color{}
.dark-color{}

Alors en cas de changement de palette de couleur, on n'aurait qu'à modifier notre feuille CSS des différents types de couleur.

Évidemment, il y a à prendre et à laisser. Mais, sur le sujet abordé ici, l'ajout de classe non sémantique en CSS pour la gestion de grille est loin d'être problématique dans l'optique qu'une modification du code HTML sera de toute manière nécessaire lors d'une refonte graphique en profondeur.

Je suis d'accord avec toi pour OOCSS, sur le papier ça semble vraiment intéressant... celà dit quand ça touche au layout... Je sais pas, j'ai pas envie d'avoir des .gird_8 dans mon markup quoi, c'est euh...

Mouai y'a peut être pas de fondement au final, mais perso je préfère utiliser un pré-processeur css qui au final me simplifie le travail pour pas mal d'autre choses que d'utiliser un framework css tel quel. Mais va falloir que je regarde attentivement OOCSS.

HammHetfield a écrit :
Je sais pas, j'ai pas envie d'avoir des .gird_8 dans mon markup quoi, c'est euh...

D'accord avec toi sur le fond. Seulement, OOCSS se destine plutôt à de très gros projet avec forcément plus de contraintes. Un certain pragmatisme est donc de mise.

Et comme le disait @fvsch, osef de la sémantique des classes tant que le markup en lui même reste cohérent.

Florian_R a écrit :
Et comme le disait @fvsch, osef de la sémantique des classes tant que le markup en lui même reste cohérent.

.grid_8 -> 8 unités relatives à la largeur de la grille, y'a pire comme sémantique, sachant que 960 px pour la grille de base mais il y a plusieurs largeurs disponibles et le nom des classes ne change jamais.

En passant : http://978.gs/ vraiment très bien pour remplacer 960.gs
Modifié par jb_gfx (06 Sep 2011 - 00:03)

Victor BRITO a écrit :
Bref, comme le dit judicieusement le W3C : (...)

Gaffe quand tu dis «le W3C». Ce n'est pas une spec. Contre-citation qui va bien (dans la même page):

a écrit :
While the tips are carefully reviewed by the participants of the group, they should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications.

Une classe "blueborder" peut être beaucoup plus pertinente que warning, ça va dépendre du projet.

Et si tu expliquais pourquoi tu as galéré et mis 3 fois plus de temps ?

c'est bizarre parce que normalement tu galères moins, vu que t'as des dimensions précises, t'y vas pas au tatonnement.

En même temps tu as pas utilisé les grilles comme c'est prévu, donc forcément au moment de coder, ça aide pas...

Tu n'as pas divisé les gouttières en deux, donc forcément tu t'es retrouvé avec des dimensions dans ton design qui n'étaient pas celles prévues par le framework... Les repères devraient être sur les bordes des colones rouges (intérieur de la colonne) et au milieu des bandes blanches (milieu de la gouttière)...