LaurentDenis

Je veux bien mais ce site n'est même pas pour moi et la personne na vraiment pas envie de payer car ne peut se le permettre.

allez un ptit geste, moi je vous est suivie et je paye 45 € par ans mais il est vrais que j'aimerais aussi connaitre la maniere de faire sans les serveurs...

<{POST_SNAPBACK}>

On n'ira pas plus loin. Le propos du Hub n'est pas d'expliquer à tout prix des bricolages inefficaces et illusoires.

Une réponse claire a été apportée : une certaine qualité de support côté serveur est inspensable si on ambitionne une qualité donnée de service.

Ce sujet est fermé.

Après avoir modifié ta signature, limitée par les règles de ce forum à 3 liens (ce qui est déjà beaucoup sur le marché ), je suis heureux de te souhaiter la bienvenue...

que 80% des gens ont une bonne vision du contraste (je pense à ton site commmit)

<{POST_SNAPBACK}>

Disons clairement sur cet exemple:

- ont en effet une bonne perception des contrastes très faibles, quelque-soit leur mode de perception de la couleur (gris sur blanc cumule les handicaps).

- affichent les images et sont donc indifférents à des équivalents textuels dénués de sens... par exemple dans le contexte d'une indexation de ressource lorsqu'il s'agit d'images utilisées pour un menu.

- n'ont pas un écran de très petite taille (PDA, mobile) ou cherchent un concepteur pour un site exclusivement "screen desktop"... dont il faudra payer la rénovation dans quelques temps pour l'adapter à ce media.

- n'utilisent pas un navigateur du type IE tout en ayant besoin d'un affichage agrandi, ou n'ont pas besoin d'un concepteur pour un site dont l'accessibilité sera un des arguments marketing.

- n'ont pas de raison particulière de consulter le document sous forme imprimée un tant soit peu évoluée (c'est à dire ramenée au contenu esthétiquement et fonctionnellement pertinent sur ce media.

- n'éprouvent aucun intérêt pour le développement compatible avec les medias oraux (donc, les mobiles à nouveau, entre-autre).

- etc.

Tss tss c'est possible : http://www.browsercam.com/

Il s'adresse d'abord à des gens et combien d'hommes sont daltoniens, combiens de décideurs ont plus de 40 ans et une vision à la baisse, combien sont pressés et n'ont rien à faire d'une splash page...

<{POST_SNAPBACK}>

Il s'adresse surtout à combien de gens au profil imprévisible, maintenant, et demain, lorsque la cible, la technologie, etc. auront évolué ?

Soyons réaliste, il est impossible (et il le sera certainement toujours ainsi) de rendre lisible un contenu sur 100% des postes.

Personne n'a jamais dit le contraire.

En revanche, le % de postes où il sera accessible sera d'autant plus important que l'accès au contenu sera conditionné par une forme rigide.

Bien souvent le contenu d'un site s'adresse à un coeur de cible bien précis. Le travail du webdesigner consiste à capter l'attention de ce type de cible, à l'intéresser, à apporter une ambiance, à développer un concept lorsque cela s'avère nécessaire.

Oui. Si le designer ne rétrécit pas la cible (ce qui est le cas du bon designer).

s'assurer que le message soit transmis de la manière voulue, à la cible recherchée est important aussi (et certainement davantage en phase avec les réalités maketing exigée par notre métier  )

<{POST_SNAPBACK}>

Les réalités marketing du métier n'ont rien d'immuables, et sont justement en train de changer. C'est actuellement le bon moment pour s'en apercevoir

En attendant, j'essaie de faire du joli avec le peu qu'on me donne.

<{POST_SNAPBACK}>

Non. Tu restreins volontairement la palette d'outils à ta disposition, en voulant figer une forme, là où tu pourrais faire beaucoup mieux sans renoncer à tes ambitions esthétiques (ton propre site en donne un bon exemple, d'ailleurs).

