Unfortunately XHTML5 doesn't exist and if you try to force the issue, you have to re-declare all of the non-numeric HTML entities in your own DTD (I abandoned the idea here). I'd love to use XHTML, its just not viable anymore.
As for generating all HTML, that's simply not possible given the current state (of open-source at least) WYSIWYG HTML editors.
I stopped using entities once we had UTF-8. I suppose there’s a case for the occasional < > but beyond that, I have no problem typing “‘—’” or üçě when I need to.
You can still just manipulate the official hardware to produce the image you desire, i.e. record a video that's projected onto a wall. And it'd be fairly easy to do with existing technology too.
I use OpenSUSE Tumbleweed, and I've never had trouble running a game that's rated gold or above. I've even gotten an Easy AntiCheat game to work correctly.
I've been gaming on linux exclusively for about 8 years now and have had very few issues running windows games. Sometimes the windows version, run through proton, runs better than the native port. I don't tend to be playing AAA games right after launch day, though. So it could be taste is affecting my experience.
And what happens when the licensing board gets politically compromised? You cant fix broken incentives by papering over another layer of administration. If the underlying incentives are opposed, the administration layer will be adapted to fit.
Civil engineering licensing works because underneath it all the incentive structure is aligned with the goals of the license. Its not about imposing morals, its about ensuring that buildings and devices are constructed to not fail, and to not fail catastrophically. The motivations of the ones who hire engineers are mostly aligned, they don't want the devices to fail either, and expose them to liability.
Medical doctor licensing also works because the incentives are mostly for patients not to be dying. But in the pharmaceuticals industry the incentive structure is different, where some rate of fatality is considered an acceptable cost of doing business, we see examples of subversion.
Sure software engineering licenses could be a great addition. But alone it will fail unless the incentive structure for those employing software engineers is aligned with the licensing goals.
Details works even when it's set display:contents too, for even more flexibility. Can't animate from open›close, yet, though. That's pretty much my last frustration with it.
I think the CSS support for that has finally landed, though it means targetting a pseudo element instead. Its been a year, so support is probably good enough you don't care if just the animation doesn't happen.
Note that the transition to `auto` in that post relies on `interpolate-size` which has yet to land on Firefox or Safari, and neither have movement right now.
The ones that Microsoft Apple and Google pay for, the codec licenses. FFmpeg believes that only end users need licenses for codecs, which is not only their belief, but it’s not a belief of Microsoft, Apple and Google, and it is true the sense of the status quo, but also, LGPL violations are a status quo. So you can see how it’s a bad idea for FFmpeg to make a stink about licenses.
I like to think of typescript, pycharm, and whatever consumes t-ruby as, effectively, type-directed linters. The types are advisory only at runtime, so the full power of the dynamic language can be used. But at compile time the type can be checked and verified (insofar as they correspond correctly to the types at runtime).
So the reason to add types to python/ruby is that switching to a statically typed language you lose power and expressiveness. But if you use a type-directed linter, you can prevent many of the common errors writing in a dynamic language.
I write scripts in rust as a replacement for bash. Its really quite good at it. Aside from perl, its the only scripting language that can directly make syscalls. Its got great libraries for: parsing, configuration management, and declarative CLIs built right into it.
Sure its a little more verbose than bash one-liners, but if you need any kind of error handling and recovery, its way more effective than bash and doesn't break when you switch platforms (i.e. mac/bsd utility incompatibilities with gnu utilities).
My only complaint would be that dealing with OsString is more difficult than necessary. Way to much of the stdlib encourages programmers to just do "non-utf8 paths don't exist" and panic/ignore when encountering one. (Not a malady exclusive to rust, but I wish they'd gotten it right)
Paths are hard because they usually look like printable text, but don't have to be text. POSIX filenames are octet strings not containing 0x2F or 0x00. They aren't required to contain any "printable" characters, or even be valid text in any particular encoding. Most of the Rust stdlib you're thinking of is for handling text strings, but paths aren't text strings. Python also has the same split between Pathlib paths & all other strings.
Yeah, the issue is that there are no utilities for manipulating OsStrings, like for splitting, regex matching, or formatting OsStrings/Paths.
For instance the popular `fd` utility can't actually see files containing malformed utf-8, so you can hide files from system administrators naively using those tools by just adding invalid utf-8.
touch $'example\xff.txt'
fd 'example.*txt' // not found
fd -F $'example\xff.txt' // fails non-utf8
The existing rust libraries for manipulating OsString push people towards ignorance or rejection of non-utf8 filenames and paths.
reply