Les limites du css

Bonjour,

Globalement, je ne suis pas du même avis que vous.

Jah a écrit :

En règle générale j'arrive en gros à monter une page assez complexe en 2 heures. En xhtml strict (mais uniquement en div) je mets 3 à 4 fois plus de temps et encore c pas nickel au pixel près.

Avec le temps et la maîtrise du XHTML/CSS, ca devrait aller de plus en plus vite. Évidemment, impossible de rivaliser avec des logiciels comme Fireworks qui te génère les découpes HTML en tableaux imbriqués noyés dans une mer de saleté. Ca prend quelques minutes, mais bonjour le bordel au niveau du code. Il faut aussi savoir décrocher. Même si certains éléments ne sont pas au pixel près dans Firefox versus IE, c'est pas grave du tout. Un visiteur ne verra jamais la différence. Si je visite un site, c'est avec l'un ou l'autre, pas les deux en même temps.

Jah a écrit :

Je trouve que les incompatibilités entre les navigateurs semblent montrer les limites du xhtml et css pour l'usage de ts les jours.

Il y a certe plusieurs incompatibilités entre certains navigateurs, mais avec l'expérience, ils sont clairs et facilement réglables. Je ne trouve pas que ca pose une si grande limite aux CSS.

Jah a écrit :

Une intégration avec des hacks dans tous les sens c pas gérable et agréable pour de la production.

J'ai réalisé beaucoup de sites en XHTML et CSS, et jusqu'à ce jour, je n'ai pas utilisé tant de hacks que ca. Tout dépend aussi jusqu'où tu pousse la compatibilité descendante... jusqu'à Netscape 4 peut-être ? Si tel est le cas, là j'imagine pas l'enfer. Personnellement, Netscape 4 pour moi égal aucun CSS (css import). L'utilisateur n'a qu'à se mettre à jour. C'est une question de choix et de philosophie, sauf que là, ce n'est pas le sujet de la discussion. Je ne m'étendrai donc pas la-dessus si je veux terminer ma réponse avant que je m'effondre sur mon clavier.

Jah a écrit :

De plus je pense que l'intégration en XHTML strict ET CSS limite vraiment la création car on est obliger de penser sa maquette pendant la création.

Faux. Rien n'oblige de penser code lorsque tu crée ton interface graphique, pas plus que c'était le cas avec les tableaux de présentation html. J'ai vu des merveilles réalisées en XHTML et CSS, des interfaces que j'aurais trouvé plutôt ardu de réaliser en tableaux de présentation imbriqués. D'ailleurs, je trouve que le codage aux normes et les CSS permettent tout simplement plus de créativité, plus de liberté. J'ajouterais aussi que dans mon cas, la personne qui fait la maquette ne connaît rien ou presque rien au code, ni html, ni css, tableaux ou pas. Enfin si, mais elle n'y pense pas, car c'est pas son job. Les rares occasions qu'elle me demande si la forme ou la position des éléments graphiques complexifie l'intégration, je lui répond toujours que non. Je lui dis de se laisser aller, que je m'occupe du reste. Cette personne fait tout ca dans un logiciel de graphisme, et ensuite c'est moi qui fait l'intégration. Donc CSS ou pas, tableaux ou pas, ne devrait jamais avoir une quelconque influence sur la créativité graphique.

Jah a écrit :

Un client demande par exemple de bouger un bloc c le bordel total. il faudrais repenser la maquette entière.

Pourtant, je me souviens parfaitement du passé, époque où nos interfaces étaient constituées de tableaux imbriqués découpés via Fireworks et compagnie. Lorsque nous voulions déplacer un menu, changer la hauteur d'un bandeau graphique, changer la position d'un élément, c'était le bordel total. Il fallait tout remanier, refaire les découpes, c'était l'enfer. Maintenant, avec une interface bien pensée, bien codée, en XHTML et CSS, les changements s'effectuent en quelques minutes à peine, avec une facilité qui nous fait à chaque fois sourire.

osscour a écrit :

Je pense que tout l'un ou tout l'autre c'est pas ça (pour le moment en tous cas), donc pourquoi pas rester sur une mise en page tableaux plus pratique à mettre en place rapidement et en formatant tout ça en css ?

