wonderclochette

Bonjour, c'est tout à fait normal que ta bordure ne s'applique pas puisque tu as oublié de déclarer la propriété border-style. Donc si tu rajoutes : <img style="border-width:thin; border-color:RGB(255,255,255); border-style:solid;" ... Alors ça sera bon

Salut, Les éléments qui suivent DIV#thematics dans le flux sont sans doute en float. Il faut donc que tu créé un contexte de formatage pour l'élément conteneur. Le résultat avec IE est un bug de haslayout, comme tu pourras le voir en testant avec #container sans bordure ni largeur. Mais c'est un bug qui tombe bien puisque IE refuse de créer des contextes de formatage. Lecture : http://www.blog-and-blues.org/articles/Flo...es_de_formatage Bon courage

salut, En fonction du code que tu as donné la boite 1 ne peut que s'adapter au contenu de la boite 2 et ce quelque soit le navigateur !!! Si y tu a un problème et que tu souhaites une solution tu devrais commencer par rédiger ta question de manière plus précise et compréhensible merci

En fait c'est un vrai désastre... Heu ... ... Sinon ... ... ... ça existe un site dédié à la standardisation des hébergeurs ??? Parce que dans ce domaine ça ressemble vraiment à un freestyle qui confine au n'importe quoi.

Salut, 1. ce n'est pas possible 2. Ce n'est pas souhaitable Sinon je t'invite à ne pas suivre les suggestion se référant aux include conditionnelles de php. En elles mêmes elles ont un réel intérêt, mais cet intérêt n'a rien à voir avec ta question. Donc au mieux tu te retrouveras à faire n'importe quoi avec quelque chose dont tu ne comprendras rien. Je te conseille donc mon point 1 et d'en rester là.

Bonjour, je suis vraiment quelqu'un de têtu, J'ai testé ce code <?php $ftp_host='hote_ftp'; $ftp_login='nom_utilisateur'; $ftp_password='mot_de_passe'; $ftp = ftp_connect("$ftp_host"); // On prépare la connexion ftp_login($ftp,"$ftp_login","$ftp_password"); // On se connecte au serveur ftp_mkdir ($ftp,"pics_viewer/include"); // Création du dossier. (chemin depuis la racine du serveur) ftp_chmod ($ftp ,0777,"pics_viewer/include"); ftp_quit ($ftp); // On se déconnecte du serveur ?> Cela semble bien fonctionner... A votre avis cette solution a t'elle une chance d'être fiable ? Ou dois je m'attendre à de mauvaises surprises suivant les hébergeurs. Je sais que du point de vue de l'automatisation déjà il y a déjà une limite puisqu'il faut que la racine http corresponde à la racine FTP.

Bon, le simple fait que tu en parles signifie que cette situation est au moins possible suivant les hébergeurs. Je vais donc en tenir compte. Deux petites questions avant de m'éclipser . Cette situation est elle courante, notamment dans les hébergements payants ? . Peux tu me confirmer que si php avait pu changer les droits, mon code <?phpchmod('pics_viewer/include/',0777);?> aurait du fonctionner ? (l'adresse relative étant bonne je le jure !) merci

