Template talk:Flow under

Back-link of image file can overlap and nullify other nearby links

@AuFCL, first - thanks for adding this; it was something that consistently comes up every-so-often and nobody had a "good" way to get this effect.

But I happen to notice the REFerence linkage on Page:The Pinafore Picture Book.djvu/91 is usurped & unavailable thanks to the "area" taken up by the automatic generation of any image file's link back to its File: namespace main-page when |link= is not present in the mark-up's string.

So, for example, if the the third word in the top line after the image using Flow under was an Author: link piped under a person's name, and I tried to click on it, I would be taken to the image's File: page instead.

At the moment, I'm not sure how to keep the back-link but limit it to the actual image-area rather than the overlapping object-area. Verified? Thoughts? -- George Orwell III (talk) 02:22, 16 February 2014 (UTC)

Oh. Damn. To be completely honest I had not even thought of that consideration, primarily due to the fact I initially mistook the layer "stacking" order (thus the sudden template name change.) Would not have been an issue if the text layer genuinely overlaid the image.

Two approaches come to mind:

1. any thoughts as to how to reverse the layer ordering, and really send the image "to the background" as originally envisaged? (you may have noted my failed experiments using "z-image" styling.)

   I had not observed anything like this template until an hour or two ago so I'd have to dig a bit to check all that..

2. will disabling the native image linkage restore "text layer" links? Experimentation required.

   Adding |link= does disable the image back-link but that is not an option, IMO, per serveral User: requests for restoring the back-links during the FreedImg saga. I don't expect that sentiment has changed any since.

Of course, this should merely be considered notification of proposed trials yet to be executed. AuFCL (talk) 02:56, 16 February 2014 (UTC)

Gotcha. I will search for solutions in the interim & chime in if anything looks promising. -- George Orwell III (talk) 03:10, 16 February 2014 (UTC)

I simply cannot come up with a better solution than your idea of adding <span style"z-index:1;"&/gt; blocks around paragraphs following the {{flow under}}. To make it a little more "socially acceptable" I suggest encapsulating precisely this in (say) {{flow under/text}}? with suitable directions for use incorporated in the main template's documentation. If people use it in the Page: space: well and good. Otherwise at document transclusion time a (perhaps more aware) integrator might apply same or similar to Page:-crossing paragraphs, so maybe a pre-emptive {{flow under/text/s}}/{{flow under/text/e}} set?

Unless anybody has a better approach I'll make a start on this as my time permits. AuFCL (talk) 09:31, 17 February 2014 (UTC)

Basic observations

Setting "link=" on File: reference disables all links; does not transfer right-of-linkage to underlying layer. AuFCL (talk) 03:26, 16 February 2014 (UTC)

This is the "problem" whenever testing in the Page: namespace - too many settings, etc. applied without one realizing it. Setting |link= disables the image back-link just fine but it doesn't free up the total "area" being allocated (max-width & max height wise) to the image. Nearby links aren't technically disabled at all (resizing your browser window until the link in question is no longer under that allocated area allows your pointer to select the nearby link again regardless of the back-link being present or not). I think the issue goes back to the wiki-markup's control over all image files through the File: statement - though in this case I'm not sure trying to accomplish the same using HTML & the IMG tag is possible either.

A possible solution lies in calculating offsets of the image's dimensions as they relate to a particular relative or absolute block (sort of like how the hover-pagelink highlights-content "feature" of dynamic layouts calculates nearly the same but using text content rather than image dimensions) and then go from there. That type of intricate "offset scripting" is something I've only seen done by @Eliyak: in our MediaWiki:PageNumbers.js file.

Otherwise, the z-index approach seems like our only hope here -- George Orwell III (talk) 04:15, 16 February 2014 (UTC)

Yup, the z-index is the solution (see the changes to Page:The Pinafore Picture Book.djvu/91 that restored access to the REF link). I just don't know how we're going to "templatize" something like that to avoid having to inline-style every element sharing the page near the image. -- George Orwell III (talk) 04:55, 16 February 2014 (UTC)

Just a ponder: if there are z-index values on a page, is there a default value for the other elements? Beeswaxcandle (talk) 05:10, 16 February 2014 (UTC)

Don't believe there is but I've never been a big fan of applying z-index routines so I'll have to double-check all that. This still might not be "workable" without some serious numbering getting involved - what happens when multiple images are positioned like that in a range of Page:s being transcluded into the final [single] mainspace page? The chances for duplication of numbered "levels" seems likely. -- George Orwell III (talk) 05:27, 16 February 2014 (UTC)

