search

ckeditor / ckeditor5

Powerful rich text editor framework with a modular architecture, modern integrations, and features like collaborative editing.
https://ckeditor.com/ckeditor-5
Other
9.59k stars 3.7k forks source link

The font size and font family plug-ins only operate on values they have been configured with #983

Closed davidpolberger closed 4 years ago

davidpolberger commented 6 years ago

Is this a bug report or feature request? (choose one)

🆕 Feature request

v1.0.0-beta.2, customized to include the font size and font family plug-ins.

📋 Steps to reproduce

  1. Execute the following code: editor.commands.get("fontSize").execute({ value: 11 }), where the fontSize plug-in has not been configured with the numeric font size 11.

✅ Expected result

The font size should be applied regardless of whether the plug-in has been configured with the given font size.

❎ Actual result

Nothing happens.

📃 Other details that might be useful

(This issue also affects the font family plug-in, which also does not apply values it has not been configured with.)

This issue makes it hard to allow users to type custom font sizes, which is standard in word processors. While Word, for instance, does not display the font size 11.5 in its drop-down, it allows users to type this value manually. Creating such a user interface with CKEditor 5 means that all values the user might type need to be whitelisted when the plug-in is configured.

The current CKEditor 5 user interface, of course, does not allow the user to type custom font sizes. As such, this issue is mostly relevant for clients implementing their own user interfaces. For them, it would be convenient to be able to set font sizes and font families without having to configure them first, regardless of whether it is desirable to allow users to type in font sizes manually.

davidpolberger commented 6 years ago

I should note that this is a low-priority issue for us. It's here mostly because @Reinmar asked me to move my Gitter chat comments to GitHub. We're not currently allowing users to type font sizes directly (we use a drop-down just like the official editors) and if we do, adding the most common fractional font sizes isn't a big issue. Also, we're using "one source of truth" in our codebase in terms of what font sizes and font families are supported and then simply making use of that information when configuring the plug-ins. It would have been even more convenient if we didn't need to do that, but now that the (simple) code is written, we don't mind keeping it around -- and as such, we don't mind if this issue is closed.

jodator commented 6 years ago

Thanks for reporting. A quick note as I was thinking a bit on this. Probably if we allow a callback in font-size configuration for the view then it would allow such case.

AFAIR right now the other values are not rendered to the view because of how we define converters (partially due to two-way converters definition and partially because of parsing font-size configuration option a bit).

oleq commented 6 years ago

I agree that this feature could be useful for some integrations.

But despite that, we should rather discourage this because, more often than not, developers want to have a full control over the HTML users create. Users tend to abuse formatting features and the editor should help site/system maintainers standardize the content.

Anyway, if we decide to implement this feature, how should we deal with the font size defined as classes? There's no way to allow users to type anything they want in that situation because classes are supposed to give the semantics to the content. I guess the feature would be disabled then.

jodator commented 6 years ago

Anyway, if we decide to implement this feature, how should we deal with the font size defined as classes?

I think that this should work as now. Also the numeric presets as well.

This would be another kind of configuration option - like ultra custom configuration. I see this particular requirement as an extension of numeric presets - thus not working with named presets (semantic-ish ones).

Reinmar commented 5 years ago

We'll need to resolve this issue one day to make the paste from MS Word feature work with font styling. Right now, everything is dropped.

statler commented 5 years ago

I have come from editors that render full HTML documents - so this has been a bit of a learning curve working with a model. After a few hours of config with the plugins have successfully achieved the results I want using ckeditor5. The notable exception is the way it parses font size and family. Pretty much everything else works like I would hope with the right plugins.

My use case is that I have a shared DB across mobile and desktop. The desktop version generates HTML that must be interpretable in the browser. Everything renders fine except font-size and family. Even an improved parse would be a start. Any pointers on where this actually happens in the font plugin, or docs on how to work with it?

jodator commented 5 years ago

@statler I've responded in font feature repo: https://github.com/ckeditor/ckeditor5-font/issues/6#issuecomment-462674994.

yankustefan commented 4 years ago

Yes, it would be great to have the option to leave font-sizes as they are. For example, when fontSize.options is not defined.

Or, even better, allow to provide some sort of custom "plugin" function that handles font sizes. Then we could define there a logic how undefined font sizes should be handled.

Reinmar commented 4 years ago

Resolved by ckeditor/ckeditor5-font#61.