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

Implement different toolbars for Mobile #22

Closed
ipeychev opened this issue Aug 14, 2014 · 12 comments
Closed

Implement different toolbars for Mobile #22

ipeychev opened this issue Aug 14, 2014 · 12 comments

Comments

@ipeychev
Copy link
Contributor

Current editor toolbars are suitable for Desktop but not for Mobile. We have to implement new toolbars. One idea is to place them just above the native keyboard of the phone/tablet. To be discussed with the UX.

@trshafer
Copy link

+1

@dandv
Copy link
Contributor

dandv commented Aug 28, 2015

👍 I've compared ~50 WYSIWYG editors, and Alloy was one of the most promising.

@ipeychev
Copy link
Contributor Author

@dandv Great! A note about the numbers here - "alloy-editor-all-min.js" is actually 598KB and not 800KB. Also, the gzipped version is about 167KB.

@Heilemann
Copy link

Is there any movement on this? I haven't taken a look at the codebase yet, but would it be possible to do a mobile-specific toolbar without too much fuzz?

@ipeychev
Copy link
Contributor Author

Mobile toolbar is the last problem here. We got stuck not with the Toolbar, but with the fact that managing selection on the mobile browsers wasn't working properly. Any Toolbar operates on the selection, and we were unable to properly control it (to get its position, etc.) on the mobile browsers. However, more than 6 months passed since this time, we updated several times CKEditor's engine, so maybe it is time for another iteration.

@jbalsas
Copy link
Contributor

jbalsas commented Feb 1, 2016

I agree, we will try to look into this again.

However, a lot of the issues might come from CKEditor itself, and I'm not sure there's been a lot of effort around mobile support for 4.x... we might have to wait until 5.x to get a decent mobile support from them, but we'll definitely investigate!

@hiddentao
Copy link

I'd really love this too. Until then, if I want to have the Toolbar to always show in a fixed position on the page should I be doing something similar to what's in your guide?

@ipeychev
Copy link
Contributor Author

ipeychev commented Feb 2, 2016

Hello,

We officially don't support fixed toolbar (because the purpose of AlloyEditor is to provide context toolbars and buttons), but with a bit of hacks you should be able to do it. If you don't like this approach, you are free to create a toolbar, yes.
And, btw, this will not make the toolbars work automatically on mobile, see here.

Thanks,

@kaushikbarodiya
Copy link

Hey @ipeychev ,

Is there any workaround for managing selection on mobile browser. Also the add button is not visible on mobile browser.

Can you provide some help.

Thanks,

@ipeychev
Copy link
Contributor Author

Mobile support is targeted for 2.0

@duracell80
Copy link

duracell80 commented May 3, 2018

Have there been any other movements towards mobile on CK?

There is a bug filed for the reason why the context menu idea can't work on mobile.
#767

With iOS and Android capturing the users text selection at the OS level and presenting text operations naively it seems odd to think that Alloy's context menus could work. Fixed menus would be the only way forward for mobile.

For what it's worth I'll offer a possible solution ... why trigger the context toolbars on text selection? On desktop it's at first not very obvious but on mobile doesn't work at all. Trigger the context menus with a simple icon in a square button that appears in addition to the iOS or android text selection toolbar. The user then touches this rather large hit area for fingers.

Is there any discussion about moving to TinyMCE instead for Liferay 7.2?

@wincent
Copy link
Contributor

wincent commented Sep 30, 2019

Closing due to inactivity. Issue was filed in 2014. Back in 2016 we thought we might do this for v2.0, but it is 2019 now, v2 was released, and we didn't have the resources to prioritize it. When/if this pops back on our roadmap we'll create a new issue for it.

@wincent wincent closed this as completed Sep 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants