TheRec

De rien Mais pourquoi dis-tu "Par contre ..." ? Utiliser <br> (HTML) ou <br/> (xHTML) C'est ce que je t'ai conseillé

Bien sûr qu'il est "possible" de le faire, maintenant c'est au propriétaire du site de décider s'il veut le faire. Connaissant Dan, il sera disponible pour te répondre si tu prends la peine de lui écrire un message personnel pour faire ta demande

De rien. Bien sûr, jQuery n'est pas du tout indispensable, il facilite juste les choses à mon avis. Il ne fait rien de plus que ce qu'est capable de faire Javascript nativement

Bonjour, Donc invariablement, le document.write s'exécute car il est appelé dans le script distant ? Ou as-tu le contrôle sur ce(s) document.write ? Si tu n'a pas le contrôle sur cela, le seul moyen que je vois est, une fois la page chargée et le script distant exécuté, reprendre l'ensemble des éléments générés (pour peu que l'arborescence DOM soit toujours cohérente) et effectuer un deuxième traitement en corrigeant ce qui ne te plait pas. Je ne peux que te conseiller jQuery pour ce genre de travaux, il y a des fonctions très pratiques pour la sélection des éléments souhaités. Une fois les éléments sélectionnés, tu peux simplement les supprimer de l'arborescence. Il faut simplement placer ce traitement dans un événement qui se produit après l'appel à ton script distant.

Bonjour, Je n'utilise pas Smarty, mais ma compréhension de ce que tu fais est la suivante : $oSmarty->assign('lemembre',$membre); Tu assigne à la variable $lemembre de ton template la valeur de $membre qui prend sa valeur depuis la fonction mysql_fetch_array. Donc tu récupères un enregistrement de ton recordset ($req) sous forme de tableau et tu l'assignes à cette variable $lemembre. À chaque itération de la boucle tu remplaces ta variable $lemembre et donc en fin de boucle tu n'auras plus que le dernier enregistrement. Ensuite dans le fichier .tpl lorsque tu essaies d'afficher cette variable elle ne contient qu'un tableau (correspondant à ce dernier enregistrement), donc tu parcours (avec la boucle section) les champs, alors que ton but était de parcourir un tableau contenant chaque ligne de ta base. Pour remédier à cela je ferais ainsi : $req = mysql_query("SELECT * FROM ga_membres"); $membres = array(); while($membre = mysql_fetch_array($req)) { $membres[] = $membre; } $oSmarty->assign('lemembre',$membres); Ainsi ta variable $lemembre sera un tableau de tableaux et lorsque tu le parcourra avec la boucle section chaque itération correspondra à une ligne de ton recordset. Maintenant, pourquoi obtiens-tu ces résultats "bizarres" ? Je suppose que tu as 7 champs dans la table "ga_membres" et comme je l'ai dit précédemment ta variable $lemembre contient qu'un seul enregistrement et donc lorsque tu parcourrais ce tableau tu ne récupérais qu'un caractère (car lorsque tu utilise $var[x] et que $var et une chaîne de caractères tu accède au caractères correspondant à la position "x") pour chaque champ.

Bonjour, Deux cas de figures sont possible, soit le visiteur a activé le système de cache de son navigateur (généralement c'est le cas car par défaut les navigateurs ont cette fonctionnalité activée) cette image sera mise en cache (localement sur le disque dur) lors du premier survol et ne sera pas rechargée depuis ton serveur à chaque fois (à moins que cette image change, qu'elle soit plus récente que celle dans le cache, qu'elle ne soit plus présente dans le cache, etc. bref que le système de cache estime que cette image est "périmée"). L'autre cas de figure, sans système de cache, l'image sera chargée à chaque survol (et donc consommera plus de bande passante). Bonne continuation. P.S. : Pense à te présenter et illustrer ton problème en nous communicant l'adresse de ton site

petit-ourson> ZeBrian a déjà indiqué que ce code n'était pas ce qu'il cherchait quelques messages plus haut (lors de sa réponse à sarc)

Bonjour, Il ne suffit pas de spécifier une adresse de courriel comme action pour que le formulaire soit transmis à cette dernière. Tu auras besoin d'un langage interprété côté serveur (PHP, ASP, CGI, etc.) qui fera appel à un "mailer" qui permet l'envoi de courriel électronique. En PHP par exemple il y a la fonction mail. P.S. : Le code que tu as donné va ouvrir le client de courrier électronique, s'il y en a un qui est installé, de ton visiteur et ouvrir un nouveau message avec l'adresse que tu as indiquée dans l'action du formulaire.

Bonjour, Les nouvelle lignes (que ce soit \n, \r ou \n\r) ne sont pas traduites par un retour à la ligne dans un fichier HTML lorsque ce dernier est interprété par un navigateur, à moins que élément où il se trouve soit par exemple <pre> ou <textarea> par exemple (ou tout autre élément pouvant contenir du texte et prenant en compte l'attribut CSS "white-space: pre;"). Sinon pour avoir un retour de ligne effectif en HTML (après interprétation du code par un navigateur) il est possible d'utiliser le balise <BR> ou en xHTML <br /> et PHP met à disposition une fonction permettant de convertir toutes les nouvelles ligne en balises <br /> : nl2br. P.S. : Dans le cadre d'un fichier texte les nouvelles lignes se font effectivement avec ces caractères "non-imprimables" : \n (Unix/Linux), \r\n (Windows) et \r (Mac)

Normal, tu as un certain temps pour modifier tes messages... mais ne t'en fait pas, un modérateur aurait de toutes façons enlevé le "Résolu" du titre de ton message, Dan ne souhaite pas être positionné en premier sur ce mot clé dans les moteurs de recherche P.S. : Je n'ai pas la science infuse non plus... je t'ai dit que je ne connaissais pas d'autre solution, pas qu'il n'en n'existait pas une

Bonjour, je peux peut-être te donner une piste du côté de jQuery, de base les pseudo-classes :hover, :focus, etc. ne sont pas implémentées dans les sélecteurs, mais il y a un plugin permettant d'étendre les possibilité de sélection et inclure la majorité des pseudo classe. Je ne suis pas certain que c'est ce que tu cherche, j'ai eu l'impression que tu souhaite quelque chose qui se règle en une fois pour tous les :hover qui sont défini pour une classe, mais cette solution ne permet que de modifier l'élément sur lequel la souris est actuellement : Selectors Plugin Si c'est ce que tu cherches, une fois l'élément sélectionné tu pourras modifier ses propriétés CSS simplement comme tu l'aurais fait avec tous autres éléments (comme dans ton exemple : obj.style.<propriété>). Cela implique donc d'appliquer les modifications de style à chaque fois qu'un élément est survolé. Sinon je ne connais pas d'autre manière de faire... Javascript a effectivement ces limites lorsqu'il s'agit de modifier le style des éléments.

Oh oui Comme quoi, on est tous passé à côté de cette faute "d'orthographe" sauf sarc, bravo Les guillemets restent superflus mais ne doivent pas gêner...

Euh... non il les a mis dans le bon ordre, mais effectivement le nom des variables qu'il a utilisé peuvent porter à confusion. Sinon je penche pour la même solution que georges, les guillemets sont de trop. Mais je pense plutôt que tu devrais essayer d'utiliser les jointures entre tes tables pour faire ce genre de requêtes (c'est à ça que ça sert), car une requête dans une boucle peut s'avérer très coûteuse en ressource lors de la montée en charge.

Bonsoir, Je suppose que tu parle des variable GET, POST et COOKIE, si c'est le cas c'est la création de ces variable est réalisée par une directive qui est appelé register_globals. Lorsque ce mode est activé, chaque variable définie soit par GET, POST ou COOKIE (et autres variables d'environnement et de serveur) est assignée automatiquement à une variable globale du même nom sous PHP. Lorsque ce mode est désactivé il faut utiliser les tableau de variables super-globals $_GET, $_POST et $_COOKIE ($_ENV, $_FILES, $_SERVER, etc.). Pour activer ce mode tu as plusieurs possibilités mais il n'est pas possible de l'activer avec la fonction ini_set. En revanche tu peux le faire depuis un fichier.htaccess si tu en a l'autorisation (sur le serveur HTTP, Apache généralement), voici la ligne a ajouter dans ton fichier.htaccess : php_flag register_globals on Attention: Il faut que tu sois conscient que cette directive, lorsqu'elle est activée, est potentiellement très dangereuse et peut créer des failles de sécurité si tu utilises des variables sans les déclarer auparavant par exemple. Tu vas réellement intérêt à remplacer ces variables par l'utilisation des tableaux super-globals du point de vue de la sécurité et également de l'évolutivité (PHP 6.0 n'implémentera plus cette directive). P.S. : Il y a des chances pour que sur uns serveur mutualisé cette ligne dans le fichier .htaccess ne soit pas autorisé et provoque une erreur "500 Internal Error", si c'est le cas tu n'as pas d'autre possibilité que remplacer le nom de tes varaible... et sérieusement c'est un mal plus que nécessaire !

Le problème ne se pose pas justement parce que les lois sont faites pour protéger les gens... elle limite dans une certaine mesure la "liberté d'expression", mais c'est pour le bien de la majorité et c'est ce qui est le fondement de n'importe quel loi : l'intérêt général (cette notion n'existe pas à proprement parler en droit français). Si ces lois te gênent autant il est possible de t'investir politiquement et d'essayer de les faire changer, bien entendu tu as très peu de chance de faire changer quoi que ce soit à ce genre de loi qui assure une certaine liberté aux personne concernée par le "vol" de leur image. Sinon il te reste à appliquer ces lois aussi aveuglement que possible pour préserver l'intérêt général. P.S. : J'abonde dans le sens d'Arlette, nos réponses ne sont pas faites pour te plaire mais pour résoudre le problème que tu nous as proposé. C'est dur dans un sens de consacrer du temps à un tel projet et ensuite entendre qu'il n'est pas légal... c'est pour cela que dorénavant tu devrait évaluer ces risque avant même de commencer à travailler sur un projet.

Le code que tu proposes n'est pas réellement un hack, c'est un commentaire conditionnel et c'est une fonctionnalité du navigateur Internet Explorer depuis sa version (un hack CSS est l'utilisation d'une mauvais interprétation du parseur d'un ou de plusieurs navigateur), mais je te l'accorde ce n'est qu'une question de terminologie. @Loupilo> Ce que je propose et que tu considères comme un gadget est une solution qui permet de ne pas se limiter à une largeur fixe ou une largeur minimum (qui ne satisfont pas mes critères d'usabilité). Concernant la séparation des diverses couches d'une page Web, pour moi elles sont claires, elles sont motivées par le langage utilisé entre autres (je ne vais pas faire la liste de critères vu que ce paragraphe est déjà hors sujet). La syntaxe utilisée dans ce cas est du Javascript (invoquée par la fonction CSS expression), dans une feuille de style. Pour moi, et je doute être le seul dans ce cas, cela revient exactement au même que d'utiliser l'attribut style de n'importe quel élément HTML alors que l'on souhaite faire une séparation du contenu et de la présentation. Il n'y a pas d'assimilation à faire selon moi, contrairement à ce que tu penses, si je devais faire ce que Leonick propose j'invoquerai un script écrit en Javascript au chargement de la page (et cela correspond à la couche de comportement, aussi connue sous le nom de behaviour layer). Comme je l'ai dit, par expérience c'est ce genre d'assimilation qui mène aux problèmes de maintenance. Il est possible de faire ainsi, mais tu ne me verras jamais le conseiller.

Bonjour, Il est parfois utile de faire une petite recherche avant de prendre la peine de rédiger tout un message J'espère que c'est ce que tu cherches, corrige-moi si je me trompe Bonne continuation.

Oui, le mélange de la couche de comportement de la couche de présentation est gênant dans la mesure ou cela nuit justement à facilité de la maintenance... mais c'est un choix, comme ont peut choisir de mélanger la couche du contenu et de la présentation et on se retrouve avec les mêmes problèmes Je ne vais pas trop débattre sur ce point car c'est un peu hors-sujet et je n'ai pas vraiment d'argument plus probant à t'apporter (d'ailleurs je doute qu'il y en ait besoin). Concernant le choix pour l'utilisateur je ne propose pas de le laisser choisir en "800x600 et 1024x768" (un point technique que je n'ai même pas évoqué, car il n'est pas significatif à mon avis), mais entre un contenu extensible en largeur (dans les deux sens) et un contenu qui a une largeur fixe. Voici un exemple accompagné d'un article (en anglais, désolé pour ceux qui n'en profiteront pas) qui reflète mon point de vue : Fixed Or Liquid? Et je ne vois pas en quoi un tel système ne serait pas accessible aux utilisateurs, du point de vue de la compréhension. Du point de vue de la maintenance et de l'évolutivité, il est clair que cela demande un peu plus de travail à la conception. Mais en admettant que, comme dans l'exemple ci-dessus, on tire avantage des feuilles de styles et qu'on ne définit que les styles qui changent d'un layout à l'autre (flexible, et largeur fixe) et que les autres styles se trouvent dans une feuille de styles commune, ces problèmes sont tout à fait surmontables. Pour ce qui est de la mise en place du système ce n'est pas vraiment une difficulté, il existe des style switcher de plusieurs natures: Javascript seulement, PHP (ou langage interprété côté serveur) uniquement, mélange des deux. Si le site est bien conçu l'entier du code agit simplement sur l'en-tête HTML des pages (liaison des feuilles de style). Tout ceci conservant l'accessibilité au contenu et en augmentant l'usabilité des pages. Maintenant il est clair que si l'investissement que cela représente ne vaut pas selon toi le gain en usabilité c'est ton droit, j'exposais juste la manière que je préfère utiliser

Tout cela démontre une chose, la résolution n'est pas une constante chez les visiteurs donc il n'est pas possible de ce baser sur cette mesure pour créer un site, d'où mon approche du côté de l'usabilité. La contrainte en largeur s'applique pour une question d'usabilité et laisser la possibilité aux visiteur de "casser" cette limite de largeur et rendre la largeur de la page flexible (dans les deux sens, que ce soit fenêtre agrandie, plein écran, ou de taille réduite) permet à ceux qui le souhaitent d'obtenir une mise en page qui le convient mieux (parce qu'ils on une plus grande résolution, deux écrans, etc.). Où le faire dans l'autre ordre c'est-à-dire présenter une page avec une largeur flexible et proposer une alternative avec une largeur fixe. On ne peut pas se baser sur une expérience empirique et/ou statistique pour définir un nombre d'or dans la réalisation d'une page vu la nature du média et de la diversité des visiteurs. Ce dont je parle se base sur des études scientifiques (certes empiriques dans une certaine mesure). Je ne suis pas d'accord, une page totalement flexible peut se dégrader et/ou nuire à l'usabilité lorsque la la taille a disposition devient plus large ou moins large que les valeur "habituelles"... c'est pour cela que je propose un compromis. Ce que propose Leonick est un début, mais le problème est que cette solution mélange la couche de présentation et la couche de comportement en incluant du Javscript dans la feuille de style (ce n'est pas un hack, c'est une fonctionnalité). C'est pour cela que je suis plutôt pour un système de changement de feuille de style qui ne pose pas ce problème de conception.

Peut-être que pour vous décider choisir le compromis entre un layout flexible et un layout à largeur fixe il faudrait attaquer le problème sous un autre angle. Du point de vue de l'usabilité il est nécessaire de maîtriser la largeur du texte d'une page, cette affirmation se base sur un étude (qui date un peu je vous l'accorde), The Effects of Line Length on Children and Adults Online Reading Performance (2002) et la plus récente suite de cette étude The Effects of Line Length on Reading Online News (2005) Document en anglais, désolé je n'ai pas trouvé de traduction. Cela vous indique qu'un design complètement flexible qui permet au texte d'une page de s'étendre au delà de 95 caractères par ligne ou en dessous de 35 cpl ne sera pas "agréable" à la lecture... c'est aussi un de facteur qui pousse beaucoup de gens à utiliser des layouts à largeur fixes qui sont compatibles avec la résolution 800x600, cela donne à peu près 775px "exploitables" (à cause des barres de défilement, bordure de fenêre, etc.) et cela correspond à environ 100 caractères par ligne (espaces compris) et on rejoint la longueur "idéal" d'un point de vue de l'usabilité. Le problème est que, comme cela a été évoqué précédemment, le Web n'est pas un média "statique", chaque utilisateur peut obtenir des résultats différents (polices installés, taille des caractères, résolution) et donc ce calcul fonctionne dans le cas des configuration "par défaut" des navigateurs (en plein écran). Pour travailler avec cet état de fait il y a plusieurs solution et selon moi la meilleure est de partir d'un point de référence, c'est-à-dire largeur fixe pour optimiser l'usabilité de la page et laisser la possibilité de briser cette largeur fixe par une action de l'utilisateur (c'est à dire au moyen de Javascript, soit pour présenter la page une feuille de style alternative, soit en ôtant ces largeur fixe directement, la méthode importe peu). Premier inconvénient de cette méthode est que cette fonctionnalité ne sera pas accessible aux personnes qui n'ont pas activé Javascript (volontairement ou non), le contenu restant accessible cela ne me gêne pas outre mesure. Second inconvénient c'est le temps de développement supplémentaire nécessaire, malheureusement peu de clients souhaitent investir dans ce genre de fonctionnalités ce qui me force souvent à revenir au bon vieux layout à largeur fixe et cette largeur fixe n'est pas motivée par la résolution mais par l'usabilité comme je l'ai expliqué précédemment.

