Skip to content
This repository has been archived by the owner on Jun 26, 2020. It is now read-only.

Fix placeholder over media embed. #1749

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Fix placeholder over media embed. #1749

wants to merge 3 commits into from

Conversation

jodator
Copy link
Contributor

@jodator jodator commented Jun 19, 2019

Suggested merge commit message (convention)

Other: The placeholder will not be shown for widgets. Closes ckeditor/ckeditor5#1684.


Additional information

@oleq: I've update the PR so the widgets (checked by a custom property) are considered not needing a placeholder.


OLD:

I've been fiddling with the placeholder for some time to check what caused the ckeditor/ckeditor5#1684 and it turned out that the placeholder was enabled for "emptish" elements. The "emptish" element is such that has no children or all of the children are UI Elements.

I'm not sure why this was created this way (maybe some collaboration features? but I doubt it) but this check would give false positive for widget with only UIElement children - this is what happens with MediaEmbed.

So taking this into consideration I don't see that UIElement should dictate that element is empty in regards for showing a placeholder.

The other change that we might consider is to tie emptiness check to the model. I didn't go this route as currently the placeholder operates on the view solely.

ps.: The isWidget check was also discarded.

@jodator jodator requested review from scofalik and oleq and removed request for scofalik June 19, 2019 08:30
@coveralls
Copy link

coveralls commented Jun 19, 2019

Coverage Status

Coverage remained the same at 100.0% when pulling b772835 on t/ckeditor5/1684 into c057a94 on master.

@oleq
Copy link
Member

oleq commented Jun 24, 2019

The isEmptyish check has been introduced by @scofalik in 6a66f6e and solved https://github.com/ckeditor/ckeditor5-engine/issues/1018 which, in turn, was a piece of https://github.com/ckeditor/ckeditor5-engine/issues/1017. Sounds like there was a solid reason for that check (something about markers, which makes sense on second thought).

Can you investigate that? Because it looks like your PR could break some core functionality.

Copy link
Member

@oleq oleq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot merge this without the research as pointed out in #1749 (comment).

@jodator
Copy link
Contributor Author

jodator commented Jun 24, 2019

We cannot merge this without the research as pointed out in #1749 (comment).

Thanks bisect & git log master :D I feel so bad for not digging it properly :( - you're right the check should be better then. I'll check on this and I'll update the PR.

@jodator
Copy link
Contributor Author

jodator commented Jun 25, 2019

@scofalik & @oleq:
OK so after some fiddling I can see that this check is done for markers case mostly. The placeholder must be visible when there are markers in empty paragraph or empty caption.

The solution for this could done by:

  1. CSS override for media embed - do not show placeholder there.
  2. Check if element is a widget and consider it always not empty either by:
    a. isWidget() util
    b. checking custom property element.getCustomProperty( 'widget' )

As the markers are hidden in the UI similarly (by CSS) with a placeholder active I think that we might go with CSS solution. But OTOH such solution is not clean enough - it will add the ck-placeholder class to the widget which is not totally OK. So I'd rather go with 2b solution as the engine should not import widget repository.

@oleq
Copy link
Member

oleq commented Jun 25, 2019

I'm for 2b. 2a would add a ckeditor5-widget dependency to ckeditor5-engine which we don't need (want?).

@jodator jodator force-pushed the t/ckeditor5/1684 branch from b2203e7 to 6fb56bd Compare June 25, 2019 10:26
@jodator jodator requested a review from oleq June 25, 2019 10:29
@@ -153,6 +153,12 @@ export function needsPlaceholder( element ) {
return false;
}

// If the element is a Widget, always consider it a non-empty and thus not needing a placeholder.
// https://github.com/ckeditor/ckeditor5/issues/1684
if ( element.getCustomProperty( 'widget' ) ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the second thought, that would be the only place in the codebase other than isWidget() from ckeditor5-widget that calls getCustomProperty( 'widget' ) 😛

Maybe we could use ckeditor5-widget as an engine dependency after all. I'm not sure about consequences, though. cc @Reinmar.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah... it might be a cycling dependency then... or widget being an engine feature :P.

At the current state I rather have this check then importing isWidget() but let's see @Reinmar 2¢.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I have nothing against the current state (element.getCustomProperty( 'widget' )) and some improvements in i26 as long as we don't change dependencies in i25.

Copy link
Member

@oleq oleq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

The only question is whether to isWidget() or to getCustomProperty( 'widget' ).

@jodator
Copy link
Contributor Author

jodator commented Jun 27, 2019

After F2F talk with @Reinmar I'll updat this PR with checks in the schema so the needsPlaceholder() method will also get editingController.

@jodator
Copy link
Contributor Author

jodator commented Jul 1, 2019

@Reinmar I'm working on the rewrite so the needsPlaceholder() function would check model, not the view.

This looks like a bigger change because the enablePlaceholder() function and some other functions in this feature must also accept the editing instead of the view.

It is not a big issue in most places but it would require some more work at least in the ImageCaptionEditing because in the downcast conversion it first enables the placeholder and as the next step it binds view and model elements so the needsPlacesholder() fails on checking the schema.

TL;DR: I don't think we can squish the rewrite in the 25 milestone. My suggestion is that we could use the current state (checking for the widget) in 25 and rewrite it in 26.

@scofalik
Copy link
Contributor

scofalik commented Jul 2, 2019

To be honest, I think that the problem is using UIElement where we shouldn't. Media embed element is not a UIElement. We use UIElement only because we don't have a better option as far as view element types go. So maybe we should go that way?

@Reinmar
Copy link
Member

Reinmar commented Jul 2, 2019

WDYM? I remember you were proposing introducing new element types. Would that (IIRC) RawElement help here?

@scofalik
Copy link
Contributor

scofalik commented Jul 2, 2019

I am not sure why exactly UIElement was used here because I haven't been developing the feature so I don't know what problems EmptyElement or ContainerElement had. All I am saying is that using UIElement for non-UI (read: content meaningful) elements is not the indented use case for UIElement. So saying that "old placeholder solution is wrong because UIElement is used in media embed" might be approaching the problem from an incorrect side. Same with introducing additional checks or extending schema. Although this is something I like because it might be useful for plugins creators.

@Reinmar
Copy link
Member

Reinmar commented Jul 2, 2019

I am not sure why exactly UIElement was used here because I haven't been developing the feature so I don't know what problems EmptyElement or ContainerElement had.

We need custom rendering, without going through our rendering engine.

@jodator
Copy link
Contributor Author

jodator commented Jul 24, 2019

Guys, so the RawElement would play nice here (https://github.com/ckeditor/ckeditor5-engine/issues/1643). Am I right? From what I can see it would act similarly as UIElement - it should allow creating custom HTML code inside base elment - just like UIElement does but from model POV it will act like any other element.

@scofalik
Copy link
Contributor

I think so.

@Reinmar
Copy link
Member

Reinmar commented Jul 24, 2019

Yep, I think so too. I wasn't sure initially about the semantics of this type of element and the difference between UI and Raw, but I think https://github.com/ckeditor/ckeditor5-engine/issues/1643#issuecomment-514653753 makes it clear and in that case, it would solve this case.

@scofalik
Copy link
Contributor

What is the status of this PR ?

@jodator
Copy link
Contributor Author

jodator commented Sep 12, 2019

What is the status of this PR ?

I'm going to implement RawElement or whatever it would be called. At the moment the work is staled.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Placeholder does not disappear after inserting media
6 participants