Italic

[Comandeer]

"Italic", along with "Bold", is one of the must have features.

We already have a draft for that feature: https://github.com/ckeditor/editor-recommendations/blob/gh-pages/_features/italic.md

The main concern here is to rethink the idea of bounding "Italic" to em element. I'm not sure which use case is more frequent: trying to stress something differentely (eg. sarcasm) or using italic for some sort of terminology, foreign words or titles of books. I personally use italic for terminology far more frequently than for marking stress.

So probably we should consider two elements here: em element, the current one, used to mark different stress, and i element, used to mark terminology and titles.

The other concern is i18n issues, very similar to that connected with "Bold" feature: keystrokes and icon are optimized for English language. That issue also should be mentioned in our spec.

[fredck]

So probably we should consider two elements here: em element, the current one, used to mark different stress, and i element, used to mark terminology and titles.

The spec should not propose more than one solution in this case. My point is that implementors will have the same doubts about this point: which one to use? As a result, we would have different implementations, many times driven by personal POVs, which will be trying to answer the same question.

The whole point about these specs is having a place where research has already been done so that question is already answered. People will not have to think much then. So me must, based on research, define which of the two options is the most generally acceptable.

I tend to say that em is the way to go, but we need references and more opinions here.

[fredck]

The spec should not propose more than one solution in this case.

One option we may take in consideration though, is including one "recommended" option but listing "possible alternatives", explaining acceptable use cases for them.

[Comandeer]

The spec should not propose more than one solution in this case.

By "here" I meant in these issues, before putting into spec. The problem in this particular case is fact that spec for "Italic" is already created ;)

One option we may take in consideration though, is including one "recommended" option but listing "possible alternatives", explaining acceptable use cases for them.

It could work, but I'm not sure how many features will have more than one option.

I'm against em, because in my free time I'm the editor in some magazine and we use italic nearly exclusively for marking titles or foreign words. And there are many semantic errors according to fact that nearly all WYSIWYGs implement "Italic" as em, eg. in this review the title of book is marked with em:

<p><em>Longin. Tu byłem.</em><br />

One more example - markup excert from the 1. page in Google for "marking titles with italic":

<em>Moby Dick</em> by Herman Melville

I think that this use case is far more popular than writing sarcastic responses and it's why I'm against em.

The problem here is… users. They don't want to think about "that terrifying thing with H at the beginning" - they just want to see visual effects of their actions. They don't differentiate em and i - they're the same for them: "italic". And i in such use cases is far more harmless than em, that could change meaning in screen readers.

[Comandeer]

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

"Italic" feature is present in all tested editors, except Summernote:

• 9 of them use em
• 11 of them use i
• 1 uses own syntax, based on XML (text:span)

[Comandeer]

One more example (in Polish) why em is not necessarily the best option: https://the-awwwesomes.gitbooks.io/html-css-step-by-step/content/pl/how-internet-works/index.html

It's the article about how the Internet works. Every technical term is marked with italic, e.g.:

<em>[…] servers</em>

As the whole book is generated with Markdown and the above code is generated via * Markdown "function", we get em instead of i. And that's the error because em is just for emphasizing stress, not to be used with technical terms.

I really think that there are far more use cases for i than em and I think that we should switch from em to i – even if it seems to be "unsemantic".

[Reinmar]

I wanted to propose that we check some articles that we know that were created with a WYSIWYG editors to understand what are the most common use cases for bold and italic. I'm afraid though that we'll get more results like @Comandeer.

There are two reasons for that:

1. The main one – missing features (incorrectly configured editors). In the book mentioned by @Comandeer the author is using italic to mark terms. This is a common practice in typography for print (at least in Polish), so if that author wanted to copy the same practice for his online book she/he should've used another marker, not MD's **.
2. General misunderstanding and abuse of text formatting by users.

We can't help for any of these, so accepting the fact, I think that we should choose the safest option, which would be <b> and <i>. The worst case scenario will be that if some user really wanted to emphasise some fragment of text, a screen reader or some other assistive technology won't understand that. The opposite – a screen reader shouting half of a text to the user is much worse in my opinion.

At the same time, we could recommend that the output tags should be configurable, so it can be easily changed in a more controlled environments, used by authors aware of the proper semantics.

[fredck]

If anything, I would go with <strong> and <i>. I don't think that going with the "safe way" is the "right way". We need to provide a common setup that works for creating quality content, not to be "safe".

Therefore the common use case must be somehow identified and I feel that in fact people tend to bold to emphasise words and italic to mark technical, foreign and non usual words.

[Comandeer]

I agree with @fredck. I'll switch from em to i, but stay with strong.

[Reinmar]

