Someone fixed this a while back. AND IT WASN'T ME. HAH.
I think that should do it, unless we want to discuss the padding on the actual boxes or some such.
Might be useful, as it should implement a specific single-sidebar setting: T131803: Options to only use a specific layout/not go bigger - single-column with only dropdown menus, or one sidebar-only
So we add some 'Desktop layout options':
- Single column layout with dropdown navigation
- Navigation in left-sidebar only
- Navigation and page tools in left and right sidebars
I thiiink this is good enough now?
(We're talking about an extension using a hook that exists to insert things after the content to insert things into the content. A quick test shows the extension content to be displaying reasonably for the described hook purpose; if we're expected to catch that it's actually trying to do something else entirely, that requires a much more thorough review of its function and interaction.)
I'm also a little confused what actually constitutes 'breakage' here to begin with, given that the factbox still appears to be displaying fine, just slightly further down. How deep do we need to go with this to catch potential issues, a full UX design review of every extension using the hook?
As an example, Timeless and Bluesky are two other skins that would already have been placing the Factbox thus, having effectively taken the hook at its word that it is data after the content; this just makes Vector and MonoBook more consistent with this naming and expected usage (as anything that is content can simply be added to the content itself). Other skins such as Modern and GreyStuff are unchanged because they don't really have clear separation in the first place.
Fri, Jul 12
Colours, while less garish, still don't match any WMF style documents I'm aware of.
...apparently I forgot to actually add that comment when I submitted the task. >.>
Screenshot is CologneBlue, but is unlikely to be the only example.
Thu, Jul 11
Apparently the problem was mariadb-10.4.6.
I mean potential use cases, where the extensions/whatever aren't doing this because it's too hacky, but might actually want to do something more sane if the option were available.
If we did have a more sensible way to achieve this sort of thing, it might provide a useful way around changecontentmodel right restrictions for extensions just creating new pages with different content content models (massmessage lists, collaboration hubs), without us needing to totally redo how we handle content model changes in general...
Mon, Jul 8
Oh my. :D
We could probably safely wrap any tables specified as wikitables, since that would rule out all the plain ones regardless (as the weird template tables tend to be), but given that's a class inside the table, it might be a bit messy to actually identify these, so yeah.
Fri, Jul 5
Wed, Jul 3
Given overriding .box isn't half as bad as using .unbox on it, though, I'm just going to close this and call it all bad css. Please yell at me if you actually care and I'll make a more specific task about all the bad css like this, though...
Oh, yeah, that's because it's overriding a mixin. This probably happens a few places, but... eh.
Should now be a lot more specific about what we actually want to do here.
Tue, Jul 2
Also I gotta rewrite this, and phabricator is incredibly difficult to edit with large amounts of text, so, er, I'm going to have to move the bulk of the background back to the wiki page...
I'm not sure if I'm supposed to do that (in fact I'm pretty sure I was told I wasn't), but maybe that will get this to move forward?
Ah, wikibase. Okay. Hmm.
What are interproject links?
This seems to be a common issue with a lot of tables across a lot of wikis, wikimedia and third-party alike. Is this really resolved? Would including a wrapper like that (but without the styles, specifically) perhaps be feasible core-side, allowing skins to handle it such that the styles themselves may or may not be applied across all modes, thus opening up the possibility of doing so where needed across the board?
Because the whole premise here was to make heavy use of layering and includes in order to allow maximal flexibility without requiring people to really implement a whole lot themselves. And that seems to be where our current mustache support quits working very well.
So having experimented (very briefly) with some templating with the current mustache support in core, I note that MediaWiki seems to have some very heavy caching of anything after the initial level, evidently due to performance concerns. What this means in practice is that it can actually be somewhat difficult to work with - one needs to manually disable or reset the cache every time they make a change in order for the change to show up, which for frontend design and development work presents a major problem in terms of seeing what we're doing while we do it.
Mon, Jul 1
By doing a little bit of refactoring of FlaggableXML, you can probably stop using the SkinAfterContent and achieve your goal
Why? What goal, exactly?
Sun, Jun 30
^ Assuming nothing else goes wrong with anything else and blocks the train, of course. Because that sometimes happens too!
Sat, Jun 29
And done. Do we need to cherry pick or something for actual deployment (and see what else we broke rather immediately), or are folks happy with waiting for the usual trains this time?
This should be resolved by the following patches, which are awaiting review:
Fri, Jun 28
FlaggedRevs in vector before and after:
As a workaround we could just add some really basic form styles (padding/margins, mostly) to Minerva to covet this sort of thing in general, like I did in Timeless (https://gerrit.wikimedia.org/r/c/mediawiki/skins/Timeless/+/504963/6/resources/forms.less). I think it mostly turned out to be fine even with all the other weird assumptions in mw, but definitely don't do the 'wat' thing, that was indeed an awful idea.
Also while I'm still pretty sure my above suggestion would fix them all, frankly migrating the FlaggedRevs forms to any core abstraction would probably fix this, and likely quite a few other things in other skins as well. Er.
Updated the task description, this actually seems to affect every FlaggedRevs form in Minerva, desktop and mobile alike, including special pages.
And Vector is fine, nothing to do there.
Okay, MonoBook done, I guess.
Echo + Modern needs more fixes in general (such as the ludicrously tiny text - T184295), but should now have parity with how it was before the badge change, so eeeeh good enough?
Thu, Jun 27
CologneBlue confirmed not to have any special styles to begin with. Also has issues with alignment of the flyouts, as echo apparently really doesn't like being in the left sidebar. T226786
There's an NGO that does mw skins? Have we reached out to them in order to collaborate on these things?
Probably the best way to do this is to just add an option skins can enable (or just a very specific thing to override/kill) to make it all text-based. I doubt this would actually make sense as a thing to make default for all skins, as many other third-party skins do indeed use icons, and a lot more heavily than, say, MonoBook or Vector, but having it as an option for these specific ones (and any others people make like them) would be good...
But this is a specific issue, so it's good to have a task about it.
For cologneblue I mean we should probably just do this and maybe add some extra vertical padding if need be: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Mask/+/519058
The cologneblue issue isn't new - I think it's always been like that.
Wed, Jun 26
I propose we just swap it to use OOUI for the form. That should fix this, and also make people less likely to notice my, er, other change.
Perhaps we can take a look in the morning at maybe just killing all the special skinstyles in Echo for the non-minerva skins (Minerva is really the only one not just doing basically the exact same thing as the rest) and doing what skin-example does. And all the other wikimedia-deployed skins have inline or inline-like personal tools, so it really shouldn't be this complicated...
Tue, Jun 25
Okay, that was the wrong place for that comment, so let's follow up with another really wrong-placed comment - I should also probably be rechecking all the positioning for FR in the other skins if we're maybe going to move all that there too...
Is minerva missing fieldset styles?
Is likely caused by timeless' form styles, especially if the icon is some sort of form element as well. But why is there a randomly floating icon in any case?
Mon, Jun 24
Sat, Jun 22
Slightly more seriously, do we have specific issues with it? Or ways to make it more... specific (some methods requiring the right, others not?)
They're always mad.
Fri, Jun 21
Yup, I don't know what that means. Congratulations, self. You utterly fail at filing actionable tasks.
Yeah whatever someone fixed it upstream or something, I dunno. It's usable.
...I'm paying attention.
Thu, Jun 20
Sorry, apparently this is a site request because apparently it's only enabled for some skins some places regardless. I misunderstood that.
It's also possible we may only want to do this in Vector, or something, just to distinguish more between the two skins - they have the exact same behaviour regarding this now, but that doesn't necessarily mean that's desired either.
All right, so experimenting with using the hook, it looks like it works pretty much as expected in most skins: Minerva (once support is added) is unchanged, Timeless, Modern, and other skins behave as expected, etc.
So it looks like the headers styling issue has since been fixed, regardless of why, and the reason why it's not using that hook is because Minerva doesn't support that hook and this extension is apparently primarily for Minerva, based on the default whitelist only including Minerva.
Wed, Jun 19
...also why is it headers at all?
So if I am understanding this correctly, the issue here is that this extension doesn't know where to add its content in the dom because skins vary and it's doing so via js?
This should have been tagged and closed when the timeless form styles were reverted mostly to defaults.
Added some others in case someone who cares about those can come up with something more reliable.