I propose using theme's approach: putting them all inline under the specific skin, and displaying immediately as soon as the skin is selected using js, not just showing up once the skin is selected (but also doing this without js).
Mon, Nov 19
Appears to have been fixed, but I can't really speculate as to what by.
Wed, Nov 14
I'm not sure what you mean here by consuming. Does the skin needs to explicitly load it or something for it to activate? Or is this more of a VE-like deal where we just need to make sure the structure is actually, uh, what we expect?
Sun, Nov 11
Mon, Oct 29
this is causing me eyestrain
Wed, Oct 24
@Theklan To try it on testwiki, you'll need someone with admin or changecontentmodel rights (I recommend just getting that yourself if you don't have it) to make a hub and see it if meets your needs, as the signup feature is part of that. Just go to special:CreateCollaborationHub once you have that and try making one, etc.
Oct 21 2018
theoretically the important stuff are abstracted by mw.util
Oct 20 2018
I actually really like this idea - programmatically set the background to a colour calculated from the content of the image itself, if colours not already varying a lot. Would something like that be feasible?
Oct 18 2018
...I changed it back to the default. This is shorter. >.>
Even if the WMF website is not produced by the WMF directly, it is the front-facing... face of the WMF. To not follow the WMF style there completely undermines the style guides as applied to everything else, because for visitors who is producing it will not be a meaningful distinction.
Oct 17 2018
Oct 6 2018
Sep 17 2018
Sep 14 2018
Sep 13 2018
This patch should at least resolve the immediate issue, but I'd still like a better, more collapsed handling for these variants specifically, so the above question holds.
Sep 12 2018
Okay, anyone know how I replicate this on my dev environment?
Can we just make a separate module just for this?
To do this: set 'placeholder' => $this->getMsg( 'timeless-search-placeholder' )->text() in makeSearchInput call, except with a $1 calculated per above... and the fallback?
Per the prototype: use a placeholder string with a specified number of articles, but:
- Actually round the number ($1)
- Fall back to default (short) placeholder string at lower resolutions (how? js?)
Sep 11 2018
If this isn't actually fully resolved please yell at me.
Not that it really matters what it is; we just need a better default handling in general.
It's the language variants, whatever it is.
Sep 2 2018
Disregarding comments as 'personal opinions' is not helpful - by all means ask for references and further information, but in the meantime, let's please keep things civil and assume good faith.
Aug 31 2018
You should see the fix next week or so.
Is this resolved? If not, couple you please provide links to where it can still be reproduced?
'Blacklist' and 'whitelist' are the generic terms. Based on these, 'greylist' is probably about as generic as you can get as well.
All right, no worries. Thanks for taking the time to sort it out!
Timeless displays the hidden categories below the regular categories depending on the user preference to show hidden categories - is there another behaviour you're expecting to also enable them (perhaps a gadget)?
Aug 30 2018
Seems to no longer be an issue regardless.
Apparently fixed (likely the switch to flexbox layout?). Can no longer reproduce.
Aug 27 2018
Aug 24 2018
Generally speaking self-merging is not a good reason for this at all, unless it's specifically for projects with no other maintainers. Given that you are asking for +2 across all extensions, however, it sounds like that is not the case?
Aug 21 2018
Okay, so as it is right now, some comparison pictures:
Aug 14 2018
Aug 10 2018
Dumb question, but where exactly is this being developed? Does the foundation actually have access to the version control where it is, or is all of that being handled on the contractor end?
(Not that the cited codemirror or whatever it is bug also doesn't need to be fixed...)
Part of the point of doing the position and layer changes on both these skins is also just to make a clearer, more consistent-between-skins separation between content and navigation stuff. Needless to say this won't always work, but there are other potential extension incompatibilities that this should also help avoid, so if we have another option than to simply revert it, I'd argue that's probably ideal.
Aug 9 2018
Aug 8 2018
It sounds like there are some common symbols/whatever that probably would make for safe assumed breakpoints, though - maybe look into if this is truly the case, for some general default handling for which those blocks should be?
Aug 7 2018
So basically we just need a cleaner way for editors to define potential breakpoints - which LaTeX normally provides anyway?
Aug 6 2018
Aug 4 2018
Aug 3 2018
Aug 2 2018
I totally forgot this task was here.
Our policy is that we try to avoid z-index in favor of dom order (whenever possible).
This is a poor strategy. Not only are the colours not consistent with any extant branding, they are also do not meet accessibility guidelines, in terms of both contrast and general choice.
White on black (footer) and pink/green on blue (header and other parts of the site), for text or other elements, are also problematic and make some parts of the site quite painful to look at.
This is a branding issue. The red green blue are part of the visual identity of both the movement and the foundation itself, and thus deviations without apparent reason should be avoided, as they serve only to diffuse the brand and take away from any recognition people might otherwise have.
Specifically, that's Echo/Notifications, another extension. Is this echo/toolbar thing happening with everything, or just modern?
Technically fixed skin-side (it's now there, but as with in other skins, hidden by default), but it's up to the project(s) to actually unhide it if desired. Related: https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#SiteSub_display_('From_Wikipedia,_the_Free_Encyclopedia')
Basically I'm assuming we've currently got a desktop layout that works, we probably just need another one entirely for mobile. >.>
Okay, yeah, that is not a design that translates well to mobile, especially with the grouped version.
The easiest fix would be to move #mw-page-header-links above #firstHeading and then visually re-order then with CSS.
So there's more than one dot at times?
Do we have consistent guidelines anywhere for content vs chrome layering and z-index recommended ranges?
Even at full width the margins aren't entirely consistent between them and vary by a couple of pixels.
Agh, sorry, I missed this one. You told me and then I forgot and then it wasn't linked on the main task...
Jul 30 2018
This is silly. This is maintained functionality (the maintainer is right here yelling at you) that clearly works (as evidenced by the fact that people are using it), and there is already another task/RFC that would be a proper solution to the proposed problem anyway.
Nevermind, it breaks horribly in every single view mode. dataaftercontent placement appears to just be borked.
This probably has something to do with the new flex layout or something, which makes me really wonder what happened before...
Jul 22 2018
I want one. Thanks.
Jul 21 2018
Also, er, if you do use those and actually want better metrics and stuff, you might want to... get someone who's had less beer to... make things line up better?
Fixed for timeless in the above patch.
I'm going to be really, really optimistic for no reason.
Jul 20 2018
General heads up for all subscribers: development of Timeless is now being funded by a Project Grant. If you're interested in receiving updates about this, I've created a newsletter about it, which should be going out ~monthly.
Jul 19 2018
Total rejig of layout done in https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/Timeless/+/446569/
Okay, mobile issue IS caused by the giant pile of indicators.