À ce sujet je suppose que cela va à l'encontre de la volonté de Google Adsense qui souhaite que les clics soient générés volontairement et pas fortuitement par l'utilisateur... Je pense que les règles sont assez claires et qu'il ne faudra pas s'étonner des conséquences : Source : Règles définies pour le programme Google AdSenseDu moins je l'interprète comme cela

Bonjour, Sois le bienvenu sur le Hub ! Je ne sais pas si on doit parler de partenariat (du moins je nais pas connaissance d'un partenariat officiel) avec Alsacreations mais à mon avis et d'un point de vue qualitatif ces deux communautés sont proches donc je ne peux que me réjouir d'accueillir un membre de cette communauté À bientôt dans tes prochaines interventions sur le Hub

Personnellement du moment qu'il y a bien un lien sémantique entre le libellé et les données qui s'y rapportent, la structure utilisée m'importe peu... Le débat se résume à cela à mon avis. Le W3C ne recommandera jamais l'utilisation d'une ou l'autre de ces solutions (d'abord car ce n'est pas leur rôle premier), ils établissent les recommandations à un niveau d'abstraction plus haut que cela. Les recommandations ne sont justement pas toujours précises au niveau où ce situe le problème évoqué ici car il n'y a pas de solution unique (et donc le W3C devrait établir une liste exhaustive de toutes les possibilités ce qui ne serait pas viable). L'essentiel étant d'être conscient des choix que l'ont fait et des implications qui en découlent, dans ce cas les deux solutions se valent et j'ajouterai que, par expérience personnelle, la solution des tableaux donne peut-être plus de flexibilité au niveau de l'évolutivité et que dans ce cas précis cet avantage ne sert pas vraiment (je ne vois pas comment pourrait évoluer le contenu du tableau dans ce cas précis).

Bonjour, Les avis vont différer sur les questions que tu poses, c'est certain. C'est le même problème qu'il y a avec les formulaires de savoir si un tableau est l'idéal pour présenter les champs et leur libellé... Personnellement je ne suis pas "fixé" sur un "oui définitif" ou un "non définitif", l'utilisation sémantique des tableaux doit se limiter à des données dites tabulaires (c'est le cas, chaque cellule du tableau correspond à un en-tête) et si c’est la solution que tu choisi, il faut utiliser tous les moyens à disposition pour faciliter l'accès à aux données du tableau (summary, caption, th, td, scope, etc.). Si tu optes pour un liste de définitions, ce qui est tout à fait valable également, tu n'auras pas certains avantages du tableau (summary entre autres) et tu perds en flexibilité si tu viens à avoir une colonne supplémentaire par exemple (je n'en vois pas l'utilité dans ton cas, mais qui sait ). Tu vas me dire que cela ne t'avance pas beaucoup, ce que tu dois retenir de ce que je viens de dire c'est que les deux structure son sémantiquement correcte pour les données que tu veux présenter. D'autres te diront certainement de laisser tomber les tableaux pour faire tu 100% tableless et si j'étais toi je ferais la sourde oreille, car selon le W3C n’a jamais recommandé ceci, il recommandent uniquement d’utiliser les élément selon la sémantique Choisis la solution qui te sembles la plus facile à mettre en œuvre étant donné des deux solutions sont équivalentes dans ton cas. **EDIT** : Comme prévu lorsque j'ai intiailement rédigé mon message, le débat s'oriente vers la même issue que ce sujet (Hein sarc... )

C'est une possibilité, mais il y a beaucoup de moyen de voir son compte désactivé... par exemple : Source: Conditions générales de Google Adsense Ce n'est qu'un exemple, les annonces sur les pages d'inscription sont très courantes et apparemment elles sont interdites... (Je ne parle pas du dernier point concernant les sites adultes, etc.). Déjà rien que sur le Hub je constate ce problème, et c'est de loin pas le seul site dans ce cas :S Comme je ne suis pas un visiteur régulier de ton site Sarc je ne sais pas où étaient placées les publicités, donc c'est difficile d'avoir une idée précise du problème qui a amené Google a désactiver ton compte... je t'incite à relire les conditions et les conseil donnée par Google, tu es le mieux placé pour trouver ce qui a posé problème. Et aussi, si ce n'est pas déjà fait, contacter le service de support Adsense pour leur demander des informations... et t'armer de patience, ils ne sont pas très prompt pour les réponses selon les échos que j'ai eus P.S. : Ou même les contacter sur le forum de Google Adsense