Hi all, I'm an admin on the English Wikipedia. I originally posted this here with no response. VisualEditor is stripping whitespace from Infoboxes, which is largely problematic because many people opt to organize infoboxes by lining up parameters. Note the sample infobox at Template:Infobox film. Can someone please turn this off as it is disruptive? Visual Editor is basically deciding that editors' formatting choices are invalid. This seems like it must've been a recent change, I think, as I'm seeing it more frequently in the last few days. Some examples here and here and here. Thanks, Cyphoidbomb (talk) 06:42, 29 October 2017 (UTC)
Topic on VisualEditor/Feedback
Similar problems on the french-language side since the last 2 weeks. Annoyances:
- When a field is using comments, the next parameter is bumped a line above, after the comment, like this:
<!-- commentaire --> | paramètre = (something)
- When a field uses the * for a list, the first item is also bumped a line above.
These annoyances are invisible to the visitor, but old-school "source" contributors prefer a clean workspace.
Having gotten no response to this here, I opened a ticket here. Regards, Cyphoidbomb (talk) 22:08, 29 October 2017 (UTC)
@Cyphoidbomb, @InMontreal, have you seen the page linked above by the IP? You need to tell TemplateData how you want the template to be. I think the one at en.wp is the simplest explanation available.
This post was hidden by Elitre (WMF) (history)
Forgive me if I'm wrong in my interpretation, but it sounds like you're suggesting the solution is to add some instruction at the template level for how Visual Editor treats the formatting.
But template formatting varies from article to article, so these are local consensus issues. (Consensus through editing, not necessarily through discussion.) If I create an article, I might prefer the extra whitespace, but another editor may not in an article they create. The extra whitespace isn't harmful, nor does it contravene any guidelines that I'm aware of, so it should not be removed without discussion.
Not sure what to do from here. Cyphoidbomb (talk) 14:04, 30 October 2017 (UTC)
Another example: here.
Hmm, the summary on top should have made it clear that this is an editor problem. This is a lot like blaming a gun manufacturer because someone used a gun to shoot themselves on the foot. Indeed, for the last linked page, it seems that someone unilaterally went and changed single spacing to multiple spacing in the documentation page. A previous discussion on its talk page seems to have had no agreement.
In general, any discussion on whitespaces is completely misplaced and a waste of time (see https://joshondesign.com/2014/09/02/bar). There are dozens if not thousands of blogs or discussions about spacing one should use for programming that have gone for years which are just as applicable to wikitext whether people like to believe it or not. In fact one developer seems to have predicted that this would happen (https://phabricator.wikimedia.org/T64217#1650279).
The bottom line is that it doesn't matter even one tiny bit. There will never be 100% consensus about the exact spacing even for wikitext or programming code because humans are complicated creatures. There will just be a group forcing another group to do it their way because "they like it".
The right approach here consistency. A reasonable solution is to develop a javascript tool that can show the spacing as preferred, with something like Extension:CodeMirror, Extension:CodeEditor, and so forth.
That way each user can see whatever they prefer without inconveniencing others. But humans being the complicated creatures they are will simply continue arguing over this.
Good luck with the star (space) wars.
Again, the point seems to keep slipping by everyone: This is a local consensus issue, and each article may have an established preference for how the table is formatted, but Visual Editor is by default removing all whitespace, and non-technical-types such as I have no idea how this can be abated on a local level.
@Cyphoidbomb actually, that's not really slipping by. It's just that such editor assumptions are misinformed. I mean on Mac OS X for the longest time, any spacing you indicate was useless anyway, as OS X didn't use a true monospace font, so what you see as aligned, was seen by others as non-aligned.. And even now that this is more consistent, EVERY SINGLE PERSON can choose a different font on his own accord.
So as annoying as the changes might be (and i'm positive people won't stop complaining, because they are set in their ways).... at the same time, editors really need to make fewer assumptions about how things look. This is the web, not bookprint, the web has NEVER been able to guarantee that things look the same for two different people. That was part of its strength, the flexibility guaranteed that everyone could participate, instead of forcing everyone into a straitjacket.
The local consensus is based on a fallacy.
DJ, I don't understand this tangential thread. Though I do notice at Phabricator you seem to get my basic complaint:
Developers: Please stop using Visual Editor as though it were AWB to needlessly "fix" things that aren't actually broken.
Per MOS:VAR: "On some questions of style, the MoS proposes more than one acceptable answer; on other questions it gives no guidance. The Arbitration Committee has ruled that editors should not change an article from one styling to another without 'substantial reason'"
No substantial reason has been put forth for why skill-less editors are being used as botfarms to obliviously make silent, bold formatting changes that may contravene local consensus or the status quo. Thus, I argue, Visual Editor should stop messing with stuff.
As a purely practical matter, the formatting options for an infobox are:
- always accept the default formatting, or
- define how that template should always vary from the default, using the codes at Help:TemplateData#Custom_formats
It may help to think of it this way: When someone edits a template, the original version is removed, and the updated version is inserted as if the original never existed. The software can't think of it as a few characters here or there, in a sea of text that will be turned into something meaningful only after you save your changes; it has to think about the template as a whole, and it has to produce meaning from it when you click the "Apply changes" button on the template dialog. So if someone edits the template at all, the whole thing becomes "new", and that means that the whole thing gets re-written from scratch. There really isn't any practical way around this.