Last modified: 2014-02-28 23:03:47 UTC
Created attachment 12748 [details] MS Word document describing and illustrating the bug See attached document. O/S is iOS 6.1.3
This looks like a CE-munging-absolutely-positioned-CSS bug.
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
For an example of a similar but not identical problem see the map in [[Loyalsock State Forest]]
Also does nasty things to railway line diagrams - see [[South Maitland Railway]].
Created attachment 12941 [details] VE display of a railway line in Chrome 22 on Win7
Created attachment 12942 [details] Map of Loyalsock State Forest in VE on Chrome 22 Win7
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.
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.
(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)
