MediaEmbed: Rename <oembed> to <o-embed> for custom elements compatibility

[tony]

I propose changing the name of <oembed> to write <o-embed> for forward compatibility with custom elements per #2737

📝 Provide a description of the improvement

Media embed saves <oembed>, but in the WhatWG specification requires a dash/hyphen (1, 2):

These requirements ensure a number of goals for valid custom element names:

They start with an ASCII lower alpha, ensuring that the HTML parser will treat them as tags instead of as text.

They do not contain any ASCII upper alphas, ensuring that the user agent can always treat HTML elements ASCII-case-insensitively.

They contain a hyphen, used for namespacing and to ensure forward compatibility (since no elements will be added to HTML, SVG, or MathML with hyphen-containing local names in the future).

They can always be created with createElement() and createElementNS(), which have restrictions that go beyond the parser's.

Apart from these restrictions, a large variety of names is allowed, to give maximum flexibility for use cases like <math-α> or <emotion-😍>.

This will permit systems like LitElement, Stencil and others to fill support for embeds.

📃 Other details

• Browser: Any
• OS: Any
• CKEditor version: 26
• Installed CKEditor plugins: MediaEmbed

Ideas:

That change should be backward compatible so it doesn't break existing HTML.

As a first step, prepare MediaEmbed to handle different tags:

• An option such as preferredElementName can be set,
• An option like elementNames for tags that should be detected as media embeds

Later:

• An option like migrateToPreferredTagOnChange can be turned on to implicitly update existing tags to the preferred tags

  mediaEmbed: {
    // default: ['oembed', 'o-embed']
    elementNames: ['oembed'],
    // default: 'oembed', in a later version, `o-embed` can be the default
    preferredElementName: `o-embed`,
    // default: false
    migrateToPreferredTagOnChange: true,
  }

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[Reinmar]

I'll quote myself from the PR (#9375):

As for the solution – initially, I wasn't sure whether making this configurable is the right direction. If this feature's output is configurable this way then why not every other's? We need to be cautious in such cases.

However, I think we should ask ourselves why this particular feature got this PR and no other. I think the answer is that it uses a non-standard HTML output and hence there's no convention we're able to follow (BTW, I wouldn't go with o-embed too as why would the o be separated from the rest of the name? what about features that are undividable single-word?). In such case, making the output configurable makes more sense, even though it's always modifiable via custom converters.

[tony]

As for simplifying the configuration, another PR has been made at #9418

(BTW, I wouldn't go with o-embed too as why would the o be separated from the rest of the name?)

Do you have an alternative to o-embed to suggest?

Custom elements require a hyphen: https://html.spec.whatwg.org/#valid-custom-element-name

I am flexible as to the element name being something else. Please let me know if you have any suggestions!

I picked o-embed because the standard being emulated is oEmbed, a hyphen is required for custom Elements and it felt intuitive/familiar to me. Probably due to crossing paths with common slugification and inflection libraries (example: https://www.npmjs.com/package/decamelize, https://www.npmjs.com/package/camelcase, https://api.rubyonrails.org/classes/ActiveSupport/Inflector.html, https://pypi.org/project/inflection/)