I'm marking this as declined. A new major release (which also doesn't have collapsible sections) has come out since this issue was first made, and since then I haven't heard requests for collapsible sections. If anyone is still interested in this, please resubmit as a new issue.

Marking as resolved. As of https://phabricator.wikimedia.org/R1893:68dd17bbabb00ed49f92edde3b4da86547e7fab8, the skin prioritizes $wgLogos['wordmark'] above MediaWiki:Refreshed-this-wiki-wordmark and $wgLogos['icon'] above MediaWiki:Refreshed-this-wiki-mobile-logo.

This issue should be resolved as of this commit: https://phabricator.wikimedia.org/R1893:0ad6616423acf536af8fb8bf4466a353485e8ceb.

Marking as resolved as the dropdown is now accessible through tab focus. Any future issues regarding the more button or tab focus can be placed in a new issue.

Thanks @ashley and @SamanthaNguyen! This issue should be resolved as of version 2.2.1.

Wow, thank you for the quick response! I did some digging and found the issue is related to the change in $wgResourceModules as described here:

@ashley Do you have thoughts on this?

I submitted the relevant patch to VisualEditor: https://gerrit.wikimedia.org/r/#/c/584037/. I think the patch won't necessarily help you though, since you're on an older version of MW. If you take the version of ve.init.mw.DesktopArticle_target.init.js from that patch and move it into your own copy of VisualEditor, it should work fine.

@matmarex Thank you! I just submitted a patch for review.

Hi Lachlan,

Interesting. I'm limited to testing on iOS, but it's worked for me on both Safari and Firefox. By any chance do you have JS disabled? It looks like the Flat Earth Wiki hasn't upgraded their skin for a while, so if search suggestions recently stopped working on your phone it may be a setting on your end.

@SamanthaNguyen Thanks! Sounds good. Good luck in your future non-MW endeavors!

Since a major (breaking) release just came out, it's a good time to commit to a convention. Refreshed 4 is now free of Brickimedia-specific logos, etc. so my concern raised above is no longer relevant. Since nobody else has chimed in in over 3 years, let's stick with the convention proposed by @SamanthaNguyen and close this.

I kept RTL in mind during Refreshed 4 development. My testing hasn't yielded any issues. I'm closing this for now, but if specific RTL issues come up feel free to make a new issue.

Done as of Refreshed 4!

Updated the docs for the v4 release. Suggestions would be appreciated!

@Mj0730 Does this still occur in Refreshed 4?

Closing--in 4.0.0, each item in the dropdown has an icon (ignoring any additional items from extensions).

This should no longer be an issue as of Refreshed 4.

Done as of Refreshed 4!

As of Refreshed 4, the watch button is no longer inside a dropdown, so I think this issue is resolved. Feel free to reopen it if you have more thoughts.

Closing since Refreshed 4 resolves T142157.

Closing--Lato is not included in Refreshed 4.

Closing as of the Refreshed 4 release, which should address most if not all of these points. Feel free to submit further suggestions as a new issue.

Closing--Refreshed 4 uses inline OOUI SVGs.

Resolved in Refreshed 4!

@lachlan Hi! This may be resolved in Refreshed 4. Is it occurring on BS01? Also, if you upgrade Coasterpedia to Refreshed 4 and it's still an issue, please let us know.

Released!

Ok I think it's ready! https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/Refreshed/+/561788/-1..2

It's been a while since I've provided an update. Sorry about that. The skin has been used on BS01 for several months with no issues. I'm going to make one more substantive change, which is adding an empty LESS file so that users can customize Refreshed with actual LESS without installing Extension:Theme. Then I'll update the docs, and I think Refreshed 4 will be ready!

Ah sorry yes, I should have thought that through further. Installing themes on a per-wiki basis would not scale well, I agree. (Too used to working on a small site I guess!)

Implementing SkinLessVariablesImportPaths would be valuable for Theme (https://www.mediawiki.org/wiki/Extension:Theme). For example, v4 of the Refreshed skin relies heavily on a custom set of LESS mixins. If Refreshed could give extensions easy access to those mixins through ResourceLoader, writing custom themes for Refreshed would be much easier.

Bumping this. Could the extension be redone so themes can be defined on the wiki itself using CSS subpages? For example, a green Vector theme could be defined MediaWiki:Vector.css/theme-Green. This would make theme maintenance easier.

In v4 (currently on the refreshed4-beta branch) the default text is vertically centered and has no border. It is not written in Lato either, since Lato has been removed from the skin. Since that seems to cover the issues above, I'm marking this as resolved.

Dropdowns and the mobile sidebar work without JS in the refreshed4-beta branch, so closing.

I believe both parts of this task are resolved in the refreshed4-beta branch as of 488f4149ab7a.

Marking as declined since we're not using the variable. The breakpoint between small and medium was adjusted in 488f4149ab7a.

The variable listed is now deprecated. Regardless, I think we should choose the breakpoints between Refreshed's views ourselves, since we can fine tune the skin better if we have that freedom. I do agree the current small/medium breakpoint is too small though.

As of the latest commit (R1893:cb09065e1d63019e2413eb807d9960fd99e1bd22), the toolbox has been redone with separate toolboxes for page actions and user actions. However those toolboxes aren't yet optimized on smaller screens. See the screenshots below:

This would be a good task to include in T200303, so if anyone wants to contribute for Google Code-in, consider working on the refreshed4-beta branch. Thank you!

This would be a good task to include in T200303, so if anyone wants to contribute for Google Code-in, consider working on the refreshed4-beta branch. Thank you!

I've found a pure CSS way to replace the header category buttons with the explore button when the viewport is too narrow for all the header category buttons. It's not perfect though. When the buttons get replaced, any open dropdown trays stay open. So there are ghost dropdown trays floating there without the buttons they're attached to. I think we'll need JS to avoid that.

Switched to click dropdowns as of the latest commit.

After some more thought/testing I think we should stick with dropdowns triggered by click rather than hover.

Cool, sounds like a plan then. I made the refreshed4-beta branch, we can start work there.

Closing per T155083#4447180.

Alright, thanks for the quick response! :) I'll close T200250 now and try things out with inline SVGs.

