Enterprise: Éditeur : la configuration des boutons de titre ne fonctionne pas

Cela peut également être reproduit dans ids-enterprise. Il est donc probable que le problème soit là.

1. Allez sur http://localhost :4000/components/editor/example-customize-buttons.html
2. Ce code est configuré pour afficher h1 et h2 et non h3 et h4 mais cela ne prend aucun effet https://github.com/infor-design/enterprise/blob/master/app/views/components/editor/example-customize -buttons.html#L21

Attendez-vous à ce que vous puissiez définir les boutons sur h1-h6 comme vous le souhaitez (pour correspondre à la structure de la page).

@Fruko @tmcconechy , je pense que ce qu'il y a dans le code source ici est un peu abusif.

En regardant la source , header1 et header2 ne sont pas nécessairement mappés respectivement à une balise H1/H2. Ils sont mappés à H3/H4. Le composant Editor a toujours été ainsi, et je crois que le raisonnement était qu'au niveau de l'application, les H1/H2 ne sont pas quelque chose de "modifiable" dans le sens où un utilisateur utilisant ce composant pourrait simplement en ajouter un à le contenu.

De toute évidence, les exigences/besoins ont changé depuis notre ensemble de conceptions d'origine, mais ce problème n'est pas très simple pour moi. C'est un peu une amélioration/ajout de fonctionnalité. Quelques questions:

• Devrions-nous intégrer la prise en charge de tous les niveaux d'en-tête ?
• Comment gérons-nous gracieusement les changements de rupture potentiels autour de cela (changer header1/2 en 3/4, en ajoutant en fait un "vrai" 3/4).
• Nous aurons besoin de @infor-design/design pour générer des icônes pour les 6 niveaux d'en-tête dans les deux thèmes.

Je pense qu'à l'origine, j'ai fait fonctionner H2, H3, puis en définissant, vous pouvez faire fonctionner H4 et H5.
Vous devez définir cela en fonction de la structure de votre page afin que l'accessibilité fonctionne avec les en-têtes.

Je pense que pour résoudre ce problème, nous pouvons peut-être simplement créer un bouton de menu avec le titre 1 - le titre 6 et laisser les utilisateurs décider. Ou peut rendre cela perferencable quant aux titres autorisés (et au texte). Donc, nous n'avons pas besoin d'icônes (elles étaient un peu moches de toute façon)

L'utilisateur veut juste établir une hiérarchie pendant qu'il tape ; comment nous rendons cela par la suite est une tout autre préoccupation.

Si nous nous en tenons à la conception actuelle, les boutons devraient simplement indiquer H1, H2 et H3.

J'aime la suggestion de Tim d'un menu déroulant ; beaucoup d'éditeurs de texte utilisent ce modèle. Si nous passons à cette conception, nous pouvons avoir des options qui lisent : Paragraphe, Titre 1, Titre 2 et Titre 3. Cette approche pourrait même prendre en compte des formats personnalisés s'ils sont nécessaires.

@EdwardCoyle Je suis d'accord avec @kentonquatman en tant qu'utilisateur Je souhaite spécifier la hiérarchie du texte avec plus de flexibilité que H3 et H4

Je pense que je préfère maintenant l'idée de Paragraph, Heading 1, Heading 2, and Heading 3. sous forme de texte dans un sélecteur de bouton de menu. Cela se lit moins comme des balises HTML pour l'utilisateur final.

Ensuite, en dessous, nous pouvons utiliser la classe au lieu des balises HN ou tout ce que nous voulons dans le balisage. Il s'agit donc simplement d'établir une hiérarchie dans le texte.

Si besoin, je peux me créer un ticket pour mettre à jour le design de la barre d'outils RTE afin d'y inclure un menu déroulant.

Bien sûr, et l'une des raisons pour lesquelles j'ai mentionné le bouton de menu au lieu de la liste déroulante est que ceux-ci fonctionnent plus facilement sur les barres d'outils. Mais si vous inventez quelque chose, nous pouvons y jeter un œil.

L'implémentation décrite ci-dessus me ressemble à la façon dont Google Docs le fait :

Juste en spécifiant quelques idées rapides sur ce dont le bouton de menu pourrait avoir besoin, en termes de changement. Faites-moi savoir si ceux-ci sont sur la bonne voie :

