Gutenberg: Improve the Code Editor

Created on 13 Aug 2019  路  16Comments  路  Source: WordPress/gutenberg

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

Screen Shot 2019-08-12 at 4 47 08 PM


Problem Areas

Screen Shot 2019-08-12 at 4 48 34 PM


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

Code Editor

Accessibility (a11y) Needs Dev [Feature] Code Editor [Priority] Low

All 16 comments

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.

Some syntax highlighting discussion here: https://github.com/WordPress/gutenberg/issues/10423

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.

I think this is a really cool idea!

  • I'm into the code editor being full width鈥攖his 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! 馃檪
  • 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 -->).

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.

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.

Screen Shot 2019-08-23 at 2 30 50 PM

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.

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.

editing-html-structurally

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,