2018-04-04 18:40 GMT+03:00 Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>rg>: Skipping navboxes is a decision that was taken by the WMF team responsible for the mobile site (whatever it was called at the time) and can be solved cleanly only at the skin level, but I don't expect this to happen as long as it will break the mobile site. Your proposal would be the ideal argument for reversing the current "solution", yes, but realistically, it's not going to happen throughout the hundreds of wikis that implemented navboxes. Strainu

On 03/04/18 22:52, Strainu wrote: Well, admittedly, that approach was largely just so it would work at all without js. I was kind of planning on also having a more traditional popout thing for when js is enabled, but I haven't implemented that yet. As others rightly point out, the problem with navboxes is as much an onwiki/content problem as a skinning one - many of these did not need to be tables to begin with, but there was no reason not to, but there also wasn't really any better alternative. Now that we have things like templatestyles, options exist to convert them, but that's going to take considerable time and effort as well from actual content editors - but there are also a lot of tables in the wiki content that actually do need to be tables, too. This sort of data is hard to present and... well, frankly resolving that for tables in general should at least begin to approach navboxes as they are currently, as well? So I see a few approaches here, beyond just convert the navboxes content-side, since, again, that doesn't solve all of it anyway (though we still should do that too): * Hide such tables entirely (what MF apparently does?). They display poorly, and provide relatively little value as a result. I... don't like this logic, because if they weren't worth having they wouldn't be on the page in the first place, generally. This is the sort of call the editors should be making. * Collapse tables into a modal, as DJ says - have some sort of thumbnail and the like to indicate what it is in general, and then open it up into a full-screen viewer. Unfortunately requires js. (So fine for modern skins, but this is monobook!) * Just kind of... separate them from the rest of the content with contained scrolling (overflow: auto, I think?). Has potential to be very annoying, but at least it doesn't require js! Given that that's all I've got, I'll just come out and say that a canned version of the second one in core would be incredibly useful across all skins, and... we can probably just manually add in the third as a nojs fallback? Except why not include that fallback regardless? Hmm. Are there any other options here? -I