Rikki

Google has strict guidelines about how their logo shows on social sign in buttons, so we're following those guidelines - in the past some customers received automated warnings that they were not compliant.

font-display: swap won't really give any benefit to that particular font since it's used for icons - there would be no system font it can use temporarily. We can certainly experiment with font-display: block and see if that would improve how lighthouse sees the page though.

I'm not familiar with how MathJAX works, but it sounds to me like you'd need a plugin that listens for our Javascript events to reinitialize content when the page updates.

You're likely thinking of Section 230, which makes users responsible for posted content, not the sites that host it. Understandably, removing that protection would be a significant problem for most small, independent communities.

It's a legend lost to time. We just keep them in case removing them releases a terrible curse.

Unless I'm misunderstanding your report, the email address you see is that of the user that is checking out - i.e., their own email address.

While TestFlight (and Android) allow you to submit feedback, honestly the best way is to submit a ticket in the usual way. Thank you!

CSS is flexible enough to allow you to do that without needing unique classnames. For example: .ipsType_richText a { color: red; }

It's under Customization -> Appearance -> Icons & Logos. As for push notifications, I'm not sure what our plans are on that.

We already have PWA support, though that doesn't include push notifications yet.

We are a way off of offering a white label service still - we plan to get the main app stable and add more functionality first. We'll post an announcement when we're ready to accept some interested sites 🙂

@opentype to the rescue 🙂

Thanks for the feedback; it sounds like a couple of the issues you noted are bugs, so we'll be able to address those as such. We've been upfront that firstly the app is in its early stages but also that it won't necessarily be ideal for every community. If you have a lot of customization (be it plugins or lots of custom pages) it's probably not going to be the best solution for you. We may devise a solution to that in future but right now it'll be focused on core 'out of the box' functionality. I'll lock this since you have struck out your first post, but I just wanted to address you

In 4.5 we've tried to keep headers consistent, so that buttons are where you expect them to be, there's space for additional buttons as each page/app might require, and so that each page/app can extend the data shown in the header without the whole thing breaking down. In 4.4, this was a problem - sure, on perfect example pages, the follow button worked well in the top right. But using a different app where more buttons need to be shown, or even just having a long topic title, suddenly it wasn't so pretty and usable. The new header is designed to be flexible and extensible according to require

We don't load (many) polyfills ourselves - they are included with libraries that we use. Those libraries will only execute them when needed, but the code is still sent to the browser since we bundle and minify javascript.