Xavier

C'est très joli, ça se dégrade bien sans Javascript et/ou sans CSS, juste le fait que le code est un peu alourdi par le CSS et le javascript qui feraient mieux d'être externes, mais franchement bravo

Les link rel peuvent aussi pointer sur la même page (je l'ai déjà vu, ça marche très bien, et nulle part le W3C ne dit l'inverse), bien que les rel officiellement autorisés ne soient effectivement pas spécialement conçus pour ça

Si tu as un IE qui traine sur ton ordi, refais le test avec !

<{POST_SNAPBACK}>

Dudu n'a pas windows

Il tourne sous Mac avec Safari si je ne me trompe pas. Donc il faut tout de suite oublier les détections de navigateur, il n'y aura jamais qu'un seul et unique navigateur (même si on en est passé très près) et toujours de l'hétérogénéité (heureusement !)

Pour Firefox qui recherche favicon.ico c'est à la base par mimétisme avec IE (qui recherche aussi favicon.ico à la racine, encore qu'il semble qu'il le fasse fort différemment...)

C'est intéressant, mais quand-même assez moyen...

Parmi les rel autorisés : x2:contentinfo (visiblement identique au "Index" officiel)

x2:secondary : presque "Section"...

x2:note : Appendix (environ)

x2:seealso : c'est presque alternate non ?

Au final je suis très septique : ils ont défini un profil comme indiqué par le W3C pour déclarer de nouveaux rels ?

Tu peux également "échapper" les caractères en unicode

 texte = document.createTextNode("\uXXXX");

où XXXX est le code unicode que tu peux normalement trouver ici si je ne me suis pas une fois de plus embrouillé les pinceaux

Plus compliqué pour toi, oui, mais nettement moins pour le visiteur, le client... c'est lui le roi non ?

Ce serait pas par hasard un

<link rel="Contents" href="..." title="Table des matières" />

avec le bon rel (contents) qui serait suivi ? Peu de sites utilisent ces balises (surtout que ni Firefox ni IE n'ont par défaut aucun moyen d'en tirer parti du moins par défaut)

Sur Blogzinet il y a

<a href="http://mozinet.free.fr/dico/index.html" class="b" rel="contents">Plan du site</a>

qui devrait fonctionner aussi même s'il n'est pas sur un link. Je n'arrive définitivement pas à retrouver un site qui utilise un <link rel="contents" />

Dudu, tu inclus tes liens dans les images maintenant ?

Sinon pour les stats, qu'est-ce qui te fait sourire?

<{POST_SNAPBACK}>

Il y avait très exactement

Navigateurs
1.	Mozilla Firefox 1.x	65.6 %
2.	Safari 1.x	31.2 %
3.	Internet Explorer 6.x	3.1 %

et

Systèmes d'exploitation
1.	Windows XP	65.6 %
2.	Mac OS	31.2 %
3.	Linux	3.1 %

Drôle de coïncidence non ? Exactement autant de IE que de Linux...

Maintenant ça a tout changé

C'est comme avec le clic droit, il y a des techniques laissant croire aux webmasters qu'ils peuvent déposséder leurs visiteurs de leurs droits les plus élémentaires comme le clic droit, le bouton de retour ou la barre d'état, mais en fait c'est du bidon, il y a toujours un moyen de contourner. Par exemple la technique du popup ne fonctionnera pas chez moi (eh oui, ils sont totalement désactivés).

Au final c'est toujours l'utilisateur final qui est floué et à moins que tu n'ait quelque chose d'exceptionnel à lui montrer il a toutes les chances d'aller voir ailleurs.

Dans le cas d'un QCM la multiplication des popups me paraît être une très mauvaise idée (sauf s'il n'y a qu'une question).

Non, le seul vrai moyen de bloquer le bouton précédent c'est... le flash (du coup on casse beaucoup d'autres choses, l'accessibilité, le clic droit, la copie, le redimentionnement, le confort, les préférences de police, et surement plein d'autres trucs encore)

C'est n'importe quoi, franchement à déconseiller au débutants

Une page "XHTML 1.1" même pas valide (et de loin pas) envoyée en text/html (par conséquent qui ne respecte pas les règles de compatibilité HTML pourtant obligatoires pour le text/html),avec des fautes d'orthographe (galerie ne prend qu'un "L" en français... c'est vraiment le genre de pages à éviter et à espérer que les débutants ne copient pas

