Enterprise: Editor: la configuración de los botones de encabezado no funciona

Esto también se puede reproducir en ids-enterprise. Es muy probable que el problema esté ahí.

1. Vaya a http: // localhost : 4000 / components / editor / example-custom-buttons.html
2. Este código está configurado para mostrar h1 y h2 y no h3 y h4, pero esto no tiene ningún efecto https://github.com/infor-design/enterprise/blob/master/app/views/components/editor/example-customize -buttons.html # L21

Espere que pueda configurar los botones en h1-h6 como desee (para que coincida con la estructura de la página).

@Fruko @tmcconechy , creo que lo que está en el código fuente aquí es un nombre poco apropiado.

En cuanto a la fuente , header1 y header2 no se asignan necesariamente a una etiqueta H1 / H2 respectivamente. Se asignan a H3 / H4. El componente Editor ha sido así desde siempre, y creo que el razonamiento fue que, a nivel de aplicación, los H1 / H2 no son algo que sea "editable" en el sentido de que un usuario que use este componente simplemente podría agregar uno a el contenido.

Obviamente, los requisitos / necesidades han cambiado desde nuestro conjunto original de diseños, pero este problema no es muy sencillo para mí. Es una mejora / adición de características. Algunas preguntas:

• ¿Deberíamos incorporar soporte para todos los niveles de encabezado?
• ¿Cómo manejamos con elegancia los posibles cambios de ruptura en torno a esto (cambiando header1 / 2 a 3/4, en realidad agregando un 3/4 "verdadero").
• Necesitaremos @ infor-design / design para generar iconos para los 6 niveles de encabezado en ambos temas.

Creo que originalmente hice que H2, H3 funcionaran, luego, al configurarlo, puedes hacer que H4 y H5 funcionen.
Lo establecería en función de la estructura de su página para que la accesibilidad funcione con los encabezados.

Creo que para solucionar esto, tal vez podamos crear un botón de menú con el título 1 - el título 6 y dejar que los usuarios decidan. O puede hacer que sea perferencable en cuanto a qué títulos están permitidos en él (y texto). Entonces no necesitamos íconos (eran algo feos de todos modos)

El usuario solo quiere establecer una jerarquía mientras escribe; cómo traducimos eso después es otra preocupación en conjunto.

Si nos atenemos al diseño actual, los botones deberían decir H1, H2 y H3.

Me gusta la sugerencia de Tim de un menú desplegable; muchos editores de texto usan ese patrón. Si cambiamos a ese diseño, podemos tener opciones que dicen: Párrafo, Título 1, Título 2 y Título 3. Este enfoque podría incluso tener en cuenta los formatos personalizados si alguna vez se necesitan.

@EdwardCoyle Estoy de acuerdo con @kentonquatman como usuario Quiero especificar la jerarquía del texto con más flexibilidad que solo H3 y H4

Creo que ahora me gusta más la idea de Paragraph, Heading 1, Heading 2, and Heading 3. como texto en un selector de botones de menú. Esto se parece menos a las etiquetas HTML para el usuario final.

Luego, debajo podemos usar class en lugar de etiquetas HN o lo que queramos en el marcado. Entonces es solo establecer una jerarquía en el texto.

Si es necesario, puedo hacer un ticket para mí mismo para actualizar el diseño de la barra de herramientas RTE para incluir un menú desplegable.

Claro, y una de las razones por las que mencioné el botón de menú en lugar del menú desplegable es que funcionan más fácilmente en las barras de herramientas. Pero si inventa algo, podemos echarle un vistazo.

La implementación descrita anteriormente me suena a la forma en que lo hace Google Docs:

Simplemente especificando algunas ideas rápidas sobre lo que podría necesitar el botón de menú, en cuanto a cambios. Avísame si están en el camino correcto:

• [x] Probablemente podamos hacer un botón de menú personalizado (tal vez crear un componente "fontpicker" / "stylepicker") que pueda representar elementos de menú para mostrar las reglas de estilo proporcionadas. Es posible que necesite algunos cambios en la canalización de renderizado para facilitar esto.
• [] Imita la configuración "predeterminada" actual del sistema de fuentes (h3 / h4 / párrafo) al crear los valores predeterminados para el nuevo selector.
• [] Necesitaría hacer alguna compatibilidad con versiones anteriores además de eso (fx: si la configuración del editor detecta la configuración anterior, debería convertirla al nuevo sistema automáticamente).
• [] También podría ser un buen momento para abordar el número 2679, que trata sobre la conversión entre etiquetas / estilos.

@tmcconechy Sí, lo siento. Me refiero al botón de menú.

@EdwardCoyle Sí, sería genial mostrar las opciones del menú con el estilo aplicado, como en el ejemplo que publicaste en Google Docs.

Algunos de los colores de estos están sujetos a cambios ya que @elizabethhartley está trabajando actualmente en mejoras para nuestra paleta de colores y temas.

@kentonquatman ¿qué pasa con los nuevos íconos?

@elizabethhartley Por lo que vi en el sitio web de IDS, aún no se han adoptado: https://design.infor.com/code/ids-enterprise/latest/demo/components/editor/example-index?theme=uplift&variant = luz y colores = 0563C2

¿Su captura de pantalla parece mostrar los íconos "soho"? https://design.infor.com/code/ids-enterprise/latest/demo/components/editor/example-index a menos que no haya entendido mal la pregunta.

Lo siento, estoy agregando confusión. Basé el diseño en lo que tenemos actualmente en IDS, que usa los iconos del sistema más antiguos. Si miras la versión vibrante, verás a qué me refiero. También deberíamos actualizar esos iconos.

QA FALLÓ

1. Navegador: IE11

• [] El selector de fuentes no funciona cuando el texto no está seleccionado (es decir, simplemente coloque el signo de intercalación en algún lugar del texto), debe seleccionar el texto para que se aplique.

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

• [] Caret desaparece después de aplicar el tipo de encabezado o usar el selector de fuentes

3. Navegador: IE 11, EDGE, Firefox

• [] Puede combinar blockquote y tipo de encabezado

4. Navegador: IE 11, EDGE

• [] Al cambiar los tipos de encabezado, se eliminan los estilos de fuente del texto (por ejemplo, negrita, cursiva, tachado)

Sobre estos puntos que he enumerado. No creo que ninguno de ellos suponga un esfuerzo adicional.

1. No vale la pena arreglarlo, ya que IE 11 pronto no será compatible y es menor y demasiado difícil (si no imposible) de arreglar
2. Posiblemente valga la pena corregir estos tres, pero el cursor volverá una vez que seleccione, por lo que no es fácil. Veamos si algún cliente plantea problemas similares.
3. Este no es un requisito.
4. Probablemente sea bueno que elimine esos estilos y use el estilo del encabezado.

Todos estos son demasiado pequeños para gastar un tiempo en uno.

Parece que el estilo de este elemento no coincide con el diseño.

| Diseño | Versión actual |
| --- | --- |
| | |

Parece que la implementación solo usa el componente de botón de menú estándar. Me gustaría quitar la flecha y acercar el menú a la barra de herramientas. ¿Es posible incluir más estilos del diseño o tendríamos que actualizar el componente del botón de menú?

Ok, volvamos a abrir y ajustar. Me pregunté sobre el tamaño del botón. ¿Alguna razón por la que el diseño tiene la flecha tan lejos del texto? Esta es una personalización del botón de menú, por lo que no tenemos que cambiarla específicamente.

@kentonquatman, ¿ es el estilo en el diseño algo que debe aplicarse de manera más general a todos los tipos de

