Headings

[Comandeer]

When creating content, the need to insert non-default block context usually occurs. In most text editors it's done by adding a "Styles" dropdown to editor's GUI (as it's done in LibreOffice or in CKEditor) or via "tiles" with styles preview (as it's done in newer versions of MS Word). However Editor Recommendations should not assume how the editor's GUI would look like therefore probably it would be better to break styles from such GUI element into separate features.

Probably the most common ones are headings, which are used to divide content into logical, hierarchical structure.

There should be ability to create at least 6 levels of headings indicating the hierarchy between different content's parts. Headings in HTML should be reflected by h<x> elements, where <x> stands for heading's level.

Pressing Enter when inside the heading should create new default block context after the heading.

That's probably all, I think. Am I missing something?

[fredck]

There are some things that we could discuss, in a way to modernize this features on the context of editors:

• Heading level 1 (H1): there is a good chance that in the great majority of the cases, using H1 is not appropriate because content produced with editors are in their great majority placed inside pages under an existing H1 level. Maybe we should jump this level so.
• Going as deep as level 6 (H6): aren't we going way too far just because HTML allows for it? I think that 3 levels should be more than enough, to stimulate writers to not abuse of headings.

After all we're not here to spec HTML, but what makes sense for quality text editors. Not sure though... that's food for thought.

[Comandeer]

I think that 3 levels should be more than enough, to stimulate writers to not abuse of headings.

I've seen some legal documents that had 6 or even more levels… But yes, in "normal" use cases it's very unlikely to go deeper than 3 levels. I think that we could limit the heading's level to 4 (as h1 probably wouldn't be used, so we're de facto left with h2, h3, h4).

Heading level 1 (H1): there is a good chance that in the great majority of the cases, using H1 is not appropriate because content produced with editors are in their great majority placed inside pages under an existing H1 level. Maybe we should jump this level so.

Probably that's right. The note about h1 and when it could be allowed should be sufficient.

[fredck]

Another important aspect to take in consideration here is naming... considering that we endup with 3 levels which, technically speaking, start with h2, how should we name this to make it intuitive for end users and acceptable by developers?

I'm for this:

• Heading Level 1 (h2)
• Heading Level 2 (h3)
• Heading Level 3 (h4)

Intuitive for end users, but I'm 100% sure that developers will complain about this. But if not that, then what?

[Comandeer]

I don't see why developers would complain. The name is for user and often names for users are not technically correct or 100% accurate. The name just describes how the feature looks like.

[Comandeer]

First version of the draft is now available: http://ckeditor.github.io/editor-recommendations/features/headings.html

[fredck]

Another thing we can take in consideration is keystrokes. This is such and essential feature that it may deserve that.

Maybe something like Alt+1, Alt+2, Alt+3?

Probably some research is needed first.

[Reinmar]

I guess you know about document outline algorithm and that you've read that it doesn't work and is not recommended. It's a real pitty that we cannot assume that headings in the content always start from h1. At the same time we cannot also predict how many levels will be needed and we should not go for maximum, because in 99% cases h4-h6 won't be styled anyway.

So, in my opinion we should recommend that this is configurable behaviour. At the same time we may recommend some default setting (h2-h4 with names "heading 1-3").

[Comandeer]

I guess you know about document outline algorithm and that you've read that it doesn't work and is not recommended.

The issue is widely known for ages, it's even inside [https://www.w3.org/TR/html5/sections.html#outlines](the spec) (there are also two references in our "Headings" draft about it).

So, in my opinion we should recommend that this is configurable behaviour. At the same time we may recommend some default setting (h2-h4 with names "heading 1-3").

That's what our draft does.

[Reinmar]

Heh... so now it's official https://twitter.com/htmlwg/status/721694848911335424. Weird though that browser vendors' reluctance in implementing the algorithm lead to breaking the spec. Unless there's more into that than we see. I'll check https://github.com/w3c/html/issues/169 tomorrow and maybe leave my comment.

[chaals]

@Reinmar I'm not sure there is "more into that". Browsers have implemented a stylesheet that makes h1 inside nested sections appear like progressively lower level headings. But it's a dirty, and broken, hack.

My thoughts on this issue are that it is worth enabling maybe 6 levels of headings, trying to communicate to the user where to start based on analysing the parent tree where the editor is - although obviously that isn't terribly reliable - and maybe even providing a flag that lets the editor be told the right "top" level heading.

I'd aim for maybe 3 levels with shortcuts. Since I'm not paying for your work time the last would be "subheading" that dynamically adds a new subheading at "the right level" - which means you need to be able to present the outline and pop in and out of it. Being able to collapse a document to its outline for navigation - or just skip through it with shortcuts - is the sort of thing that is very valuable to people who are working on serous documents, and actually care about having multiple layers of headings, in my experience.

