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
- Composer++ (1 clic)
- L'annonce sur mozillazine (1 clic)
- mozillazine-fr (1 clic)
- Mozilla sur DLFP (0 clic)
# Re: Composer++ : après la scission
Posté par Gruik Man . Évalué à 5.
[^] # Re: Composer++ : après la scission
Posté par David FORT . Évalué à 1.
[^] # Re: Composer++ : après la scission
Posté par huhuhu . Évalué à 0.
[-20%]
[^] # Re: Composer++ : après la scission
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 2.
houlà, mon karma va prendre cher
[^] # Re: Composer++ : après la scission
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
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 Gruik Man . Évalué à 5.
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 david thenon . Évalué à 2.
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 Marcopolo (site web personnel) . Évalué à 3.
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 Gruik Man . Évalué à 2.
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 Erwan . Évalué à 1.
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.
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 Alain Bret . Évalué à 2.
# Re: Composer++ : après la scission
Posté par cedricv . Évalué à 1.
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 imr . Évalué à 4.
http://dot.kde.org/1050969840/(...)
# Re: Composer++ : après la scission
Posté par wismerhill . Évalué à 2.
# Re: Composer++ : après la scission
Posté par Étienne . Évalué à 4.
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 cedricv . Évalué à 2.
trop gros, passera pas...
[^] # Re: Composer++ : après la scission
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[troll detected]
Ouai c'est sur, tout ces outils sont réputés pour produire du code light, permettant de manier les CSS avec aisance, et qui plus est, produit du code valide, conforme aux standards du web.
lol
http://openweb.eu.org(...)
[^] # Re: Composer++ : après la scission
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 1.
ouf... ce fut long
[^] # Re: Composer++ : après la scission
Posté par MrTout (site web personnel) . Évalué à 1.
# Re: Composer++ : après la scission
Posté par Sidoine de Wispelaere . Évalué à 4.
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 NebuchadnezzaR . Évalué à 1.
Trop facile !
[^] # Re: Composer++ : après la scission
Posté par MrTout (site web personnel) . Évalué à 1.
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 huhuhu . Évalué à 2.
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 Gabriel . Évalué à 2.
(http://www.thinkgeek.com/tshirts/coder/57f0/(...))
[^] # Re: Composer++ : après la scission
Posté par MrTout (site web personnel) . Évalué à 2.
# Re: Composer++ : après la scission
Posté par Mathieu Pillard (site web personnel) . Évalué à 4.
le lien : http://daniel.glazman.free.fr/weblog/(...)
# C'est pour quand le XHTML
Posté par Mes Zigues . Évalué à 3.
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 huhuhu . Évalué à 2.
Il manque un ftp.
J'aimerai bien un FileZilla pour Linux...
[^] # Re: C'est pour quand le XHTML
Posté par david thenon . Évalué à 1.
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 Pierre Jarillon (site web personnel) . Évalué à 1.
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 huhuhu . Évalué à 1.
[^] # Re: C'est pour quand le XHTML
Posté par Bapt (site web personnel) . Évalué à 1.
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 huhuhu . Évalué à 1.
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 david thenon . Évalué à 1.
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 huhuhu . Évalué à 1.
[^] # Re: C'est pour quand le XHTML
Posté par Gilles Mocellin . Évalué à 1.
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 david thenon . Évalué à 2.
[^] # Re: C'est pour quand le XHTML
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: C'est pour quand le XHTML
Posté par david thenon . Évalué à 1.
Je note 'mget' et 'mput' pour une future lecture de man, merci ;)
[^] # Re: C'est pour quand le XHTML
Posté par reno . Évalué à 1.
# Re: Composer++ : après la scission
Posté par Wawet76 . Évalué à 1.
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 Erwan . Évalué à 1.
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 Gabriel . Évalué à 2.
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 Gruik Man . Évalué à 2.
# Re: Composer++ : après la scission
Posté par - - . Évalué à 2.
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 JSL . Évalué à 2.
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.