In T350515#9307030, @XanonymusX wrote:

Also would like to point out that the mobile history pages (whether with AMC or not) are additionally affected by this change. In e.g. https://de.wikipedia.org/w/index.php?title=Jonne_J%C3%A4rvel%C3%A4&action=history&useskin=minerva, the Undo button looks very different from the Thank button and especially the Rollback button. Also, the colours indicating flagged versions are not covering 100% width anymore, but only the width of the summary text. And on windows below 1000px, the "talk/contribs" links after the user name get hidden, while the user icon will suddenly show up. It just seems all very broken.

EDIT: And the button to show/hide selected versions (admin only) now causes overflow.

Yes, thank you! However, the element is now double the height it should have, I guess that should still be fixed.

Also would like to point out that the mobile history pages (whether with AMC or not) are additionally affected by this change. In e.g. https://de.wikipedia.org/w/index.php?title=Jonne_J%C3%A4rvel%C3%A4&action=history&useskin=minerva, the Undo button looks very different from the Thank button and especially the Rollback button. Also, the colours indicating flagged versions are not covering 100% width anymore, but only the width of the summary text. And on windows below 1000px, the "talk/contribs" links after the user name get hidden, while the user icon will suddenly show up. It just seems all very broken.

In T350515#9306065, @Jdlrobson wrote:

There is a history link at the top of the page (clock icon). With AMC disabled i still see the modified bar. What am I missing?

We have now finally added another font before Georgia on dewiki via vector.css (and vector-2022.css), in order to get rid of broken headings. Maybe this problem should be taken into account also for the upcoming typographical changes in Vector 2022 (@ovasileva)?

In T315893#9108971, @doctaxon wrote:

No, I disagree but you are wrong too. The words within the page title name indeed should be spelt orthographically. But the colon is not an orthographically colon but a namespace separator within the title database item, and with this it's programming language but not German language with its orthography. In spite of this the page name title is written in the URL without blank or separator, too. Why do we need such differences.

In T315893#9108778, @doctaxon wrote:

This has nothing to do with German spelling but with namespace separation. So the blank style is a programming language spelling mistake. I never saw this spelling within any other programming using namespaces.

In T315893#9108778, @doctaxon wrote:

This has nothing to do with German spelling but with namespace separation. So the blank style is a programming language spelling mistake. I never saw this spelling within any other programming using namespaces.

At least in German, not using a space after the colon is a spelling mistake, so in principle I would welcome such a change (for all page titles in all non-0 namespaces). The same would go for subpages, where in many instances there would be spaces needed before and after the slash. However, it is unclear whether we really need to enforce spelling rules on page titles outside the main namespace.

I had filed T328221 for the latter problem.

Actually, the form should not be visible at all in the editor. I had already pointed this issue out previously, on dewiki we are hiding it in the editor locally atm …

For reference: in dewiki, we applied these CSS fixes.

Another thing I noticed regarding the comment field: the input does not have any ID, while the label refers to mw-fr-commentbox.

In T324422#8989274, @matmarex wrote:

but I guess no one cares to report bugs in FlaggedRevs any more.

Just discovered another bug this has caused: when editing in VE or NWE, the new box covers dropdown menus like the link editor or the reference editor.

In T191156#8978655, @hgzh wrote:

The DOM looks odd, we have div and p inside span now and the mw-fr-reviewformlegend span got an 'additional' cdx-card__text id which should be in class= I guess.

I wouldn't call it very ugly, but the font size should definitely be reduced. The horizontal positioning on Vector 2022 seems definitely strange. And on dewiki, Monobook users seem to be particularly unhappy about it, but I can't really speak for them, as I have zero Monobook experience.

As I just noticed it on dewiki: is it intended that the subscribe option is now available for basically all pages outside of ns-0? In my eyes, it only makes sense on talk pages and other meta pages used as talk pages (like eg. this project), but there is no use for it on static meta pages. Most prominently I noticed this on our main page.

Yes, that sounds good. I have implemented the template solution in Template:Nummer-eins-TOC for now, seems to work fine! Will check whether I can expand the use of this solution on dewiki.

Exactly, there needs to be an alternative to NOTOC. A suggestion would be a magic word specifically for this use case (NO_INLINE_TOC or something like that). But the template suggestion sounds interesting as well. So you mean that the TOC will be forced to be invisible in the content? It seems a bit hacky, but if we are sure that it won’t break anything, I could introduce such a template on dewiki and replace the NOTOCS in relevant templates/pages.