Du moins est-ce que ce que diverses personnes ont tenté de t'expliquer ici

<edit>je supposais jusqu'ici une certaine part de provocation dans tes propos. Mais après avoir consulté commmint.com, j'ai le net sentiment d'une sincère incompréhension de ta part des problématiques évoquées par tes contradicteurs.</edit>

Ce sont des espaces de noms. Pour utiliser XML, il faut définir des "dialectes" spécifiques, adaptés à la tâche à accomplir. Chaque dialecte est un ensemble de balises définies dans un espace de nom qui lui est propre.

Par exemple, XHTML (qui est du XML) est défini dans son espace de nom, et celui-ci est indiqué par la ligne habituelle :

<html xmlns="http://www.w3.org/1999/xhtml">

En faisant appel à plusieurs espaces de noms dans le même document, on peut conjuguer plusieurs dialectes.

Si on prend RSS1.0 comme exemple :

- <rdf:RDF xmlns:rdf=&quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns=&quot;http://purl.org/rss/1.0/"> indique qu'il s'agit de RDF, dans l'espace de nom qui définit RSS1.0. Avec cela, on dispose du jeu de balises minimales pour faire un fichier RSS de ce format. On peut donc écrire son fil RSS avec ces balises :

<item rdf:about="...">
<title>...</title>
<link>...</link>
<description>...</description>
</item>
etc.

- Disons qu'on veut ajouter des informations sur l'auteur. RSS1.0 n'offre pas le balisage nécessaire. On fait appel à un autre dialecte, compatible, qui constitue le module "Dublin Core", et qui a son espace de nom spécifique (dc). On fait donc référence à cet espace de nom pour qu'il soit exploitable dans le fichier (troisième ligne ci-dessous):

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://purl.org/rss/1.0/"
 xmlns:dc="http://purl.org/dc/elements/1.1/">

On peut à présent utiliser les balises existant dans cet espace de nom dc :

<dc:creator>...</dc:creator>
<dc:date>...</dc:date>
<dc:subject>...</dc:subject>

Cette modularité du RSS1.0, basée sur l'utilisation de RDF et des espaces de noms, en fait un outil particulièrement puissant, puisqu'il est possible de l'étendre selon ses besoins...

J'avoue que je vois mal ce que tu veux dire ?

S'agit-il du choix du format RSS ? RSS2.0, RSS1.0, RSS0.91, Atom ... ?

Dans ce cas, tu trouveras une bonne base de départ dans les articles RSS d'OpenWeb ( http://openweb.eu.org/rss/ ).

Mon site est spammé par un **** utilisant windows server 2003, et je souhaite bloquer son acces à tous les utilisateur windows 2003.

D'un côté, je te comprends. D'un autre... C'est un petit peu brutal, non ?

Tu dois pouvoir agir uniquement au niveau du module de trackbacks. ça limiterait déjà pas mal les dégâts colatéraux

Il ne s'agit pas d'espace de nom (xmlns) mais de type de contenu.

Le type de contenu est l'une des métadonnées clé du Web. Il indique la nature d'une ressource, et fournit l'information permettant au client de déterminer comment elle doit être traitée.

Par exemple, text/html indique un contenu HTML dont le balisage doit donc être interprété. Si tu applique un type text/plain à une page HTML... le navigateur affiche le code sans l'interpréter

Autre exemple : le type de contenu application/xhtml+xml fait toute la différence de traitement par les navigateurs entre un document (X)HTML et un "vrai" document XHTML...

La plupart des gens ne se préoccupent pas des types de contenu, parce que leur serveur est configuré pour associer les types requis aux différentes ressources (pages web, images, icônes, etc). Mais il arrive fréquemment que cette configuration soit insuffisante, ou incorrecte. Elle s'appuie le plus souvent sur les extensions de fichier : ton fil rss ayant une extension php... c'était logiquement un document HTML au yeux du serveur. Mais une extension .rss aurait sans doute donné... du text/plain faute de l'association idoine dans le paramétrage de ton serveur.

