Font Size and Font Name drop-downs do not always reflect font styling

[Teresa Monahan]

Currently the font and fontsize combos on the toolbar only reflect styles set through the style definition specified by the fontSize_style and font_style config settings. This means that if font is specified in any other way, the toolbar does not show this.

To Reproduce:

• Copy the following into Source view:

<h1 style="font-family:arial,helvetica,sans-serif;font-size:14px;">Sample heading text with Arial font, size 14 applied directly on the H1 tag.</h1>

<p><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size: 14px;">Sample text with Arial font, size 14 applied through the style definitions specified by config.fontSize_style and config.font_style.</span></span></p>

• Switch back to wysiwyg view and click into the second line of text. Note that the font and fontSize combo boxes correctly display the font styling.
• Click into the first line of text.

Problem: The font and fontSize combo boxes do not reflect the font styling set on the H1 tag.

Setting font and fontSize styling for the paragraph formats is easily achievable in the editor using config.format_<formatName>. For example:

config.format_h1 = { element : 'h1', styles : { 'font-family':'arial,helvetica,sans-serif', 'text-align' : 'center', 'font-size' : '20px;' } };

However the toolbar does not reflect these font styles. Other styles such as text-align and color are correctly represented on the toolbar.

The font and fontsize combo boxes should display the font regardless of how it is applied. Perhaps using the computed font values would be the solution for this. This approach would also address the issue raised in ticket #4887.

[Piotrek Koszuliński]

IMO the first part of this issue (inserting into editor h1 with inline styles) is strongly related to #9829.

I think that font name and size combos do not have to understand all ways of applying a CSS style. They are applying (and understand) CSS style using style definition defined by font_style and that's it - this is a feature that they are.

The problem is elsewhere - editor should not accept content that it doesn't understand. This is why I think that this issue is related to #9829.

Now, what are the ways of solving this issue:

1. Strip styles that are not allowed. In this case entire h1's style attribute would be removed because any of editor's features doesn't allow font-family and font-size set for this element.
2. Harder, but cooler way - editor transforms h1 element by wrapping its content with span and moving style attribute there. Now, the content is fully aligned to the editor's features.

The second part

Should font family and size combos (but also e.g. bold and italic buttons) reflect font styles applied by this format?

config.format_h1 = { element : 'h1', styles : { 'font-family':'arial,helvetica,sans-serif', 'text-align' : 'center', 'font-size' : '20px;', 'font-weight': 'bold' } };

MSWord, Libre Office, Google docs do this. However, they are not generating HTML so we should consider if our case isn't different. But for now, this looks like a reasonable feature request.

[Jakub Ś]

MSWord, Libre Office, Google docs do this.

@Reinmar that's not true.

Type any header and style it and the check how browser sees it. It will be like below code:

<h1><span style="font-size:28.0pt;line-height:115%;color:red">Test my test my
test my test<o:p></o:p></span></h1>

Notice spans in h1 tag

Such code after pasting into editor (with config.pasteFromWordRemoveFontStyles=false; and config.pasteFromWordRemoveStyles = false;) will look:

<h1>
	<span style="color:red;"><span style="font-size:28.0pt;">Test my test my test my test</span></span></h1>

If you change 28.0pt to 28px you will get font size selected in dropdown.

What I’m trying to say is all dropdowns represent certain elements - you can see their visual representations in dropdowns - headers represent headers and styled spans represent styled spans. If there is certain style represented by span I don't think it is valid highlight this span when h1 with styles but with no spans is selected. This kind of breaks “element visual representation in dropdown” approach - this is no longer WYIWYG.
Even MS Word, as I have described it above, doesn't do it (it reacts to spans that are in h1).

I'm closing this as invalid. @tmonahan if you don't agree with my comment please reply.

[Lynne Kues]

If you are in MS Word and you apply a heading to text, the font and font size combos will indicate what is active for the heading when the cursor is in the heading. We have customers who are complaining about the fact that applying a heading style in CKEditor does not indicate what font and font size are active. Teresa investigated whether or not we could somehow extend the editor to create a span when a heading is applied (vs. putting the styles on the heading tag), but this led to other issues that could not be worked around.

[Lynne Kues]

This needs to be reopened and is considered a defect by our customers, not a new feature.

[Piotrek Koszuliński]

@j.swiderski: Create header, place caret in it. In MSWord and Libre Office bold button is enabled, font name indicate the font used for header, etc.

Thus, I'm reopening this ticket. However, I'm still unsure if CKEditor should behave the same way. Now it is consistent - only block styles (e.g. text align) are indicated in toolbar on header. If we'd do the same for inline, then we'd have to deal with many problems:

1. Header style applies font-size:20px, but this font-size is not available in font size combo. What should it show?
2. The same with font names.
3. Header applies font-weight:bold. We select some part of header and try to remove bold style by clicking enabled bold button. What should happen now? There's no way to remove bold without adding "span{font-weight:normal}" in this case. This would completely ruin semantic of created HTML.

[Jakub Ś]

We have customers who are complaining about the fact that applying a heading style in CKEditor does not indicate what font and font size are active.

1. Please note that browser sets its own styles for H1. This is huge difference comparing to MS WORD. There is no way for editor to see these styles.

Even there are differences this still works as described in comment:4. Dropdowns reflect selection if there is a match

2. Check out Google Docs that @Reinmar has mentioned. The so called heading 1 is in fact represented by set of divs and spans. There is no heading. Dropdowns react to elements with particular classes.

3. Check out below example from Word. I have created plain H1 and pasted it into IE to see how it "really" looks like. IMO IE shows word code best.

   <font face="Times New Roman">
   </font><h1 style="margin: 24pt 0cm 0pt;"><span style="mso-ansi-language: PL;" lang="PL"><font size="5"><font color="#365f91"><font face="Cambria">test<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></font></font></font></span></h1><font face="Times New Roman">
   </font>
   

Notice that H1 has span and font tags. This is probably why MS Word shows font size and font name - simply because there are tags that represent this size.
You can also Reveal Formatting with SHIFT+F1 in MS WORD 2010 which IMO kind of confirms what I'm talking about.

To summarize in all applications' dropdown show "style" if it matches code. In example mentioned by you there is no match thus styles aren't shown. If there were spans in H1 (which can be done by setting font size on H1) font size would be shown.

@Reinmar since dropdown reflect selections everywhere and this concept breaks this I'm closing this issue again as it is invalid.
I would really like to hear what Fred thinks about it.

[Teresa Monahan]

I understand that the dropdown values currently represent certain elements and therefore the font and fontsize fields only display fonts set on span elements by default. The problem with this is that there are many other ways in which fonts can be applied i.e. inline styles on many elements. This can be achieved programmatically (e.g. through config.format_<formatname>) so the end-user is usually totally unaware of how the font styling is applied. They just see different fonts and sizes in the editor contents but cannot determine what they are.

What are the benefits of restricting the toolbar dropdowns to only display styles specified through the configured style definition? Would it not be of more benefit to display the computed value so that the toolbar reflects the actual styling of the editor contents?

If it is desirable to only display styles specified through the configured style definition, then perhaps a solution to this would be to process the styles attribute on all elements and transform them into the format supported by the editor as mentioned by Reinmar in comment:2. This could move font styles to span elements (or whatever fontSize_style and font_style specify), insert strong tags for font-weight:bold styling etc.

[Jakub Ś]

What are the benefits of restricting the toolbar dropdowns to only display styles specified through the configured style definition? Would it not be of more benefit to display the computed value so that the toolbar reflects the actual styling of the editor contents?

I was just trying to say that this is how it works now and that this is not a bug.

@tmonahan the way you said it "let's improve this behaviour" is much better than saying that this is a bug like @lynne_kues did.
I agree there is no sense in not being open to new approaches.
Before reopening this ticket I would really would like to hear Fred opinion on this one.

[Frederico Caldeira Knabben]

This is the kind of change that we don't want to do, but still we can make further research about it in the future to check if there is really any possibility to make it... and if it makes sense.

[Jakub Ś]

Taking the above into account, I'm confirming this feature request but with priority low.

I can imagine that not faking elements like e.g. Google Docs and having valid HTML plus dropdown reflecting all styles could be a pain to implement and maintain.

[Jakub Ś]

#4887 was marked as duplicate.

[Jakub Ś]

We have just had a talk that perhaps computed styles could be used and then dropdown could reflect selection (despite element) if only style matches. This should even work if element inherits certain styles like font-size from parent elment.
Still such style needs to be defined for dropdown.
Probably dropdowns that should be affected by this change are font-size, font-familly and styles. Not sure about 'format' as it is rather used with raw HTML which makes current implementation for this dropdown rather correct.

Some concerns:

1. As you know dropdowns like Size or Font insert spans only. What if you have <div style="font-family:comic sans ms,cursive;">text</div> and select part of text in div? Should part of text be wrapped in span or not?
2. Based on above example what if user selects whole text in div? Should style be removed or not?

Taking into account that these two dropdowns work on spans then style should not be removed (This is what will happen in editor currently). Is there any other better solution than this one? Sure this doesn't sound perfect but just think above mentioned example or perhaps something more complex - let's say style reflected for text is in fact placed 3 elements above and there are many other child elements that use this style - How can editor know that user wishes not to remove such style (based on current element siblings and fact they don't have style)?

[Mike Burgh]

If anyone is interested here is some code you can run on the editor's selectionChange event.. If CKE cannot match the font family/size this code will then find it, and show the right item in the drop down (or the details of what it found if the item is not in the list (Eg a font that is not allowed, or a size not in the options).

It also uses jquery to get the computed CSS, but that could be worked around easily I am sure.

var selectionChange = function(e) {

        //We have to sleep this to get it to run after CKE's built in one
        setTimeout(function() {


            var $element = $(e.data.path.elements[0].$) //Current element that has focus in the editor
                , fontMenu = e.editor.ui.get('Font') //The fontMenu
                , fontSizeMenu = e.editor.ui.get('FontSize') //the FontSize Menu
                , fontSize
                ;

            if (fontMenu.getValue() == '') {
                setRichCombo(e.editor,fontMenu,$element.css("font-family").replace("'","").split(',')[0]);
            }

            if (fontSizeMenu.getValue() == '') {

                fontSize = $element.css("font-size");

                //Good old IE, sometimes returns us the font sizes from font tags (eg 1,2,3,4,5) and other times the px font size
                if (g_isIE && fontSize.indexOf('px') === -1) {
                    //So it's a 1,2,3,4,5 in IE

                    switch(parseInt(fontSize)) {
                        case 1:
                            fontSize = 7.5;
                            break;

                        case 2:
                            fontSize = 10;
                           break;

                        case 3:
                            fontSize = 12;
                            break;

                        case 4:
                            fontSize = 13.5;
                            break;

                        case 5:
                            fontSize = 18;
                            break;

                        case 6:
                            fontSize = 24;
                            break;

                        case 7:
                            fontSize = 36;
                            break;

                        default:
                            break;
                    }

                } else {
                    fontSize = (parseFloat($element.css("font-size")) * 72.0 / 96.0).toFixed(0);
                }


                setRichCombo(e.editor,fontSizeMenu,fontSize);
            }
        },0);
    }

var setRichCombo = function(editor, combo, value) {

        var matched = false;

        //The fun part about this is the list may not exist yet
        if ($.isEmptyObject(combo._.items)) {
            //So it's not present yet!
            combo.createPanel(editor); //This creates it!
        }

        //Okay so items is now our list, get our value and go through it
        //Loop the object and see if we have a match on any keys
        $.each(combo._.items, function( index, v ) {

            if (v.toLowerCase() === value )  {
                matched = true;
                value = v;
                return false;
            }
        });

        //If we match it we set it, else we set it's display with nothing selected!
        if (matched)
            combo.setValue(value);
        else
            combo.setValue('',value);

    }

[Jakub Ś]

(Eg a font that is not allowed, or a size not in the options).

If font is not allowed or not in the list then IMHO CKEditor should not display it at all. Anyway when font is not allowed and ACF is on then this font it is as good as gone when user for example switches to source or gets data from editor. Displaying such font can only be confusing for users.

[Jakub Ś]

#12904 was marked as duplicate.

[Marek Lewandowski]

cc

[Jakub Ś]

#14554 was marked as duplicate.

[Jakub Ś]

#16678 was marked as duplicate.

Perhaps some conversion from pt to px and some font-name cleaning could be considered an option if we decide to do any converion?