Thu, Feb 6
Per what Volker said, I find it very unlikely that users would want this on MonoBook, for example. That skin is all about not changing things from defaults unless there's a very good reason.
Jan 15 2020
Also there's probably some assumption here that whoever runs the script knows what they're converting in the first place and chooses appropriate content models to convert to.
It won't always work at all, but in most cases it should at very least be possible to change it to something that can be viewed/displayed in some sense. Most should be text-based, for instance, so it should be possible to, while not changing the actual content, change the type to something that could be displayed and accessed at all (even if it's only to privileged users or something) without erroring out or losing data...
What ashley said.
Dec 11 2019
Also random note, this appears to only affect newer and up-to-date android devices.
Where is the source for this?
Nov 27 2019
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.
Nov 15 2019
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?
Nov 10 2019
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.