En effet, CSS n'est pas encore complet (ou plutôt le support de celui-ci dans les navigateurs) et parfois l'utilisation modérée d'un petit tableau de présentation simple, pour des cas très particuliers, peut s'avérer la meilleure solution.

Sans vouloir offenser qui que ce soit ici, surtout que je ne vous connais pas, peut-être que cette difficulté que vous ressentez avec le XHTML et CSS, et que l'impression des limites au niveau créatif relève davantage d'un manque de maîtrise de ces langages. Peut-être que vos anciennes habitudes avec les tableaux nuisent à votre façon d'aborder la conception d'une page en XHTML et CSS.

Donnez-vous un peu de temps, peut-être ?
Amicalement
AMEN
Modifié par Tony Monast (11 Feb 2006 - 16:19)

a écrit :

En effet, CSS n'est pas encore complet et parfois l'utilisation modérée d'un petit tableau de présentation simple, pour des cas très particuliers, peut s'avérer la meilleure solution.

Sans vouloir offenser qui que ce soit ici, surtout que je ne vous connais pas, peut-être que cette difficulté que vous ressentez avec le XHTML et CSS, et que l'impression des limites au niveau créatif relève davantage d'un manque de maîtrise de ces langages. Peut-être que vos anciennes habitudes avec les tableaux nuisent à votre façon d'aborder la conception d'une page en XHTML et CSS.

Donnez-vous un peu de temps, peut-être ?
Amicalement
AMEN

Bonjour,

dans mon cas je suis au courant du css depuis 2000, je l'utilisais en me faisant aider de Dreamweaver 3 à l'époque.

Puis j'ai laissé tombé pendant un moment avant de m'y remettre activement il y a 3 ans (2003) pour nettoyer le code de mes pages en ne gardant que les tableaux et les balises de gras et italiques (plus gras je n'utilisais pas vraiment <i>) .
J'ai à ce moment là externalisé le css tout comme le javascript.

grâce à un ami j'ai découvert openweb (grand merci car on y comprend pas mal de choses qu'on ne trouve pas à lire ailleurs-et j'en ai lu des bouquins, la fnac me connait si bien...-et surtout en français !!!)

là ça fait 3 mois que je me met activement au xhtml strict et site full-css, avec openweb, pompage, ce site et de temps en temps alistapart (quand j'ai le courage de lire de l'anglais).
openweb je l'ai lu et relu (et mis en pratique) au moins 3 fois, pompage aussi je me le suis farci.
Ce site (alsacréation) m'a servi concrêtement à faire passer un des récents projets de portail en css ( et accessibilité) dans la limite de mes connaissances, les autres acteurs restants sur l'ancienne manière de faire.(il y avait alor sencore du tableau en mise en page parfois)

Et pour finir, CSS par Éric Meyer,
CSS 2e édition,
Pratique du CSS (de l'auteur de ce site!),
Zen des CSS

que je lis (me reste à finir juste CSS 2e édition)

Malgré tout ça, tout l'amour (c'est le mot) que je porte au css et au travail bien fait (je suis perfectionniste) je continue à penser qu'on aura du mal à cause :

1-du manque de docs en français (sur des cas de bugs précis et bien pénibles -> voir mon topic http://forum.alsacreations.com/topic-4-11243-1-IE--effets-tranges-de-disparitions-et-placements.html toujours pas résolu)

2-du manque de prise de conscience des utilisateurs d'utiliser des navigateurs qui respectent les standard (Firefox monte et tant mieux !)

3-du manque de réactivité des services informatiques (faire une recherche sur schéma directeur ou lire le livre "Bonjour paresse"
De l'art et de la nécessité d'en faire le moins possible en entreprise
Corinne Maier), je dis ça en l'ayant vécu (et des amis aussi en SSII)


Mais on va y croire !

Le temps de la maturité arrive au niveau web, reste à se tenir informé en lisant, en pratiquant et en testant...sans cesse.

Bonjour,

Cette pratique du découpage de maquette (et son automatisation) repose traditionnellement sur une approche bien précise de la page Web affichée : celle-ci y est conçue et contruite comme une grille, plus ou moins élastique en largeur ou en hauteur, mais dont les lignes sont figées (une ligne comportera toujours dans le même ordre les mêmes cases, quelque-soit les conditions de rendu, ces cases ont entre elles des relations très simples -et du coup limitées-, etc.).

Cette approche traditionnelle typique de l'imprimé a rencontré sur le Web un outil technique qui lui convenait très bien : le tableau de présentation.

La mise en page CSS, malheureusement pour cette approche, n'envisage pas de cette manière la page Web affichée. Ce n'est plus une grille qui la détermine, mais l'interaction fluide de boîtes de différents types (en-ligne, block, inline-block, cells), dont le comportement est fonction de leur contenu, et basé fondamentalement sur le flux (ou sur le degré d'abstraction vis-à-vis de celui-ci : flottants, positionnement, etc). Disons, par rapport au modèle précédent, que les cases de la grille ont acquis leur indépendance, et ont entre elles des relations nettement plus riches (ou complexes). La grille (rassurante) a volé en éclat...

Dans ce cadre, la démarche de "découpage de maquette" est évidemment parfois malaisée. Et tout particulièrement quand on est encore (ce qui est normal) "entre deux approches" : comme le souligne Tony, il s'agit de perdre certaines habitudes (ce n'est pas facile).

