Aller au contenu

Denis

Hubmaster
  • Compteur de contenus

    1 537
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Denis

  1. Effectivemment, j'aurais pu faire l'effort de chercher quelques fils de discussion pour alimenter mon information... Merci Monique. Ceci dit, il arrivera invariablement un moment où tu auras envie/sera tenté de faire du strict plutôt que du transitionnel parce qu'aux yeux du monde extérieur, la tendance est à croire que l'un est effectivemment meilleur que l'autre (ce n'est pas le cas, je le répète). À ce moment, si tu as besoin d'utiliser le target, tu te retrouveras devant un choix Cornélien : Insérer autant d'erreurs HTML dans ton code que d'occurences de l'attribut (horreur) Songer à utiliser javascript pour ouvrir de nouvelles fenêtres (terreur) Dans tous ces cas, et bien d'autres que l'on pourrait nommer, je ne saurai que te référer vers un article rédigé par Éric Daspet il y a un moment, intitulé "liens et nouvelles fenêtres", qui traite justement de la question...
  2. Bonne chance! Reviens nous voir si tu as d'autres questions.
  3. Et bien, tout le plaisir est pour moi... Mode collaboration : ON!
  4. Ta source semble un peu biaisée... on peut savoir elle vient d'où? Ta conclusion vient certainement de l'idée que le strict est mieux que le transitionnel, alors qu'il n'en est rien dans les faits. Il s'agit de choisir la formule qui convient le mieux à ton projet et ton besoin. Peu importe la sorte de HTML que tu utilises (HTML ou XHTML) et la saveur que tu lui donnes (strict, transitionnel ou frameset), toutes ces combinaisons sont conformes à la norme, donc pleinement recommandables. Quiconque te dictera le contraire n'a clairement pas encore compris la vraie nature du langage de structure à la base du succès du Web. Insinuer que le transitionnel est moins bon que le strict, c'est d'adopter une vision qui est partisane et complètement hors contexte. Comme la plupart des gens, j'ai moi-même confondu tout ça il y a quelques années, mais à force de réfléchir sur la question, on se rend bien compte que transitionnel ou strict, ça n'a aucun intérêt. Dans le cas de l'attribut target, la question a longuement été débattue sur les blogues et les forums, dont d'excellent débats ont eu lieu ici par le passé. Tout ce que je pourrais dire pour le moment là-dessus, c'est que si tu considères que c'est important d'ouvrir une nouvelle fenêtre pour un lien, prend du transitionnel. Si comme beaucoup, tu considères que c'est un mauvaise pratique d'ouvrir de nouvelles fenêtres à la volée, prend du strict. Mais si tu appliques une séparation nette entre la structure, la présentation et le comportement, il y a moyen de faire du transitionnel tout aussi propre que du strict. Le point de vue qualitatif ne tiend donc pas la route puisque la seule différence dans ton code entre du strict et du transitionnel tiendrait uniquement sur l'utilisation de l'attribut. .
  5. Et pourquoi l'attribut target ne pourrait plus être utilisé? Qu'as-tu lu qui te pousse à cette conclusion?
  6. C'est la direction dans laquelle je m'en allais avec ma question. À mon avis, c'était forcément une question de ce type, si ça c'est réglé avec le changement de client FTP.
  7. Bienveue sur le Hub, tu y trouveras certainement réponse à ton clavier!
  8. Je plussoie, comme on aime bien dire ailleurs... Présenté comme ça C'est vrai que pour un minimum de crédibilité, cet investissement vaut chaque sous qui y est injecté.
  9. Question plus pertinente encore... Quels types de tutos te demandent tes visiteurs? T'as un moyen de mesurer ça?
  10. Ce que Marvin voulait dire, c'est que ton code sera toujours beaucoup plus facile à déboguer si ton HTML est exempt d'erreurs... alors tu sais au moins que le problème d'affichage est causé par un mauvais support CSS dans ton browser, et non à case d'une erreur interne. Si tu commences par utiliser un doctype valide (peu importe ta saveur préférée) et que tu t'assures avec un service de validation que ton code est syntaxiquement correct, tu élimines une à une les pistes de recherche pour déterminer les causes du problème. Car actuellement, voici les statistiques liées à cette page : Nombre d'erreurs: 23. Nombre d'avertissements: 0. Nombre d'erreurs et avertissements différents: 5. Nombre de lignes: 160. Nombre d'erreurs par ligne: 0.14. Nombre de lignes erronées: 14. Passage: Cette page est invalide selon le DOCTYPE utilisé. Si tu commences par nettoyer ton code, il sera beaucoup plus agréable de fouiller avec toi les causes de ce petit désagrément. Mais bon, tu connais le principe, ta CSS est volontairement valide. Joli design en passant!
  11. C'est réglé? Parce qu'en regardant l'affichage de http://www.bulgaria-france.net/library/frbg.jpg avec Firefox, tout ce que l'on voit, c'est un rectangle blanc...
  12. Merci, tu confirmes ce que je pensais... serait-ce à dire que ce ne serait donc pas une pratique comme telle qui, dans la plupart des cas (je dis bien la plupart des cas), causerait les problèmes, mais l'accumulation de pratiques abusives sous un même toît - ou disons, un même nom de domaine?
  13. En tant que québécois, je ne vais pas m'avancer sur les centres de formation car à moins que tu ne songes à traverser l'Atlantique, l'intérêt serait bien limité... Par contre, j'aimerais revenir sur une question particulière que tu posais, à propos des coûts potentiellement élevés de ces formations. Effectivement, c'est loin d'être donné. Pour ma part, à la fin des années 90, une année intensive de formation m'avait coûté 15000.00 $ dollars canadiens (ça doit faire dans les 10 500 euros j'imagine)... Cependant, considérant les opportunités du marché, il m'a été bien plus facile de rembourser ma dette avec le salaire qui est venu suite à mon diplôme que ne l'aurait été une dette bien inférieure dans un domaine moins payant. Parfois, il ne faut pas seulement voir les coûts à court terme, mais bien les revenus à long terme.
  14. J'irais dans le même sens que mes illustres collègues : plus tu auras de contenus intéressants, plus le site le deviendra par la même occasion. De même, la question des contrastes est très pertinente. Pour arriver à lire ton menu, j'ai non seulement dû plisser les yeux, mais encore (et c'est pire) sélectionner le texte avec ma souris... texte qui a été remplacé lors du mouseover... Disons simplement que j'ai fait l'effort dans ce contexte, mais en temps normal, jamais je ne me serais donné cette peine. D'autres visiteurs potentiels rencontreront les mêmes problèmes et tu risques de perdre du public pour un truc aussi banal. Simplement jouer avec tes choix de couleur réglera en partie ce problème et ce sera un premier pas vers l'accessibilité même de ton site, question sur laquelle nous nous pencherons certainement un jour si tu demeures dans les parages assez longtemps.
  15. Si au moins Google faisait ça, on se débarasserait une fois pour toutes de ces satanés menus... Et quelle serait la fourchette de spam acceptable au juste? A t-on une idée? On la calcule en fonction de la proportion ou du ratio de texte pertinent par rapport au texte dont l'utilisation est discutable?
  16. Je trouve également que la dernière version est la plus intéressante. Il y a une maturité achevée derrière ce design, qui est maintenant nettement mieux que ce qu'elle était au départ. La version orange, je l'ai trouvé un peu curieuse, comme si la volonté était de faire quelque chose de chaud, mais pas complètement assumé. En retravaillant la version blanche, je trouve que le résultat est mieux. Bravo! Peut-être un peu trop "pâlotte" par contre...
  17. Pas juste le tien mon ami, le mien aussi. Ce que j'ajouterais à tout cela, c'est qu'il y a un intérêt à mettre chaque document dans son propre répertoire et de le nommer index. Ainsi, les URLs sont toujours plus simples et si du jour au lendemain on change de technologie, rien ne bouge (ex. passer de index.html à index.php dans un répertoire service).
  18. Il te manquerait simplement un ajout à ta CSS, pour indiquer à l'image que c'est elle qui ne doit pas avoir de bordure (plutôt que le lien lui-même) : a.lienimage img {border: 0;} Du coup tu pourrais enlever de .lienimage toutes les références aux bordures, qui sont inutiles.
  19. Toutes mes excuses, tu as parfaitement raison, c'est moi qui avait mal lu... Dans le contexte de la question de Developer, il s'agirait de découper à partir d'une maquette, probablement Gimp ou Photoshop... c'est une toute autre histoire!!! Je dois avoir le cerveau qui ramollit un brin.
  20. Comment? Tu considères qu'il n'y a rien de tel chez AlsaCréations ou ailleurs? http://css.alsacreations.com/Modeles-de-mise-en-page-en-CSS
  21. Un lien avec un libellé aussi descriptif que "Cliquez ici" vaudra toujours mieux que pas de lien du tout, c'est clair... du moins pour moi, qui ne suis pas non-voyant et qui peut reconstituer globalement le contexte d'une page. Pour un aveugle ou une persoone ne voyany qu'une portion de la page à la fois, tomber sur une page contenant 350 liens vers autant de nouvelles ou d'actualités affublées du significatif et intuitif libellé "Cliquez ici", ce serait probablement autre chose!
  22. Je suis tombé sur l'article de Weakly cette semaine en fouillant dans les archives des "Links for light reading". J'ai été sur le coup vraiment étonné de la simplicité et de l'ingéniosité de la technique. Parfois, il n'est pas nécessaire de chercher midi à quatorze heures. On prend deux ou trois techniques éprouvées, on les brasse dans un grand bol et hop!, on arrive avec une nouvelle solution qui règle avec génie certains problèmes. Dans ce cas-ci, le problème de validité associé à l'utilisation de CSS-3 pour identifier les liens externes. IL n'y avait pas moyen de respecter la règle Opquast[1] sans perdre la validité des CSS ce qui, malheureusement, contrevenait également à une autre règle Opquast[2]. Avec la technique de Weakly, le problème est réglé, tous les navigateurs récents le supportent et on n'a pas à crocheter notre CSS. Génial. [1] http://www.opquast.com/bonnes-pratiques/fiche/50/ [2] http://www.opquast.com/bonnes-pratiques/fiche/10/
  23. À mon avis, l'intérêt était dans l'innovation. Dieu sait que j'aurais aimé être celui à l'avoir le premier, mais quiconque tentera de reprendre le modèle passera pour un opportuniste sans envergure essayant de se faire du capital sur une idée déjà passée de mode au moment où j'écris ces lignes. Le hype est passé, et si Tew passera à l'histoire pour avoir eu le génie de faire ça, ceux qui le suivront n'y trouveront probablement pas leur compte. Ceci étant dit, attendons-nous à en trouver plusieurs autres qui s'essaieront dans les prochains mois. Quant à l'intérêt pour le référencement, j'ai quelques réserves. Le principal intérêt selon moi, c'était de s'afficher comme une entreprise assez cool pour embarquer dans un projet aussi dément à l'origine. Le message ainsi lancé par ces entreprises étant plus du type "audacieux, dynamique et fonceurs". Enfin, mes deux sous canadiens, pour ce que ça vaut.
  24. Intéressant ces propositions... ainsi, je change un peu l'orientation de ce thread. Parlons plutôt de forums en open source, tableless, conformes au normes et accessibles. Faites-moi part de vos préférences, vos expériences et vos suggestions. Quels seraient les solutions étoiles? PunBB n'est pas encore un choix arrêté, je réfère nettement repousser ma décision pour en prendre une plus éclairée que de regretter mon choix plus tard.
×
×
  • Créer...