Underline

[Comandeer]

I'm not sure if it's really neccessary, but "Underline" seems to be always connected with "Bold" and "Italic" features (the "big trio" that is available in every editor out there).

The main concern here is its usability on web, where the underline convention is used generally to mark links, therefore marking some other text by underlining it can be problematic for users.

If we're going to implement it, I think we should consider two elements

• span with appropiate styles
• u element - it's important to note that HTML5 changed semantics of that element and it's no longer purely presentational; on the other hand its current definition renders it pretty useless…

Also we should consider some i18n issues, such as keystrokes and icon optimized for English language.

[fredck]

From my experience and as a personal opinion, I would suggest to not include this feature, exactly because of the usability concerns presented. If we were supposed to go that way, we should gather more references that support this decision and list them into this thread or maybe even wait for more opinions.

[scofalik]

It's funny, cause whenever you think about simplest editing features, always "the big trio", with underline, comes to mind as must-have. But when you think of it more it becomes apparent that underline is... not needed.

Apart from usability issues, there is nothing that you would like to do with underline that can't be done with either bold or italic. If you want to highlight a part of text, just use bold or italic. Unfortunately I am afraid that it may look like something is missing. I hope people won't laugh at us saying that we don't even know how to implement underline feature :P

[Comandeer]

Unfortunately I am afraid that it may look like something is missing. I hope people won't laugh at us saying that we don't even know how to implement underline feature :P

Yes, I think that it could be even greater issue than choosing the appropiate element or finding examples against that feature. The people hate any changes and removing such feature is a really big change.

On the other hand, it's really useless for semantic content and it hurts usability. Maybe include it as "dangerous feature", which displays question "Are you really going to hurt your users?" ;)

[fredck]

Most new editors out there are already dropping this feature.

[Comandeer]

Some stats. I've checked 22 editors to see how they implement some basic features.

"Underline" is absent in 7 editors, the rest implements it as follows:

• 12 of them use u
• 2 of them use span[style]
• 1 uses own syntax, based on XML (text:span)

[Comandeer]

Actually I would like to drop this feature completely. What do you think about such move?

IMO underline hurts usability and accessibility to much to be tolerated.

[Reinmar]

I think that's a reasonable choice for an article editor. I agree with the a11y issues and I agree that such a semantic-less styling makes little sense. Writing lots of content myself I don't remember missing it once.

[Comandeer]

Ok, dropped.

[ssougnez]

Hi,

wondering why the underline functionality was not yet implemented, I ended up on this topic and read the discussion. Even though I totally understand the decision that has been taken, I'm wondering if it isn't up to the user to decide whether they want to show the underline functionality or not.

I mean, the decision here lies on a technical point of view but I can't help myself to wonder if everyone (especially client) will share this technical vision. Indeed, says that I develop a small CMS for a team of non-technical users. Maybe they are my client and it's not my place (or maybe I just can't tell them) that they shouldn't use underlined text. I'm working on a company where people are using a CMS to make a public facing site and you'd be surprised how many obsolete formatting feature they are using.

So, while I understand the choice here, it seems a bit weird to me that the user is imposed with technical/semantic choices. If the user wants to be able to underline text, he should be able to do so. Besides, even though I'm a developer, when I first setup ckeditor5, I was kind of surprised by the lack of this feature, even though, after considerations, I realized that I never used this feature in any article I wrote :-D

Maybe I'm wrong but the best of the two solutions might be to include an underline feature in the basic-styles and then, it's up to the developer, after a discussion with his client to include it or not in the toolbar. At the end of the day, it's not because the functionality is available that it will be used.

Now, I get that semantically speaking, the underline think is a bit tricky and for me, neither "u" or "ins" are good solutions as neither of them just mean "underlined". Therefore, if this feature was to be implemented, I think that <span[style]> should be used.

That's it for my 2 cents :-)

[Comandeer]

Hi @ssougnez!

The main goal of this project is to develop a set of recommendations for developers that want to create Rich Text Editor, which produce high quality, accessible and semantic content. "Underline" feature, as it was discussed above, does not convey any semantics (it's just pure decorative feature) and, what is more important, can hurt accessibility (as underline is reserved for links). Therefore it's against the goal of this project and was rejected.

However every developer, who needs such feature, is free to develop one.

[fredck]

Maybe I'm wrong but the best of the two solutions might be to include an underline feature in the basic-styles and then, it's up to the developer, after a discussion with his client to include it or not in the toolbar. At the end of the day, it's not because the functionality is available that it will be used.

That's exactly the way we want to do it in CKEditor 5. The feature will be available in basic-styles in the future and it'll be up to the developer to decide whether to include it or not. It'll just not be configured by default in the standard builds.

Please note that the scope of this project, the Editor Recommendations, is not to define what gonna be developed in CKEditor. It is an open project that fits all editors out there and it sets recommendations on what a proper, modern editor should look like. Then it is up to the editor teams to develop their editors in the way they prefer.