Je ne pense pas definir mon passé d'informaticien comme étant un passé de hacker (quoique..), j'ai peut-être plus un passé 'geek' (mmmm, à vrai dire, c'est sûrement à peu prés la même chose, les différences sont subtiles, faudrait que je relise le jargon), mais en tout cas, en lisant la Hacker Faq, j'ai l'impression qu'elle dresse une partie de mon portrait assez representatif au boulot :-). Sauf le coté relationnel, je ne pense pas être comme ça... Ah oui bon ba je suis pas un vrai hacker alors :-)
En tout cas, j'ai parfois l'impression d'être pris pour un extra-terrestre là bas, avec mon pc sous linux, toujours en train de parler de standards W3C, de logiciel libre à tout bout de champs, à pester contre la dernière désinformation microsoftienne, et à coder/surfer toute la journée en utilisant des outils aux noms bizarres comme vi, ssh, quanta, bash, kde. Enfin, je ne dois quand même pas trop faire peur, vu qu'on me dérange de plus en plus pour des histoires de PHP, linux, HTML/CSS, open-source etc.. (et j'en suis ravi :-)
Et puis il y a un point sur lequel je ne suis pas d'accord dans cette faq, c'est le numéro 3.2. Mais alors pas du tout ! Alain, Jérôme, si jamais vous me lisez... ;-)
Tout le monde attend avec impatience CSS3 pour pouvoir faire des bordures réalisées à partir d'image. Pour l'instant, ce n'est pas possible, et il est difficile de faire des pages contenant des bordures "graphiques" sans porter atteinte à la sémantique du document.
Il y a des techniques utilisant des tableaux, ou d'autres utilisant des divs, comme je l'ai moi-même déjà expliquer dans un petit tutoriel.
En allant sur le site www.schillmania.com, indiqué par Daniel à propos d'un jeu arkanoid fait entierement en javascript (au passage, admirez le code source, ça vaut le détour, et montre bien que le langage javascript est à la hauteur de beaucoup d'autres :-), j'ai découvert que l'auteur de ce site avait une autre technique.
Le code HTML de la page est ce qu'il y a de plus sémantique. Il n'y a pratiquement pas de div vide ou autre balise qui servent à aménager des emplacements pour les bordures, les coins des bordures comme dans ma technique.
En fait, tout ces élements HTML sont générés dynamiquement en javascript, aprés le chargement de la page, grâce aux fonctions de manipulation du DOM (getElementById, createElement et consort). Les feuilles CSS se chargent du reste.
Ainsi la page a un source HTML de base qui reste clair, sémantiquement correct, tout en ayant une présentation un peu plus "stylé".
L'inconvenient de cette méthode, c'est qu'il faut avoir le javascript activé bien entendu, pour profiter du design, et que la page s'affiche un peu plus lentement. Surtout sur ce site où les boites à bordures imagées sont légions.
Eric nous liste ses arguments contre l'utilisation des systèmes anti-aspirateur de site. Son point de vue est tout à fait valable, au point même que je me sens cupalbilisé :-). En effet, j'utilise moi-même un système anti-aspirateur sur mon site tahiti-fenua.com.
Cependant, j'ai ma propre opinion envers ces outils "vampires". Voici donc mes arguments pour l'utilisation de systèmes anti-aspirateur, en particulier dans mon cas précis.
Un aspirateur aspire le maximum de page qu'on lui indique. La visite d'un aspirateur n'est donc pas representatif, et le nombre de page "lues" ne devrait donc pas pris en compte dans les outils de stats. Il y en a qui font la distinction entre visiteur normal et robot/aspirateur. Mais je ne sais pas si, par exemple dans Awstats, les resultats de visites et de page lues au total prennent oui ou non en compte les stats liés à ces visiteurs pas commun. Et puis comme l'a fait remarqué Eric, étant donné que l'on peut modifier le user-agent dans la plupart des aspirateurs, on se retrouve donc avec des statistiques faussées (et si en plus l'outils de stats ne fait pas la distinction visiteur normal vs aspirateur...).
Ca n'a pas l'air grave, mais en fait, pour moi, un peu quand même. Sur un petit site comme le mien, qui ne compte que 400 à 500 visiteurs par jour, avec une moyenne de 5200 pages lues par jour, le passage d'un aspirateur boulverse profondément mon petit moteur de stats. Le dernier internaute qui a aspiré le site, cela a representé au bas mot prés de 5000 pages ! (Et oui, ca en fait des pages, les forums, et tout et tout... et je ne compte pas les images, css..). On voit bien que finalement, les stats sont toutes faussées, ce qui rend le suivi de l'evolution du site un tantinet difficile. Déjà que les outils de stats, ne sont pas par nature fiable à 100%... Si j'avais des millions de hits par mois, je m'en foutrais un peu. Mais là...
Ma liberté à moi c'est de pouvoir regarder avec amusement ces petites courbes de stats monter chaque mois, sans que leur progression ne soit perturbée par des vampires (oui, je sais, ca fait un peu egoiste..).
Et si il n'y avait que ça encore...
Quand un aspirateur passe sur mon site et pompe 5000 pages en quelques dizaines de minutes, je suis en droit de me dire que, oui, les aspirateurs, ça suxor !
Quels interêts aura l'internaute de télécharger le site entier ? ou même seulement une rubrique entière. Aucun dans le premier cas, mais compréhensible dans le second. Je doute fort qu'il lise les 5000 pages et qu'elles l'interressent toutes. Au final, c'est un gachis en temps de téléchargement et de bande passante, autant pour lui que moi.
Que dire aussi lorsque le contrat d'hebergement impose une limite de bande passante, de X Mo par mois ? Que quelques internautes passent l'aspirateur sur votre site, et vous voilà à payer les Mo de bande passante supplémentaire à la fin du mois, quand ce n'est pas à pleurer devant le blocage pur et simple de l'accés au site par l'hebergeur.
Actuellement, je ne suis pas dans ce cas, mon hebergeur ne m'impose pas de limite, mais ça pourrais le devenir si mon site bouffait trop de BP.
La machine hébergant mon site commence à ne plus se faire toute jeune. Malgré la ligne 100Mbits/s sur laquelle elle est connectée, avec son pentium 200 et ses 128 Mo de ram, la vieille s'essoufle vite au passage d'un aspirateur. J'ai fait l'experience et je peux vous assurer que le processeur pédale comme un fou (à cause en grande partie de la forte sollicitation de la base de donnée dans ces moments là).
Du coup le site devient difficilement accessible pendant quelques minutes. Et pas seulement le mien, mais tout les autres petits sites qui sont sur la même machine, parce que je ne suis pas sur un serveur dedié.
Laisser pomper le site par un seul internaute, et par la même occasion, empécher tout les autres de visiter le site (et les autres sites) agréablement : je ne vois pas ce que cela apporte globalement. La liberté des uns, s'arrète là où commence celle des autres. Je prefère privilegier donc la majorité des internautes. Je ne vois pas pourquoi Monsieur le pompeur aurait plus le droit qu'un autre de visiter le site.
Autant, sinon, faire une seule page, proposant en téléchargement avec un zip contenant tout le site. Et encore, là aussi, ça ne resoud pas le problème de bande passante. Ca l'agraverais même. Et puis ce n'est plus ce que j'appel du web.
Un anti-aspirateur, bien fait, ne devrait pas géner la visite des robots d'indéxation des principaux moteurs de recherche.
A voir le code source de la solution de phpfreaks,celle-ci n'est pas terrible, voir idiote.
Ma solution ne bannit pas tout à tarlarigo. Lorsque le nombre de pages lue sur une periode donnée pour un internaute donné, dépasse un certain seuil, une page spécial, légère est affiché avec un petit texte explicatif. Il suffit donc d'attendre quelques minutes/secondes pour reprendre la visite (ou le pompage).
Certes, cette methode m'oblige à faire des enregistrements en base de donnée, mais étant donné que ceux-ci me servent également pour mon petit outil de stats perso, je n'y echappe pas...
Il faut noter que cela ne concerne pas les images, css etc. Donc l'enregistrement d'une ou quelques page en local n'est nullement affecté (à ma connaissance).
Et finalement ma méthode n'empêche nullement les robots d'indexations. En observant les accés de ceux-ci sur le site, on remarquera qu'en fait, ils etalent leurs requètes sur la journée. On constatera ainsi que google ne fait en moyenne que quelques requètes (1 à 10 ) par heure, un taux qui est loin d'égaler celui des aspirateurs et qui n'activera donc pas le blocage de l'anti-aspirateur.
Quand Tahiti-fenua aura des milliers de visiteurs par jour, sera hebergé sur une bécane performante, que j'aurais optimisé le code de manière à mettre en cache les pages pour moins solliciter la base de donnée, quand j'aurais un outil de stats plus performant, que je pourrais à loisir consommer toute la bande passante car le site sera sur un serveur dedié, je pourrais alors enlever ce système anti-aspirateur.
Mais je n'en suis pas encore là, donc je garde pour l'instant mon anti-aspirateur :-).
Par contre, si vous n'êtes pas dans mon cas, vous n'avez, comme l'a dit Eric, peu de raison d'avoir un anti-aspirateur.
C'est le printemps et ça se voit. Y a du ménage un peu partout. Et je n'ai pas été épargné par cette pratique traditionnelle, puisque j'ai mis en ligne ce matin une nouvelle version de mon site www.Tahiti-fenua.com.
Cette version est quasi identique visuellement par rapport à l'ancienne, mais la différence se voit dans le code HTML : les pages sont dorénavants conformes aux standards ! C'est un minimum pour un webmestre impliqué dans l'évangélisation des standards, vous ne trouvez pas ? :-)
Cette refonte a été plus longue que prevue, non pas parce que les standards sont compliqués, mais parce que j'en ai aussi profité pour refondre une partie de mon code PHP. En effet, le code de ces parties était plutôt vieux, lourd, digne d'un débutant, qu'il était donc nécessaire de le retaper pour plus de performances, de sécurité et de facilité de maintenance. Une manie de geek en somme (les geeks ne sont jamais satisfait).
Enfin bref, parmis les sites majeurs sur la Polynésie, voilà le premier à être conforme aux standards, et j'en suis pas peu fier !
Pour les puristes, sachez que certaines pages ne valident pas, car elles font appel à des textes stockés en base de données, contenant du vieux code invalide (des balises b en majuscules par exemple..), par rapport à la DTD que j'ai choisi au depart (XHTML 1.0/strict). Qui plus est, la fonction nl2br de la version PHP dont je dispose, transforme les sauts de lignes en br au lieu de br / comme elle le fait dans les versions plus récentes de PHP. Et je ne m'en suis rendu compte, qu'à la mise en ligne. Donc ce soir, j'ai encore un peu de boulot :-) (finalement, je regrette d'avoir pris du XHTML ;-)
Sinon, au niveau accessiblité, c'est pas le top du top, mais c'est déjà beaucoup mieux qu'avant.
Au niveau de l'adaptabilité des pages, c'est pas terrible car figé en 800 de large. Je pense en fait qu'il faudrait totalement repenser ce vieux design qui commence à dater. Mais n'étant pas vraiment artiste en la matière (y a qu'à voir ce blog :-D), je n'ai donc pas modifié le design (celui-ci n'etant pas de moi à la base). Si toutefois ça en inspire quelques uns, il y a mon email en bas ;-).
Enfin voilà, le site n'est pas encore parfait. De toute façon, il ne le sera jamais, avec un développeur comme moi, qui est à la fois fainéant, puriste et perfectionniste dans l'âme. (Par exemple, ça m'agace ces franges sur les cotés qui ne descendent pas jusqu'en bas; j'ai bien la solution, mais là, j'ai envie de vivre des soirées un peu plus reposantes :-) )
Dans l'immédiat, toutes ces imperfections ne sont pas vraiment importantes. Je les corrigerais au fur et à mesure. Pour finir, je voudrais faire remarquer à ceux qui pensent que standards/CSS rime avec laideur, que Tahiti-Fenua.com est la preuve vivante qu'on peut faire un beau site (ce sont mes internautes qui le disent depuis toujours qu'il est beau ;-) en HTML/CSS, et en tout cas, sans être forcément "carré". Elles ne sont pas jolies ces petites franges ondulées ? Et cette petite liste d'archipels, qui suivent la courbe d'une image de fond, faite simplement d'une liste UL et de styles CSS ? ;-)
PS: j'ai arreté de supporter Netscape 4. Il n'y a donc aucune feuille de style spécifique pour ce navigateur, mais le site reste lisible et accessible.
Je suis un peu moins actif sur mon blog, pour une bonne raison : l'hebergeur free m'agace de plus en plus. Les pages mettent un temps infini à s'afficher, quand elles s'affichent. Poster un message est donc un veritable calvaire. Le service de free devient vraiment nul à chier.
J'ai donc décidé de changer d'hebergeur. Il faut donc vous attendre à un changement d'adresse dans les prochains jours.
En voilà une entreprise qui écoute ses internautes !
Etant abonné à la mailing-list du groupe de travail d'interopérabilité de l'AFUL, j'ai pu suivre une action du groupe à l'encontre Google. Cette action visait à rendre visible les statistiques concernant mozilla dans le zeitgest (le rapport statistique mensuel de google), ou plutôt à clarifier les intitulés. Le Netscape 5.x est ainsi devenu Netscape 5.x (inc Mozilla)
Mine de rien, ce petit changement est un peu une révolution : Mozilla est trés rarement cité dans les statistiques des gros sites comme google. Espérons que cette reconnaissance lui donne un peu plus de crédibilité face aux décideurs et aux autres internautes, et qu'ainsi, fasse monter cette courbe statistique qui tarde malheureusement à décoller.
Eric nous fait un bon topo sur les unités, lesquelles sont préférables, leurs conséquences sur le design et l'accessibilité.
Bon, je ne sais pas ce qu'en penserait la redaction d'OpenWeb, mais moi je suis d'avis pour qu'Eric nous le refasse, en plus complet (avec exemple et tout) ;-)
Je viens de découvrir le about:mozilla (à taper en tant qu'url), qui affiche des versets de l'apocalypse, remanié par les developpeurs de Netscape.
Dans Mozilla 1.3, ça donne:
And the beast shall be made legion. Its numbers shall be increased a thousand thousand fold. The din of a million keyboards like unto a great storm shall cover the earth, and the followers of Mammon shall tremble.
from The Book of Mozilla, 3:31
(Red Letter Edition)
Traduction de ce verset de l'apocalypse sauce Mozilla :
Et la bête deviendra légion. Elle se reproduira par milliers de mille. Le vacarme de millions de claviers tel un déluge couvrira la terre, et les adeptes de Mammon trembleront.
C'est pour bientôt, je vous assure, le mal sera vaincu ! Un jour...
Le plus drole, c'est celui que l'on trouve dans Netscape 4.78 :
And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days.
from The Book of Mozilla, 12:10
Argggg ! J'aimerais pas être à la place de ceux dont les balises clignoteront à jamais. Quelle horreur ! :-)
C'est un site regroupant beaucoup de documentation libre, sur linux, la programmation etc. En fait tout ce qui touche à l'informatique libre. On y retrouve bien entendu des documents sur les standards du web et notament, au coté des documents issus du W3C, il y a les articles... d'OpenWeb ! Cool non ? (Je rappel que les articles d'OpenWeb sont publiés sous la licence OpenPublication comme indiqués dans les conditions de réutilisations, et que par conséquent, il est tout à fait possible de les recuperer).
En plus, le site est conforme aux standards :-)
Voilà une nouvelle qui aurait magnifiquement sa place sur totalement cretin. Illiad, le gros groupe possédant notament free, a envoyé un mail à tout les possesseurs de noms de domaines qui contiennent le mot annu. Il les menaces de poursuite judiciaire, sous pretexte que ces personnes (dont la plupart des sites ne sont pas commerciaux) ont enfrein le code de propriété intellectuel, car illiad posséde la marque annu.
Mais où va-t-on ? Imaginez les conséquences de ces poursuites. C'est la porte ouverte à d'autres de ce genre : je m'en vais déposer la marque bank (si pas déjà déposé), et intenter un procés à tous ces sites de banques qui utilise ma marque !
Le site debian-fr.org vient de faire peau neuve, avec des pages HTML transitionnal valide et une utilisation quasi systématique des CSS. Mais hélas, il n'y aucun respect de la sémantique des balises.
C'est dommage, car cela rendrait la page beaucoup plus légère, plus accessible, et surtout beaucoup mieux maintenable, comme je le démontre ici.
Eh oui hein ! c'est mieux ;-)