Notes from @Mooeypoo: "This is a problem with rendering templates on top of templates on wikis, and there's very little we can do as a generalized solution, since the bugs are not generalized themselves. Case in point -- if you edit this example article in VisualEditor, you'll see the same problem; hovering over the bottom template shows the "overlay" as over the image itself.

We can't really fix this, unfortunately, it's a deeper issue with the way that templates are rendered on wikis."

I discussed this bug with @Prtksxna today. We discussed the fact that, from what Moriel has shared, there's nothing we can do to change the opacity bug. This means that we have 3 main options:

• Option 1: Leave the opacity implementation with the bug
• Option 2: Remove opacity implementation and don't replace it with anything else
• Option 3: Remove opacity bug and replace it with something else (such as CSS filters)

Prateek said he prefers Option 2 or Option 3 (his first choice). This way, we don't remove the differentiation between interactive and non-interactive parts of the page, so users can have a better understanding of how WWT works.

As for me, personally, I think this depends on how often the bug occurs. If it's very rare, I may be fine with Option 2. I also agree that Option 3 is the best choice, if it's a relatively easy fix.

For the MVP or first version of the feature, it may be fine to leave the opacity implementation in its current form, depending on how often the bug occurs (and replace it later). We'll discuss it in Estimation today.

Just a quick comment here: css filters also have their own css stack context, so they won't help :(

I looked into alternatives when I investigated this for [T235130#5726670]

See https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context

After a brief chat in RL, I suggested this to @ifried :

Since #3 is not viable (filter creates the same context stack issue), I propose that the bug would be less pronounced if we flip the behavior of the opacity: We load the page with all elements 100% visible (no opacity) and have an opacity 50% when the element is hovered-on. This will still change in stack *when it is hovered on*, which means that a line might still be visible -- but that would only happen when the user is literally on top of that element, which makes it clearer to get the context of what "box" just dimmed for the user (looks less like a bug, and is more similar to what VE is doing). It will also mean that no element is changing its stack unless you are purposefully on top of it which prevents "double" transparency issues.

@Mooeypoo, I like your suggestion of keeping the effect the same but showing it only on hover. This will still tell the user if something isn't interact-able, even if it is after they've hovered on it.

I wonder, how often will we see this issue. If this kind of overlap is common on pages, then I think we should go with what Moriel is saying. If not, I'd prefer that un-interact-able elements are always faded out even if they cause this weird bug in some cases.

@ifried just told me this bug happens quite often, so, let's go with Moriel's suggestion :)

PR: https://github.com/wikimedia/WhoWroteThat/pull/127

We still have the "problem" of the lighter line crossing the infobox, but now it only happens when you hover over the specific template, which (at least in my opinion) gives the user some sense of what it's attached to as a box on the screen.

In order to make sure that this line only appears on hover (and not anywhere else) I've removed the 0.8 opacity that we had before on hover, and now the disabled elements are fully opaque until hovered -- then they're 0.5 opacity -- which is the acceptance criteria.

In T240262#5770063, @Mooeypoo wrote:

PR: https://github.com/wikimedia/WhoWroteThat/pull/127

We still have the "problem" of the lighter line crossing the infobox, but now it only happens when you hover over the specific template, which (at least in my opinion) gives the user some sense of what it's attached to as a box on the screen.

Looks something like this, when you hover over an overlapping element:

In order to make sure that this line only appears on hover (and not anywhere else) I've removed the 0.8 opacity that we had before on hover, and now the disabled elements are fully opaque until hovered -- then they're 0.5 opacity -- which is the acceptance criteria.

I tested this briefly and this seems accurate. I did not test very thoroughly because it is a very small CSS change (famous last words...)

Tested on commit 53ec5da8fba6e18018f49f5644de8265c6c0316b, which is the latest as of 8th Jan. This change is not on the Chrome Store/Firefox Addons.