5160 sujets

Le Bar du forum

Less/Sass - Layout via table-cell

Pages :
(reprise du message précédent)

Oui, et avec un lecteur vocal on aura droit avant chaque item "ligne 1, colonne 2", ça dois être passionnant de naviguer la dedans Smiley langue enfin maintenant ça dépend où on met les priorités ^^.

De plus le concept de grille est un concept de présentation alors qu'ici on parle bien sémantique. Sémantiquement c'est une liste d'image, visuellement c'est une grille d'accord, mais ça c'est en CSS.

Enfin c'est un débat sans fin je crois Smiley langue
Gili a écrit :
Oui, et avec un lecteur vocal on aura droit avant chaque item "ligne 1, colonne 2", ça dois être passionnant de naviguer la dedans Smiley langue enfin maintenant ça dépend où on met les priorités ^^.

De plus le concept de grille est un concept de présentation alors qu'ici on parle bien sémantique. Sémantiquement c'est une liste d'image, visuellement c'est une grille d'accord, mais ça c'est en CSS.

Enfin c'est un débat sans fin je crois Smiley langue


Ben si tu veux un exemple concret imagine un puzzle ou un jeu de taquin. C'est une grille composée d'images donc tu utilises un tableau. Si tu crées une liste et que tu fais flotter les éléments pour former une grille. Visuellement (avec CSS) c'est OK mais au niveau sémantique tu as tout faux. Si tu désactives CSS ton puzzle ne voudra plus rien dire.
jb_gfx a écrit :
Ben si tu veux un exemple concret imagine un puzzle ou un jeu de taquin. C'est une grille composée d'images donc tu utilises un tableau. Si tu crées une liste et que tu fais flotter les éléments pour former une grille. Visuellement (avec CSS) c'est OK mais au niveau sémantique tu as tout faux. Si tu désactives CSS ton puzzle ne voudra plus rien dire.
Rofl !

Effectivement, dans ce contexte, tu as raison ^^.

J'ai été élevé aux standards contrairement à certains d'entre vous qui ont connu la période des tableaux de mise en page. Résultat j'ai tendance à diaboliser (car on me l'a appris comme ça) l'utilisation des tableaux lors d'un usage qui sort du contexte habituel. Mais merci pour ce contre exemple, je vais pouvoir frimer en soirée maintenant Smiley lol
Hermann a écrit :
Quant à la mise en page via display:table-..., maintenant qu'il est possible (via un fichier htc) pour IE6/7 d'utiliser ces valeurs de display, est-ce qu'il n'est pas préférable finalement de se passer des bloc flottants avec les problèmes qu'on leur connait. D'autant plus que la logique de fonctionnement d'un layout a base de display: table-machin me semble plus proche de celle du futur grid module.


Je reviens juste sur la question de départ (pas bien compris le lien avec Less/Sass d'ailleurs) : j'ai justement refait tout mon futur folio avec un body{ display:table } et tout ce qui suit, et la morale de l'histoire c'est que j'en ai quand-même bien chié. Smiley smile

J'ai essayé de me battre avec IE7 pour traduire ça en float en dégradant pas mal (comme certains autres ici j'aime pas beaucoup les .htc), et au final j'ai carrément abandonné l'idée d'arriver à un truc qui singerait ne serait-ce que vaguement la tête du layout. Et j'ai fini par servir une CSS ultra minimaliste aux vieux IE.

Si c'était à refaire, pas sûr que je referais comme ça donc... ou j'attendrais peut-être que les parts de marché d'IE7 rejoignent celles d'IE6.
Merci pour ces retours.


STPo a écrit :

