eevee

imagine a world with:

• mathjax ($$\frac{1}{2}$$) so i can mathpost about math and have nice fractions. mostly it's about the fractions. though i'm absolutely the kind of fox who would write $$x$$ every time i mention a variable. which is helpful when talking about $$a$$ or $$i$$ actually

• maybe mathml too why not. or instead of. i'm not sure. but it's good and gecko has supported it for decades and i think it deserves some recognition for that in the form of me writing math posts that are only readable in firefox

• inline svg so i can also plot a graph and/or do even worse animation crimes. i feel like 84% confident that this should not create any new Problems — svg is already allowed as an image format, inline svg is contained within its box, and without scripting you can't do anything especially heinous. some power is lost without being able to use ids to do references but maybe that works with some id-rewriting similar to what is described below (although you would also have to ferret out url(#...) and rewrite those too)

• inline <style> tags. no listen hear me out. i've handwaved this before but i think it is eminently doable:

  1. give every post an id like post1234

  2. so, you have to parse the html in post contents to do a tag whitelist anyway, right. (although it occurs to me, maybe you're only doing that once on store and not in the post rendering every time? but i believe post rendering is client-side, so you could still do these transformations by letting the browser do the parsing in a DocumentFragment and then fussing around before injecting the post — a DocumentFragment can't apply stylesheets yet since it doesn't even know where it's going to end up.)

     but the idea is, while you're at it, look for class attributes and prefix every class in them with post1234- to prevent hijacking cohost classes

  3. also while you're at it, you're parsing <style> tags, right. the whitelister can throw out anything that is NOT a simple unnested property block with selectors built from tag names, class selectors, ,>+~, and basic pseudos like ::before and :first-child and :hover (!). you already have a whitelister for sequences of properties which is basically what the contents of every block are so that's not a problem.

     you could even allow variables here since they're scoped to the dom tree. i know they were disabled because they allowed circumventing restrictions on values of certain properties, but if we had stylesheets then it would be kind of a shame to not also have variables. it could be feasible to restore them but simply forbid using them at all within properties like position? i don't know if they could do any mischief elsewhere that you couldn't just do by writing a regular property, but i also haven't thought about this too hard

     you have to parse the selectors to make sure they're acceptable, so while you're in there you can rewrite any class selectors to have the post1234- prefix, and also prefix each of the selector chains with #post1234 .prose. (the existing selectors would have to be non-empty to be valid, so selecting the prose container itself should not be possible.)

  and tada you're done and we can write posts using classes that can't escape to affect the rest of the page. we can also use :hover and :active to make stuff a little more interactable! i think this would be good and also make cohost function a bit more as a practical way for folks to dip their toes into web design, since "paste everything into the style attribute every time" is not exactly recommended practice

  it might also be nice to have @media, even if only for prefers-reduced-motion, but this adds effectively another parser. but offhand i can't think of much that @media might be used for nefariously since all it does is conditionally enable blocks. i guess you could use it to skim some computery demographics, but you can already capture IPs if you know how, so getting screen resolutions doesn't seem too dire.

  another obvious candidate is @keyframes. that should be doable but it's a little bit finnicky — you'd want to prefix the animation names too, which means identifying where the animation names are within the css, which is a bit murkier

  this is a lot of bits of things to parse but i think you can reasonably insist on being conservative here and not trying to handle nonsense like :is() safely

  this is probably all fairly obvious to anyone who already plugged in an html/css whitelister but i wanted to write it out because it feels exciting

• also it would be nice if images (+ other media) were just expanded into a somewhat broader notion of "attachments" that exist independently of being part of the default image grid, so i could stick them in the middle of a post without either hosting offsite or relying on the lack of upload garbage collection. i feel like most of the effort here might even just be ui for files that are attached but not shown by default

• given all this, "view source" for posts would definitely be helpful as a learning tool i'd think

thanks. thanks everyone