Bref, les type de contenus sont indispensables, mais mal employés le plus souvent. D'où problème pour les agents utilisateurs qui doivent décider entre deux maux :

- recourir à des mécanismes de "devinette" et de correction du type de contenu, souvent basées sur les extensions de fichier... avec des résultats plus ou moins heureux, des risques côté sécurité, et un bel effet pervers : les auteurs sont encouragés à ne pas s'occuper de fournir les bons types de contenu.

- ou bien être strict sur le types de contenu... au risque de ne pouvoir traiter les ressources incorrectement adressées.

Dans le genre strict :

- une feuille de style qui n'a pas le type text/css sera ignorée par Firefox

- une favicon qui n'a pas le type mime image/... sera ignorée dans certains cas par Opera

- un fil RSS n'ayant pas un des types idoines ne sera pas lu par certains clients RSS

C'est pourquoi il faut veiller à toujours indiquer le type de contenu exact

Deux modifications à apporter :

- corriger le type mime et l'encodage indiqués par le serveur, en ajoutant en début de fichier rss.php :

header('Content-Type: application/xml; charset=iso-8859-1');

- corriger les dates en ramplaçant GTMT+1 par +0100

Renseigne toi sur la façon dont les medias ont évolué dans le temps (et pas ton journal TV préféré) et tu te rendras compte que c'est bien la rue, l'utilisateur, le citoyen qui a décidé de la façon dont il voulait percevoir l'information.

<{POST_SNAPBACK}>

<antitroll>

Désamorçons, voulez-vous ?

La télé n'est effectivement pas un exemple pertinent ici, dans la mesure où:

- effectivement, son contenu figé a évolué en réponse aux réactions supposées des téléspectateurs

- mais la seul action que je peux avoir en tant qu'utilisateur de la télé, sur son contenu, c'est d'aller faire pipi pendant les pubs.

</antitroll>

On gagnerais du temps, AMHA, en modifiant la question de départ en Pourquoi faites-vous du Flash ?

Il y a en effet ici des gens qui l'utilisent, l'aiment, ne l'aiment pas, partiellement, totalement, d'une manière, d'une autre... avec des objectifs de base totalement différents

Maintenant par contre si ton outil est mis à jour pour gérer nativement les nofollow sur sa prochaine version ET que les noms des champs ou l'interface pour poster un commentaire/trackback change ... il faudra au spammeur mettre son outil à jour, ce qu'il ne fera pas puisqu'il n'a aucune utilité de perdre du temps à spammer des sites insensibles.

<{POST_SNAPBACK}>

Ce n'est valable que pour les solutions de blogs qui peuvent, de manière centralisée, modifier leur code pour tous les utilisateurs.

Pour les gens qui utilisent DotClear, par exemple, même si cette modif était incluse dans la récente version "nofollow" du CMS, il resterait une marge de sites non mis à jour à spammer.

Enfin, cela ne fera que déplacer l'effort des spammeurs d'un endroit à un autre.

La réponse au spam n'est pas vraiment technique, aussi regrettable que ce soit. Elle est juridique.

Là, c'est quelqu'un qui te fait un gag, alors. Ou effectivement un spammeur amateur. Agaçant, mais pas vraiment grave : la rançon de la célébrité

<edit>

Le nofollow ne vise pas vraiment le spam amateur

</edit>

Et ce n'était pas le cas avant ?? 

Je ne comprend pas ce que ça change.

<{POST_SNAPBACK}>

Je suis un spammeur (enfin, façon de parler, hein). je vends mes services. Mes concurrents aussi.

Conséquence 1 : mon but n'est pas de positionner mes liens dans l'absolu. C'est juste de les positionner mieux que mes concurrents.

