Ganf

Ca ne le fait pas avec un firefox récent. Netscape 6.x est vraiment une horreur, ça vient peut être de lui. Pas grand monde ne l'utilise de toutes façons. tu ferais mieux de regarder avec firefox ou mozilla dans leurs dernières versions. Le moteur est le même mais ila beaucoup évolué depuis.

Du point de vue de tes scripts PHP et du navigateur c'est totalement transparent. Ce qui est crypté c'est uniquement la transmission entre apache et le navigateur. Apache fera le décodage avant et après PHP, tu n'as donc pas besoin de t'en préoccuper.

> Au passage, le livre on le trouve que chez Eyrolles .. ou on peut le trouver dans n'importe quelle librairie ? N'importe laquelle qui a des livres informatiques, théoriquement je pense que oui. On m'a signalé une présence chez Virgin, il est aussi présent à la FNAC (vérification faite à Lyon et sur leur site Web). Par contre des fois il faut chercher un peu (je ne sais pas pourquoi mais à Lyon il n'était pas avec les autres). Si ce n'est pas le cas c'est comme tous les bouquins, il faut demander à la vendeuse de le commander, en n'oubliant pas de lui dire d'en commander quelques exemplaires en plus pour le rayon

C'est possible, il n'y a rien à faire à part faire un deuxième <link> similaire au premier, avec une autre adresse dedans. Ça ralentira simplement d'un appel de document (vu qu'il aura un fichier à aller chercher en plus). Si tu penses que c'est nécessaire lances toi.

Un peu trop au mien aussi Disons qu'on est deux auteurs et qu'il a fallu faire des concessions des deux cotés. Maintenant bien que presque tout soit expliqué de la base, je crois que ça contentera même ceux qui connaissent presque tout. Le chapitre 20 mis en exemple est justement là pour introduire le traitement "simple" de XML. SimpleXML est une nouveauté, nous nous devions d'y faire attention. Parti de là nous avons choisi d'expliquer la base de XML (un peu vite) tout de même. Le terme avancé peut paraitre trompeur mais il qualifie plus le type de cible (programmeur, personne qui connait déjà le Web) que le niveau de PHP exactement. On peut avoir fait des choses de folie en PHP en Web et en prog sans pour autant avoir joué avec XML. Si on ne part pas des explications de base finalement ça sera inutile à beaucoup de monde. Il ne faut pas oublier que le livre est gros, on a la place de mettre les base ET le reste (la preuve, on a même choisi de faire deux chapitres sur le XML pour pouvoir tout mettre). Rédiger est une activité complexe de ce coté là. Des fois on a du être pragmatiques. Maintenant c'est loin d'être un livre de débutant. Même partant des bases, quelqu'un qui n'a pas l'habitude de la prog risque d'aborder avec difficulté les deux chapitres sur XML. (on a eu pas mal de relecteurs, ça donne une bonne idée des impressions de lecteurs). Grr, je savais qu'on aurait du mettre un chapitre plus technique, malheureusement avec le 20 tu tombes sur la moitié "simple" d'un sujet. La moitié plus "avancée" est dans le suivant. J'espere que si, parce que pour moi ça voudrait dire que j'ai complètement loupé ce que je voulais. Pas que la doc soit mauvaise (au contraire), mais je pense que les deux ne doivent pas faire la même chose. Les sujets abordés sont les mêmes, par contre je pense que le contenu est bien différent. (je persiste pour un sujet séparé par contre, si vous êtes ok je le lance, à moins qu'un admin sache couper ce fil au bon endroit pour en faire un nouveau) [edit : merci à Anonymus d'avoir déplacé la discution]

