Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Styles-Dropdown shows "Paragraph" instead of "Formats" as empty-value #9186

Closed
lerni opened this issue Nov 23, 2023 · 16 comments
Closed

Styles-Dropdown shows "Paragraph" instead of "Formats" as empty-value #9186

lerni opened this issue Nov 23, 2023 · 16 comments

Comments

@lerni
Copy link

lerni commented Nov 23, 2023

Styles-Dropdown (formerly styleselect) displays "Paragraph" as empty value. Previously, it was "Formats". This behavior seems to be consistent across different languages.
https://k5jp2r.csb.app/

✔️ Expected result

Styles-Dropdown shows "Formats" as empty value.
Tiny-ss4-styleselect

❌ Actual result

Styles-Dropdown shows "Paragraph" as empty value.
Tiny-ss5-styles

📃 Other details

Firefox 119.0.1 on Mac
I'm using Tiny with Silverstripe. It used to be "Formats" with v4 (Tiny 4.9) and now is "Paragraph" with v5 (Tiny 6.5).

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

@lerni
Copy link
Author

lerni commented Nov 23, 2023

Duplicate of #8737

@lerni lerni closed this as completed Nov 23, 2023
@kinglozzer
Copy link

Copying my comment in from #8737 (comment):

I have a similar issue to this - we use the block_formats to let users choose h1, h2 etc, and use style_formats to allow them to modify styles for things. For example:

{
  block_formats: 'Paragraph=p;Heading 1=h1;Heading 2=h2;Heading 3=h3',
  style_formats_autohide: true,
  style_formats: [
    {
      title: 'Button',
      selector: 'a',
      classes: 'button'
    }
  ]
}

Despite the fact that “Paragraph” is not an option in the style_formats dropdown, it still always defaults to saying Paragraph as the label when no styles are selected.

I’m working around this for now by adding { title: 'Format', selector: '*' } so that the dropdown always says “Format”, but that’s not ideal because it obviously then never changes when a format is selected.

@lerni
Copy link
Author

lerni commented Nov 23, 2023

I've re-opened and let you decide, if it's worth keeping open ☺️

@lerni lerni reopened this Nov 23, 2023
@Wertisdk
Copy link

We have the same issue, and since we use both the blocks select and the formats select right next to each other, having two of the same dropdown right next to each other, is extremely confusing for the users.

I have made a very hacky temporary fix, which works by finding the correct select based of the title tag and then using a mutation observer to fix the textContent whenever no format is selected:

function observeAndFixStyleFormatLabel() {
    const formatTranslation = tinyMCE.translate('Formats');
    const paragraphTranslation = tinyMCE.translate('Paragraph');
    const targetNode = document.querySelector(`.tox-tbtn--select[title*="${formatTranslation}"], .tox-tbtn--select[title*="Formats"]`);
    const labelSelector = ".tox-tbtn__select-label";

    if (!targetNode) {
        return;
    }

    const fixStyleFormatLabel = (node) => {
        const labelNode = node.matches(labelSelector) ? node : node.querySelector(labelSelector);

        if (!labelNode || labelNode.textContent.trim() !== paragraphTranslation) {
            return false;
        }

        labelNode.textContent = formatTranslation;
        return true;
    }
    const mutationCallback = (mutationsList, observer) =>
        mutationsList.some(mutation => mutation.type === 'childList' && fixStyleFormatLabel(mutation.target));


    const observer = new MutationObserver(mutationCallback);
    const config = {childList: true, subtree: true};

    // Apply intial fix if necessary
    fixStyleFormatLabel(targetNode);
    // Start observing the target node for configured mutations
    observer.observe(targetNode, config);
};

// On tinymce init event
function handleInitEvent() {
    observeAndFixStyleFormatLabel();
}

Obviously this falls apart easily and it would be much preferred, if the standard functionality was to have a translatable standard label / text for each of these dropdowns.

@richardczeiger
Copy link

+1 for this issue. We should be able to specify the 'label' of the styles dropdown. kinglozzer's hack above is almost good enough, but has the downside of seeing the label as the selected first option...

@Leilahodgkins
Copy link

Yes, please fix this - it's confusing and makes the interface look amateur, especially when I have to explain to clients.

@TheSpyder
Copy link
Member

TheSpyder commented Jan 25, 2024

@Leilahodgkins please calm down. TinyMCE is not "amateur" and has operated this way since 2018. Apologies for the lack of updates, it took a while to trace through what happened.

This was a design change in TinyMCE 5. The entire contents of what is now the blocks dropdown are usually available within what is now the styles dropdown, so we don't expect both to be on the toolbar. To retain the ability for users to see what style is active after removing blocks, the styles dropdown needs to show the selected style instead of just Formats.

