<dl> <dt> <dd> by introducing "Manually editable HTML tags" configuration on Source Editing

Currently awaiting information from the CKEditor 5 team.

Got a response from @Reinmar:

Similar to - can be enabled with GHS, but definition lists are not on our roadmap as a real feature.

Alright, so let's do what we did for #3222842: <a hreflang> + <blockquote cite> and use #3216021: Automatically use CKE5's General HTML Support feature on text formats without any TYPE_HTML_RESTRICTOR filter + add `sourceEditing` button to bring this to Drupal.

Except that unlike for <cite> (where we can hinge this off of blockquote support), there isn't a clear way to enable these tags conditionally… 🤔 Ideas?

You just inspired me to think of an alternative proposal, @bnjmnm! 😄

Since you will only be able to modify this kind of content properly when using the sourceEditing toolbar item … what if we associated those tags with sourceEditing? 🤓

Or … what if we take this further … and we provide a configuration UI for sourceEditing?! So you can choose which additional tags to list, but hey, you'll have to be comfortable writing HTML source code to be able to use them! And so if/when you remove sourceEditing, you'll also make all those pesky weird/obscure/exotic tags disappear!

This … well … weirdly excites me 🙈🤣 REALLY curious about your thoughts, @bnjmnm!

🤩 Exciting!

Marked #3222840: <ol start>, #3224256: <h* id> (or more generically: <$block id>) and #3220534: [PP-1] [needs upstream feature] Type attribute not configurable for <ul> and <ol> as blocked on this per @bnjmnm 😄 (Not yet closing them, but likely/hopefully we will be able to close them! 👍)

Also bumping to Major and marking as feature, to match the increased scope.

Awesome! 🤩

This is nothing short of magic 👏

Merged in #3215600: Unclear relationship between "plugin_config" in *.ckeditor5.yml and Drupal plugin settings to generate that configuration, resolved conflict. Hopefully that makes it slightly easier for you to continue here, @bnjmnm 😊

Pushed forward the one area deep down I was concerned about, I'm quite happy with the result — curious what you think, @bnjmnm 😊

The comment stream from GitLab here on d.o is an impossible-to-parse clusterf… mess, but the following two comments walk you through it step-by-step:

1. https://git.drupalcode.org/project/ckeditor5/-/merge_requests/84#note_38249
2. https://git.drupalcode.org/project/ckeditor5/-/merge_requests/84#note_38253

Finally: I'm happy to pull out the validation piece (which I added there) out of this issue and into a separate one. That'd make this MR/issue more focused.

marked this merge request as draft

I … did? 🙃

Apparently DrupalCI only runs when a merge request is marked "ready" 🤷‍♂️

Self-assigning because I'll push this forward tomorrow! :)

I was getting concerned about repeating parsing logic for how to interpret “elements”/“allowed tags” strings. Each time slightly different. I feel much safer now that they’re all reusing the same logic. That's what I did in those last 4 commits.

I think we should go further, but that’s for a follow-up issue.

Assigning back to you for the last few (literally less than a handful) of threads that need attention! 🥳

I think we should go further, but that’s for a follow-up issue.

Created #3228334: Refactor HTMLRestrictionsUtilities to a HtmlRestrictions value object for this.

One more follow-up created: #3228343: Follow-up for #3222852: "change" event is triggered only once for Source Editing's "Manually editable HTML tags" form item.

Replying here since finding the thread on the GitLab UI is impossible :/

I think it would be best to add unit tests for everything in HTMLRestrictionsUtilities, but they can probably be done in a followup. Having this at least establish a standard for how it would happen make the followup easier to get started with.

+1 — IMHO that's part of #3228334: Refactor HTMLRestrictionsUtilities to a HtmlRestrictions value object. Clarified the issue title there: #3228334-2: Refactor HTMLRestrictionsUtilities to a HtmlRestrictions value object.

IMHO the only truly essential remaining thing to clarify is https://git.drupalcode.org/project/ckeditor5/-/merge_requests/84#note_38845 — where I wrote this on src/Plugin/Validation/Constraint/ProcessLikeFundamentalConstraintInterface.php:

This comment is super helpful, thank you!

Unfortunately, I've noticed that the `allowed_tags` setting for `FilterHtml` becomes editable again due to the check in `ckeditor5_form_filter_format_form_alter()` to _not_ modify the form if there's a fundamental compatibility error.

We can fix that by either:

1. Changing the logic in `\Drupal\ckeditor5\Plugin\Editor\CKEditor5::buildConfigurationForm()` to only set `ckeditor5_fundamentally_compatible=true` if the truly fundamental compatibility constraint is violated
2. Changing the logic elsewhere.

Ideally I'd like to not add that interface — because special-casing it in \Drupal\ckeditor5\Plugin\Editor\CKEditor5::validatePair() and then lots of code calling ::validatePair() is why this problem is occurring I think.

Pairing on this might be a good idea?

One more follow-up, discussed ~1.5 week ago: #3228346: Follow-up for #3222852: revert ineditable attributes (<blockquote cite> and <a hreflang>) now that Source Editing plugin can handle arbitrary elements & attributes.

Whew, new multi-hour deep-dive onto those 2 last commits WRT config forms. Created #3228465: Final pass over the public API prior to creating core merge request and #3228477: CKEditor5PluginConfigurableInterface should extend PluginFormInterface and ConfigurableInterface instead of adding ::settingsForm(). Those are not caused by this issue, they were just made more apparent by this issue. Especially the latter.

So the fact that f6722cc4 was green is … unexpected. Created #3228580: Follow-up for #3222852: additional test coverage for real-time validation race conditions for fixing that. I already have an idea for how to test this.

Well well … turns out that 45e7159 causes the "new text format" scenario to fail. Remarks in #24 still stand.

Fixed in f0773d9.

Discussed with @bnjmnm earlier today — he was happy with this being the final set of changes. I needed two more fix-up commits for edge cases, but it's still fundamentally the same as what we looked at together.

So … finally this monster has been slain!

🚢