Make possible and/or enable syntax highlighting in text mode

[jasmussen]

Given we have blocks with comments, it would be nice if we had some intelligence, like codemirror or something similar, in the text mode.

There's a long existing ticket discussing how the text mode could be potentially enhanced, that should be required background reading for this discussion: https://core.trac.wordpress.org/ticket/12423 — the gist is that codemirror comes with some accessibility concerns.

How can we move forward with a richer text experience without affecting accessibility? Is "syntax highlighting" off by default, and you can then enable it in a switch on the quick tags toolbar? Can we contribute upstream patches to codemirror to make it accessible? Is it an opt in as the first choice when you visit the text mode? Are there other ways you can go about this?

[StaggerLeee]

I never know when you ask core developers, and when community.
My personal opinion is code syntax should never be visible on default. Just as optional, via filter, or quick tags menu.

[westonruter]

See also feature plugin for implementing this outside Gutenberg https://github.com/georgestephanis/codemirror-wp

[afercia]

I'd suggest to consider a new "HTML" block type with syntax highlighting rather then using CodeMirror for the text mode. Keeping text mode as close as possible to a "pure" textarea with just plain text is the only way to ensure content can be edited by everyone, regardless of the device/platform/user agent/assistive technology used.

[westonruter]

CodeMirror should also be part of the Custom HTML block.

[afercia]

As long as users can disable CodeMirror in the block with the option that's going to be introduced in core, no objections from me.

[jasmussen]

From #3113:

Text mode in Gutenberg needs a lot of love. It's been largely untouched as we focused on the visual editor instead.

There are responsive issues, the toolbar isn't hooked up, and in general the experience just isn't up to snuff.

Since CodeMirror is about to land in 4.9, let's both include that when we can, and use it as an opportunity to redesign/improve text mode in Gutenberg.

There are a number of tickets and PRs that will be affected by this, mostly in https://github.com/WordPress/gutenberg/labels/Text%20Mode. See also:

• Text mode: title and content textarea focus style #1837
• Implement toolbar buttons for text mode #569
• Hook up text editor quicktags #761
• Quick tags buttons need to be properly labeled (regression from current editor) #979
• Fix for Text Mode toolbar #3043
• Text mode toolbar not visible on mobile screen  #3041

[afercia]

As discussed live and on other issues, CodeMirror on by default on the Text mode would be a huge barrier for assistive technologies users. As broadly tested on the Trac ticket 12423, CodeMirror is hard to use with screen readers and totally unusable with other software like, for example, speech recognition software.

Ideally, the text mode should be just that: a simple textarea, since a native textarea is the only guarantee content can be entered with any device, technology, or ability.

Code editors or the HTML block are different, because users can disable CodeMirror or simply not use the HTML block.

Instead, the content editor is a completely different case. Introducing CodeMirror here would seriously impact on the ability to enter content for everyone, and just totally exclude some users.Not the best example of inclusive design.

If Gutenberg wants to introduce a "HTML mode" I have no objections, but then there should be a third mode, i.e. a simple textarea which is always and easily discoverable and accessiblle for everyone.

[samikeijonen]

I could not agree more with Andrea. Text mode should be left alone with all the bells and whistles. In this case CodeMirror would just create barrier to create content.

[rianrietveld]

Can we please do big changes in phases and not all together and do better research on who benefits from this?
Gutenberg will be a huge change, adding code mirror too by default for text mode, may be too much for many users.

[karmatosed]

@rianrietveld we are trying to phase things, it's absolutely something we are trying. It's worth noting that it's not a case no research or bad research is going on. In the case of code mirror, it is about to go into core so users will have an expectation of it being there when there is a plain field.

We have to be ok with testing things also, Gutenberg is not in core yet - let's be flexible in our approach, responsible but flexible is good. The points raised here are being noted, this is not being said as a dismissal.

Let's try having it in, then let's run some tests. After that we can iterate - would a button be good to turn on? Does it maybe need to not even be there? We have done this with metaboxes and a lot of other things in Gutenberg. It has to be a space we can try things as we are not in core yet.

I would like us to rise to the challenge that the text editor isn't the only way assistive technologies can use Gutenberg, that's the way we're all trying to get things working.

[afercia]

@karmatosed can you please expand a bit on this?

I would like us to rise to the challenge that the text editor isn't the only way assistive technologies can use Gutenberg,

To recap: at the moment, Gutenberg is hardly usable with screen readers and other assistive technologies, to be fair. At the moment, Text mode is the only way to guarantee that everyone, with any device, technology, and ability, can actually enter and publish content.

Also, not so clear to me what the following actually means:

It's worth noting that it's not a case no research or bad research is going on.

Also:

In the case of code mirror, it is about to go into core so users will have an expectation of it being there when there is a plain field.

This is just an assumption and, honestly, not a good argumentation. I feel like you're confusing code editing with content editing. CodeMirror is merged in core just for the code editors. Content editing it's a completely different thing.

We've already proven with extended research and testing that CodeMirror is hard or impossible to use for assistive technologies users. Great part of this testing happened at WordCamp London 2017.

If CodeMirror is going to be used also for the editor text mode, that would defeat the only reason for WordPress to exist: giving everyone the ability to publish content on the web. That would actually exclude users. Would that be a good example of "inclusive design"? Is this what WordPress really wants?

I'd really would like to don't start again from scratch the discussion that happened on the Trac ticket 12423. If the editor team wants to implement a "syntax highlighting mode", I personally have no objections, but then there's the need of a 3rd mode: a simple textarea, for the reasons explained above.

[ptasker]

I feel like a separate HTML block would probably be a good test for CodeMirror. It's something I've been playing with with meta-boxes, as I agree, the 'text editing mode' for the legacy editor has worked and looked the same forever.

CodeMirror also is used for much more than just HTML syntax highlighting, as it has modes for JS, CSS, PHP and HTML Mixed. I think in this case, having a 'code block', with options for choosing which CodeMirror mode to use, would be a neat idea.

[karmatosed]

This came up in issue #4204.

[samikeijonen]

@karmatosed Isn't this issue 1733, was it some other issue?

[karmatosed]

[ oops ] attached to wrong issue, thanks. Speed triage blip.

[jasmussen]

Closing this per a recent discussion where it was decided not to do this at least in the near future.