I broke it again. It looks like the edit filters didn't catch problems with CSS. This probably needs a Flow dev to fix. I'll see if I can find the edit filter that was supposed to stop this.
Topic on Talk:Structured Discussions
Looks like mw: doesn't have the CSS edit filter. on enwp it's Special:AbuseFilter/56 but links to enwp don't show up for some reason.
Here's a link to the history file incase that helps.
https://www.mediawiki.org/w/index.php?title=Talk:Sandbox&action=board-history
The problem is Flow doesn't currently have abusefilter set up, to boot. It's on our list of things-we-should-do-before-deploying to enwp, I think (User:Maryana (WMF), was that resolved? In which direction?)
Okeyes (WMF): It's not in our current sprint but will definitely be high priority in the next one, which means it should be done at or a few days after the 1st release to enwp.
Maryana (WMF): yay!
@Okeyes (WMF): and @Maryana (WMF): thanks for the update. The CSS bug is not a big deal on normal talk pages because those edits can easily be undone by simply clicking "undo" from the history file. But on the new Flow talk pages there is no "undo", so this is more of a problem. A mailcious user can use this bug to stop most other users from using a Flow talk page. Of course, technical users can get around this. Thanks for looking in to it.
Maryana (WMF): Please, not " it should be done at or a few days after the 1st release to enwp.", but before it.
Fram: The CSS issue is being fixed separately. We already filter for other malicious code injection. The only thing that leaves is spam and overt vandalism; given that Flow will only be live on 3-4 talk pages that are monitored by experienced users, I don't see an absolute need to have AbuseFilter integration before launch. We know that edits triggering AF are extremely rare in the talk namespace (only ~150 per day across all talk pages on English Wikipedia). So while this is still important to have sooner than later, it's not a blocker for a limited release.
Okeyes (WMF): Why do level 3 comments show up in significantly smaller text? It *really* deemphasizes them. They're already indendented; do we want to make them even harder to read? So proud of your work on this, all of you!
Ocaasi: hmn; it's not significantly smaller to me (can you email me a screenshot?) although it is smaller. I think the designers might be doing some work in this area - Maryana will know better than I.
Ocaasi: ta :). Yeah, that is smaller: it looks okay to me, but we probably shouldn't base font size on 'what works for one staffer'. Hopefully M will have an update.
Ocaasi: We're experimenting with different ways to structure the information hierarchy of topics, posts, and replies. The smaller size of the second level of nesting was meant to encourage people to stick to talking about the topic, not go off on tangents – discussions on StackExchange sites work similarly to minimize ((literally and figuratively) back-chatting.
In practice, I notice there's confusion among users as to which level to reply to (I find myself confused, too, honestly), so this system may need rethinking. But that's why we put stuff out there early for people to play with and test in a real-ish setting :)
Maryana (WMF): "stick to talking about the topic, not go off on tangents" is one way of looking at it. Voting instead of discussing is what you'll probably get in reality, if you don't want people responding to each other but only to the initial post. Please seriously reconsider this, I haven't seen any regular editor asking for no indented replies or anyone actually applauding the only one indentation level. Some limit or technical solution, OK (although there is still half a screen to the right for more indentation), but not this or anything similar to it, and certainly not for this reason.