Code css/xhtml et développement PHP
Un bon codeur css/xhtml et standards, n'est pas forcemment un bon developpeur PHP. Un bon developpeur PHP n'est pas forcemment un bon codeur css/xhtml et standards.
Bonjour
Un bon codeur css/xhtml et standards, n'est pas forcemment un bon developpeur PHP.(l'exemple type est Raphaël Goetter d'Alsacréations)
Un bon developpeur PHP n'est pas forcemment un bon codeur css/xhtml et standards.
J'entend par là que les balises sont trop imbriquées dans le code PHP et ne laisse pas beaucoup de marges de manœuvre aux codeurs css.
Si je voulais faire un cms yacs rexpectueux des standards, je ne pourrais pas, car le developpeur PHP a décidé qu'il fallait obligatoirement utiliser telle ou telle balise.
Je travail depuis 6 ans avec un ami DEV PHP, nous avons toujours séparé le fond de la forme (son boulôt et le mien).
Je ne dit pas que votre travail n'est pas bien, au contraire l'idée est bien évoluée.
Bien entendu je peux bidouiller les css comme je viens de le faire pour obtenir certains résultats , mais je ne peux pas choisir mes tags pour un codage plus poussé.
Par exemple les balise fieldset et label sont indispensable pour la lecture standard des formulaires, dans le cas de yacs je dois me contenter d'utiliser des balises dl dd dt ou de les assimiler.
Si je voulais faire un rendu en mode strict, je ne pourrais rien faire car je n'ai pas décidé de l'ordre de mes balises et de leur rôle.
Dans le cas où, je voudrais adapter ce template je ne pourrais pas TEMPLATE
Ce n'est que mon avis, je ne tiens ni à critiquer ni a polémiquer, mon intention est le débat pas la fermeture.
cordialement
Michel @+
Un bon codeur css/xhtml et standards, n'est pas forcemment un bon developpeur PHP.(l'exemple type est Raphaël Goetter d'Alsacréations)
Un bon developpeur PHP n'est pas forcemment un bon codeur css/xhtml et standards.
J'entend par là que les balises sont trop imbriquées dans le code PHP et ne laisse pas beaucoup de marges de manœuvre aux codeurs css.
Si je voulais faire un cms yacs rexpectueux des standards, je ne pourrais pas, car le developpeur PHP a décidé qu'il fallait obligatoirement utiliser telle ou telle balise.
Je travail depuis 6 ans avec un ami DEV PHP, nous avons toujours séparé le fond de la forme (son boulôt et le mien).
Je ne dit pas que votre travail n'est pas bien, au contraire l'idée est bien évoluée.
Bien entendu je peux bidouiller les css comme je viens de le faire pour obtenir certains résultats , mais je ne peux pas choisir mes tags pour un codage plus poussé.
Par exemple les balise fieldset et label sont indispensable pour la lecture standard des formulaires, dans le cas de yacs je dois me contenter d'utiliser des balises dl dd dt ou de les assimiler.
Si je voulais faire un rendu en mode strict, je ne pourrais rien faire car je n'ai pas décidé de l'ordre de mes balises et de leur rôle.
Dans le cas où, je voudrais adapter ce template je ne pourrais pas TEMPLATE
Ce n'est que mon avis, je ne tiens ni à critiquer ni a polémiquer, mon intention est le débat pas la fermeture.
cordialement
Michel @+
Comments
Merci de votre contribution ci-dessus. Je me suis permis de la promouvoir en un article à part entière tout en la conservant dans cette section. Il apparaissait, en effet, sous la forme d'un commentaire parmi un fil de discussion consacré au SEO.
Je ne suis pas encore entièrement convaincu par votre argument selon lequel le développeur PHP de YACS ne respecte pas les standards en matière de CSS parce que les balises sont trop imbriquées dans le code PHP.
Toutefois, je vous rejoint sur le fond de la question : nous gagnerions énormément de temps, de liberté, d'énergie et de souplesse quant au résultat final, si YACS trouvait le moyen de mieux scinder la partie concernant le graphisme du code PHP.
Mais comment avancer concrètement sur cette question sur laquelle, en vérité, nombre de CMS évolués se cassent régulièrement les dents ?
Vous avez posé là une question qui appelle sans doute quelque fonctionnalité nouvelle dédiée au graphisme dans YACS.
Sans parler seulement des standards, mais en tenant compte du fait que la possibilité déjà offerte par YACS de dériver des skins peut malgré tout permettre d'avancer assez sérieusement, auriez-vous une piste, une idée... Vous, votre ami développeur... Permettant de rendre la qualité graphique d'un site YACS plus accessible ?
Il s'agit d'un vrai gros problème qui appelle un effort conjugué de réflexion et de travail, non seulement de la part de notre équipe, mais aussi de la part de tous les utilisateurs avertis de YACS (qui font aussi partie de cette équipe).
Félicitations, au passage, pour votre site qui se consacre à des questions très actuelles qui se posent par rapport aux professions de l'ancien.
C'est une question difficile, et vos apports sont les bienvenus.
La séparation des styles et du code est presque complète avec YACS, ce qui n'est pas le cas de beaucoup de ses confrères... Reste que l'interface entre le PHP et le CSS passe par le choix de balises XHTML, et que c'est là que la bât peut blesser.
YACS dispose bien de templates mais, contrairement à beaucoup d'autres systèmes qui imposent une sémantique particulière, ici le language choisi est ... PHP. Par exemple, si la fonction de mise en page d'un formulaire ne vous convient pas, vous pouvez la remplacer par une autre pour mieux répondre à votre besoin. C'est vrai que cela requière un peu de programmation PHP, mais ce n'est pas plus compliqué que les langages de template, et c'est beaucoup plus performant à l'exécution.
Soit dit en passant, si vous avez quelques idées pour améliorer le balisage des formulaires de YACS, je suis très preneur...
YACS est aussi muni de plusieurs aides pour le concepteur graphique, dont une page de vérification du rendu visuel, accessible depuis la page d'index des styles. Cela reste incomplet, comme l'a souligné Fernand, mais ça rend des services.
" Je ne suis pas encore entièrement convaincu par votre argument selon lequel le développeur PHP de YACS ne respecte pas les standards en matière de CSS parce que les balises sont trop imbriquées dans le code PHP. "
Bonjour
Merci pour votre écoute ainsi que vos arguments, au travers desquels j'entrevois un grand dynamisme.
Ne pas confondre CSS et Standards, là est la question.
Le css est conçu pour le design et en partie pour la séparation du fond et de la forme. (même si on utilise les css pour les normes)
Les standards sont une autre conception, ils consistent à contruire un site accessible pour des personnes souffrant de certaines déficiences physiques, notament visuelles.
Les moteurs de recherches tel que google par exemple sont de grands handicapés si la sémantique appliqué aux handicapés n'est pas respecté, ces mêmes moteurs ne lisent pas tout ou ne peuvent pas tout lire où leurs algorithmes se lassent des mauvaises mises en forme et pompent deux ou trois trucs peu essentiels.
Dans le cas d'une bonne sémantique les trois quarts du contenu des pages sont absorbés, j'ai eu plusieurs discussions avec des référenceurs, il y a un an je voulais me positionner sur le mot clé weblogs dans les première requêtes de google, les référenceurs avaient répondu qu'il faudrait au moins 5 ans sur un tel mot, même en ayant weblogs dans l'IP, que néni j'ai mis un an pour attérir à la cinquième page, j'ai aussi fait de même pour logins là je suis en tête, et bien d'autres.
Tout ça pour dire que je suis maintenant convaincu par cette méthode de travail.
Je vous renvoi à cet article formulaires accessibles
Pourquoi je pense que les balises sont trop imbriquées, parce que la plus grande partie du code html sur lequel je voudrais positionner les tags et influer sur ceux-ci, est imbriqué à l'intérieur du code PHP.
Dans un orchestre si l'un des instruments prend sonoriquement le dessus, nous n'entendons plus les autres, l'harmonie du concert devient vite un acapella, on va pas demander au trompetiste d'accorder la basse et vice versa ou demander au violoniste de remplacer le joueur de basson .
Le DEV PHP de yacs est très sensible aux standards et très compétent, ça se voit, je le félicite en passant, mais comme il maitrise plusieurs langages il a compacté le tout, tant pis pour ceux qui connaissent pas le PHP.
Donc les possibilités pour un Design/css/xhtml est restreint aux balisages de base. Ce qui n'ouvre pas beaucoups de persprectives.
Ce que je préconise c'est la séparation du html et du code php ou l'accès facile au html(séparation de l'église et de létat
) un peu à la dotclear et surtout comme Thelia.Cordialement
@+ Michel
Michel : Alors là, façon de parler, un point pour vous !
Même si je n'ai pas honte d'admirer profondément les apports de Google dans de très nombreux domaines, je me rends à vos arguments...
J'irai même jusqu'à dire que les standards en matière d'accessibilité, en un mot la "portabilité" d'un logiciel par rapport aux personnes handicapées, me semble être le passage obligé de toute technologie innovante... Et ce point-là devrait être notre point de passage obligatoire, ayant valeur de test, pour que YACS reste à la pointe.
J'adhère personnellement à votre préconisation:
" Ce que je préconise c'est la séparation du html et du code php ou l'accès facile au html(séparation de l'église et de l'état "
Avoir des fichiers séparés xhtml, css, et php pour les thèmes (les skins) constitue un rêve que je caresse depuis longtemps, mais que je ne retrouve nulle part. Est-ce impossible ? Cela menace t-il la cohérence de YACS ? Je n'en suis pas convaincu. Car les skins, après tout restent, dans YACS; un élément à part. Et sont (logiquement) indépendants des mises à jour.
Même si ce rêve s'avèrait impossible à réaliser pour des raisons techniques qui nous serons sans doute expliquées par Bernard, je demeure très profondément convaincu que la solution pour YACS consiste à "libérer" complètement le graphisme des templates, de la belle intégration PHP du moteur de YACS.
Une telle réalisation permettrait à YACS d'assumer le bond en avant considérable qu'il est en train de parvenir faire, dans des condition de travail hyper optimisées de la part du DEV... Le mot assumer est ici à prendre dans le sens de: ne pas laisser se dissoudre le bénéfice d'un tel travail de précision, mais au contraire, le rendre immédiatement concret et lisible pour tous.
La plupart du temps, nous retrouvons ce déséquilibre entre le rythme des développeurs et celui des "graphistes" web. Résoudre une telle question rendrait YACS magistral. Ne pas la résoudre limite terriblement dans l'entrée dans le champ des futurs très grands logiciels.
Il faudra cependant que nous devenions très inventifs pour harmoniser ces points de vue tant ils semblent difficiles à concilier. N'est-ce pas seulement une mauvaise habitude culturelle qui a la peau dure ? YACS, dans tous les cas a sa chance à jouer sur ce point-là, au moins autant que les autres. A nous-autres (vous compris), de la saisir. Soyons encore plus audacieux. Rendons nos idées plus concrètes encore. Avançons.
Et... MERCI
Bonjour
Je pense que cette base de templates est l'une des plus respectueuse, elle offre un tas de possibilités n'hésitez pas à cliquer vous allez comprendre.
Je me suis permis de la charger sur notre serveur dedibox dédié.
cliquer ici pour le lien
C'est clair c'est net et précis, de plus le boulôt est déjà fait, bien entendu il y a quelques retouches par ci par là, mais rien de bien fastidueux.
@+
Michel
Bonjour
C'est par l'exemple que nous montrons, he ben soit.
Avec un ami nous sommes sur un projet de plate-forme ecommerce depuis bientôt 6 mois environ, n'étant que deux, la tâche est ardue.
Allez voir la plate-forme à vizibox.net, ceci est une ébauche pas une phase finale, c'est juste pour vous montrer notre méthode de travail.
Vous remarquerez les blocs bien distincts, ceux-ci peuvent être placé à n'importe quel endroit de la structure (un peu à la manière des modules).
plusieurs feuilles de styles ont été élaboré afin de séparer les différent gadgets et autres.
Avec cette méthode, nous pouvons influer sur tout les tags et sur toute la structure.
merci pour votre attention.
@+
Michel
Michel: C'est très bien les boîtes, et très clair. J'ai regardé le wiki de l'outil utilisé, il a le mérite d'être assez clair. A méditer...
Michel: En fait, c'est cette page qui a servi à certains développements initiaux pour yacs... C'est vrai que c'est très bien fait.
En fait, le moteur de Thelia mentionné dans le fil de discussion propose ses propres codes, qui ne sont pas du HTML, pour la construction de pages de catalogue électronique.
Ceci est à peu près équivalent à la démarche engagée autour des codes YACS, que nous pourrions assez facilement étendre dans le cadre d'extensions de commerce électronique pour obtenir une sémantique similaire à celle de Thelia.
Comme toujours, le problème du concepteur de catalogue électronique est d'exprimer le plus concisément possible les informations dynamiques dont il a besoin, ainsi que leur rendu visuel.
Donc, le débat est donc moins entre HTML et PHP qu'entre différentes races de codes spécifiques et adaptés au commerce électronique.
Rate this page
Posted by Michel on Sep. 2 2007, commented by Bernard on Sep. 15 2007, (popular)