Later, there was a complaint (#4619) that the dropdown didn't have a default value when the cursor format was not in the list. The designers at the time chose Paragraph as the default, assuming it would always be in the list. If you look, I even questioned this - but it was a very busy time and I did not appreciate the potential downsides, nor that the stated TinyMCE 4 default was for the formatselect dropdown, not the styleselect dropdown where the bug was reported. These names were confusing until we corrected them in TinyMCE 6.

We can (and probably should) consider using Formats as the fallback instead of Paragraph - the menu item is still Formats, after all, and it doesn't update dynamically. In the 5 years since this happened the code has improved and it's now a very clear one-line change (although recent accessibility improvements make it a lot more complex than that).

This won't help interfaces that show both, but our recommendation is still to not show both.

@richardczeiger
Copy link

Thanks for your response Spyder. I admit I'm a bit confused: Are you suggesting that blocks and styles should NOT be used together?? But we merge them all into styles?

I disagree that the Format dropdown (for setting and element to para, H2, div, etc) should be mixed up with Styles. I think it should work like the semantic distrinction between content type and visual appearance. Also, if we merge these two then we would have to create each style (say a backgroun highlight colour) for every element type we want that style applied to... That's bother very prescriptive as well as labour-intensive.... Moreover the Block Formats are a single selection dropdown, while the Styles dropdown allows for multiple selections. These are two different types of interaction.

I think all everyone on this issue is asking for is for a non-applicable label (ie: can't be set for an element) at the top as a default that simply says 'Style'. In other words: please just change the word 'Paragraph' in the styles dropdown to: 'Style'.

Keep 'Format' for the menu navigation, but for the toolbar styles drowndown, please just change 'Paragraph' to 'Style'.
Thanks! :)

@TheSpyder
Copy link
Member

It's not that they merge, it's that everything on the blocks dropdown already exists somewhere in a styles dropdown submenu (by default). At least I think that was the reason - these decisions were made 5 and a half years ago so it's difficult to remember exactly. TinyMCE 5 was a big project, with design docs spread over multiple systems, and the team has changed quite a lot since then.

The ticket I've logged internally is only to swap the fallback to Formats. If the currently selected style exists, it will be shown. That's the design now.

@TheSpyder
Copy link
Member

please just change 'Paragraph' to 'Style'

If it says Formats in the menu, shouldn't it say that in the toolbar as well?

@richardczeiger
Copy link

richardczeiger commented Jan 25, 2024

Sorry - you misunderstood. The Formats menu has things like Bold and Italic. I'm talking about custom styles.
First screenshot shows the default where I have selected the custom styles text within a paragram. The left dropdown toolbar is the Block Format toolbar - showing block level elements. As you can see, the second dropdown is the Styles toolbar but it says: Paragraph.... This is what we think should be changed to 'Styles'.
image

The second screesnhot (below) shows highlighted content that has been assigned the 'sexy text' CSS style. When selected the drop down says 'Sexy text' to indicate the assigned style for the highlighted content. That's fine but when my cursor is on an element without a set custom style, this dropdown says: "Paragraph" which is just confusing to clients (as mentioned above by another user). Firstly because it's not the set style for that element. Secondly, because it's right next to the Block Format dropdown which most of the time says Paragraph.
image

@Leilahodgkins
Copy link

Thanks for the responses above. I apologise for using the word 'amateur'. I truly did not intend to mean that the software or people working on it were not professional, only that this small detail may look that way on the surface to people who don't understand what is going on.

For what it's worth, I find both dropdowns useful because the simpler 'Paragraph' dropdown (with the paragraph and heading styles) is a super quick way to add headings or change a heading back into a paragraph. The other one with all the formats and styles is great because I can put custom styles in there and the position in the toolbar is convenient - I just wish they didn't both have the same label (or appear to have the same label) :-)

'Format' in the menu does almost the same thing so I can see why you say you don't need both but the toolbar dropdown is easier to use because it has fewer options.

@Wertisdk
Copy link

Wertisdk commented Jan 25, 2024

We also use the two dropdowns in a similar manner to @richardczeiger
block_formats - Semantic HTML document structure (paragraph and headings in our usecase)
style_formats - Non-standard styles or elements in a context aware manner. Image formats like shadow and rounded borders, table designs when a table is selected, highlighted boxes for paragraphs etc.

I have made a recording showing the setup in use.
https://github.com/tinymce/tinymce/assets/12416208/6110bb9a-80cf-4ae8-9feb-96ddb96c96f0

From my point of view the issue boils down to a single needed change as well:
Separate the block format default label from the style format default label so they have individual fallback labels

@TheSpyder Maybe instead of the concept of a fallbackFormat, could you instead supply all dropdowns with a "label" or "default label/selection" that can be translated and have that be the "fallback" value? The block format menu should be able to correctly identify whether the selection is a Paragraph, an item in the block_format list or an element not in the list in which case maybe the term Element or Block is more appropriate as the fallback value for that specific dropdown - and that would also be the "label" for the dropdown anyway right?

@TheSpyder
Copy link
Member

@richardczeiger this dropdown does support bold and italic. It supports any "format", even if a lot of the time all it's configured to show is styles (and the config name change reflects that).
https://fiddle.tiny.cloud/UH2f2mBq6g/3

It looks like we might be able to change the fallback to Formats in TinyMCE 7. We will consider making it configurable as a further update, semver allows us to add new config options in a minor release.

@richardczeiger
Copy link

That's great news Spyder!
I think we would all be happy with 'Formats' for now and the idea of making it customisable later.
Can't wait for v7! :)

@TheSpyder
Copy link
Member

Just merged in #9423. v7 should be out within a month, but the nightly build (and the 7-dev channel on TinyMCE fiddle) will be updated shortly. I'll close this for now, if customisability turns out to be a key requirement I think it's best to log a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants