Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Markers directly in document fragment are always downcast to element #9463

Closed
scofalik opened this issue Apr 13, 2021 · 2 comments
Closed

Markers directly in document fragment are always downcast to element #9463

scofalik opened this issue Apr 13, 2021 · 2 comments
Labels
package:engine resolution:expired This issue was closed due to lack of feedback. status:stale type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@scofalik
Copy link
Contributor

📝 Provide a description of the improvement

This is a follow-up to #9460.

After markers downcast is enabled in a document fragment, there is one problem with it. When using markerToData, the marker is always downcast to element, instead of an attribute. This is because everything (including text) is enabled inside a document fragment. markerToData relies on schema check and whether $text is allowed at given position to decide whether element or attribute should used.

As a result, we get following conversion:

<marker-start name="foo"></marker-start><p>Abc</p><marker-end name="foo"></marker-end>

Instead of:

<p data-marker-start-before="foo" data-marker-end-after="foo">Abc</p>

Which is different if the same content would be inside a $root. OTOH, we need to have text allowed inside a document fragment. This makes the change difficult, we need to decide if we want to change the logic behind placing attributes instead of elements for markers.

@scofalik scofalik added type:improvement This issue reports a possible enhancement of an existing feature. package:engine labels Apr 13, 2021
@CKEditorBot
Copy link
Collaborator

There has been no activity on this issue for the past two years. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

@CKEditorBot
Copy link
Collaborator

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).

@CKEditorBot CKEditorBot added the resolution:expired This issue was closed due to lack of feedback. label Oct 13, 2023
@CKEditorBot CKEditorBot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:engine resolution:expired This issue was closed due to lack of feedback. status:stale type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

No branches or pull requests

2 participants