Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Markdown text input #9833

Open
Crissov opened this issue Oct 5, 2023 · 0 comments
Open

Support Markdown text input #9833

Crissov opened this issue Oct 5, 2023 · 0 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@Crissov
Copy link

Crissov commented Oct 5, 2023

What problem are you trying to solve?

Many sites – like this one – support enhanced text input with inline formatting characters, now virtually always conforming to Markdown / Commonmark (or Wiki text), but the required punctuation marks (e.g. _*+-=>~`![]()|) are usually hidden away in a 🔢second or third level on soft keyboards.

In some cases, smart conversion of input characters also destroys the function, e.g. ' being replaced by or - by .

What solutions exist today?

Many sites add an icon bar to major text area input fields which will add the required characters by scripting. Such controls may also appear in context menus for highlighted text.
Where syntax variants exist, one choice is therefore enforced.

Users may still enter the formatting characters manually if they know them. Some scripts may assist with that, e.g. automatically repeating the list marker in front of the line when the user hits return or transforming pasted URLs or formatted text.

Some sites try to render some kind of preview:

  • integrated: the formatting characters remain visible, but the marked text is presented in the target style, e.g. bold or italic
  • replaced: valid combinations of formatting characters vanish and are replaced by a WYSIWYG rendering
  • separate: the input field (usually a textarea) gets tab indexes on top to switch between editing mode and rendered preview mode

Some implementations will internally use a more complex rich-text, contenteditable representation, e.g. with color and typeface support, which is later reduced to, say, Markdown syntax.

How would you solve it?

This use case cannot be solved by a new value for the type attribute of the input element.

The inputmode attribute should get at least one new value that falls back to text: rich-text or alternatively more specific ones like markdown and wiki.

By the way, since Markdown allows most HTML phrasing content, it’s virtually a superset thereof.

Anything else?

This is related to #4589.

This may be extended to more complex code input with syntax highlighting and automatic indentation, where the content is not primarily human readable text (“prose”) but computer source code, i.e. for programming or data exchange. However, this would definitely require a way to indicate the language, e.g. <textarea type="text/markdown"> a proposed in WICG/proposals#136 – or at least a way to list the characters that should be easy to enter (e.g. <>/="&; for HTML/XML).

@Crissov Crissov added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Development

No branches or pull requests

1 participant