Just done a quick explore myself. The default value is "auto", which means the sequence found in the HTML (unhelpful). What happens if the image is forced to have a negative integer value through the template and the text chunk(s) to have ascending positive values? w3.org says that negative values are stacked below their parent and positive values are stacked above. Beeswaxcandle (talk) 06:27, 16 February 2014 (UTC)

True but using negatives was always considered a "poor practice" the best I recall. Besides that is not really the issue; in order for the text "surrounding" or "nearby" (i.e. before &/or after) the image to recognize the z-index given to degrade the image, so too must that text have a z-index assigned as well (& the only way that works is if a absolute or relative position is present for that text at the same time). I can't think of a way to pull of the results for both at once without it becoming a christmas tree of inline styling for every "nearby" element.

Again, it all goes back to the issue with the wiki-markup using File: instead of IMG tags....-- George Orwell III (talk) 07:15, 16 February 2014 (UTC)

Re: 'but using negatives was always considered a "poor practice"': I looked into this a little and found (guess!) it relates to another IE v the others fight. IE 6 & 7 apparently considered it entirely valid (source mentions nothing more recent); however most other browsers interpret it as a request to position the element behind the body (which the article claims carries default z-index:0.)

(My interpretation of [1]) AuFCL (talk) 22:58, 16 February 2014 (UTC)

• Applying inline styles to SPAN File:SomePic.png /SPAN and thinking that will affect the output is misleading because in reality what we have going on there is...
• SPAN A IMG/ /A /SPAN ; iow, the A and IMG tags never accept/inherit any settings set in the opening SPAN regardless of being subject to the wiki-code in this case or not (basically because they are inline elements just like SPAN is).

The containing block element (P or DIV) needs to be manipulated in order for settings settings to flow "down-hill" (from P to SPAN across A and finally to IMG). This is the same nuance FreedImg manages to accomplish with the height & width attributes of an image file. So far, I can't think of a way to get the same for positioning & index level. :( -- George Orwell III (talk) 07:15, 16 February 2014 (UTC)

Alternate approaches (craziness a possibility)

Apologies I had to drop out for a while. Medical panic, ruptured appendix (obviously not mine.)

Here is a thought. I don't have the skills to necessarily put the pieces together (yet), but what do you think of:

• (aside/background) offline experimentation with the HTLM reveals adding style "visibility:hidden" to the "position:absolute" tagged spansimultaneously kills the enclosed image and restores underlying link access (coincidentally this is the same span George has tagged with "class=flowUnder"...may be handy later)
• what are the chances a "mouseover" (hover, whatever) event might be registered as a javascript hook to set "visibility:hidden" on the span, and restore it to ":visible" when the mouse pointer moves on?

Crude of course; but should not be too hard to implement, if MW doesn't vet the CSS too closely? AuFCL (talk) 11:04, 16 February 2014 (UTC)

---

This isn't particularly clean (or nice), but a pure CSS approach of removing any forced style="z-index:???;" from the position:absolute span in the template, and replacing it with class="flowUnder", in conjunction with common.css line "span.flowUnder:hover { z-index: -1; }" pretty much works. Not final, but suggestive? AuFCL (talk) 13:55, 16 February 2014 (UTC)

Is there any reason the text should not fall *over* the image (aside from the template name)? It seems that would be of more general benefit in any case. This whole thing reminds me of what I done over here. In that case, additional issues were the drop-initial and that the text from the next page should begin within the indent (these are probably fairly common issues, though). --Eliyak T·C 09:00, 18 February 2014 (UTC)

@Eliyak: You are of course quite right, and text-overlaid-on-image was always the preferred way—I simply could not figure out how to do it.

Looking at the "Adjustment Team" page(s) I can see there is a lot of cleverness going on, but I simply cannot get a grip on some aspects. For example, the nested position:absolute divs (within a :relative one) obviously achieve a centred :absolute container for the image, but what is the effect of the margin:auto on the innermost div? And I cannot figure out what the &zwnj; is contributing—does it somehow link the heart of the div nesting with the later span content? Or are these both related to support for some other browser? I shall try to think on this further, but as you may have realised, right at present I am a bit "all at sea"! AuFCL (talk) 23:40, 18 February 2014 (UTC)

O.K. I am a bit better acquainted with some aspects of the (Adjustment Team) page now, and stripped of the extra issues of centring the image, handling the drop capital and the use of divs rather than spans it really is no different to George's solution above. If you really want to be picky about the laying order, it really at heart flows text under the image in exactly the same fashion (fault?) as {{flow under}}, and it is primarily the "position:relative" styling of the span which recovers the situation. In some respects "z-index:2" doesn't add a lot to that. Unless I've missed something fundamental (and I almost certainly have!) I really think GOIII's answer still stands.

Thank you again for pointing out this rather interesting example. AuFCL (talk) 06:17, 19 February 2014 (UTC)