pfp by me
banner by https://twitter.com/spect_ion
did you see that cool bug?
| Pronouns | she/her |
| Website | https://wolf.girl.technology |
| Pronouns | she/her |
| Website | https://wolf.girl.technology |
notify crate which is documented to drop events on the floor<hr> or <img> that are "void elements" (https://stackoverflow.com/a/10599002)? Hardcoded list probably?div div > span, (anscestor then child) not div {} div > span (two separate rules). if you meant the example text to be the latter then i am ok with it. just avoiding ambiguity w/ how the rule is interpreted CSS-style :)@jyn i fear my original comment did not have as noble a thesis as you may have hoped: I was expressing a preference for "HTML template languages should operate on HTML text". however recalling some experiences doing that myself, you really do need entity escaping, so this doesn't quite work (e.x. https://github.com/p0lyw0lf/website/blob/8db2c0f8546773d7cf7dfb6bfd5407f86abf7189/src/runtime/remoteImage.js#L60 and also https://wolfgirl.dev/tags/blag/ is still broken lol)
I cut my teeth on React JSX, which does solve a lot of these escaping issues, at the cost of way too many {} and also those silly <></> fragments.
I have come around to appreciating these syntaxes because they (assumedly) handle the entity escaping issues, aren't very verbose, and map cleanly onto normal HTML ("can run the algorithm in your head"). I like A more than B just because it disallows > as an operator; I think it means a different thing in CSS, and if it did mean the same thing, non-local operators in a template language seems kinda wrong.
The "strings as bodies must be quoted" implying "unquoted things are elements" from B is nice tho, lets u work with webcomponents/not have a hardcoded list of HTML ones, so in a sense yes still C :)
Sunday, December 21st: I AM MY OWN PARABOLIC ANTENNA. TOSYA'S FACE IS:
Monday, December 22nd: ok back 2 normal :)
yeah ok wow very impressive game, impeccable soundtrack too, i like it a lot. Free on steam btw!!