Bonjour, Voilà j'ai fait un petit script censé permettre la création d'un fichier config.php de paramètres de connexion à une base de données. <?phpif (empty($_POST['posted_param_sql'])) {?><h1>Paramètrer la connexion à la base de données</h1><p>Les éléments à fournir doivent être en votre possession par l'intermédiaire de votre hébergeur.</p><form method="post" action="#"><fieldset><legend>Informations à donner</legend> <input type="hidden" name="posted_param_sql" value="1" /><p><label for="hote_sql">Indiquer le nom de l'hôte de la base : </label><input type="text" name="hote_sql" id="hote_sql" /> (très souvent le nom est localhost, mais il est évidemment préférable de vous le faire confirmer)</p><p><label for="user_name">Indiquer votre nom d'utilisateur : </label><input type="text" name="user_name" id="user_name" /></p><p><label for="mdp">Indiquer votre mot de passe : </label><input type="text" name="mdp" id="mdp" /></p><p><label for="base_name">Indiquer le nom de la base : </label><input type="text" name="base_name" id="base_name" /></p> <p><input type="submit" value="Envoyer" /></p></fieldset></form><?php} else{$hote_sql=$_POST['hote_sql'];$user_name=$_POST['user_name'];$mdp=$_POST['mdp'];$base_name=$_POST['base_name'];/* On créé le fichier config.php*/$fichier_config=fopen("pics_viewer/include/config.php","w+"); /* On remplit ce fichier ligne par ligne*/fputs($fichier_config,"<?php \n");fputs($fichier_config,"$"."sql['hote'] = '".$hote_sql."'; \n");fputs($fichier_config,"$"."sql['user'] = '".$user_name."'; \n");fputs($fichier_config,"$"."sql['password'] = '".$mdp."'; \n");fputs($fichier_config,"$"."sql['base'] = '".$base_name."'; \n");fputs($fichier_config,"$"."sql['connection'] = _AT_mysql_connect("."$"."sql['hote'], "."$"."sql['user'], "."$"."sql['password']); \n");fputs($fichier_config,"mysql_select_db("."$"."sql['base'], "."$"."sql['connection']); \n");fputs($fichier_config,"?>");fclose($fichier_config);}?> Je souhaitais m'assurer d'avoir les droits élargis chmod 777 sur le dossier pics_viewer/include/ donc j'ai rajouter à mon code <?phpchmod('pics_viewer/include/',0777);?> J'ai testé ça avec un hébergement où les chmod sont par défaut à 755. Mais parfaitement modifiable manuellement via filezilla par exemple. Et bien rien ne se passe quand je veux automatiser cela avec mon script. Et le fichier pics_viewer/include/config.php ne se créé pas. Si quelqu'un voulait bien m'indiquer si j'ai fait une erreur quelque part ce serait sympa. Merci

tu exagères quand même un peu Dudu. L'affirmation "poing sur la table" est quand même de ton fait au départ donc on répond un peu sur le même mode Pour le reste je verrai demain parce que là je suis fatigué ce soir. Mais le sujet peut être très intéressant je trouve. Molly pose une question très ouverte et sybilline et n'y répond pas au fait. Pour <p> on ne t'a pas menti, simplement je pense que c'est une définition intuitive (en langage commun) de cette balise qui ne rend compte de rien de ses caractéristiques html. Une des conséquences savoureuses de cela c'est l'admonestation que se prend le plus souvent le newby de la part du gourou quand il a l'idée tellement logique et naturelle de vouloir mettre une liste dans un paragraphe et que bien que n'ayant rien compris ledit newby se met bien ça dans la tête que "il n'y a pas le droit" et peut à son tour aller jouer au gourou. Comme ça personne ne comprend rien mais les standards et la validation universelle sont sauvés... La belle affaire... Avec ma définition de cette balise, les choses sont beaucoup plus signifiantes je trouve.

Salut, Non ça ne peut pas convenir car display est une propriété css produisant des comportements. Ici il ne s'agit pas du tout de css ni de comportement mais de html et de type de balise. Et la règle c'est toute balise enfant direct de <body> doit être de type block. Or <code> est de type inline quelque soit le comportement que tu peux par ailleurs lui faire adopter d'un point de vue css. Là il y a beaucoup à dire... Rien du point de vue de la description/structuration html ne rend le choix de <pre> particulièrement pertinent ou recommandable, évidemment rien ne le rend non plus impertinent ou non recommandable. Et pour cause puisque rien dans cette balise n'apporte de signification particulière au contenu qu'elle inclue. Pourquoi ? Mais parce que c'est une balise de mise en page, une des seules qui soit restée dans la version strict du html (avec <br> par exemple). L'usage de <pre> repose donc sur un choix, éventuellement tout à fait légitime, de rendu et pas du tout sur un choix de structuration/description pertinente (pour éviter le terme de sémantique ) Concernant <p> maintenant. C'est sans doute une erreur que de vouloir trop attacher le sens de cette balise à sa traduction comme paragraphe. Du point de vue html <p> est la balise dont la seule signifation est d'arrêter la possibilité d'imbrication de balise block en étant elle même block. Utiliser <p> c'est dire : ici un contenu structuré comme block et ne justifiant pas d'être lui même scinder en nouvelles unités de type block. D'autres balises ont cette particularité, les <hn> par exemple, mais dans leur cas il s'agit bien d'une de leurs particularités. Pour <p> c'est carrémént sa signification... ... Et la seule. Je résume ce point en appelant <p> la balise block atomique. Tout ça pour dire que dans l'exemple que j'ai donné <p> convient parfaitement. Ce qui n'interdit évidemment pas l'usage d'autres balises suivant les contextes.

Salut, bon en partant de ton propre exemple, si tu veux présenter la ligne de code suivante Blabla Blah. alors la première chose à faire c'est d'éviter l'interprétation des couples de chevrons < et > comme indiquant une balise html c'est pour ça qu'on fait : Blabla Blah. Note : au passage et à tous. Une fois qu'on s'est occupé du chevron entrant via les caractères spéciaux c'est pas la peine de s' embêter avec les chevrons fermant... ceux ci ne peuvent pas être pris pour une fermeture de balise puisqu'il n'y a plus d'ouverture Suite pour karnabal : maintenant ta ligne de code va être décrite comme telle d'un point de vue html c'est à celà que sert la balise <code>. Donc on aura : <code> <p>Blabla Blah.</p> </code> pour finir une petite précaution quand même. La balise <code> est de type inline elle ne peut donc être notamment enfant direct de body et devrait dans cette configuration être placé dans une balise block (typiquement un <p>). Donc pour que tu perçoives au mieux comment ton fragment de code va être traité dans le document html je pense que ceci est le plus pertinent : <p> <code><p>Blabla Blah.</p></code> </p> En espérant t'avoir aidé, ++

bonjour, Il n'y a pas besoin de solution, si le contenu de l'élément stylé avec overflow:auto; n'est pas plus large que celui ci alors il n'y aura pas de scrollbar horizontale quelque soit le navigateur. Et s'il y une scrollbar horizontale alors c'est que le contenu est plus large que le conteneur. Tu devrais donc réexaminer ton code dans cette perspective. Le premier point à vérifier serait de voir s'il n'y a pas dans le contenu un élément à width:100%; qui par ailleurs aurait des marges latérales externes ou internes. C'est souvent ça qui provoque des problèmes difficiles à identifier au 1er coup d'oeil.

On est en "sans doctype", c'est à dire dans la panade. Pas grand chose en fait. Par contre une réflexion sur l'utilisation du strict au lieu du transitional est intéressante car celà acte l'obsolescence ou à tout le moins la dépréciation de certaines balises ou attributs. Même si une bonne évaluation des contraintes reste de mise dans le choix du doctype.

Non