Cela dit, il y a un point que l'on oublie souvent : CSS n'exclue pas de conserver cette approche de la "grille", bien au contraire. Le modèle visuel de mise en page des tableaux y est conservé comme une possibilité parmi les autres outils de la palette : mais l'utilisation des display:table, table-row, table-cell etc, qui aurait peut-être totalement changé la manière dont est perçue la difficulté CSS, reste aujourd'hui marginale faute d'implémentation dans IE en particulier. Notons qu'on ignore aussi en grande partie, du coup, quels seraient les dérives éventuelles et les problèmes que pourrait poser une utilisation systématique du modèle de rendu CSS "tableaux" pour les design... C'est un champ encore à explorer.


Pour ce qui est des obstacles mentionnés par osscour:

1. Oui, il faut en passer souvent par les documentations en anglais. Tout comme la langue de référence des spécifications est l'anglais... C'est la langue de travail inévitable.

2. La question des navigateurs plus respectueux que d'autres des standards est en fait un faux problème : le processus de développement des CSS entraîne obligatoirement des implémentations différentes, ou inégales, entre navigateurs. Au stade de Candidate Recommandation, par exemple, où il est implémentable mais non finalisée, un module CSS3 sera choisi par tel fabriquant de navigateur, mais pas obligatoirement par tel autre... Et c'est en fonction de ces implémentations (qui peuvent aussi être divergentes) que la spec sera modifiée en retour (des propriétés seront abandonnées, d'autres modifiées, etc). C'est toute l'histoire du passage de CSS2.0 à CSS2.1...

Même le cas d'un navigateur au développement suspendu pendant plusieurs années, comme IE Windows, doit être vu en partie comme une difficulté "normale". Il y a aura en effet toujours des navigateurs dont le développement sera arrêté alors que leurs implémentations sont inachevées ou décalées par rapport à d'autres, et un temps de latence avant qu'ils ne puissent être gérés par les designers et les intégrateurs comme navigateurs "périmés" : les NS4-IE4 sont clairement "périmés" et ne posent pas de problèmes majeurs, mais nous entrons dans une période où les IE5 Mac et Windows vont être délicats à gérer. Mais ce sera d'abord aux propriétaires de sites (et donc au client) de le faire, car ils sont les seuls à pouvoir faire passer le message aux utilisateurs. Il faudra sans doute beaucoup travailler à sensibiliser les décideurs sur la nécessité de renoncer au rendu CSS de la maquette dans certains navigateurs, et sur la façon de faire comprendre cette décision aux utilisateurs...

Le problème spécifique d'IE6.0 Windows est, de ce point de vue, que Microsoft a suspendu son développement tout en maintenant sa position dominante sur ce marché. Et que le choix de faire d'IE7 un produit d'appel pour Vista va laisser encore à IE6.0 quelques beaux jours devant lui. Là, effectivement, nous sortons de la logique "normale" des implémentations et de l'obsolescence progressive des navigateurs.

Mais, sur le fond : le fait d'avoir à gérer des navigateurs graphiques aux implémentations différentes n'est qu'un des aspects de la nécessité pour un design Web de s'adapter à des multiples conditions de rendu (configuration utilisateur, media, etc). On rejoint l'autre versant du problème : penser au-delà de la maquette un design qui se déclinera dans des conditions de rendu qu'on peut anticiper, mais pas contrôler (le "au pixel près" de Jah va être l'objet d'un renoncement parfois déchirant pour le design traditionnel)

3. L'adoption des techniques XHTML CSS va en effet de pair avec une rédéfinition des métiers.

En conclusion (ouf ! ) : les difficultés évoquées ici ne tiennent pas à des limites de XHTML et CSS pour une utilisation "industrielle" (rapide, rentable, aisée, reproductible, etc). Elles tiennent plutôt au fait qu'on aborde une période de transition entre :
- une première phase où les sites ont été produits de manière artisanale en reproduisant les démarches des medias traditionnels.
- une seconde phase où les démarches vont devoir changer pour prendre en compte les spécificités du media et en exploiter toutes les possibilités.
Modifié par Laurent Denis (11 Feb 2006 - 08:31)

Très bonne analyse de Laurent qui a certainement une bonne expertise de cette techno au vu de la qualité des travaux qu'il a effectué.

Je pense fondamentalelment que le passage au XHTML CSS passe par une évolution du métier de webdesigner (il ne faut tout simplement plus penser de la même manière en css qu'avec de tableaux).

En tout cas ça fait plaisir d'entendre que je ne suis pas le seul à rencontrer des problèmes liés à cette "nouvelle" manière d'intégrer une page.

Ca va peut être rentrer dans mon mini cerveau à force ;o)

Je suis en pleine refonte de mon book et je passe des heures dessus sans trouver de solutions mais je ne me laisse pas abattre, je perciste et je trouverais des aternatives aux problèmes rencontrés ;o)

