Composer++ : après la scission

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
12
mai
2003
Mozilla
Après la découpe de Mozilla prévue pour le mois de juin (NdM : découpage Phoenix/Firebird/Browser et Minotaur/Thunderbird/Mailer prévu pour la 1.5), la partie Composer semble avoir été reprise par Daniel Glazman qui propose des premiers binaires pour Windows .
Au menu, support du positionnement absolu, meilleur redimensionnement (image, table, ...), "snap to grid" et la possibilité d'éditer des cellules de tableau "en ligne".

Je profite de cette annonce pour poser quelques questions.
Personnellement, je pense qu'un éditeur WYSIWYG est très intéressant, au moins pour faire le layout des pages. Après, j'ai très souvent tendance à passer par de l'automatisation (php et ses include, templates de quanta, wml, ...).
Quels sont les outils que vous utilisez pour créer le layout de vos pages? et ensuite, passez-vous toujours à (emacs|nedit|quanta|vi|...) ou continuez-vous avec un éditeur plus graphique?

Il m'arrive aussi de devoir expliquer "l'Internet" à des enfants (11-16 ans) et les plus jeunes n'ont pas trop envie de passer par le html pour faire leurs pages, hors, pas moyen de s'en passer pour des formulaires, des images à zones clicables, ...
Avez-vous déjà rencontré ce genre de problèmes? Que conseilleriez-vous pour leur apprentissage sous un "environnement éthique" ?

