Create a schema for "allowed_html" which provides a better config diff

This is still very relevant today. We should match ckeditor, for example from core/profiles/standard/config/install/editor.editor.basic_html.yml:

settings:
  plugins:
    ckeditor5_sourceEditing:
      allowed_tags:
        - '<cite>'
        - '<dl>'
        - '<dt>'
        - '<dd>'
        - '<a hreflang>'
        - '<blockquote cite>'
        - '<h2 id>'
        - '<h3 id>'
        - '<h4 id>'
        - '<h5 id>'
        - '<h6 id>'

I agree that this issue remains pertinent, especially considering the structure used by CKEditor in Drupal core.

Adopting a similar format for the "allowed_html" setting, as demonstrated in core/profiles/standard/config/install/editor.editor.basic_html.yml, would not only ensure consistency with CKEditor's configuration but also improve clarity and manageability for developers and site administrators.

Such alignment could greatly enhance user experience and reduce configuration errors.

This at minimum soft-blocks 📌 [PP-2] Make FilterFormat config entities fully validatable Postponed and potentially hard-blocks it.

Glad I found this issue, this is a problem every single time we change filter formats in any way, especially when (for example) adding new styles.

What do people think of an interim solution where we keep the existing unstructured string and at the very least sort the tags alphabetically? That would at least alleviate very hard to parse diffs like the following:

This is an example where a new style had been added to the table element, but all the other tags were randomly reordered.

#93++ — let's do that here so we can close this already ~100-comment long issue? 😄

Ok, the failures are in sort order, which is great! Adjusting the tests to match the new order is a good novice issue. Go through the tests that fail and update the expected order.

I'm not sure if we need an upgrade path, since an export will just save it the new order easily. :)

Getting the tags sorted in ckeditor requires some extra work since it is only implicitly coupled to the filterfotmat in core. There is an issue around that but lets do make sorting available publicly so we can also do it in that part of the code.

Hmm, not sure yet how to do this. CKEditor uses HTMLRestrictions for a lot of generation of the lists of tags. There is also the config form, and the SmartDefaultSettings. Those probably need adjusting to make sure we get sorted tags.

I agree with #97, I don't think we need an update path, but we do need to mention in the change record that saving after this update will trigger a lot of extra exports.

It's good to see that you already removed the novice tag again @bbrala, because this doesn't look very easy.

I honestly hate how the error measages are. This was quite the challenge to update the expected errors.

I think we are green now, but ill have a look at the changes first to see if i didnt add changes that sign it might be a bit break.

Changes look good, fixed one test, i think we should be green now. Preemptively setting to NR

I think overall this looks great, I have a tiny documentation nitpick and a small change I'd like to see in the tests.

Adressed the feedback.

All feedback that I had suggested is now fixed.

The change record here is for the previous solution, which is also still in the summary. Does that need a follow-up issue?

Also, I think this could use a change record/release note to inform site owners they will get a config diff the next time they export config and why.