Ckeditor5: Sticky toolbar

Created on 6 Apr 2018 · 13Comments · Source: ckeditor/ckeditor5

Is this a bug report or feature request?

🆕 Feature request

📋 Steps to reproduce

The current Document Editor demo should have a sticky toolbar, just like the Classic Editor. Without that, the editor is hardly usable.

If you'd like to see this feature implemented, add 👍 to this post.

build-decoupled-document docs improvement

Source

fredck

👍1

Most helpful comment

A document editor should be similar to the native word processors: It's the document (page) area that should scroll, but never the toolbar (or page). That's why the toolbar should remain static and the demo we have ATM on our website is... wrong.

I agree with you, @oleq. I have hacked the demo a bit and got the following, which I believe should be the right demo:

fredck on 9 Apr 2018

👍2

All 13 comments

cc @oleq?

Reinmar on 6 Apr 2018

I was wondering the same when implementing it but I decided this is a different use–case.

A document editor should be similar to the native word processors: It's the document (page) area that should scroll, but never the toolbar (or page). That's why the toolbar should remain static and the demo we have ATM on our website is... wrong.

OTOH... I see nothing wrong with using the sticky toolbar in this situation. I mean: it won't break anything. It's just about the complexity of the code.

oleq on 6 Apr 2018

It's just about the complexity of the code.

What if we use position:sticky?

Reinmar on 6 Apr 2018

No IE11, that's for sure. But this is not an issue. I'm not also sure what this boundary situation would look like with the native pos: sticky:

We make sure the toolbar won't cover the last 1-2 LOC. Is the native pos: sticky capable of such thing?

oleq on 9 Apr 2018

A document editor should be similar to the native word processors: It's the document (page) area that should scroll, but never the toolbar (or page). That's why the toolbar should remain static and the demo we have ATM on our website is... wrong.

I agree with you, @oleq. I have hacked the demo a bit and got the following, which I believe should be the right demo:

fredck on 9 Apr 2018

👍2

We make sure the toolbar won't cover the last 1-2 LOC. Is the native pos: sticky capable of such thing?

Another thing: I was unable to use the viewportTopOffset with pos: sticky. Setting top: 123px always moves the element, not only when it's sticky.

oleq on 9 Apr 2018

Another thing: I was unable to use the viewportTopOffset with pos: sticky. Setting top: 123px always moves the element, not only when it's sticky.

I don't understand how viewportTopOffset is related to pos:sticky. The former is our JS implementation and is not available (?) in the decoupled editor. The latter is CSS.

Reinmar on 9 Apr 2018

Our sticky toolbar implementation offers viewportTopOffset. We use it everywhere (demos, docs...).

My point was that if we decide to switch to the native position: sticky, we're losing this feature.

oleq on 9 Apr 2018

Being this a demo issue, I believe @m-kr is the one to call for action ;)

fredck on 9 Apr 2018

👍1

My point was that if we decide to switch to the native position: sticky, we're losing this feature.

Do we? What about position: sticky; top: 33px? Doesn't it have the same behaviour?

Reinmar on 9 Apr 2018

Do we? What about position: sticky; top: 33px? Doesn't it have the same behaviour?

No.

oleq on 9 Apr 2018

This solution with the scrollable editable area is the best, I can implement it without any hacks and, as @oleq wrote, it looks like Word 👍

m-kr on 10 Apr 2018

👍1

I don't agree with this at all. You are forcing the document editor into full screen only. You can't possible think that is the only use case that will ever happen with it... not everyone wants to throw out all their layout just to show an editor.

Also as for viewportTopOffset, we require it. But why can't it simply be a margin?