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.


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.
+ 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.
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:
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!
<!-- 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:
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.

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.

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,