Denis

Ce n'est pas une question stupide, mais je crois que la majorité des gens qui font affaire avec des services comme ceux-là le font justement parce qu'ils n'ont pas les compétences techniques pour se débrouiller tout seuls...

C'est une bonne idée... seulement, il faudrait probablement élargir le sujet pour inclure les CSS et les autres langages, parce que si on se met à produire un sujet par technologie, on en sortira plus !

Tiens, j'avais jamais réalisé ça... bonne observation. Merci beaucoup pitidev, je garderai ça sous le coude. Par contre, il ne faut perdre de vue que le problème de cette astuce, c'est que ta feuille de style sera maintenant appliquée à tous les médias, ce qui peut être mauvais si tu souhaitais t'en faire une pour l'imprimé... Conclusion, intéressant, mais peut-être moins efficace que le _AT_import qui lui, permettrait de cibler seulement le media screen.

Au risque de te décevoir 20cent, je ne pourrais même pas te dire ou se trouve cette option aujourd'hui, parce que que je l'ai jamais utilisé. Pour moi, Homesite est vraiment un notepad avec du color coding. Je suis probablement un puriste, ou un ayatollahs© de plusieurs affaires, w3c, accessibilité, conscience du travail bien fait... J'appartiens aux premières générations de codeur, comme un vieux sénile qui refuse de changer ses habitudes. Mon client FTP n'est même pas intégré à mon éditeur HTML, chose qu'Homesite me permettrait également de faire. J'ai aussi essayé HTML-Kit une fois ou deux. Ça deviendrait très certainement mon éditeur de prédilection si je n'avais plus accès à Homesite. Au passage Voulf, benvenue dans le Hub !

Effectivement, si tu nous livre une URL, nous pourrons très certainement te donner un coup de main.

J'ai l'impression que le <br /> n'est utile que lorsque le codeur est incapable de s'en passer, quelle que soit la raison... Les CSS peuvent très bien le remplacer par clear, padding ou margin alors son intérêt est bien faible à mes yeux. Ma règle ? Seulement lorsque mes compétences CSS atteignent leurs limites... ou quand je tourne les coins ronds, ce que j'essaie de faire le moins souvent possible. Mon point de référence, c'est la valeur sémantique d'une balise par opposition à sa valeur de présentation. Le <br /> n'a aucune valeur sémantique, il ne sert qu'à modifier l'aspect visuel d'un document. Il devrait donc être systématiquement relégué à la CSS. Au passage, salut Thierry et bienvenue dans le Hub !

Alors dans un tel cas, ce serait l'outil que je recommanderais.

Personnellement, je dirais que non. Je code à la main depuis mes premières heures, parce que j'ai eu la chance de tomber sur un éditeur texte dès le début, un éditeur HTML nommé WebExpert... Par la suite, j'ai découvert DW 2 que l'on m'enseignait à l'école. Parce que j'étais habitué à penser comme un codeur et non comme un graphisite, mes premiers moments dans un wysiwyg ont été laborieux. J'ai retrouvé ma vitesse de croisière le jour ou j'ai retrouvé la commande f10 qui permettait de coder directement. Je serais malhonnête de dire que je code plus vite à la main dans Homesite qu'avec DreamWeaver. Je suis simplement plus à l'aise avec Homesite ou Notepad parce que je les utilise exclusivement depuis plus de 4 ans. Quand tu fais tout manuellement, peu importe l'outil tu ne peux aller plus vite que tes dix doigts. Par contre, je n'ai jamais trouvé personne capable de me démontrer que ça allait plus vite pour la même qualité de rendu avec DreamWeaver qu'un simple éditeur HTML. Je dirais donc qu'en fait, travailler avec DreamWeaver me permettrait rien de plus rien de moins parce que je l'utiliserais selon le mode codeur (qui s'avère être homesite 5.5). C'est clair que générer un menu DHTML automatisé dans DW est plus rapide que d'en coder un de toutes pièces, mais au moins celui que je ferais avec mes dix doigts serait sémantique, accessible et 10 fois plus léger que celui de DW (en plus d'être parfaitement interopérable et non propriétaire). Si on l'utilise pour la portion wysiwyg, on ne peut parler d'une meilleure qualité compte tenu de tout le code propriétaire et contextuel qui est généré à chaque appel de fonctionnalité automatisée demandée. Si on l'utilise comme éditeur texte, alors le coût ne vaut pas la peine. Une vieille version d'Homesite ou Notepad est encore mieux. Tout ça, ça me fait penser à un slogan du libre que j'adapte pour le plaisir : DreamWeaver, il est possible d'avoir mieux, mais ce sera beaucoup moins cher !

Je viens de me rapeller un bouquin en français sur CSS écrit par Daniel Glazman qui était très intéressant. Son seul défaut étant évidemment d'avoir été écrit en 1998, il y a pas mal de choses qui ont changé depuis. Peut-être peut-il encore être d'actualité pour ceux qui souffeent de la barrière de la langue avec les ouvrages disponibles en anglais. http://www.amazon.fr/exec/obidos/ASIN/2212...2613181-3739358 Pour ce qui est du livre de Beuzit, je ne le connais pas, mais c'est probablement celui-ci : http://www.amazon.fr/exec/obidos/ASIN/2746...2613181-3739358

En français ? Peut-être le bouquin sur CSS écrit par Daniel Glazman ? Cependant, il commence à sérieusement prendre de l'âge (1998), je ne suis pas sûr que le contenu soit encore d'actualité. Enfin, s'il est toujours disponible, tu peux toujours vérifier : http://www.amazon.fr/exec/obidos/ASIN/2212...2613181-3739358

Je confirme ce que dis Clair de lune, j'évite le plus clairement du temps les hacks de ce genre, par choix de conception et j'arrive quand même à mes fins. C'est possible, suffit de bien répartir les valeurs annoncées aux paddings et margins des conteneurs afin de satisfaire autant le modèle de boite de MSIE que celui des autres navigateurs. Pour ce qui est de cacher l'interprétation de la feuille de style à Nertscape 4, ton meileur ami est définitivement la règle du _AT_import. En spécifiant tout d'abord une feuille de style pour Netscape 4 (ou générale et simple) avec la balise link, tu peux ensuite venir écraser cette CSS avec une autre plus sophistiquée par la balise style avec _AT_import, Comme celle-ci ne sera pas interprétée par NS4 tu peux donc contrôler quel CSS tu envoie à quel navigateur. Exemple : <link rel="stylesheet" href="basique.css" media="screen" type="text/css" /> <style type="text/css" media="screen">@import url(evoluee.css);</style> Comme les navigateurs récents peuvent interpréter les deux, tu dois cependant t'assurer que ce qui est déterminé dans la feuille de base est écrasé dans la feuille sophistiquée sinon les valeurs s'additionneront, du à l'effet de cascades des CSS.

Je donnais récemment dans un autre sujet une différence entrre les deux. L'explication convient parfaitement à ce cas-ci : http://www.webmaster-hub.com/index.php?sho...indpost&p=22278 Je retransmet, pour des raisons de commodité : En français, le display: none ne génère aucun espace physique dans la page, alors que visibility hidden lui, oui (on dira qu'il est invisble, pas inexistant).

Personnellement, je ne l'utilise pas, mais je peux tout de même répondre partiellement à ta question. Utilisé de la bonne manière, c'est un excellent outil qui permet de faire tout ce qui est possiblement réalisable sur le Web. C'est, après tout, un simple éditeur texte avec des fonctionnalités pré-programmées. La mauvaise presse dont souffre l'outil vient du fait que c'est un outil WYSIWYG et donc, qu'il a une tendance naturelle à générer pas mal de code propriétaire qui allourdit et pollue les pages.

À mon sens, LA référence sur CSS-2, d'un point de vue pratique de développeur, demeure sans conteste le bouquin d'Eric Meyer

20cent, je crois que nous disposons des mêmes banques de smileys ! Je trouve le boxeur particulièrement excellent, j'ai toujours aimé l'utiliser. Personnellement, dans le cadre du Hub, j'ai bien hâte d'avoir à modérer un truc pour utiliser mon policier qui ramène à l'ordre ! Pour ce qui a trait au tabindex, je ne fait que théoriser, je ne sais pas si ça peut fonctionner. Ce que je dis, c'est simplement que si tu apposes un tabindex à tous tes items, tu pourrais probablement forcer le passage par-dessus le changement de focus occasionné par ton lien sur la pop up. Peut-être qu'il y a moyen bluffer l'agent utilisateur d'une certaine menière en lui faiant perdre son focus, ou simplement recoder l'appel de la pop up autrement. J'avoue que je serais un peu confus aussi à ce niveau.

Hummm... j'imagine que c'est une question de déterminer à quel point nous sommes à cheval sur nos principes. Les anglais diraient "anal retentive". Personnellement, je ne veux pas faire de concessions à ce niveau. Les fournisseurs incapables de produire du code valide me perdent donc comme client, moi et tous ceux avec qui je fais affaire (parce que mon offre de service repose sur une conformité sans failles). Pour moi (et de plus en plus de codeurs fort heureusement), le respect d'une conformité entière ne se questionne tout simplement pas, pas plus que l'importance d'une bonne orthographe d'ailleurs. Ça tombe simplement sous le sens. Bien sûr, on peut écrire des textes truffés de fautes, mais le message qu'on lance en faisant cela est simplement qu'on ne porte pas une grande importance à la qualité réelle de notre travail... et ça, c'est tout à fait légitime. Nous avons tous le droit de ne pas en tenir compte. Il faut juste savoir relativiser. Une ou deux fautes à l'occasion ça passe, ce n'est pas dramatique. Mais quand on en retrouve des dizaines à chaque page, le message ne saurait être plus clair. Si les outils que j'utilisent sont incapables de me supporter dans ce sens, je les éliminent au profit de d'autres. C'est pas le choix qui manque de toutes façons. Pas question pour moi d'appauvrir la qualité de mon travail ou de risquer l'interprétation incorrecte de mes pages dans certaines configurations logicielles évoluées, simplement parce qu'un fournisseur de services n'est pas à même de bien livrer sa marchandise, ou n'est pas sensibilisé aux enjeux reliés à sa sphère d'activités. Nous vivrons dans ce contexte encore longtemps, peut-être toujours. Tout est une question de choix. Certains se formalisent de la qualité de leurs livrables, d'autres pas. En ce sens, le Web n'est en rien différent des autres sphères de la vie. Il y a des bons mécaniciens et il y en a des mauvais. Tout ce que je peux souhaiter, c'est que ces fournisseurs perdront suffisamment de clients à cause de cette raison pour se rendre compte qu'ils n'auraient qu'à bien faire leur boulot (ou y mettre suffisamment de fierté) pour que leurs clients reviennent. Quand on constate que bien travailler ou travailler mal n'est pas plus long, ça lance un certain message sur la crédibilité des fournisseurs ou l'effort qu'ils sont prêts à faire pour accomoder les acteurs du domaine dans lequel ils évoluent.

French Dead, je m'engage officiellement à te fournir une liste de liens issus de mes bookmarks, dès que j'aurai le courage d'y faire un peu de ménage... ça ne devrait pas être trop long.

Je crois que nous avons besoin de clairifier certaines choses. Nous aurions du commencer par ça, je m'excuse de ne pas l'avoir fait. Elle servira à quoi cette ligne ? Elle est purement décorative ou elle sert de délimiteur entre deux sections ? Si ce n'est que décoratif, attribuer une bordure à un <div> (ou tout objet de type bloc contenant l'information) fait amplement l'affaire parce que l'on parle d'un élément décoratif qui ne revêt aucune valeur sémantique. C'est purement de l'ordre des considérations de design et ça doit se passer dans la CSS. Si c'est pour séparer des contenus, donc structurer l'information, alors là, le <hr> devient important parce que la valeur du trait qui ne saurait être restitué convenablement sous tous les agent utilisateurs conservera tout de même un sens de frontière entre les deux sections sous tous les envronnements. Suis-je plus clair ? Je m'excuse pour la confusion créée si c'est le cas.

Toute la question de la sémantique Web (à ne pas confondre avec le Web sémantique comme nous le rappelle Fabrice Bonny dans l'humeur d'OpenWeb) mériterait probabement d'être approfondie... existe t-il de tels documents sur le Hub ? Je n'en ai pas encore trouvé.