It has been mentioned in other places before, but I don't see it mentioned in this task, so I wanted to point it out once again. There is a specific situation in which both the custom TOC in the article and the normal V22 TOC should be displayed. For example, in this list, the TOC is shown at the beginning of the article through a specific template, but because of the current use of NOTOC, there is no left-side TOC in V22, even though it would be very helpful when scrolling. Similarly, alphabetical lists on dewiki regularly work with such horizontal TOCs. It should be possible to display both a custom TOC and the standard one in V22.

So far it was only one user in this discussion. He tried editing with Vector 2022 and ended up using VE involuntarily. As he is an experienced editor, I wonder how new users would experience it (but Vector 2022 is not yet default on dewiki, so it’s hard to say).

Based on feedback in German WP, I think that the current icon for wikitext editing is not clear enough. With the editing pencil loading the VE, the impression is that Vector 2022 automatically enforces VE. I still prefer the combined icons of Minerva desktop …

I also like this simple design (with only the W): screenshot. Not sure if something like this is available for all projects though.

Imo, all of this has highlighted underlying problems with the display of tags in the watchlist. I’ll try to summarise them.

• In the discussion on dewiki, the usefulness of seeing the tags there at all has been questioned, as the tags tend to make single entries on the list unnecessarily long without much added value (except for filtering). For relatively trivial ones like mobile edit, I do understand the concern. This could be addressed with a preference (maybe a tickbox?) to make tags invisible in the watchlist. Otherwise, the proposed solution with mouseover could also be helpful here.
• On mobile, the “pills” look nice (imo), but they currently have a nowrap. Since the tags can get really long (especially now with the added link), this needs to change, otherwise you get overflow on small screens (my watchlist is broken since this change happened).
• On desktop, the tags are now put between brackets, which causes the above-mentioned problem with brackets within brackets. Using the same design as on mobile can be a solution, as long as the nowrap problem is addressed.

I do like the idea of the popups, as the discussion on dewiki made clear to me that the entire display of tags (with or without the extra link) is seen as rather distracting. What about the mobile version though, would it be a mobile-friendly popup?

Sure! There are two problems being discussed there atm, of which the imo more important one is T326399.

Oh, and another problem: this leads to parentheses in parentheses, which according to German spelling rules cannot be of the same type. So the inner parentheses would have to be [ ]. Not sure how to change that on our side, I guess a different approach needs to be found.

I was about to file another bug report, but here should be fine. On mobile, the tag markers apparently get a nowrap, which means that now some tags can cause overflow on small screens. I constantly see that now with tags like Bearbeitung von einer mobilen Anwendung (weitere Bearbeitungen) on dewiki. Maybe @Jdlrobson has an idea on how to better deal with these long tags on mobile.

Pointing out a bug on dewiki: discussion. Not sure yet if this is something to resolve purely on our side.

Yes, still broken on dewiki too.

I was wondering why this change (which I really like!) is currently limited to article and user namespace. It is a little confusing not being able to use the same functionalities across discussions.

Yes! So how do we get some progress on T6740?

I remember that thead wasn’t generally supported last time I checked, but it’s possible that has changed (was suggested in T42763#7119724 more than a year ago). I can try to rebuild the table (but that will require some testing on Beta)!

Exactly! So far that happened anyway and the row isn’t essential for readers, but with the adjustments I made it remains visible on the other skins, so it would be a shame to have it hidden again with Vector-2022.

I noticed that the matter isn’t fully resolved in all cases. After repeated requests, I have recently modified the header of the chart tables (like the ones in the Elvis example), in order to make both lines of the header sticky. That means that cells in the first row get top:0, while the cells in the second row get top:2.05em. While this works nicely without the sticky header of Vector-2022, the 2.05em are ignored when the sticky header is visible. The 3.125rem would need to be added to the existing top value, rather than replacing it. Not sure if this is easy to fix, but I wanted to report it.

The latest one was this one. A broader community discussion is not to be expected, considering that basically nobody knows about this feature.

This is not a mobile issue, but a Minerva issue, as explicated above. So styles would have to use skin selectors, not media queries. But it is very inefficient to further increase the size of those template styles imo, that is exactly the opposite of mobile-friendly. So either the current styles are modified to adapt to Minerva as well or Minerva’s behaviour can be improved.

Yeah, I understand that. Has it been checked whether these classes have been used outside of the usual TOC? I’m wondering if this is a mere dewiki thing. For now I’ll add the styles to the Skin CSS.

Let’s see what my colleague has to say about it. I don’t need a particular styling of MediaWiki-Buttons. But it seems unexpected that the same classes are used on editing icons.

Now it has become even worse, the section headings are oversized even without the editing icon. And when the icon shows, it is completely misaligned.

I can also reproduce it on this page, but not on eg this one. Thus it can’t just be the length of the introduction. Also happens in safemode. I made videos of the behaviour, but it seems I can’t upload them here …

Exactly, thanks for the direct comparison! I really don’t understand what the reason for the new width and the unnecessary margins is. When I had first seen it on the beta cluster, I thought it was just a temporary design problem.

Break-all is never a good idea, as that would break words even in the presence of spaces or hyphens. We usually do this with word-break:break-word + word-wrap:break-word, to have all browsers covered, though I think overflow-wrap has also more browser-support now. The alternative is of course text-overflow:ellipsis.

Ah, sorry, I should have said long words in titles! Of course titles wrap at spaces, that is not the issue.

Well, the width of the sidebar is given in rem, as far as I can see, so there must have been a change in that (I compare with the previous state, as I had been testing the new ToC for a while already). I do not use any zoom for my browser window. The random example is from https://de.wikipedia.org/wiki/Kalifornischer_Wacholder.

I'm a bit confused as to why the ToC/sidebar has suddenly become so large. The size used in the prototypes seems much more natural on my screen (like https://en-toc.wmcloud.org/wiki/Moon). Now the content of the page is aligned at the right side of the screen, while the sidebar/ToC uses a lot of space on the left, also due to imo unnecessarily large margins. I am aware that the overall design will be improved at the end, but the proportions right now don't seem to make sense to me. And if I make my browser window smaller (which happens automatically whenever I use the browser tools to look at the HTML), in my eyes it is very weird that only the page content but not the sidebar becomes narrow. Also, I think this behaviour interferes with responsive design based on screen width: if I want my templates to react to the available space, I now have to calculate the width of the content instead of the full screen for Vector 2022 (so no more 720px breakpoints).

In T304169#7880823, @alexhollender_WMF wrote:

In T304169#7880556, @XanonymusX wrote:

I was also surprised to see that overflow of long titles is not handled at all at this point. Well, I'll be patient.

thanks for this feedback. can you let us know what specifically is bothering you, and any ideas you have regarding possible improvements?

The effects on screen width are really bad right now, I agree. I was also surprised to see that overflow of long titles is not handled at all at this point. Well, I'll be patient.

I am not sure if this is a new bug: whenever I scroll down on this page on dewiki, the sticky header seemingly gets confused by the intro. Starting from the very top, the header first shows when I reach the tabs. Then, in the middle of the first list of the intro (around the item requests for the attention of an administrator, it suddenly vanishes. Only when I reach the first regular section of the page, the header returns. When scrolling upwards, the header does not show at all once I'm above the first section. What is happening here, can others reproduce this (using Chrome, btw)?

Sounds reasonable. However, I feel like most of the reasons for using NOTOC or Compact TOC atm become obsolete once a TOC is permanently shown next to the content. For example, while having a traditional vertical TOC for an alphabetical list is not very helpful and looks terrible, with the new TOC it would make more sense than the compact horizontal one (which is not permanently visible and thus harder to navigate). I wonder whether the behaviour could be improved in that regard.

Phabricator is really just about the specific technical solutions, not so much about programmatic communication about broader projects. As I said, you shouldn't bother about the design too much, it is far from final. The styling changes to new Vector are the final step of the Desktop Improvements project. Besides, I think that the current ToC is very ugly (and the new one is indeed unnecessarily similar to it), but I'm sure everything will get better. The important thing is the functionality.

In T273473#7864121, @AlexisJazz wrote:

Ah, I suppose this is the place to comment. (I had posted this on T302046 but this task seems more appropriate) Feedback time!

That left-of-the-article TOC is a horrible nightmare. I absolutely hate it. I would seriously avoid any website that forced it upon me. Can't scroll it out of sight, can't collapse it, can't disable it, takes up too much space, I hate it I hate it I hate it. This was the reason I switched back to Vector classic on beta cluster. (and if Vector classic gets it too I'll switch to Monobook, Timeless or just murder it with a userscript) I'm not much of a fan of Vector 2022 (but it's not a lost cause, just needs work), but this TOC pushed me over the edge.

As a personal note: I rarely use the existing TOC. But I can scroll it out of sight so it doesn't bother me. If the TOC went completely missing tomorrow, I wouldn't miss it. Having this big, (to me) useless thing that contrasts with the main content (it's much darker) permanently in my field of vision greatly annoys me. And because of the fixed position, my banner blindness fails to kick in. This results in pure hatred for something that, on the face it, could seem innocuous.

I mean broken in the sense of not working as designed. :) Not sure if a wrongly placed span could cause some more severe issues within a gallery (potentially affecting the rendering of the images themselves). Will keep an eye on whether this gets fixed by the update then!

In T42763#7844758, @Pols12 wrote:

