Opened 5 years ago

Closed 3 years ago

Last modified 4 months ago

#8741 closed Bug (wontfix)

Editor does not allow to change the numbering list font

Reported by: IBM_RQM Owned by:
Priority: Normal Milestone:
Component: General Version: 3.0
Keywords: IBM v4 Cc: CantFix


Steps to reproduce:

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

Result: The numbers are not affected

Change History (16)

comment:1 Changed 5 years ago by j.swiderski

  • Resolution set to duplicate
  • Status changed from new to closed

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.

comment:2 Changed 5 years ago by lynne_kues

  • Keywords IBM added

comment:3 Changed 5 years ago by fredck

  • Resolution duplicate deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 5 years ago by j.swiderski

  • Status changed from reopened to confirmed
  • Version changed from 3.6.2 to 3.0

Understood :)

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

comment:5 Changed 5 years ago by j.swiderski

#9040 was marked as duplicate.

comment:6 Changed 5 years ago by fredck

  • Keywords v4 added

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 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.

comment:7 Changed 4 years ago by j.swiderski

#10303 was marked as duplicate.

comment:8 Changed 3 years ago by j.swiderski

#11000 was marked as duplicate.

comment:9 Changed 3 years ago by bendman

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.

comment:10 Changed 3 years ago by Reinmar

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>:

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

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:

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

It becomes a very presentational, nonsemantic HTML.

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

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

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.

comment:11 Changed 3 years ago by fredck

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:

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.

comment:12 Changed 3 years ago by fredck

  • Cc CantFix added
  • Resolution set to wontfix
  • Status changed from confirmed to closed

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.

comment:13 Changed 3 years ago by fredck

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.

comment:14 Changed 3 years ago by fredck

W3C's HTML 5 Working Group issue opened:

comment:15 Changed 3 years ago by j.swiderski

Another related issue #7141

Last edited 3 years ago by j.swiderski (previous) (diff)

comment:16 Changed 4 months ago by j.swiderski

#16703 was marked as duplicate.

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