Je reviens juste sur la question de départ (pas bien compris le lien avec Less/Sass d'ailleurs)

Aucun, c'était juste pour éviter de créer 2 topics à la fois Smiley cligne

STPo a écrit :

j'ai justement refait tout mon futur folio avec un body{ display:table } et tout ce qui suit, et la morale de l'histoire c'est que j'en ai quand-même bien chié. Smiley smile

Oui difficile de tout repenser en matière de table-... et comme je le disais plus haut, il manque l'équivalent des rowspan/colspan en CSS, c'est le seul inconvénient à mon avis, d'ailleurs je me demande pourquoi ça n'a pas été ajouté à CSS2 (puisqu'ils les valeurs table-machin existent).
Les table permettent de faire des choses impossibles avec les flottants (colonne de même hauteur, gouttières via border-spacing...), enfin tu connais ça.
Et puis comme les flottants, ils créent un nouveau contexte de formatage bloc, ce qui éviter de reporter les marges verticales des blocs enfants en dehors du table.

Pour la part, je n'aime pas trop la logique de fonctionnement des flottants (qui n'ont jamais été conçu pour du layout)...
Je n'y avais pas pensé mais on peut effectivement remplacer du table par du flottant uniquement pour IE7-, ceci dit je pense que ça doit être assez prise puisque le fonctionnement table/flottant est très différent.

STPo a écrit :

J'ai essayé de me battre avec IE7 pour traduire ça en float en dégradant pas mal (comme certains autres ici j'aime pas beaucoup les .htc), et au final j'ai carrément abandonné l'idée d'arriver à un truc qui singerait ne serait-ce que vaguement la tête du layout. Et j'ai fini par servir une CSS ultra minimaliste aux vieux IE.
C'est sûr qu'HTC (qui repose sur du JS) n'est pas idéal aussi bien en terme d'accessibilité que de perfs.
Modifié par Hermann (11 May 2012 - 22:04)
Tout le monde s'accorde pour dire qu'un .htc ce n'est pas une bonne solution, pourquoi (je n'en ai jamais utilisé dans la pratique) ?

Florian_R a écrit :
ça tue la perf sur des navigateurs déjà pas au top sur ce point.
C'est à dire ?
Hermann a écrit :
c'était juste pour éviter de créer 2 topics à la fois

Tu aurais peut-être dû en créer deux, le troll Less/Sass pollue ce sujet intéressant ! Smiley lol

Hermann a écrit :
Pour la part, je n'aime pas trop la logique de fonctionnement des flottants (qui n'ont jamais été conçu pour du layout)...

Clairement on détourne une propriété en concevant tous nos layout avec float, et moi aussi j'ai toujours trouvé ça contre-nature. Mais en l'absence de mieux (et avec moins de n'importe quoi sémantique que les layouts en table tout de même), je m'y tiens pour le moment.

Hermann a écrit :
Je n'y avais pas pensé mais on peut effectivement remplacer du table par du flottant uniquement pour IE7-, ceci dit je pense que ça doit être assez prise puisque le fonctionnement table/flottant est très différent.

Je pense que je ferai un petit case-study quand je sortirai mon nouveau site, mais oui c'est totalement infernal, et c'était assez prévisible...

Gili a écrit :
Tout le monde s'accorde pour dire qu'un .htc ce n'est pas une bonne solution, pourquoi (je n'en ai jamais utilisé dans la pratique) ?

>
Hermann a écrit :
C'est sûr qu'HTC (qui repose sur du JS) n'est pas idéal aussi bien en terme d'accessibilité que de perfs.


Gili a écrit :

Florian_R a écrit :
ça tue la perf sur des navigateurs déjà pas au top sur ce point.

C'est à dire ?

C'est à dire que IE6 et IE7 peinent déjà comme des morts pour afficher des sites modernes (parce que leurs moteurs de rendu sont très largement périmés) et que les gaver avec des scripts supplémentaires ne fait logiquement qu'aggraver les choses.
Dans "dégradation gracieuse", il y a "dégradation" : essayer d'obtenir un rendu identique avec 50 patchs dégueus, c'est à la fois se prendre la tête et desservir l'utilisateur.
STPo a écrit :

