Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#8593 closed Bug (invalid)

Default width of tables cannot be configured, is too wide for many reasonable instances

Reported by: Tom Boutell Owned by:
Priority: Normal Milestone:
Component: Core : Tables Version: 3.5.3
Keywords: Cc: john@…

Description

We often use CKEditor in columns narrower than 500 pixels, leading to an unworkable result with a table of the default size. Since this is not configurable, it constitutes a bug for folks upgrading from FCKEditor, which had a much smaller default less likely to create conflicts (200px).

I am attaching a patch to make this configurable. We can now configure both the width and the units in which the width is expressed.

The patch also reverts to the old default width of 200 pixels for broader compatibility. Of course I understand if you're not excited about this aspect, but the rest should be helpful.

Attachments (1)

patch (991 bytes) - added by Tom Boutell 7 years ago.
Configurable default table width and units

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by Tom Boutell

Attachment: patch added

Configurable default table width and units

comment:1 Changed 7 years ago by Alfonso Martínez de Lizarrondo

You don't really need to add extra configuration options. It's already possible to change the default values of any dialog element: http://docs.cksource.com/CKEditor_3.x/Howto/Default_Field_Values

Otherwise, imagine the length of the doc page to explain the config options if every field should be configurable like in your proposed patch :-(

comment:2 Changed 7 years ago by Tom Boutell

I'm starting from the official PHP wrapper for CKEditor, which lets you pass all of the 'config' settings without writing a lot of javascript code, which is really handy.

Is there a way to configure these settings via the PHP wrapper, or would we have to extend it to generate javascript code such as your example?

The code you suggest is pretty verbose when you have a lot of options to override.

As for concerns about the length of the doc page with more options, I would think that explaining the config options for each plugin on a page for each plugin would be manageable.

comment:3 Changed 7 years ago by Jakub Ś

Keywords: patch tables removed
Resolution: invalid
Status: newclosed

from FCKEditor, which had a much smaller default less likely to create conflicts (200px).

One might say 500 is to big other that 200 is to small

The method @alfonsoml has presented is IMHO better (especially when it is recommended in documentation) than modifying the source code what might result in some unexpected errors.

The code you suggest is pretty verbose when you have a lot of options to override.

If you want to customize default CKEditor looks and behavior writing some code is inevitable. You write the code once and put it in config.js. That way it will be applicable for every CKEditor instance.

Closing the ticket as invalid. Please leave the comment if you don't agree with my opinion.

comment:4 Changed 7 years ago by Tom Boutell

I think CKEditor should have a reasonable dictionary of configuration options to address common configuration needs without writing event handlers that watch for dialog names etc. Apparently this is not going to be the case, but for the record I feel the current policy makes supporting CKEditor a pain and will not increase its popularity.

comment:5 Changed 7 years ago by Jakub Ś

But CKEditor has reasonable dictionary of configuration options to address common configuration needs. Have a look at this link: http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html

It does not have configuration option for every dialog customization but it has something better - a well documented general way to customize dialogs through code

You may not like what CKEditor is offering by default and the general rule in this case is the more you don't like the more you have to change. Writing you own customizations is better and more flexible than having us to create configuration option for every scenario possible which is rather impossible.

comment:6 Changed 7 years ago by Alfonso Martínez de Lizarrondo

The only middle ground solution that I can think of, would be to provide a config option similar to removeDialogTabs that uses a dictionary of dialogs and elements to define custom defaults, and then runs a function similar to the one described in the docs but looping this dictionary.

That way the user doesn't have to include a javascript function but just some (complex) config option, and there's no one to create new options for every dialog field.

Last edited 7 years ago by Alfonso Martínez de Lizarrondo (previous) (diff)

comment:7 Changed 7 years ago by Tom Boutell

This could be a sensible approach. CK offers wrapper classes that let you configure a lot from a lot of different languages, and it's jarring to hit the wall on what should be a simple thing like the default width of a standard element.

comment:8 Changed 7 years ago by Alfonso Martínez de Lizarrondo

Here's a plugin that implements such option: http://cksource.com/forums/viewtopic.php?f=18&p=63588

comment:9 Changed 7 years ago by Tom Boutell

Thanks, that looks promising.

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy