Wed, Nov 27
Vector is a tiny codebase currently.
...compared to what? For a skin, it's already huge, unless you're comparing to third-party skins such as wikiHow's Owl or Fandom's Oasis skins, or Minerva, which didn't even begin as a skin at all. That's not really going to be a fair comparison anyway as the former are both single-skin sites that include quite a bit of specific functionality and extra extension handling in the skins themselves, and the later likewise existing as essentially its own version of the site. This has, for Minerva, led to most of the present work on it to consist of trying to get this stuff out of the skin, as it makes it extremely difficult to update and maintain, and for wikiHow and Fandom, been a major contributing factor to why they so rarely update their mw version at all.
Fri, Nov 15
I'm not sure what I was asking either, but from some quick testing it looks about the same to me - timeless caps at two reference columns due to the fixed width (and perhaps also the larger font, frankly) and stays at two reference columns even after vector drops down to one for a bit due to losing its sidebar sooner, but the cutoff widths at which this occurs seem consistent between the two in terms of the content itself.
So is there any reason not to do this with all files, in all skins? For all wikis?
Sun, Nov 10
Oct 15 2019
Vector uses border-bottom directly for h2s and hides all overflow to avoid this intersecting with floats, but it's a very harsh way of handling things. Unfortunately this was basically the only option back when the styles were created years and years ago, back when we also had to support IE6 and crap. Timeless does ::after pseudo-elements to render the border-bottom and thus can put the overflow rules on that alone, and avoid the problems with scripts being cut off, gadget conflicts, overlapping borders, etc. We weren't really sure if this would work in practice and thus didn't push for doing it everywhere, but given that it actually does seem to work and the issues largely just appear to be with pages where people explicitly styled around the existing approach and don't have styles for this variant, it might be worth migrating everything else to do it this way and thus negate the need for all the special language-specific styles in Vector etc...
Oct 8 2019
As always, I highly recommend against forking Vector. Its internals are dated and highly inconsistent after accumulated years of overengineering, and you will waste considerable time trying to clean that up/figure out what's going on, and even then you will undoubtably wind up with quite a bit of unnecessary code in your final product. Better to start from scratch: fork the Example skin, as recommended, and (re)add in the required features there. The result will be much cleaner, and ultimately easier to both make and maintain, following best practices.
Oct 4 2019
Oct 1 2019
It's because wikilove has an option to use an icon only. Because this option is targeted at desktop (vector, originally), we heed it in timeless desktop layouts too.
Sep 29 2019
Sep 27 2019
Per https://test.wikipedia.org/wiki/Special:PrefixIndex/Wikipedia:Test_collab, 'Announcements' is properly transcluded; 'Membres' is not not. Hub appears to have been created on an english-language project by a french user, hence the issue. In practice, 'Members' should probably just be treated the same as 'Announcements'.
Dumb question, but why exactly do we need to manually include the license with every extension when for the most part there are only like five different licenses between the lot of them? Maybe it's just that I'm not really coming from a software background, here, but that just seems needlessly redundant, especially when they all rely on mw to even do anything in the first place.
Sep 26 2019
Palette reduced. Should no longer be a blocker as such, and this should require no further schema changed.
Sep 25 2019
I'm also not actually sure why that was there in the first place, and it may not even be needed in the first place. Might be worth looking into that aspect of it, too...
Sep 24 2019
Sep 15 2019
Sep 14 2019
Okaaaay, the new version of the patch should do it, but will require another update to the above localpage once it goes live...
Sep 13 2019
Sep 12 2019
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?
Sep 11 2019
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!
Sep 10 2019
Turns out because we're manhandling both parser and parseroutput objects this is actually ridiculously easy and I'm a dumbarse.
Sep 9 2019
Sep 6 2019
@Isarra That's an interesting idea. Roan had the same idea a few weeks back. Unfortunately, that's not compatible with how MW works.
Sep 5 2019
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.
Sep 3 2019
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.
Sep 2 2019
Aug 30 2019
It won't actually hit enwp until the third or the fifth, based on the patch notes.