Pour resituer le débat : l’intérêt de « docker » l’éditeur CSS serait essentiellement (uniquement ?) de pouvoir faire défiler la page html tout en ayant l’éditeur CSS sous les yeux. La difficulté est que l’interface graphique de l’éditeur CSS repose sur des objets de taille fixe : l’éditeur CSS a donc besoin (actuellement) d’une largeur et d’une hauteur minimales, en-dessous desquelles il n’est pas utilisable.
Que l’on veuille « docker » l’éditeur CSS ou rendre la boite de dialogue CaScadeS redimensionnable, le problème est le même : il faut que l’éditeur CSS soit utilisable quelle que soit la taille de la boite. Je considère qu’une barre de défilement est acceptable, mais que deux barres de défilement sont rédhibitoires.
Pour les extensions:
En quoi consiste cette "adaptation" ?
(Une description très sommaire pour un gars (comme moi) qui s'est arrêter à l'assembleur 8bit sera la bien venue)
Les extensions Firefox utilisent des éléments de l’interface de Firefox comme « points d’ancrage ». Parfois (souvent), ces extensions réutilisent du code Firefox.
Pour adapter une extension Firefox à KompoZer il faut donc « ancrer » les éléments d’interface de l’extension sur l’interface de KompoZer, et parfois reprendre une bonne partie du code pour qu’il ne repose plus sur du code Firefox.
Concrètement, c’est le cauchemar avec Firebug mais ça s’envisage avec FireFTP.
Ce placement [vertical] de l'éditeur css me parait privilégier l'espace vertical de l'écran au profit d'une page html. Si le dock se transforme en éditeur css, la place pour l'affichage de la page diminue.
À méditer. Je ne suis pas fana de l’idée d’avoir un éditeur CSS wysiwyg dans le panneau latéral, car ça prend beaucoup de place et ça ne serait exploitable qu’à partir d’une certaine largeur minimum : il faudrait probablement redimensionner le panneau latéral chaque fois qu’on passe du gestionnaire de site au panneau CSS.
Par ailleurs, je ne trouve pas très pratique d’avoir à cliquer en haut pour sélectionner une règle et en bas pour la modifier : je préfère avoir l’arbre des règles CSS et les panneaux de propriétés côte-à-côte.
Inversement, je trouve que l’affichage actuel est pratique dans la mesure où il ne montre que les règles définies pour l’élément courant — reste à implémenter une façon d’éditer ces règles de styles, soit directement dans l’arbre CSS (tableau modifiable), soit via un double-clic qui ferait apparaître l’éditeur CSS wysiwyg (boite de dialogue ou dock).
Dans l’hypothèse où on garde une boite de dialogue pour modifier les règles de style, on aurait une boite de dialogue plus petite car on n’aurait plus besoin d’afficher l’arbre CSS dans cette boite de dialogue — un peu comme pour l’édition des styles internes.
Dans l’hypothèse d’un dock CSS horizontal, il est nécessaire qu’il soit utilisable avec une hauteur faible pour ne pas trop amputer l’affichage de la page html. Et là, je n’ai pas de solution simple à proposer.
Ça n’est que mon avis, j’essaye ici d’alimenter le brainstorming, pas de fermer des portes.
Je reconnais bien volontiers qu’un éditeur CSS « docké » n’est pas simple à dessiner. Peut-être faut-il en conclure que c’est une mauvaise idée ? Ou que le panneau latéral suffit pour des petits ajustements (sans gêner l’affichage de la page html), et que recourir à une boite de dialogue pour des modifications plus complexes serait un compromis acceptable ? D’ailleurs, je crois que les deux éditeurs ouèbe de référence (DreamWeaver et Expression Web) recourent à des boites de dialogue, et non un dock, pour éditer le CSS en wysiwyg.
Pour la fenêtre correspondant à boite ou box, je pensais à 4 curseurs +/- autour de 3 boutons Margins, Paddings, Offsets.
+1, j’irais même un peu plus loin dans cette idée en reprenant un aspect que j’aime bien dans Firebug :
Cette présentation a le mérite de montrer clairement où se situent les « margin » et « padding » par rapport à la bordure. Par contre, ça prend beaucoup de place — trop pour le panneau latéral, à mon humble avis.
Par ailleurs, je trouverais sympa d’avoir la checkbox « all four sides use same style » pour les margin / padding. Du coup, je serais tenté de vouloir définir la bordure dans la même interface : ça risque d’être plus lourd visuellement, mais ça ferait une boite de propriétés toute trouvée pour les <div>.
