[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 afercia):

 Replying to [comment:103 FolioVision]:
 > I'll watch the test videos
 You haven't yet? :)

 Replying to [comment:95 melchoyce]:
 > My concern is primarily around improving the CSS Editor in the
 Customizer. It is, quite honestly, a painful experience currently.
 Dear Mel, I understand your point and I think we're all here to try to
 introduce improvements for everyone. To be clear, if we have any data to
 prove that 80% of the users would appreciate and use syntax highlighting,
 I'm personally not opposed to that. I'm opposed to the proposed
 implementation though.

 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.

 That said, what is being discussed on this ticket is slightly different
 though, and it's about introducing a code editor in 3 different places:
 the Post editor screen, the Theme/Plugin editors, and the Customizer.
 They're 3 very different places. 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. 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.

 > The mockup here: https://core.trac.wordpress.org/attachment/ticket/38707
 /customizer-css-i2.png is very clearly an improvement on the existing CSS
 editor in core. It makes CSS easier to read, write, and maintain.
 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 accessible technologies. So
 it would be an improvement for some users, not for everyone. 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.

 > Anecdotally, Jetpack's CSS editor is something I constantly recommend at
 local tech community project nights
 To clarify, Jetpack uses CodeMirror with its default "textarea" model
 (that means it does not use contenteditable) so it's completely not
 accessible, way worse than the implementation we've tested which does use
 contenteditable instead.
 No one here is sponsoring Jetpack (sorry @FolioVision maybe you should be
 better informed before commenting), for sure I'm not.

 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.
 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.

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