[wp-trac] [WordPress Trac] #12423: Include default code editor

[WordPress Trac]

#12423: Include default code editor
-----------------------------+----------------------------
 Reporter:  scribu           |       Owner:  afercia
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  4.8
Component:  Editor           |     Version:  3.0
 Severity:  normal           |  Resolution:
 Keywords:  close            |     Focuses:  accessibility
-----------------------------+----------------------------

Comment (by melchoyce):

 Replying to [comment:105 afercia]:
 > In my opinion, the poor editing experience in the Customizer is
 primarily because the Customizer is not the right place for editing :)
 Crafting CSS in a 300px wide area is far from ideal, in fact in the
 mockups there's a proposal to add the ability to expand the editor in a
 popup (which introduces additional a11y issues, not to mention a popup
 looks so '90s). It seems to me that's just trying to "add stuff" to put a
 remedy on a design decision that maybe was not so ideal to begin with.

 It's not ideal, but I think it's the place where it makes the most sense.
 Believe me, I've been using it on .com for forever and I definitely feel
 the pain of only having 300px, but for small stuff? It's /okay/.

 I think once we start implementing the proposed enhancements, we'll likely
 add them piecemeal instead of all at once. The popup might not happen. By
 the time we get to it, we might even have a different Customizer design.
 :) Before we experiment with adding more space, I'd rather see syntax
 highlighting/formatting improvements and revisions, for example.

 > Introducing accessibility barriers in the Post editor would result in
 the complete inability to enter content so I'd say that is definitely a
 blocker.

 I agree! That's a huge issue.

 > The inability to edit CSS would have some less serious impact, but that
 doesn't mean accessibility should be a second-class citizen in the
 Customizer. Maybe worth considering a separate ticket for the Customizer
 CSS highlighting.

 You mean pull syntax highlighting out of #38707 and into its own ticket?

 > While line numbers, colors, and "auto-tabbing" can help code readability
 and the editing experience, what CodeMirror does under the hood is far
 more than that and has a devastating impact on assistive technologies. So
 it would be an improvement for some users, not for everyone.

 For the record, I have no attachment to CodeMirror or any other option
 folks have explored. It just seemed like the one with the most traction,
 and the folks working on it seem to be aware of the accessibility issues
 and are working towards fixing them. I definitely don't want us to launch
 something inaccessible.

 > We should really make an effort to stop thinking just visually and try
 to understand how a new feature can have an impact not just on people but
 also on software used by people.

 Worth noting that these updates aren't purely visual, they're interactive.
 I don't really care that the textarea looks bad — I care that it's hard to
 use.

 > How to move on? I'd suggest to open a new ticket for the Customizer CSS
 editor improvements. That would require some serious research and testing
 to be able to find accessible ways to implement line numbers, colors, and
 a few interaction aids like auto-indentation and so on.

 Already open at #38707 :)

 > Traditionally, the Customizer has been a place for experimentation and
 there are some great developers involved in the Customizer team so it's
 probably the best place to research new, accessible, solutions.

 If something this is the consensus — build something new, rather than
 adapt something existing — I'm totally fine with that.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/12423#comment:108>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform