J’avais vu l’URL passer dans les commentaires d’un billet sur latchman.org et m’était précipité pour installer ce pilote providentiel. Je rediffuse l’adresse ici car ce pilote est vraiment très pratique. En effet, il vous permet d’avoir accés facilement à des caractères autrement difficile d’accés (majuscules accentuées, guillemets français et anglais, signe ±
, etc…). Une aubaine pour ceux qui aiment soigner leurs écrits sur Internet.
Une des grandes forces de Firebird (et Mozilla), c’est le nombre phénoménale d’extensions disponibles, toutes plus utiles les unes que les autres. En voici quelques unes que j’utilise :
La perle des perles. Cette extension facilite vraiment la vie de tout ceux qui développent des pages (X)HTML. Voyez plutôt :
alt ou title alt id et class présent dans la page title ou encore les cellules d’un tableau Et j’oublie sùrement quelques autres fonctionnalités, je n’ai cité que celles que je trouve les plus intéressantes.
Du même auteur que l’extension Web Developer, cette extension vous permet de modifier le contenu de l’entête user-agent que le navigateur envoie au serveur. Pratique pour accéder aux sites récalcitrants qui font du Spoof browsing.
La console javascript présente dans Firebird et Mozilla est très pratique, mais il est vite fastidieux de devoir la lancer chaque fois pour vérifier si des erreurs javascript sont présentes dans la page. Cette extension permet de faire apparaître un petit icône dans la barre de statut du navigateur pour vous prévenir si des erreurs javascript se produisent.
Une de mes extensions fétiches :)
Avec elle, vous verrez tout le dialogue échangé entre le navigateur et le serveur. Très pratique pour mieux
comprendre le fonctionnement du protocole HTTP.
Il existe beaucoup d’autres extensions, et pas seulement utiles aux développeurs. Pour les installer, ils vous suffit
de télécharger le fichier .xpi correspondant directement avec Firebird ou Mozilla et l’installation débutera sitôt
le téléchargement terminé.
Comment ? Vous êtes sous IE ? Arf, je ne
peux dans ce cas que vous proposer avec force d’essayer le navigateur Mozilla
ou son petit frère Firebird,
vous ne serez pas déçu et pourrez profiter des superbes extensions dont j’ai parlé plus haut :)
Les feuilles de style, c’est vraiment un outil formidable, non seulement par la facilité qu’elles apportent à gérer la présentation de ses pages, mais aussi en terme d’accessibilité. Une utilisation très peu connue et utilisée, quoiqu’un peu plus par les adeptes de Mozilla/Firebird mais de façon superficielle (via les bidouilles anti-pub), est la possibilité pour le visiteur de définir des règles CSS à appliquer aux sites qu’il visite.
Pour les utilisateurs de Mozilla ou Firebird, c’est très simple, il suffit de modifier le fichier
userContent.css présent dans le dossier chrome/ de votre profil (renommer d’abord le fichier
userContent-example.css en userContent.css si besoin est). Pour les utilisateurs de
IE6, vous pouvez spécifier une feuille de style
utilisateur via outils -> options internet... -> accessibilité. Je ne sais ce qu’il en est pour les
autres navigateurs. Les règles de style que vous indiquerez dans cette feuille utilisateur s’appliqueront si l’auteur
du document (la page que vous visitez) n’a pas déja précisé cette règle dans la feuille de style du site (s’il y en
a une). Pour outrepasser cette ordre de priorité, faites suivre chaque règle de style que vous voulez appliquer par
!important (avant le point virgule, et il y a un espace avant le point d’exclamation).
Bien entendu, cela suppose que vous ayez un minimum de connaissances en CSS,
mais on peut espérer une généralisation de l’utilisation des feuilles de style utilisateur, et l’apparition à l’avenir
de sites listant plusieurs règles de style basiques et généralistes à appliquer dans ces feuilles utilisateur.
Si vous avez bien suivi jusque là, vous vous êtes sùrement posé la même question que moi. Que se passera t-il si je définis cette règle dans ma feuille de style utilisateur :
body {
background-color: black !important;
}
La règle s’appliquera en effet, et d’autant plus qu’elle aura un ordre prioritaire (avec !important) sur
la même règle éventuellement définie dans la feuille de style de l’auteur, mais elle s’appliquera à tous les sites
que vous visiterez. En effet, il n’existe pas de mécanisme natif pour lier des règles de style à un site en particulier.
Une pratique commence à se répandre parmi les adeptes des standards et de l’accessibilité qui consiste à utiliser l’attribut
id du HTML pour fournir à leur site
un identifiant unique, ce qui a pour effet immédiat de donner un caractère d’unicité du site vis à vis de la feuille de
style utilisateur. Ainsi, j’ai placé un attribut id dans la balise html (on peut aussi bien le
placer sur la balise body) avec pour valeur site_webnaute — Attention cependant, l’attribut id
sur l’élément html n’existe pas dans
la recommandation sur le HTML 4.01 ni dans aucune des
DTD du XHTML 1.0 mais bizzarement, ma page
est tout de même valide aux yeux du validateur du W3C
aussi bien que de celui du WDG (Anne Vankesteren
propose d’ailleurs l’ajout pur et simple de cet attribut id si besoin est comme elle il
l’explique ici) Mise à jour : En fait, l’attribut id n’est pas défini dans la première version de la recommandation sur le XHTML 1.0 mais il l’est dans la deuxième édition de cette recommandation —
Notre essai précédent sur la couleur d’arrière plan deviendrait donc :
html#site_webnaute body {
background-color: black !important;
}
Admettons tout de même que cette solution est loin d’être pratique, en plus du fait que l’ajout d’un attribut id
unique sur les éléments html ou body reste très marginal voire inexistant parmi les concepteurs de site.
Anne Vankesteren, toujours elle il,
propose l’ajout d’un nouveau mécanisme dans une future version des feuilles de style CSS. Ainsi :
@address "annevankesteren.nl"{
/* user specific styling */
}J’avoue que l’idée m’a paru séduisante au départ, mais après mùre réflexion, je ne pense pas que ce soit une bonne idée. Un tel mécanisme ne devrait rien avoir à faire dans une feuille de style CSS. Leur rôle se limite à la présentation de document, sans avoir à dicerner tel ou tel document. Et cela vaut encore plus pour faire la distinction selon le nom de domaine car la feuille ne s’appliquerait alors pas si le document est visualisé en local. Non, à mon avis, point de salut si ce n’est dans les concepteurs de navigateurs web :/.
Les concepteurs de site du monde entier en révaient, cela semblait impossible jusqu’à maintenant, et pourtant, quelqu’un a trouvé LA solution. L’auteur de cette page explique comment s’y prendre pour avoir plusieurs versions de IE sur le même système Windows, en l’occurence, les versions 5.01 et 5.5 (en plus d’une version 6.0 que vous auriez installée classiquement). J’ai bètement reproduit les manipulations nécessaires avec succés avant de me rendre compte que l’auteur propose également les archives zip déja prètes, il suffit de dézipper et de lancer l’exécutable iexplore.exe.
En tout cas, ça marche parfaitement bien, et j’ai d’ailleurs eu quelques surprises en testant mes sites avec IE 5.01 :)
Décidément, IE est à la fête sur Webnaute ces
temps ci :). Après la famille IE réunie (cf. billet précédent), voici un programme nommé
HTTP Interceptor
qui, couplé avec IE, vous permet de voir les entêtes échangés entre votre navigateur et le serveur.
Le programme en question peut être téléchargé à
cette adresse. Après l’avoir installé, vous devez régler votre connexion pour qu’elle utilise un proxy:
Mettez localhost comme adresse et 81 pour le port.
Ensuite, démarrez le programme et avec IE, rendez vous sur une page quelconque. Le programme vous
affichera les entêtes échangés.
C’est un bon programme pour ceux qui s’interessent au protocole HTTP ou qui veulent débogguer par exemple un script CGI. Notons tout de même que le programme est disponible dans une version "free" et dans une autre version pour laquelle il faut s’enregistrer. La version "free" est limitée dans le nombre de lignes d’entêtes qu’elle affiche :
The unregistered version only shows the first 50 lines of headers.
After that it works like a proxy server.
You must quit and restart to view more data
Register now, Only $45.00
J’ajoute que le programme est assez simpliste, voire pas très lisible. À coté de ça, vous avez
Firebird
et sa myriade d’extensions, toutes libres, gratuites et plus utiles les unes que les autres, dont
LiveHTTPHeaders
qui rend les mêmes services que HTTP Interceptor
mais en beaucoup mieux. Qu’attendez vous pour télécharger tout ça ? :)
P.S : Je connaissais déja l’incroyable
accept: */* dont nous gratifiait IE, par
contre, je découvre que le pas beau n’envoie pas d’entête accept-charset.
Une brute j’vous dis, une brute…
Oulala, j’avais juste fini de mettre en ligne le précédent billet que je me suis rappellé une autre "extension" pour
IE (On peut pas vraiment appeller tous ces trucs
"extensions" mais bon…). Vous, oui vous là qui utilisez encore cette antiquité nommée
Internet Explorer
, vous avez entendu parlé de cette chose étrange appellée
feuilles de style alternatives
, vous ne savez pas ce que c’est et aimeriez bien le savoir ?
Il y a deux solutions pour résoudre ce problème.
outilspour y trouver l’item List Stylesheets. Et voilou :)
Pfiou, si ça continue, on va m’appeller le bloggeur fou ;-)
Quel malheur d’avoir des connaissances en CSS et d’être une tanche en design… Bref, n’hésitez pas à jouer du ctrl+F5 les prochains jours.
Comme je suis un peu maniaque à mes heures en ce qui concerne le fait de classer les choses, je viens d’ajouter un système de classement de mes billets par catégories. N’hésitez pas encore une fois à faire des ctrl+F5 pour voir les changements.
À faire prochainement :
Un site en plein écran .... Attention aux yeux !!! Merci de donner votre avis !!!!
http://****************
N’hésitez pas !
Berk. Les sites en plein écran sont une abomination. Personnellement, quand je tombe sur de tels sites, je tourne les talons aussitôt.
Ne mettez pas votre site en plein écran, c’est génant pour l’utilisateur, il ne sait plus où il est, n’a plus accés à la barre de menu, n’a plus accés à rien et c’est extrèmement frustrant. On peut envisager à la rigueur une page précise qui serait en plein écran (contenant par exemple une anim flash assez conséquente) et où l’utilisateur serait pleinement conscient de ce qui l’attend — C’est à dire qu’il aurait été prévenu sur la page précédente que la page qu’il va consulter s’affiche en plein écran — mais c’est tout. Un site en plein écran, c’est le meilleur moyen de faire fuir vos visiteurs.
Et pouf, une feuille de style dédiée à l’impression fait son apparition. D’ailleurs, si quelqu’un fait le test, tout retour d’expérience est le bienvenue vu que je n’ai pas d’imprimante chez moi :¬)
Une nouvelle fenêtre pour chaque nouveau site, c’est un peu comme si tu changeais de planche à chaque vague que tu surfes...
ROFL. J’adore cette métaphore :)
Vous vous êtes peut être posé la question suivante : Mais comment fait-il pour que son site soit aussi
rapide ?
Non ? Tant pis, je vais tout de même vous répondre. Pour la suite du billet, comprenez
"navigateur web" par "agent utilisateur". J’utilise ce terme simplement parce qu’il n’y a pas que les navigateurs
web qui utilisent le protocole HTTP,
cela peut aussi bien être un script CGI.
Un agent utilisateur demande une copie d’un document, je la lui fournis. Il la redemande un peu plus tard, que faire ? En toute logique, je regarde si le document en question a subi des modifications et si c’est le cas, je lui fournis une copie du document modifié, dans le cas contraire, je lui indique que le document n’a pas subi de modifications et qu’il peut donc utiliser la copie qu’il a obtenu antérieurement. Mieux, je peux indiquer dans la foulée à l’agent utilisateur qu’il n’a pas besoin de me demander toutes les trois minutes si le document a été modifié et que la copie qu’il a en sa possession est valide pendant une heure.
Tout ceci est possible avec le protocole HTTP 1.1 et c’est d’ailleurs exactement ce que je fais. Je comptais réaliser un long billet, mais après quelques dizaines de lignes tapées, je me rend compte qu’il serait beaucoup trop long et mériterait plutôt l’appellation d’article. Je vous livre donc la petite classe que je me suis confectionné pour gérer tout ça et je rédigerai un article plus complet ultérieurement. J’ai ajouté un petit explicatif/exemple en tête du fichier PHP.
Autre chose qui fera du bien à votre serveur si le module apache mod_expires est installé (à mettre dans un fichier .htaccess):
ExpiresActive on
ExpiresByType image/gif A86400
ExpiresByType image/png A86400
ExpiresByType image/jpeg A86400
ExpiresByType text/javascript A86400
ExpiresByType text/css A86400Cela permettra au serveur d’indiquer à l’agent utilisateur de ne vérifier qu’une fois par jour si les images, feuilles de style et fichiers javascript ont été modifiés. Autant de hits en moins sur votre site et de temps gagné pour l’affichage de la page par le visiteur.
Près de cinq mois se sont écoulés depuis que j’ai découvert Openweb. Cinq mois pendant lesquels j’ai découvert un nouveau monde peuplé de bloggeurs fous, d’adorateurs des spécifications et de personnes à l’avant garde du développement du web. Cinq mois à retourner les archives de moults blogs, à faire des recherches sur la toile, à découvrir de nouvelles possibilités des feuilles de style, à tester, à hanter f.c.i.w.a, à retester… Le temps passe, les connaissances s’accumulent.
Un mois depuis que j’ai mis en place la nouvelle structure de phpCodeur et déja, je n’en suis plus satisfait.
Comme le dit bien ma signature sur les newsgroups que je fréquente : La vie d’un geek est un combat perpétuel
contre l’imperfection
.
Site plein écran ! moi penser que bien ! vous pensez pas bien du tout ! bon et bien les boules !!! je repards donc de 0.
Mais bon, merci pour vos avis au moins on sait à quoi on s’attends comme réaction !!
Alors moi changer !!Friendly !
Yes ! Encore une victoire de canard des standards.
Voir le billet précédent.
Ahh, les feuilles de style de niveau 3… La majorité d’entre nous piaffe d’impatience dans l’attente de leur passage en tant que recommandation officielle du W3C. Malheureusement, il reste encore beaucoup de travail et ce n’est donc pas pour tout de suite, et je ne parle même pas après cela de leur intégration rapide dans les navigateurs (suivez mon regard).
Par chance, il existe un navigateur à la pointe du respect des standards, et qui a même déja intégré quelques fonctionnalités des CSS3, ce qui me permet d’en profiter honteusement, quitte à ce que mes feuilles de style ne soient pas valides. Ce navigateur, vous l’aurez deviné, est Mozilla.
Parmi ces possibilités offertes en prime-time
, on trouve
les sélecteurs.
Cette partie des CSS3 est à l’état de
Candidate Recommendation
, ce qui signifie qu’on peut considérer son contenu comme
définitif. Ce qui m’interesse en l’occurence, ce sont les nouvelles possibilités offertes avec le sélecteur
d’attribut. On connaissait déja
les sélecteurs d’attribut : E[foo] pour cibler un élément E
ayant un attribut foo, [att~=val] et [att|=val] (personnellement, je n’ai
jamais trouvé ces deux là très utiles dans le contexte d’un document
(X)HTML).
Avec les CSS3, nous en aurons quelques uns de plus, et franchement plus utiles :
Substring matching attribute selectors (je trouve pas la bonne traduction).
Je vous invite à aller lire le lien donné, mais en gros, il sera possible de cibler un élément dont l’attribut att
commence par une valeur val, contient la valeur val (sans besoin de séparation par des espaces ou autre) ou
se termine par une valeur val. J’utilise déja ces possibilités dans ma feuille de style de base, pour ajouter
l’icône d’enveloppe après un lien vers une adresse en mailto et ajouter une icône de dossier zip après les liens pointant
sur une archive zip :
a[href^="mailto:"]:after { content: " " url("/Icones/email"); }
a[type$="zip"]:after { content: " " url("/Icones/zip"); }Franchement excellent, et je regrette presque qu’ils ne soient pas allés plus loin dans l’utilisation des expressions régulières, enfin il est vrai qu’il faut bien trouver une juste limite entre l’ajout de possibilité et le besoin de garder un fonctionnement relativement simple des feuilles de style.
Merci à Xanthor pour avoir attiré mon attention sur le module XLink. Celui ci permet de rendre des éléments activables au sein d’un document XML. Par bonheur, la recommandation qui y a trait existe en français. Je n’ai probablement eu qu’un faible aperçu des possibilités de XLink (je n’ai trouvé la traduction française qu’à l’instant) mais j’ai mis en application le peu que j’en avais vu sur mon fil RSS et ça fonctionne très bien… sous Firebird. Cela ne marche pas sous IE mais qui s’en étonne ? Le principal est que ça reste visible.
Juste un truc que je n’ai pas saisi, c’est comment utiliser le sélecteur d’attribut sur les noms d’attributs préfixés.
J’ai eu beau essayer item link[href], item link[xlink:href] ou même item link[xlink], rien à faire.
Merci Denis, béni sois tu d’avoir enfin mis en place l’ancre permettant de tomber directement sur la partie commentaires de tes billets. Ma molette de souris t’en remercie et verra sùrement sa durée de vie augmentée. :)
Je note aussi l’apparition des trackback
. Kesako ? Fabien vous explique tout. Je mettrai en place quelque chose de similaire dés que j’en aurai bien compris le fonctionnement. :/
C’est quand même désolant de voir des gens faire preuve de si peu d’imaginations qu’ils en viennent à repomper intégralement le design d’autres sites (en l’occurence, mon autre site, phpCodeur) ainsi que certaines pages (page de confidentialité, d’accessibilité...). Pire, l’auteur (le terme n’est pas vraiment adéquat ici) pousse la stupidité jusqu’à linker le site pompé sur une de ses pages, ce qui m’a permis de remonter jusqu’à lui (toutefois, le référent menait à une erreur 404).
Passer plusieurs semaines à confectionner, fignoler et tester une nouvelle mouture avec amour pour ainsi dire pour le site phpCodeur et voir le design et quelques pages pompés ainsi me donne envie de gerber.
Il ne faut pas se voiler la face, quand on conçoit un site tel que Webnaute (espace perso/journal), c’est parce que l’on a des choses à dire, mais aussi par pur plaisir de mettre le tout en place. Faire un site le plus clean possible au niveau du balisage, le plus sémantique possible et approfondir ses connaissances au fur et à mesure font partie de ces petits plaisirs du concepteur du site. L’affaire se complique toutefois quand les visiteurs peuvent intervenir d’une manière ou d’une autre sur le contenu du site.
Je parle en l’occurence du système pour commenter les billets. Comment faire pour que le contenu ajouté soit valide et un minimum sémantique ? Quelle syntaxe adopter ?
Bref, je suis toujours sur la case départ et ne sais pas quelle solution adopter ou quelle solution concevoir. Mais peut être est-ce moi qui en demande trop aussi ?
Une discussion sur la liste des pompeurs tout à l’heure traitait des moyens de cacher la feuille de style à Netscape 4.x. La discussion a dévié sur le site Openweb qui masque justement sa feuille de style à Netscape 4.x en utilisant une méthode… inconnue. On a beau triturer le code source de la page ainsi que la feuille de style, impossible de savoir laquelle ils utilisent.
On connait plusieurs méthodes (voir aussi cette page) pour cacher une feuille de style aux navigateurs périmés tels que Netscape 4.x (qui gère les feuilles de style aussi bien que je sais chanter, ce qui n’est pas peu dire). La plupart consistent en bidouilles plus ou moins efficace, mais aucune ne s’avère être la solution parfaite, logique, clean et efficace.
Bref, ma curiosité à nouveau attisée, j’ai procédé à quelques tests sur Openweb, mais sans succés. Et puis j’ai repensé au protocole HTTP, aux types MIME puis à la réécriture d’URLs. Et là, le puzzle s’assemble. La négociation de contenu, quoi de plus logique. Testons si le navigateur envoie le type MIME text/css, et si ce n’est pas le cas, envoyons lui une feuille de style basique dédiée spécialement à ces croulants que sont les navigateurs périmés.
Et après pas mal de tests et de contorsion (Netscape 4.x a vraiment des comportements bizzares par moment), il semble bien que Netscape 4.x n’envoie pas le type MIME text/css à l’appel de la feuille de style :) J’ai mis en place une page de test et d’explications afin que vous puissiez juger par vous même. Reste à voir également quel est le comportement des autres navigateurs (quelques uns ont déja été testés) — Bon, bah après avoir retester encore, je me rend compte que IE fait faux bond puisqu’il envoie */*. Grumbl, j’ai la haine contre la firme de Redmond là — .
Cette méthode aurait l’avantage d’être la plus logique et la plus simple. Évidemment, cela demande à ce que le
module mod_rewrite
soit disponible sur votre serveur, cependant, on peut envisager aussi un script CGI
qui se chargerait de tester l’entête accept et renverrait selon les cas l’une ou l’autre feuille de
style. Par contre, je ne sais pas si cela aura une quelconque incidence sur tel ou tel navigateur que le fichier
appellé par la balise <link> n’ait pas l’extension .css.
Mes tests de la nuit dernière sur le type de media text/css m’ont rappellés un document que j’avais déniché il y quelques mois au fin fond du site du W3C. Le document en question est une liste de résultats de test avec les différents navigateurs comprenant le XML et portant sur la reconnaissance des types de media text/html, application/xhtml+xml, text/xml et application/xml. Les documents de test sont également très instructifs.
Associer des liens relationnels à un document sans qu’ils soient pour autant présents dans la structure du document ? C’est possible… en théorie.
CHIP. Ce document, dont l’acronyme est assez évasif et n’attire pas forcément l’attention, décrit les problèmes courants dans la mauvaise utilisation ou utilisation incomplète du protocole HTTP pour la gestion de contenu. Je vous en recommande vivement la lecture, il est riche d’enseignement.
Aujourd’hui, je me suis appliqué à peaufiner ma feuille de style, et notamment améliorer la lisibilité du rendu sous IE 5.0x (si ça n’avait pas été une question de lisibilité, je n’aurais pas levé le petit doigt). Après avoir effectué quelques tests, je me suis rendu compte de plusieurs choses :
Quand IE 5.0x rencontre une ligne type
div#foo > div#bar, ce crétin fait comme si tout ce qui se trouvait avant le chevron n’existe pas.
Prenons en exemple ce passage de ma feuille de style :
div#menus li.menu:hover > ul {
display: block;
position: absolute;
margin-left: 135px;
}Je vous laisse imaginer de quelle façon toutes les listes non ordonnées se barrent en sucette dans tous les sens.
Même principe, il ignore le sélecteur d’attribut et continue comme s’il n’existait pas. Encore un passage de ma feuille de style :
*[title] { border-bottom: 1px dotted black; }Résultat, tous les éléments de la page se voient affublés d’une bordure noire sur leur bord inférieur. Évidemment, ces problèmes se reproduisent pour d’autres parties de ma feuille de style où je pensais contrecarrer IE en douceur avec ces sélecteurs. Attention, ne vous méprenez pas sur mes intentions, je ne cherche pas à améliorer le design de la page sous ces navigateurs périmés (IE 6.0 compris), j’essaie juste d’améliorer la lisibilité du texte (parce qu’une liste dont le contenu dégueule sur le texte en dessous, c’est pas l’idéal).
J’ai réalisé quelques impressions d’écran pour les curieux parce que c’est quand même assez impressionnant, en particulier la troisième impression d’écran :)
Je viens de remarquer qu’en faisant div#foo>div#bar { ... } au lieu de faire div#foo > div#bar { ... } (que je trouvais plus clair pourtant…), IE n’interprète plus ce qu’il y a derrière le chevron, ouf…
Je suppose que vous connaissez ce principe : À toute action, il y a une réaction. Ce principe s’applique à la physique (oula, c’est loin dans mes souvenirs de cours) mais aussi à la vie réelle. On a tous pu suivre l’affaire de père-noël.fr et défense-consommateur.org. Et bien BOOM, retour à l’envoyeur.
Ahh, ce sont de petites choses comme ça dans la vie qui font toujours plaisir.
J’ai reçu ce matin un pourriel d’un genre
particulier en provenance de Vincent Gardet, webmestre de ceforweb.org,
où l’auteur annonce la mise en place d’une page de veille
recensant par voie de syndication
RSS les derniers articles de quelques blogs
plus ou moins connus de l’univers des standards, ce qui est une très bonne initiative.
Du fait de la grande jeunesse de mon journal, j’avoue avoir été agréablement surpris d’apprendre que
Webnaute faisait partie des blogs/journaux syndiqués, les résumés de mes articles se retrouvant au milieu de ceux
du Standblog, de Cybercodeur et d’autres bien connus. Je tâcherai donc d’être à la
hauteur :) (Heureusement, je crois constater que le système utilisé s’appuie sur la balise <dc:subject>
pour trier les articles selon les catégories, ce qui me permettrait de continuer à raconter mes conneries dans la
section Bric à brac).
P.S : Je m’interroge sur l’origine du nom de domaine "ceforweb.org", si l’auteur passe dans le coin :¬)
Vous ne l’avez peut être pas remarqué, mais j’ai ajouté ces jours-ci un nouveau champs texte dans le formulaire des
commentaires pour ajouter l’adresse de son site. Toujours en quète de pages les plus parfaites possibles, l’absence
de hreflang sur les liens vers les sites en question me chagrinait quelque peu. J’ai d’abord pensé
ajouter une liste déroulante pour indiquer la langue de son site mais je trouvais que ce n’était pas vraiment le
plus simple pour les utilisateurs du formulaire et il aurait fallu donner un choix conséquent de langues
sélectionnables, même si la plupart du temps, c’est anglais ou français.
Pour finir, je m’y suis pris autrement. Je lance à l’aide de la fonction fsockopen() de
PHP une requète à destination du site
indiqué dans le formulaire et je récupère la valeur donnée par l’en-tête Content-Language que me renvoie
le serveur. Dans le cas où cet en-tête n’est pas fourni par le serveur, je m’attaque au contenu même qui m’est renvoyé
en cherchant les attributs xml:lang et/ou lang sur les éléments
html ou body puis le meta Content-Language.
Encore une preuve des bienfaits des pages codées proprement et des bons en-têtes envoyés par le serveur :)
PS : Une copie de la fonction que j’ai faite est disponible ici pour les curieux.
Je viens d’effectuer une mise à jour assez importante.
D’autres améliorations et ajouts sont au programme et ne tarderont pas. Et ne vous inquiétez pas, j’ai aussi quelques sujets à traiter dans ma besace :)
Cela faisait déja plusieurs jours voire semaines que je butais sur un problème. Impossible d’envoyer mes pages encodées en UTF-8, cela faisait purement et simplement planter mon navigateur (Firebird, faut le faire quand même). Reprenant mes tests ce matin pour essayer de comprendre, j’ai constaté plusieurs choses au fur et à mesure :
À ce niveau là, je me disais que le problème venait des données même de la page et non pas des en-têtes HTTP envoyés par exemple. Et puis vient la lueur de lucidité, je retourne voir ma feuille de style principale pour finalement constater ceci :
div#menus li.menu > a:after { content: "\00A0»"; }Et le problème venait évidemment de là. J’insérais un caractère non encodé en UTF-8 (la feuille de style n’étant pas elle-même encodées en UTF-8) et cela a suffi pour faire planter Firebird. Il m’a suffi de remplacer le caractère » par son code ISO 10646 \00BB pour que tout refonctionne, ouf :)
Que se serait-il passé si j’utilisais non pas Firebird mais Mozilla et que mes pages étaient encodées en UTF-8 depuis le début ? Mes pages auraient été inaccessibles aux visiteurs utilisant Firebird, et ceux ci n’auraient pas pu me prévenir même s’ils en prenaient le temps puisqu’ils n’auraient pu obtenir mon adresse email. Au mieux, j’aurais été prévenu par des amis utilisant Firebird ou par des personnes parvenues ici par l’adresse du site donnée dans ma signature sur les newsgroups.
Cet exemple démontre que, malgré l’application stricte des normes en vigueur, il est nécessaire de tester ses pages sous différents navigateurs car il suffit de peu pour les rendre involontairement inaccessibles à une partie des visiteurs.
Jusqu’à maintenant, on connaissait les documents HTML contenant pèle-mèle des styles CSS et parfois une pincée de langage de script client (généralement Javascript). Ces langages s’intègrent de deux façons dans le document :
<style> et <script>, et en spécifiant comme il
se doit le type MIME
avec l’attribut type style et les attributs d’évènement onclick, onselect,
etc…
Auquel cas, il est nécessaire de préciser le type MIME au niveau global
avec Content-Style-Type et Content-Script-Type à l’aide de l’élément
meta et son attribut http-equiv La nouvelle norme du W3C est le XHTML 1.0, laquelle, dans sa forme strict, impose une séparation claire entre le document et les styles et scripts utilisés, ceci pour améliorer la lisibilité, la maintenance et l’évolution du code source. Pour la présentation, c’est simple, il suffit d’utiliser les styles CSS et dans l’idéal de les placer dans une feuille de style externe. Il en va autrement pour le javascript…
Lorsque les concepteurs de pages XHTML
intègrent du javascript à leurs pages, ils utilisent généralement les attributs d’évènements onclick,
onselect, etc… Or, il est nécessaire dans ce cas de spécifier le type
MIME du langage de script
utilisé. Le problème est que l’élément meta utilisé avec l’attribut http-equiv
n’est pas reconnu par les parseurs XML
(Vous aurez donc compris que je parle d’un vrai document XHTML, servi en tant que tel),
la note du W3C sur
le XHTML et les types de media est claire sur ce sujet :
Note that a meta http-equiv statement will not be recognized by
XML processors, and authors
SHOULD NOT include such a statement in an XHTML
document served as application/xml (and application/xhtml+xml as well for that matter).
Il reste donc deux solutions :
style, ça éviterait de semer des attributs d’évènements au sein du
document alors qu’ils n’ont rien à y faire (à mon avis).
Enfin, notez que "l’inutilité" des meta avec un attribut http-equiv s’applique quelque soit
l’en-tête, que ce soit Content-Type, Expires, etc… et aussi que tout logiquement,
l’attribut http-equiv sera purement et simplement
absent de XHTML 2.0.
PS : Tiens, ce billet m’a permis de constater que les attributs d’évènements dégagent aussi du XHTML 2.0. Mwaaahaaha… j’adore :-). Vive le W3C !
Les gens ont malheureusement tendance à oublier qu’une publication sur Internet, que ce soit un message posté sur un newsgroup ou un long document HTML devrait respecter quelques usages établis en terme de typographie. Les possibilités sont limitées pour un message en texte brut, comme sur les newsgroups, mais le sont beaucoup moins pour les documents HTML. Sans compter les autres usages typographiques comme les accents sur les majuscules, qui sont indépendants du type de document.
uZine vous explique tout et pourfend quelques croyances erronées au passage (l’article date un peu mais je suis sùr qu’il y en a parmi vous qui ne le connaissent pas).
Ah oui, bravo ! J’aime beaucoup ce pronostic :) Prions, mes frères…
Voilà encore un parfait exemple de ce que j’entend par une mauvaise gestion des URI d’un site. Le site Boomtchak.net, très connu dans la communauté PHP, ferme ses portes ces jours ci comme il avait été annoncé début novembre. Après une longue réflexion et quelques débats houleux, le gestionnaire du site (Davduf) a décidé de laisser accessible le contenu du site tout en gelant les fonctionnalités dites dynamiques. Ça, c’est une très bonne nouvelle et une marque de respect envers tous les webmestres/sites/personnes qui ont fait un lien vers telle ou telle page du site.
Un bémol toutefois, et c’est là que je voulais en venir. Toutes les URI sont de type dynamiques, dans le sens où :
Résultat : Impossible de mettre en place une version statique du site, sauf à faire la version statique puis mettre en place les redirections permanentes nécessaires pour chaque ancienne URL, bref, du boulot en perspective selon la taille du site.
Le site est donc condamné à fonctionner à l’aide de PHP pour les traitements et génération des pages et la base de données pour toutes les données du site (bien que, là encore, il y ait moyen de contourner l’utilisation inutile d’une base de données en rapatriant les données dans des fichiers et en modifiant de façon conséquente l’application qui effectue les traitements et affichage, mais bon…).
Alors qu’avec l’utilisation adéquat des systèmes de réécriture d’URL et de la négociation de contenu, tout ces tracas auraient pu être évités. Il aurait alors suffi d’écrire un script générant toutes les pages statiques, les mettre en place, dégager les fichiers PHP et la base de données et basta, tout marchait tout seul :)
Bon, ce billet n’est pas là pour critiquer la gestion de son site par le webmestre de Boomtchak.net, je voulais juste profiter de cet exemple pour rappeller (à nouveau ?) ma conception d’une bonne gestion des URI d’un site. Au passage, à quand donc un CMS disposant d’un système d’URI digne de ce nom ? (Vous inquiétez pas, pour l’appli de forums, c’est en cours ;-))