Deprecation of slots, attributes and syntax

[jovyntls]

Is your request related to a problem?
Currently, there are quite a few attributes/slots/syntaxes that are deprecated. They may or may not be listed in the docs, implemented in the codebase, or log a warning when used.
Since the next release would be V4 with breaking changes, we can consider fully deprecating these.

Component	Deprecated	In docs	In code	CLI warning?
Modals	modal-footer -> footer	yes	yes	yes
Modals	modal-header -> header	no	yes	yes
Question	has-input -> type="text"	yes	yes	no
Question	invalid question types[1]	no	yes	no
Icons	{{ prefix_name }} -> :prefix_name:	yes	no	no

^[1] This seems a bit more complex compared to the others - it looks like there is some backwards compatibility intentionally preserved (#1274, #1293)

Describe the solution you'd like

Remove these from the docs, along with their implementation.

Describe alternatives you've considered

We may want to maintain backward compatibility for some of these changes?

Additional context

N/A

[itsyme]

Hi @jovyntls! I am currently working on the last part on deprecating invalid question types but I am slightly confused about what the outcome should look like. Is the desired behaviour to make invalid question types (e.g. questions without answers) not render or something along that line?

[jovyntls]

Thanks for checking in @itsyme :)

Given that some of these legacy questions are not documented, and that the rewrite of the questions component (#1274) that first mentioned deprecation was several major releases ago, I think it would be nice to do a full deprecation of these question types - i.e. not support it at all and remove the legacy code from the codebase.

But would like to check with @damithc - Prof do you use the legacy question types at the moment? Would it be fine for us to completely remove (backward-compatibility) support for it?

[damithc]

But would like to check with @damithc - Prof do you use the legacy question types at the moment? Would it be fine for us to completely remove (backward-compatibility) support for it?

@jovyntls OK to remove. If I'm using legacy syntax, I can update the code to use the new syntax. Just clearly indicate in release notes what needs to change to what.

[jovyntls]

Just clearly indicate in release notes what needs to change to what.

👍 @itsyme Should be safe to deprecate entirely! Remember to document the changes (and how to migrate) in your PR description so it can be added to the release notes later on.