Journal Le blues du webmaster

Posté par .
Tags : aucun
0
28
sept.
2004
"C'est plus comme dans le temps, ma bonne dame! Avant on avait des webmasteurs élevés au lien, à l'ancienne. Mais maintenant sasfépu avec leur cms, blogs et tous leurs machins automatisés, là!". En quelques années, le métier de webmasteur a vivement évolué.

D'architecte global d'un site, le rôle de webmestre tends plus vers une responsabilité éditoriale et organisationelle aujourd'hui. Toujours au confluent de la technique et de l'éditorial, le webmaster a vu son rôle se modifier considérablement avec l'émergence - et l'évidente utilité - des systèmes de publication automatisés (quelle que soit leur approche d'ailleurs: cms, blogs, wikis). En schématisant: en 1997 quand on voulait un site, ben on demandait à un webmasteur, point. Si y avait besoin de trucs plus spécifiques ou complexes, on faisait appel à un développeur, qui nous faisait un beau cgi en perl, et tout était clair. Le webmasteur intégrait tranquillement le design du graphiste et les scripts du développeur, tout en concevant une arborescence adaptée au projet. Les choses étaient simples et bien définies. Aujourd'hui avec les systèmes de publication automatisés, l'intégration (=mise en ligne du contenu+design) est plus ou moins triviale, mais en tout cas n'est plus du tout réservée a des spécialistes. Le webmestre se justifie plus aujourd'hui par une expérience organisationelle+compétence éditoriale que par une stricte connaissance technique. Une ambiguïté, plutôt une erreur, serait de percevoir que ledit webmestre actuel ne sert uniquement qu'à l'intégration et à la maintenance courante. Son rôle est plus d'optimiser les accès à l'information, tant sur la forme (standards, code) que sur le fond (ligne éditoriale, "design de l'information"). Enfin tout cela se redéfinit rapidement et constament, parce que l'évolution rapide des système de publication automatisés renouvelle sans cesse la question du rôle du webmaster dans le web moderne. Une question qu'il est obligé de se poser, de toute façon, souvent.

Autre point: pour le webmaster de base, le prestige de l'uniforme en a pris un sérieux coup depuis l'époque glorieuse (avant 2000, avec le html à l'ancienne et Netscape, nostalgie;). En France tout au moins, le métier subit encore les conséquences négatives de la "ruée vers l'or" des années folles fin 99/2000. A cette époque tout le monde investissait sur le web, tous voulaient des sites pour un oui ou pour un non, parce qu'il le fallait. Cà a été un moment prospère sur court terme pour les webmestres, mais négatif sur long-terme. On avait besoin de sites, de préfèrences avec du Flash, bien chers et totalement improductifs sur un plan autre que "en jetter plein la vue aux investisseurs", donc de webmasters. Le couple php/mysql, à l'époque seulement émergent, n'était pas du tout démocratisé comme aujourd'hui. Bref, on faisait essentiellement des sites à l'ancienne, en html pur pour l'essentiel, la production étant bien rodée sous ces technologies, qui semblent aujourd'hui bien préhistoriques.
Là ou cà a été moins drôle c'est quand les investisseurs se sont finalement aperçu qu'ils avaient un peu trop forcé la dose sur les paillettes jettées dans le vent, et quand la "ruée vers l'or" s'est écroulée sur elle même. La fête était finie: les cours de bourses mirifiques de multiples start-ups prometeuses s'effondrant à la chaine, les fortunes (+ ou - virtuelles) se défaisant aussi vite qu'elles étaient apparues. A partir de ce moment ca a été l'expiation: la demande en site internet a brusquement chuté, pour ne remonter ensuite avec le temps que très progressivement à un niveau de marché réaliste. La "follie internet" a été un traumatisme pour beaucoup. Ca a fait beaucoup de mal au métier de webmaster, étant donné aussi qu'on a vu fleurir toutes sortes d'énergumènes et d'arnaques possibles durant cette période incroyable. De cette époque le "prestige de l'uniforme" a été bien terni: on ose plus trop dire webmaster encore aujourd'hui on préfère souvent se présenter comme programeur, ou graphiste, rédacteur en chef, concepteur ou n'importe quoi mais pas webmaster (j'exagère à peine).

Le point le plus délicat, celui qui nous mobilise tous en tant que webmestres responsables, indépendament des variantes régionales, c'est celui du balisage et des normes. Au début tout était beau, simple et limpide. De mémoire le html 3.2 passait bien dans Netscape 2, Netscape 3. Il n'y avait pas grand chose comme brouteur compétent à l'époque (hors Mosaïc le primate et Opéra, qui a commencé relativement tôt je crois), c'était clairement le meilleur. Ie3 tenait pas du tout la route à coté, aucun doute, et le marché était a fond dominé par Netscape. On le savait pas encore, mais on avait connu le bonheur. C'est avec la sortie d'Ie4 qu'à commencé la "Guerre des Brouteurs 1", et les vrais ennuis pour nous pauvres webmestres. On a alors vu arriver des différences de comportements par défaut, des propriétés spécifiques à un navigateur (jusqu'au fameux marginwidth/marginheight et topmargin/leftmargin dans les propriétés du tag body, que des générations de webmasters chérissent dans leur coeur chaque jour). En 2 ans Ie5 avait raflé le marché des navigateurs et coulé Netscape. Ca changeait la donne pour nous autres pôvres webmestres victimes innocentes sur le champs de bataille des titans. On a été obligé de s'adapter, d'apprendre tous les hacks qui vont bien pour faire du html cross-browser. Ca donne en gros un html 4.01 plus ou moins mixé à de l'ancien 3.2, mais qui marche partout.
Seulement la guerre n'est pas finie: c'est le deuxième épisode aujourd'hui: Mozilla ou la revanche de Netscape. Avec de nouveau un gros dilemme pour les webmestres: faire du W3C friendly bien propre (xhtml strict+css), ou du Ie6 compliant bien crade mais bien accepté communément (html old style hackpatché* empiriquement et laborieusement)? Mais la guerre, ca fatigue, et c'est reconnu comme étant mauvais pour la longévité. Pour éviter ce genre de désagrément, je recommande à tous les webmasters d'écouter leur instinct, pas leur client sur ce coup: faites donc l'évolution vers une incompatibilité Ie6: ca simplifie beaucoup de choses, et c'est nettement plus pratique de faire du xhtml/css que du html hybride patché de partout. J'ajouterais qu'une utilisation judicieuse du css peut aussi s'avérer client-friendly et graphiste-compliant, dans la mesure ou c'est beau. C'est une évolution à faire, mais ya quand même de quoi embrouiller son webmestre bienveillant avec tous ces dilemmes cruciaux et tout ce qui pends au nez et dépends de leur conclusions.

* tiens, un nouveau verbe se serait-il insidieusement glissé dans mon journal?

PS: si j'ai un peu forcé le trait dans le genre "pépé raconte le web comme c'était mieux dans le temps" c'est volontairement pour donner plus de poids au subversif message caché dans de ce journal: favorisons les formats/protocoles/outils/standards/gens ouverts, documentés et accessibles pour le bien de tous.
  • # Joli

    Posté par . Évalué à 1.

    Journal qui résume ce que je pense:
    Lorsque je vois certains sites ... Rien que de voir le site, je sais que le HTML va être ...
  • # pas que xhtml

    Posté par (page perso) . Évalué à 4.

    html 4.01 est aussi un standard. On est pas obligé de passer à xhtml si le terme fait peur.

    Rappel : mis à part la syntaxe xml du xhtml, il n'y a pas de différence entre html 4.01 et xhtml 1.0 au niveau des balises/attributs :

    html 4.01 strict = xhtml 1.0 strict
    html 4.01 transitionnal = xhtml 1.0 transitionnal
    html 4.01 frameset = xhtml 1.0 frameset

    Pour plus d'info (en particulier, savoir les différences entre strict et transitionnal ) : http://openweb.eu.org/articles/differentes_dtd/(...)

    ce qui est recommandé en revanche, et surtout, c'est l'utilisation des version stricts (pas de balises de présentation) et de CSS pour le design.
    • [^] # Re: pas que xhtml

      Posté par . Évalué à 1.

      Les tableaux récapitulatifs "Les balises obsolètes et les alternatives à leur utilisation" et "Les attributs obsolètes et les alternatives à leur utilisation" sont très intéressants dans le lien sus-cité.

      Y aurait-il sur openweb ou ailleurs le tableau inverse, à savoir une liste des balises sémantiquements conseillées dans des contextes précis? Du genre de hx pour les titres à acronym pour les acronymes, jusqu'a des trucs nettement moins répandus mais paraissant très sémantiques genre label, address, cite, dfn ... Bien sûr on peut se farcir toute la spec pour les dégotter une à une, mais en bon feignant à pragmatique, je cherchais un tableau synthétique rapide. J'ai trouvé cet article: "Respecter la sémantique XHTML" http://openweb.eu.org/articles/respecter_semantique/(...) mais pas de tableau synthétique de balises triées par valeur sémantique (avec précisions sur leur contexte d'utilisation).

      C'est aussi une interrogation de ma part sur la valeur sémantique à attribuer à chaque tag xhtml. Par exemple em est peut-être plus sémantiquement significatif que b car un peu plus général, mais sans doute moins que address, dans la mesure ou ce dernier contient plus d'infos sur le sens de son contenu.
  • # C'est bien beau...

    Posté par . Évalué à 1.

    Mais...
    moi, je suis pas webmestre, mais j'aimerai bien !
    Faire un tout petit site simple comme bonjour, sans ligne éditolriale particulière...
    Bref, juste quelques pages avec des liens dedans et quelques images.
    Et alors, pourquoi pas respecter les standards et utiliser une mise en page à l'aide des CSS (c'est bien à ça que ça sert non ?)
    Le tout surtout pour apprendre !
    Je sais, openweb est fait pour moi !
    Mais je ne sais pas par où commencer.
    Existe-t-il des bons tutos qui permettent de s'y mettre ?

    Merci
  • # c'est bien gentil ...

    Posté par . Évalué à 2.

    ... mais je vois mal comment tu vends a un decideur préssé que son site web n'est pas ou est mal visible chez 80% de ses clients

    meme s'il est sensibilisé a la securité, la perenité et aux standards ca ne passera pas c'es tout
    • [^] # Re: c'est bien gentil ...

      Posté par . Évalué à 0.

      Pourquoi tu ferait un site pas ou mal visible toi ?

      on peux faire un truc standards qui passe partout aussi ...

      Dam
    • [^] # Re: c'est bien gentil ...

      Posté par . Évalué à 1.

      Avant toute chose, commence par lui vendre Firefox. Incidement il deviendra ton allié, sans même s'en apercevoir. Sournois mais efficace.
  • # Beau texte

    Posté par (page perso) . Évalué à 2.

    Tout est dans le titre : voila un beau texte.
    Commentaire peut être inutile, mais je tenais à le dire.
    • [^] # Optimisme 2ème édition

      Posté par . Évalué à 3.

      C'est la 2ème fois que je le dis sur DLFP : on peut faire des sites XHTML 1.1 et CSS qui marchent aussi sur IE.

      La méthode c'est : toujours un Firefox d'ouvert et toujours un IE d'ouvert. On se base sur le rendu Gecko pour faire une feuille de style propre, puis on corrige avec des hacks spéciaux pour IE. Des fois spéciaux pour IE Mac. On peut même faire tourner le site décemment sous IE 5.0, et oui cinq point zéro.

      C'est pas la mer à boire.

      Sinon pour le "blues du webmaster". Je crois plutôt que c'est ton blues... On est à l'heure du cliquodrome CMS mais sans feeling informatique les gens ne sont pas capables de mettre correctement un article en forme. Je suis sûr que le rôle de webmaster reste primordial aujourd'hui, parce qu'il s'intéresse à la structure de son information globalement sur le site alors que les utilisateurs se soucient juste de leur petit article à eux. Et il n'y a pas grand monde qui peut comprendre cela dans une boîte (hors secteur informatique bien sûr). Donc souvent on est seul, parce que on est le capitaine du bateau Internet. Allez moussaillons souquez ferme direction le W3C !
      • [^] # Re: Optimisme 2ème édition

        Posté par . Évalué à 2.

        on peut faire des sites XHTML 1.1 et CSS qui marchent aussi sur IE.
        on corrige avec des hacks spéciaux pour IE


        Je profite de l'occasion pour te demander si tu voudrais bien mettre en ligne ou me faire parvenir quelques exemples de présentations en css clean avec hacks IE incorporés (commentés si possible:), ceci dans le but d'intégrer les exemples dans Wookie, un éditeur css wysiwig que je développe actuellement:

        http://www.zwook.org/fr/dossiers/web/css/wookie/(...)

        Cet éditeur est notamment à vocation pédagogique, outil pour apprendre le positionement css. Il contient des exemples commentés, mais actuellement aucun n'a été testé sous IE, et je suis pas du tout compétent sur les hacks css IE. Ca serait super de pouvoir profiter de ton expérience sur le sujet pour fournir quelques exemples solidement commentés, dans l'idée de compléter la collection d'exemples du Wookie.
        • [^] # Re: Optimisme 2ème édition

          Posté par . Évalué à 2.

          Va voir sur ce site :
          http://dean.edwards.name/IE7/(...)
          Le mec a synthetisé tous les hacks possible pour IE dans une css. En gros tu codes ton site en css2/xhtml pour Firefox et ensuite tu utilises cette css en + pour que ca marche correctement sous IE.
        • [^] # Re: Optimisme 2ème édition

          Posté par . Évalué à 3.

          Alors en fait y'a 2 grandes solutions je pense que tu es au courant :
          1) détecter le navigateur et importer la bonne feuille de style
          2) avoir 1 seule feuille de style avec des hacks CSS qui permettent d'écrire des bouts de la feuille de style seulement lus par certains navigateurs.

          Pour l'instant j'ai pu me contenter de la soluce 2. L'avantage c'est que tu n'as pas 2 fichiers dans lesquels reporter toutes tes modifs et à maintenir. L'inconvénient il y en a 2 : la feuille de style est plus lourde et surtout il faut vraiment ruser parfois pour réussir. IE Mac respecte assez bien les standards mais sur certains points il lui faut des hacks que pour lui...

          Je commence sous Gecko (je dis Gecko pour simplifier, ça sous-entend les navigateurs qui respectent bien le CSS) :
          .monstyle {attributs: paramètres Gecko;}


          Cas simple : si le rendu diffère sous IE je mets les bons paramètres pour IE en normal dans la feuille de style à la place :
          .monstyle {attributs: paramètres IE;}

          Puis j'écrase avec les paramètres normaux CSS pour les navigateurs Gecko :
          html>body .monstyle {attributs: paramètres Gecko;}

          Qui est lu par tout sauf IE. Ca c'est dans le cas simple.

          Cas compliqué : si le rendu diffère entre IE Mac et IE Windows je mets les paramètres CSS pour IE Mac en normal dans la feuille :
          .monstyle {attributs: paramètres IE Mac;}

          Puis je corrige pour tout sauf IE Mac : (attention à bien mettre \*/)
          /* code invisible pour IE Mac \*/
          html>body .monstyle {lesCSSàcorriger: paramètres Tout_sauf_IE_Mac;}
          /* fin de code invisible pour IE Mac */

          Enfin pour rétablir les bons paramètres Gecko je remets :
          html>body .monstyle {lesCSSàcorriger: paramètres;}


          Sinon il y a aussi ça qui peut servir :
          .monstyle {lesCSSjustepourIE: paramètres !important;}
          que reconnait uniquement IE.

          Il existe d'autres hacks mais l'avantage de ceux-ci est : ils passent au validateur CSS du W3C. Ceci dit il n'y a pas de garantie qu'ils continuent toujours à valider, si le W3C décide d'être moins permissif dans son validateur CSS.

          En pratique j'ai surtout du être attentif sur ces points :
          • Gecko ajoute les bordures des boîtes à l'extérieur des boîtes, donc la dimension totale des boîtes est : leur dimension + l'épaisseur cumulée des bordures. IE compte les bordures à l'intérieur de la boîte

          • padding/margin

          • les background-image doivent souvent être repositionnés


          Ce n'est pas simple, mais c'est vraiment faisable même avec une charte relativement complexe. Le site dont je m'occupe sera bientôt en ligne, je donnerai l'adresse à ceux que ça intéresse. Mais c'est sûr qu'il faut mettre les mains dans le cambouis, et à part un webmaster je ne vois pas qui peut le faire. Dans le cadre d'un éditeur WYSIWYG CSS les gens recherchent plutot la simplicité je suppose, donc je ne sais pas si ça va t'aider mais j'espère !

          Un autre problème des CSS c'est les colonnes, c'est souvent contourné en imbriquant un tas de div les unes dans les autres. Pour ma part pour des raisons de sémantique je ne voulais pas avoir ce système alors j'ai inventé une astuce assez dégueu mais qui marche : mettre en background-image de body une image d'1 pixel de haut et comportant les couleurs des 3 colonnes, puis en lui donnant la propriété repeat-y. Puis comme j'ai des éléments qui doivent aller en bas de page dans une colonne donnée, j'ai même dû utiliser du Javascript qui détecte les tailles des divs et les augmente au besoin...
          • [^] # Re: Optimisme 2ème édition

            Posté par . Évalué à 2.

            il y a une erreur
            ie ne gere pas le !important c'est une directicve CSS1 qui n'est pas gere et je m'en sert pour diffrentier le code IE / Navigateur conforme

            width: 200px !important;
            width: 195px;

            Gecko prendra le premier et ie qui ne vois pas le !important prendra le dernier ...


            Dam

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.