Conséquence 2: Je sais déjà qu'un très gros X% de mes spams sont inefficaces. Je m'en fous. Je ne vise que le petit pourcentage qui reste, avec pour but d'en avoir un plus gros que mes concurrents.

Là, Google restreint l'efficacité de mes spam avec le nofollow.

ça m'incite à quoi ? A spammer plus, pour accroître ce petit pourcentage marginal de spam efficace qui fait mon business...

Tout ça, finalement, c'est bel et bien une histoire de Viagra

Si cela peut te consoler, tu n'es pas le seul : mon appli RSS s'est brusquement affolée ce matin avec une masse exceptionnelle de nouveaux items dans les fils "commentaires et trackbacks" des blogs... Items passionnants consacrés à divers casinos en ligne, produits miracles pour les messieurs aux petits pieds, etc.

Tiens... mon blog a été épargné : c'est bien, d'être confidentiel

Coïncidence ? Sans doute. Mais on ne peut s'empêcher de penser à cette argumentation selon laquelle, le bénéfice recherché du spam étant marginal et non absolu, ce type de mesure peut inciter les spammeurs industriels à rivaliser davantage pour accroître leur marge, en intensifiant leurs efforts...

Allez on se fait tous les trois un bisou et on reste bon amis 

<{POST_SNAPBACK}>

Ah... S'il existait une police de caractère Zen pour mettre de l'huile dans les rouages !

PS: Faudra tout de même qu'on discute de typographie, un de ces jours. La question de la pertinence des règles typo de l'imprimé sur le web est passionnante...

Je vais parler un peu cruement, mais tu n'as pas l'impression de prendre les gens pour des cons ? 

Ma mère est très très loin d'etre douée en informatique mais sait quand même utiliser le crtl+molette pour lire plus confortablement.

Inutile d'employer des noms d'oiseaux. Il n'y a dans mes propos aucun postulat désobligeant pour la maman de qui que ce soit

Simplement une constat d'expérience, fait en tant qu'enseignant et formateur, sur un éventail très large d'utilisateurs novices...

Partir du postulat que tes lecteurs sont trop idiots pour utiliser leur navigateur et que donc c'est normal de leur bloquer l'accès au contenu est contraire même à l'objectif premier : diffuser de l'information.

<{POST_SNAPBACK}>

Heu... Peux-tu relire mon message, s'il-te-plaît ? Tu me fais dire exactement le contraire de ce que j'ai dit

PS: Pour le français, utilises la balise:

<meta http-equiv="content-language" content="french">

<{POST_SNAPBACK}>

J'aurais besoin de votre expertise '"googliste", là, si toutefois les réponses sont connues

- AdSense requiert-il ce format précis french pour l'indication de langue, ou tient-il compte de l'indication donnée dans le format normal content="fr" ?

- AdSense tient-il compte d'un "vrai" en-tête HTTP Content-Language ?

- AdSense exploite-il le <html lang="fr"> ?

Je reviens sur la question car j'ai de plus en plus l'impression que l'introduction du rel="nofollow" est très liée à certains dysfonctionnements constatés actuellement sur Google...

Il sera en tous cas intéressant de voir quels développements éventuels Google donnera au "nofollow" dans les mois qui viennent. Ou s'il lance une autre initiative du même ordre pour compléter celui-ci.

Que Google souhaite inventer des balises propriétaires, je n'y vois pas d'inconvénient. On en avait déjà l'habitude depuis la balise <meta name="Googlebot">

En fait, d'un point de vue standards, les meta name="Googlebot" sont parfaitement conformes et n'ont rien de propriétaire.

Mis à part les règles syntaxiques usuelles, le contenu des attributs name et content de <meta> n'est pas figé, et peut être étendu à volonté pour répondre à tel ou tel besoin spécifique.

Par exemple, le système de localisation GeoUrl (recensement géographique des sites Web) utilise une telle meta pour l'indication de la latitude et de la longitude:

<meta name="icbm" content="46.7229, 3.6848" />

