Wikimedia Developer Support

Is there any established practice about using or not using `position: sticky` css in official MediaWiki (MediaViewer in this case)?

I’m fixing the bug : MediaViewer - after closing, browser sometimes scrolls to the top of the page. (I’ve separated scrolling the overlay lightbox from scrolling the page.)

The cleanest solution to properly position the elements is to use position: sticky. has ca. 75% support for unprefixed use.

The alternative is a more complex setup with absolute positioning, margin-trickery or top: calculation in js and some issue with handling scroll events.

Which one is the canonical way?

Im not sure if this is still accurate but might help with what level of support features should ideally have.

1 Like

You can also search for existing uses of position: sticky on Wikimedia CodeSearch. (I also suggested using position: sticky for Wikidata a while ago, but with no conclusion on whether that would already be acceptable or not.)

1 Like

Fixing the JS logic that attempts to restore the scroll position would probably be a lot simpler than redesigning the layout.

Fixing the JS logic that attempts to restore the scroll position would probably be a lot simpler than redesigning the layout.

I wouldn’t call it a redesign, but both the JS and CSS required fundamental - albeit not structural - changes: changing the scrolled element had some unexpected consequences that required rethinking the CSS. The working solution was the result of a few half-days of trial and error and debugging.

Btw, fixing the bug is not dependent on sticky positioning: that would be a modernization and cleanup step only.

Regarding the question of using position: sticky:

I’ve opted to use it, with a fallback of position: static for Internet Explorer. It seems all other modern browsers support it. To find the best solution I had to try quite a few. There were many unexpected behaviours that I’ll summarize below.

position:static might be a surprising fallback for sticky. The reason for that choice is that position: absolute and fixed would remove the element from the document flow, changing the location of the following element, which containing the image data. The static positioning is a very minor inconvenience in a browser used by almost nobody, while still 100% functional. Acceptable compromise for me.

Absolute positioning is not usable as the parent element is scrolled.

I’ve also done the layout with position: fixed, that’s compatible with all browsers. This solution had many complications: the pointer (mouse) events were consumed, making it impossible to use mouse scroll to open and close the image metadatabar. I could circumvent this with pointer-events: none;", however then the image could not be clicked to zoom in, the occasional horizontal scrollbar would be unclickable, the individual buttons and popups needed pointer-events: all;` to capture mouse events, not to say that scrolling did not work over those. Fixed position was the least satisfactory.

The issues with fixed positioning were the most unexpected and troublesome. Sticky works the best in many regards.