Make WordPress Core

Opened 7 years ago

Last modified 4 days ago

#12423 assigned feature request

Include default code editor

Reported by: scribu Owned by: afercia
Milestone: 4.8 Priority: normal
Severity: normal Version: 3.0
Component: Editor Keywords:
Focuses: accessibility Cc:


We've dropped CodePress since it wasn't quite up to par in regards to browser compatibility.

How about using Bespin for editing plugin and theme files?

Attachments (1)

12423.codemirror.unminified.diff (751.2 KB) - added by georgestephanis 8 days ago.
First patch at including CodeMirror.

Download all attachments as: .zip

Change History (60)

#1 @scribu
7 years ago

There's already a plugin that does this (on a separate admin page):

Better File Editor

#2 follow-up: @c00l2sv
7 years ago

Bespin has poor support for non HTML5 browsers [1].

What about CodeMirror [2]?
Pretty active development and cross-browser support, bsd-like license [3], clean look[4].

[1] https://wiki.mozilla.org/Labs/Bespin/UserGuide#Requisites
[2] http://marijn.haverbeke.nl/codemirror/
[3] http://marijn.haverbeke.nl/codemirror/LICENSE
[4] http://marijn.haverbeke.nl/codemirror/contrib/php/index.html

#3 @nacin
7 years ago

I've also been looking at EditArea. http://sourceforge.net/projects/editarea/

#4 @jane
7 years ago

I was at a panel with one of the guys behind Bespin last week and he said flat out that Bespin was created knowing that they didn't have to worry about IE based on their audience. It was a Canvas vs Flash panel at sxsw, and though it looked cool, it looked very niche in availability based on our general audience browser stats. I don't think we can use Bespin unless we are going to try and be trailblazers for Canvas/HTML5 and basically pull an early-2000s web standards trick and just say 'your browser sucks, upgrade,' which is sometimes tempting, but would be a bummer for users who don't get to install software on their machines and are stuck with pre-9 IE (schools, libraries, government agencies, etc). Injecting a Chrome frame into IE is their workaround I think.

#6 in reply to: ↑ 5 @nacin
7 years ago

  • Milestone changed from 3.1 to Future Release

Replying to c00l2sv:

Also found this: http://shjs.sourceforge.net/

General thoughts here. By all means, we should identify and test as many projects as possible. That said, I don't think we want to repeat mistakes made with CodePress in regards to project activity. http://shjs.sourceforge.net/ has only one maintainer (as does EditArea and countless others) though it also hasn't had a release since 2008.

It would be naive to think that just because a project supports IE6 now, it'll always support every presumably more standards-compliant browser in the future (not to mention future standards). Aside from that, inclusion in WordPress would reveal existing bugs thanks to a larger userbase.

Finding an active (and willing) project should be as important an objective as finding one that works cross-browser.

#7 @c00l2sv
7 years ago

What are the chances to fork an existing project and maintain it exclusively for WordPress (patching and bug fixing if problems arise)?

#8 @mitchoyoshitaka
6 years ago

  • Summary changed from Include Bespin as default code editor to Include Ace (or similar) as default code editor

Bespin, which became SkyWriter, now has merged with and is superceded by Ace. Ace doesn't require canvas for its rendering engine. It is tri-licensed (MPL/GPL/LGPL).

#9 @mitchoyoshitaka
6 years ago

  • Cc mitchoyoshitaka added

#10 @aurimas
6 years ago

  • Cc aurimas added

#11 @mitchoyoshitaka
6 years ago

FWIW, note that Mozilla themselves have decided not to use Ace wholesale for integration into the browser for Firefox's DevTools initiative (think native Firebug).

More info on that decision here:

The bug for their work on integrating their winner, the Orion code editor, into fx is here:

#12 in reply to: ↑ 2 @WraithKenny
5 years ago

Replying to c00l2sv:

What about CodeMirror [2]?
Pretty active development and cross-browser support, bsd-like license [3], clean look[4].

I've been using CodeMirror in Scripts-n-Styles and like it alot. The best feature is mixed-mode support so that script and style tags are appropriately highlighted in html which in turn is highlighted in a php file which is properly highlighted.

#13 @WraithKenny
5 years ago

CodeMirror is a solid and unobtrusive editor (degrades gracefully, ie, doesn't impact without javascript) which is simple to include into the plugin/theme editor pages. For example, I've quickly integrated it into Scripts-n-Styles to see what would be involved (and because I thought it'd be useful):


The CodeMirror part of it works great (though there are bugs in the wp side of the editor). There are also quite a few other plugins that configure CodeMirror in more advanced ways, to include Search-n-Replace, Auto-complete, and more. (This also means it is somewhat tested in the wordpress environment.)

CodeMirror is open and actively developed https://github.com/marijnh/CodeMirror2/graphs/impact

Supports Firefox 2+, Chrome (any version), Safari 3+, Internet Explorer 6+, Opera 9+ http://codemirror.net/

Anyone still interested in this? I think I remember something about splitting the editors completely out of core and into a "Core Plugin" like the importer plugin. If so, any interest in that? (I'd contribute if it had blessing.)

#15 @WraithKenny
4 years ago

An update: Adobe decided to go with CodeMirror over ACE: https://github.com/adobe/brackets/wiki/Notes-on-CodeMirror essentially because of its MIT license. Their engineers are working with CodeMirror's developer, so the project has more support behind it.

On the related ticket above (a request for highlighting in the post editor) CodeMirror has a markdown mode included.

Also, In the mean-time, I'm sure ACE has evolved from the last time I checked, and they moved to a BSD license.

#16 @bpetty
4 years ago

I can't find it now, but I know there was some recent discussion regarding possibly removing the code editors entirely from core because they are just so dangerous for most users, and now that WP 3.4+ has the theme customizer, the theme editor really isn't needed/recommended at all.

Anyway, I think this is part of the reason that when I proposed doing exactly this kind of thing with the editors, I was forced to convert my patch into a plugin. Here's the relevant IRC discussion, and here's the final plugin (which made use of ACE).

Given the above though, I think that we really should start closing up these tickets just like all other "plugin material" requests, they honestly aren't going to ever be merged in when it comes down to a finished patch in the end, based on my experience. It's definitely less than 20% of users that end up needing the editors or using them, and they encourage the horrible practice of "cowboy coding". Everyone that told me to move it to a plugin really was right, the entire editors themselves should be a plugin.

#17 @scribu
4 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I'm not sure why the code editors have stuck around for so long; wordpress.com probably uses entirely different code for enalbing CSS editing by now.

Version 0, edited 4 years ago by scribu (next)

#18 @DrewAPicture
17 months ago

#23601 was marked as a duplicate.

#19 @westonruter
6 weeks ago

  • Keywords needs-patch added
  • Milestone set to 4.8
  • Resolution wontfix deleted
  • Status changed from closed to reopened

CodeMirror was originally proposed to be employed by the Custom CSS feature (#35395), but it was removed from what was committed due to the 4.7 timeline and the size of the library. In its place, a regular textarea was added with support for tabbing. Nevertheless, it is used by Jetpack for its enhanced Custom CSS feature. Having syntax highlighting and syntax error checking would be very helpful for users.

In addition to being used in the Custom CSS feature, having a proper code editor available would be greatly helpful for the file editor and also the HTML post content editor (as was raised during the Q&A at SOTW).

So, is CodeMirror the library that core should ship with and employ?

#20 @iseulde
6 weeks ago

Thanks @westonruter for reopening this. Cc @joen @azaozz.

Some other conversations: https://wordpress.slack.com/archives/core-editor/p1484239765000646 (scroll a bit down too).

We have talked about this lot for the text editor too and I'm leaning towards a yes to add a code editor there as well. In the case of the text editor, I would still keep the look more or less similar to what we have at the moment: a light (maybe even just greyed text) theme, no line numbers etc. In other words, no scary code editor feeling.

The benefits would be:

  • Syntax Validation. This is very useful for users who just want to change something small and are not that familiar with HTML.
  • Autocomplete tags. This might be especially useful if we want to drop auto-p.
  • Separate HTML tags and text with colour. Initially I though just greying out the HTML tags a bit would be a good default. We could format the HTML better too to make it more readable.
  • Switching mode without losing context. This has been a hard issue to solve with a text area, but if we use a code editor it's easy to scroll to the right part in either mode when switching.

I wouldn't add a code editor without making it a pure HTML editor. I'm not entirely sure what all the reasons were for adding auto-p all these years a go, but my guess is that:

  • It was annoying to add all the paragraphs by hand.
  • There was no visual editor, and it make it a bit more visually pleasant.
  • It would be noisy to have all the paragraph tags.
  • It would looks more like code and scary.

With just a text area these issues were hard to solve. But a code editor comes with many possibilities:

  • Autocompleting paragraph tags when pressing enter, which would be similar to the visual editor.
  • We can grey out the paragraph tags, or, more extremely even, make them invisible.
  • We can leave a margin between the top level tags so it resembles the visual side more closely.

So a code editor could also mean no more auto-p!

#21 @afercia
5 weeks ago

  • Focuses accessibility added

Adding the accessibility focus, especially for the "HTML post content editor" part.

#22 @celloexpressions
5 weeks ago

I'm not sure that we should lump custom CSS and the editor into the same discussion here other than selecting a library to use (that could potentially be used for both). They're fundamentally different experiences that will require very different things to implement. I'd suggest using this ticket to select and add a code editing library, then use separate tickets to implement it in the various places.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

5 weeks ago

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.

5 weeks ago

#25 @westonruter
5 weeks ago

For code editor for Custom CSS, see #38707.

#26 @FolioVision
3 weeks ago

Hi Iseulde.

Adding a proper code editor would be a huge improvement to the core editor. I have some ideas about also splitting Visual into Preview and Writer but that's a bigger jump. You wrote:

So a code editor could also mean no more auto-p!

Yes to that. When we wrote Foliopress WYSIWYG (the low ratings came in a period where we were had decided to end of line Foliopress WYSIWYG and migrate to the core Editor. In the end we were unable to do so as too many complex posts were broken on save in TinyMCE. Most of our users stopped using Foliopress WYSIWYG during that period. It does work well enough that there were about 10,000 active installs at its peak) we contended with exactly those issues with WP auto-p. We ended up disabling auto-p completely. Yet we had to count on people turning our editor on and off. So we wrote some code (which is in the current editor) to deal with posts that are counting on WP auto-p in a resilient way.

We'd be happy to help with a migration forward which eliminates WP auto-p going forward yet does not break existing posts on open or require active intervention from end users.

Syntax colouring. For the new code editor to be truly useful, syntax colouring is essential. This mania for low contrast design is just a fashion trend. It will swing back. Form should follow function. I think a subtle colour scheme would be far more useful for WordPress publishers than a trendy low contrast look. I should add that for those users in their forties and beyond, low contrast is almost unreadable/unusable. For accessibility reasons alone we should include coloured syntax.

If you look at the full Ace Demo, there's a lot of skins available. I'd suggest both Eclipse and KatzenMilch could be subtle enough colour schemes to fit in well with WordPress.

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.

2 weeks ago

#28 @westonruter
2 weeks ago

  • Owner set to georgestephanis
  • Status changed from reopened to assigned

Assigning out for initial core patch of CodeMirror integration based on prior art from Jetpack.

#29 @FolioVision
2 weeks ago

Hi Weston,

Thanks for the update. A couple of questions:

  • Why did we choose CodeMirror over Ace?
  • Is there any reaction to my suggestions about syntax highlighting (@iseulde Eclipse or Katzemilch as good options for WordPress)?

Thanks, Alec

#30 @jadpm
12 days ago

One fantastic side effect of including Codemirror as a core library is that all plugins developers would get to use the benefits of sharing an asset handle and a known version. Right now, using Codemirror in your project is faily common but dangerous as you end up with duplicated scripts of sometimes quite different versions.

This ticket was mentioned in Slack in #core by westonruter. View the logs.

11 days ago

#33 @westonruter
11 days ago

  • Keywords needs-patch removed
  • Owner changed from georgestephanis to afercia

Suspending developing in light of CodeMIrror not being accessible. Assigning to wait for feedback from accessibility team on GPL-compatible code editors that pass the accessibility test.

#34 @afercia
11 days ago

Just to confirm what was discussed on Slack yesterday (see link to the Slack logs above), here's a couple screenshots. Worth noting these kind of editors should be tested on Windows with NVDA or JAWS or other Windows screen readers, since VoiceOver uses a different interaction model.

As @westonruter pointed out, CodeMirror does not use contentEditable internally. Also, it "decouples" the underlying textarea from the presentation of the content. Basically the textarea is almost always empty.

Using a screen reader, when navigating content in "browse mode" (e.g. using the arrow keys): the textarea is hidden just visually so screen readers announce it and it's empty. After the textarea, the presentation of the editor content is announced as it was normal text in the page:


When entering "forms mode" to operate inside the textarea, there's no content at all. As said, the textarea is initially empty and screen readers just announce "blank":


It is possible to enter content in the textarea, and the visual presentation gets updated with the new content but when trying to read out what you just entered, the textarea is empty again. This is because, in non-technical terms, CodeMirror clears out the textarea as soon as the arrows keys or Enter get pressed, since it needs to move the cursor in the visual presentation of the content.

Quick video where I've made the CodeMirror textarea visible to illustrate what happens under the hood: https://cloudup.com/iQRX47naOxY

#35 @FolioVision
10 days ago

Thanks for these notes Andrea.

Off the top, I always liked the ACE Code Editor. That said, it does seem to me that we could work around CodeMirror issue with screen readers. Either we could choose to mirror the content out to contentEditable or there could be an alternative source code editor provided when a screen reader editor for screen editors it seems to me would have widely different requirements for ideal behaviour than a visual screen editor.

Perhaps we could really improve the accessibility performance via automated substitution. There could be a hidden manual switch picked up by all screen readers just in case the automatic one doesn't trigger. Moreover, screen reader editing would be an ideal preference to pair with "Disable Visual Editor" in WordPress user profile.

#36 follow-up: @lukecavanagh
10 days ago

In relation to ACE and screen readers I did see this issue.


#37 @WraithKenny
10 days ago

Why not have a link/btn, much like "skip to main" that says, "disable highlighting for accessibility?"

This way, the enhancement wouldn't negatively impact users in any way.

P.S. or as @FolioVision said, "Disable Visual Editor"user option sounds good.

Last edited 10 days ago by WraithKenny (previous) (diff)

#38 @FolioVision
10 days ago

Thanks for that link Luke. That puts CodeMirror and ACE Code Editor on an equal footing in terms of accessibility. It sounds like visual code editors are exactly the opposite of what a screen reader/editor needs. Plain text would be much better than any of them.

Even more fabulous if WordPress could do better than plain text and insert the best screen reader/editor for those who use that technology while offering the best visual code editor for those who prefer that editor.


#39 follow-up: @westonruter
10 days ago

@afercia is there an established pattern to sniff out for whether or not a screen reader is being used and in that case just opt to not initialize CodeMirror/ACE/etc at all? If the textarea is best for accessibility, if we can just only progressively enhance the textarea with the code editing control when the user actually would benefit from it, that would seem like a good workaround.

#40 in reply to: ↑ 36 @afercia
10 days ago

Replying to lukecavanagh:

In relation to ACE and screen readers I did see this issue.


Thanks, interesting reading (especially the comments from Mr. Garaventa) that may help people understand why the technical choice implemented by CodeMirror and ACE is basically a hack.

In Ace we have textarea focused, which is used for capturing input and it's value is being reset after each keystroke. Visible text is not a part of the focused element, and selection is just a div.

Altering the native behavior of a control (in this case a textarea gets cleared out so there's no content to announce) actually means destroying the native level of accessibility that assistive technologies can understand. If there's really the need to alter in such a way the native behavior of a control, then it should be a developer's responsibility to rebuild that level of accessibility he/she just destroyed.

#41 in reply to: ↑ 39 @afercia
10 days ago

Replying to westonruter:

@afercia is there an established pattern to sniff out for whether or not a screen reader is being used

There is and it's: please don't do that :) Detecting screen readers is no different than sniffing browsers: difficult and unreliable. Additionally, there are some important ethical and privacy concerns to consider. Some interesting reading:

Thoughts on screen reader detection
Léonie Watson

On Detecting Assistive Technology
Joe Dolson

Why screen reader detection on the web is a bad thing
Marco Zehe

On Screen Reader Detection
Adrian Roselli

Detecting Screen Readers – No
Web Axe

Aside: I've spent some time testing the accessible, alternative version of CodeMirror: http://bgrins.github.io/codemirror-accessible/
While it works decently with Firefox+NVDA, it is not ideal when using Safari 10 and VoiceOver and it completely freezes Internet Explorer 11 when using JAWS 17, at least for me.

I tend to think that only editors based on contenteditable can offer a decent level of accessibility. Maybe, even something like (cough) draft.js could work better, if only decorators for syntax-highlighting existed (couldn't find any, so far).

#42 @iseulde
10 days ago

Re: accessibility:

CodeMirror has a contenteditable input mode: http://codemirror.net/doc/manual.html#option_inputStyle. This might work better with screen readers.

Selects the way CodeMirror handles input and focus. The core library defines the "textarea" and "contenteditable" input models. On mobile browsers, the default is "contenteditable". On desktop browsers, the default is "textarea". Support for IME and screen readers is better in the "contenteditable" model. The intention is to make it the default on modern desktop browsers in the future.

#43 @afercia
10 days ago

Testing the "contenteditable model", will post first results as soon as possible. Seems to me all that's needed to get the different model is using the Chrome emulator with a "mobile" device. Alternatively, there's a quick Codepen kindly setup by @iseulde: http://codepen.io/iseulde/full/apxRzj/

#44 @FolioVision
9 days ago

Hi Andrea,

Thank you for the links to some existing viewpoints in favour of no special treatment. It may have been more efficient to summarise the arguments and support those arguments with links. For the sake of brevity, I'll take one of the more recent posts and respond to each of the writer's arguments in turn.

78.4% of respondents were very comfortable or somewhat comfortable with letting a web site know they are using a screen reader.

In my opinion, it should have been the other way around.

So those opposed to special treatment for screen reader users are more anxious about the issue than the people on behalf of whom they are advocating. I salute Marco's frankness.

It would take away the one place where we as blind people can be relatively undetected without our white cane or guide dog screaming at everybody around us that we’re blind or visually impaired, and therefore giving others a chance to treat us like true equals.

That a screen reader user interacted with a website comment section or even an admin interface via screen reader is not then printed beside their name on the author's bio or in the comments section. So for everyone except the screen reader's browser, that person is an equal. While it would be diabolical to print submitted via screen reader beside every comment of screen reader users, that is not what we are talking about. We are talking about giving screen reader users an enhanced interface for their interaction with web publishing. It's perfectly possible for screen reader users to give a different user agent and get a standard interface at any point.

Second, this is just a modern form of the text-only alternative web sites of the 1990s when screen readers were still learning to stumble around graphical user interfaces, let alone the web, and those text-only alternatives were a necessary evil to get anything done in most cases. In the early 2000s, as screen readers became better and browsers more modern, those faded away.

Actually those text version only content rich version of websites are back again. This time they are called AMP. We as web developers and publishers have failed so badly by overbuilding, over monetising and over tracking our and our client websites that even Google has given up on content parsing/separation and is insisting on a separate version with the content.

The current worst of the bad examples is the “accessible alternative” of the Audible.com web site. For one, its feature set is limited, and second, it constantly throws you back to the standard web presence, when doing searches, for example, and other totally screwed user experience snafoos. Or is there anyone out there who is actually wanting to tell me they enjoy this and find it even remotely useful? And to add insult to injury, the stuff that is currently a bit tricky on the standard web site can easily be fixed by some WAI-ARIA markup and some consistent keyboard navigation JavaScript.

In our case, we are not talking about building out the public facing side of the website with enhanced interface and tools. We are talking about the admin and content creation side. It's pretty clear that the ideal content creation tool for a sighted person will look and work differently than the ideal content creation tool for a visually impaired person. Each are using different ways to perceive and manipulate that content.

To say otherwise is to suggest that when using a screwdriver one use a hammer or the inverse. Or that everyone playing a racket sport should use a tennis rackets, regardless if you're hitting a tennis ball, a badminton birdie or a squash ball.

And the old arguments still apply: Alternative versions of web sites tend to get out of date, no longer being maintained, and creating and maintaining them is more expensive than properly applying markup and learning the web accessibility skill properly once.

Again, we are talking about the admin side and talking about adding a full-fledged and globally rolled out and maintained enhanced content editing interface for screen readers. I see far less chance of those users getting short shrift in a custom interface, globally available across WordPress than if we compromise the visual content editing tool on their behalf. That seems the worst of both worlds:

  1. a second rate code editor for sighted people
  2. no enhanced code editor for the visually impaired

Everyone should get the best tool for their work. Heck, over on the new editor thread we are dealing with issues of writing vs layout. There probably need to be separate editing interfaces for each of those activities or both modes will have to accept a seriously compromised experience. This is not about inconsideration to people with disabilities but about making their lives better and their work easier.

Third, there are security implications. Ever since I started working for Mozilla in 2007, there have been repetitive inquiries about exposing whether a screen reader is running with the browser, and if so, also granting access to the accessibility APIs to content JavaScript to manipulate what screen readers read to the user. Either of these would give web sites knowledge or exposure of operating system bits that, in every other case, would be considered unacceptable. You wouldn’t want to give web site JavaScript access to your file system, which type of keyboard you’re using, what brand your processor is, or if your machine still has a floppy drive or not, would you? Accessibility APIs hook into all kinds of channels to expose all the needed information to assistive technologies. Granting a web site access to these APIs would open a level of access to a computer that is just unacceptable, and unnecessary, for a web site to have.

This is a more delicate question. We must find a way to provide a secure experience for the code editor for both screen readers and non-screen readers. The security argument is equally relevant with a single code editor or multiple code editors (sighted and screen reader).

Aural style sheets never gained acceptance because the expected gain was just not there, and the desire to have equal access to the same content as everybody else was much stronger. More recent requests all are just the same thing in different disguise.

Again we are not talking about the front end of a website where a screen reader user would have reason to fear his or her needs being neglected. We are talking about a controlled admin interface where the screen reader user will be an equally privileged visitor with a uniform interface across websites.

Responsive design while it envisions a single code base for a website indeed includes device specific hacks within that single interface (bigger buttons for touch devices for example). Enhancing a responsive interface to create a better flow for screen reader users makes a certain amount of sense but again that is a front end issue and not what we are talking about here which is back end publishing tools.

[I hope] W3C will provide enough incentive for web authors not to abuse the querying mechanisms described, and that this will only be used by very well-informed sites where the developers provide actual value. The privacy examples in that document look at least promising. Let’s hope it all holds up until this becomes a standard one day. I, for one, will strongly discourage web developers who ask me from using this unless I am personally convinced they know what they’re doing. And yes, like with Location sharing, I will personally be very restrictive about allowing sites access to that particular information if I’m asked.

Again, we are talking about a content creation tool in the admin area of a website. As WordPress core developers, we could do much to discourage tracking of which users are using what (not adding any hooks for tracking for example, requiring modifying core to track which as we all know is a huge maintenance burden and something most casually evil publishers will be either technically incapable or too lazy to implement).

For the screen reader users who are truly wary of tracking we could still leave the plain text option available which works equally well or poorly for non-screen reader users and screen reader users.

I respect and agree with a principle of equality for all people regardless of sensory perception or any disability. Yet I cannot not buy into the argument of creating a worst of two worlds solutions for both screen reader users and non-screen reader users to make sure that neither side has a tool best suited for his/her use. On the contrary I see an opportunity for WordPress to forge a bold path forward with improved tools for screen reader users baked into the core editing product.

As there isn't a single best way (due to browser capabilities, specifically the best way of handling contentEditable) to build a code editor for screen reader users and non-screen reader users, we should also be talking here about what the best code editor for screen reader users is and not just about what the best code editor for non-screen reader users is. And after we do, we should figure how to integrate each code editor equally and seamlessly.

That is what we as a community can do to better the editing experience and publishing opportunities for screen reader users.

Anything else means starting from scratch, building from the ground up, losing a year or two of development and still in the end having to divide the capabilities even if it's nominally under a single code umbrella instead of two. Where possible stand on the shoulders of giants. In this case, two are at our disposition for non-screen reader users: CodeMirror and Ace Code Editor.

Who can tell us which are the giants of code editing in the screen reader world?

#45 @westonruter
8 days ago

Some seemingly great results on using the accessible version of CodeMirror: https://wordpress.slack.com/archives/core-editor/p1487436288004630

8 days ago

First patch at including CodeMirror.

#46 @georgestephanis
8 days ago

First attempt at including CodeMirror in a patch is attached.

Be warned, it's over 700k, as it's just the unminified sources (that will shrink significantly when they get compressed prior to release). I just cloned the GitHub repo, switched to the most recent release tag, npm install to build it, and then added/removed files from svn as seemed prudent at the time. Happy to add/remove others.

The current patch does two things:

1) Add and register the relevant scripts and styles
2) Implements them for the Theme Editor screen -- CSS and PHP files.

That should let us play around a bit and see how it works in practice for a11y and the like.

There are a lot of files that I left out of the patch -- some addons, and some languages. There were a few addons and languages we likely won't directly need, but I included because they were pretty small and would likely be useful for some plugin authors -- like the Markdown and SQL modes, for example.

Last edited 8 days ago by georgestephanis (previous) (diff)

#48 @westonruter
8 days ago

@georgestephanis great! I opened a PR to collaborate on: https://github.com/xwp/wordpress-develop/pull/217

The remaining functional pieces would seem to be:

  • Incorporate with plugin file editor.
  • Utilize in Custom CSS customizer control.
  • Employ in HTML tab for the WP editor.

However, I realized that I hadn't actually done a search to see what plugins already exist that integrate CodeMirror, or another editor library, into WordPress. Doing a quick survey of plugins, there are several:

Good news is that CodeMirror came up over and over again in my quick search. But to move forward with incorporating CodeMirror and implementing it—for the theme and plugin file editor, content HTML editor, and the Custom CSS customizer control—I think we are first beholden to list out all of the plugins that already implement these fully and to loop in their authors to the conversation so that we don't reinvent the wheel, so we can incorporate the best of each of their plugins, and also so that we can be good neighbors since we'd effectively be deprecating their plugins.

All of this to say, it seems the next steps for this would be less technical and more communicative.

#49 follow-up: @afercia
8 days ago

As mentioned in the last dev meeting on Slack this should be extensively tested with assistive technologies. We'll discuss during next accessibility team meeting and probably ask the a11y testers group to test the current patch or the Codepen. In the meanwhile, I've done some first testing with screen readers and, although it's a bit early to make any judgment, first impressions are not so great. Seems navigating through content in the editor is extremely hard and I'd say it's a regression compared to the native textarea.

By the way, will limit to some first considerations about keyboard accessibility and semantics for now.

With keyboard only:
Usual known issue: since the tab key is used to enter tab characters, there's no way to tab-away from the editor. Keyboard users are "trapped" inside the editor. In the current Plugin and Theme editors, and in the Customizeer CSS textarea, WordPress allows to use the Escape key to tab-away. A similar solution should be implemented here too, not sure if this would require to hack CodeMirror.

Once the cursor is within the editor, some operating system-specific keyboard shortcuts are broken. Just a couple examples: on Windows, using Firefox, the shortcut Alt+D to move to the browser address bar doesn't work. On a Mac, Cmd+[ or Cmd+] to navigate to the previous/next pages don't work. I guess there are also other ones that are broken.

The editor is just a div. It should at least use role="textbox" aria-multiline="true" and an aria-label attribute with a proper value.

The autocomplete functionality:
it can be used with a keyboard but it's completely not accessible for screen readers. The drop-down list is just an unordered list without any ARIA treatment and nothing gets announced by screen readers.

#50 @georgestephanis
7 days ago

The conflicting keybindings aren't really a big issue -- they're trivial to rebind in implementation.

Marijn (CodeMirror developer) also remarked over email that

The contentEditable mode isn't rock-solid yet (especially on Android, which does some really weird things with input compositions), but it'll see more work in the next months, which should help with that.

@afercia -- I'm blocking off some time later this week to get on the CM github repo and try to submit a couple PRs to address some of your accessibility concerns.

Last edited 7 days ago by georgestephanis (previous) (diff)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

6 days ago

#52 in reply to: ↑ 49 ; follow-up: @FolioVision
6 days ago

Replying to afercia:

Andrea, what would be the gold standard in terms of a dedicated screen reader code editor? Is there one out there which does all of this and more really well?

@foliovision not that I'm aware of. We can do some research though. I think most of the issues are because contenteditable is still buggy and inconsistent across browsers. Add screen readers on top of that and you have an additional layer of buggy behaviours and inconsistencies. Even editors that have a complete different approach, for example draft.js, use contenteditable.

Last edited 6 days ago by afercia (previous) (diff)

#54 @FolioVision
5 days ago

Thanks for the links Luke. I particularly find useful Piotrek Koszuliński's essay ContentEditable — The Good, the Bad and the Ugly. Wow those Medium URLs are hideous and unreliable: let's never do that to URLs with WordPress. Here's a simpler working link which brings up both articles and any new ones about ContentEditable.

I found this section particularly relevant:

ContentEditable is like JavaScript, only Douglas Crockford hasn’t written a book about it yet. But (like JavaScript) it also has its good parts (yeah, I know — the good/bad ratio is debatable). It’s amazing that adding one attribute to an HTML element enables typing, selection, keyboard navigation, spell checking, drag and drop, pasting, undo manager. That all of this is integrated with the OS, that such editor can be used with a screen reader or on a touchscreen device and that it’s well internationalised. Let’s focus on these good parts and forget the bad ones.
Over the past years, while working on CKEditor I noticed that we were gradually replacing native features with our own implementations....It means that today CKEditor does not let the browser do anything to the content except handling typing, some deleting and that’s basically it. At the same time, it still uses the native selection system, keyboard navigation and other APIs such as those related to clipboard or focus management.

What this suggests to me is that any good JS code editor will be sufficiently complex that just pasting in some screen reader functionality will result in a not particularly sharp pencil. We would really be better off building a dedicated code editor for screen readers into our new code editor.

I would be very grateful if someone better versed in editing with a screen editor would share the gold standard for code editing with a screen reader so we could compare that ideal situation with where we are with the CodeMirror adaptation.

#55 @jorbin
5 days ago

Authoring Tool Accessibility Guidelines specify eight guidelines. Following each of these would likely be the "gold standard"

#56 @FolioVision
5 days ago

Thanks for the link, Aaron.

Aaron and Andrea, I'm a bit surprised to hear again about the guidelines when I'm asking about a gold standard implementation. What is the best existing implementation of accessibility for screen readers in a code editor? If we are to aspire to a better accessibility for screen readers, starting with the most successful screen reader code editor to date as a model would make the most sense.

If there are no good of implementations of code editors for screen readers, then we should say so and decide what is realistic to do within this round.

PS. On the other hand, if the best implementation is in CKeditor for example and we are determined to prioritise accessibility, perhaps it would make sense to move to the modular and fast iterating CKeditor from TinyMCE. CKeditor would give us perfect code support within the WordPress editor (hurray, no more mangled markup: even our venerable Foliopress WYSIWYG based on FCKeditor doesn't mangle markup) with even Markdown close at hand.

This ticket was mentioned in Slack in #core-editor by joen. View the logs.

5 days ago

#58 @iseulde
5 days ago

  • Summary changed from Include Ace (or similar) as default code editor to Include default code editor

This ticket was mentioned in Slack in #core by westonruter. View the logs.

4 days ago

Note: See TracTickets for help on using tickets.