Page MenuHomePhabricator

ContentTranslation "Contributions" menu overlaps awkwardly with Vector search suggestions
Closed, ResolvedPublic

Description

As reported elsewhere:

Found one more glitch: cirrus search is incompatible with content translation contributions menu. Try to search something, and when the autocomplete opens, hover on contributions link.

image.png (980×1 px, 479 KB)

This is not related to T182602, as neither of these actually use OOUI at all.

Looks like you just need to increase the z-index for your dropdown (search suggestions have z-index: 1099; for some reason).

Event Timeline

Looks like you just need to increase the z-index

It feels to me we are currently having an uncontrolled race to the top. Is it reasonable to ask for project wide guidelines to make things predictable?

Ideally, we would do that (or rather we would have done that 10 years ago), but I think creating new guidelines now and changing all of the existing z-indexes to match them is likely to break a lot of things.

I don't think the funny-looking values are a problem, not until they're like nine digits long ;)

Change 401483 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/ContentTranslation@master] ext.cx.callout: Increase z-index

https://gerrit.wikimedia.org/r/401483

Ideally, we would do that (or rather we would have done that 10 years ago), but I think creating new guidelines now and changing all of the existing z-indexes to match them is likely to break a lot of things.

It amazes me that we don't have z-index policy since long time ago, because just trying to beat random-looking values per-case (like this) looks unprofessional.

I don't think the funny-looking values are a problem, not until they're like nine digits long ;)

I think everything above single digit value is uncontrolled and causes unstructured and messy code that we have.

Ideally, we would do that (or rather we would have done that 10 years ago), but I think creating new guidelines now and changing all of the existing z-indexes to match them is likely to break a lot of things.

I don't think the funny-looking values are a problem, not until they're like nine digits long ;)

Maybe, we should create a catalog - all possible values in wiki, and if possible, in extensions. So somebody that needs a new value, could check if there will be no problems.

Ideally, we would do that (or rather we would have done that 10 years ago), but I think creating new guidelines now and changing all of the existing z-indexes to match them is likely to break a lot of things.

It amazes me that we don't have z-index policy since long time ago, because just trying to beat random-looking values per-case (like this) looks unprofessional.

I agree this is bad, but in my opinion it is very low priority tech debt. If it bothers you, then feel free to be the change you want to see in the world ;)

I don't think the funny-looking values are a problem, not until they're like nine digits long ;)

I think everything above single digit value is uncontrolled and causes unstructured and messy code that we have.

I would actually recommend using a bit bigger values and keeping some gaps between them, to make it possible to add new things "between" existing things, if that ever becomes necessary (without changing a dozen extensions to bump z-index values by 1).

Here is another overlap issue to check when solving the problem:

another-callout-overlap-issue.png (155×559 px, 9 KB)

Change 401483 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] ext.cx.callout: Increase z-index

https://gerrit.wikimedia.org/r/401483

matmarex claimed this task.