Attention, de ce coté le bouquin que j'ai écrit n'est pas là pour décrire toutes les fonctions une à une. Pour ça je trouve que la doc est très bien (d'autant que celle de PHP est bien foutue). On fait une référence par thème, mais le but n'est pas de faire une documentation. Je pense que ce que peut apporter un bouquin est un peut différent : des retour d'expérience, des explications qui vont un peu plus loin que la simple fonctions, des cas d'applications, des mises en contextes. Si ce que vous cherchez c'est une doc à mon avis la doc officielle est assez bien faite pour ne pas avoir besoin de plus. Éventuellement, si vous insistez, le O'Reilly et le Campus Press reprennent le principe de doc (mais pour PHP4). Je crois qu'il faut de toutes façons bien savoir ce que vous attendez d'un bouquin avant de l'acheter, et comment vous comptez l'utiliser par la suite. Ce genre de questions sont probablement bien plus importantes que le sommaire. C'est avec plaisir, n'hésitez pas. (mais si on continue trop sur ce sujet il sera peut être aussi bien de faire un fil séparer pour ne pas pourrir celui ci)

Bonjour, Je crois que je vais conseiller le même que les autres : le livre PHP 5 avancé, chez Eyrolles. Maintenant je ne suis pas très objectif, et pour faire moins publicitaire je peux te dire que le seul autre qui vaille le coup (à l'heure ou j'écris) semble(*) être le cahier du programmeur dédié à PHP 5, de Stéphane Mariel (toujours chez Eyrolles). Grosso modo il faut éviter tous les autres. La plupart sont soit des bouquins PHP4 auxquels on a changé le n° sur la couv, soit des bouquins se basant sur des vieilles versions de dev qui ne ressemblent pas au PHP5 actuel (Atkinson s'est par exemple méchament planté en sortant son bouquin trop tot). Après c'est à toi de savoir ce que tu recherches dans un bouquin. PHP 5 avancé est orienté référence : le but est d'en décrire le plus possible, de traiter de tous les sujets principaux, en détail. Tu as au final un gros bouquin (et encore, on a du élaguer) avec des petits exemples sur chaque domaine. Le cahier du programmeur est plus orienté pratique, la démarche de stéphane semble être d'au contraire faire un exemple d'application entièrement et aborder les différents sujets quand ils se présentes (au lieu d'aborder un sujet et de faire à chaque fois un petit exemple). Il en résulte un livre plus court et plus centré sur un sujet précis (dans son cas c'est PHP5 et la POO) Concernant celui que j'ai fait avec Cyril vous avez le sommaire et deux chapitres en PDF gratuits sur le site de l'éditeur, pour vous faire une idée. (*) je marque "semble" car je ne l'ai pas eu entre les mains. Ceci dit pour avoir discuté avec l'auteur et avec les retours que j'ai eu, j'ai peu de chances de me tromper.

Pour ça on a déjà le <object>. Il suffit de mettre l'image en lien et le contenu alternatif à l'intérieur. Les possibilités existent, ce qui manque c'est le support. Et c'est là (et uniquement là) que je rejoins les septiques : en 10 ans ou presque nous ne sommes pas arrivés à faire marcher un HTML pourtant relativement simple. On ne peut pas l"utiliser entièrement et on se contraint à des contorsion pour palier les déficiences de tel ou tel client HTML (et les clients pour les personnes avec difficultés sont probablement ceux qui supportent le moins de choses alors que ce sont eux qui en ont le plus besoin). Comment vas t'on faire pour XHTML 2 ? est-ce faisable ? J'espere que oui, en tout cas je pense que ça vaut le coup d'essayer, mais c'est loin d'être simple.

Il y a beaucoup de débats sur beaucoup de choses. Grosso modo ce que tu as cité ce sont les choses où tout le monde est d'accord. Il y a la question de l'élément <line>, donc l'usage est assez rare pour remettre en question la balise. (Personnellement je pense que si on en est à forcer des <line> c'est qu'on devrait être dans un <pre>, je ne vois pas vraiment d'autres cas) Ce qui fait surtout peur à tout le monde c'est que XHTML 2 aille trop loin et qu'on se retrouve encore avec des spec qui ne seront pas implémentées correctement avant l'an 3000. Rajouté à ça le fait que XHTML 2 ne cadre pas avec les besoins exprimés de beaucoup de producteurs (ils cherchent plus un format pour coder des applications graphiques via Web qu'un format de description de contenu, il faut l'avouer) ... le risque de voir tout ça dérapper est grand. Moi j'attend beaucoup de XHTML 2 parce que ça peut permettre de remettre beaucoup de choses à plat.

Le <p> ne peut contenir que des balises de type inline. <script> est une balise de type bloc. Comme le </p> est optionnel en HTML, on considère donc qu'il y en a un juste avant le <script> et que tu l'as simplement omis. Par contre du coup le </p> après le </script> se retrouve seul, il n'a pas d'équivalent <p> (qui lui est obligatoire), d'où l'erreur.

> Bref, y'a t-il une solution !? Fermer ton <div> au lieu d'en ouvrir un deuxième.

Sauf erreur de ma part du as un caption { font: 14px; } qui devrait être plutot un caption { font-size: 14px ; }

Ce que tu cherches est probablement is_numeric()

> Dans les deux cas, j'ai une 20aine de requêtes à effectuer et ça me semble tout de > même un peu pompeux en ressources... Des solutions ou tous les système ayant une > arborescence pompe les ressources d'un serveur ???? Tous les systèmes hiérarchiques codés avec une base relationnelle posent problèmes. Tu mélanges deux concepts totalement opposés. Maintenant tu as quelques solutions. Il y a des cas d'école avec des jolis algos qui permettent de numéroter les entrées et récupérer toute une arborescence en une ou deux requête. Globalement ça reste complexe à gérer et/ou casse couille. Le plus simple est encore d'attribuer un identifiant à chaque catégorie et de rajouter un champ "chemin" à chaque entrée. Le chemin retrace toutes les catégories pères. ex : id - nom - chemin 1 - informatique - 1 2 - littérature - 2 3 - systèmes d'exploitation - 1/3 4 - programmation - 1/4 5 - linux - 1/3/5 Avec des tris sur le champ "chemin" tu pourras faire facilement des recherches sur les sous catégories, les catégories pères, les catégories filles .... Ce n'est clairement pas le plus efficace mais c'est probablement le plus simple.

Bonne question tiens. Je n'en suis pas sûr et j'en entendu les deux écoles. Pour : - c'est effectivement l'équivalent textuel Contre : - normalement le <li> suffit à repérer une liste et l'étoile risque de faire double emploi (surtout qu'à l'oral ça risque de ne pas être parfait) Mais de toutes façons ... une image de liste ne devrait-elle pas être en CSS ? Gaffe, le W3C conseille aussi des trucs idiots, et même des trucs négatifs (qu'il vaut mieux ne pas faire). Les WAI sont en train d'être réécrite, si tu veux te baser dessus regardes plutot les drafts de la 2.0 (bon, maintenant peut être que ce point précis est aussi dans la 2.0, je ne suis pas forcément du même avec que le W3C sur tout)

Je me permet de commenter en détail pour améliorer La formulation laisse entendre que : alt et longdesc servent à la même chose mais on ne doit mettre que du court dans le premier et du long dans le second on doit mettre des alt pour les puces et autres choses, j'ai peur qu'on comprenne qu'il faut mettre alt="puce" ou quelque chose du genre Pourquoi ? J'ai beau être totalement en faveur des CSS il ne faut pas se tromper de cible. Les <font> HTML sont autant accessibles que les color: et font-size: CSS, peut etre même plus. Celui qui ne les comprend pas ou qui ne sait pas les interpréter peut tout à fait les ignorer. C'est moins élégant, moins pratique, mais ça n'a rien à voir avec l'accessibilité à mon avis. J'ai peur que ne comprenne que quelqu'un qui sait déjà ce qu'est <label> et à quoi ça sert. Nommer la balise pourrait être plus utile. cf plus haut. Le support HTML 4 est toujours là, il est largement plus répandu que CSS. Même si je ne le considère pas comme "à privilégier" <font> n'a rien à faire dans "plus supportés". XHTML n'a jamais remplacé HTML.

Perso je n'y serai pas, mais je compte bien sur Braillenet pour en faire un résumé

Pourquoi 1.1 ? non, pas forcément.

- xxx/yyyy ou tout autre procédé d'écriture linéraire (avec plein de parenthèses et tout) - une image - mathml (pas supporté partout) - faire du joli ascii art dans un <pre> Désolé, il n'y a rien d'autre à disposition.

pour ceux qui comme moi ne sont pas doués, l'adresse de la page est dans le titre du fil de discussion. Aligner à gauche ... la page ? je ne suis pas d'accord, centrer me parait beaucoup mieux. Enfin c'est une affaire de gout je pense.

Juste un truc: coder un truc à la main en js ou PHP n'empêche pas de déclarer les CSS correctement de façon à ce qu'un navigateur bien foutu n'ai pas besoin d'utiliser vos artifices ...

Ça me va très bien, c'est au contraire des choses que j'attend. Si toi tu ne comprend pas c'est que je me suis mal exprimé et qu'il me faudra reprendre certaines parties.

Mea culpa, j'avais oublié de préciser ça : Tu es *obligé* d'encoder les caractères <, > et & si tu ne veux pas qu'ils soient interprétés. Ceci est une obligation (sauf cas spéciaux), ce n'est pas simplement "mieux". Nota: c'est valable aussi pour les URL, http://example.org/page?param=valeur&param2=valeur2 s'écrit <a href="http://example.org/page?param=valeur&param2=valeur2">xxx</a>

aucune raison d'inscrire les caractères spéciaux sous forme d'entité. Ce n'est nécessaire que si tu as besoin de caractères spéciaux qui ne sont pas disponnibles dans ton codage actuel. Si tu ne sais pas de quoi je parle c'est que tu utilises le codage par défaut, l'ISO-8859-1. Et là les caractères français sont tout à fait supportés.

> Quel est le jeu minimal de métadonnées pour décrire une page web Le titre Tout le reste est facultatif. Pire, les valeurs elles mêmes ne sont pas normalisées (à part les DC, mais ce ne sont pas les plus utilisées). Donc à toi de voir ce qui t'intéresse de mettre. Personnellement la date me parait des plus utiles. > Mais je les vois floues , et j'ai décidé de ne plus les mettre. Elles sont toutes floues. Rien n'est standardisé. Certaines sont largement utilisée, d'autres peu. Chacun fait sa sauce. Les seules réellement "sûres" sont "description", "keywords" et "robots". Globalement je te conseille d'utiliser Dublin Core, de part le fait qu'ils essayent de standardiser tout ça, c'est clairement la voie à suivre (la seule qui permettra une réelle exploitation de ce que tu écris).