GHS: `name: /.*/` should allow arbitrary HTML elements, including custom/unofficial ones

[wimleers]

Sibling issue of #10891 and #11104? 🤔

I cannot configure CKEditor 5 to not strip away custom elements (f.e. <drupal-media>) or even arbitrary elements (f.e. <yo>).

📝 Provide detailed reproduction steps (if any)

1. Load the htmlSupport.GeneralHtmlSupport and sourceEditing.SourceEditing CKE5 plugins, with the following htmlSupport config:

   {"allow":[{"name": /.*/}},"attributes":true,"classes":true,"styles":true}]}

2. Access a CKEditor 5 instance, use the Source button to paste this:

   <p>p</p>
   <yo>yo</yo>

3. Click the Source button again to access the rendered HTML representation
4. Click the Source button again to access the raw HTML representation

✔️ Expected result

Exactly what we pasted:

<p>p</p>
<yo>yo</yo>

❌ Actual result

<p>p</p>
<p>yo</p>

📃 Other details

• Browser: N/A — reproduced in Chrome and Firefox.
• OS: N/A — reproduced in macOS Big Sur
• First affected CKEditor version: v32.0.0
• Installed CKEditor plugins: see above.

[Reinmar]

Sibling issue of #10891 and #11104? 🤔

Unfortunately no. Support for custom elements is a different thing. CKEditor needs to understand the meaning of an element to know how to handle it. This is impossible for custom elements unless someone can provide such information.

In fact, CKE4 doesn't support custom elements unless you modify its DTD manually. I've checked that (to my surprise) it will accept custom elements (assuming ACF passes them), but this was never officially documented and is quite buggy (e.g. such elements are lost on copy-paste).

So, assuming that DTD's modification is a must to make them work reliably – that's the same story for CKE5. You can register custom elements in GHS's schema. But you need to know their names.

We'll need to discuss how this was handled in Drupal becuase I didn't know that someone could enable elements via a wildcard.

[wimleers]

We discussed this a week ago in our meeting. I believe you got the information you needed then? 😊

I think the conclusion we reached was to follow @dawidurbanski's proposal: to implement this using the same approach as CKEditor 5 uses for HTML comments. That is: don't treat it as HTML but just something arbitrary that would be stored and wouldn’t be visible in the editing view, only in the dataDowncast.

[Reinmar]

Options:

• Like-HTML comments approach. Keep entire subtrees starting from custom elements as markers in the model. Render them only in the data view. 
  • Pros:
    • It should be the easiest option.
    • Ensures data retention.
  • Cons:
    • Confusing that they don't render in the editing view (and unlike HTML comments that are invisible, custom elements usually are).
    • Might slightly change their position in the tree due to the node -> marker -> node conversion path.
• As elements in the model. Keep them as elements in the model and render as widgets in the editing view.
  • Details:
    • Keep them in the model as <htmlCustomElement rawData="<myCustomElement>raw HTML content</myCustomElement>"></htmlCustomElement>
    • Allow htmlCustomElement everywhere (just like htmlScript and htmlStyle). Define isInline: true
    • Editing view:
      • option 1: or don't render at all (similar to <script> and <style> support)
      • option 2: render as widget with a RawElement with the rawData rendered inside
  • Cons:
    • What about XSSes if we render the preview?
      • We've got a mechanism to strip unsafe stuff already – we could use it here.
• Use HTML Embed feature.
  • Similar to the previous option, but would require more work because we don't support inline HTML Embeds yet.
  • But the UX would be nice.
  • It's a potential path for the future.

Additional remarks:

• This handling does not have to be perfect in terms of UX. This is a fallback that's meant to ensure data retention. If anything aims for a better UX and know the elements with which they are dealing, they can extend the data schema.

[Reinmar]

Decision: "As elements in the model" + option 1 (no preview in the editing view for now).

[Reinmar]

Example content that we need to handle:

<p>Foo</p>

<custom>x</custom>

<custom someattr>
    <p>Bar</p>
    <custom2 someotherattr=1234>
        foo
    </custom2>
</custom>

<p>
    Foo
    <custom someattr />
    <custom someattr />
    <custom someattr /><custom someattr />
    Bar
    <custom>Bom</custom>
</p>

[Reinmar]

Making sure that GH won't lose this comment (sorry for a screenshot :P):