Olga: possible blocker for wikidata so we might want to reach out to WMDE to get this prioritized.

If I remove Vector 2022’s limitations on the page container’s width in dev tools, then the sitelinks move to the side again:

(Edit: In the screenshot, I disabled the padding as well as the max-width, but it turns out disabling the max-width is enough on its own, you can leave the padding as it is.)

Is the restriction on the page width relevant for Wikidata? I thought it was aimed at large amounts of prose, like Wikipedia articles. Could it just be turned off by default?

In T316797#8378718, @Lucas_Werkmeister_WMDE wrote:

If I remove Vector 2022’s limitations on the page container’s width in dev tools, then the sitelinks move to the side again.

Unfortunately, simply removing the max-width of .mw-page-container would cause the content of entity pages to overflow their margins, and make them become excessively wide. Further adjustments would be needed. Here's a screenshot with an exaggerated width (>1800px) so the effect is easier to perceive:

I would try to find a more localized and scalable solution, probably related to adjusting min-widths and breakpoints. I'm currently working on a design proposal: it'd be great to get help to validate its feasibility 🙏🏻

In T316797#10394206, @Arian_Bozorg wrote:

This seems to be fixed now

Still visible here. Try narrowing your screen a bit more, e.g., until 'View history' is above the sitelink box?

Hi Mike, can you give me some details of the browser and the width of the screen?

In T316797#10410059, @Arian_Bozorg wrote:

Hi Mike, can you give me some details of the browser and the width of the screen?

Firefox on Mac, latest versions. For the width, see the task description - 'Make sure screen is < 1570px'.

Project chat for reference: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2024/05#Could_we_switch_the_default_interface_skin_to_Vector_2022%3F

Sharing this user style that may be helpful

@media ( min-width: 1600px ) {
    .wikibase-entityview.wb-item {
        display: flex;
        flex-flow: row;
        gap: 8px;
    }
    .wikibase-entityview > * {
        float: none;
        overflow: scroll;
    }
    .wikibase-entityview-main,
    .wikibase-entityview-side {
        max-width: none !important;
    }
    .wikibase-entityview::after {
        content: none !important;
    }
    .wikibase-snakview {
        display: flex;
        gap: 8px;
    }
    .wikibase-snakview * {
        margin: 0 0 0 2px !important;
        position: relative !important;
        width: auto !important;
    }
    
    .wikibase-entityview-side {
        min-width: 366px;
    }
    .wikibase-statementgroupview {
        overflow: scroll;
    }    
    .wikibase-snakview-value {
        display: flex;
        max-width: 140px;
        white-space: nowrap;
        overflow: scroll;
        text-overflow: ellipsis;
     }
}

FWIW limited width can be disabled on certain namespaces ($wmgVectorMaxWidthOptionsNamespaces and VectorMaxWidthOptions), and probably doesn't make sense on item pages e.g. https://www.wikidata.org/wiki/Q1

WMDE: Let me know if you need any help working out how to fix this.

In T316797#10566092, @Jdlrobson-WMF wrote:

FWIW limited width can be disabled on certain namespaces ($wmgVectorMaxWidthOptionsNamespaces and VectorMaxWidthOptions), and probably doesn't make sense on item pages e.g. https://www.wikidata.org/wiki/Q1

I was just thinking the same thing – given that limited width is (IIUC) mainly motivated by legibility of long lines of prose text, and the desktop Wikidata UI already limits the width on its own anyways, I think it would make a lot of sense to disable the width limitation in the Item, Property and Lexeme namespaces. (Maybe EntitySchema too, but I’m not so sure there.) I think this wouldn’t completely solve the issue here, but it would already help for some screen widths.

@Lucas_Werkmeister_WMDE strangely my bad. This is already configured:
https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/1d43603d85f7b7e00aeeb7f1a8199dae6a0bd5bc/wmf-config/InitialiseSettings.php#2405

Ignore my last comment. It's already defaulting to as wide as Vector 2022 supports. If I recall correctly, the reason we don't support different widths on different pages is to provide consistent placement of the menu items. The width only applies when menus are closed, and here we're specifically concerned about the content when the menus are open.

T316797#10566092 seems like the best approach here. I'd suggest we try it out in [[MediaWiki:Vector 2022]] first while Wikidata.org defaults to legacy Vector to get some user feedback unless there any major objections.

Any objections to trying this out in MediaWiki:Vector-2022.css first? If I don't hear any by Tuesday next week, I'll apply this with the intention of feedback for this task.