search

ckeditor / ckeditor5

Powerful rich text editor framework with a modular architecture, modern integrations, and features like collaborative editing.
https://ckeditor.com/ckeditor-5
Other
9.33k stars 3.68k forks source link

Custom unordered list markers are removed despite GHS #13872

Open jacekbogdanski opened 1 year ago

jacekbogdanski commented 1 year ago

📝 Provide detailed reproduction steps (if any)

Configure GHS to allow list-style-type attribute:

const ghsConfig = {
  allow: [
     {
        name: /^(?:ul|ol|li)$/u,
    styles: [ 'list-style-type' ]
      }
  ]
}

Feed the editor with HTML like:

<ul style="list-style-type: '¶ '">
  <li>item 1</li>
</ul>

✔️ Expected result

The custom list marker is preserved.

❌ Actual result

The custom list marker is removed from the HTML.

❓ Possible solution

If you have ideas, you can list them here. Otherwise, you can delete this section.

📃 Other details

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

Witoso commented 1 year ago

Works correctly for the Document lists, @jacekbogdanski any need from your side to add it to the List, etc.?

Witoso commented 1 year ago

Ok, I found a case where it doesn't work. Without DocumentListProperties plugin it works correctly, with this plugin the list-style-type is lost.

Fix scope: Given I have DocumentList, DocumentListProperties, and GHS configured, the list-style-type is preserved in the styles attributes.

Badlapje commented 10 months ago

Is it possible to add custom list markers in a less round-about way? I'd love to be able to extend the plugin, or better still: add configuration so that i can add custom "markers"/list-style-types

niegowski commented 9 months ago

I can see 2 options, IDK which is better:

  1. The upcast converter for the list style attribute should not consume unknown values, those should be handled by GHS.
  2. The list style should allow unknown values in the model but it will not be reflected in the UI (same as supportAllValues option for font family, font size, etc.)
Witoso commented 9 months ago

Question from my side would be, which one brings us a step closer to the feature of custom list markers (defined maybe in the UI or by integrator) but is a good starting point to unblock current cases.

niegowski commented 9 months ago

Question from my side would be, which one brings us a step closer to the feature of custom list markers (defined maybe in the UI or by integrator) but is a good starting point to unblock current cases.

I think we should go with option 2 so it will be consistent with the font features.