But is it USB-IF’s fault manufacturers tried […]
Yes, it absolutely is USB-IF’s fault that they are not even trying to enforce some semblance of consistency and sanity among adopters. They do have the power to say “no soup certification for you” to manufacturers not following the rules, but they don’t use it anywhere near aggressively enough. And that includes not making rules that are strict enough in the first place.
They are not bad at this. You are bad at understanding it.
I work with this stuff, and I do understand it. Some of my colleagues are actively participating in USB-IF workgroups, although not the ones responsible for naming end user facing things. They come to me for advice when those other workgroups changed some names retroactively again and we need to make sure we are still backwards compatible with things that rely on those names and that we are not confusing our customers more than necessary.
That is why I am very confident in claiming those naming schemes are bad.
“don’t even bother learning it” is my advice for normal end users, and I do stand by it.
But the names are not hard if you bother to learn them.
Never said it is hard.
It is more complex than it needs to be.
It is internally inconsistent.
Names get changed retroactively with new spec releases.
None of that is hard to learn, just not worth the effort.
Sorry, didn’t want this to look like an attack or disagreement. Just wanted to highlight that point, because arbitrary maximum sizes for passwords are a pet peeve of mine.
At least the character limit had a technical reason behind it: having a set size for fields means your database can be more efficient.
If that is the actual technical reason behind it, that is a huge red flag. When you hash a password, the hash is a fixed size. The size of the original password does not matter, because it should not be stored anyway.
TL;DR: The USB Implementers Forum is ridiculously bad at naming, symbols and communication in general. (And they don’t seriously enforce any of this anyway, so don’t even bother learning it.)
It’s not like there was nothing at all in that space before git came along, e.g. we had svn before, and mercurial more or less in parallel.
The Next Great Thing™ will not make a number of users that is significant to any real world scenario move away from Windows. The only approach that might have a chance to do that is something that looks and feels as close as possible to Windows. Yes even the parts of Windows that are bad. All of it, except the most glaringly obviously horrible stuff (like ads in menus). And that also includes all the programs a significant number of users care about either running there out of the box without having to jump through any hoops or a replacement fulfilling the same “looks, feels and operates almost identical” criteria.
People care about something feeling familiar and not having to relearn stuff a lot more than about shiny new features.
If Google wants to push webp because it is smaller than previous formats, and jxl is even smaller than that, why would Google have an interst in blocking jxl?
Not saying Google did not or does not block jxl, just your chain of logic as to why they do that does not make sense to me.
A typical project manager will get a range, take the lower bound and communicate it as the only relevant number to every other stakeholder. When that inevitably does not work out, all the blame will be passed on to you unfiltered.
Depending on where you work it may or may not be worth giving someone new the benefit of the doubt, but in general it is safer to only ever talk about the upper bound and add some padding.