Une précision optionnelle peut être apportée par un lien vers un scheme, comme dans l'ancienne syntaxe recommandée pour le Dublin Core:

<link rel="schema.DC" href="http://purl.org/DC/elements/1.0/" />

Mais l'absence de ce scheme ou d'un profile n'est pas invalidante, ni problématique dans le cas d'une <meta name="brocoli"> destinée à l'usage exclusif du robot brocoli... Contrairement à l'attribut rel, qui n'est pas destiné à l'usage d'un robot unique.

Avant tout:

ça va on est pas faché ? 

Pas du tout fâché, bien sûr. Il ne manquerait plus que cela !

Tu ne m'enlèveras pas de l'idée que ces polices écran ont tout d'abord été créées pour des interfaces graphiques, bien avant l'existence des navigateurs

Tout le problème est de savoir ce qui reste pertinent, lorsqu'il s'agit de le transférer sur le Web, ce qui change, ce qui est utile, ce qui est possible, ce qui est problématique...

(Problème classique, rencontré par exemple avec les règles typographiques de l'imprimé... Mais bon, un troll à la fois, passons ! )

A ce titre, il me semble plus judicieux de "fixer" les tailles de polices qui sont sensées tenir la route dans un contexte d'affichage standard, meme si celà va à l'encontre de la nature flexible d'un contenu HTML.

N'y a-t-il pas une contradiction entre le contexte d'affichage standard et la nature flexible du Web ? Ce qui ne veux pas dire que j'exclue l'idée d'un contexte d'affichage hypothétique, souhaité, mais non contraignant.

Le principe premier de la communication (absolue celle-là  ) est de fournir un contenu formaté à destination d'une cible bien précise. Dans cette optique, la production d'un graphiste "fixe" effectivement un certain nombre de critères pertinents.

Le Web introduit quelque-chose de très nouveau à cet égard. Sur le Web, l'utilisateur cible est beaucoup moins soumis aux contraintes du media.

Attendre de l'utilisateur qu'il s'adapte à un contenu et à sa présentation ? C'était sans doute tout à fait cohérent dans le contexte des années 90 et de l'optimisé pour un navigateur. Mais on va justement aujourd'hui dans le sens opposé.

- L'utilisateur diversifie ses moyens d'accès (le formatage esthétique du contenu n'a plus guère de sens en RSS). le contenu lui-même diversifie ses canaux de diffusion (là encore, RSS, avec l'agrégation de contenu). Jusqu'aux moteurs de recherche, à l'ésthétique supposée si stratégique, qui s'y mettent : que m'importe le graphisme de la page de MSN Search... que j'utilise sous forme de flux RSS ?

- L'utilisateur reprend le contrôle de la page HTML affichée (filtrage de contenu publicitaire, par exemple, ou plus généralement du contenu graphique) et de sa navigation (onglets, maîtrise des ouvertures de liens en nouvelle fenêtre).

L'utilisateur va se réapproprier, timidement, le contenu Web. Biens-ûr, il lui manque encore beaucoup des outils nécessaires, notamment pour intervenir sur l'esthétique de celui-ci. Redimensionner une police de caractère relève déjà d'une connaissance avancée du fonctionnement de son propre navigateur, que tous les utilisateurs sont loin d'avoir. Ne parlons pas de choisir son degré de contraste de couleur, ses substitutions de polices : bien que la technique soit là, elle manque encore d'interfaces qui la rende accessible.

(Au passage, un exemple : j'ai une sainte horreur des polices sérifs sur des textes longs à l'écran, trop fatiguantes à lire. J'apprécie peu les liens soulignés réglementairement, faute d'un espace suffisant entre le soulignement et le texte... Il y a belle lurette que mon navigateur corrige tout cela sur toutes les pages que je consulte).

Mais certaines évolutions des navigateurs indiquent bien que ces processus d'adaptation de la présentation se développent : le système ERA d'Opera, par exemple, destiné à adapter les largeurs fixées à celle de la fenêtre du navigateur, ainsi que les contrastes de couleurs, voire le contenu lui-même.

Voilà pourquoi je lutte pour un webdesign qui exploite la forme des standard dans ce qu'ils ont de plus beau, et non pas de plus efficace. Laisser le soin à l'utilisateur de choisir l'aspect d'un texte est une possibilité, mais pas une priorité au regard d'une forme qu'on a voulue esthétique au départ...

Et pourquoi pas apprendre à faire beau avec une forme souple et que l'on sait mouvante ? Au prix d'une révolution culturelle, certes. Nous nous y rencontrerions sans doute

Question d'école et débat intéressant !

Question qui va devenir de plus en plus concrète

 

32 pixels en 72 dpi = 32 pixels en 96 ou 300 dpi. Le nombre de pixel est le même, l'aspect est donc similaire dans le cas ou un caractère construit sur une grille 32 mais je crois qu'on doit pas parler de la même chose... 

Oups, en effet. Oublie ça : je me suis mal exprimé (un peu pressé).

Tiens, un détail qui a son importance : la "verdana 11" du Hub est en fait du 12px pour le corps de texte des messages, pas du 9-10 ou 11. Un petit pixel... Cette différence n'est pas négligeable du tout, selon la résolution d'écran et la configuration d'affichage...

LaurentDenis > ce que tu critiques comme police en terme de taille est justement ce qui est le plus approuvé par les designer. Trop petit peut être selon le contexte, précis et esthétique surement (et je ne parle que taille en PIXEL visible à l'écran, hors de toute considération CSS)

Je n'en veux pas à Verdana, Commmint Pas du tout. C'est une police tout à fait sympahique, je suis bien d'accord.

Mais c'est à cette démarche tentant de figer le document dans des dimensions illusoires, que j'en ai ici. Férocement, même. J'en ai contre les designers et leur illusion de l'affichage-chez-moi qui serait le même chez mes visiteurs

Les rares zones de texte du Hub qui sont en 10px seraient illisibles pour moi, si je ne lui appliquaient pas une CSS user me permettant de rétablir des tailles agréables. Ne parlons pas du 9px, qui ne passera de toute façon pas le réglage de taille minimale de police dans mon navigateur...

D'autant plus que oui, les pixels sont une unité relative: non pas relative à la configuration du navigateur, contrairement aux em et %, mais relative à la résolution d'écran. Ce qui a sans doute créé l'illusion d'une unité absolue, c'est le bug d'IE empêchant le redimensionnement des textes de taille fixée en pixels. Mais un pixel ne joue pas le même rôle qu'un pouce : le nombre de pixels dans un pouce d'écran est variable selon les utilisateurs. Que l'on prenne en compte les CSS ou non n'y change rien

Le rendu dépend du matériel, de la configuration, des paramètres et des préférences utilisateurs, des polices présentes ou non, de l'application utilisée, des adaptations liés à l'accessibilité. N'oublions pas non plus que bien peu d'écrans sont calibrés comme le sont ceux des graphistes...

Alors, à quoi bon fixer agressivement des règles comme "Verdana, ça se fait en 9-10-11px" ou "Arial,en 11 uniquement" ?

Quitte à proposer une règle, je juge beaucoup plus réaliste celle consistant à dire : la taille de base par défaut du texte est de 1em, c'est à dire celle fixée par l'utilisateur. Voire légèrement en dessous (0.9, 0.85em), ce qui est risqué, ou légèrement au-dessus, ce qui est plutôt rare dans la pratique.

Hum... testé avec l'identification de mon navigateur favori ("Space Bison/0.02 [fu] (Win67; X; SK)" , ça passe sans problème...

Non, bon, sérieusement : problème réglé, en effet

<edit>

Par curiosité : le problème venait de nuke sentinel ?