I was afraid that you want to propose strong and i :D. I see the reasoning behind this, but it will be weird for other developers. You can expect lots of WATs, because let's face it – developers won't look for editor recommendations. We'll need to send them there and that's not easy.

[Reinmar]

BTW. If we'll decide to go this way you need to explain very well why not <em> and why <strong> at the same time.

[oleq]

Let's start off with the spec. Clearly <b>/<i> are explicit and <strong>/<em> are semantic, as explained in HTML5:

The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.

and

Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term.

So if we recommend semantic, meaningful content, <strong>/<em> is the right way to express it. It might look like a WYSIWYG revolution but I think that "bold" and "italic" terms are no longer valid in this context so I wouldn't name the features this way.

Of course, it would mean facing some problems which are the legacy of "pre–semantic" web like default keystrokes (CTRL+B OK to create <strong>?) and icons (does "B" feel right for <strong> content?), but it would make much more sense to me still. WDYT?

• https://www.w3.org/TR/html5/text-level-semantics.html#the-b-element
• http://w3c.github.io/html/textlevel-semantics.html#the-i-element
• https://www.w3.org/TR/html5/text-level-semantics.html#the-strong-element
• http://w3c.github.io/html/textlevel-semantics.html#the-em-element

[Comandeer]

So if we recommend semantic, meaningful content, <strong>/<em> is the right way to express it.

b, i also convey semantic meaning. The difference is not in fact that some tags are semantic and some not (all tags in HTML5 are semantic, there are no non-semantic ones!), the difference is in allowed use of them. And in that case, em inside WYSIWYG would be frequently used in a wrong way.

De facto none of the use-cases cited here should use em. em, as we could read in the specification, should be used only to emphasize the stress:

The em element represents stress emphasis of its contents.

But let's be honest: nearly noone emphasize stress by italic (the only use-case I could think of is irony). Everyone else uses italic to insert some foreign phrases (just look at my de facto!), technical terms, titles of books etc. And if we're going to create semantic content, em CAN'T be used in such situations. It's the use-case of i:

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.

Actually your quote also confirms it (bold's mine):

Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term.

The true WYSIWYG revolution would be to admit that i has the semantic meaning we all want to use, not to ditch i ;)

[oleq]

Good point. But what about <strong> vs. <b> then?

[Comandeer]

I don't feel the strong is such a big problem. Bold is very often used to mark up something important. And that's the use case of strong. But probably we should move our discussion about strong vs b into #1.

[fredck]

I agree.. I think that keeping the approach that <strong> MUST be paired to <em>, just like <b> to <i>, is an oversimplification coming from the old times. Each should be analyzed independently.

[Wolfr]

Regardless of your opinion of whether i or em should be used, both are used for styling something in a specific way in CSS. The way they are styled is up to the author but in 90% of cases it is just an application of font-style: italic;.

I feel CKEditor should support the output of both tags (by way of congiruation), with a default for em because it is the most common way to write italics (even though it is semantically the way tho emphasise something).

[xavez]

Looking at this from a design and typography perspective, I think the issue originates from trying to use a WYSIWYG editor as a semantic editor. The answer to me is: throw out the semantics. The vast majority of people using a WYSIWYG editor in WYSIWYG mode are not trying to create semantically correct documents. They are using Word in a browser and are applying their personal semantics (visual style) to a piece of text. They will use an h3 heading if the h1 looks too big.

There are too many use cases where users will use italics to style something typographically, that are not semantically <em>: quotes, citations and tradition are only a few.

Typographic traditions also change – also for people who do not consciously practise typography. <em> and <strong> are displayed as italic and bold now. Tastes may change and website stylesheets, user stylesheets and browser stylesheets might change over time. That might alter the layout of a text that was purposely set to be italic, not emphasis. In this case, funnily enough, <i> is semantically and historically more correct as a signifier of intent than <em>.

Practically, you could build a smart switch: use only <i> and <b> when editing latin text in WYSIWYG mode. Add <em> and <strong> buttons when editing in Source mode.

I would not make it a preference, because as said in the beginning of the thread, the idea of this kind of spec is to have thought about it so that thousands of others don’t have to go through the same process.

[fredck]

You made the point with your comment, @xavez and that's reason still think that the pair <strong> and <i> works better.

The fact is that we'll not be able to always match the intention of users with the proper semantic markup. There will be never a 100% match therefore The best we can do is guessing what's the most common use case and go for it, reducing the wrong cases as much as possible.

Add <em> and <strong> buttons when editing in Source mode.

Source mode is not part of the recommendations.

I would not make it a preference, because as said in the beginning of the thread, the idea of this kind of spec is to have thought about it so that thousands of others don’t have to go through the same process.

Couldn't agree more.

[xavez]

