Beatnykk

scarab ce que t'as marqué dan au-dessus est clair : si ton adresse commence par www.motclé.neoboot.com, il est impossible que la requête arrive au serveur de www.neoboot.com (avec derrière quelquechose comme 'script.php?var=motclé'). à moins que... ? tu me crois si je te dit que c'est peut être possible ? mais ça va peut être pas te plaire... à mois que tu n'achète TOUS les domaines de tes grandes catégories avec www.*(.|-|_)neoboot.com là ensuite il y a du boulot mais je pense que c'est possible de rediriger des requêtes vers neoboot avec motclé et tout. mais ce serait te lancer dans un boulot que seules d'énormes structures se permettent ... sacré scarab, un peu la folie des grandeurs et puis pour le référencement ouïalle ! les grands domaines ne seraient-ils pas considérés comme des satellites ? je sais pas trop. en tout cas il y a surement plus simple. dans le cas de mon magazine, l'url www.domaine.com/pages/categorie/(rubrique)(numero).html renvoie bien sur www.domaine.com/script.php?v1=(categorie)&v2=(rubrique)&v3=(numero) et c'est fort satisfaisant, non ? j'ai même &v4=(version) pour low ou high résolution images, maintenant nan puis pour les recherches, fait donc un tableau par categorie et propose dans la page recherche un 'rechercher dans', comme cela se fait. c'est sûr si quelqu'un met 'dans tout', tu dois faire une recherche multiple un peu lourde à gérer mais bon... bonne chance.

le problème du zip c'est que c'est bon sur pc, problématique sur mac fait plutot 3 versions de l'image (100%, 50%, 25% de sa taille) en .jpg ensuite tu crées un selecteur (par un formulaire (<form>) cochable ou listé) proposant les 3 et un bouton valider la validation poste la bonne image dans une nouvelle fenêtre (_blank) ou directement (invite 'ouvrir' ou 'enregistrer sous' pour le client) tu peux aussi écrire le choix de résolution dans un cookie, ou dans une variable cachée repostée entre les pages (ces deux derniers en php ou en javascript), pour ne le demander qu'une seule fois quelle résolution l'utilisateur souhaite demande des détails si l'une de ces possibilités t'interessent il y en a surement pleins d'autres dailleurs

c'est une bonne idée. il y a des élèments à reprendre. seulement comme je suis idéaliste (rien qu'un peu) je voudrais un système ne faisant ni appel au cookies ni au javascript (car certains les désactivent) et de préférence pas à flash (certains n'en veulent pas ou ne peuvent pas installer le plug). je pensais me baser sur le fait que pour le serveur les requêtes images sont des opérations à part entière (détachées des autres requêtes). il faudrait donc que je passe quelquechose (une variable, un élèment quelconque) au moment où le client réclame une image via une page. et là le serveur décide si c'est low ou high. je suis encore dans le vague d'autant que ta solution a un problème majeur : quand je travaille une page (sous dreamweaver) si toutes les images sont dynamiques on ne les voit pas (un gros carré gris qui sent la mort). jusqu'à tester le site dans un explorateur, du moins. et niveau travail mise en page ça complique les choses. je suis à la recherche (illusoire? ) d'une technique s'apparentant aux 'post-fx' du cinéma : une redirection intervenant tout à la fin, par simple commmodité méthodique... rêveurs du soir, bonsoir.

salut. nouveau problème : quelqu'un voit-il comment conditionner le chemin des images (chemin avec RewriteCond dans htaccess, à moins qu'il y ait mieux ou plus simple) à partir d'une variable dans l'url du script php. en d'autres mots : je veux, en fonction de la vitesse de connection client, conditionner la route de TOUTES les images d'une page vers une version basse déf desdites images, pour des raisons évidentes (adaptabilité client, occupation serveur, etc.). je pensais utiliser un script php ou flash qui teste et renvoie une variable (low, high) qui indique à htaccess (en cas de low, par exemple, high étant le site par défaut) de remplacer par un chemin donné je ne sais pas si c'est fonctionnel, j'en suis à l'étape par étape et j'avoue que je nage un peu. quelqu'un a peut être, de plus, une solution évidente auquelle mon cerveau tortueux n'aura point pensé merci de vos aides. si ça marche je vous rhaaaa lovely ! :!:

