Topic on Talk:Talk pages project/Replying/Flow

Prototype testing report

15
Alsee (talkcontribs)

First, I'm not saying the full page needs to be in the edit box. However the product concept should be somewhat more closely derived from the current editor. The community essentially asked for three quality-of-life improvements over the current talk system:

  1. We don't want to have to count and type the indent markup. Put it in the box for us.
  2. We don't want to have to type ~~~~. Auto-add it on the end. Displaying this is less important than displaying the indent-markup, but it should be visible at the bottom right for consistency and simplicity of concept.
  3. Insert that blob at the correct place in the page.

Don't take radical leaps away from that. Hiding the indent markup breaks my ability to control that markup. Faking the indent markup is breaking the previews. Running things through VE's parser is a fundamental design flaw. It's breaking previews and it's breaking the content itself.

Jc86035 (talkcontribs)

(For the purposes of this discussion I'm going to ignore the fact that Parsoid exists, because discussing it here will not be productive by most meaningful measures.)

The summary of the proposed product direction that was used in the phase 2 consultation questions:

The Wikimedia Foundation proposes building a new, clearer design on top of existing wikitext talk pages. It will offer simpler tools for replying, indentation and signatures. You could continue to use wikitext on talk pages, if you prefer that. It should also be possible to participate in a discussion without using wikitext.

I analyzed the English Wikipedia responses to the summary in July. There was near-unanimous support of the summary's stated goals from the users whose accounts were created in 2007 or later (i.e. users who signed up in the last 13 years), though the users who joined before were clearly somewhat more ambivalent. Overall, more than three quarters of the respondents stated their support without voicing any concerns (although it is notable that some of them made their support conditional on their workflows not being disrupted and supported the changes primarily because of the benefit to new users; and a few opposed because they found the direction insufficiently ambitious).

The other community discussion summaries on the linked page indicate a similar distribution of responses, with most respondents supporting the statement and agreeing with the specifics.

Furthermore, the respondents were clearly supportive of the initiative as a way to make talk pages easier to use for inexperienced users; it follows that if the main goal is to improve talk pages for new contributors, the specific technical quality-of-life improvements that the community wants should not even be the main focus of the talk pages project to begin with.

So, in a nutshell, I would disagree with your comment's framing of the direction of the talk pages project, and would also disagree with the conclusion that the primary aims should be to make small and incremental improvements for the benefit of experienced users.

Regarding your specific concerns:

Hiding the indent markup breaks my ability to control that markup.

They're not taking the source editor away.

And from my experience using reply-link, automatic indentation is sufficient in most cases, so it's not clear what would normally be worth controlling. Even in the case where you would be expected to choose between : and *, typically this is dependent on what the previous users have used unless you're writing the first reply in a discussion. This is not even the first beta version yet; it wouldn't make sense to expect that edge case to be dealt with before everything else.

Faking the indent markup is breaking the previews.

Again, I think it is unrealistic to expect a prototype of unreleased software to work very well. The code for previewing, as far as I can tell, did not even exist until last week.

Alsee (talkcontribs)

@Jc86035: I would disagree... improvements for the benefit of experienced users.

I protest you and everyone else who slanderously frames opponents as some sort of selfish villains just because we disagree on how to best help new users.

The community is deeply protective of our on ramp for new users, and I expect community consensus will kill any product believed to damage that new user experience.

The Foundation had wonderful-sounding theories on how to help new users. Unfortunately those theories failed in practice. I believe community consensus has a better understanding of the process of turning new users into experienced users.

The new interface shouldn't be trying to hide the fact that we're a wiki. We're explicitly keeping talk pages as wiki pages, we explicitly plan to continue making some of our edits to the page the same way we do now. The new interface eases the most routine class of talk edits. If a new user is to become an experienced user, we expect that they are going to edit the talk page with the full page wikitext editor at some point. The new interface should be 'convenient training wheels', so the new user feels comfortable and familiar when they do click the full-page-edit. That means the new interface should look and feel sort of like a streamlined standard wikitext edit.

We help turn new users into experienced users with things like ensuring that previews are accurate. We help turn new users into experienced users with things like showing the indentation markup, so the new user can see it and learn how it works and control it. We help turn new users into experienced users by ensuring that the software does not randomly mangle what they type in. The Foundation likes to cite "broken markup" as an reason for mangling the user's work. That is not a valid excuse. New users are expected to experiment and they are expected to enter strange markup. If a user types in "broken markup" then that is what you save, character-for-character. That's how people learn on a wiki.

We might disagree on some points, but can we agree to kill the experienced-users-are-selfish-villains framing?

Jc86035 (talkcontribs)

Many of the experienced users in the consultation supported the direction specifically (and in some cases only) because of the focus on making talk pages better for new users. This, I would think, clearly shows a lack of self-interest in their decision-making; I'm not trying to villainize experienced users, and the data wouldn't be able to support that sort of judgement anyway.

Furthermore, the overall results of phase 2 of the consultation (as aforementioned) indicate that community consensus is more or less in favour of the approach that was proposed then, which explicitly mentions the introduction of a WYSIWYG editor. The present consensus is, then, to support the Editing team's direction (unless a different consensus is found by some future consultation or RfC). "Consensus", when invoked, should be an accurate reflection of the opinions of community members, and is not supposed to be a cudgel to get the developers to acquiesce to demands (and to be pedantic, it is nominally useless here per w:en:WP:CONEXCEPT).

The new interface should be 'convenient training wheels', so the new user feels comfortable and familiar when they do click the full-page-edit.

Talk pages do not have to be forced into being training wheels; it's arguable that they shouldn't be, and doing so may come at the cost of making communication harder. Moreover, definition lists and signatures are almost never used in articles, so forcing users to handle them in order to communicate has questionable utility (even if the aim is to familiarize users with wikitext). As I understand it, the new interface will have a wikitext option, so those using it would still be able to write comments in wikitext.

Talk pages, as I'm sure you're by now aware, were more or less an ad hoc solution, targeted towards an audience that was very different to both present-day new contributors and present-day experienced contributors. If the interface can be modified without breaking advanced workflows and such, then there is no practical reason to keep forcing that onto new users indefinitely, especially since there is little evidence that it actually helps them learn wikitext syntax.

If a user types in "broken markup" then that is what you save, character-for-character. That's how people learn on a wiki.

A wiki is a public environment. While you might not have been dissuaded by going through this sort of experience, some people might not like their mistakes to be recorded publicly forever. Forcing users to learn by trial and error (which is probably what usually happens) is a recipe for frustration.

And I would note that even experienced users routinely use incorrect syntax on talk pages. This suggests that users wouldn't necessarily learn from making mistakes on a talk page, since they might not realize their mistake to begin with.

Alsee (talkcontribs)

unless a different consensus is found by some future consultation or RfC

A new RFC may be necessary to clarify or make explicit some issues, but doubt the underlying consensus would really be any different.

There was a consensus to keep Talk pages and improve them for both new and experienced users. A number of ways of doing so were identified.

Converting a "direction" into a product requires filling in a lot of details. If the editing team declares "everything will be comic sans font" as part of their direction, obviously you cannot claim consensus for the editing team's direction.

There was nothing remotely resembling consensus for a VE default. For example on DeWiki a few people suggested a VE default - however it dies there to explicit and implicit opposition. On EnWiki a few people suggested eliminating the Foundation's restriction banning VE from some namespaces, and I do not recall any opposition to that idea. However that does not remotely equal support for reversing the default. VE is explicitly the secondary editor, and if the Foundation's ban on VE is lifted then VE remains the secondary editor.

During the consultation phase the Foundation did a really good job working to listen to the community. During this phase, it's starting to seem like there's disinterest in hearing from the community. The Foundation should welcome or even collaborate on any RFC for more clarity and information.

experienced users routinely use incorrect syntax on talk pages

There are good reasons HTML pages need "correct syntax". Those reasons do not apply on a wiki. The syntax is therefore not incorrect.

For example:

  • ''' bold '' bold-italics ''' italics ''
  • <b> bold <i> bold-italics </b> italics </i>

Both of those are correct wiki syntax. On a wiki, users are expected to use all sorts of random syntax. It is the job of the wiki parser to accept any syntax, and jump through the proper hoops to convert that into HTML-correct syntax.

On a wiki, the only "incorrect syntax" is syntax that didn't produce the desired result.

Jc86035 (talkcontribs)

Could you clarify what you refer to by "VE"? Does this encompass the source editing mode (i.e. the 2017 wikitext editor) as well or just the WYSIWYG portion?

The syntax is therefore not incorrect.

You can't just define "incorrect" out of existence and say that there's nothing wrong with misnesting HTML and forcing the parser to guess what it means. Words have meanings. Obviously, the editor still allows you to save the page, but that doesn't mean that you haven't introduced any syntactical errors; Special:LintErrors exists specifically because it is considered desirable to correct syntactical errors (strictly speaking, this is primarily because of the transition away from HTML Tidy, but the page is still maintained even though the transition has already occurred).

Alsee (talkcontribs)

Could you clarify what you refer to by "VE"? Does this encompass the source editing mode (i.e. the 2017 wikitext editor) as well or just the WYSIWYG portion?

Given consensus that wikitext is primary and consensus against 2017editor, I expect no one will be interested whether wikitext-inside-VE does or does not fall within a wikilawyer definition of "VE". The result is the same regardless.

Regarding syntax, what I wrote would have been misnested if I were writing HTML. But I wasn't. I was writing wikitext. Wikitext does not require it to be nested. Therefore it was not misnested.

The point of wikitext is that editors aren't expected to have any HTML programming training. Wikitext must be more accepting and more intuitive. Wikitext resembles and copies some things from HTML, but anyone who attempts to force "HTML-correctness" on wikitext is sabotaging new users.

Jc86035 (talkcontribs)

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 first rendered server-side (and so displays largely the same for all end users), whereas HTML isn't (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?

PPelberg (WMF) (talkcontribs)

Thank you for these clear questions, @Jc86035 – I'm working on gathering answers here.

Also, I appreciate how you acknowledged how definitive answers about implementation questions get harder to provide, the further into the future we are talking about.


PPelberg (WMF) (talkcontribs)

Okay, I've added some responses below.

Will the textarea editor remain in the software, or will it be replaced? Is it too soon to say?

It's too soon to say for certain. With this said, we have talked about, and explored, using the 2017 wikitext editor as the editing interface for the wikitext text input mode in the future. Although, we have not made any decisions about this yet and before doing so, we would need to, at a minimum, talk about it on-wiki and conduct user testing. And by "explored" I mean we have started documenting and investigating issues with the 2017Wikitext Editor with the intention of figuring out whether it is a tool we could all rely on in the future.

Note: I started to type out a fresh response to this question, then I thought, "I think it's okay to copy over what was written here: Topic:Vbp5bbixpqsqtv3s."

How much code/features will the new WYSIWYG editor draw from (a) the VisualEditor extension and (b) the Structured Discussions extension?

Our current plan is to use VE as the basis for the WYSIWG editor we are planning to release as part of version 2.0.

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?

Good question. We have not yet formed an opinion about whether things like, "syntax highlighting, error highlighting and error autofixing" would be included in a future version of the "source mode."

Our current approach to providing contributors with feedback they can use to identify "errors of execution and intention" (which it seems like the tactics talked about here are related to) is to show contributors a real-time preview of the comment they are composing (see: T238177).

It seems like you've thought about this topic quite a bit, so if there is anything beyond what you've mentioned above (e.g. the two different approaches), we'd be keen to hear it.

On the topic of previews, what's currently on the prototype is our initial approach. We are very much still gathering feedback on it: Topic:Vcehezaiyl3znf0d.

...please let me know if anything about the above could be made more clear or if any new questions come to mind.

Alsee (talkcontribs)

The wikitext parser actively transforms a variety of non-nested constructs into nested-HTML. It is implausible to suggest that the pattern of non-nested language behavior is accidental.

Regardless of original intent, one of our top priorities is to design for and accommodate users with zero programming or HTML knowledge. They don't know what syntax is, don't know what nesting is, don't know what DOM scopes are, and it would be harmful to expose them to those issues. It is important that wikitext work in an intuitive way insofar as we can. If someone types a non-nested <small><sup>(Note: see xyz)</small></sup> we don't want to bother them with nesting. It is visible and intuitive that small and sup were opened, it is visible and intuitive that small and sup were closed. It's a good thing that the wikitext parser does not expect nested syntax. Another example, if someone writes:

<b>Bold list heading
   * My first list item is still bold</b> 
   * The rest of my list is not bold

Again, we don't expect the user to know anything about HTML. We don't expect them to know that the * is converted into HTML list tags. They have no idea anything is nested at all. They don't want to know anything is nested. Non-programmers will parse it in more of a string-matching approach. The <b> string turns on bolding, and the </b> string turns off bolding. Everything in between is bold. Easy peasy. It is a good thing that the parser does not expect or implement nested syntax there.

The non-nested syntax is the clearly superior definition for the language. I know why the programmers prefer nesting. But we're a wiki, the users come first. We pay the programmers build what the users need, even if some aspects of the language design are less convenient for the programmers. Breaking that aspect of the language, for a purely internal programming agenda, would be harmful.

Jc86035 (talkcontribs)

Regardless of original intent, one of our top priorities is to design for and accommodate users with zero programming or HTML knowledge.

Even if it works (well, outside the version of Parsoid that Structured Discussions uses, anyway), is it necessarily superior? The current implementation can break as soon as background styling, padding, margins or borders are involved (including e.g. <pre>), and in some cases it's impossible to represent that well in HTML. Encouraging the use of misnested HTML – as opposed to encouraging users to fix it – would mislead users into thinking that it's always appropriate and will always work. Are there any use cases where intentionally keeping the misnested tags would actually be better than nesting them correctly?

That said, in practice a lot of "misnested" tags (that is, the ones shown in Special:LintErrors) seem to come from the non-misnested use of block-level elements inside inline elements, which Remex doesn't like (it splits up the inline element so that it's inside all the block elements). VE-Parsoid actually differs here, because it doesn't seem to care about the block/inline distinction (or at least the preview function of 2017WTE doesn't), whereas Remex and SD-Parsoid do.

Alsee (talkcontribs)

I don't understand why it seems to be so difficult to communicate this concept.

Let's imagine there are two wikis. Wikiwiki and HTMLwiki.

On Wikiwiki a new user sees various kinds of markup, with the simple concept that everything between tag-pairs is affected by that pair. Something like <small> means "turn on small style" and </small> means "turn off small style". The language deliberately does not care about nesting, insofar as possible. The language aims for "things do what they look like they do".

On HTMLwiki people either need to already have training in HTML and programming concepts, nesting and DOM scopes, or they are effectively forced to learn it. I'm a programmer, I understand stuff like nesting, but not everyone is mentally-built to think like a programmer. Let's look at a specific and grotesque example:

On Wikiwiki, everything between a tag pair is affected by that pair. Easy peasy.

On HTMLwiki sometimes the end tag is mysteriously ignored, spilling the markup down the entire page. A user points to several pages with different scenarios where this happens. Two simplified real world example cases are basically as follows:

::::<small>comment1

::::</small>comment2
The rest of the page, several entire sections, are all in small font.

and

<s>::::first line
 ::::last line</s>
The rest of the page, several entire sections, are all in strikethrough.

Those examples will confuse the hell out of new users. Those examples will confuse the hell out of experienced editors. Those examples will probably confuse the hell out of even a mediawiki developer, until they go digging and figure out what the heck is going on. Everything works fine up to three indentation, but at four-or-more indentation those pages break.

