Integrate "text formats selector" into CKEditor toolbar

quicksketch is going to work on improving reducing the heaviness/noise of the text format help. I don't think he's going to solve it in the way you propose though.

I think there are very significant problems with your proposal. At the most basic level, the UI you propose will break down as soon as there is one text format that either uses either a different text editor or no text editor at all (which is the case for the "Restricted HTML" format out of the box).

You've filed this under the "Seven theme" component, but what you propose is really within the scope of the CKEditor module. I'm pretty sure this should be solved at the filter.module level though — a CKEditor-specific improvement is unlikely to be acceptable.

So my suggestions aren't actually quite the same as what @Bojhan is trying to accomplish. My suggestions basically only encompass the filter tips. I think that we should move (some of) them to a button in the toolbar for "Help" (represented as the typical "?" button).

The importance of handling the text format dropdown is reduced, but clearly not eliminated by #788114: Unprivileged users should only get one text format by default, where we made it so that both anonymous and normal authenticated users don't get a choice of format at all. @floretan mentioned to me at Drupalcon that he's working to implement a "Better Formats"-ish ability into the text.module to enable the list of formats to be changed per field. If that were to happen, then it would enable users to further eliminate the probability of multiple formats.

Anyway, so here are my suggestions: 1) Eliminate most filter tips when CKEditor is enabled. Those that still need tips, put them into a "Help" button (which provides a dialog). 2) Just leave the text formats dropdown where it is if multiple formats are supported.

The first step to getting a Better-Format-ish solution is to fix the following missing functionality in the text_format form element provided by the filter module: #1423244: #allowed_formats property for #type 'text_format' to filter available formats. When this is in, we can integrate it into the text module: #784672: Allow text field to enforce a specific text format.

are we going to by default provide only one option?

All anonymous and authenticated users by default will only get one option (so the dropdown won't show at all); it's like that already on D8 installs today. However for users in the administrator role (or any user with multiple roles), it's likely that they'll still have access to multiple formats, so the dropdown will still exist in a lot of situations unfortunately.

whether people expect more under help than just text-format information.

I don't think people expect/need help for the filters if a WYSIWYG is present, since the behavior of the WYSIWYG will reflect the filtering that is happening on that field. For example there shouldn't be a need to say that only local images are allowed, since the image dialog should throw a validation error if remote images are attempted to be used. Displaying the list of allowed tags is clearly even less necessary. However there could be some help text that is still relevant, but not important enough to give the space beneath the field like we do currently. My thoughts on help text + CKEditor are something like this:

• Each filter provides filter tips like it does currently. These filter tips are displayed when no editor is active.
• Each editor gets to set a property whether they want the default help at all. For an editor like CKEditor, we would set this property to FALSE. Something like BUEditor Editor module sets the #access property on the entire help section to FALSE.
• If the editor requests no filter default help, the responsibility of displaying help is shifted to the editor implementation. In the case of CKEditor, we'll provide a button to open the CKEditor-specific help in a dialog. CKEditor will provide its own plugin (and alter hook) for generating the help displayed in the help dialog.

All of this doesn't help with the text format select list, however I'm not sure we can integrate the select list into the toolbar of CKEditor. The jumping around of this option when switching between editors would be a significant source of confusion.

the only usability question I would have is whether people expect more under help than just text-format information.

I misinterpreted this question. Yes, I think it's entirely possible that additional help would be needed besides just help that corresponded with filters. Because CKEditor would provide its own Plugin/hook for help, any module could put in any help it wanted, not just filters. My favorite help I've seen is the help displayed by Confluence, where all the keyboard shortcuts are displayed. Github's help is really pretty good too, but it's mostly around how to type Markdown syntax.

This issue has been silent for almost 10 weeks.

Unless quicksketch or somebody else is going to work on this, I don't think this will happen.

I'm still interested in this, but my distaste for D8 has halted my work on core. Maybe in a couple months/years I'll get over it and deal with the reality of new Drupal. I think this is a good feature that should stay open as an issue, even if we don't have a plan to immediately execute on it.

#11: no time, more important priorities!
#12: Sure, no problem :) Sorry to hear your distaste has grown so much! :(

Per #12, marking as postponed. Not blocked on any issue, but on somebody taking it on. Having this marked postponed makes it easier for me as maintainer of this component to keep track of things.

#15: eh, you're kidding, right? We spend a huge amount of time on things that aren't on the Spark roadmap. Usually not on smaller issues like this one, but broader changes in D8, where they need extra man power to get very important, D8 release blocking/delaying things fixed. But also for example the automatic filter setting updating based on CKEditor toolbar configuration was not part of Spark's goals; we spent a lot of time on it because it was the right thing to do!
We currently need to focus on getting D8 *done*, not keep working on refining and refining.
I'd love to refine many things even more, but we must now work on stabilization first (fixing majors and criticals), refinement second.

practice in core isn't to postpone it because the maintainer has no time. We postpone it, because something else needs to be done first.

I think @Bojhan is right in this regard. This isn't really postponed in a way that would prevent anyone else from working on it. Maybe another interested person may pick it up.

Yes, true, that is fair.

A phase 1 of this is now in #2098071: Disable filter guidelines for a text format if that text format has a text editor enabled.

Updated issue summary.

#2098071: Disable filter guidelines for a text format if that text format has a text editor enabled has landed. Do we still believe that something like

is worth pursuing?

When reading #4 and #7, it seems like this issue wants to "provide meaningful help when using CKEditor"?

+1 for #22, I like the idea of getting back all that wasted space taken up by the text formats info.

#23: well, the text format's filter tips are already gone when using a text format, as of #2098071: Disable filter guidelines for a text format if that text format has a text editor enabled. Further: only admin users will see the text format <select> in Drupal 8, because anonymous and regular authenticated users will each only have access to 1 text format. So what you see in #22 would only benefit administrator users.

Not sure how relevant it is then. I know personally as an admin user I always click the "source" view as part of the WYSIWYG if I want to see the HTML.

#25: I agree on the strongly diminished relevance.

The most annoying part — text format filter info — is gone when using a text (WYSIWYG) editor since #2098071: Disable filter guidelines for a text format if that text format has a text editor enabled.

The remainder: moving the text format selector itself into CKEditor is at best something that brings a very minor improvement:

1. very few people will see it
2. for those few people that see it, it's questionable whether this is an improvement at all (especially if you consider that other text formats might use different text (WYSIWYG) editors and hence they would need to implement that too, and the location/styling of the text format selector would vary depending on the text editor).
3. this would be a PITA to implement, and it is impossible to make this tie in elegantly/non-disruptively to the drag-and-drop toolbar configuration UI

Because the added benefit is clearly questionable, I'm closing this issue. If we want to tackle this again, we should open a more focused issue, with better reasoning, that takes into account that #2098071 is already a big step forward.