edit: MOUHAHAHAHA, je n'avais pas vu qu'il s'en servait lui-même sur son propre site. Çà supprime le position:fixed sur Safari. Bravo, du grand art !

Bon, je m'en vais, je m'énerve tout seul, là...

<{POST_SNAPBACK}>

Pas étonnant, il introduite une valeur illégale pour "top" et pour "position". Par contre je ne sais jamais si "le navigateur doit l'ignorer" signifie qu'il doit revenir à la valeur par défaut de la propriété ou pas... cela dit il me semble tout de même que Safari ne devrait pas du tout en tenir compte (donc ce serait un bug qu'il faudrait reporter...)

Conclusion : pensez à IE 7 c'est garanti !

Tu peux également viser les stats "nedstat" des sites qui le proposent, il y en a pas mal et l'icône est bien identifiable. Le seul exemple qui me vient à l'esprit à cette heure tardive c'est http://mycroft.mozdev.org/ il y a l'icône "courbe rouge sur fond bleu" standard en bas à gauche de la colonne centrale et l'onglet "With what" (ou parfois en français "avec quoi" présente les stats.

Au passage sur la page http://www.upsdell.com/BrowserNews/stat_trends.htm sous le titre "Other Stats Sources" il y a pas mal de liens

D'accord, c'est ce que j'ai fait, un des visiteurs de mon site a dit que ça avait réglé le problème chez lui, je crois les doigts en espérant que c'est le cas aussi chez vous 

<{POST_SNAPBACK}>

Ça marche !

J'ai mis ça :

<meta http-equiv="Pragma" content="no-cache">

Ca ne suffit pas?

<{POST_SNAPBACK}>

Non, parce que le visiteur doit avoir rechargé la page pour que son navigateur voie qu'il ne doit pas la mettre en cache, ce qui est donc inutile vu qu'à ce moment il l'a déjà rechargée...

Je te conseille plutôt de ne pas y toucher. Considère que les navigateurs de tes visiteurs sont suffisemment bien réglés pour rafraîchir la page quand ils y reviennent (une fois par session par défaut). Tu économisera énormément de bande passante, et tes visiteurs du temps à ne pas charger la page, tout ça juste pour une fois... donc vire cette ligne et laisse le cache. La page n'est pas modifiée toutes les 5 minutes

PS : j'aime bien les stats de ton site

En effet, moi qui ait la police minimale fixée à 13px ça déborde sur une jolie longueur !

À mon avis il faut fixer la largeur de #text plutôt que de mettre des marges/paddings, parce que ça dépend de la résolution

Peut-être que si la page était valide ?

Et contenait un doctype autorisé ?

Ce n'est probablement pas ça non plus mais sait-on jamais

http://www.w3schools.com/browsers/browsers_stats.asp (site assez orienté techniques web)

http://www.upsdell.com/BrowserNews/index.htm (comparaisons intéressantes entre domaines, il faut absolument lire les commentaires sur les erreurs)

http://www.webhits.de/deutsch/index.shtml?...h/webstats.html (sites généralistes en allemagne)

http://www.xitimonitor.com/etudes/equipement6.asp (sites généralistes sur toute l'europe)

Un identifiant, pour être valide en XML, doit être unique, et respecter une construction de type « Name » : http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Name

Et là tu peux te lâcher, t'as toutes les lettres et les chiffres Unicode à ta disposition

<div id="ufÀLaCoque"> c'est valide

<{POST_SNAPBACK}>

Mais est-ce le cas également en XHTML ?

En HTML 4 on est limité

http://www.la-grange.net/w3c/html4.01/types.html#type-name"]les atomes ID et NAME doivent commencer par une lettre ([A-Za-z]), qui peut être suivie par un nombre quelconque de lettres, de chiffres ([0-9]), de caractères trait d'union « - », souligné « _ », deux-points « : » et points « . ».

La mention dans les différences XHTML/HTML ne me paraît pas très claire...

Pourquoi pas tout simplement éviter que les gens aient besoin d'agrandir le texte ?

Si tu respectes leurs préférences (= supprimer le font-size: 80% le texte sera directement à la bonne taille, donc les gens ne redimentionneront pas la page, et n'auront pas de chevauchement

Dans le sens que des gens qui s'intéressent au web (c'est le forum dédié à un navigateur, donc les modérateurs, ceux qui répondent en premier dans ce sujet, devraient quand-même en connaître un rayon) ne connaissent même pas l'existance du XHTML !

Au moins maintenant ils savent ce que c'est, même si je ne garantirais pas qu'ils ont compris que leur navigateur utilise le moteur d'IE qui ne le supporte pas...

CSS3 introduit de nouveaux sélecteurs.

#content a[href^="http://"]:after

Attention, certains navigateurs qui auraient compris le a:link:after pourraient ne plus comprendre ce sélecteur...

Tiens, tiens, c'est un truc auquel je n'ai jamais pensé ça, et que je n'ai d'ailleurs jamais remarqué sur aucun site Web... il y a des gens qui utilisent vraiment cette extension ?

<{POST_SNAPBACK}>

Très peu, très peu. Pour la simple raison que les pages ne seront pas lisibles par IE...

Elles ne sont pas facile à trouver, les moteurs de recherche les indexent très mal voire pas du tout (je ne connais guère que reacteur.com qui en soit capable)

On en trouve, par exemple, sur Mozilla.org, et en quelques autres endroits du web.

Pour ma part j'en ai quelques unes, ça permet principalement de faire se poser des questions aux gens (c'est français ça ? vous m'avez compris ) sur l'outil qu'ils utilisent.

<select style="width: 80px">

Sous FF, la liste est plus large que le width 80 px et chaque option est entièrement lisible.

Par contre, sous IE, les options font 80 px de large et donc, ne sont pas entièrement lisible...

J'aimerai obtenir sous IE la même chose que sous FF... comment puis-je faire ?

<{POST_SNAPBACK}>

Si tu veux que ce soit plus large que 80px pourquoi mets-tu 80px ?

Çà fait trèèèèèès longtemps que c'est le comportement par défaut de Netscape, çà

<{POST_SNAPBACK}>

Ah non, la beta ne le faisait pas ! Je pense que cette absence n'a pas du plaire à AOL...

Après Firefox... Netscape maintenant 

Bon... que chacun choisisse le navigateur qu'il veut... moi je ne vais pas revenir 5 ans en arrière pour savoir avec quoi les visiteurs vont naviguer sur les sites... ras le bol 

Si tu fait encore des détections de navigateur c'est que tu es 5 ans en arrière ! (ou peut-être seulement 2 ou 3...)

Tu n'as pas besoin de le savoir, tu as juste à faire un code respectant les standards, c'est tout !

C'est clair que si ton code est bourré de détections de navigateur et autres, tu es mal barré, mais ça te fera une bonne occasion pour supprimer ça

Le fais tu vraiment ? sûr ? sur quel navigateur ?

Parce que ce n'est pas possible nativement sur Firefox.

<{POST_SNAPBACK}>

Il y a une pref pour l'instant cachée mais qui ne le sera plus dans la prochaine version 1.1.

Dans about:config (ou ailleurs) trouver la propriété browser.tabs.showSingleWindowModePrefs et la passer à true.

Ensuite dans les options > avancé > Navigation par onglet tu as 3 nouvelles cases, dont une "Forcer les liens ouvrant de nouvelles fenêtres à s'ouvrir dans" et "le même onglet/fenêtre que le lien actif". En cochant ces deux cases, c'est le bonheur, plus de popup, même les window.open !

Je ne pourrais plus m'en passer

PS : si c'est une option cachée, il y a sans doute d'obscures raisons...

Bof bof bof, j'ai installé, pas génial...

• Moteur d'IE activé par défaut sur les sites sites "de confiance" (ex : netscape.com... mais où va-t-on ?)
  
• Spyware inside : voir le blog de Pascal Chevrel déjà pointé par Monique et bien regarder la capture d'écran; et puis la barre "weather" et l'autre "Real", c'est limite spyware aussi
  
• Il s'est associé automatiquement avec les fichiers .xpi
  

Résultat, en voyant ce dernier point il a immédiatement quitté mon disque dur ! Non mais ! Faut pas exagérer.

Moi qui avait l'intention d'essayer de convertir quelques extensions Firefox pour Netscape, AOL s'est tiré une balle dans le pied

Ça ne fait que me conforter sur l'incapacité d'AOL à faire les choses correctement. Ils ont coulé WinAMP, ICQ, Netscape, ils ont un client mail déplorable, eh bien au moins maintenant je suis sur qu'ils n'ont pas envie que Netscape refasse surface