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

 Andrea wrote:

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

 Separating the code editor in Customizer from the code editor for posts
 and the code editor for PHP/CSS files would be creating a huge amount of
 redundancy. Surely there should be a single visual code editor throughout
 WordPress and a single optimised code editor for screen reader users not
 different implementations throughout the project.

 We settled on jQuery as WordPress's single javascript library. While not
 having MooTools or other javascript libraries available makes a few things
 harder, settling on a single main library simplified troubleshooting and
 made it easier to document best practices.

 >we need to focus on practical arguments like this rather than setting up
 '''conditions''' which are almost '''impossible to fulfill'''.

 (emphasis mine). This ten times over.

 There's absolutely no reason we can't make code editing better for
 everyone by improving the plain text editor to provide fantastic screen
 reader tools while adding a visual code editor for those who can use it.
 Everyone wins.

 It would surprise me if actual screen reader users are as jealous and
 eager to deprive non-screen reader users from features which do not
 benefit screen reader users as members of the WordPress accessibility
 group are. I'm not a surfer but I don't want to keep surfers from
 [http://www.surfscience.com/topics/surfboard-design/ enjoying soft top
 boards]. Nor do I begrudge marathon runners advanced running shoes, even
 though for health reasons I can't run (I cycle instead). Going the other
 direction, I'm the last person to want to deprive wheelchair users from
 having the most advanced innovations in wheelchair design.

 Heck, due to long hours working on the computer, I've had issues with
 vision myself (severe headaches looking at the scree, blurry vision). Who
 knows when I'll have to use a screen reader myself as a primary interface
 (I had to give up reading any news and just listen to audiobooks for two
 weeks recently). Hence I even consider myself in the target audience for
 both code editors. On both sides of the code editor question (visual and
 screen reader), I'd want the best possible tool for each use case, not a
 single code editor which doesn't really suit either side. To make another
 analogy, I don't wear the same shoes for hiking as I do for cycling.

 Anyway there are practical issues to solve. Let's solve them.

 Rian wrote:

 > If you really want this, develop a plugin, we can test it without
 forcing it up onto people, we also can monitor how often the plugin is
 installed. If the plugin turns out to be very populair we can spend time
 to make it accessible before integrate it into core.

 We already wrote a feature plugin ([https://wordpress.org/plugins
 /thoughtful-comments/ Thoughtful Comments]) which provides front end
 comment editing and speeds up loading comments by a factor of ten. As
 Automattic had Intense Debate at the time and people were satisfied with
 Disqus (didn't realise core's role is to promote third party products
 whether Jetpack, WordPress.com or Disqus: for me self-hosted software is
 about freedom and independence) and I'm not politically connected (happily
 stranded out here in Middle Europe and I won't travel to the States) there
 was little interest in adding these improvements to WordPress which are
 free for the taking (those improvements were not free for the making:
 there are hundreds of hours invested).

 This is a long way of saying that doing a lot of development for free,
 hoping that someone might smile at me sometime is not in the cards Rian.
 We have maintained five feature/pro plugin level plugins for five years or
 so (some more, some less). Only one of those we charge money for. I'm
 slowly convinced that offering free plugins to the community at this point
 is a waste of time as there is little respect in our community left
 (whether from core developers or from the end users or from Automattic)
 for free plugin developers. WP Rocket probably had it right from the
 beginning: all paid, all marketing, all the time.

 This state of affairs makes me sad.

 Not sad enough not to want to contribute financially and in terms of
 design and code to a brilliant implementation of an improved code editor
 within core, along with much needed enhancements for screen reader users
 for the plain text editor.

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