See T200250

Bump. There's possible overlap with T134851 if we decide to completely re-design the dropdowns so they don't use JS.

There's potential overlap with T134851 if we decide to completely re-design the dropdown menus without JS.

Yeah imo that'd be a good thing to look into. Maybe if we implement hover dropdowns we could use the checkbox hack as well to cover our bases for mobile?

@SamanthaNguyen @ashley Personally I wouldn't mind it if the dropdowns opened on hover, would you? Of course this would cause issues on mobile. How should we go forward?

This is resolved no?

The proposed CSS from earlier would trigger the dropdowns on hover, as opposed to on click.

Actually it looks like the rowspan is only being incremented twice the very first time a user posts. I think that's because the default rowspan is 1, not 0. So when the user posts the first time, the rowspan starts at 1 (the default) but gets incremented to 2. It's not actually being incremented twice, it just looks that way because we've been thinking of the initial rowspan as 0, not 1. From then on, every time the user submits another "child message," the rowspan of the "parent message" is incremented by 1 as expected. This means the rowspan is always 1 greater than it should be. This throws off the formatting once another user posts. Thanks to that extra bit of rowspan, the (now) previous user's username and avatar occupy the first columns of the new user's first message, where the new user's username and avatar would normally go. This pushes the new user's username and avatar over to the right, which in turn pushes the new user's messages over to the right. This compounds as more and more users post.

Is this patch in use on https://social-tools.wmflabs.org? The rowspans are still being incremented twice as much as they should be on there, and that still seems to be the cause of the broken formatting.

That looks good to me, go for it. (BTW interesting styling you've done to the skin, it gives a Vector vibe.)

@SamanthaNguyen Having some issues leaving responses to your line comments (they save as drafts--I guess I need to do another code review for them to actually show up?) Anyway...

@SamanthaNguyen Those names would work for me. Implementation seems fairly straightforward, so I'll try handling it.

This features requested in this task fall outside the scope of the Refreshed skin.

@SamanthaNguyen In brief--all good points. You've turned me. :P

@SamanthaNguyen The avatars would not be configurable by the user, only by sysops who could edit the system messages where each group's avatar is listed. As such new special pages and new user rights wouldn't be necessary. It's basically replacing the current WikiFont icons for logged in and anon users with something slightly more customizable by the staff, not by normal users.

@SamanthaNguyen If nothing else, I think Refreshed itself should provide a way to override the two icons that are baked into the skin. It'd be pretty straightforward if we made two system messages, one for the URL of the anon image and one for the logged-in image. The height of those images would default to the height of the sidebar but could be customized with on-site CSS. Thoughts?

@SamanthaNguyen Thanks for the notice, I incremented the version number per T143368.

EDIT:
Heh, ninja'd. I'll reply in a bit :)

@SamanthaNguyen Thanks for the info! I went ahead and pushed a commit to fix this issue.

Seems fine to me.

Currently Refreshed just runs a hook to pull all the page content, no? This would require a fair bit more processing than is done currently, since the skin would have to wrap the content under each h2 in some kind of container element. MobileFrontend might provide some clues on how to do it. That said, Minerva (the MobileFrontend skin) is built very differently than Refreshed--lots of disparate PHP and Mustache files. It'd require some digging through the skin files to figure out where the sectioning is done.

All the changes you recommended sound good.

Not sure the best way to implement this. I noticed Wikimedia's log in links changed a while ago, was that due to a change in the software or a local change?

Sounds good.

Sorry, I read this a while ago but I guess I never responded. Sounds good.

Maybe a warning isn't the most elegant solution, but it's better than the alternative of no warning that we have currently. Another thing to consider is that the people installing skins on MediaWiki are probably people comfortable with a couple of extra installation steps.

Oh yeah that'd be fine. That stack was based on the one planned for the MediaWiki typography refresh, but in the end it wasn't used and plain old sans-serif was used instead.

That sounds good, yes.

I support this. Should the default header font-family be the same as the current body scheme ("Helvetica Neue","Helvetica","Arial",sans-serif) or should it match Vector's header ("Linux Libertine",Georgia,Times,serif)?