Geckozone

Bonjour,

suite à un post dans le forum allemand, je viens de comprendre qu'il y a une incohérence dans certains outils de la barre de mise en forme. Désolé, ça me fait poster un message encore bien trop long ! Je crois que la mauvaise "qualité" du code de Nvu provient de là.

Dans KompoZer, j'ai scindé la barre de mise en forme en deux :

'Format toolbar 1' : structure HTML et classes (on oublie la punaise dans un premier temps)
'Format toolbar 2' : styles en ligne

La première fonctionne correctement, à une exception près : la liste des classes. Si le curseur est dans une cellule de tableau, la liste des classes affiche bien la classe du conteneur <td> (normal), mais si on modifie la classe avec cette liste, on modifie le parent <tr> (pas normal). Il y a peut-être d'autres cas similaires, si vous en trouvez ça serait bien de les référencer.

La deuxième barre d'outils est celle qui permet aux débutants de faire de si jolis codes HTML.

Code : Tout sélectionner

<div style="text-align: center;"><big style="color: rgb(255, 0, 0); font-family: Calisto MT;"><big><big><big><big><big><small><small><small><span style="font-weight: bold; color: rgb(0, 0, 0);"></span></small></small></small></big></big></big></big></big></big><big style="color: rgb(255, 0, 0); font-family: Calisto MT;"><big><big><big><big><big><small><small><small><span style="font-weight: bold; color: rgb(0, 0, 0);">QM2 &nbsp;das erste mal in Hamburg Gallery:</span></small></small></small></big></big></big></big></big></big><br>
</div>

Je pense remplacer <big> et par des attributs de style (font-size: xx-small, x-small, small, medium, large, x-large, xx-large). Ca ne permet pas d'agrandir ou de rétrécir un texte autant que les boutons <big> et , mais ça a l'avantage évident de supprimer la cascade de balises.
Qu'en pensez-vous ?

Restent les autres boutons, qui normalement ne font qu'appliquer des règles de style. Petite surprise (pour moi), on peut créer des imbriqués selon les sélections qu'on fait. Pas très malin mais passons.
Le principal problème que je vois sur ces outils, c'est que pour une même sélection, ils ne s'appliquent pas toujours au même élément. Exemple : quand on sélectionne une portion de texte brut dans <body>, le bouton de couleur d'avant-plan crée un autour de la sélection, alors que la couleur d'arrière-plan est appliqué au conteneur <body>.
Je vous laisse découvrir toutes les incohérences du même genre...

