the current definition of `font-variant-emoji´ simply implicitly adds a V·S·15 or V·S·16 after emoji characters which can take them. this is definitely the least useful possible interpretation of `font-variant-emoji´. if i `font-variant-emoji: text´, i would like NO emoji characters to be given emoji presentation, not “only emoji characters which were not {already encoded codepoints at time of encoding and thus prone to possible awkward re·presentations in pre·existing encoded texts}”
@alyssa have you watched tale of princess kaguya
@aescling do you pronounce “qualify” as “quay lifi” or something
@aschmitz i’m not trying to argue plugins were stellar, but i am trying to make an argument about where labour was being allocated. part of the reason why plugins were buggy / inaccessible / etc was certainly that the Netscape Plugin API was, or soon became, legacy unmaintained code, and there was no interest in improving it or replacing it with something better. some responsibility lies with Adobe and other plugin authors too, definitely, but browser manufacturers also failed to work with them to improve the situation and instead decided to work among themselves to make the situation obsolete.
i like WebAssembly, think it opens a lot of doors, and am not saying we should go back. but there was a pretty long period between when iOS Safari shipped and when WebAssembly became reasonably capable of running entire applications in-browser. and we’re still working on solving some of the same accessibility issues there.
i do think things could have taken a different path if the interest wasn’t so strongly in keeping the internet in the hands of standards bodies that browser developers controlled.
@aschmitz i think it’s not that “web browsers just got so good that nobody would ever want to write a plugin”; PDF rendering in browsers basically began as a kind of plugin; there has been persistent interest from users in native support for things like EPUB; people are writing entire games and applications in WebAssembly and shipping them to browsers and i’m sure that things like a PICO‐8 plugin would have interest in a different world where browsers were differently architectured. i don’t think the reason why we don’t have that world is because web browsers got too powerful, but because they made web browsers just powerful enough that they could get away with killing it
@aschmitz i think this is reversing history though; there was an alternate timeline where browsers leaned hard into XML and relied heavily on plugins for supporting namespaces and elements which they didn’t straight out of the box. Opera/Mozilla/Apple didn’t like this future because it reduced their power as The Browser Manufacturers and consequently shut down not only plugins but also technologies like XForms in favour of doing everything in plain HTML and Javascript. Apple refused to support plugins in iOS Safari, forcing adoption of HTML5, and the refusal of browser manufacturers to invest in good extensibility mechanisms led to HTML always being the winning solution, especially after the removal of legacy browser extensions in Mozilla (which were a kind of plugin in their own right).
re: united states politics
@aescling yes they are not suggesting the democrats do not field a candidate
(please don’t put “i filed a bug report on GNOME GitLab” on your resume; save that for the interview)
if i were hiring for a position i would rank someone with an account on GNOME GitLab who only submitted a couple of issues above someone with a GitHub account with 2000 commits and 30 pull requests merged
i do not care about your github stats
in fact i care substantially more about how many repositories you have contributed to that are NOT on github
Administrator / Public Relations for GlitchCat. Not actually glitchy, nor a cat. I wrote the rules for this instance.
“Constitutionally incapable of not going hard” — @aescling
“Fedi Cassandra” – @Satsuma
I HAVE EXPERIENCE IN THINGS. YOU CAN JUST @ ME.
I work for a library but I post about Zelda fanfiction.