C'est à dire que IE6 et IE7 peinent déjà comme des morts pour afficher des sites modernes (parce que leurs moteurs de rendu sont très largement périmés) et que les gaver avec des scripts supplémentaires ne fait logiquement qu'aggraver les choses.
Dans "dégradation gracieuse", il y a "dégradation" : essayer d'obtenir un rendu identique avec 50 patchs dégueus, c'est à la fois se prendre la tête et desservir l'utilisateur.

C'est sûr qu'avec tous ces palliatifs (notamment le IE7.js de Dean Edwards qui est assez lourd, respond.js pour les media quieres...), mieux vaut éviter d'en rajouter.
Je crois que je vais tester la solution des flottants uniquement pour IE7-. Aprés il y a aussi la solution des layout via inline-block mais ça n'a pas été conçu pour ça non plus.
Je préfère reserver inline-block et les flottants aux petites portions d'éléments à l'intérieur d'un layout à base de table-cell/row...
Modifié par Hermann (12 May 2012 - 13:33)
Personnellement, j'utilise SASS/Compass depuis un bon moment et je ne commence aucun projet sans aujourd'hui.

J'ai préféré SASS (mode SCSS) à LESS car utilisant Ruby, il est bien plus complet (bien que LESS a une syntaxe légèrement plus élégante). Actuellement, LESS veut laisser la possibilité d'inclure ses fichiers directement dans le navigateur, cela lui empêche d'utiliser un niveau technologique plus bas. Cela dit, si un jour LESS se décide à être compilé côté serveur via Node.js, les deux risques d'être équivalent en terme de fonctionnalités. Ce n'est malheureusement pas encore le cas.

Les avantages de préprocesseurs sont quand même nombreux:
- Séparation du code CSS en plusieurs fichiers (finit les CSS de 4000 lignes)
- Facilite l'utilisation des préfixes navigateurs (pas d'excuse d'oublier Opéra)
- Permet d'intégrer rapidement des fix pour les bugs courant d'IE 6-7 (les clearfix, inline-block, etc)

Au niveau de SASS, ce qu'il y a aussi de très utile que LESS n'a pas :
- Générateur d'images sprites
- Générateur de Data-URI

Il y aussi d'autres petits trucs, mais ce sont réellement les deux plus utiles. Pour le reste SASS et LESS s'équivalent à mon sens.
salut,

pour ne réagir que sur display.

display:table et Cie ? pourquoi ?
alignement vertical ou colonne ou englober les flottants ou bien ... ?


Il ne faut pas généralisé et relancer un troll <table> contre display en mélangeant HTML et CSS.

Pour les colonne, on a aussi column-count ou les fond (colonnes factices) ou
styler un tableau html réduit au minimum.

