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

Attributes hoisted to paragraph are not converted when selection is in another place #4142

Closed
Reinmar opened this issue Aug 11, 2017 · 5 comments
Assignees
Labels
package:engine resolution:expired This issue was closed due to lack of feedback. type:bug This issue reports a buggy (incorrect) behavior.

Comments

@Reinmar
Copy link
Member

Reinmar commented Aug 11, 2017

This leads to breaking the X position of the caret:

aug-11-2017 09-32-47

The <strong> element should always be in that paragraph. That would allow the selection to natively land in there when pressing up/down arrows so we wouldn't need to fix it (breaking the X position).

@Reinmar
Copy link
Member Author

Reinmar commented Aug 11, 2017

The problem here is that we're converting attributes of the selection (which inherits attributes from the paragraph once it lands there). We'd need to somehow convert element attributes to attribute elements (fun with words!) too so those attribute elements don't disappear.

@scofalik scofalik self-assigned this Oct 4, 2017
@scofalik
Copy link
Contributor

scofalik commented Oct 4, 2017

I've pushed branch t/1071 ckeditor/ckeditor5-engine@3b797c6 with one of possible solutions. The solution is so that we make sure that we don't touch attribute elements created for stored attributes during selection conversion.

I don't like this solution much, I have a feeling that it is unstable / uncomplete (although it works and makes sense). It uses the same flow for selection conversion as it did, but:

  • it takes extra care now when breaking attributes (effectively removing empty attribute elements),
  • and when wrapping elements when similar element is next to wrapped position (this is a "no change" in view, but in fact a new view element is created and it makes a difference for view->dom conversion).

We could try creating attribute elements for stored attributes during "normal conversion". It also makes sense and sounds more stable. But there is still problem with breaking and wrapping attributes because we have to do it if element is not empty. So I am afraid that we would need the same conditions anyway.

@mlewand mlewand transferred this issue from ckeditor/ckeditor5-engine Oct 9, 2019
@mlewand mlewand added this to the backlog milestone Oct 9, 2019
@mlewand mlewand added status:confirmed type:bug This issue reports a buggy (incorrect) behavior. package:engine labels Oct 9, 2019
@pomek pomek removed this from the backlog milestone Feb 21, 2022
@CKEditorBot
Copy link
Collaborator

There has been no activity on this issue for the past year. 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

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still 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 resolution:expired This issue was closed due to lack of feedback. and removed status:stale labels Jan 15, 2024
@CKEditorBot CKEditorBot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 15, 2024
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. type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Development

No branches or pull requests

5 participants