Support Markdown text input #9833
Labels
addition/proposal
New features or enhancements
needs implementer interest
Moving the issue forward requires implementers to express interest
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:
textarea
) gets tab indexes on top to switch between editing mode and rendered preview modeSome 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 theinput
element.The
inputmode
attribute should get at least one new value that falls back totext
:rich-text
or alternatively more specific ones likemarkdown
andwiki
.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).The text was updated successfully, but these errors were encountered: