Dudu

Salut - Mettre un espace est nécessaire pour garder une compatibilité avec une vieille version de Netscape qui n'est plus utilisée par personne. Donc si tu as un site énorme et que tu veux économiser quelques précieux octets, fais-toi plaisir. Sinon mets un espace, ce sera toujours mieux pour l'instant (on sait jamais dès fois qu'un Netscape 4 passe dans les parages) - <div/> n'est pas valide et pour cause: <div></div> est valide mais non conforme. Le validateur (qui rappellons-le ne vérifie que la bonne imbrication des balises !!!) ne dit rien mais ce n'est pas correct. Et dommage pour les applications signées Google (qui s'en sort toujours aussi mal avec l'HTML). Dans la pratique, les navigateurs gèrent bien les balises vides de contenu, mais dans la théorie il suffit de relire les specs: c'est non conforme. - Aucun problème de validation pour les balises orphelines sans espace. Bien au contraire.

Salut Désolé de ne pas rentrer dans ce petit aparté RSS/XSL: l'apprentissage est encore est en cours. Mais donc pour le CSS anti-pub, c'est ici: UserContent.css. En revanche, savoir si çà marche dans IE 7 aucune idée. Je sais juste que çà marche dans tous les navigateurs depuis quelques années, sauf IE 6 (et antérieur). Mais tiens-nous au courant: ça donnera une idée du support de CSS 2/3 par IE 7.

Salut Le code que tu nous présente (celui avec les en-têtes PHP), où l'a tu mis ? Sur la page dans laquelle tu insères l'image en HTML avec la balise <img> ? Ou bien dans le fichier PHP qui génère l'image ? Car Explorer est TRÈS tatillon avec ces histoires de cache, et il tient toujours à nous refourguer ce qu'il a en mémoire: c'est un problème connu. Mais en sépcifiant no-cache un peu partout, tu devrais t'en sortir.

Au contraire Aucun risque d'avoir à encoder des caractères étrangers (type &xxx; ), il suffira de les écrire tout simplement et c'est le navigateur qui se tapera le sale boulot (décoder les caractères sur je-ne-sais-combien de bits).Quelques minuscules octets de gagnés, mais en tous cas aucun de trop. Amalgame L'UTF-8 est le langage d'XML. Donc en utilisant XHTML avec le type MIME d'XML (1% des cas à tout casser) on est forcé d'utiliser UTF-8. Sinon c'est libre choix. Sinon, les moteurs savent très bien se débrouiller avec les différents encodages existants. Ce qui est logique puisqu'ils font partie d'une norme définie.

Salut À te lire, la machine qu'il te faut est le MacBook Pro 17' Je m'explique. Le MacBook est le digne successeur de l'iBook. Donc une gamme moins professionnelle, plus axée grand public. Le MacBook Pro, quant à lui, est le successeur du PowerBook, donc gamme professionnelle. Une différence qu'on oublie souvent entre ces deux gammes est l'offre logicielle fournie avec. Évidemment tous les logiciels Apple 'de base' sont présents dans les deux (dont la fantastique suite d'utilitaires situés dans /Applications/Utilities). La gamme professionnelle se démarque avec certains logiciels Apple 'bonus' comme la suite iWork contenant Pages (successeur d'AppleWorks) et Keynote (sans comparaison avec PowerPoint) et quelques logiciels externes destinés à un usage pro. Ensuite, les MB n'ont pas vraiment un grand écran (13 pouces contre 14.2 sur les iBook); quant aux cartes graphiques elles peuvent tenir sur un usage photoshopesque mais elles ne sont pas réellement optimisées pour cet usage. Les MBP sont dispos en 15 et 17 pouces avec des cartes graphiques plus puissantes. Pour finir, le MBP 15 pouces est à mon sens un mauvais choix car trop cher en regard de ce qu'offre le 17 pouces pour quelques dollars de plus (comme aurait dit Sergio Leone ). D'autre part, 17 pouces c'est déjà beaucoup surtout en résolution élevée même si on peut avoir envie de temps à autre d'un écran externe pour plus de confort. Donc mon choix se porte sur le MPB 17. D'ailleurs, pour ne rien cacher il s'agit très vraisemblablement de mon prochain ordinateur en remplacement de mon iBook vieillissant et trop petit (petit en écran mais aussi en espace disque). Je t'avoue tout de même lorgner sur la série des iMac, notamment les 20 et 24 pouces, mais avoir un portable est vraiment un luxe dont il est difficile de se passer. PS: un conseil utile à l'attention des nouveaux venus sur Mac. Résistez à la tentation de commander un ordinateur boosté en RAM. Prenez la plus petite quantité de RAM et installez ensuite des barrettes achetées chez des fabricants spécialisés. En effet, Apple a baissé ses prix... et s'est nettement rattrapé sur les accessoires ! Tout ce qui est chargeur d'iPod, adaptateur batterie de portable, barrettes de RAM, et autres, se vend une petite fortune. Sachez-le ** edit: J'ai souvent plusieurs fenêtres de Safari ouvertes en permanence, plus Transmit (FTP), SubEthaEdit (éditeur de code) et un logiciel bien lourd qui tourne derrière (genre Photoshop ou InDesign pour ma graphiste préférée). Le tout sur mon iBook tout de même upgradé en RAM et çà roule. Donc pour répondre à ta question: oui sur un MB a 2 Go tu n'auras pas de souci

Les plus curieux qui auront été fouiller les moteurs de recherche pour savoir quel était ton hébergeur auront pu voir ton site Très sympa d'ailleurs. Et joli skin de PunBB qu'on jurerait être un IPB Bienvenue à bord Matthias !

Salut Infantilisante, ce n'est que ton avis.Brièvement, même s'il s'agissait d'un dangereux criminel, et que nous citions son nom publiquement, celui-ci a tout à fait le droit de faire jouer la diffamation, et c'est Dan qui serait visé. Avec peut-être même obligation de fermer boutique pendant quelque temps. Est-ce vraiment le but recherché ? Alors qu'il est si simple de le demander par MP (ou mail, ou messagerie instantanée, bref en privé). Donc si un membre cherche à prévenir la communauté des webmasters d'un abus quelconque, qu'il le fasse si vraiment il le juge nécessaire. Mais sans citer personne SVP

Salut NorSeb Oui c'est clairement dû à un problème d'en-tête serveurs, notamment celui relatif au type de contenu: c'est sûr à 99%. Est-ce réellement PHP qui est en cause, difficile à dire vu d'ici: on dirait qu'Orange utilise plusieurs langages pour la gestion de ses sites. As-tu regardé ce que dit le visualiseur d'en-têtes HTTP du Hub ? Je viens de regarder la réponse donnée pour la page d'accueil orange.fr/ et tout semble normal, mais il ne s'agit pas d'une URL de connexion à un compte. Si pour se connecter à un compte Orange, il faut passer par un cookie ou par Javascript ou un quelconque élément susceptible de bloquer le visualiseur du Hub, et que tu utilises Firefox tu peux regarder dans les informations de page (Pomme-I chez moi, donc certainement Ctrl-I sous Windows). En théorie, le type MIME est affiché. Tu peux aussi installer une formidable extension de Mozilla qui a été portée sur Firefox: LiveHTTPHeaders (un must-have !) Sinon utilise Safari: un de ses grands défauts est de vouloir à tout prix interpréter des balises HTML, même envoyées en mode texte (oui oui, parfois je critique Safari, ça m'arrive) A+