Evidemment, si on travaille "proprement" (= avec des feuilles de styles, et en définissant d'éventuels styles en ligne avec un clic droit dans la barre d'état), tout se passe bien. On sait exactement où les styles sont appliqués.
Pour ceux qui travaillent "autrement" (= à l'ancienne !), je me demande s'il ne faudrait pas reprendre cette deuxième barre d'outils, en fixant de façon plus rigoureuse l'élément sur lequel le style doit être appliqué :

si un élément est sélectionné (le bouton est "enfoncé" dans la barre des tâches) : le style doit être appliqué à l'élément (ça fonctionne déjà comme ça) ;
si une portion d'un même élément est sélectionnée : il faut créer un autour de la sélection (quelques corrections à apporter, donc) ;
si la sélection contient des éléments de type 'bloc' : il faut appliquer le style directement aux éléments 'blocs' et créer des blocs autour des autres éléments (tant pis !) ;
s'il n'y a aucune sélection : il faudrait appliquer le style à l'élément conteneur du curseur (nouveau comportement, mais très facile à développer).

Avec une nuance pour les quatre derniers boutons (alignement de texte), qui ne peuvent être appliqués qu'à des éléments de type "bloc" (p, h[n], div, ...).
Là encore, qu'en pensez-vous ?

Je ne sais pas si tout ça est très clair...

Kaze a écrit : Là encore, qu'en pensez-vous ?

On se sent petit. Vraiment tout petit.

Et ça correspond pile poil à toutes sortes de soucis évoqués depuis bien longtemps.
Mais, en gros, tu voudrais savoir qui est d'accord sur le fait que tu corriges tous les défauts cités?

Sinon

Kaze a écrit : si la sélection contient des éléments de type 'bloc' : il faut appliquer le style directement aux éléments 'blocs' et créer des blocs autour des autres éléments (tant pis !) ;

Je suppose que je comprends de travers.
Une sélection du type

Code : Tout sélectionner

bla bla bla
<p>blablabla<p>
bla bla bla

à laquelle à appliquerais l'action du bouton "Gras"
deviendrait

Code : Tout sélectionner

<span style="font-weight: bold;">bla bla bla</span>
<p style="font-weight: bold;">blablabla<p>
<span style="font-weight: bold;">bla bla bla</span>

au lieu de

Code : Tout sélectionner

<div style="font-weight: bold;">bla bla bla
<p>blablabla<p>
bla bla bla</div>

Enfin, tout ça, c'est pour répondre quelque chose...

Ymai a écrit :Et ça correspond pile poil à toutes sortes de soucis évoqués depuis bien longtemps.
Mais, en gros, tu voudrais savoir qui est d'accord sur le fait que tu corriges tous les défauts cités?

Je voudrais savoir si on est d'accord sur la liste des défauts à corriger (y en a-t'il d'autres ?) et sur la façon de les corriger.
Grosso modo, ça reviendrait à :

remplacer les boutons <big> et par une liste déroulante de tailles de texte ;
toujours définir un autour de la sélection pour appliquer un style de couleur ;
permettre d'utiliser ces boutons même quand il n'y a aucune sélection (je dirais même surtout quand il n'y a aucune sélection), en appliquant le style au premier conteneur.

Ca suppose donc de modifier sensiblement l'ergonomie de Nvu. Je n'utilise jamais cette barre de mise en forme, donc j'ai besoin d'un petit brainstorming pour y voir plus clair...

Ymai a écrit :
Kaze a écrit :si la sélection contient des éléments de type 'bloc' : il faut appliquer le style directement aux éléments 'blocs' et créer des blocs autour des autres éléments (tant pis !) ;
Je suppose que je comprends de travers.

Euh, non, c'est moi qui ai écrit des âneries : une sélection du type

Code : Tout sélectionner

bla bla bla
<p>blablabla</p>
bla bla bla

à laquelle à applique l'action du bouton "Gras" devient déjà

Code : Tout sélectionner

<span style="font-weight: bold;">bla bla bla</span>
<p style="font-weight: bold;">blablabla</p>
<span style="font-weight: bold;">bla bla bla</span>

et c'est très bien comme ça. Mais bizarrement, ces ne sont pas placés au même endroit quand selon que l'on clique sur un bouton de couleur ou sur le bouton "Gras". Il faut que j'affine tout ça.

En fait, les boutons Gras / Italique / Souligné fonctionnent de façon très satisfaisante. Il faudrait juste que les boutons de taille et de couleur fonctionnent de la même façon.

Kaze a écrit : Grosso modo, ça reviendrait à :
remplacer les boutons <big> et par une liste déroulante de tailles de texte ;

Je crois avoir lu quelque part que la définition de la taille des caractères ne devrait pas se faire en donnant une valeur précise (Alsacréations? OpenWeb?...). Ce qui gênerait ceux qui ont besoin d'agrandir le texte pour pouvoir le lire. Mais une liste de tailles est certainement un moindre mal par rapport à ce que nous connaissons.

[*]toujours définir un autour de la sélection pour appliquer un style de couleur ;

sauf s'il contient des éléments de type blocs

[*]permettre d'utiliser ces boutons même quand il n'y a aucune sélection (je dirais même surtout quand il n'y a aucune sélection), en appliquant le style au premier conteneur.[/list]

Comme c'est déjà le cas lorsque l'on applique une directive de style et qu'aucun élément n'est sélectionné. Ca surprend, au début. Mais la logique est imparable.

Ca suppose donc de modifier sensiblement l'ergonomie de Nvu. Je n'utilise jamais cette barre de mise en forme,

nor do I

En fait, les boutons Gras / Italique / Souligné fonctionnent de façon très satisfaisante. Il faudrait juste que les boutons de taille et de couleur fonctionnent de la même façon.

L'objectif est effectivement de supprimer ces <big> du code HTML, et si possible réduire le nombre de , pour que Nvu produise du code plus propre quand il est utilisé par des débutants. J'en ai marre de lire sur le forum Développement Web des trucs comme : "ton code fait par Nvu est illisible, refais tout avec un éditeur texte ou débrouille-toi tout seul".

Ymai a écrit :Je crois avoir lu quelque part que la définition de la taille des caractères ne devrait pas se faire en donnant une valeur précise (Alsacréations? OpenWeb?...). Ce qui gênerait ceux qui ont besoin d'agrandir le texte pour pouvoir le lire. Mais une liste de tailles est certainement un moindre mal par rapport à ce que nous connaissons.

J'envisage deux types possibles de liste déroulante pour les tailles de police :

font-size: xx-small, x-small, small, medium, large, x-large, xx-large ;
une liste modifiable avec la taille et l'unité ('em' par défaut) ; c'est déjà ce qu'il y a dans la fenêtre "Propriétés de texte"...

Après quelques tests, la deuxième solution s'avère bien plus simple à utiliser. Je peux supprimer les boutons A+/A-, ou faire en sorte qu'ils agissent sur la taille affichée dans la liste déroulante plutôt que d'insérer des <big> .

Ymai a écrit :Comme c'est déjà le cas lorsque l'on applique une directive de style et qu'aucun élément n'est sélectionné. Ca surprend, au début. Mais la logique est imparable.

Ce n'est clairement pas un usage très standard, mais ça ferait économiser des clics dans la barre d'état pour l'utilisateur avancé ; et pour visualiser des styles, on voit mieux ce qu'on fait quand la sélection n'est pas en surbrillance.
Reste à voir à l'usage si ça minimise le nombre de dans le code produit par des débutants...

Je vais mettre tout ça dans ma "todo-list", avec des boutons <div> et pour la barre d'outils, et peut-être une boite de propriétés spécifique aux <div> (pompée sur celle des 'cadres' d'OOo).

Kaze a écrit :Je peux supprimer les boutons A+/A-, ou faire en sorte qu'ils agissent sur la taille affichée dans la liste déroulante plutôt que d'insérer des <big> .

Quelle serait la difficulté de faire varier un pourcentage de la taille du texte (similaire au pourcentage de zoom dans Firefox avec Ctrl+roulette) avec ces boutons ?

Par exemple, on appuie une fois sur A+, ça fait un style "font-size: 120%". On appuie une seconde fois, ça le remplace par un font-size: 150%". Ou au contraire on appuie sur A-, et puisque le pourcentage vaut de nouveau 100 le style disparait.

(les chiffres sont donnés au hasard, je suppose qu'une échelle plus ou moins linéaire serait plus intéressante mais c'est surtout sur la faisabilité d'un fonctionnement sur ce principe que je pose la question

)

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Benoit a écrit :Quelle serait la difficulté de faire varier un pourcentage de la taille du texte (similaire au pourcentage de zoom dans Firefox avec Ctrl+roulette) avec ces boutons ?

Exactement la même que pour faire varier des "px" ou des "em"...
Vaut-il mieux utiliser "100%" ou "1em" comme valeur par défaut ? Peut-être faudrait-il faire une préférence pour l'unité de taille de police ?

Benoit a écrit :les chiffres sont donnés au hasard, je suppose qu'une échelle plus ou moins linéaire serait plus intéressante

Actuellement, les incréments de font-size dans l'éditeur CSS sont linéaires (unité par unité, ce qui est plus pertinent pour "px" que pour % ou em...) ; l'idée de reprendre l'échelle de l'affichage de Firefox me plait bien !

Kaze a écrit :Vaut-il mieux utiliser "100%" ou "1em" comme valeur par défaut ? Peut-être faudrait-il faire une préférence pour l'unité de taille de police ?

C'est strictement équivalent, ce sont des unités relatives à la taille courante. Je pense juste qu'un pourcentage est plus parlant pour la plupart des gens, mais je me trompe peut-être.

Kaze a écrit :Je ne sais pas si tout ça est très clair...

C'est très clair. Mais on peut encore l'éclaircir.
Virer la 2eme barre d'outils

> Garder uniquement

si un élément est sélectionné (le bouton est "enfoncé" dans la barre des tâches) : le style doit être appliqué à l'élément (ça fonctionne déjà comme ça) ;

Inclure sous forme de menu texte la 2eme barre d'outils pour et uniquement lors d'un clic droit sur un conteneur de la barre des conteneurs (body div etc...).

J'en profite pour replacer mon fake. Un menu si important pour une construction structuré d'une page html n'a pas ça place dans la barre d'état.

Pourquoi pas ajouter dans la 1ere barre d'outils un assistant de création de classe, en 2 page. 1ere page les explications + saisie du nom de la classe, 2eme page à la kazcades avec tous les onglets.

Sinon autre solution moins utopiste.
Bloc sélectionné ou pas de selection > Le style est appliqué au bloc.
Sélection d'une portion ou plusieurs blocs > griser la 2eme barre d'outils.

Deux semaines de sevrage d'internet, à bientot pour la 0.8

Do-IT a écrit :J'en profite pour replacer mon fake. Un menu si important pour une construction structuré d'une page html n'a pas ça place dans la barre d'état.

Je trouve au contraire que c'est un excellent endroit. Il ne s'agit pas d'une barre d'outils classique mais d'une notification contextuelle détaillant l'endroit où on se trouve, c'est parfait pour la barre d'état !

Geckozone

Incohérences de la barre d'outils (styles en ligne)

Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)

Re: Incohérences de la barre d'outils (styles en ligne)