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

 I'd second @jorbin's proposal to close this ticket as maybelater. Apart
 from the technical issues we've proven with real testing, I'd also like to
 add some general considerations.

 Just my 2 cents of course, but I think this kind of decisions should be
 based on actual data. I haven't seen ''any'' data to support the
 introduction of a code editor with syntax highlighting. The only rationale
 mentioned was that the introduction of this feature was "raised during the
 Q&A at SOTW". Aside: please expand abbreviations since not all the people
 reading this ticket may know what "SOTW" (State Of The Word, during
 WordCamp US 2016 I guess) means.

 I'd argue the audience at the State Of The Word is really representative
 of the WordPress user base, since it's typically made of people with good
 technical knowledge or, at least, by advanced WordPress users.

 At the risk of sounding a bit pedantic, I'd also like to remind some of
 the points of the WordPress philosophy, as it seems, as developers, we
 sometimes tend to forget them.

 https://wordpress.org/about/philosophy

 '''Design for the Majority'''
 Many end users of WordPress are '''non-technically minded'''. They don’t
 know what AJAX is, nor do they care about which version of PHP they are
 using. The average WordPress user simply wants to be able to write without
 problems or interruption. '''These are the users that we design the
 software for''' as they are ultimately the ones who are going to spend the
 most time using it for what it was built for.

 '''Clean, Lean, and Mean'''
 '''The core of WordPress will always provide a solid array of basic
 features. It’s designed to be lean and fast and will always stay that
 way'''. We are constantly asked "when will X feature be built" or "why
 isn’t X plugin integrated into the core". The rule of thumb is that the
 '''core should provide features that 80% or more of end users will
 actually appreciate and use'''. If the next version of WordPress comes
 with a feature that the majority of users immediately want to turn off, or
 think they’ll never use, then we’ve blown it. If we stick to the 80%
 principle then this should never happen.

 Apart from accessibility-related considerations, I personally feel the
 feature proposed on this ticket doesn't fit with these principles and
 therefore I'd consider it plugin territory.

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