Enterprise: Editor: a configuração dos botões de título não está funcionando

Isso também pode ser reproduzido em ids-enterprise. Portanto, provavelmente o problema está aí.

1. Vá para http: // localhost : 4000 / components / editor / example-customize-buttons.html
2. Este código está configurado para mostrar h1 e h2 e não h3 e h4, mas isso não está tendo nenhum efeito https://github.com/infor-design/enterprise/blob/master/app/views/components/editor/example-customize -buttons.html # L21

Espere que você seja capaz de definir os botões para h1-h6 como desejar (para corresponder à estrutura da página).

@Fruko @tmcconechy , acho que o que está no código-fonte aqui é um pouco incorreto.

Olhando para a fonte , header1 e header2 não são necessariamente mapeados para uma tag H1 / H2 respectivamente. Eles são mapeados para H3 / H4. O componente Editor tem sido assim desde sempre, e acredito que o raciocínio era que, no nível do aplicativo, o H1 / H2 não é algo "editável" no sentido de que um usuário que usa esse componente seria capaz de adicionar um ao o conteúdo.

Obviamente, os requisitos / necessidades mudaram desde nosso conjunto original de designs, mas esse problema não é muito direto para mim. É um pouco como um aprimoramento / adição de recurso. Algumas perguntas:

• Devemos construir um suporte para todos os níveis de cabeçalho?
• Como lidamos normalmente com as possíveis mudanças de quebra em torno disso (alterando header1 / 2 para 3/4, adicionando na verdade um 3/4 "verdadeiro").
• Precisaremos de @ infor-design / design para gerar ícones para todos os 6 níveis de cabeçalho em ambos os temas.

Acho que originalmente fiz H2, H3 funcionarem, então, ao definir, você pode fazer H4 e H5 funcionarem.
Você definiria isso com base na estrutura da página para que a acessibilidade funcione com os títulos.

Acho que, para corrigir isso, talvez possamos apenas criar um botão de menu com Título 1 - título 6 nele e deixar os usuários decidirem. Ou pode tornar perferenciável quais cabeçalhos são permitidos nele (e no texto). Então, não precisamos de ícones (eles eram meio feios de qualquer maneira)

O usuário deseja apenas estabelecer uma hierarquia enquanto digita; como interpretamos isso depois é outra preocupação.

Se ficarmos com o design atual, os botões deverão apenas dizer H1, H2 e H3.

Eu gosto da sugestão de Tim de um menu suspenso; muitos editores de texto usam esse padrão. Se mudarmos para esse design, podemos ter opções que dizem: Parágrafo, Título 1, Título 2 e Título 3. Essa abordagem pode até mesmo levar em conta formatos personalizados, se eles forem necessários.

@EdwardCoyle Eu concordo com @kentonquatman como um usuário. Quero especificar a hierarquia do texto com mais flexibilidade do que apenas H3 e H4

Acho que agora gosto mais da ideia de Paragraph, Heading 1, Heading 2, and Heading 3. como texto em um seletor de botão de menu. Isso se parece menos com tags HTML para o usuário final.

Então, por baixo, podemos usar a classe em vez de tags HN ou o que quisermos na marcação. Portanto, é apenas definir a hierarquia no texto.

Se necessário, posso fazer um tíquete para mim mesmo para atualizar o design da barra de ferramentas RTE para incluir um menu suspenso.

Claro, e um dos motivos pelos quais mencionei o botão de menu em vez do menu suspenso é que eles funcionam mais facilmente nas barras de ferramentas. Mas se você inventar algo, podemos dar uma olhada.

A implementação descrita acima me parece a maneira como o Google Docs faz:

Apenas especificando algumas idéias rápidas sobre o que o botão de menu pode precisar, em termos de mudança. Deixe-me saber se eles estão no caminho certo:

• [x] Provavelmente podemos fazer um botão de menu personalizado (talvez, na verdade, criar um componente "fontpicker" / "stylepicker") que pode renderizar itens de menu para exibir as regras de estilo fornecidas. Pode ser necessário algumas mudanças no pipeline de renderização para facilitar isso.
• [] Imitar a configuração "padrão" atual do sistema de fontes (h3 / h4 / parágrafo) ao construir os padrões para o novo seletor.
• [] Seria necessário fazer alguma compatibilidade com versões anteriores (fx: se a configuração do editor detecta as configurações antigas, ele deve convertê-las para o novo sistema automaticamente).
• [] Também pode ser um bom momento para abordar o nº 2679, que trata da conversão entre tags / estilos.

@tmcconechy Sim, desculpe. Eu quis dizer botão de menu.

@EdwardCoyle Sim, seria legal mostrar as opções do menu com o estilo aplicado, como no exemplo que você postou do Google Docs.

Algumas das cores neles estão sujeitas a alterações, visto que @elizabethhartley está atualmente trabalhando em refinamentos para nossa paleta de cores e temas.

@kentonquatman e os novos ícones?

@elizabethhartley Pelo que vi no site da IDS, eles ainda não foram adotados: https://design.infor.com/code/ids-enterprise/latest/demo/components/editor/example-index?theme=uplift&variant = luz e cores = 0563C2

Sua captura de tela parece mostrar os ícones "soho"? https://design.infor.com/code/ids-enterprise/latest/demo/components/editor/example-index a menos que eu esteja entendendo mal a questão?

Desculpe, estou adicionando confusão. Eu baseei o design no que temos atualmente no IDS, que usa os ícones do sistema mais antigos. Se você olhar para a versão vibrante, verá o que quero dizer. Devemos também atualizar esses ícones.

QA FALHOU

1. Navegador: IE11

