Ideally should all be consistent with mediawiki.skinning stuff in core.
Wed, Apr 18
Tue, Apr 17
Special:ChangeContentModel + stuffing everything in a template would probably cover it?
Okay, fine, I've quit using oldopera.
Sat, Apr 14
Note that we need some sort of nojs fallback in general for mobile. The MonoBook approach may be appropriate here if we opt to make hover no longer activate menus for whatever reason, but if not, everything still just showing up on hover makes the most sense.
Sat, Mar 24
Appears to have been caused in 421717 by using spaces to indent instead of tabs. No idea about the other one as that one is already using tabs properly.
Mar 14 2018
(I'd be more specific about what rules exactly are causing this combined with what, but sadly I apparently neglected to write it down when I investigated for T183215. On the plus side, if this is the same thing, the severity of this particular issue should make it easier to check?)
Sounds like the same thing as T183215 (but possibly compounded further by VE/OOJS specific stuff) which appears to be caused by overflow: rules and the whole floaty layout for the columns. Was planning to fix it by getting rid of the whole float approach entirely and replacing it with flexbox, or something, but then I never got the funding to properly work on any of this, so it's all just sat there.
Welcome to chrome.
Mar 2 2018
Will the exceptions be configurable? Some wikis will have different appropriate uses or only want more simple/common options to be thankable, whereas others may actually want to thank even the most frivolous things. Especially the most frivolous things.
Feb 20 2018
Unfortunately something this large will require consistent backing in order to move the process along and effectively reach out to all involved. A volunteer could pull it off, but it's very unlikely anyone actually will - which brings me back to 'we really need people actually working on this'. Many of the groups I included are also not going to be currently active contributors - they're potential contributors, or contributors we've already lost - but they're just as important to the overall goal of drawing in and keeping a wider community of contributors as those who actually have managed to stick around. We need all these voices to understand the overall context.
How I would do this:
- Find a decent set of people to specifically reach out to - non WMF among top patch uploaders, bug reporters, etc. Also check github, smw, other venues and the like. Include companies like wikiHow and other third-party organisation users to contact as specific entities, especially if they have actually tried to work with the WMF in the past. Could be any number, but 50 is a reasonable target total.
- Send out invites to above specific people and entities, and also include messages to various other relevant groups/lists (mediawiki-l, stakeholders, etc), to a call for comments, essentially - some sort of central hub to gather stories about what's good and bad with current interactions with the WMF, and what's needed. For the specifically targeted individuals/entities, include the basic questions in the email and also encourage them to simply reply directly to the email if that's easier.
- Compile all responses in hub, regardless of how they arrived.
- Do the opposite - get information from WMF teams, especially those who have worked with third-party organisations in the past. Find out what their pain points were and what did and didn't work then, or in general, what they could see gaining from more external cooperation, and what they see as blockers currently.
Feb 19 2018
Feb 12 2018
It's supposed to work across devices, with distinct designs for desktop, mobile, and other weird things. The only problem is they're all broken. Slight problem. Slight.
Feb 9 2018
Jan 20 2018
Yeah, this is a bad idea. All the things vandals could do with this can be done just as easily out of the template namespace as anywhere, and even on third-party sites like ?pedia and uncyclopedia where we use extension:css, which lets users use pretty much ANY css anywhere, applying to anything on the page, it still hasn't caused a lot of extra problems. Yes, vandals with that can even remove the entire interface, but it's not like they couldn't cover it all up before, or the like, and these kinds of edits do stand out particularly when using change patrolling tools.
Jan 17 2018
If we want to propose specific projects for this, should we just do the usual discussion on-wiki to see if there's consensus, as it looks like svwiki has already done? Is there anything in particular people should know when discussing it? What would the timeframe look like to editors?
So when's this happening? Wheeeeeen?
Has nothing to do with hardware acceleration; still occurs with it enabled.
Jan 14 2018
That patch does seem to mess up ULS's handling (forced visibility) of empty languages blocks. I'm not sure what to make of it, though, so whatever.
Sorry, I was on the wrong computer for awhile there and it kind of got lost in backlog.
Dec 31 2017
Start with that, reposition, replace icon?
Dec 29 2017
Yeah, I've been meaning to come back to this when my brain is actually working, but it hasn't happened for whatever reason. I've asked @ashley to take a look in the meantime, though - if everything's sane he can totally merge it anyway. >.>
Dec 28 2017
@grey-bright is what is used for image borders in thumbs. It should be the same. Whether or not the value is too light in general is a separate issue; you are welcome to file a task about that as well.
Dec 27 2017
@Od1n: Use the @grey-bright variable.
This has nothing to do with SWAP. Probably caused by disabling hardware acceleration combined with some css chromium doesn't handle well?
Dec 22 2017
Typically for images on the page, we don't want the text to wrap around them on mobile. This specifically applies to thumbs, which are floated left or right, usually, in the content.
Dec 21 2017
Great idea. If anyone wants to make a patch for that, please just yell at me and I'll merge it.
Dec 20 2017
Since we actually have a more thorough style guide now.
Dec 19 2017
Oh, also hardware acceleration is disabled, may or may not be related, but now we're getting into the general rabbit hole of chromium's utter instability.
Er, this is on linux (mouse clipboard), Chromium 63.0.3239.84, and when running out of SWAP. Yes, SWAP can be slow, but not this slow, and not for this, as evidenced by other skins not being affected. Tested on meta.
Dec 16 2017
Okay, sometimes the tools one is also behind it? I don't even know.
Search suggestions cover up the search in ancient safari on ancient iphone.
Dec 14 2017
Dec 10 2017
There is also the very obvious question of do I even care.
It was some sort of fancy api thing to get the information and completely reimplement the toggle ui. Or possibly even more than that. @ashley?
Dec 9 2017
Okay, this is happening in every skin with css hover dropdowns (splash, vector, bluesky, etc - not greystuff because that one is actually js). Appears to just be a chromium bug.
Dec 8 2017
Nevermind, I think I found a new browser.
Since this being gone means I can't use oldopera for css editing anymore, does anyone know of any extensions for chrome to bring back oldopera-style css editing in the developer tools?
That preference isn't exactly new, though.
Dec 7 2017
The 'approximately' was a joke. Because it was exact... and generally, exactly wrong.
Dec 5 2017
(The issue does not occur on mobile resolutions without going through MF. See: https://en.wikipedia.org/wiki/Yellowhammer?useskin=timeless which does not have the ToC issue, but also lacks all the other MF content improvements.)
Thank you, looks like it's a compatibility issue with mobilefrontend.
What project is this on?
Dec 4 2017
Sitenotice shows up fine for me on testwiki. https://test.wikipedia.org/wiki/Main_Page?useskin=timeless
Dec 2 2017
Huh, okay. Support clearly needs to be added.
Dec 1 2017
How ballpark is ballpark?
Can we also only look at logged-in users? This being about user preferences, and all.
Can we make this just content pages?
Yeah, I'd love to have this now that Timeless has had a chance to stew everywhere for a bit. Be good to have an idea where we're starting from.
Thanks. Looks like that can happen in all skins, though, so I'm not really sure how to avoid it besides maybe using custom fonts...
Nov 30 2017
Nov 29 2017
I mean, I kind of want to replace the entire text with something... shorter and less silly? But in the meantime, that is totally reasonable. Or stuff.
Nov 28 2017
Minerva should reuse the same footer links that all the other skins do instead of implementing this specifically.
@Menthe I fully agree; the right sidebar isn't going anywhere at high-resolution because there's just no good reason not to use that space (and it's already collapsed into the left at lower ones so the content doesn't get too squished). And moving the infobox into it is an excellent idea currently blocked by the fact that infoboxes are just content and it's hard to make a skin handle specific content, BUT that is definitely a very important use case for actually making that into an extension so we can do that. Apparently there's an RfC and stuff already, but I don't remember where.
In which part of the interface is this coming up?
Nov 27 2017
I mean, I'm sold. overflow: hidden sounds good to me.
No, we should totally tell the wikipedias to do that. :D
Overflow:hidden results in the overflowing content being just... gone, though. Which means if you have a too-big table, it can't even be accessed.