that's reason still think that the pair <strong> and <i> works better.

I understand your reasoning and it is a good idea to evaluate them separately. To me, both of them have the same issue individually: if someone is using <strong> to create titles, for example they structure their text with newlines and bold text, then this is still strange. I think a decision like this will also yield more questions and lead to more confusion – but that is another topic.

I think the main point is that you will want to define who the target group is to solve this issue:

• If you are creating a WYSIWYG text editor, what a user will do with it is akin to what they will do with a pencil, or with Word: it’s all visual semantics, they are not editing theoretical or document semantics “behind the UI”. There is no notion of HTML, there is only “what you see on the screen”. Therefore, the best way to keep the author’s intent intact over time, is probably to use <i> and <b> since the author meant to “make it bold” or “make it italic”.
• If you are making a WYSIWYG HTML editor, I think it is probably better to add <em> and <strong>, and you would also want to label your buttons as such. So no B and I leading to <strong> and <em> under the hood.

[eaton]

Given the fact that the list of plugins is customizable, this is a question of defaults, not a question of capabilities, right? The differences between b and strong, and i and em, have always been tricky to explain due to the fact that in the vast majority of cases, they produce the same observable result.

I'm inclined to use @xavez's distinction as a cue: In my experience the majority of end users approach the editor as a WYSIWYG Text Editor, while WYSIWYG HTML Editing requires careful configuration and mapping of the editor's features to a given site's markup lexicon. Given that perspective, I lean towards defaulting to i and bold, while em and strong remain as options for those customizing a site's editor config.

[fredck]

Just to clarify the scope of this discussion, the Editor Recommendations is focused exclusively on content creation (e.g. articles). It's not about "HTML editors". This helps us focusing on the creation of quality content only, today and in the future.

Editor implementers have ofc the option to make things configurable to enlarge the scope of their solutions. Still we'll not make specific recommendation here for that purpose.

[fredck]

if someone is using <strong> to create titles, for example they structure their text with newlines and bold text, then this is still strange.

Although valid, this example is about the extreme bad uses of the editor. We cannot help on these cases anyway, because neither <strong> nor <b> will bring any better semantical value, considering that heading markup is the only right solution for it. Therefore I think that such cases go out of the scope of our analysis here as real solution for them are much different, probably more related to UX.

I would be focused on the use of the bold and italic features on words in a sentence or situation where either <strong> | <b> or <em> | <i> would make sense.

[lutzissler]

Just a few years back, we switched our CMS editor from WYSIWYG to Markdown in order to provide more “semantic editing”. Unfortunately, many users refrained from learning a (arguably very simple) syntax, and instead requested the WYSIWYG editor back. I hated that step. But in the light of what @xavez wrote, it makes sense: If editors make something italic, they very likely want it to come out as italic, and not “now italic but if the designer changes his mind about how emphasis should be expressed we’d also go with uppercase”. So I’m with @xavez when he states that “funnily enough, <i> is semantically and historically more correct as a signifier of intent than <em>.”

Yet, I’m still thinking an ideal markup should be semantic. In an ideal world, the editor would provide buttons for semantic markup, and plenty of them: One button to markup titles, one for names, foreign language words, locations, and so on. Obviously, except than in a very controlled environment where you know what the editors will likely want to express, that’s impractical. Having a generic <em> doesn’t help further as well, as like @eaton said, most editors will just use it because the em button is the one to make something italic. They don’t care if as the button provides the result they’re looking for, and they’re likely expecting that result to be persistent to style change.

So that said, and I’m really surprised to hear me saying that, I’d also go for <i> and and <b> in the general WYSIWYG context. With the recommendation to replace (or at least complement) the generic buttons with semantic markup buttons for the specific use case in order to allow editors to express what they mean. That last emphasis, in case you wonder, was like “speak a little slower and slightly louder and make a pause before.”

[quasipickle]

I use CKEditor in my CMS for a university campus' website. We don't have tons of users, but those we do have use bolded text almost exclusively to make text stand out. In most applications, <strong> would be the appropriate tag.

As for italics, they are never used to emphasize text. They are used almost exclusively to denote terms or people in citations. A sentence might be entirely italicized to make it stand out if it's all on it's own. More often than not though, we use colour to bring attention to that text. As there is no additional semantic meaning for most applications, <i> would be the appropriate tag.

[Comandeer]

OK, as most of us are happy with the <i> option, I'll make an appropriate change to the draft tomorrow.

[Comandeer]

The draft has been updated and <em> was dropped from it, along with the "Emphatic Stress" alternative name (as it didn't make sense anymore).

[Comandeer]

Ok, it seems like a stable feature. I propose moving it from draft to the recommendation status. I'll wait 3 days for objections and then do what should be done ;)