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).

It is a MediaWiki problem as long as it is not handled consistently between Desktop, Mobile Web and App; how should editors be able to keep all of these in mind? Plus most editors I know (so-called power users) don’t care about the mobile experience at all, while most readers are on mobile.

No, still the same. Just follow the links I posted above, eg this one (broken in both Safari and Chrome).

What is the state of the patch? It seemed ready in 2018, what is blocking it? The approach seems right to me. I agree that it is urgently needed!

Does the Uploads link also depend on ContentTranslation then?

Yes, as it is done anywhere else in Minerva, as far as I am aware of. MobileDiff has had this really strange approach with break-all for some time now, so I’m not surprised that it is broken.

Seems to be fixed now! However, if I open a page with the VE or NWE, both these links are displayed double:

Yes, but either way, word-wrap won’t fix it for Chrome, so I’m not sure how this addresses the most recent bug (these properties are incredibly annoying, but I have come to accept that they just need to be used in combination everywhere and all the time).

Again, why break-all? That should have never been there in the first place, anywhere else the strategy for mobile is to use either hyphens:auto or word-break. The issue here is mostly the inconsistency, even between the changed lines and the context lines; but also the lack of browser support for certain functions needed here. Right now, the changed lines need a word-break:break-word for Chrome to correctly handle the diff (again, word-wrap is not supported there).

While testing this on beta, I was wondering whether users might start to expect finding the user page also inside the regular user menu, once they are used to the user menu of the sticky header. I honestly find the current design with the separate user page link to be less intuitive, so maybe it is worth considering a more consistent solution (involving also the notification icons, probably).

This diff is broken even on Safari, which means that hyphens:auto can’t handle all cases either. This was definitely a recent change!

In T289816#7441253, @Jdlrobson wrote:

Olga, It's alright a patch is up to fix the tooltip problem.

Looks good!

Hm, but to me it looks like also the font type (or the line-height?) has changed (also in Safari). Well, take for example this diff: the file name is too long for small screens and while in Safari it now gets hyphens:auto (weird for a file name, but anyway), in Chrome it neither breaks nor gets hyphenated and I have to scroll. See my EDIT 2 in the task description, right now only hyphens:auto and word-wrap:break-word are applied, instead of word-break:break-word, as needed for Chrome.

Has something been changed with regards to this recently? The mobile diff does not break words anymore in Chrome, but also does not use hyphens (as it does in Safari), which leads to broken diffs requiring scrolling sideways.

Another issue with the user menu I have noticed recently: while the single options in the dropdown usually have a tooltip, the final one (logOut) doesn't, so User menu is shown instead.