Salut La réponse courte: non, ce n'est pas possible. La réponse approfondie: Chaque navigateur a sa petite mécanique interne pour modifier les tailles de police. Et d'une. Ensuite, ces paramètres ne sont de toute façon pas accessibles via l'interface Javascript. Et de deux. De trois, certains navigateurs refusent de modifier du texte défini en pixel (Explorer) quand d'autres ne modifient que le texte mais pas les images (Firefox, Safari et tous les Gecko/KHTML) quand d'autres "zooment" toute la page, y compris les images (Opéra). De quoi créer un beau bazar à vouloir détecter qui a quoi, comment, et où. À mon avis, ta question repose sur un problème de conception de tes pages: au hasard un problème d'affichage quand les polices sont modifiées ? Je te conseille plutôt de régler ce problème à la source (par exemple en optant pour une mise en page fluide, mais tout dépend de tes pages) plutôt que de tenter de le corriger avec une béquille en Javascript.

Salut De manière très simple en important une liste d'adresses. Par exemple une liste au format texte dans laquelle les adresses sont séparées par un retour chariot, ou bien par un point-virgule... Je te conseille aussi de jeter un oeil à la documentation de WaNewsletter, qui est fort bien faite (c'est assez rare pour le souligner). Tu y trouveras réponse aux questions de ce genre.

Présentation longue pour mémoire courte ?Tu as déjà un message à ton actif si j'ai bonne mémoire Mais ceci étant, bienvenue tout de même

On me pique au vif ? Je viens de jeter un oeil, c'est vrai qu'il a l'air sympa. Cela étant, la qualité du code final est largement meilleure chez Vanilla quand on voit les gros tableaux vieillots et faciles de chez BBPress. Dommage, il a l'air de mériter qu'on s'y attarde... PS: ce que tu appelles "l'utilisateur bozo" existe sur d'autres forums

