Ticket #100 (closed New Feature: fixed)

Opened 20 months ago

Last modified 4 months ago

Set editing area styles in fckconfig.js

Reported by: Robby.Klehm@… Owned by: martinkou
Priority: Normal Milestone: FCKeditor 2.5 Beta
Component: General Version: FCKeditor 2.4
Keywords: SD-COE Cc: Daniel.Pietsch@…, pkdille, Jyhem, nyloth

Description

This time the default font (after FCKEditor startet) may to be set in

editor/css/fck_editorarea.css: body, td {

font-family: 'Courier New', Arial, Verdana, Sans-Serif; font-size: 12px;

}

In order to integrate FCKEditor without changes in its code we like to set all configurations in one file. Calling one FCKEditor from php we are using the $oFCKeditor->ConfigCustomConfigurationsPath? option overlaying the parameters.

Could you implement an option to set default font within this config file?

Regards

Robby

Change History

  Changed 20 months ago by fredck

  • keywords default font setting removed
  • summary changed from default font configuration to Set editing area styles in fckconfig.js
  • milestone set to FCKeditor 3.0

I'm changing this ticket to make it broader. Actually, it would be nice to set any style in the editing area using a configuration option, named "EditorAreaStyles". So one could use it like:

FCKConfig.EditorAreaStyles = 'body, td { font-family: 'Courier New', Arial, Verdana, Sans-Serif; font-size: 12px;} .SomeStyle { color: Red; }' ;

It should not override the FCKConfig.EditorAreaCSS behavior, but add a specific <style> tag right after it.

follow-up: ↓ 3   Changed 20 months ago by alfonsoml

If there's already the FCKConfig.EditorAreaCSS option, why do we need to add more complexity with another configuration option?

Suggested invalid.

in reply to: ↑ 2   Changed 20 months ago by fredck

Replying to alfonsoml:

If there's already the FCKConfig.EditorAreaCSS option, why do we need to add more complexity with another configuration option?

FCKConfig.EditorAreaCSS will still be there. FCKConfig.EditorAreaStyles would be added as a further option, completely optional.

This is not the first time I hear a request like this. Actually, it seams that on many CMSs, users are able to control styles by using a control panel. They are able to edit the styles using a admin page, or even switch between styles. I remember also of cases where each user may have a custom style, or even different styles per page, depending on templates selection and so on. Well, we could imagine hundreds of situations.

Actually I don't expect this config to be used that much in the fckconfig.js file, but it could be largely used inline on pages when creating a editor instance.

Of course, for other users it may has no value, but FCKeditor is well know for its flexibility too (and this feature would not bring a huge impact in the code, I think).

  Changed 15 months ago by fredck

  • cc Pascal.KUSTNER@… added
  • keywords SD-COE added
  • milestone changed from FCKeditor 3.0 to FCKeditor 2.5

  Changed 15 months ago by fredck

  • cc jean-marc.libs@…, patrice.weber@… added

  Changed 15 months ago by fredck

  • cc pkdille, Jyhem, nyloth added; Pascal.KUSTNER@…, jean-marc.libs@…, patrice.weber@… removed

  Changed 15 months ago by martinkou

  • owner set to martinkou
  • status changed from new to assigned

  Changed 15 months ago by martinkou

  • status changed from assigned to closed
  • resolution set to fixed

The "FCKConfig.EditorAreaStyles" configuration entry is implemented in [411] and [412].

Click here for more info about our SVN system.

  Changed 15 months ago by alfonsoml

  • status changed from closed to reopened
  • resolution deleted

This has broken loading the editor in Safari.

It gives an error:

NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7
http://localhost/FCKDev/editor/_source/internals/fcktools_gecko.js

pointing to

	var e = documentElement.createElement( "STYLE" ) ;
->	e.innerHTML = cssStyles ;

  Changed 15 months ago by martinkou

  • status changed from reopened to closed
  • resolution set to fixed

Thanks for the report.

I've changed the offending line from

e.innerHTML = ...

to

e.appendChild(documentElement.createTextNode(...));

in change set [422]. It should be working fine on Firefox, Opera, Safari and IE now.

Note: See TracTickets for help on using tickets.