Opened 12 years ago

Closed 10 years ago

Last modified 7 years 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 (17)

comment:1 Changed 12 years ago by Jakub Ś

Resolution: duplicate
Status: newclosed

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 12 years ago by Lynne Kues

Keywords: IBM added

comment:3 Changed 12 years ago by Frederico Caldeira Knabben

Resolution: duplicate
Status: closedreopened

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 12 years ago by Jakub Ś

Status: reopenedconfirmed

Understood :)

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

comment:5 Changed 11 years ago by Jakub Ś

#9040 was marked as duplicate.

comment:6 Changed 11 years ago by Frederico Caldeira Knabben

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 11 years ago by Jakub Ś

#10303 was marked as duplicate.

comment:8 Changed 10 years ago by Jakub Ś

#11000 was marked as duplicate.

comment:9 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by 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>:

  <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 10 years ago by 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:

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 10 years ago by Frederico Caldeira Knabben

Cc: CantFix added
Resolution: wontfix
Status: confirmedclosed

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 10 years ago by 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.

comment:14 Changed 10 years ago by Frederico Caldeira Knabben

W3C's HTML 5 Working Group issue opened:

comment:15 Changed 10 years ago by Jakub Ś

Another related issue #7141

Last edited 10 years ago by Jakub Ś (previous) (diff)

comment:16 Changed 7 years ago by Jakub Ś

#16703 was marked as duplicate.

comment:17 Changed 7 years ago by Jakub Ś

#17069 was marked as duplicate.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy