Ckeditor5: [Docs] Showcase Basic Styles features

[wwalc]

🐞 Is this a bug report or feature request? (choose one)

• Feature request

💻 Version of CKEditor

1.0.0-alpha.2

📋 Steps to reproduce

1. Go to https://docs.ckeditor.com/ckeditor5/latest/features/index.html
2. See that one cannot easily understand that Code and Underline features are available.

✅ Expected result

It should be pretty clear for anyone exploring features that Underline and Code features are already available.

📃 Other details that might be useful

When showcasing Underline and Code, make sure to point to an article about creating custom builds: https://github.com/ckeditor/ckeditor5/issues/669

[Reinmar]

Yep, we need a Features -> Basic text styles guide.

Content:

1. List of existing styles.
2. Demo.
3. How to install. (Similar to https://docs.ckeditor.com/ckeditor5/latest/features/image.html#Installation)
4. Common API. (Similar to https://docs.ckeditor.com/ckeditor5/latest/features/image.html#Common-API)
5. Contribute! (https://docs.ckeditor.com/ckeditor5/latest/features/image.html#Contribute)

[oleq]

Maybe we should showcase a "full-featured" editor somewhere? Not because it makes sense as an editor but simply to showcase all editor features that are available.

Code, Underline, Alignment: there are lots of features disabled in default editor builds already and more will come but we should still make sure developers know about them. If we develop features and then hide them from the people, then what's the point?

[oleq]

TBH a simple list would do the trick. We can generate it automatically.

[Reinmar]

Maybe we could have this list here https://docs.ckeditor.com/ckeditor5/latest/features/index.html?

[Reinmar]

BTW, we also have https://github.com/ckeditor/ckeditor5#packages and we'll be redesigning the readme soon, so we'll need to decide whether we want to maintain that list in the readme or move it to the docs.

cc @wojtekidd

[wwalc]

I think instead of index, it should be named "A brief list of all features" or something like that and be linked in the sidebar. Reasoning: it will be huge and will duplicate dedicated features examples, which explain them in more details.

In such a "brief list of all features" we could also mention which package provides that feature and mention the button name (if any), to satisfy all the users asking us for years for a complete list of toolbar items.

[oleq]

In such a "brief list of all features" we could also mention which package provides that feature and mention the button name (if any), to satisfy all the users asking us for years for a complete list of toolbar items.

Yes, what I meant was that the list should be very simple: a name of the feature, a name of the package which delivers it, some super–short description, and a button (if any).

When people think about features, they think buttons not "engines". If they see a button, it becomes very clear what does it mean. I think it is important for the DX.

[Reinmar]

When people think about features, they think buttons not "engines". If they see a button, it becomes very clear what does it mean. I think it is important for the DX.

At the same time, not every end-user feature has a button (magicline, clipboard). So the name of the feature is still the first thing to list. But I agree that in the next column we can list button names.