Editor does not allow to change the numbering list font

[IBM_RQM]

Steps to reproduce:

• Create a numbered list
• Select all the text, change the font size, color...

Result: The numbers are not affected

[Jakub Ś]

A lot of users are claiming that after they put a style on li element it does not get applied to list number/bullets (E.g. bigger font size, color)

But if you look at the code you will see that those styles are applied to text in li element and not to li element itself.

The source of the problem is that at the moment CKEditor is missing features like "list style dialog" and "list-item style dialog". Both were mentioned in #844 and #7853.

I'm closing this one as DUP of #844.

[Frederico Caldeira Knabben]

Right now, I would not make this one a DUP of #844. We may have different solutions for colors and fonts. I would just make a cross ticket reference.

[Jakub Ś]

Understood :)

I'm confirming this one. Links to tickets concerning this issue may be found comment:1

[Jakub Ś]

#9040 was marked as duplicate.

[Frederico Caldeira Knabben]

It looks like we'll have to re-write the color/font/size code from scratch to be able to solve this problem properly. In this way we'll be able to apply style in different ways, depending on the elements the selection crosses. I still think we'll have hard to deal cases, like partial list item selections, but overall it should work well.

The idea would be making the editor configurable, so either the current CKEDITOR.style way is used, or a custom "style attribute" processing takes place.

In any case, this is something that we'll be able to handle in the future only, not now.

[Jakub Ś]

#10303 was marked as duplicate.

[Jakub Ś]

#11000 was marked as duplicate.

[Ben Duncan]

It would be more intuitive (and dialog free) if highlighting the area surrounding an entire list and setting a style would apply to the ULs (or LIs) rather than the contents of the LI. From my company's feedback this seems to be the users' expected behavior.

[Piotrek Koszuliński]

Unfortunately in HTML it would be very complicated to achieve this.

Let's say that user applied bold to entire list. We would have to know that bold on list is not <strong> any more but font-weight: bold on <li>:

<ul>
  <li style="font-weight: bold">foo</li>
</ul>

First of all - it's a poor HTML. The kind of HTML which we try not to produce. But most importantly, I already see (and usually the further, the more) cases which makes this a nightmare.

When the caret is in that list item, the bold button should be on, indicating that bold is applied in current place.

Now, it is possible that user will copy text wrapped with <strong> from other place and paste it in the list item. The <strong> should be filtered out by the editor#insertHtml method, because it won't make sense inside <li>. It's doable, but will require a lot of work, because insertion will have to be controlled by styles definitions (style will have to say that bold may be a <strong> or font-weight:bold style applied on certain block level.

There's also even more tricky case. When user will press bold button on the collapsed selection in the bolded list item, the bold should be removed and that can be achieved only by inserting <span style="font-weight: normal">

So the resulting HTML would look like:

<ul>
  <li style="font-weight: bold">foo<span style="font-weight: normal">bar</span></li>
</ul>

It becomes a very presentational, nonsemantic HTML.

However, we can go even further. What if user deletes "foo"?

<ul>
  <li style="font-weight: bold"><span style="font-weight: normal">bar</span></li>
</ul>

In this case we have bolded list item and normal text, so editor would have to remove the style from the list item and the <span> element. Since there are dozens of ways to remove some content, editor would have to observe all of them and perform a check on every change.

Other features that would have to be updated:

• removing styles,
• checking if style is applied on selection,
• remove format feature,
• ACF (it has to automatically understand inline styles applied to list items),
• perhaps also algorithms changing lists structures (so the inline styles are correctly continued),
• all that would have to be disableable, because most of users would not like CKEditor producing such HTML,
• and perhaps more.

So a non-critical improvement would require a pretty deep and costly changes in most important CKEditor features. In my (personal) opinion it's not worth the cost. Editor would become bigger, harder to maintain, heavier and we don't even know what level of stability we would be able to achieve.

[Frederico Caldeira Knabben]

The whole idea about handling this issue has been way too simplistic so far. I've just coded the following, that clearly shows that this is totally out of our control, no matter how much effort we put on it:
​http://jsfiddle.net/P3vRJ/

In other words, this is a HTML limitation and the only way to really solve this is by changing the way browsers behave. In fact, the above fiddler can be used to propose this change.

I have the impression that HTML has been designed taking in consideration that only developers would ever produce HTML pages. But this is different now and we must try to make browser vendors understand that some additional solutions are required for needs like ours.

[Frederico Caldeira Knabben]

Currently, the only reasonable way to have styles applied to either list items (li) or whole lists (ol, ul) is by using the Styles combo. Other inline styling features are dedicated to... well... inline styling. As said this is unfortunally a HTML constraint.

In the other hand, we'll try to open discussions with standards decision makers and browsers vendor to bring our problem to their knowledge and eventually have a better solution in the future.

[Frederico Caldeira Knabben]

Additionally, semantics hasn't been taken in consideration at all in this ticket. Replacing things like <li><del>...</del></li> with <li style="text-decoration:line-through">...</li> would not only be wrong, but also a lack of responsibility from our side.

This situation must be handled by browsers vendors and that's what we'll try to achieve now.

[Frederico Caldeira Knabben]

W3C's HTML 5 Working Group issue opened:
​https://www.w3.org/Bugs/Public/show_bug.cgi?id=24111

[Jakub Ś]

Another related (or duplicate) issue #7141

[Jakub Ś]

#16703 was marked as duplicate.

[Jakub Ś]

#17069 was marked as duplicate.