On 03/04/18 22:52, Strainu wrote:
Well, it looks a bit dated, but in cute and geekish way. I love the way you took the menu out of the way without hiding it under a hamburger button,
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.
but what I would particularly like to see is how it handles navboxes. Traditionally, they have been hidden on the Wikipedia mobile site, prompting people to do all kinds of sick workarounds that kind of work, but not really. If anyone can come up with a decent solution to that it's probably you :)
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