• [] O seletor de fonte não funciona quando o texto não está selecionado (ou seja, basta colocar o cursor em algum lugar do texto), você deve selecionar o texto a ser aplicado.

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

• [] O acento circunflexo desaparece após aplicar o tipo de cabeçalho ou usar o seletor de fonte

3. Navegador: IE 11, EDGE, Firefox

• [] Você pode combinar blockquote e tipo de cabeçalho

4. Navegador: IE 11, EDGE

• [] Ao alternar os tipos de cabeçalho, ele remove os estilos de fonte do texto (por exemplo, negrito, itálico, tachado)

Em relação a esses pontos que numerei. Não creio que nenhum deles seja trabalho, nenhum esforço adicional.

1. Não vale a pena consertar porque o IE 11 em breve não será mais suportado e é pequeno e muito difícil (se não impossível) de consertar
2. Possivelmente vale a pena consertar todos esses três, mas o cursor voltará assim que você selecionar, portanto, não é fácil. Vamos ver se algum cliente levanta questões semelhantes.
3. Este não é um requisito.
4. Provavelmente é bom ter removido esses estilos e usar o estilo do cabeçalho.

Todas essas coisas muito pequenas para serem perdidas em qualquer momento.

Parece que o estilo deste elemento não corresponde ao design.

| Design | Versão atual |
| --- | --- |
| | |

Parece que a implementação está usando apenas o componente de menu padrão. Eu gostaria de remover a seta e mover o menu para mais perto da barra de ferramentas. É possível incluir mais estilo no design ou precisaríamos atualizar o componente menubutton?

Ok, vamos reabrir e ajustar. Eu me perguntei sobre o tamanho do botão. Alguma razão para o design ter a seta tão longe do texto? Esta é uma personalização do menu, portanto, não precisamos alterá-la especificamente.

@kentonquatman é o estilo do design que precisa ser aplicado de forma mais geral para todos os tipos de botões de menu? Ou estamos criando um estilo secundário apenas para isso?

@tmcconechy A seta está na extrema direita para contabilizar palavras maiores (Cabeçalho 1 vs. Padrão), semelhante ao estilo de um menu suspenso. A largura do botão deve ser sempre a mesma e a seta deve estar sempre no mesmo lugar, independentemente do estilo selecionado.

@EdwardCoyle Não tenho certeza se esse estilo deve ser aplicado a cada instância de um botão de menu. Eu precisaria examinar isso um pouco mais, mas meu palpite é que não.

É um pouco confuso, pois é um botão de menu um tanto combinado com um menu suspenso. Mas meu pensamento é que você está apenas ocupando espaço extra na barra de ferramentas. A seta pode estar no final do texto, seja 8 vs 7 caracteres + 5px, sem consequências? Ou poderia dizer que o texto maior é o Cabeçalho 6 e usar essa largura. Não estamos realmente exibindo o estilo no botão quando ele está selecionado? Ou é esse o motivo. (Fx Header 1 Mostra em fonte grande quando selecionado?)

Não acho que a seta deve se mover com base no comprimento da etiqueta. É melhor mantê-lo na mesma posição; é o tratamento mais comum para esse tipo de elemento.

Exemplos do Google Docs:

| One | Dois | Três |
| --- | --- | --- |
| | | |

Ok, a única coisa que acho que me confundiu é que nosso botão de menu se move agora. Um exemplo (um pouco confuso) http://master-enterprise.demo.design.infor.com/components/menubutton/test-on-toolbar.html . Isso é importante para que não haja muito espaço em branco desperdiçado na barra de ferramentas, então eu não mudaria isso, mas eles estão alinhados à direita.

Mas para este caso de editor, eu poderia realmente ver como corrigir o tamanho como google, mas talvez não fossemos apenas torná-lo um pouco, mas menos, para que o tamanho seja o mesmo, mas mais próximo do conjunto real de valores? Há talvez 40 pixels perdidos no espaço vazio e isso fará com que um ou dois botões da barra de ferramentas transbordem?

Isso pode ocorrer porque ou o texto é "Padrão" e "cabeçalho 1" e não "Texto do cabeçalho" / "Cabeçalho 3"
que é mais longo. Então, talvez possamos apenas aproximar com base nos valores que você pode escolher em nosso caso (como 10 px mais o valor de texto máximo).

@kentonquatman , @tmcconechy e eu

• [x] Mude "Padrão" para "Texto Normal" no primeiro item
• [x] Crie uma detecção programática da largura do maior item da lista e defina-a como a largura de nível superior do botão do seletor.
• [x] De maneira geral, na barra de ferramentas do formatador, remova as setas dos menus pop-up e posicione os menus ligeiramente acima dos botões de acionamento.
• [x] Localize os tamanhos de fonte padrão.

Outra coisa que acabei de descobrir é que no tema do Soho o texto do seletor é muito grande. Isso é meio correto, pois esse é o estilo, mas me pergunto se é um pouco inconveniente. O Google realmente altera o tamanho das coisas no seletor assim? Achamos que isso poderia ser melhorado no tema soho?

Falha no controle de qualidade

• [] A largura do menu está no mesmo nível do botão de disparo. O menu deve ser um pouco mais largo do que o botão de disparo. Veja a captura de tela para referência. Não tenho certeza se este é apenas um problema de aplicativo de demonstração

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

• [] Navegador: EDGE
  A seta não está alinhada
  

Para o ponto 1 - fizemos uma pequena variação para tornar as coisas consistentes. Vamos deixar isso como está.
Ponto 2 - devemos consertar

• [x] Corrija o problema de layout observado
• [x] Também descobrimos que um teste falhou nos detalhes 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.