Pour l'alignement vertical on a aussi display:inline-block;(qui a l'avantage de jouer sur le haslayout des vieux IE et le contexte de formatage pour tout les autres, donc un comportement trés similaire, si ce n'est identique et de fait facile à gerer )
il ya aussi inline-table (ressemble peut-etre trop au flottant ? mais s'en sortir du flux) ou run-in .

Pour les bidouilles IE7 et inf , heu !?
Le display "incompatible" serait un mauvais choix à la base quelque soit le navigateur ?
La volonté de tordre ces vieux coucou a une raison qu'il ne comprennent pas sans imaginer qu'une alternative simple ou sans correction , ça le fait aussi ?

Penser que "display:table; est une solution universelle de mise en page garantie(comme l'imagine le debutant avec le position:absolute; par exemple) est une erreur . ce n'est rien d'autre qu'une option parmi d'autres et ça sert pas a faire du ... hmm? ... pixel perfect ou autre fausse idée que l'on se fait? .

display:table; , c'est le display par defaut de <table>, inline-block de <img>, <input>, .. list-item de <li>... , bref ça sert quand même a décrire/appliquer un aspect et comportement visuel et si on y a accès via les feuille de styles , pourquoi s'en passer, ça sert a ça , Non ?.

float et display ont tellement de raisons/contextes d'application qu'il n'est raisonnablement pas possible d’éradiquer l'un pour l'autre. Et pis IE6 et 7 ont vraiment tout plein de bugs aussi avec les float ...
Faire un choix quand il faut plutôt que de le faire une fois pour toute me parait plus logique.

Si l'on se contente de float parce qu’on le maitrise , il n'y aucune honte ou contre indication a mon sens. Pour les display:machin-chose; , ça finira par venir Smiley smile (avec ou sans dInosaurEs ).
C'est une histoires de compromis et pas de bonnes pratiques, il n' y a pas a privilégier plus l'un que l'autre.

Je croyais display:table; entrer dans les moeurs et compris, apparemment, non Smiley smile ou bien c'est moi ?
@Vaxilart Merci pour ce retour


gc-nomade a écrit :

Pour les colonne, on a aussi column-count ou les fond (colonnes factices) ou
styler un tableau html réduit au minimum.

C'est pas fait pour structurer visuellement une page mais seulement pour des colonnes de texte.

gc-nomade a écrit :

il ya aussi inline-table (ressemble peut-etre trop au flottant ? mais s'en sortir du flux) ou run-in .

Je me suis jamais trop intéressé à ses valeurs car leur intérêt me semble être mineure, d'ailleurs run-in et compact ne sont pas encore implémentés par Firefox. Quant à inline-table j'en sais rien.

gc-nomade a écrit :

La volonté de tordre ces vieux coucou a une raison qu'il ne comprennent pas sans imaginer qu'une alternative simple ou sans correction , ça le fait aussi ?

Phrase incompréhensible.. et les points d’interrogation faut pas en abuser Smiley cligne

gc-nomade a écrit :

Penser que &quot;display:table; est une solution universelle de mise en page garantie(comme l'imagine le debutant avec le position:absolute; par exemple) est une erreur . ce n'est rien d'autre qu'une option parmi d'autres et ça sert pas a faire du ... hmm? ... pixel perfect ou autre fausse idée que l'on se fait? .

C'est une solution parmi d'autre mais que pour ma part dans l'absolu, je privilégierais pour la structure de premier niveau du document.

gc-nomade a écrit :

Je croyais display:table; entrer dans les moeurs et compris, apparemment, non Smiley smile ou bien c'est moi ?

Stp, je sais que tu es très compétent mais ne nous fait pas croire que le débat sur ces display est un vieux serpent de mer..
Modifié par Hermann (14 May 2012 - 08:57)
Modérateur
Bonjour, quelques points

D'abord sur LESS/SASS

Vaxilart a écrit :
- Séparation du code CSS en plusieurs fichiers (finit les CSS de 4000 lignes)

Mon CMS me les réunit tout seul comme un grand, du coup je crée plusieurs css sans problèmes.

Vaxilart a écrit :
- Facilite l'utilisation des préfixes navigateurs (pas d'excuse d'oublier Opéra)

Je ne trouve pas que c'est un avantage, si il y a utilisation de préfixe, on utilise une fonctionnalité expérimentale en développement. Leur utilisation doit être réfléchie et mesurée, rendre cela transparent c'est encourager de mauvaises pratiques. C'est d'ailleurs mon problème principal envers ces systèmes.

Vaxilart a écrit :
- Permet d'intégrer rapidement des fix pour les bugs courant d'IE 6-7 (les clearfix, inline-block, etc)

Au passage le clearfix n'est pas un bug d'IE mais une réponse pratique à un comportement standard. Pour le reste on a quelques fixs courant en réserve, ce n'est pas ça qui étend inutilement mon temps de travail.

Au final je comprends les avantages et les intérêts que l'on peut y trouver. Mais je n'ai pas trouvé que ces avantages sont vraiment déterminant par rapport au fait de ne pas l'utiliser. En considérant que l'évolution des css va dans l'avenir rendre des avantages obsolète, je ne considère pas l'avantage d'en changer.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Display: table.

gc-nomade a écrit :
Pour les colonne, on a aussi column-count ou les fond (colonnes factices) ou
styler un tableau html réduit au minimum.

Bien que les column-count ait été dans les premiers modules à recevoir une implémentation expérimentale, à ce jour certains navigateurs n'ont aucun support (ie9) quant aux autres ils ont au mieux un support incomplet.

Sinon effectivement, le futur de css, va nous apporter de vrais moyens de gérer de la mise en page. Si float n'a pas été fait pour faire de la mise en page, display: table non plus… juste pour rendre des éléments sous forme de tableau. Entre-temps, je ne l'utilise que dans les cas où je peux (raisonnablement) choisir les navigateurs supportés (si si ça arrive Smiley langue ). Les raisons des problèmes ont été évoqués.

Cependant, il vaut souvent mieux re-réflechir le visuel pour trouver une solution techniquement simple qui ne pose pas de problèmes. On trouve souvent de la sorte des visuels tout autant qualitatifs qui nous simplifient la vie, voir parfois, des solutions encore plus élégantes!

Quand on a commencé à parler de standards du web, c'était un des arguments, qui ont conquis un certain nombre de designer pour abandonner des solutions comme flash: vu qu'on ne peut pas tout faire, cela évite un peu de faire n'importe quoi! Dans le graphisme, beaucoup (dont moi) considèrent la contrainte comme un gage de créativité et de qualité.
kustolovic a écrit :
Mon CMS me les réunit tout seul comme un grand, du coup je crée plusieurs css sans problèmes.
Le CMS maison, cet instrument du diable (power troll inside).
Parlons LESS donc.

kustolovic a écrit :

Je ne trouve pas que c'est un avantage, si il y a utilisation de préfixe, on utilise une fonctionnalité expérimentale en développement. Leur utilisation doit être réfléchie et mesurée, rendre cela transparent c'est encourager de mauvaises pratiques. C'est d'ailleurs mon problème principal envers ces systèmes.


Oui enfin ça n'a strictement rien à voir avec LESS/SASS, qui restent des outils et sont par définition tributaires de l'utilisation qu'on en fait : mal utilisés (ou inconsciemment), forcément ça fait des mauvaises choses, c'est ce qui différencie un bidouillage amateur d'un boulot professionnel. On peut dire exactement la même chose de n'importe quel outil offrant une couche d'abstraction supplémentaire. Tiens au hasard, jQuery : on peut en faire des choses merveilleuses comme des choses atroces, tout dépend de qui est aux manettes.

kustolovic a écrit :

Au final je comprends les avantages et les intérêts que l'on peut y trouver. Mais je n'ai pas trouvé que ces avantages sont vraiment déterminant par rapport au fait de ne pas l'utiliser. En considérant que l'évolution des css va dans l'avenir rendre des avantages obsolète, je ne considère pas l'avantage d'en changer.

Haha, l'évolution de CSS.
Rendez-vous en 2028 alors...
Smiley lol
Modérateur
Florian_R a écrit :
Le CMS maison, cet instrument du diable (power troll inside).

^^Lorsque j'ai écris cela, je me demandais si cette marque affectueuse envers un des plus utilisé des CMS actuellement porterait à confusion! (power troll destroyed)

STPo a écrit :
Oui enfin ça n'a strictement rien à voir avec LESS/SASS, qui restent des outils et sont par définition tributaires de l'utilisation qu'on en fait : mal utilisés (ou inconsciemment), forcément ça fait des mauvaises choses, c'est ce qui différencie un bidouillage amateur d'un boulot professionnel.

Oui, tu n'as pas tout tord. Au temps pour moi, j'y suis allé un peu fort sur ce point.

STPo a écrit :
Haha, l'évolution de CSS.
Rendez-vous en 2028 alors...

Tous des impatients!

Au final, c'est vrai que sur l'utilisation de ces preprocesseurs je fais un peu le vieux réac' de service. Et que promis, je serai moins catégorique à l'avenir à ce sujet…
Modifié par kustolovic (15 May 2012 - 14:06)
Pages :
Sujet clos
Aller à