enterprise: Editor: Configuring heading buttons is not working

Describe the bug Rich Text Editor seems to ignore editor buttons settings, or the feature is not documented. Editor always shows H3 and H4 while H1 and H2 are missing. Editor also seems ti ignore any settings other that header1 and header2 which are then displayed as ‘H3’ and H4’

To Reproduce Steps to reproduce the behavior:

Run ids-enteprise-ng project and use this code

    // Customize the buttons on init
    this.editor.buttons = {
      editor: [
        'header1', 'header2', 'header3', 'header4', 'header5', 'header6',
        'separator', 'bold', 'underline', 'strikethrough',
        'separator', 'foreColor',
        'separator', 'justifyLeft', 'justifyCenter', 'justifyRight',
        'separator', 'quote', 'orderedlist', 'unorderedlist',
        'separator', 'anchor',
        'separator', 'clearFormatting',
        'separator', 'source'
      ],
      source: [
        'visual'
      ]
    };

Click on Rich Text Editor
See buttons H3 and H4 showing

Expected behavior Editor should respect settings and create heading buttons accordingly, as per attached code H1, H2, H3, H4, H5, H6

Version

ids-enterprise-ng: 5.5.2

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 31 (18 by maintainers)

Commits related to this issue

Added `CHANGELOG.md` note about #2722 — committed to infor-design/enterprise by EdwardCoyle 5 years ago

Most upvoted comments

I think i now best like the idea of Paragraph, Heading 1, Heading 2, and Heading 3. as text in a menu button picker. This read less like HTML tags to the end user.

Then underneath we can use class instead of HN tags or whatever we want in the markup. So its just setting hierarchy in the text.

tmcconechy on Nov 18, 2019

IDS_RichTextEditor_StyleSelection_Dark_01

kentonquatman on Dec 5, 2019

@kentonquatman, @tmcconechy, and I came up with this list of next steps to finish this off:

Switch “Default” to “Normal Text” in the first item
Build a programmatic detection of the width of the largest item in the list, and set that as the top-level width of the picker’s button.
Overall throughout formatter toolbar, remove arrows from popupmenus, and position the menus slightly over top of their trigger buttons.
Localize default font sizes.

EdwardCoyle on Dec 19, 2019

Concerning these points which i have numbered. I do not think any of them are work any additional effort.

Not worth fixing as IE 11 will soon be not supported and is minor and too difficult (if not impossible) to fix
Possibly worth fixing of all these three but the cursor will come back once you select so its not an easy one. Lets see if any customers raise similar issues.
This is not requirement.
This is probably good that it removed those styles and uses the style of the header.

All of these too minor to spend any time one.

tmcconechy on Dec 16, 2019

The implementation described above sounds to me like the way Google Docs does it:

Screen Shot 2019-11-18 at 4 22 16 PM

Just speccing out some quick ideas on what the menu button might need, change-wise. Let me know if these are on the right track:

We can probably make a custom menu button (maybe actually create a “fontpicker”/“stylepicker” component) that can render menu items to display the provided style rules. Might need some rendering pipeline changes to facilitate this.
Mimic the current “default” configuration of the font system (h3/h4/paragraph) when building in the defaults for the new picker.
Would need to make some backwards compatibility on top of that (fx: if the editor configuration detects the old settings, it should convert them to the new system automatically).
Might also be a good time to address #2679 which deals with converting between tags/styles.

EdwardCoyle on Dec 6, 2019

If needed, I can make a ticket for myself to update the design of the RTE toolbar to include a dropdown menu.

kentonquatman on Nov 18, 2019

@EdwardCoyle I agree with @kentonquatman as an user I want to specify the hierarchy of the text with more flexibility than just H3 and H4

Fruko on Nov 18, 2019

The user just wants to establish hierarchy while they’re typing; how we render that afterwards is another concern altogether.

If we stick with the current design, the buttons should just say H1, H2, and H3.

I do like Tim’s suggestion of a dropdown menu; a lot of text editors use that pattern. If we switch to that design we can have options that read: Paragraph, Heading 1, Heading 2, and Heading 3. This approach could even account for custom formats if they are ever needed.

kentonquatman on Nov 18, 2019