Aller plus loin

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 5.

    En ce qui me concerne, je fais le layout sur papier, une première maquette avec GIMP (quitte à faire du WYSIWYG, autant se donner le plus de liberté possible) et ensuite, je passe directement à Emacs ou vi pour rédiger le code HTML et CSS qui correspond à ce que j'ai dessiné.

    • [^] # Re: Composer++ : après la scission

      Posté par  . Évalué à 1.

      Même combat, et c'est la technique utilisée par tous les webdesigner avec qui j'ai travaillé.

    • [^] # Re: Composer++ : après la scission

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Le problème de cette technique, utilisé par bon nombre de web designer, est que cela conduit à des sites assez figé, et finalement pas adaptable. (du style: page en 800 de large, pas plus, pas moins).
      Ce qui est regretable car le web, ce n'est pas un plaquette cartonnée dont les dimensions sont déjà connus.
      Non, le web, c'est un media adaptable, dont le contenu peut etre vu de differentes façon, avec differents outils, dont la surface de lecture varie enormement.
      à mediter : http://www.pompage.net/pompe/tao/(...)

      Une meilleur approche, pour la conception de page web, serait je pense, dans un premier temps, d'avoir certes un premier jet sur une feuille de papier sans se preoccuper du dimensionnement, histoire de voir la position des elements par rapport aux autres. Mais ensuite de passer le plus rapidement possible au html pour structurer les pages, et aux css pour le positionnement et la presentation, Gimp ne servant qu'à creer les images (ce n'est pas un logiciel de PAO, et de plus la PAO telles qu'on la connait pour realiser des documents papiers n'est pas du tout adapter pour faire du web)

      • [^] # Re: Composer++ : après la scission

        Posté par  . Évalué à 5.

        Pas tout à fait d'accord ; )

        Lorsque tu conçois une maquette avec un logiciel de graphisme, rien ne t'oblige à fixer de manière statique les tailles et positions des éléments: par exemple, je n'utilise quasiment jamais de fenêtre de 800 pixels de large, mais plutôt de plus petites fenêtres (500 pixels de large, ou moins) lorsque j'essaie de concevoir une maquette ou ses sous-ensembles. La maquette me sert avant tout à pouvoir choisir un jeu de polices/couleurs/marges/décorations qui soit conforme à ce que j'attends, mais lors du passage de l'image au HTML/CSS, j'exprime ces contraintes en termes d'éléments aux marges et tailles relatives, et non en termes de tableaux imbriqués aux largeurs de cases fixes.

        En fait, ça se passe en cinq phases:

        * expression de la structure logique du site
        * en fonction de cette structure logique, maquette dessinée (papier ou tablette graphique) pour fixer la présentation
        * en fonction de la maquette papier, maquettes dessinées finies, permettant d'avoir une représentation du modèle à utiliser
        * expression de la structure logique du site en HTML
        * expression de la structure visuelle du site en CSS, à partir des contraintes tirées de la maquette dessinée finie.

        Le problème du passage direct maquette papier -> CSS (c'est comme ça que je faisais avant), c'est que taper directement le code CSS ne permet pas (ou du moins, ne _me_ permet pas, peut-être certains sont plus doués) de savoir, par exemple:

        Est-ce que les titres en #A03030 s'accordent bien avec les sous-titres en #602020 ?
        Est-ce que, avec un titre en font-size: 120%, les sous-titres en font-size: 80% n'ont pas l'air trop petits?
        De quelle taille fixer les marges de telle boîte, pour que le texte ne soit pas trop collé au bord, ou trop éloigné?
        Est-il vraiment judicieux d'utiliser tel graphisme, telle icône, telle décoration, à cet endroit? Et comment la positionner?

        Bien sûr, il est parfaitement possible de procéder à tâtons avec les CSS (et parfois, dans le cas d'une modification mineure du site, ça va bien plus vite). Mais, quand il s'agit de décider de l'allure générale, complète, il me semble en général plus efficace d'avoir, sous les yeux, une page représentant ce vers quoi on souhaite tendre. En tous cas, et en ce qui me concerne, c'est toujours comme ça que j'ai obtenu les meilleurs rendus.

        • [^] # Re: Composer++ : après la scission

          Posté par  . Évalué à 2.

          J'approuve aussi.

          Je crééer une 'planchette' avec Gimp,poposhop,feuworks,etc.. ce qui me permet d'avoir un visuel de référence de ce que je vais reproduire en (x)html+css.

          Et ca ne m'empêche aucunement de faire des sites accessibles et aux normes.

          D'ailleurs y'a qu'a voir la charte de pompage.net , ca m'étonnerait que ca soit tout fait à l'arrache sous éditeur texte, comparer à l'ancienne qui pouvait le laisser penser =)

        • [^] # Re: Composer++ : après la scission

          Posté par  (site web personnel) . Évalué à 3.

          Moi j'ai une démarche un peu inverse de tout ce qui a été écrit au dessus.

          Je m'occupe d'abord du contenu avec un découpage logique.

          Une fois que je sais ce qu'il y a dans mon site je m'ocupe du positionnement puis seulement du graphisme. Cette démarche n'etait pas vraiment possible avec les table, avec les CSS c'est désormais possible facilement sans refaire deux fois le développement.

          En plus cela permet de facilement proposer plusieurs fauilles de style avec des rendus alternatifs tant en terme de couleur/image que de positionement.

          Une petite remarque en passant, le positionnement absolue c'est bien, mais les recommandations du WC vont plutot vers un positionnement float (flotant en français ? our relatif...).

          Pour la partie graphique je n'utilise aucun outil graphique, la représentation que je peux m'en faire est sovent beaucoup plus fiable.

          • [^] # Re: Composer++ : après la scission

            Posté par  . Évalué à 2.

            Je trouve que positionnement et graphisme vont plutôt ensemble; d'ailleurs, comme tu le dis, si ta page est bien conçue, changer de feuille de style te permettra de changer à la fois le positionnement et le graphisme du site.

            Par exemple, si tu crées un site qui soit un peu « design », quel qu'il soit, il est bon d'en produire une version alternative, avec de grosses polices, et un contraste fort... Mais si les polices sont de grande taille (ou destinées à être agrandies par le visiteur), le site sera plus accessible si, par exemple les boîtes qui étaient flottantes dans le style « de base » sont positionnées de manière linéaire (pour éviter le débordement horizontal)... C'est pour ça que je pense que celui qui conçoit le « layout » du site (puisqu'il était question de layout, ici, à la base) doit prendre en compte simultanément les aspects « positionnement » et « graphisme »; et à ce titre, je trouve que disposer d'un dessin du site peut largement aider à se faire une idée de ce à quoi il devra ressembler.

            Maintenant, libre à chacun d'utiliser les moyens qu'il veut... Tant que le site est accessible et conçu selon les standards ; )

    • [^] # Re: Composer++ : après la scission

      Posté par  . Évalué à 1.

      Pas moi.

      Je concoit d'abord la structure, les parties, (un menu, puis un paragraphe d'info, puis le texte principal, puis le pied de page...) et je met tout dans des . Ca me fait deja un fichier HTML avec une gueule vraiment tres basique.

      Apres en fonction de la structure je fait une premiere maquette "placement" sur papier et j'ecris la feuille de style qui va avec.

      Pour finir, je colle une deuxieme feuille de style avec les couleurs, les polices, les tailles, les marges, les papiers peints...

      Ca me permet ensuite de pouvoir facilement changer la maquette.

    • [^] # Re: Composer++ : après la scission

      Posté par  . Évalué à 1.

      pour les maj , rsync est utile (en console)

      oui oui je sais ,c est une commande r* , donc a bannir et maudire :)

      mais :

      rsync -v -rlptD --delete -e ssh ~/Sites/dossier/ login@10.0.0.10:~/dossier

      permet de se connecter via ssh, supprime les fichiers qui ont été effacé en local et met à jour.

      ca marche bien, c rapide. fourni dans tous les unix/linux.

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 2.

    Mes enfants utilisent Bluefish pour faire leur site. Le HTML ne les rebute pas (avec mon support). Quant à moi, j'utilise emacs ou jext, puis Cocoon !

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 1.

    Personellement j' évite les outils wysiwyg html (j'ai été traumatisé à jamais apres avoir vu le code frontpage ;) ) mais j'utilise Quanta+ qui est un excellent environnement de développement web, pas encore complet mais il y a un gros potentiel et le projet est tres actif.

    Sinon pour répondre à la question, j'ai essayé Ginf est très simple et surement adapté pour de l'apprentissage de création de pages html.
    Homepage : http://www.symonds.net/~deep/stuff/vtu/ginf/index.php(...)
    Screenshot : http://www.symonds.net/~deep/stuff/vtu/ginf/ginf-1.01.png(...)

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 2.

    Moi je fais directement le PHP, avec la documentation de html4 à portée de click, puis je regarde le résultat sur mon serveur apache local et je retouche éventuellement.

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 4.

    Moi j'utilise Frontpage avec Wine, et j'édite ensuite avec NotePad. Eventuellement je retouche avec OpenOffice (ou Word si la barre de progression n'avance pas assez vite).

    Quoiqu'il en soit, il devient urgent de voire les mêmes outils de qualité qu'on trouve sous Windows arriver sur notre système. Et il faut arréter de jouer les intaigristes : si nous voulons des outils professionnels, nous seront contraints de payer des logiciels propriétaires. J'attend avec impatience l'éditeur WYSIWYG intégré à Yast de la prochaine Suse.

    Ouvrons nos porte-monnaie et nous pourrons fermer nos sources.


    (C'est peut-être un peu trollons comme commentaire)

    Etienne

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 4.

    Moi à onze ans je programmais en assembleur sur des cartes perforées, alors ces sales gosses vont pas râler parce qu'ils doivent faire du HTML.
    Pour ma part, j'utilise du Perl pour générer les pages statiques. C'est quand même à mon avis le langage le plus simple pour ce genre de choses.
    Comme je fais rarement des designs complexes, je fais ça directement en HTML+CSS. Mais pour un ou deux sites je suis avant passé par un logiciel de dessin pour faire la mise en page (je dirai pas le nom du logiciel parce que c'est pas Gimp, hihi).

    Jeu : quelque part dans ce message il y a un mensonge, à vous de deviner où

    • [^] # Re: Composer++ : après la scission

      Posté par  . Évalué à 1.

      > Moi à onze ans je programmais en assembleur sur des cartes perforées,

      Trop facile !

    • [^] # Re: Composer++ : après la scission

      Posté par  (site web personnel) . Évalué à 1.

      Je te plussoie volontier, d'ailleurs, simple coïncidence c'est la méthode que j'utilise aussi (sauf que j'ai de plus en plus tendance à utiliser systématiquement ruby (le plaisir de faire des blocs et de laisser reposer cette pauvre touche ';' sans doute)

      Mais je pense qu'importe la méthode, que chacun fasse comme il lui plait, l'important amha est d'avoir au final des pages html légères respectant les normes. Mon seul essai d'un wysiwyg étant le composer de Nestcape 3 il me semble et il ne m'avait pas laissé un souvenir fameux.

      Réponse au jeu : comme Monsieur Jourdain, tu faisais pas de l'assembleur mais du GOTO++ sans t'en appercevoir.

    • [^] # Re: Composer++ : après la scission

      Posté par  . Évalué à 2.

      Jeu : quelque part dans ce message il y a un mensonge, à vous de deviner où
      Il est là:
      Pour ma part, j'utilise du Perl pour générer les pages statiques. C'est quand même à mon avis le langage le plus simple pour ce genre de choses.
      Qu'est ce qu'on gagne ? FrontPage Millenium Edtiion AdvancedPowerXPPro2005 BSOD Express Retail Cracké ?

  • # Re: Composer++ : après la scission

    Posté par  (site web personnel) . Évalué à 4.

    Un lien vers le blog de daniel glazman aurait ete pas mal, vu tout ce qu'on y apprend (ses idees sur le futur de composer, comment zdnet a raconte nimporte quoi apres l'annonce de la reprise par lui de composer, et surtout le fait que la version linux pour composer++ arrive :)

    le lien : http://daniel.glazman.free.fr/weblog/(...)

  • # C'est pour quand le XHTML

    Posté par  . Évalué à 3.

    Composer continu, c'est une bonne nouvelle.

    Ainsi, Mozilla s'installe comme un vrai suite internet (par comparaison aux suites bureautique). C'est un positionnement original et réellement concurrentiel de la suite bureautique de chez MS.

    Autre bonne nouvelle, Composer supportera XHTML. La question est quand, car aujourd'hui, le Composer massacrait le XHTML :-(

    Si au moins il y avait une première étape "XHTML friendly" où on ait le choix entre la transformation en HTML 4 et l'édition texte ce serait sympa (déjà demandé dans bugzilla).

    Pour ce qui est du développement de page, personnellement plus les pages sont simple, mieux c'est. Il faut dire que j'ai une utilisation utilisataire des pages web.

    Mon code HTML doit être le plus pur possible, tout ce qui est présentation est fait par des CSS externes, ceci permet d'avoir aisément la cohérence de présentation sur plusieurs pages.
    La première chose dont je m'assure c'est que ma page se redimensionne correctement, car c'est bien quelque chose que je supporte par : optimisé pour 800x600 ou 1024x768.
    Ensuite, je fait un test pour vérifier que je n'ai pas fait de grosse erreurs d'accessibilité (objectif AA en accessibilté, je sais ce n'est pas assez, mais je fais souvent des galeries de photos).

    • [^] # Re: C'est pour quand le XHTML

      Posté par  . Évalué à 2.

      >Ainsi, Mozilla s'installe comme un vrai suite internet (par comparaison aux suites bureautique). C'est un positionnement original et réellement concurrentiel de la suite bureautique de chez MS.

      Il manque un ftp.
      J'aimerai bien un FileZilla pour Linux...

      • [^] # Re: C'est pour quand le XHTML

        Posté par  . Évalué à 1.

        Ancien utilisateur de FileZilla, j'aurai cru en trouver un similaire sous linux mais le projets qui s'en rapproche le plus c'est gftp, Kbear étant un peu éloigné d'un client Ftp habituel.

        Pour un client Ftp intégré dans mozilla, il faut faire un tour sur mozdev.org, quelques projets discutent la dessus ou en préparent déja un (notamment un projet de CMS de ne je sais plus quel nom..), depuis quelques mois je ne sais plus suivis l'affaire.

        • [^] # Re: C'est pour quand le XHTML

          Posté par  (site web personnel) . Évalué à 1.

          Et konqueror ?

          J'ouvre deux fenêtres, l'une sur ftp://monlogin@ftp.monsite.org,(...) l'autre locale.
          Une autre fenêtre me demande le mot de passe et se referme.
          Il suffit ensuite de faire des drag and drop entre ces deux fenètres. Ça fonctionne dans les deux sens avec des fichiers et des répertoires.
          On peut copier, déplacer, changer les droits, ouvrir...
          J'ai utilisé autrefois Igloo (quand c'était libre), gftp, et surtout la ligne de commande (très souvent) avec ftp et ncftp. Mais rien n'est plus simple et ergonomique que konqueror. Je pense qu'on peut le prendre comme modèle si l'on tient absolument à le refaire sous GTK.

          J'utilise ce mode de transfert depuis au moins trois ans avec une très grande satisfaction avec des OS divers sauf dans un seul cas :
          Ça ne fonctionne pas de façon très fiable avec wanadoo. On ne peut pas recopier un répertoire et la connexion se ferme sporadiquement. Je m'en suis expliqué sur http://perso.wanadoo.fr/jarillon/(...) et je donne surtout la façon de résoudre le problème.

          • [^] # Re: C'est pour quand le XHTML

            Posté par  . Évalué à 1.

            Ah oui, très bien, on rajoute une frame dans la fenetre pour le local, on met le coté ftp en liste, et ca marche nickel ! Merci beaucoup.

      • [^] # Re: C'est pour quand le XHTML

        Posté par  (site web personnel) . Évalué à 1.

        bof...
        honetement, ncftp, lftp, yafc, ou encore zftp (pour le puriste de zsh :) ) pour le ftp ca suffit très largement.

        Les clients autant les mails, les browser web (quoi que links -g en FrameBuffer déchire) le graphique apporte un réel intéret, mais pour le ftp la je vois pas...

        • [^] # Re: C'est pour quand le XHTML

          Posté par  . Évalué à 1.

          pour les gros uploads je trouve ca quand meme bien pratique. Un ptit drag'n'drop et voilà :)
          Actuellement j'utilise lftp mais je ne connais pas bien les commandes un poil avancées, par exemple pour envoyer un répertoire avec tout plein de chose dedans.
          Message du haut:
          J'ai trouvé tranzilla qui a l'air intéressant
          http://tranzilla.mozdev.org/index.html(...)
          Mais apparement ca vient juste de commencer. Wait and See...

          • [^] # Re: C'est pour quand le XHTML

            Posté par  . Évalué à 1.

            Transilla c'est un peu mort, il semblerait du au fait que le projet maitre 'Aphrodite' avance à petit pas.

            Par contre en attendant, tu peut regarder :
            http://bazil.mozdev.org/(...)

            Mais c'est un peu loin du client ftp de base.

          • [^] # Re: C'est pour quand le XHTML

            Posté par  . Évalué à 1.

            avec lftp, tu tape "mirror tonrepertoire" !!!

            Tu peux même le mettre en tâche de fond avec "&", lancer d'autres transfert ou sortir.

            L'option -c du get, mget et mirror permet de continuer un chargement...

            Moi, j'aime bien lftp :o)

        • [^] # Re: C'est pour quand le XHTML

          Posté par  . Évalué à 2.

          Je suis peut être un peu difficile mais le ftp en ligne de commande quand je fais des mises à jour de sites ca m'énerve mais ca n'engage que moi =)

          • [^] # Re: C'est pour quand le XHTML

            Posté par  (site web personnel) . Évalué à 1.

            Je suis d'acord avec toi. c'est le plus souvent vrai. Mais parfois un mget ou mput s'avère plus efficace. J'aime bien les deux façons de procéder que je choisis selon le cas à traiter.

            • [^] # Re: C'est pour quand le XHTML

              Posté par  . Évalué à 1.

              Oui, faudrait peut être que je profite un peu de la puissance du terminal pour certaines taches balots que je fais encore à la main.

              Je note 'mget' et 'mput' pour une future lecture de man, merci ;)

          • [^] # Re: C'est pour quand le XHTML

            Posté par  . Évalué à 1.

            Euh moi ce serait plutot les clients FTP intégrés aux browser qui m'énervent : quand on fait des gros download, genre image iso en général ils ne sont pas fichus de faire de la reprise sur erreur correctement: vive ncftp!

  • # Re: Composer++ : après la scission

    Posté par  (site web personnel) . Évalué à 1.

    Perso je fais mes pages avec Emacs (du jsp pour le boulot).

    Par contre, j'aimerais avoir un bidule WYSIWYG dans lequel je collerais le HTML généré par mes jsp et qui me permettrait d'éditer graphiquement un fichier CSS comme il faut.

    • [^] # Re: Composer++ : après la scission

      Posté par  . Évalué à 1.

      Ben justement, tu as CasCadeS, developpe par Galzman et qui sera tout naturellement integre a Composer.

      Bon, pour le moment c'est pas si graphique que ca puisque c'est des boites de dialogues pour editer les valeurs ! On est pas tres loin de l'edition directe du css.

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 2.

    Pour moi c'est éditeur de texte et css. Je pense à ce que je voudrais montrer, je dépouille le concept, et j'ouvre un tag <table> pour tout assembler avec à chaque <td> ou <tr> le style qui correspond.
    cela donne des pages genre
    <table>
    <tr class="entete" >
    <td>
    include
    </td> <td>
    include
    </td>
    <tr>
    <tr class="ligne" >
    <td>
    include
    </td> <td>
    include
    </td>
    <tr>
    <table>

    Et pour l'include, pareil:
    <table>
    <tr class="ligne">
    <td>
    <?php bla bla ?> ou <%bean:write name="titi"property="toto" />
    </td> <td>
    <?php bla bla ?> ou <%bean:write name="titi"property="toto" />
    </td>
    <tr>
    <table>

    En revanche: pour lier les couleurs et pour assembler les éléments que cela permet d'afficher dans des includes, je suis une tanche

    Dans mon taf je travaille plutôt dans l'autre sens: je travaille avec un (excellent) graphiste (Rénaldo !), , il m'envoie sa page faite (avec GoLive sur Mac) et je mets le dynamique - en nettoyant à fond! Il n'arrive pas réutiliser les feuilles de style que je lui ai fourni après avoir dépouillé son code. Mais c'est vrai que GoLive est pas très intuitif en ce qui concerne les styles. Si quelqu'un a un outil pour graphiste pour manipuler artistiquement les feuilles de style,
    Pour moi de toutes façons, c'est lui le chef ! D'abord, je m'entends très bien avec les graphistes!
    Et surtout seul compte le rendu. Parce que seul compte ce que créent les graphistes, nous, si on déconne, on peut toujours faire un SAV, mais un site moche ou illisible, et pas un bug ne va apparaître parce que personne ne va rester sur le site.

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 2.

    utilisation de xemacs avec les modes xml et la gestion des DTD en ce qui me concerne

    indentation automatique, coloration syntaxique _intelligente_ et les menux de xemacs ne propose que les tags VALIDES.

    bref c'est très bien

    (oui j'utilise xemacs, c'est surement tout aussi vrai avec emacs)

    je n'ai pas trouvè d'éditeurs wysywyg satisfaisant et je n'aime guère ce principe. (le xhtml est structuré, pas un flou graphique delirant comme trop d'outils wysywyg encourage à pondre)
    Aucun ne semble permettre une édition parrallele de l'arbre XML (ben vi, xhtml c du xml ) avec des classes CSS de manière conviviale et rapide . et avoir un visu impeccable.

    bref, j'attends encore une fusion d'un outil a la emacs/xml-mode combiné avec un traitement de texte hierarchique. le tout bien fait et agréable à utiliser (le moins possible de boites de dialogues bloquante comme les "styles" dans word et autres softs mal fichus)

  • # Re: Composer++ : après la scission

    Posté par  . Évalué à 2.

    > «Il m'arrive aussi de devoir expliquer "l'Internet" à des enfants (11-16 ans) et les plus jeunes n'ont pas trop envie de passer par le html pour faire leurs pages, hors, pas moyen de s'en passer pour des formulaires, des images à zones clicables, ... »

    Si jamais un jour j'avais l'occasion d'enseigner ce genre de choses (je suis prof de maths, mais qui sait ce que l'avenir nous réserve), je crois que je les ferais bosser en xhtml (genre 1.0 strict, 1.1 ou supérieur, parce que la séparation de la forme et du fond est consommé), histoire qu'ils se concentrent uniquement sur la structure. Ensuite, plusieurs feuilles de styles prédéfinis leur permettrait de constater par la pratique que leur page peut s'afficher de manières fort différentes, alors que le contenu n'a pas changé.
    Plus tard, le contenu développé, il serait toujours possible de passer de l'autre côté et de faire découvrir les feuilles de style pour faire quelquechose plus à leur goût.

    Qu'en pensez-vous ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.