Merci

a écrit :

En conclusion (ouf ! ) : les difficultés évoquées ici ne tiennent pas à des limites de XHTML et CSS pour une utilisation "industrielle" (rapide, rentable, aisée, reproductible, etc). Elles tiennent plutôt au fait qu'on aborde une période de transition entre :
- une première phase où les sites ont été produits de manière artisanale en reproduisant les démarches des medias traditionnels.
- une seconde phase où les démarches vont devoir changer pour prendre en compte les spécificités du media et en exploiter toutes les possibilités.

Très bonne conclusion (comme très bonne analyse par ailleurs, on reconnait bien le professionnel qui maîtrise!).

On en demande beaucoup au webmaster (qui est de plus en plus obligé d'avoir des connaissances étendues et techniques, et je rajouterais de "communication" pour faire de son mieux afin d'expliquer "ça" aux clients ou à ses collègues qui freineront des 4 pieds en connaissance de cause ou pas).


ça me fait penser à un ami responsable de projet dans une grande SSII qui m'a dis que dans la vraie vie (informatique je veux dire) on est loin du perfectionniste scolaire (et celui voulu pour le respect des standarts et le goût du travail bien fait).

C'est quelque chose qui m'a frappé car j'aime franchement le travail bien fait dans la mesure où je donne le meilleur de moi-même (mon cerveau est limité mais j'essaye de voir les choses au maximum pour éviter des erreurs qui peuvent être évitées, ce pourquoi je remercie des sites bien expliqués et de qualité comme celui-ci ou bien openweb, cointinuez dans cette voie Messieurs !!).