I've certainly used 4 levels reasonably often in writing plain blog posts. But I'm not sure I am a typical user. I've edited stuff that's going to have a real h1 often enough to think it's probably going to happen to a notable minority of your users. But this is "anecdata", so treat accordingly.

[Comandeer]

Browsers have implemented a stylesheet that makes h1 inside nested sections appear like progressively lower level headings. But it's a dirty, and broken, hack.

It's not even a hack, it's just some fancy styling. No a11y, no UX, no nothing – just a bunch of styles. I'm quite happy that W3C decided at last to get rid of that fiction.

I've certainly used 4 levels reasonably often in writing plain blog posts. But I'm not sure I am a typical user. I've edited stuff that's going to have a real h1 often enough to think it's probably going to happen to a notable minority of your users. But this is "anecdata", so treat accordingly.

Such use cases are also covered by our draft, in "Implementation Concerns" section.

My thoughts on this issue are that it is worth enabling maybe 6 levels of headings, trying to communicate to the user where to start based on analysing the parent tree where the editor is - although obviously that isn't terribly reliable - and maybe even providing a flag that lets the editor be told the right "top" level heading.

IMO it's an implementation detail, so it shouldn't be included in the draft.

[chaals]

my thoughts on this issue

an implementation detail

Yeah, by "this issue" I was referring specifically to the CK implementation question... seeing as I was here.

[chaoaretasty]

I think there's always going to be a problem trying to work from a generic editor to what heading levels it should output as we can't guess the context. Have the editor instead work on relative headings and the implementer setup the top allowed level in configuration. Heading one in the editor then represents "the top level heading allowed in where you are editing". It's also easy to work from there how many heading levels deep to allow.

[fredck]

We're just trying to grab the most common case here. It's safe to assume, based on the architecture of current CMSs, that a "Title" field is generally available, paired with a "Body" field. Therefore, the assumption that inside "Body" we should start from h2 seems realistic.

The specs presume configurability on this feature, therefore we should have it covered, both the h1 and the "how many levels deep" issues.

[Comandeer]

we should have it covered, both the h1 and the "how many levels deep" issues.

We have, in "Implementation Concerns" section.

Another thing we can take in consideration is keystrokes. This is such and essential feature that it may deserve that. Maybe something like Alt+1, Alt+2, Alt+3?

I'm not sure if such keystrokes aren't already in use (AFAIR [accesskey] attribute could be used for that kind of bindings). Maybe something more verbose, but still understandable, e.g. Alt+H+1, Alt+H+2? I'll do some research with JAWS and see which combination is less problematic.

[Comandeer]

It seems that finding good key combination could be hard…

• Alt + <number> is used in Chrome to change tabs.
• Ctrl + <number> is also used in Chrome for the same purpose.
• Alt + H + <number> activates "Help" menu in Firefox.
• Ctrl + H + <number> in both browser activates "History" tab/panel.

Ctrl + Shift + <number> and Alt + Shift + <number> don't seem to do anything however.

[mlewand]

Word does it with ctrl + alt + 1, some other web editors use alt + shift + <number>.

For sure we can't prevent ctrl + <number> as it's a very useful hotkey if talking about web browser, as it's used to focus n-th tab in most browsers.

I'd suggest using ctrl + shfit + 1 it seems to be a convenient hotkey.

[Comandeer]

Ok, for now I added Ctrl+Shift+<number> keystroke to the draft.

[Cambridgeport90]

Has this been fixed as of yet? I've got CKEditor running around on my site. Will have to try it, as the original provider that comes with DNN is crap, so I added a pure provider with pure CKEditor, and my keystrokes don't disappear. I'm blind as well, so my being able to use keystrokes is essential.

[Comandeer]

No, it's not fixed yet. This repository contains only proposals of how such features should be working inside online rich text editors (you can read more about it on our project's About page). However it's highly possible that these keystrokes would appear in CKEditor 5 when it's released.

[Reinmar]

Do we want to go into such things like how should headings dropdown behave? Do we want to define that a dropdown is the most typical way to apply them? Or that clicking a button (being it a separate one or a dropdown's item) representing the currently applied style should remove it (and leave a paragraph)?

[fredck]

I don't think we should go on details of the UX implementation. If it's a dropdown, a set of buttons, a shortcut, if it changes to paragraph on click, doesn't make any difference. Those are the implementation choices.

[Reinmar]

Those are choices that affect UX. How are keystrokes different from them? I'm simply confused a bit by what ER is about and what isn't.

[fredck]

Keystrokes are issues that make sense to be standardized and doing so is very different than talking about which UI component should be use to activate the feature and how such UI component should behave. We just assume, as an included part of the recommendations, that keyboard support is a basic requirement among all features and so we standardize it to avoid differences.

For example, we're not discussing whether the feature should be activated by using a keyboard shortcut, a mouse gesture or body gestures. Instead, by assuming that keyboard is a required feature, we simply define which keystroke is recommended for that.

[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 ;)