ha ha ! et voilà ou ça mène trop de principes : on en oublie non pas les normes (w3c) mais les standards (la loi du plus fort) !!! hé hé. pis oui c'est normalque ce soit déroulé. ce que je dit c'est que si ton menu est dans une zone donnée (une frame ou un div) il y a des risques qu'il déborde et ne soit plus entièrement visible au premier coup d'oeil (c'est pas le but d'un menu en fait ?) otherwise, overall okay 2 me. i respect your style, (css) body

rien n'est anormal mireille et tout est possible... continue sur tes mots clés et l'impensable peut arriver: tu vas doubler les 'united naked beurettes' dans gg et, qui sais, vendre du beurre demi-sel à des hypertendus !

passant sur ton arrondissement un peu 'chauvin' à 100 sec pour 10 images à 2 sec/img , je pense tomber d'accord sur ta version 'compromis' avec du texte + image. 1/ parce que niveau référencement c'est le top 2/ parce qu'on peut respecter des impératifs graphiques tout en tenant compte des utilisateurs en browsers texte (anciens browsers, browsers linux, image désactivées, etc.) 3/ parce que niveau compatibilité c'est plutot un bon juste milieu. 4/ j'aime bien le chiffre 4 mais je n'ai plus rien à ajouter nb : après test, sur différents browser et sur mac : tes menus sous déroulants posent problèmes sion considére 10 ou plus rubriques : 1/ en mode texte tou est déroulé dés le début (façon données chapitraires Titre <br> espace .soustitre1 etc.) et si tu as une zone donnée, forte chance que ton menu déborde sous 800*600 ou moins voire plus si beaucoup de sous-titres. 2/ sous mozi et nscape le problème c'est qu'en passant successivement sur les titres, tous les sous titres s'ouvrent et ne se referment plus (pas comme sous mie et opera) : du coup même remarque ça risque de déborder et tout le monde ne va pas penser à 'refermer' les premier pour faire 'remonter' les derniers titres et sous-titres. 3/ quoi c'est pas clair ce que je dit ? 4/ j'adore le chiffre 4 en fait. mais j'ai pas testé tes pages sur mac non plus... a+

quelle saloperie ce gg ! il t'as pris en flag ce jour là. bon je rigole mais j'aimerais pas être à ta place. j'espère que ça se reparera vite dès sa mise à jour...

