Topic on Talk:Talk pages project/Replying/Flow

The result is the same regardless.

Is it necessarily possible to apply the 2017WTE consensus here? That consensus was for the use of the editor in article space, where the considerations and applications for the software are substantially different to the ones for this project. It is not very likely that FA-length replies are going to be written regularly, and new users would presumably be less likely to run into issues with loading time and such. Other users have noted that the editor has improved since then.

Additionally, the editor within Structured Discussions (the one we have been using on this page) is actually a separate editor to both modes of Extension:VisualEditor (per Editor). Considering that the editors have clearly diverged in some ways despite both being based on Parsoid, I think it is important to make the distinction. It is not clear to me whether the Editing team would use either editor's code.

That said, I personally would want there to be an option to use a <textarea>-based version of this editor, primarily because some users may not want to or may be unable to use JS/VE, but may still want the ability to reply inline. Presumably, this would mean leaving the prototype's edit box in the software in some form. However, this could come with disadvantages; e.g. the team would be forced to maintain two largely redundant versions of a number of things (e.g. previewing, formatting toolbar).

Wikitext does not require it to be nested.

Citation needed? I think this is somewhat of an apples-to-oranges comparison, because HTML has a formal specification (by design) and wikitext doesn't (probably not by design). Additionally, wikitext is rendered server-side (and so displays the same for all end users), whereas HTML is rendered client-side (and so browsers differ in what HTML they are willing to render and/or how they render it). I think it would be more helpful to refer to something more specific than "requiring" something, because what this means in relation to the two formats is not really the same, and this reduces the meaningfulness of the verb in this context.

HTML's formal specification does not prevent website owners from serving invalid or incorrect HTML. Obviously, making the XML structure incorrect will cause most browsers to throw an error, and in that specific case wikitext is somewhat more lenient because the parser needs to fix misnesting so that the generated HTML doesn't contain XML errors. Nevertheless, I would be wary of interpreting this as an open invitation to let users misnest wikitext wherever they want. There isn't really any evidence that the intention of this particular feature (that is, the parser's fixing of misnesting) is for wikitext to be "more accepting and more intuitive", even if wikitext is "designed to be easier to use and learn than HTML", because it seems to primarily serve a much more pragmatic function (that is, to allow browsers to render the generated HTML at all).

On the other hand, both MediaWiki and web browsers allow authors to use deprecated tags and introduce all sorts of semantic errors (e.g. block inside inline) and whatnot. In this case, the MediaWiki parser typically just doesn't do anything, and the errors end up in the generated HTML as well. This category is what I was mainly referring to by "routinely use incorrect syntax" (e.g. misuse of list items).

Within the set of wikitext errors that the parser attempts to fix, there is the set of errors that the parser does not fix "correctly". As such, I think it wouldn't be acceptable to expect users to rely on the parser to fix errors.

From this, I think both of these approaches could logically follow:

1. A wikitext editor should highlight and attempt to suggest fixes for (or autofix) all errors that the parser would attempt to fix. This would tell the user that something is wrong with their code, whereas the rendered HTML might not communicate that.
2. A wikitext editor should not attempt to suggest fixes for (or autofix) any errors, even if it highlights detected errors. Doing so would encourage the user to rely on the software, even though its fixes might not be correct.

Obviously, the second approach is much easier to implement, even if users could benefit from the first. In practice, the Structured Discussions source mode is the only source code editor that doesn't use the second approach. (2017WTE also seems to use the second approach; upon limited testing it appears that it doesn't actually do any autofixing, or at least the SD editor is a lot more aggressive with wikitext.)

The SD editor also doesn't really use the first approach; it makes some unnecessary fixes like removing spaces after bullet points. I think this might be a design limitation rather than something intentional; both editors include the spaces if the bullet points are created in visual mode, but SD will confusingly proceed to remove the spaces if you switch modes or save the comment even though the editor introduced them in the first place. Given that 2017WTE does not seem to use the same approach (as far as I'm aware), I don't think it would be appropriate to assume that the new inline editor would also be problematic in this way; if another attempt is made to follow the first approach, I would hope that it doesn't have the issues that the SD editor's implementation has.

This leaves some questions that remain to be answered:

• Will the textarea editor remain in the software, or will it be replaced? Is it too soon to say?
• How much code/features will the new WYSIWYG editor draw from (a) the VisualEditor extension and (b) the Structured Discussions extension?
• If the new WYSIWYG editor has a "source mode" like VisualEditor, will that source mode take any particular approach towards syntax highlighting, error highlighting, error autofixing, or similar?

@PPelberg (WMF), would the team be able to answer any of those questions at this point in time?