@Sneha wondering about your take on this - I think these were all intentional design choices? For the first two, I think that Quickview is supposed to overlay anything in that right column, and for the last one, I believe the arrow should only display on hover of the snippet (and the gray background is a local override on ptwiki).

In T326383#8505327, @CBogen wrote:

@Sneha wondering about your take on this - I think these were all intentional design choices? For the first two, I think that Quickview is supposed to overlay anything in that right column, and for the last one, I believe the arrow should only display on hover of the snippet (and the gray background is a local override on ptwiki).

Yes, the behavior is according to the specs, however there are some fine points. After @Sneha's review, if there are not follow ups, the ticket may be closed (it's FYI ticket, not a bug report).

My reasons for filing this task

• the QuickView on Special:Search blocks some other elements on the page. It'd be good to evaluate the impact on users' experience.
• the hover up area is restricted only to articles' snippets - on ptwiki it seems non-intuitive due to the presence of the background color.

#1a For quick view overlapping existing content on the right hand side: Our solution was to reduce the opacity. We did not anticipate those external search links to be there. Ideally they should be grayed out when quick view is open but since not all wikis have it, this may be a minor thing to do and nice to have.

#1b For quick view overlapping the wikidata content: Currently the quick view changes its height so that it does not overlap the footer. @matthiasmullie made that change. Now I wonder if this wikidata content be treated the same as footer or not. @matthiasmullie ?

#2 The hover area for the arrow is documented in the screenshot in this ticket T310281. It should include the area were arrow is and the metadata as well.

I have filed a bug for issue #2 here T326580 so we can change this ticket to be more more focused on overlapping content.

#1b For quick view overlapping the wikidata content: Currently the quick view changes its height so that it does not overlap the footer. @matthiasmullie made that change. Now I wonder if this wikidata content be treated the same as footer or not.?

I did some quick investigation and noticed that achieving the same result that Matthias achieved with the footer is going to be more complicated in this instance. The wikidata sections is PART of the search result and this makes the work a little harder. (completely the same as the interwiki shown in the other wikis).

There are two technical solutions for this problem:

• We actually change the design of the wikidata section and any other section that we know could be shown in that section of the page to be align with the rest of the page (50em width)
• We change to hardcode the section and dynamically set the height of the search vue. This is not only expensive and fragile (as another section with a different name would still break), but also a solution that may result in edge cases in the future (due to its fragility).

Matthias knowledge on this subject may actually help us further as the above comment are coming from a small research and I may be missing some important context.

Change 878108 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/extensions/SearchVue@master] Make quickview height relative to search container

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

Those wikidata results (.wdsearch_container) are not part of the search results container (.searchresults, the one where the min-height is set), so in this specific case, it's fairly easy to change & also make sure we don't overlap with that one (see above patch)

That said, we may not always get so lucky; other wikis may have other scripts and enhancements that might not be as easy to work around.

So as I understand correctly if anything is part of search results container it would tend to follow the 50em width in that case we won't have to worry about overlap.
With this case of wiki data we are able to use the same solution as avoiding overlap on footer. Is that correct?
And yeah understood that we may not always be able to fix this for all cases.

@matthiasmullie should this be moved to code review, or @Sneha is there more to this ticket that isn't covered by @matthiasmullie's patch?

Yes if it fixes the overlap issue we can move it to code review.

In T326383#8514354, @Sneha wrote:

So as I understand correctly if anything is part of search results container it would tend to follow the 50em width in that case we won't have to worry about overlap.

Stuff within the search results container should be safe and always remain visible (although it's possible to break out of those boundaries or change them with custom CSS)
Note: the search container is not 50em, but 7/12 or 8/12, depending on width of the screen.

With this case of wiki data we are able to use the same solution as avoiding overlap on footer. Is that correct?

Yes; instead of using the page content container as reference for where to extend quickview to, we'll use the search results container instead (which is a subset of the page content).
That wikidata content is part of the former, but not the latter. After the patch-in-review, quickview will no longer extend that far down.

Change 878108 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Make quickview height relative to search container

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