This is incredibly annoying; even Wikipedians most critical about VE have always admitted that it is a good way to work with tables. Now not even that works anymore, it's so frustrating! At the moment apparently I have no way to copy and paste table columns.

So I created this testing environment, using only the tooltip-related styles: http://danu-talis.bplaced.net/tooltip-test.html (first with the styles I use on testwiki, then with the ones I use on German WP). You are right, it behaves exactly like it does in MediaWiki environment. Btw, I also found out that when using Firefox on iOS, the sticky tooltips problem is resolved, but the caption still jumps.

In T212610#4845272, @matmarex wrote:

I don't know, but I would guess that these sites have implemented something that makes it work, either intentionally or accidentally. Maybe they have a global click event handler for some reason, making everything "clickable", or maybe they override something about scrolling that accidentally changes what tapping does.
If you want to prove it's a MediaWiki problem, please create a small stand-alone .html file that implements the same feature and does not have the problems.

Thanks for looking into it! Well, if it is a general iOS problem, why doesn’t it happen on the external website and why only in WP desktop version and not in mobile version? Otherwise I wouldn’t have asked it here. And the caption jumping is definitely not a Safari bug, since it also happens in Chrome; furthermore, I would expect to find trace of such a bug on some other support/discussion site if it were a general one (probably captions are not that often used, but still). So I’m not convinced that there is nothing to do on the side of MediaWiki.

On iOS usually with Safari, but I also tried Chrome (same behaviour).

Well, as described above, the exact same HTML/CSS apparently works fine on the external website I have linked, the problems are only visible in MediaWiki (I have tested German WP and Testwiki). I can also try it on my personal website, if further testing is required, but the different behaviour on the website that presents the code explicitly as a generally applicable demo seems proof enough to me.

Is anything happening here? I have made a lot of unnecessary template edits already because of the lack of a preview function. If it is not introduced, I guess template pages should either use the CodeEditor or the old wikitext mode per default , otherwise template editing will never properly work.

Ah, I see. My earlier suggestion for a fix was indeed to leave the first line with the {| inside the template and create only the following parts through Lua. But apparently the <div>\n{| solves the problem! Thus I suppose that infoboxes should always be wrapped in a div to avoid such a behaviour.

I will look into this. But if it is not a Lua problem, what other change to the template could have been relevant for changing the behaviour? If you compare this article with the original template and the corresponding German article with the new Lua template, the difference is visible.

Yes, the problem is gone! :) Thanks to whoever solved it!

Oh no, seems like I overlooked something last night. :| The bug is still here, just reproduced it again. However I'd be glad if someone else could reproduce as well, otherwise I get the feeling I'm doing something wrong here, and I have no idea what that could be ...

Okay, it seems to be resolved, I can't reproduce it anymore!

I think this is related to T52407, about the larger need of a way to specify dependencies between parameters. There is indeed a lot of work still to be done in order to make sure that TemplateStyles can deal with any kind of templates. However, I doubt that “low priority” will ever get us there …

According to this help page, Templates are supposed to have subpages just like user or project pages. And indeed I also never noticed any different software treatment until recently with TemplateStyles.

Indeed, meanwhile articles mainly edited with VE are flooded with auto generated weblinks disguised as “cite book”, which will then also further spread with copy&paste by inexperienced users.

I hoped that resolving T185184 would fix this as well. But I can still reproduce the invisible wikitext parts at the beginning of any article that start with a template (infoboxes, usually). Just encountered another interesting case: initially, there were two different infoboxes at the beginning of the article, which I both deleted (by selecting single parts of them and overwriting the wikitext; it was this article: https://de.wikipedia.org/wiki/Zero_Assoluto). Then I used the backwards function of the editor, which eventually only brought back the first infobox. When using the preview, though, the other infobox was still there. Trying to reproduce it later, I managed to get various combinations of chaotic template wikitext, like

Okay, did some testing: I can always reproduce the problem in Firefox and Chrome, while in Edge it works fine (all browsers are updated to the latest version). Whether I am logged in or not does not matter; any time I paste a chunk of text (no difference between VE and NWE), there is an invisible character at the end of the line, which I can only get rid off by deleting it explicitly or by saving the page. OS is Win10, also latest version.

This sounds a lot like T171616 to me! There it has nothing to do with syntax highlighting, though. In any case I can still reproduce my problems, although I fortunately did not have another crash.

Yes, substituting within refs won't work if this bug is not resolved!

I am also thinking of templates with an unlimited number of unnamed parameters, which are not handled well in VE currently.

At least in German Wikipedia, the number of wrongly used cite book templates for websites is increasing quickly, as new users apparently just leave the formatting of the reference to VE. This produces a completely unnecessary workload when correcting the templates subsequently and also means that you will have to fill in everything manually if you want to have it correctly from the start. It’s definitely not of low priority!

Just encountered the problem again in a different setting (and with less severe consequences)!

To give a short summary of my usual steps (described in detail in German): it always happens when I want to delete an infobox at the beginning of an article which contains a photo. The moment I try to use the file name in a normal file embedding without the infobox code, the font changes and different problems can arise (there are some variations): sometimes the editor is completely blocked, one time making it even impossible to save (after a lot of editing in the article); sometimes it is not possible to write in some paragraphs (in those moments the Chrome console always warned about "Uncaught TypeError: Cannot read property 'getStore' of null" and similar); usually if I try to copy-paste some part of the source, I will not get back the part I have previously selected (mostly the code at the beginning of the article that I had previously deleted will always reappear somewhere). Looks like some deleted parts instead of vanishing are somehow hidden under other parts of the text.

I could reproduce it with Chromium as well, it’s apparently not limited to Firefox!

I noticed the problem today for the first time on my PC (Chromium), before I had experienced it only on the tablet. It happened with a user page on de.wiki that derived from meta, a similar case as the above mentioned.

Anything going on? It's high time that typography is corrected automatically; I don't get how you can classify this as lowest priority!

Well, I have another case: In German Wikipedia we have Template:Charteintrag, where not only such dependencies are required (eg if “POS_xy” then also “WO_xy”), but even the parameter names depend heavily on earlier added parameters. If I enter 1=x and 2=y, the possible parameters following are POS_x (with WO_x) and POS_y (with WO_y), but of course not eg POS_z! At the moment TemplateData is totally useless with this template, I fear.