Mon, Sep 17
Fri, Sep 14
Thu, Sep 13
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.
Wed, Sep 12
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?)
Tue, Sep 11
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.
Sun, Sep 2
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.
Fri, Aug 31
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!
Timeles 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)?
Thu, Aug 30
Seems to no longer be an issue regardless.
Apparently fixed (likely the switch to flexbox layout?). Can no longer reproduce.
Mon, Aug 27
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.
Okay, so in three-column mode you need to scroll on the sidebars. The content cannot be scrolled on. Also it scrolls horizontally really far for some reason.
Jul 18 2018
I tried deleting the entire icons node and it didn't seem to help any. I... may have to come back to this one later.
...what is going on, indeed. I can't even get to the content on desktop in chrome... there's just this giant empty space off to the side, and all the content itself is just... gone.
So what have been all the versions and what are y'all really after, here?
As a wordmark, that version's pretty good.
Okay, question - in a way, does this sort of just depend on making a new mw logo that meets requirements, such that then parsoid can have an appropriate derivative logo that is actually usable in print etc?
So, uh, what should it look like? Wikibase logo modified how? What's a registry? What is this thing? What does it do? What do you associate with it? Bees?
SHITTY LOGO COMING UP.
Jul 8 2018
NOPE, STILL HAPPENING. Or again. Or something.
Jul 7 2018
Awesome. Let's consolidate the non-sidebar stuff! A probably header one, a probably footer one, anything else? I'm thinking those two will be the most common - header for global stuff, footer for, well, extra footer stuff. Possibly also global, but we don't actually care HOW folks use them as long as it serves the likely cases in some way...?
I feel like that last paragraph should be a bug all on its own.
New idea: consistentify HasSomeColours/Splash/etc global project navigation into a general cross-skin thing they all pull on to render, use same approach here.