sibelius désolé de te contredire mais : 1/ des images bien compressées, otpimisées en jpg peuvent être belles et ne peser que quelques ko (souvent mois de 10 ko soit 2 sec à 56k) 2/ si tu renseignes bien le tag alt de tes images ça ne gêne aucunement le réferencement selon moi (qui pense le contraire me l'argumente) 3/ sans images c'est plus léger mais beaucoup moins 'dynamique' et carrèment moins 'graphique'. de plus les rollover de texte (par css) ne marchent pas sur tous les navigateurs. +/ même si tu fais des rollovers (en javascript) ça ne gêne pas la navigation pour un client qui ne les active pas : le bouton ne s'allumera pas au passage de la souris, les images secondaires de seront pas préloadées et c'est tout. ceci dit si tu veux un menu de base (non-péjoratif), de type texte , pas besoin d'image okay, d'accord... et tes exemples de menus sont très bien, sincérement, mais ne correspondent pas à tous les besoins 'graphiques'.

benvenito webmom. comment ça pas en pole position ? quel genre de mots clés saugrenus as-tu bien pu taper ??? bon en tout cas j'espère tes visites sur le hub fructueuses et instructives comme elles le sont pour moi...

tiens je viens même de faire ta manip (enreg sous et rouvrir sous dreamweaver mx) : no blème juste un bout de tag qui traine en bas avant le </body> : 'iv> ' (soit 'iv> ') mais çapeut pas être ça qui fait problème. peut être comme souligne monique tes <tbody>. tout le monde ne gère pas ça. quelle version de dream as-tu ?

je pense que le problème arrive lors de ton 'enregistrer sous'. si les pages sont 'bonnes' dans dreamweav si elles s'affichent correctement sous http://www.tonsite.truc (essaye plusieurs browsers différents et sur mac aussi, et regarde la source html en ligne en +) alors il n'y a qu'au moment où tu les resauve depuis ton browser (lequel est-ce dailleurs ?) qu'une bizarrerie peut arriver. l'informatique ne fait que ce qu'on lui demande. (conseil au passage, dont tu fais ce que tu veux) prends l'habitude de bosser avec la vue intermédiaire sous dreamweaver (bouton du milieu en haut : laisser quelques lignes laissant voir le code html, le reste de la page en mode graphique). comme ça tu aura en quelques temps le code 'dans l'oeil' et tu ne te poseras plus ce genre de questions. et puis tu vas vite voir qu'aussi performant soit dreamweaver, quand tu modifie des pages il alourdit allègrement le code (il n'est pas le seul) dans certains cas. d'où l'intérêt de 'controller' son travail avec une vue scendée code/graphisme. ex: quand tu as fait un paragraphe reglé sur un format de ta liste css comme <p class="truc">, et que des parties de ce paragraphe (plusieurs passages à mettre en valeur, par ex.) ont été formaté différemment avec <span class="autre"> truc </span>. si tu décides de ne plus mettre en valeur ces passages parce que ça gène la lisibilité par ex., tu sélectionnes tout le paragraphe et reclique sur la ligne 'truc' dans la liste css, non ? hé bien au lieu de supprimer tous les <span> comme attendu, il va les garder en changeant 'autre' par 'truc'. et ce n'est qu'un exemple d'alourdissement du code. il y en a des milliers d'où intérêt à travailler en scindé.

stéphane : j'espère que tu dis pas ça pour me faire plaisir. mais si on tombe d'accord tant mieux, histoire de pas faire une polémique pour rien. en revanche je ne te suis plus, mon ami, mais alors plus du tout à propos du diesel : okay c'est dégueu mais ça défonce 10000x plus la tête que du rhum à la banane. je peux pas laisser dire des choses pareilles !! bon stop.

mon utlisation des layers est un peu celle des calques de photoshop (je suis avant tout graphiste). ils me permettent de délimiter une zone (rectangulaire uniquement), de fixer ses attributs taille et position en absolu (px) ou relatif (%), et donc d'avoir une mise en page précise et souple à la fois. la différence avec l'utilisation d'un tableau dit "graphique" est : 1/ que les tableaux graphiques c'est quand même hypra lourd à mettre en place (et à modifer par bloc par la suite). 2/ que ces "zones" css n'ont pas la paramétrabilité d'un layer (scroll, plan ou profondeur 'z-buffer', définition de visibilité et de dépassement, etc.). mais surtout : ----début 3/ qu'une image donnée en pourcentage à l'intérieur d'une cellule de tableau se referrera selon le browser, sa version et sa plateforme (et l'humeur de l'ingé réseau voire l'âge du capitaine surcouf) soit à la cellule elle même (ex: mie6 pc), soit à la taille du tableau (ex: nscap5 pc), à la taille totale de la page (mie5 mac)ou pire, à la taille originale de l'image (nscape 4.5 mac). étant donné que par ex. sur mac les mises à jour des browsers sont faites pour mac os X users seulement (les autres pouvant la plupart du temps aller crever dans leur ghetto élitiste), et tout le monde n'utilisant pas forcément internet explorer, ça pose des sacrés problèmes de compat'. comme j'ai décidé de faire des pages visibles par tous et partout après version 4.0, et extensibles d'un 640*480 à 1600*1200 (j'ai testé, c'est sans soucis) je trouve les layers pratiques. ----fin et que comme je ne sais pas si toute cette "science" acquise bonnant mallant de façon empirique s'avérerait toujours applicable au css, je continue en layer. le css offre donc sûrement d'autres possibilités (sinon vous ne bosseriez pas avec), mais est d'autre part bloqué face à certaines fonctionnalité des layers. il me semble qu'une fois de plus la fusion (sans mélange des genres) permet le meilleur compromis. dès que j'ai le temps j'essaie d'introduire du css dans mes layers. le résultat sera peut être détonnant, qui sais ?

la première des deux url pose problème dès qu'on réduit la largeur de l'écran. quant à la deuxième c'est super sympa, ça, on pourrait même proposer à un visiteur de choisir son layout préféré en fonction d'un cookie qui réaffiche à chaque visite. mais il n'y a pas forcèment besoin de css. en layer ça doit marcher aussi !? non ? par contre, language dynamique obligé (php ici) ...

pour ce qui est des frames, je suis juste pas d'accord (ça y est y refait son rebelle le beatnykk). je pense que les frames sont un bon moyen incontournable dans certains cas : je pourrais citer des tas d'exemples où cela m'a évité de devoir insérer du javascript, ou permis d'avoir une navigation rapide et claire, ou d'avoir une interface totalement adaptable du 800x600 +edit+et même du 640x480+edit+ au 1600x1200 (de pc à mac, de mie5 à lynxviewer) sans une ligne de code conditionné. dire que la méthode est en 'fin de vie', c'est un peu comme de dire que le diesel va supplanter le rhum à la banane. les frames ont une utilité et quelques inconvénients. il n'y a pas une seule méthode parfaite pour faire un site. chacune a des avantages et des limites. dire "les frames sont moins utilisées que les pages 'à plat' " est correct. dire "les frames sont en voie de disparition, elles sont moins bien référencées" est à moitié faux. la meilleure preuve est qu'on peut avoir des frames à source dynamique (php par exemple). mais je ne demande qu'à être contredit...

bon finalement je suis pour et je l'ai utilisé. aucun visiteur ne voit le travail fait sur l'url, c'est instantané, invisible, inodore, mais léthal dans la clarté de l'adresse affichée. c'est assez marrant en fait, mais je conseille à ceux qui veulent le tester de s'installer un "faux" serveur sur leur machine de test (logiciel comme easyphp) pour tester leur ficher htacess en local parce que ça peut tatonner avant d'être juste, une règle de rewriting. en fait l'url rewriting c'est comme le vélo, disons, c'est les premiers centimètres... heu ... kilomètres qui sont pas évidents.

monique : on peut aussi le faire en layer (<div>) par include php, et c'est aussi payant en terme de possibilités de mise en page. question compatibilité je teste le tout sous 2 plateformes et 7 explorateurs (allant de version 4.5 à 7) et je n'ai aucun problème. maintenant c'est sûr le css c'est bien mais est-ce que l'affichage dans un éditeur classique (dreamweave ou autre) est aussi clair pour travailler qu'avec des calques ??

ils font aussi des clans dans warcraft3. ah oui c'est sûr c'est pas pareil comme délire. et au fait sibelius j'ai bien essayé d'aller voir ton site, hé bah j'ai jamais reçu de mail de confirmation avec mon mot de passe et tout comme quoi fast2reply, heu, ça veut dire quoi en javanais médieval déjà ?

j'ai essayé spamcop cité un peu plus haut : c'est pas la panacée dites moi, les adresses mails où se plaindre que fournit ce site lorsqu'on lui envoie l'entête des spams reçus, renvoient effectivement au bon domaine de départ du spam (en l'occurence moi c'était surtout des chinois ! les salauds ! me direz ils sont beaucoup et sont pas trop libres faut bien qu'ils s'occupent) mais les adresses (genre mailer_AT_beijin) n'existent plus. en plus que de me faire spammer j'envoie du mail à doublon (un envoi dans le vide + un retour du delivery server). pffffff écoeurant. la solution à nos problèmes : les pigeons voyageurs et l'essence de betterave.

alors donc j'ai revu mon système de variables et d'url rewriting pour obtenir dans l'url visible en barre d'adresse (celle qui sera rewritée par apache) un chemin très explicite, de façon à profiter (comme me l'a conseillé Coyote) des mots clés induits par le path de l'url. ce qui suit convient-il dans l'optique décrite ci-dessus ?? : h**p://www.spottwnews.com/pages/medias/television01.html (exemple) tourné autrement, le fait d'avoir "television" pris entre "/medias" et "01.html" dans l'url m'empêche-t-il de profiter d'une recherche sur critère "television" ? ou est-ce suffisant pour en profiter ? si oui cela profite-t-il en plus que des mots-clés dans la page elle-même ?. vais-je réussir la mission de tata poulet dans *vice*city* ? brenda acceptera-t-elle la proposition de michaël ? merci de m'éclairer

oui petite mireille ne t'énerve pas et saches que de toute façon il est très dur voire quasi impossible d'être bien classé avec un seul mot clé en recherche, étant donné la polysémie d'un mot donné quelque soit la langue (en l'occurence l'ambiguité dont tu fais les frais). en dehors du fait que ces sites, qui te "prennent ta place" par rapport à l'angle où tu considéres tes critères de recherche, soient des sites pornos, je pense qu'il n'y a aucun état de fait éthique qui leurs interdissent un mot de vocabulaire courant, même d'argot ou de verlan. que dire de "black", "vieilles", "jeunes", etc. j'en passe et des pires. les sites de boules ont droit à l'existence aussi, heureusement où malheureusement. tout ça est pour un mot clé, critère de recherche extrêmement vague. si maintenant tu recherche sur "beurres plaquette lait" tu n'es même pas référencée : c'est là que tu dois t'inquièter sur la pertinence de tes mots clés, et là tu ne peux t'en prendre qu'à toi si enfin le critère est "beurres patissiers" tu es 1ere, alors voilà du bon boulot ! il te reste tous les mots clés du champ sémantique de ton client à couvrir avant d'hurler sur les vendeurs d'huiles "aphrodisiaques". et puis qui sait peut être que le beurre corman est tartinable sur tout le corps

mémoi, à vue de nez sans éplucher le code, me semble que dans ton script l'élèment à déplacer s'appelle "calque", et que dans lepage, l'id de ton layer est "image"... donc le script ne peut pas deviner ce qui cloche tout seul. renomme le layer "calque" juste y voir clair

mimi, juste pris d'un doute en te lisant, et en supposant que tu n'y connais pas grand chose (ce qui est peut être faux ) : il ne sert à rien de formater un cdrw avant de le graver la première fois (contrairement à une disquette ou un disque dur, par exemple). par contre s'il n'y a que des données inutiles déjà gravées, ou une session unique, fermée et obsolète, là ça vaut le coup parfois de reformater et regraver par au-dessus. le mieux étant quand même de faire de multiples sessions pour des gravages par petits paquets plutot que de flinguer un cd à chaque fois pour quelques megaoctets ; dans ce cas s'assurer d'utiliser toujours le même logiciel car récupérer des multisessions d'un soft à l'autre (des sessions nero avec easycd par exemple) s'avère parfois impossible...

mangda: il n'y a de plus aucun intérêt à mettre des liens sur un élèments d'arrière plan car tu n'es pas sûre (selon les navigateurs, la résolution d'écran de chaque client, etc.) que ces liens ne seront pas cachés par des élèments du premier plan. maintenant s'il est vraiment nécessaire que tu fasses des liens dans une image située derrière d'autres élèments, tu as (selon moi là maintenant à l'esprit) 2 possibilités : -une image avec des cartes (map et area) cliquables comme chez bruno. -un tableau correspondant au découpage de ton image (pour avoir 1 partie par lien cliquable) rempli de la bonne façon avec le decoupage multiple. voila bon courage !!