• [x] Nous pouvons probablement créer un bouton de menu personnalisé (peut-être en fait créer un composant "fontpicker"/"stylepicker") qui peut rendre les éléments de menu pour afficher les règles de style fournies. Peut-être besoin de quelques modifications du pipeline de rendu pour faciliter cela.
• [ ] Imitez la configuration "par défaut" actuelle du système de polices (h3/h4/paragraphe) lors de la création des valeurs par défaut pour le nouveau sélecteur.
• [ ] Aurait besoin de faire une compatibilité descendante en plus de cela (fx: si la configuration de l'éditeur détecte les anciens paramètres, il devrait les convertir automatiquement vers le nouveau système).
• [ ] C'est peut-être aussi le bon moment pour aborder le #2679 qui traite de la conversion entre les balises/styles.

@tmcconechy Oui, désolé. Je voulais dire bouton de menu.

@EdwardCoyle Oui, ce serait cool d'afficher les options de menu avec le style appliqué, comme dans l'exemple que vous avez publié à partir de Google Docs.

Certaines de ces couleurs sont susceptibles de changer car @elizabethhartley travaille actuellement sur des améliorations de notre palette de couleurs et de nos thèmes.

@kentonquatman et les nouvelles icônes ?

@elizabethhartley D'après ce que j'ai vu sur le site IDS, ceux-ci n'ont pas encore été adoptés : https://design.infor.com/code/ids-enterprise/latest/demo/components/editor/example-index?theme=uplift&variant =lumière&couleurs=0563C2

Votre capture d'écran semble montrer les icônes « soho » ? https://design.infor.com/code/ids-enterprise/latest/demo/components/editor/example-index sauf si je comprends mal la question ?

Désolé, j'ajoute de la confusion. J'ai basé la conception sur ce que nous avons actuellement dans IDS, qui utilise les anciennes icônes du système. Si vous regardez la version vibrante, vous verrez ce que je veux dire. Nous devrions également mettre à jour ces icônes.

ÉCHEC QA

1. Navigateur : IE11

• [ ] Le sélecteur de polices ne fonctionne pas lorsque le texte n'est pas sélectionné (c'est-à-dire placez simplement le curseur quelque part dans le texte), vous devez sélectionner le texte pour qu'il s'applique.

2. Navigateur : Chrome, IE 11, EDGE, Safari

• [ ] Le curseur disparaît après l'application du type d'en-tête ou l'utilisation du sélecteur de polices

3. Navigateur : IE 11, EDGE, Firefox

• [ ] Vous pouvez combiner le type de citation et d'en-tête

4. Navigateur : IE 11, EDGE

• [ ] Lorsque vous changez de type d'en-tête, les styles de police du texte (par exemple, gras, italique, barré) sont supprimés.

Concernant ces points que j'ai numérotés. Je ne pense pas qu'aucun d'entre eux ne représente un effort supplémentaire.

1. Ne vaut pas la peine d'être réparé car IE 11 ne sera bientôt plus pris en charge et est mineur et trop difficile (voire impossible) à réparer
2. Cela vaut peut-être la peine de réparer tous ces trois, mais le curseur reviendra une fois que vous aurez sélectionné, donc ce n'est pas facile. Voyons si des clients soulèvent des problèmes similaires.
3. Ce n'est pas une exigence.
4. C'est probablement bien qu'il ait supprimé ces styles et utilise le style de l'en-tête.

Tous ces éléments sont trop mineurs pour y passer du temps.

Il semble que le style de cet élément ne corresponde pas au design.

| Conception | Version actuelle |
| --- | --- |
| | |

Il semble que l'implémentation utilise simplement le composant menubutton standard. J'aimerais supprimer la flèche et rapprocher le menu de la barre d'outils. Est-il possible d'inclure plus de style dans la conception ou aurions-nous besoin de mettre à jour le composant menubutton ?

Ok, rouvrir et ajuster. Je me suis interrogé sur la taille du bouton. Une raison pour laquelle la conception a la flèche si loin du texte ? Il s'agit d'une personnalisation du bouton de menu, nous n'avons donc pas à le modifier spécifiquement.

@kentonquatman est-ce que le style de la conception doit être appliqué de manière plus générale à tous les types de

@tmcconechy La flèche est à l'extrême droite pour prendre en compte les mots plus gros (En-tête 1 par rapport à la valeur par défaut), de la même manière qu'un menu déroulant serait stylisé. La largeur du bouton doit toujours être la même et la flèche doit toujours être au même endroit, quel que soit le style sélectionné.

@EdwardCoyle Je ne sais pas si ce style doit être appliqué à chaque instance d'un bouton de menu. Il faudrait que je me penche un peu plus là-dessus, mais je suppose que non.

C'est un peu déroutant car c'est un bouton de menu quelque peu combiné avec une liste déroulante. Mais je pense que vous prenez juste de l'espace supplémentaire dans la barre d'outils. La flèche pourrait être juste à la fin du texte, que ce soit 8 contre 7 caractères + 5px sans conséquences ? Ou pourrait dire que le texte le plus grand est l'en-tête 6 et utiliser cette largeur. Nous n'affichons pas réellement le style dans le bouton lorsqu'il est sélectionné ? Ou est-ce le raisonnement pourquoi. (Fx Header 1 s'affiche en gros caractères lorsqu'il est sélectionné ?)

Je ne pense pas que la flèche doive se déplacer en fonction de la longueur de l'étiquette. Il vaut mieux le garder dans la même position ; c'est le traitement le plus courant pour ce type d'élément.

Exemples tirés de Google Docs :

| Un | Deux | Trois |
| --- | --- | --- |
| | | |

Ok, la seule chose qui m'a dérouté, c'est que notre bouton de menu bouge maintenant. Un exemple (un peu brouillon) http://master-enterprise.demo.design.infor.com/components/menubutton/test-on-toolbar.html . C'est important donc il n'y a pas beaucoup d'espaces perdus sur la barre d'outils, donc je ne changerais pas cela mais ceux-ci sont alignés à droite.

Mais pour ce cas d'éditeur, je pourrais en effet voir fixer la taille comme google, mais peut-être ne le ferions-nous pas un peu mais moins pour que la taille soit la même mais plus proche de l'ensemble réel de valeurs? Il y a peut-être 40 pixels perdus dans l'espace vide et cela fera déborder un ou deux boutons de la barre d'outils ?

Cela peut être dû au fait que le texte est "Par défaut" et "En-tête 1" et non "Texte d'en-tête" / "En-tête 3"
qui est plus long. Alors peut-être que nous le rapprochons simplement en fonction des valeurs que vous pouvez choisir dans notre cas (par exemple, 10 px plus la valeur de texte maximale) ?

@kentonquatman , @tmcconechy , et j'ai proposé cette liste des prochaines étapes pour terminer ceci :

• [x] Basculez "Par défaut" sur "Texte normal" dans le premier élément
• [x] Créez une détection par programmation de la largeur du plus grand élément de la liste et définissez-la comme la largeur de niveau supérieur du bouton du sélecteur.
• [x] Dans l'ensemble de la barre d'outils du formateur, supprimez les flèches des menus contextuels et positionnez les menus légèrement au-dessus de leurs boutons de déclenchement.
• [x] Localiser les tailles de police par défaut.

Une autre chose que je viens de découvrir est que dans le thème Soho, le texte du sélecteur est très gros. C'est en quelque sorte correct car c'est le style, mais je me demande si c'est un peu rebutant. Google modifie-t-il réellement la taille des éléments du sélecteur comme celui-ci ? Pensons-nous que cela pourrait être amélioré sur le thème soho ?

Échec du contrôle qualité

• [ ] La largeur du menu est au même niveau que le bouton de déclenchement. Le menu doit être légèrement plus large que le bouton de déclenchement. Voir capture d'écran pour référence. Je ne sais pas si c'est juste un problème d'application de démonstration

Vérifié dans http://4240-rc0-enterprise.demo.design.infor.com/components/editor/example-index?theme=uplift&variant=light

• [ ] Navigateur : EDGE
  La flèche n'est pas alignée
  

Pour le point 1 - nous avons fait une légère variation pour rendre les choses cohérentes. Laissons cela tel quel.
Point 2 - nous devrions corriger

• [x] Correction du problème de mise en page noté
• [x] Nous avons également trouvé qu'un test a échoué dans les détails de NG :

-  checkout 6.3.x in ng and run:
- `npm run test`
- `npm run testdebug` to debug
- seems like this test page shows the issue http://localhost:4000/components/toolbar-flex/example-more-actions-ajax.html notice that beforeOpen is not being called anymore.