Aller au contenu

LaurentDenis

Membres
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    1 281

  • Inscrit(e) le

  • Dernière visite

Réputation sur la communauté

0 Neutre
  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>
×
×
  • Créer...