Improve the Code Editor

[mapk]

I'm seeing more and more 1-star reviews in the plugin due to the code editor lacking for more advanced HTML & CSS savvy users. It might be time we take a look at how we'd like to improve the Code Editor.

Current Code Editor

---

Problem Areas

---

Solutions

There are a couple of things to improve here. For one, if we improve the appearance, it can become obvious that the user is in the Code Editor mode and we can then get rid of the Editing code label.

1. Widen the column of text in the editor to allow the text to fill the horizontal space.
2. Remove the "block" feeling by getting rid of the borders.
3. Add syntax highlighting.
4. Add dark mode.
5. Add a column of numbered lines.
6. Get rid of the "Block" tab setting because it's irrelevant in this mode.
7. In place of the "Block" tab setting, we can add a "Code" tab setting that can include these settings for the Code Editor.
8. I'd even allow the use of the + block inserter icon so that a user can insert a block in the code editor too! It would just render as code in the document.

---

Proposed Design

[karmatosed]

Thanks for exploring this @mapk. I have a few thoughts based on this. What we have now for editing is very minimal and a starting point to iterate from. That said, I think there needs to be a conversation about what that iteration needs to be. Editing code is something ideally there would be less need for, unless that person chose. One part of this is really if more have to edit code then there's a deeper problem.

That said, having an experience for those that want to edit is also something to weigh up. A minimal iteration for me would be:

• Syntax highlighting (this was explored I recall).
• Some phrasing and guiding.

I am not totally convinced in making it look like the old editor and full width. I think having it still be 'of the block' makes a lot of sense as long lines even of code are hard to read anyway.

For some of your extra points like dark mode and checkboxes in tab, I think that could be where we have to review if a plugin territory or something to really be of us too lots of people, across range. Totally worth digging into to see if that's case.

[spencerfinnell]

Some syntax highlighting discussion here: #10423

[joyously]

I don't think syntax highlighting is needed, but I would like to see the simple button toolbar for bold and italic and links (similar to this editor or the Classic editor HTML mode), so small things can be done while in HTML mode via the toolbar. Also important is the selection maintaining from one view to the other.

[noisysocks]

I think this is a really cool idea!

• I'm into the code editor being full width—this aligns with how most online code editors (Glitch, CodePen, etc.) work. It also aligns with our existing Theme Editor in WP Admin.
• I'd argue that Syntax Highlighting should always be on as it provides a better experience for folks familiar with editing HTML. Decisions, not options! 🙂
  • Will have to be conscious about accessibility though. CodeMirror is bad for this. (They're working on it!)
• I think a Dark Mode setting here is unnecessary and could be implemented in a plugin instead.
• I'd propose that we remove the Block / Code sidebar tab and keep the existing Exit Code Editor top bar. I like that this bar nudges folks to get back into our primary UI which is the block editor. We could make that top bar look like it's a part of the editor chrome and not a part of the post by giving it a non-white background or a bottom border.
• I love the suggestion of having the inserter add block HTML to the bottom of the editor, but it's difficult for blocks that have a placeholder. For example, inserting an Image block would insert HTML that doesn't do anything (<!-- wp:image --><figure class="wp-block-image"><img alt=""/></figure><!-- /wp:image -->).

[afercia]

Add syntax highlighting.

Not willing to repeat all the lengthy discussion from https://core.trac.wordpress.org/ticket/12423 but syntax highlighters were extensively tested for accessibility and they're not accessible.

The accessibility team is not opposed to a block with syntax highlighting or to an Editor mode with syntax highlighting but in the latter case there should be three Editor modes:

• visual (blocks)
• code (syntax highlighting)
• text (normal textarea)

The need for a normal textarea is fundamental, as for some users it's the only accessible way to edit content and actually publish on the web.

[afercia]

Related: #10423

[mapk]

I would like to see the simple button toolbar for bold and italic and links (similar to this editor or the Classic editor HTML mode)

@joyously, I'm not opposed to this. It would be like using the Top Toolbar option in the visual editor. But I'm also okay with not having anything like that included.

I'd argue that Syntax Highlighting should always be on as it provides a better experience for folks familiar with editing HTML. Decisions, not options!

@noisysocks, "Decisions, not options!" I get bit with that one all the time. If we can make syntax highlighting accessible, I'm all for defaulting it on. While I'm not for introducing three editor modes as @afercia mentions, he does bring up some good points to consider.

I think a Dark Mode setting here is unnecessary and could be implemented in a plugin instead.

Yep, completely agree. I was just getting excited about the possibilities.

I'd propose that we remove the Block / Code sidebar tab and keep the existing Exit Code Editor top bar.

Well that button really feel arbitrarily placed there inside the editor. I'd like to find another home for it.

I love the suggestion of having the inserter add block HTML to the bottom of the editor, but it's difficult for blocks that have a placeholder. For example, inserting an Image block would insert HTML that doesn't do anything

I'm okay with this because that's HTML that I didn't have to write. Sure I now need to add the src= but I didn't have to write any of the other stuff.

[dmsnell]

Agreeing with @afercia there is a clear value in having three editors. The code editor isn't the same as "plain text" as we can enhance the view while maintaining the structural integrity of posts. It becomes another block list of Elements but instead of visual direct-manipulation blocks we get a generalized block supporting every block and that gives us the ability to edit the insides of the block content.

That's probably poorly worded. What we would love to avoid is allowing for partial updates to the "source code" of a Gutenberg page. That is, we should never have an autosave or update including, for example, <!-- wp:paragraph - that would represent invalid syntax. Instead, it'd be better if we could make sure those edits are atomic, and something like <!-- wp:paragraph --><!-- /wp:paragraph --> were the minimal entry.

So imagine a different view of the block editor that showed you the block name, JSON attributes, and content of the blocks and was focused on making quicker text edits to the structural elements. However, instead of treating everything as text we make some special behaviors for adding, changing, and manipulating the block structure.

This would be akin to the dev tools HTML inspector which lets you click into an HTML tag and change its name, click into the attributes and change their values, and edit the #textNodes directly.

[afercia]

Not opposed to alternative editors whether they're atomic, non-atomic, whatever.

From an accessibility perspective, noting again the request is to have a native <textarea> element containing the post content to provide users with a traditional web form. That's the only UI guaranteed to work with any device and any assistive technology.

we should never have an autosave or update including, for example, <!-- wp:paragraph - that would represent invalid syntax
I'm a bit surprised 🙂the chance users may corrupt a Gutenberg comment is an architectural flaw that was outlined several times by many experienced contributors since the very beginning of this project. It can happen at any moment, even if the parser tries to repair the comments.

Hiding the HTML blob behind one more UI doesn't solve the architectural issue and doesn't solve the accessibility issue. Just gives us a textarea please.

[dmsnell]

@afercia that's all fine. my response was to the original issue post discussing how to make the code view better for people wanting to mangle more HTML and CSS directly. keeping a plain-text and accessible view is great; it will always belong.

what we have currently is the worst of both worlds: we allow non-atomic updates and it's not accessible.

I'm just coming in and acknowledging that this view is a different render of the post and has different needs which can go beyond treating the post as plain text, which it isn't.

the chance users may corrupt a Gutenberg comment is an architectural flaw that was outlined several times by many experienced contributors since the very beginning of this project

I'm not sure I follow the point you are trying to make. none of the fragility is new or surprising. the value of editing the "code" structurally is that it adds a layer of protection against the kind of manual updates which unintentionally break blocks.

maybe I'm misunderstanding you, but are you trying to express your disagreement with the choice of the comments? what is surprising about the possibility of breaking manual updates?

[afercia]

none of the fragility is new or surprising

Exactly. From your previous comment I had the impression you were acknowledging now what many warned against in the last 2 years and a half (the comments fragility).

Regarding the textarea see:

Previous comment:
#17017 (comment)

See also:

19 Mar 2018
#5698

28 Apr 2017
#569

[paaljoachim]

How can we move this issue along?

[noisysocks]

How can we move this issue along?

I think let's punt on syntax highlighting and work on improving the problem areas that @mapk identified in his original comment. Design feedback and a final mockup is needed before we can proceed with development.

[mapk]

The Design Team discussed this in today's triage on Slack.

Some next steps to help this move along are:

1. Add a column for numbered lines as in the initial mockup above.
2. Remove the borders and allow full width.

Future iterations:

• Allow ability to add empty block HTML with the Inserter.
• Remove the "Editing code" label at the top. Figure out what problem prompted this solution to see if there are other solutions possible.
• Remove the "Exit code editor" link and design an alternative way to achieve this. I think it's here to support keyboard navigation, but maybe there's another solution?

[joyously]

I disagree that the borders should be removed. It should stand out as being different from the visual mode blocks.

[afercia]

Accessibility feedback has already been provided in a couple previous comments, see:
#17017 (comment)
#17017 (comment)

I see latest feedback from the Design team on #17017 (comment) asks for something different.

Add a column for numbered lines as in the initial mockup above.
Remove the borders and allow full width.

Both features can go in third editing mode. For accessibility and interoperability, it's fundamental there's a simple textarea because that's the only user interface that is guaranteed to work everywhere.

Remove the "Editing code" label at the top.

That's not just plain text. It's a H2 heading which allows for better semantics and content navigation for assistive technologies. As such, I disagree on removing it because it's there for an important purpose.

Remove the "Exit code editor" link and design an alternative way to achieve this. I think it's here to support keyboard navigation, but maybe there's another solution?

I don't see the need to remove that button: it serves a purpose and improves keyboard accessibility. What is the argument to remove it? In what way its removal would improve the user experience?

[strarsis]

Related issue:
Currently I can't click the "Exit Code Editor" button, I first have to scroll up. It is somehow obscured by other editor UI.

[nicgithab]

How soon will visual marking (highlighting) of open/closed wp-comments be implemented in the code editor?

[windhamdavid]

Since this issue is still open, I figured I'd add my recent experience to it. Last month I spent a bunch of time migrating a couple older themes to full site editing which involved building page layouts in Gutenberg so that I could copy/paste the markup from the Code Editor back into parts and patterns files. Even with some autocompletions, I discovered that it was faster to copy from the Gutenberg code editor than write them from scratch, so being able to quickly identify various parts with Syntax Highlighting in the Code Editor would have made that process much easier. ( ref - #10423 )