Dans le genre, il y a l'excellentissime hotscripts.com qui contient des milliers de scripts PHP, en plus de pleins d'autres dans plusieurs langages backend. http://www.hotscripts.com/PHP/Scripts_and_...rams/index.html

J'ai dis ça moi ? Où ça ? Peut-on suposer que c'est suffisant ? Ça dépends à qui tu le demandes. Je crois que non. D'autres diraient que oui. Si tu es pour le faire, je pense que c'est mieux de le faire ne image, dans la page (l'image a une valeur et mériterait un alt). L'inscrire dans ta CSS ne servirait pas à grand chose. Tant qu'à faire, tu serais mieux de l'écrire textuellement. Je ne suis pas trop sûr non plus... Si tu indiquais par tabindex le même ordre qui se construit naturellement tu passerais probablement par-dessus le lien pour la pop up. Si ton javascript répond à la syntaxe propre à Microsoft (jscript) ou Netscape (javascript) par exemple, il est propriétaire en ce sens qu'il ne fonctionnerait pas pour les autres agents utilisateurs. Un bon exemple de cela, c'est le DOM de Microsoft Internet Explorer 4 qui parle aux objets par la syntaxe document.all alors que le DOM de Netscape 4 passe par la syntaxe document.layers... tu as donc besoin d'utiliser lesdeux pour que ca marche dans les deux navigateurs. C'est donc propriétaire. Si ton javascipt repose sur le DOM W3C, la syntaxe sera plutôt document.getElementById et sera issue de l'ECMAscript, la version standardisée de Javascript.

En fait, si tu as perdu un peu de ton classement depuis que tu as sémantisé ton code, je ne vois qu'une chose possible, c'est que d'autres l'ont également fait, de manière plus efficace encore... Et que si tu ne l'avais pas fait, et bien, tu en aurais perdu plus encore. Il faut dire que la sémantisation n'est pas la panacée. L'optimisation du code, l'épuration du code non significatif servant uniquement à des fins de présentation (tableaux html, spacer gifs, etc.) y compte aussi pour beaucoup. Par exemple, si Google indexait uniquement les premiers 10k d'une page et qu'il ne trouvait rien de meiux qu'une tonne de javascript et des débuts de tableaux HTML sans H1 ou h2 pour déterminer des indicatifs de titres ou sous titres, il ne pourrait pas conserver grand chose. Si à l'opposé, sa recherche des 10 premiers kilo-octets ne tombe que sur du contenu, le résultat d'indexatio sera beaucoup plus efficace. Si ce code récupéré à une forte valeur sémantique, ce sera plus efficace encore. Tu sais, chaque octet de HTML inutile récupéré par Google, c'est un octet de moins de contenu... Je ne détiens aucune notion scientifique à cet effet, mais ce que je sais, c'est que tout ce qui est fait dans un esprit efficace d'optimisation du code jumellé avec une forte sémantisation sort toujours les premiers dans les engins de recherches.

C'est vrai... à la différence près que n'importe qui peut se les approprier et prétendre à un certain niveau de qualité même si ce n'est pas le cas...

Je ne sais trop... un orangé probablement, ou une teinte entre le orange et le rouge. Je suis vendu à l'orange comme couleur complémentaire alors je ne suis pas objectif du tout...

Je suis désolé, mais c'est complètement faux de A à Z. La valeur d'un h1 par opposition à un autre élément HTML se fait au niveau sémantique. Le h1 veut dire quelque chose, il signifie le titre le plus important de la page après le title. Google s'en sert dans son référencement et accorde une valeur supérieure au H1, ensuite au h2, etc. Les headers (h1, h2, h3, h4, h5, h6) servent également de points de repères pour les agents utilisateurs. Un synthétiseur vocal ou un cellulaire par xemple, qui sont incapables de restituer un design, peuvent tout de même structurer une page lorsqu'elle est interprétée par ces balises. S'en passer, c'est donc définitivement appauvrir la valeur du site. En terme de référencement, vous n'avez qu'à regarder le site d'Eric Daspet dans le concours de mangeur-de-cigogne pour réaliser tout de suite qu'un code sémantisé est beaucoup mieux référencé par Google qu'un autre qui ne l'est pas.