Okay good enough done.

Why is there no firstheading? Even on skins where nothing breaks as a result of it not being there, it's still a bit confusing and sometimes looks quite... odd.

There are separate styles for MobileFrontend, but... while those use space far more efficiently than the desktop styles, I understand they may also be missing some tools/affordances, and there's no reason not to expand to use the space if it is there (tablets, for instance, or someone loaded the mobile site on desktop/is using it for some other reason than just mobile).

I feel like we could also just resolve this by dropping IE9 support.

:DDD

This was... basically done. At some point.

In T245476#5897501, @Esanders wrote:

I would rather we kept the same font-size between the various wikitext editors for now. There may be a case to increase it for serif, but that will affect a very small number of users who ever change that preference.

Also most of these aren't even tables... why in the world would you css-spoof tables and make them worse than real tables?!

Right, so I was looking into this to see if the generalised 'tables don't fit on page' solution would maybe apply here. But these tables (and their classes/ids/surrounding DOM) are insane. I really can't apply this to wikidata, as is.

But ghah if we just had something more like that in general that really would solve so many problems, huh.

Like, even if that actually is done in the wikibase extensions themselves (as in, it's not just a MF hack), why in the world isn't it just switching to those styles on breakpoints? And why are the desktop ones so... only functional on really wide layouts?

That's... not responsive, though. That's just totally different styles if you're using mobilefrontend...

Like I could put some hacks in timeless to make it sort of work, but if wikibase ever finds its pants and starts acting sane and not putting margins of ~20em on either side of all the statement values, for instance, it's just gonna break at that point.

So this seems... less bad than it was when filed, but for the remaining stuff, I'm inclined to put this down as just a general responsiveness problem with Wikidata/WikiBase in general... like what does it even do on mobile at all, for instance?

This solution is good, but we do need to actually migrate all the skins. Now that more of them are actually done, though, we have some decent examples so that should be more feasible than some of these changes have been, in terms of figuring out what to do with them.

In theory this should now be resolved (though not deployed anywhere). I haven't actually tested it.

I think we fixed this with the other one? I can no longer replicate it...

Do you have a link to some example usage?

Yeah, there's not going to be a fix-all here. Plenty of sites just have longer names that absolutely need to wrap (see meta as a somewhat silly example), whereas others won't want it, or will want different handling entirely. Basically, it's kind of on the site to make sure things come out optimally, either by:

• Setting some custom css in the wiki's Timeless.css, such as no-wrap in this case where it actually does make sense
• Using a wordmark image for the logo that's tailored to this size and placement (also good for other skins like Minerva anyway, such as if you're using MF) via $wgLogos['wordmark']
• Setting a different display string via changing the contents of the timeless-sitetitle message

It's not a Timeless-problem, but I'm also not really sure what project to add as there don't... appear to be any for skinning in general?

It appears to be caused by some of this stuff:

We need some js to make all tables pop out if they don't fit, no matter the resolution, as an up-to-full-wdith side-to-side thing with a scrollbar if needed.

I'ma call this basically done, as it's at least responsive, even if it's still missing a bunch of uuuh slightly more fancy proper support. Whatever. Tasks for specifics should be separate anyway.

To be fair, that it's part of a general problem probably makes this a bit more pressing anyway. Maybe the task as a whole should be updated to reflect that?

In this particular case calling $this->get('footericons') is all that should be needed to read the data. Whenever you call getFooterIcons('icononly') you are recreating data to return the value of $this->get('footericons') inefficiently. Updating to use footericons is in the skin's best interest to avoid this.

Whooo thanks!

In T267447#6638443, @Jdlrobson wrote:

BaseTemplate::getFooterIcons is being hard deprecated NOT SkinTemplate::getFooterIcons, which is the subject of this task.

What about all the other skins that use it? Namely, er, nearly all of them?

@ashley did some digging and found cd54c03e86e6a2a0caa6c6943b22dfa052e874bd, which appears to be responsible.

I'm just going to close this, as the task really doesn't make a whole lot of sense. It's basically 'let's deprecate these styles and move them into <the only four skins that don't use the styles> because of <reasons that range from just confusing to very important, where we definitely want to make sure that if this is fixed, all the skins using it get these fixes>'.

All those link styles seem not be a useful part of core, it's an additional aesthetical choice, better located on a per skin-base.

The reason why this is a module in core is that it isn't particularly skin-specific. The module is called from twenty different skins in gerrit alone (who knows how many others also use it out in the wild), and Vector, Modern, and MinervaNeue, and Example are the main skins that don't use it as they either just have their own styles for this, or don't use any.

Whoop!

Okay, that was a guess on the correct projects, I don't know.

This isn't Timeless; it looks like the styles for properly positioning the toggle icons are just only in Minerva instead of in MF or something.

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...)

In T259240#6382465, @Iniquity wrote:

@alexhollender Thank! I now understand your thoughts :) But in any case, it seems to me that this is a bad decision. You can indent with some graphic elements at the logo level.

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...

Look, as long as it works, I'm fine with any sane default. :P

Is now... normal.

Probably didn't get all of them, but whatever.

:DDDD

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.

Definitely added.

Wow, this was vague.

Nope! I don't know!

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.

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.

\o/