Aug 13 2020
The icons are black, or rather, default fill (black), which would probably explain why they show up as, well, black. Based on the echo icons, which also appear to have unspecified and thus default fill, the only difference I can see is that the echo icons appear to be embedded, the timeless ones are not?
(And if you really want to put things in those side margins, just expand them then. Or this may well be an even better argument for losing the different background/borders entirely, as this way you would maintain consistency between pages with and without...)
Aug 4 2020
Okay, the title scared me, but yeah, that line can definitely be killed. We don't want to lose the screen-desktop.css file, as that is just the general desktop stylesheet, but it's loaded... normally for real browsers. Well, semi-normally. The user preference makes it a bit less normal, but anyway...
Aug 3 2020
Look, as long as it works, I'm fine with any sane default. :P
Jul 30 2020
Is now... normal.
Probably didn't get all of them, but whatever.
Better solution: disable it by default so folks can just apply their own in splash.css or whatever if they want. Or just... you know, not have it.
Splash now supports ULS better than Timeless. Well. Maybe.
But probably still stands, especially for the long page names.
Wow, this was vague.
Nope! I don't know!
Jul 28 2020
Screw it, let's just let people disable it. They can use mediawiki:splash.css to actually do whatever.
Uuuh I'll let you figure out the logic of this one.
Jul 24 2020
It's IE. Nobody cares! Or I don't, anyway.
Pretty sure they all have it because monobook/example have/had it. Kick it out of those and the rest should follow.
The hilarious bit here is I'm not even sure any of these skins (or othe skins I've looked at) actually use it for anything.
Jul 21 2020
Jul 18 2020
Jul 17 2020
Are there any simpler examples? Do you have any plans to migrate the Example skin?
Heeey, it works. I have no idea what you did or what's going on so I cannot comment further. Good day, but thank you for whatever it was!
Jul 14 2020
Skin exists. Has all modes. Needs fixes, but is implemented.
It's farms, or whoever. Done.
Nevermind. Skin exists.
Jul 10 2020
If the IP block exempt right onwiki also works (at least some of the time) per T254568, maybe I should just go request that? I never bothered because I so rarely actually edit anything anymore, but if it also covers this, that would be an actual reason to request it. Also then maybe I'd actually bother to update documentation on mw.org slightly more often...
Jul 9 2020
Okay, that would explain it, at least. T229620 seems pretty major in particular and I'd argue describes the bare minimum of what needs to be resolved here, as when I first ran into this I spent the better part of a day just thinking phabricator was down for some reason. Took it as an excuse to give up entirely and not work on anything, which is great when I'm already having some difficulty getting back into any involvement to begin with when it comes to mw development...
Jul 8 2020
Jun 5 2020
Makes sense to me, given this never got to the point of usability to begin with. And given how the project ended, I don't really see myself coming back to this any time soon, if ever.
May 28 2020
This was probably about the css classes that core etc expect to have defined, which may or may not be defined in the extremely nebulous legacy.css (?) files of the time.
May 22 2020
So basically we just need to sort out how to do this in a way that doesn't balloon the css or make it inordinately difficult to work with, was my understanding, but it sounds like we're still in a better place overall now than we were...
I deny all responsibility.
I kind of want to close this as I don't see it going anywhere further, but there's also some useful conversation in the comments that could well still be applied to other things... so I dunno.
Unassigning as I don't really have the resources to do anything about this, but can definitely confirm it to be an issue. We basically have a submenu hidden in another submenu, and no visual affordances to even indicate the second one even exists to begin with until you hover over 'contributions' specifically (doubly hilarious for me to reproduce as hover is currently partially broken for me in-browser).
I'ma say we don't care about older browsers. Like, this doesn't break anything for them, just is a mild annoyance.
Closing; all handling these days should be fully up to them onwiki?
Apr 13 2020
If it takes more than a simple include/activation + some styles to set it up, I'm gonna be honest, probably not. (Even the portals thing almost qualified as such, despite the js in questing needing to be copy-pasted into the skin directly, except it just didn't work out of the box with a lot of mw, either.)
Apr 7 2020
Unless of course I cave and... oh gods why...
Okay, having looked at what Alistair provided, we are not reusing even a subset of the portals js in timeless. That is some truly scary stuff.
Apr 6 2020
I am so confused... is this about the core editor, or VE's wikitext editor? Or does VE's editor just inherit the core styles regardless, in which case why does it matter and why was it filed against any of that when those are not where the fix should be? And what skin is this for? I don't think any of the mentioned skins have sidebars the same size as the content?
Feb 6 2020
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.