The user reporting the issue points out that everything used to work fine, there's nothing visibly wrong on either of the pages, the tags are balanced, and asks why is the pages are suddenly broken? The answer is, and I quote:

This behavior appears to be the result of the HTML5 "adoption agency algorithm", implemented by Remex:

https://www.w3.org/TR/html5/syntax.html#adoption-agency-algorithm (large page).

Specifically, this part:

If outer loop counter is greater than or equal to eight, then abort these steps.

Four colons :::: generate eight tags <dl><dd><dl><dd><dl><dd><dl><dd>.

No one but a programmer can understand the link supplied in that explanation, no one but a programmer can realistically follow the explanation for why the close-tag didn't work. And even an HTML expert would be hard pressed to provide an understandable explanation for why it was changed to do that. Everything used to work fine, but now four-or-more indentation sometimes breaks the page. It was broken in pursuit of a purely internal agenda. I hope anyone can understand that this kind of wiki-behavior will only confuse and drive away users, and this kind of rationale will only confuse and drive away users. The point of a wiki, the point of wikitext, is to be understandable and usable by average people who don't want to learn strange and obscure HTML rules. The point of wikitext is to NOT be HTML.

Jc86035 (talkcontribs)

Thank you for mentioning those specific examples here. I had no idea that this was part of the problem you were talking about. (At this point, this isn't really directly related to the original subject of this thread, so apologies if I've ended up sidetracking this discussion.)

