TemplateStyles should be able to add skin-specific CSS
Closed, ResolvedPublic

Assigned To
Authored By
Jc86035
Jun 18 2018, 4:24 PM
Referenced Files
None
Tokens
"Piece of Eight" token, awarded by RandomDSdevel."Yellow Medal" token, awarded by Jdlrobson."Orange Medal" token, awarded by Krinkle."Pterodactyl" token, awarded by Effeietsanders."Like" token, awarded by stjn."Like" token, awarded by MartinK.

Description

@MartinK: "Skin-specific CSS classes (e.g. .skin-vector) are attributes of the body element, while TemplateStyles prefixes all selctors with .mw-parser-output and therefore has only access to the content of the page." Being able to style content for only some skins without resorting to site CSS would be nice.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

This would be good for improving mobile support for Wiki Loves Monuments, which begins at the start of September. @Tgr thinks he can work on this soon, sometime after Wikimania, and that we could get it deployed by then.

Deskana raised the priority of this task from Low to Medium.Jul 18 2018, 2:14 PM

Hello,

I'd like to propose a new attribute "skins" for templatestyles. For example:

<templatestyles skins="monobook vector" src="Template:Foo/styles.css" />

Instead of prefixing ".mw-parser-output" only, this generates styles prefixed by "body.skin-xxx .mw-parser-output", where the "xxx" is a real skin name. For example:

body.skin-monobook .mw-parser-output .style-one {
  // blah blah
}

body.skin-vector .mw-parser-output .style-one {
  // blah blah
}

Since the "skin-xxx" class already exists in <body> tag, this solution requires minimal changes to the extension and no core change is needed.

I'd like to propose a new attribute "skins" for templatestyles. For example:

If you look above, that was already suggested. But the solution proposed in T197617#4298242 was determined to be superior and is likely what will be done.

I'd like to propose a new attribute "skins" for templatestyles. For example:

If you look above, that was already suggested. But the solution proposed in T197617#4298242 was determined to be superior and is likely what will be done.

You are right. I didn't notice that part of discussion until you reminded.

@Tgr @Deskana Just as a quick reminder: We talked about this task on Wikimania. And both of you agreed, that it should be possible to implement and deploy it by mid August, so that is ready to use for this years WLM campaign (starting end of this month).

So, hows the implementation going? Do you need any input from our side?

TemplateStyles was deployed everywhere today as planned (yay!) so I'm hopeful @Tgr should have some time to work on this now as planned?

@Deskana @Tgr
+1 to yay! for TemplateStyles being deployed everywhere as of today :)

Change 452049 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[css-sanitizer@master] Add hoisting option to StyleRuleSanitizer selector handling

https://gerrit.wikimedia.org/r/452049

Hey there. I ran into this exact need while working on T202024. My selector targeting skin-minerva in https://en.wikipedia.org/wiki/Template:Afd-merge_to/styles.css currently doesn't work and I don't think its right to add this rule into Minerva itself given the low usage of the template.

Recognize .skin-foo as the first simple selector in a selector (with more than one simple selector), and insert the .mw-parser-output after it instead of before it.

+2 for doing this.

Something like <templatestyles src="..." skin="vector" /> would easy to do without hacking css-sanitizer. Less flexible though.

This also sounds great.

Is https://gerrit.wikimedia.org/r/452049 still the solution we're going with and do we have any idea when this might land?

@Tgr: Any plans, when this is going to be deployed.
As I told you on Wikimania. We need this feature for the LandingPages of this years WLM-Campaigns - starting in little more than a week now.

@Tgr: Any plans, when this is going to be deployed.
As I told you on Wikimania. We need this feature for the LandingPages of this years WLM-Campaigns - starting in little more than a week now.

There's a lot of competing priorities and vacations all happening at once here, sadly. @ggellerman and I are trying to get some answers on engineer availability.

I can't stress enough that it's really important to be able to use this feature right from the beginning of the campaign on. We had a significant slump in contributors last year, which, according to our analysis, can also be attributed to the inadequate optimization for the increasing proportion of mobile users.

I can't stress enough that it's really important to be able to use this feature right from the beginning of the campaign on. We had a significant slump in contributors last year, which, according to our analysis, can also be attributed to the inadequate optimization for the increasing proportion of mobile users.

I understand. I've passed on the importance and priority of this task on to the engineering managers. The rest is, sadly, out of my hands.

Thanks for passing it on, @Deskana . Please note that also a negative reply, is a response. But if it has to be negative, better have it sooner than later :)

We were counting on this being ready well in time. Realistically, we will soon have to pull out emergency contingencies to create alternative pages - which requires building a global template and then need tweaking to national level, translations etc. (countries are already switching to other structures as we speak)

Off topic: @MartinK i am curious if you are targeting mobile why using media queries (which is currently supported) is not an option. Can you elaborate? Skin specific styles would only be necessary for design consistency e.g. changing backgrounds. I'm really curious and would love to help you with preparing that campaign if I can. Feel free to ping me on wiki (user:jdlrobson).

@MartinK we are aiming to get this in place by Monday.

Change 452049 merged by jenkins-bot:
[css-sanitizer@master] Add hoisting option to StyleRuleSanitizer selector handling

https://gerrit.wikimedia.org/r/452049

Change 455221 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/vendor@master] Update wikimedia/css-sanitizer to 2.0.0

https://gerrit.wikimedia.org/r/455221

Change 455223 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/TemplateStyles@master] Hoist selectors for html and body element

https://gerrit.wikimedia.org/r/455223

@Jdlrobson The problem is, that with MediaQueries react to the viewport width - not to the width of the content column. The very same viewport-width can result in totally different content widths, depending on the skin, the content lives in.

  • In Minerva e.g. the content column is limited but fills up the full viewport on smaller devices.
  • In Vector the content column floats to infinit but has to share its space with the side column
  • In Timeless there are to side-columns and a max-width
  • etc.

So for a really good working layout, one needs to know, which skin one is in.

Change 455221 merged by jenkins-bot:
[mediawiki/vendor@master] Update wikimedia/css-sanitizer to 2.0.0

https://gerrit.wikimedia.org/r/455221

Change 455223 merged by jenkins-bot:
[mediawiki/extensions/TemplateStyles@master] Hoist selectors for html and body element

https://gerrit.wikimedia.org/r/455223

Tgr claimed this task.

@MartinK this will be deployed with this week's train (ie. on Commons by end of Wednesday, on Wikipedias by end of Thursday). Please reopen if that's too late and we'll arrange for a SWAT deploy.

@Tgr Thanks for the implementation. It would be good ta have it deployed on Commons asap, because we also need some time to build and test the landing pages - that need to be ready on Thursday evening latest.

Change 455770 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/vendor@wmf/1.32.0-wmf.18] Update wikimedia/css-sanitizer to 2.0.0

https://gerrit.wikimedia.org/r/455770

Change 455771 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/TemplateStyles@wmf/1.32.0-wmf.18] Hoist selectors for html and body element

https://gerrit.wikimedia.org/r/455771

Change 455770 merged by jenkins-bot:
[mediawiki/vendor@wmf/1.32.0-wmf.18] Update wikimedia/css-sanitizer to 2.0.0

https://gerrit.wikimedia.org/r/455770

Change 455771 merged by jenkins-bot:
[mediawiki/extensions/TemplateStyles@wmf/1.32.0-wmf.18] Hoist selectors for html and body element

https://gerrit.wikimedia.org/r/455771

Mentioned in SAL (#wikimedia-operations) [2018-08-28T12:31:37Z] <tgr@deploy1001> Synchronized php-1.32.0-wmf.18/vendor/: SWAT: [[gerrit|455770|Update wikimedia/css-sanitizer to 2.0.0 (T197617)]] (duration: 01m 16s)

Mentioned in SAL (#wikimedia-operations) [2018-08-28T12:34:36Z] <tgr@deploy1001> Synchronized php-1.32.0-wmf.18/extensions/TemplateStyles/: SWAT: [[gerrit:455771|Hoist selectors for html and body element (T197617)]] (duration: 00m 48s)

I added some documentation on mediawiki.org here and here. Improvements welcome.

Just checked it on de.Wiki and it seems to be working.
@Tgr Thanks for the express delivery!

@MartinK thanks for clarifying. Yeh unfortunately that is a problem that would need TemplateStyles, although I'd argue with the right media queries, changes could be applied that would be useful for both mobile and tablet. IMO, we should be assuming that content will take up the full width of the screen and adding media queries for > 720px (tablet) to account for menus.

@Tgr @Anomie and @Deskana thanks so much for prioritising this. It's also been very useful for the Page-Issue-Warnings project!

@Jdlrobson Glad to hear that this is useful!

In addition to @Tgr @Anomie and @Deskana, others involved in making this happen on time for WLM were @dr0ptp4kt @Jhernandez @Fjalapeno @Legoktm @Jdforrester-WMF and @Catrope. Many thanks!

A thing @Shizhao has voiced concern about is the data overhead caused by "unconditional" loads as opposed to skin attribute-defined loads, per https://zh.wikipedia.org/wiki/Wikipedia_talk:%E9%A6%96%E9%A1%B5/styles.css. This might be the rationale behind T197617#4439270.

Not looking for any more changes here, just figured that it would be good to add a side note here. TemplateStyles, after all, is not supposed to map to all of the MediaWiki stylesheets…

OTOH, having a 'skin' attribute would mean we'd have to fragment the parser cache by skin, which would be a different kind of overhead.