Aller au contenu

LaurentDenis

Membres
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    1 281

  • Inscrit(e) le

  • Dernière visite

 Type de contenu 

Tout ce qui a été posté par LaurentDenis

  1. LaurentDenis
    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é.
  2. LaurentDenis
    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...
  3. LaurentDenis
    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.
  4. LaurentDenis
    Il s'adresse surtout à combien de gens au profil imprévisible, maintenant, et demain, lorsque la cible, la technologie, etc. auront évolué ?
  5. LaurentDenis
    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. Oui. Si le designer ne rétrécit pas la cible (ce qui est le cas du bon designer). 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
  6. LaurentDenis
    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>
  7. LaurentDenis
    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...
  8. LaurentDenis
    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/ ).
  9. LaurentDenis
    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
  10. LaurentDenis
    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
  11. LaurentDenis
    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
  12. LaurentDenis
    Bouton CSS ?
  13. LaurentDenis
    <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
  14. LaurentDenis
    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.
  15. LaurentDenis
    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>
  16. LaurentDenis
    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
  17. LaurentDenis
    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
  18. LaurentDenis
    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...
  19. LaurentDenis
    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...
  20. LaurentDenis
    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... Heu... Peux-tu relire mon message, s'il-te-plaît ? Tu me fais dire exactement le contraire de ce que j'ai dit
  21. LaurentDenis
    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"> ?
  22. LaurentDenis
    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. 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.
  23. LaurentDenis
    Avant tout: Pas du tout fâché, bien sûr. Il ne manquerait plus que cela ! 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 ! ) 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 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. 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 qui va devenir de plus en plus concrète Oups, en effet. Oublie ça : je me suis mal exprimé (un peu pressé).
  24. LaurentDenis
    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... 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.
  25. LaurentDenis
    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 ?
×
×
  • Créer...