Considering that the earlier Phabricator task was declined and the later one was merged into it, the clearest options to me would be to either increase (or remove) the limit, or do nothing. Changing the behaviour now would have the side effect of potentially breaking wikitext that has been written since the RemexHtml transition, would take RemexHtml out of compliance with the HTML5 standard, and would require more effort on the part of the developers than doing nothing. I think I would agree that the algorithm (as specified) doesn't really seem suited to the specific task of fixing wikitext misnesting, mainly because of the unusually low numerical limits, but there are still good reasons to keep Remex as it is. (I also don't know how easy it would be to get a +2 on such a change, since Remex was most likely stabilized a while ago.)

If there isn't anything to be done, there isn't much of a point in discussing this particular part of the issue here. If you think there's a case for reopening phab:T199057, then... well, this isn't really the place either.

On Wikiwiki, everything between a tag pair is affected by that pair.

Obviously this is supposed to be a comparison between parser.php+Tidy and parser.php+Remex, so I think it would be best not to oversimplify and claim that Tidy was able to do this perfectly.

For Tidy (as well as Remex, in most of these cases), the claim that misnested markup will always work isn't true for many combinations of misnested tag pairs (notably those involving pre, nowiki, ref, noinclude, includeonly, onlyinclude, and some extension tags), isn't true for many misnested combinations involving wikimarkup (particularly combinations of wikimarkup and XML), and generally isn't true for misnested combinations involving templates or magic words. (Tidy also breaks certain combinations of XML with wikimarkup even with correct nesting.) It follows: this behaviour was already somewhat inconsistent to begin with, so is it necessary to keep the behaviour precisely as inconsistent as it used to be?

