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

I support unifying search to be consistent with the other header dropdowns, but what do you envision for the toolbar dropdown? The toolbar matches the content background color because it's within the content area and distinct from sitewide actions like navigation, search, etc.

@SamanthaNguyen I think that may be more trouble than it's worth. It'd require a new font and quite a bit of PHP changes to create icons for what's just a fallback.

For me there doesn't seem to be a significant difference in loading speed between Refreshed and Vector. That goes for Chrome and Safari. @LegoFan4000 what browser are you using? OS shouldn't matter except for the fact that Safari is only available on Mac.

On Safari 9.1 (OS X 10.11.4), the font doesn't render at all. Nothing shows up, not even emoji.