Note style="position:sticky; top:0" workaround meets an issue with new Vector sticky header (the site header displays over the table header).

Something went wrong with German-language labels, as pointed out here. They are now using long-obsolete translations.

I have recently activated responsive navboxes on dewiki, for now restricted to music-related articles. Maybe as a design suggestion, I have only made minimal changes to the CSS.

Another situation in which I have noticed the behaviour: all pages on screen widths between 720 and 1000px. The sticky header only appears at 1000px while the additional top width is already triggered at 720px.

Is there more information on this by now? In my eyes, AMC should become default as soon as possible, so having a trial like this could be very helpful.

Another, presumably more serious issue I just noticed: the sticky site header seems to be not active on diff pages, but other sticky elements on the page will nonetheless be moved down and leave a gap the size of the (invisible) sticky site header! See for example when scrolling down this diff. Either the sticky header is activated for diffs as well, or the other sticky elements must be left as they are on diff pages.

I meant jumping back up! As is visible in your video, the [6] remains hidden under the table header (but not under the site header, that's why I thought that maybe there could be a solution for the overall problem).

I have noticed one issue: if I want to jump to one of the references from the footnotes, the position I jump to is below the sticky header, but not below the other sticky elements. Example: try to jump to reference 6 in the Elvis discography; it will be hidden under the sticky table header. Now, this problem is of course already present on these pages even without the sticky site header, but I was wondering if this could be fixed since it can be done for the sticky site header (I guess the unpredictability of the height of such elements makes a solution difficult though).

Well, the use of the <wbr> tags is part of the dewiki guide on how to use DISPLAYTITLE. There have been discussions about it in the past, but apparently this has shown to be the most efficient solution so far. Even more extreme example: Lopadotemachoselachogaleokranioleipsanodrimhypotrimmatosilphiokarabomelitokatakechymenokichlepikossyphophattoperisteralektryonoptokephalliokinklopeleiolagoosiraiobaphetraganopterygon. What you are proposing is what the mobile version is doing, right? Of course that could be used for all skins, so manual solutions wouldn't be needed anymore. Or, if we were to go for a new technical solution, imo soft hyphens would need to be allowed in DISPLAYTITLE, just breaking the title at random positions should generally be avoided (see T66528).

Two considerations:

• It is not obvious why the title has to be faded out at exactly that width; it leaves quite a lot of whitespace in the header on my screen, too much for my taste. I would have suggested to only fade titles out whenever they get too close to the icons. But I guess that could be looked at again when the header gets its final form.
• The title behaves unexpectedly in this dewiki article. I imagine it has to do with the <wbr> tags. Should I file this bug as a new task or does it still fall within the scope of this one?

Looks cool! I am only missing a tooltip right now, could that still be added?

I have tried it in Chrome and in Safari, it looks good to me! Long lines are now wrapping consistently, and only when actually needed. Thanks! Still not a fan of automatic hyphenation in the diff, but I guess it's acceptable.

Today I found another broken MobileDiff: https://de.m.wikipedia.org/wiki/Spezial:Mobiler_Unterschied/219031629 The inserted part overflows on smaller screens (both in Chrome and in Safari) because of the long IPv6. Word-breaks are apparently not applied. I am not sure if this is still related to the fixes from this task, in any case there should be word-breaks for long lines. I have been able to fix it for myself by adding .diff td div { word-break: break-word; } to my common.css, which I find confusing, as this used to be a mere Chrome fix and shouldn't have been necessary at all; but now it works for both Chrome and Safari. Any ideas?

Yeah, T293395 should really be worked at!

In T171726#7547887, @TheDJ wrote:

In T171726#7547881, @XanonymusX wrote:

But wasn’t it a table before already? The problem is fairly new (October).

I'm pretty sure it was always broken like that. That's probably why this ticket kept getting comments since 2017. it was never fixed in the right way.

Positive, my browser now seems to work just fine with word-wrap! This was definitely not always the case (see eg https://stackoverflow.com/questions/22785191/chrome-paragraph-word-wrap-break-word) and in the Chrome inspector it is still marked as wrong (unlike word-break or overflow-wrap, see screenshot), but I guess the patch will work everywhere then!

Last time I checked, all over MediaWiki word-wrap:break-word was always used together with word-break:break-word. I do the same whenever I add this to templates on-wiki, as I use Chrome and Safari, and without the double styles it never behaves consistently between the two! There might have been a very recent change in that, so I will do some more testing, but I’m pretty sure both lines are still needed.

Thanks for the patch! Seems good to me, but it still misses word-break:break-word for Chrome; word-wrap only works on other browsers.

But wasn’t it a table before already? The problem is fairly new (October).