This looks like a CE-munging-absolutely-positioned-CSS bug.

lunarjam.mcgahan wrote:

This bug also occurs in Chrome Version 27.0.1453.116 m on Windows 7.

Problem confirmed on Firefox and Chrome, and can be seen at

https://en.wikipedia.org/wiki/Macumba_Station?veaction=edit

And most other pages (lots and lots) that use

https://en.wikipedia.org/wiki/Template:Location_map

also confirmed for uses of the German template, so I am guessing most other wikis will have the same problem

https://de.wikipedia.org/wiki/Vorlage:Positionskarte

https://en.wikipedia.org/wiki/Azincourt?veaction=edit
https://de.wikipedia.org/wiki/Albany_%28New_York%29?veaction=edit

I cant find another bug that mentions location maps.

It also appears in other cases, such as this circle which should be over right-most persons face.
https://de.wikipedia.org/wiki/Selbstbildnis_%28Leonardo_da_Vinci%29?veaction=edit

Another fairly large set of 'CE-munging-absolutely-positioned-CSS bug'. Is there an open bug for that?

https://en.wikipedia.org/wiki/Template:Football_kit

lunarjam.mcgahan wrote:

For an example of a similar but not identical problem see the map in [[Loyalsock State Forest]]

lunarjam.mcgahan wrote:

Also does nasty things to railway line diagrams - see [[South Maitland Railway]].

lunarjam.mcgahan wrote:

VE display of a railway line in Chrome 22 on Win7

Attached:

lunarjam.mcgahan wrote:

Map of Loyalsock State Forest in VE on Chrome 22 Win7

Attached:

Probably a separate problem, which may already be filed in buzila, but here are a few railway templates that have extreme layout issues.
https://en.wikipedia.org/w/index.php?title=Ontario_Northland_Railway&veaction=edit
https://en.wikipedia.org/w/index.php?title=Brunswick%E2%80%93Magdeburg_railway&veaction=edit
https://en.wikipedia.org/w/index.php?title=East_Lancashire_Railway&veaction=edit
https://en.wikipedia.org/w/index.php?title=Channel_Tunnel&veaction=edit
https://en.wikipedia.org/w/index.php?title=Ravenglass_and_Eskdale_Railway&veaction=edit

For Location map, this is caused solely by:

.ve-ce-protectedNode, .ve-ce-protectedNode * {
position: relative !important;
top: 0 !important;
left: 0 !important;
bottom: 0 !important;
right: 0 !important;
}

Disabling it returns both the markers and the coordinates back to their original position. However, that also makes all content outside of the main box (you can click title coordinates that are generated by an info box).

Conclusion, this was probably done to counter the effects of absolute positioned elements and causes 'fallout' for relative positioned elements. One way to fix this is with a bit of JS.

var elements = $(".ve-ce-protectedNode").filter(function() {

if( $(this).css("position") === "absolute" ) {
      $(this).addClass("evilabsoluteitems");
}

});

And then assign the above css only to those elements. This is probably a rather 'expensive' operation. Ideally, we would just get rid of absolute positioned elements (.topicon, coordinates, FA/GA etc icons), but that's probably going to be near impossible. A third option might be to add a classname to all these elements that VE can recognize and then apply this styling to it.

The question of the railway template seems more complex. I have a suspicion that there is actually a coding error in those templates, since I see problems with columns/rows counts on those pages. That would also explain why they take long to render in parsoid, it likely makes it complex to render the pages.

By investigating the railway template problem, I think I identified 3 Parsoid bugs that were contributing to those problems on those pages. Most important is bug 57258. The others were bug 57251 and bug 57252.

These are very distinct issues from the location map issue.

Wikifram wrote:

The DJ, thanks for your response, but I fear that it is again symptomatic of the incorrect view you and other devs seem to have. VisualEditor is ''not'' the goal, it is a means to make editing easier. Comments like "Ideally, we would just get rid of absolute positioned elements (.topicon, coordinates, FA/GA etc icons), but that's probably going to be near impossible." are so wrong that I feel it may be hard to explain to you what is the problem with it. There is absolutely ''nothing'' ideal about getting rid of these elements, they are a very useful aspect of maps and other position-defined elements. If VE can't handle these, then VE has to change or an alternative method that can be used in view mode and VE mode needs to be found. But "VE can't handle this, so we should get rid of these elements"? No, that's the opposite mindset of what we actually need.

As for "nor is it extremely visible to the uninitiated.", have you looked at pages like [[:en:FC Barcelona]] or [[:en:ant]]? I think most of the "uninitiated" would notice some differences in the display between [[:fr:Azincourt]] and [https://fr.wikipedia.org/wiki/Azincourt?veaction=edit this] (cause this bug happens on all wikis, not just here...)

This bug happens on about 1 in 5 pages. I don't see how this can be both "low" and "minor" in importance, either one should be a lot higher (a minor aspect that affects an awful lot of pages on all wiki versions is a lot more important than a minor aspect that only affects a few hundred pages, obviously). On a fair number of pages (e.g. the football kit ones, 25000 on enwiki alone, but also e.g. [https://fi.wikipedia.org/wiki/Paris_Saint-Germain?veaction=edit here]), this bug (assuming it is the same one) is very pronounced, so not so minor anyway.

are so wrong that I feel it may be hard to explain to you what is the problem with it.

I think you assumed that I meant the elements/templates themselves. You assumed incorrect. I meant the technology of absolute positioning that is use by these templates and replace them with something more sustainable. They currently also break in mobile and are very sensitive to skin changes for instance. The technique used to place them is problematic (and has been known to be problematic for many years, it's part of why I consolidated those hacks into https://en.wikipedia.org/wiki/Template%3ATop_icon, so that we could replace them at some point). The same technique has also been used for several spam attacks on the wiki.

And i'm slightly offended by your attack on me as a person. A volunteer who probably spends more time on en.wp than doing development.

Wikifram wrote:

(In reply to comment #14)

And i'm slightly offended by your attack on me as a person. A volunteer who
probably spends more time on en.wp than doing development.

I haven't attacked you as a person, for all I know you may be a wonderful person. I have attacked your comment as a developer here, and what I see as the mindset of many developers here when working as a developer.

(In reply to comment #14)

are so wrong that I feel it may be hard to explain to you what is the problem with it.

I think you assumed that I meant the elements/templates themselves. You
assumed
incorrect.

I didn't "assume" anything, I read what you wrote: "Ideally, we would
just get rid of absolute positioned elements". Usually, when people write "get rid of elements", they mean "the elements themselves", not "keep the elements but get rid of the technology used". Don't blame your errors on others please. I have no problem with someone correcting his position or retracting earlier statements, and I'm not the type to claim for all eternity that you want to get rid of these elements if you clarify that that was not what you intended; but then just state that what you said was not what you meant, not that the problem lies with the reader who "assumed" something incorrectly.

Yes, exactly, the elements themselves. The HTML DOM elements. Not the pretty picture that translates into, nor the ugly wikicode language that generates them.

Link to a few other templates that run into trouble due to this problem.

https://en.wikipedia.org/wiki/Template:Chess_diagram
https://en.wikipedia.org/wiki/Template:Quote_box (with curly quotes option on)

In T52714#589573, @TheDJ wrote:

the technology of absolute positioning that is use by these templates and replace them with something more sustainable.

Split to T120809