General comment on the current implementation (I couldn't find a dedicated subtask): of the icons in the sticky header, talk page and history still need a tooltip (or is there a specific reason to treat these two differently from the rest?). Should be fixed before deployment.

Wasn't the link to the user page itself supposed to be part of this user menu as well? At least it was in the prototype. Right now there is no way to get to the user page from the sticky header.

Yes, that's what I thought. On dewiki, I am not aware of other templates generally using sticky table headers, so "my" templates would be the most common, if not only use cases so far. Those tables all use the class charts-stickyhead (as documented here). I have no idea if other projects have done similar experiments, the Gadget on enwiki (@TheDJ) can probably be adapted to the Skin-specific differences. I think if this sticky header is deployed, the potential problem and its fix (eg, adding a certain standardized class) should be clearly documented somewhere for reference, then fixing any unwanted effects should be relatively easy. I will follow it closely in any case ;)

Hm, so you basically do not see the element mw-fr-category-oldreviewed. I thought logged-in users would see it generally, but since it comes from FlaggedRevs, I suppose you need reviewer rights in order to see it.

The linked page is still the relevant use case. To see the issue, you just need to be logged in and get rid of span.subpages {display: block;} in Minerva.css and Mobile.css, which is our temporary fix.

Yes, I was thinking of that. But would that have to be done for every template and gadget or would new Vector automatically modify top:0 in tables? In templates, it would of course be possible to target Vector and change the top property only there, but I don’t know how that would affect Vector Legacy. And much depends on the final version of the sticky site header: if it only appears on mouseover, it might not be necessary to change sticky table headers at all, as they would only be covered temporarily; otherwise, elements would have to move whenever the sticky site header appears. If the site header remains sticky all the time, the table headers need to remain visible all the time. And if the site header will be configurable through user preferences, the configuration would have to adapt accordingly.

True, I remember having tested to fix the VE toolbar in such situations, the overlap is very annoying. A page with several sticky table headers on dewiki is eg this discography (the template is of course used on thousands of pages). On enwiki, there is even a Gadget that can be activated for basically all tables.

I had already mentioned that on one of the feedback pages (can’t find it anymore), but I would like to point it out here as well: the feature should not clash with sticky headers of tables already used on pages. A sticky site header would overlap sticky table headers and make them useless. Maybe such situations have already been addressed in the meantime, just wanted to mention it again. I’m looking forward to the feature!

The blatant “who cares?” attitude shown on this task makes it hard for me to comment any further. But anyway, let’s wait until someone answers the obvious question on why this change was not announced the way it should have been. Then we might think about a local solution. Just further cluttering the common stylesheet of dewiki after every new bug should be avoided.

Yes, that could only be fixed via Common.css, but I would not touch that stylesheet only for a temporary fix.

Who is going to determine what are “important articles” and by which criteria? Without a replacement strategy, this change should have never been done in the first place. If it can’t be undone easily, I will propose a local replacement via Common.css on dewiki (at least for the row highlighting, which in my experience is the main reason why it is used). But I guess that cannot be a permanent solution.

Yeah, currently we are advised against using TemplateStyles that way. And as PerfektesChaos already pointed out, who is going to insert that template in more than 2,000 pages now?

I always liked using datatable on tables, and apparently I was not alone on dewiki: more than 2,000 pages there use the feature. The suggestion to work with TemplateStyles does not help, as we cannot simply make templates out of all the individual tables. Please bring back the functionality asap!

How far are we on this? The search suggestions footer still does not wrap correctly on Chrome, in any case.

In T97892#7281678, @Jdlrobson wrote:

This looks like a small unintentional mistake in T285492 that's easily rectifiable due to 2 conflicting but unrelated changes. No action is needed from editors.

In T97892#7281043, @XanonymusX wrote:

Are we supposed to fix this on dewiki directly via Monobook.css (easily doable) or will there actually be a central solution? I don’t really understand what the proposed “move to Monobook” of this task was trying to do.

For the record, this task was a refactor to make MonoBook more manageable that was done in July that has nothing to do with the current breakage. The current breakage occurred due to applying a patch that was written before the change and only recently merged. I've applied a temporary fix to MonoBook.css which I'll remove when this is dealt with.

Are we supposed to fix this on dewiki directly via Monobook.css (easily doable) or will there actually be a central solution? I don’t really understand what the proposed “move to Monobook” of this task was trying to do.

As far as I can see, the same error is shown for links to redirects and for “red links” (thus links to ?action=edit of non-existing pages). For the former I would expect to be shown the preview of the page it redirects to, for the latter I would recommend a more specific error message, if possible (“read on Wikipedia” is a misleading description if it leads to editing a page).

I have tried to describe what the original problem was (and still is)

Oh, true, I checked with protected pages in ns-0 as well! Okay, new task then.

Just noticed this as well. Additionally, for pages in the Help and Template namespace, I do not see a “protect” option (while move and delete are present). I can’t think of a good reason to treat the various namespaces differently.

Yes, but why would you go for break-all now? That one is the worst option available, as lined out in T171726 (at least for text, not sure if it would make any difference for mere search results). It needs break-word (and yes, as a fallback for hyphenation). There is also some confusion around whether to use word-break, word-wrap or overflow-wrap (Chrome does some weird things there), but that will need some browser testing. Search results and footer should act in the same way in any case.

As long as it does not work in Chrome (the by far most widely used browser), it should not even be an option. And while in normal text it might be reasonable to use it, in the context of a diff (T171726) it does more harm than good, as readers won’t be able to distinguish between actual hyphens in the text and automatic hyphens. I guess in the search, hyphenation could be considered (but please consistently, not just in the footer), as users can directly see if they typed a hyphen themselves, but it needs word-break as fallback for Chrome and unsupported languages.

So, your observation is actually easily explainable: the browser apparently does not know any working hyphenation for Hebrew specifically, just tried it on Firefox. Other languages work fine. While Chrome apparently does not provide hyphenation in this context at all. That’s why I already questioned the use of hyphens:auto several times; just use word-break as anywhere else and we should be fine on all browsers and in all languages.

Hm, doesn’t seem like a satisfying explanation to me; I always have this happen on dewiki, where content language and interface language are both German!

Interesting. So this part is supposed to use hyphens instead of word-break? I would suggest to be consistent everywhere, but no idea if this is the root cause. For me it looks like in this screenshot; I use Chrome, there should be nothing else causing trouble.