@tmcconechy La flecha está en el extremo derecho para tener en cuenta las palabras más grandes (Encabezado 1 frente a Predeterminado), similar a cómo se diseñaría un menú desplegable. El ancho del botón siempre debe ser el mismo y la flecha debe estar siempre en el mismo lugar, sin importar qué estilo se seleccione.

@EdwardCoyle No estoy seguro de si este estilo debería aplicarse a cada instancia de un botón de menú. Necesitaría investigarlo un poco más, pero supongo que no.

Es un poco confuso ya que es un botón de menú algo combinado con un menú desplegable. Pero mi pensamiento es que solo estás ocupando espacio extra en la barra de herramientas. ¿La flecha podría estar al final del texto, ya sean 8 vs 7 caracteres + 5px sin consecuencias? O podría decirse que el texto más grande es el encabezado 6 y usar ese ancho. ¿No estamos mostrando realmente el estilo en el botón cuando está seleccionado? ¿O es ese el razonamiento por qué? (¿El encabezado Fx 1 se muestra en letra grande cuando se selecciona?)

No creo que la flecha deba moverse según la longitud de la etiqueta. Es mejor mantenerlo en la misma posición; es el tratamiento más común para este tipo de elementos.

Ejemplos de Google Docs:

| Uno | Dos | Tres |
| --- | --- | --- |
| | | |

Ok, lo único que creo que me confundió es que nuestro botón de menú se mueve ahora. Un ejemplo (un poco desordenado) http://master-enterprise.demo.design.infor.com/components/menubutton/test-on-toolbar.html . Esto es importante, por lo que no hay muchos espacios en blanco desperdiciados en la barra de herramientas, por lo que no cambiaría eso, pero están alineados a la derecha.

Pero para este caso de editor, de hecho, pude ver la fijación del tamaño como Google, pero tal vez no lo haríamos un poco, pero menos, para que el tamaño sea el mismo pero más cercano al conjunto real de valores. ¿Hay tal vez 40 píxeles desperdiciados en el espacio vacío y hará que uno o dos botones de la barra de herramientas se desborden?

Esto puede deberse a que el texto o es "Predeterminado" y el "encabezado 1" no es "Texto del encabezado" / "Encabezado 3"
que es más largo. Entonces, ¿tal vez lo acerquemos más en función de los valores que puede elegir en nuestro caso (por ejemplo, 10 px más el valor máximo de texto)?

@kentonquatman , @tmcconechy , y se me ocurrió esta lista de los próximos pasos para terminar con esto:

• [x] Cambia "Predeterminado" a "Texto normal" en el primer elemento
• [x] Cree una detección programática del ancho del elemento más grande de la lista y configúrelo como el ancho de nivel superior del botón del selector.
• [x] En general, en toda la barra de herramientas del formateador, elimine las flechas de los menús emergentes y coloque los menús ligeramente por encima de sus botones de activación.
• [x] Localiza los tamaños de fuente predeterminados.

Otra cosa que acabo de descubrir es que en el tema Soho el texto del selector es muy grande. Esto es correcto ya que ese es el estilo, pero me pregunto si es un poco desagradable. ¿Google realmente cambia el tamaño de las cosas en el selector de esta manera? ¿Creemos que esto podría mejorarse en el tema del soho?

Control de calidad fallido

• [] El ancho del menú está al mismo nivel que el botón disparador. El menú debe ser un poco más ancho que el botón de activación. Vea la captura de pantalla como referencia. No estoy seguro de si esto es solo un problema de la aplicación de demostración

Verificado en http://4240-rc0-enterprise.demo.design.infor.com/components/editor/example-index?theme=uplift&variant=light

• [] Navegador: EDGE
  La flecha no está alineada
  

Para el punto 1, hicimos una pequeña variación para que las cosas fueran consistentes. Dejemos esto como está.
Punto 2 - deberíamos arreglar

• [x] Soluciona el problema de diseño observado
• [x] También encontramos una prueba fallida en los detalles 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.