Salut Il est possible de faire une page valide non sémantique. Et possible de faire une page sémantique invalide. Je reste persuadé que la deuxième plaira plus à Google (ou autres moteurs) que la première. Dire qu'une page valide a plus de chances qu'une autre pour se positionner est une rumeur de village. Affirmer qu'une page bourrée de <div> jusqu'à la gueule est valide sous prétexte que le validateur l'a dit est aussi une absurdité: le validateur ne vérifie que la bonne imbrication des balises, point barre.

Salut Quand tu parles d'inclure le fichier virtual.php dans index.php tu parles de quel index.php ? Celui de Dotclear ou un autre (que tu auras créé toi-même en dehors du blog) ? En tous cas, il suffit d'appeler le fichier via la fonction PHP include() de la même manière dont les fichiers list.php et post.php sont appelés selon que l'affichage doive se faire en mode liste ou pas. Ensuite, tout dépend si virtual.php doit être affiché dans n'importe quelle circonstance (mode liste ou pas), tout dépend aussi quel gabarit de Dotclear tu souhaites réutiliser (idem: mode liste ou pas). En fait, Dotclear a deux gabarits: celui utilisé par list.php et celui utilisé par post.php Le fichier template.php ne sert finalement qu'à définir les éléments qui sont présents partout: c'est-à-dire le prologue, le doctype, l'en-tête, le menu de navigation (#sidebar), et le pied-de-page. Par exemple, si tes pages externes au blog sont vouées à ressembler uniquement à un billet, tu peux supprimer l'appel à list.php (et vice-versa). Si tes pages externes doivent ressembler aux deux gabarits et que virtual.php ne doit être que dans un des gabarits, alors il faut que tu places l'include de virtual.php dans un des deux fichiers list.php ou post.php ** J'oubliais de préciser: Une autre solution consiste à afficher dans ton navigateur une des pages de ton blog dont tu souhaites réutiliser le gabarit, en copier le code source, le coller dans un nouveau fichier texte et enregistrer le tout en php. Mais je ne recommande pas cette solution, car tu perds (entre autres) une des fonctions les plus géniales de Dotclear: la détection du navigateur en vue d'envoyer (ou non) le prologue XML et le type MIME application xhtml+xml.

Salut Un article sur la partie développeurs du site Apple me semble tout indiqué pour ta question: Plug-in Detection Effectivement, ce genre de détection ne peut se faire que par le biais de Javascript, avec les limitations que cela peut entraîner.

Salut OVH en mutualisé ? Si oui, tente de remplacer l'adresse de ton site par son chemin interne sur le serveur (ce que nos amis anglophones appellent le path ) Renseigne-toi aussi sur mod_ort si ce n'est pas déjà fait C'est une petite spécificité propre à OVH sur ses serveurs mutualisés (on en parle dans la partie francophone du forum de ModX)

Salut Si j'ai bien compris, tu souhaiterais écrire des pages qui auront la même mise en page et le même design que les pages de ton blog ? Très simple: ce n'est pas le fichier index.php sur lequel tu dois te baser, mais les fichiers de template. De mémoire, c'est dans le repertoire de ton thème. Là tu as trois fichiers qui vont t'intéresser: template.php, list.php, et post.php Le premier est le fichier générique. Le deuxième est celui utilisé par Dotclear pour afficher une liste de billets (comme par exemple pour une catégorie, ou pour un classement par date, ou encore pour la page d'accueil du blog). Le troisième est celui utilisé pour afficher un billet seul. C'est assez simple, je l'ai fait plein de fois: c'est enfantin. D'autant que le code de Dotclear est lisible et bien commenté. En cas de problème, reviens tout de même vers nous Bon courage.

Bonjour As-tu un pourcentage représentatif de l'affirmation que tu avances ? Je m'intéresse à ce genre d'études comportementales. Merci

Salut À noter un excellent article de Loupilo sur le blog d'Aozeo: Firebug, plus qu'une extension: un prodige ! Détaillé, avec des captures d'écran, et la mention du Firebug Lite pour les autres navigateurs. Un commentaire sur le blog de Sébastien nous rappelle tout de même dans le cas précis de Safari que ce type de fonctions existe déjà en standard grâce au Web Inspector et à Drosera. Plus d'excuse à ne pas travailler son optimisation de code !

Salut Avec un formulaire de spam report, tu n'auras pas de réponse par mail. De plus, il a souvent été dit qu'il faille plusieurs dizaines (voire centaines) de dénonciations sur un site pour observer une réaction de Google. Bien sûr, avec des IPs différentes, des navigateurs différents, avec des cookies différents... bref, ne spamme pas le formulaire de spam Bon courage.

Salut Je pense qu'il est encore meilleur de ne faire qu'une seule image et d'utiliser la technique des sprites dont slender parle dans le message n°7 de cette discussion. Pourquoi ? Quelle différence entre une image double et deux images simples ? Découpe une image de 100 Ko en deux parties égales et tu auras la réponse: les deux images créées feront plus de 50 Ko chacune. Donc au final un poids total supérieur aux 100 Ko de départ. Pourquoi ça ? Quasiment tous les logiciels d'imagerie gèrent les données EXIF. À chaque image créée on ajoute ces données EXIF: elles seront donc dupliquées (inutilement) si une image est découpée. Que plusieurs petites images soient plus rapides à charger qu'une seule grande est donc une fausse information, voire une rumeur de village. De plus, l'avantage d'utiliser cette technique des sprites est de n'avoir AUCUN "blanc" entre le statut survolé et le statut non-survolé de l'image. En plus, on n'utilise pour ça que la CSS, donc on se fiche de savoir si JS est activé ou non sur le navigateur du client. Résultat: un chargement optimisé et bien plus rapide, du CSS à 100%, et aucune saute d'image. La technique idéale Petit rappel des liens: Fast rollovers without preload [en/cz] CSS Sprites: Image Slicing’s Kiss of Death [en] article de Dave Shea, créateur du CSS Zen Garden Sprites CSS : Meurs, découpe d’images, meurs ! [fr] La traduction française de l'article de Dave Shea par Pompage Propriété CSS "background-postion" [fr] Propriété méconnue et pourtant si utile A+

Bonjour Dans la mesure où l'on doit s'inscrire pour avoir accès aux outils du Hub (ce qui est la moindre des choses), cela me semble normal. Il y a des gens qui discutent sur le forum et qui utilisent les outils mis à leur disposition. D'autres qui utilisent les outils sans avoir envie de participer (pourtant avec ce genre de sujets palpitants, ils ont vraiment tort de se priver ) C'est ainsi. Et tu verras le même ratio sur bon nombre de forums. PS: comme le fait remarquer petit-ourson, se présenter est facultatif. C'est un bonus afin de mieux se connaître dans la communauté.

Bonjour C'est une mauvaise chose, on ne le répétera jamais assez :!: Supprimer les tableaux pour tout remplacer par du <div> ne sert à rien. Ce qui est important en revanche c'est d'utiliser les balises qu'il faut au bon endroit: un <div> s'il faut un diviseur, une <table> s'il faut un tableau, un <h1> s'il faut un titre, un <p> s'il faut un paragraphe, etc... Dans le lien que tu donnes, TOUT (ou presque) est encapsulé dans des balises <div>, même les menus ! Idéalement: La bannière mériterait d'être un <h1>, dont l'image serait spécifiée en CSS (et pas un <div> contenant l'image directement dans le code HTML) Le menu mériterait d'être une liste <ul> dont les éléments seraient des <li> (et pas une avalanche de <div>) Les mots "Menu" et "Accueil" devraient être des <h2> (pas dans des <div> ...) Aucune balise, même <div> ne doit être vide de contenu (c'est à dire <div></div>) Toutes les images "décoratives" ou "présentatives" doivent être codées dans la feuille de style En fait, désolé mais tu n'as pas encore vraiment la bonne façon de travailler, et ton problème vient essentiellement de là. Évidemment, en partant sur de mauvaises bases HTML, tu n'obtiendras pas un CSS correct, ou très difficilement. À mon avis, tu gagnerais beaucoup à partir d'un code HTML propre. Soit en l'apprenant, soit en partant sur des gabarits tout-faits. Si tu souhaites apprendre, voici un excellent tutoriel. Profites-en pour regarder le code source de cette page, et le comparer au tien. Si tu souhaites partir de mises en page déjà faites, je te renvoie au lien donné ci-dessus par karnabal. Quoi qu'il en soit, nous sommes là en cas de problème. Et on va t'aider à faire ta mise en page de façon correcte, reviens nous dire ce qu'il en est

Si tu parles de la prochaine réunion du Hub, elle sera nordiste pour une fois !Mais on t'y attend tout de même Sois le bienvenu ici !

Salut Je te conseille la lecture de cet article Liste déroulante personnalisée sur le blog de TheRec, modérateur du Hub. La seule condition sinéquanone est l'activation de Javascript pour obtenir l'effet visuel. Toutefois, cette solution est parfaitement accessible sans Javascript... mais avec une apparence 'standard', donc. PS: on ne voit pas tes images dans ton précédent message. Visiblement elles sont liées depuis ton poste local