Ce qu'il ma dis c'est que les études montrent que là où la logique dirait "on re-construit le tout bien (codage aux normes, tout externisé, js comme css ou includes php par exemple, relations fonctionnelles )", ce qui est plus efficace, clair et facile à maintenir, le concret veut qu'on ne fait que rafistoller à la va-vite car... ça coûte bien moins cher !
C'est un des aspects du monde du travail qui à mon avis va nous coûter dangereusement.
Je pense à tous ces "accidents" pour lesquels à chaque fois on feind l'étonnement.
Comme les effondrements de stade de foot(montés pour l'occasion), de ponts vers les bateaux, de partie d'aéroport, etc.

La logique d'usine contre le travail de qualité de l'artisan ?

Enfin bon un certain Nielsen disait à un moment que 99% des sites web étaient obselettes...


PS: je n'ai riend ocntre l'anglais, mais avouer que c'est parfois difficile de comprendre les explications.
Je reste profondément emmerdé pour la "guillotine" de mon autre topic, ça décourage un peu du css

osscour a écrit :
Ce qu'il ma dis c'est que les études montrent que là où la logique dirait "on re-construit le tout bien (codage aux normes, tout externisé, js comme css ou includes php par exemple, relations fonctionnelles )", ce qui est plus efficace, clair et facile à maintenir, le concret veut qu'on ne fait que rafistoller à la va-vite car... ça coûte bien moins cher !
C'est un des aspects du monde du travail qui à mon avis va nous coûter dangereusement.

Ah...
- Oui, tout à fait : l'obligation de faire de son mieux dans le "quick and dirty" est parfois difficile à vivre
- Oui encore : c'est un investissement à court terme
- Mais : le "quik and dirty" répond aussi à une certaine rationalité. Mettre ici beaucoup de précautions sur la façon de s'y prendre, mais la validité peut être un facteur de non-qualité. Voir par exemple http://www.temesis.com/article/conformite-surqualite1_fr.html
- Mais encore : ce qui très intéressant, pour le coup, c'est de réfléchir à la manière d'organiser un travail de développement ou de refonte partielle pour optimiser le site afin de pouvoir faire du "bon quik and dirty", c'est à dire préparant l'avenir. ça peut passer par des moyens lourds du type log validator du W3C, mais ça peut passer aussi au niveau CSS, par exemple, par la mise en place de classes de présentation qui seront facilement compréhensibles et utilisables par d'autres intervenants, et qui éviteront les balisages de présentation ou les styles internes...

Là-dessus, il a beaucoup à faire côté méthodologies, et c'est passionants. Plusieurs "Web agencies" et assimilé semblent déjà avoir développé un certain savoir-faire. Mais il est encore très peu publié.
Modifié par Laurent Denis (11 Feb 2006 - 14:17)

moi ce qui m'ennuie assez, ce sont les bouquins (je les citterais pas mais on les reconnaitra si on fréquente ce forum) qui sont à la ramasse et présentent encore de la mise en forme HTML en majuscule et balises FONT.
Le plus étrange (mais je me trompe peut-être ?) c'est le buquin qui va dire que Flash est le standart de diffusion multimédia (c'est le mot standart qui me dérange, j'aurais mis le plug-ins le plus installé sur des ordi et cela en France.)

ça me dérange pour les gens qui débutent et prennent les infos papier pour La Vérité (comme le JT aussi )

j'ai fait du Flash, il y a beaucoup d'avantages qu'on ne retrouve pas ailleurs mais c'est comme pour tout, les mauvais exemples trop nombreux de sites vides et clignotants ont mis en vrac les possibilité d'un outil qui est avant-gardiste (j'attend comme certans un logiciel générant du svg ouvert mais avec des possibilités d'interactivité et de programation du flash).

Ceci dit je ne fais plus que principalement du php et (x)html + css, le flash étant si peu utilisé dans les projets demandés (je ne bosse pas pour des sites de cinémas malheureusement, les sites de films ou autres payent et veulent du multimédia attractif).

Petit ajout, le flash peut s'utiliser avec du xml et des fichiers appelé de temps en temps au lieu de tout fourrer dans le swf...

Donc c'est avec impatience que j'attend des sites sur xhtml et css en français (plus nombreux quoi!) car si j'étais moi,s dérangé par l'anglais je traduirais sans problème (comme le fait pompage, merci au passage) les articles en "bon" français (opposé à celu igénéré par des traducteurs automatique) et aussi l'arrivée du CSS3, la fin de IE tout court (au pire rester que le IE le plus conforme possible !).

osscour a écrit :
moi ce qui m'ennuie assez, ce sont les bouquins (je les citterais pas mais on les reconnaitra si on fréquente ce forum) qui sont à la ramasse et présentent encore de la mise en forme HTML en majuscule et balises FONT

C'est une convention bien ancrée, qui n'est pas sans intérêt, car elle permet de repérer immédiatement les termes de codes cités au fil du texte, avec une plus grande lisibilité qu'une typo monospace, par exemple.

Evidement, un copié collé d'un bloc de code XHTML en majuscules est invalide. Mais évidemment aussi, le copieur-colleur est supposé prendre le temps de vérifier la validité de son code, ou de lire le chapitre 1 du livre X, Y ou Z sur la casse en XHTML.

Ce n'est pas si grave