—crossposting doesn't change here right? Since we just render that out as HTML and pass it raw to the target site and ask them not to mangle it.
Yes, exactly!! Now that we're pre-rendering everything and force-setting opt_preformatted at the destination (instead of trying to work within a foreign version of casual html), we're home-free no matter WHAT we do. As long as we're:
- Able to render non-broken HTML for our own site - Translating things that DO directly correspond to magic LJ markup (right now that's just @mentions, but if we ever made a shorthand syntax for e.g. cut tags we'd want to handle that too)
...then crossposting stays fine.
Ultimately tho, it doesn't look like this will really _change_ user behavior/experience? They will see a new dropdown/UI change that lets them explicitly select their formatting—
That's my hope, yeah — the user side of this should just feel like we replaced the "don't autoformat" checkbox with an easier-to-understand dropdown. The only complex bits from the user perspective are:
- How we set user defaults (cf. above).
- The combination of "current format affects editor controls" and "RTE is just another format". This makes perfect sense to me, but if we, e.g., ended up with an RTE that had its own integrated "view source" mode, we could end up in a nested hierarchy, where I chose rich formatting but I'm viewing/editing HTML code as part of the implementation of "rich." Which I think I don't actually have a problem with, but it might be worth thinking through those contradictions.
- How we handle obsolescence of formats. (The "but I liked the old way" effect -- would we want to offer a backdoor way to keep your default locked to a hidden format? So far the consensus of staff and volunteers sounds like "no." I'm inclined to agree.)
(—possibly we can just use CSP or such to block [scripts] by policy and then simplify? I suppose this doesn't fix a lot of the "HTML fixing" we do though—)
Word. IMO the security part of CleanHTML contributes a lot to its gnarliness, so even if the text transformation part is always going to have to happen somewhere, it'd still be super cool to make the security part more modern and concise. But when it comes to XSS security, gotta admit that I'm Baby, so I don't have a useful contribution there yet.
no subject
Yes, exactly!! Now that we're pre-rendering everything and force-setting opt_preformatted at the destination (instead of trying to work within a foreign version of casual html), we're home-free no matter WHAT we do. As long as we're:
- Able to render non-broken HTML for our own site
- Translating things that DO directly correspond to magic LJ markup (right now that's just @mentions, but if we ever made a shorthand syntax for e.g. cut tags we'd want to handle that too)
...then crossposting stays fine.
That's my hope, yeah — the user side of this should just feel like we replaced the "don't autoformat" checkbox with an easier-to-understand dropdown. The only complex bits from the user perspective are:
- How we set user defaults (cf. above).
- The combination of "current format affects editor controls" and "RTE is just another format". This makes perfect sense to me, but if we, e.g., ended up with an RTE that had its own integrated "view source" mode, we could end up in a nested hierarchy, where I chose rich formatting but I'm viewing/editing HTML code as part of the implementation of "rich." Which I think I don't actually have a problem with, but it might be worth thinking through those contradictions.
- How we handle obsolescence of formats. (The "but I liked the old way" effect -- would we want to offer a backdoor way to keep your default locked to a hidden format? So far the consensus of staff and volunteers sounds like "no." I'm inclined to agree.)
Word. IMO the security part of CleanHTML contributes a lot to its gnarliness, so even if the text transformation part is always going to have to happen somewhere, it'd still be super cool to make the security part more modern and concise. But when it comes to XSS security, gotta admit that I'm Baby, so I don't have a useful contribution there yet.