(Incidentally, I couldn't find any wikis with Tidy still enabled, so I couldn't actually test these. I'm fairly confident in this being accurate, but it would be nice if these things could be tested without having to bother with installing MediaWiki locally.)

It was broken in pursuit of a purely internal agenda.

My understanding of the situation is that HTML4 Tidy had to be replaced anyway because it was no longer maintained, and this particular issue came up because Remex (which was written specifically as a Tidy replacement) exactly follows the parsing algorithm in the HTML5 specification, which can be somewhat problematic for the reasons you've mentioned.

It's definitely clear that there is a strong internal developmental agenda – that is, aiming at replacing the current wikitext parser with Parsoid – but there seem to be clear benefits from transitioning to Parsoid, although I think it would be fair to state that most experienced contributors wouldn't directly benefit much from the change. I don't think the existence of an agenda in itself is particularly problematic, although I haven't really followed discussions on Parsoid closely.

The point of a wiki, the point of wikitext, is to be understandable and usable by average people who don't want to learn strange and obscure HTML rules.

I don't think it has really succeeded in doing that, even if it's better than HTML. Even aside from the difficulty of learning all of the markup, wikitext still has its own idiosyncrasies, such as the impossibility of nesting <ref> tags without using a parser function. Obviously, the development of VE is primarily a consequence of the perception that wikitext was not sufficiently accessible.


As for what Parsoid actually means for this project, I think the situation may be clearer once the team posts answers to the questions I asked in my second-last comment.

If it were up to me, I might not go as far as to automatically mess with the input to the source editor; extending the linter or adding tracking categories would probably be better for handling markup errors (and might encourage users to fix the errors in the first place). I think following the 2017WTE behaviour would make a lot more sense than following the SD behaviour, but at this early stage both could still be possible.

It's also been suggested to "armour" comments so that unbalanced markup doesn't spill into the rest of the page, which could be possible with a magic word that forces each comment to be parsed separately.

Alsee (talkcontribs)

The 'problem I am talking about' is that the Foundation has been making user-hostile changes to wikitext, and they plan to continue making user-hostile changes. (If "user hostile" is objectionable, you can read it as "less user friendly".)

I very carefully read and re-read your post trying to Identify what arguments you were presenting. It looks like you start with superficial reasons, leading up to what appears to be the main argument. This is what I came up with:

  • You do not appear to dispute that these changes make the wiki less user-friendly.
  • You cite that the original wikitext was not "able to do this perfectly". I hope we can agree that doesn't support making the imperfect-thing worse.
  • You argue "Changing the behaviour now would have the side effect of potentially breaking wikitext that has been written". The Foundation has broken millions of pages, and plans to break millions more. Your argument doesn't support what they're doing, it argues against it.
  • You argue Tidy had to be replaced because it was no longer maintained. That is a circular argument. They deprecated Tidy as a result of their strategy to redefine wikitext.
  • The remainder of your post presents what appears to be the actual argument. You don't quite say it this way.... but it appears you're arguing that we should make wikitext worse because you think people should use Visual Editor instead. It reminds me of something a staff member wrote in an Office Hours meeting about Visual Editor, discussing Visual Editor's abysmal acceptance figures:
[15:06:32] <James_F> So, as you can see, adoption isn't as high as we'd want and we're looking to make VisualEditor better so that more people choose to use it over wikitext.
[15:06:52] <James_F> (The alternative of course would be to make wikitext worse, but that wouldn't be very ethical. ;-))
Reply to "Prototype testing report"