Sun, Sep 15
Sat, Sep 14
Okaaaay, the new version of the patch should do it, but will require another update to the above localpage once it goes live...
Fri, Sep 13
Thu, Sep 12
This is now a lot simpler and just requires some sane styles. Yippee?
Well, above patch kills most of the 'too much contrast' cases, but what in the world is with that 'pastel yellow'?
The scrollbar thing also looks quite strange in MonoBook and Vector, just doesn't stand out as much.
Slight problem in that different browsers appear to have wildly different line-heights and I do not know how to account for that with css when the problem is that we are trying to insert content data into a non-content part of the page...
Note that this already works fine with MF, and probably belongs in core...
Note that this will also require the VE-specific styles to be removed entirely once merged/deployed, as they will no longer be needed at that point.
That should cover the weirdness where https://en.wikipedia.org/w/index.php?title=MediaWiki:Timeless.css&diff=915346348&oldid=853254178 isn't enough.
Nevermind, looks like it's in mediawiki:Timeless.css... I'll just update that, I guess?!
All right, ashley found the things:
So what's the specific problem with regard to MediaWiki? Is this blocking something? Would it enable us to do something of particular value in our contexts here?
Wed, Sep 11
All right, seems to be related to the position:relative on #mw-content-text. That maybe shouldn't even be there (should probably be on a block around/under the firstheading)...
And I could really use a sticky 'edit current section' button, while we're at it...
- Absolutely needs sticky top/bottom links somehow. I just got trapped on a long page and it sucks.
Patch was reverted for reasons. Apparently mw has too many modules and that's bad for js.
Between the patch for the general mobile support and https://gerrit.wikimedia.org/r/c/mediawiki/skins/Timeless/+/535273 we should be good.
We live in the future now!
Tue, Sep 10
Turns out because we're manhandling both parser and parseroutput objects this is actually ridiculously easy and I'm a dumbarse.
Mon, Sep 9
Fri, Sep 6
@Isarra That's an interesting idea. Roan had the same idea a few weeks back. Unfortunately, that's not compatible with how MW works.
Thu, Sep 5
Note: default theme has basically been named 'wikimedia' internally.
Linked image size:
Other skins accidentally avoid this issue by setting overflow: hidden (Vector and most other skins)
Why skins? Why not let people just mark modules as 'stylemodules', not worry about what the hell is providing them, and then not add them to the giant js bloat pile and be done with it?
So what Timeless does is you can either specify an array with all the image information (1x, 1.5x, 2x versions, plus nominal size), or just upload a file and it figures the rest out for you, but... yeah, skins will be making different sizes of these - what we should be standardising, however, are the intended dimensions so site admins can just upload one (set) and be done with it. We seem to have two use cases - likely square logos, and generally rectangular wordmarks. So if we settle on this, perhaps we just need to decide how big they should be uploaded up to in order to support all the likely uses different skins will want, and thus what to recommend for rasters?
In Timeless we basically just threw out the entire thing to roll a new logo handler using img srcsets (and optionally, the core thumb handler to generate the different resolutions for us) - this allows for arbitrarily-sized images to scale correctly regardless of how big they are to begin with.
Basically, Timeless already optionally does this ($wgTimelessWordmark and $wgTimelessLogo). Minerva does part of this (the wordmark), and simply doesn't use a square image logo to begin with. I am suggesting that everything should be doing this and we need to totally rework our logo handling on this assumption.
There is also a major issue in that a 'recommended size' isn't something we can meaningfully standardise, as what is going to be optimal is also going to vary considerably depending on a site's (main) skin. 135px is a good size for MonoBook. 155px is a better size for Vector (while still almost fitting on MonoBook, which tops out at ~154x155px). Timeless starts looking a bit weird when you go under 150px, and if anything the recommended there would be more like 160px. Greystuff and BlueSky use the same logo, but then scale it down to 66px and 55px respectively, and we don't even need a HiDPI version for that at all.
So the reason for the 135px thing on the higher-resolution versions is because raster background images really aren't intended to scale properly for different viewports.
Tue, Sep 3
BaseTemplate should probably just come with a default handler for older skins (Vector etc) where it just does the same as the current on in effect so folks can safely migrate and not worry about what skins they're targetting.
(But yeah, tacking it onto the end with a default fallback seems fine to me.)
We may want to consider an approach here that would also be consistent with other skins that use icons for menus and whatnot - for instance as I recall, bluesky had an option to just shove icons into the mediawiki:sidebar that it would parse and use for its main menu. I dunno if that's necessarily indicative of an approach that would actually work here, but it's something to consider - we probably need to establish a consistent way of handling icons for skins that use them regardless.
Mon, Sep 2
Fri, Aug 30
It won't actually hit enwp until the third or the fifth, based on the patch notes.
Not listed is experiment 2, because I forgot to link the task: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Timeless/+/530456
What we might want to do is include the jump buttons in the mobile one only, but by doing so, clearly establish what the handles would be for a gadget for desktop modes where people would want it there too.
Not just in the fixed header, also really needed on mobile...
Note that this is partially resolved in that there will now be icons for js-enabled users, but we won't have nojs support in Timeless (or Vector) until the ProofreadPage patch is also merged.
Would have been really nice if we could have just set up something automated for this. And, well, other such features, for that matter. What's the buy-in on any given extension, generally? Should I even be bothering to support it?
So no way to check against users that have even been active since the skin was created, or types of users in terms of edits.
So what exactly does one need to actually run these queries? Are you guys doing this on labs or quarry or what? Could someone rerun this or tell me exactly how I would do it myself?
Based on my experience with two RfCs this year, two things stood out:
Thu, Aug 29
Icons are now unspecified colour and could be used with this. (Greyness is done by opacity; may also be worth rethinking opacity level - T231619.)