Use names that describe purpose #550
Conversation
I found that I needed to redo the whole section here. Changing the focus seemed better than adding text. This is more text, but not a lot more. Future-proofing is one motivation, but it's not the real motivation for these recommendations. I also found the key event example to be spectacularly non-compelling. It even made me think that it is almost a bad example. Key events can be synthesized by speech recognition tools in some cases. To that end, I chose an example that I'm more familiar with. Closes w3ctag#507.
There was a problem hiding this comment.
Overall, this seems like a good change.
In looking for counter-examples, I tried to think of a more purpose-based name for WebGPU. Its design is so tied to the common GPU architectures, that I don't think there is a better name. That probably means the API itself isn't so future-proof, as we might be seeing in the introduction of WebNN, but that seems like a different principle, which itself would need to acknowledge the balance between future-proof semantics and getting something out the door for web developers to use.
I'm approving, but we should give Domenic and the section's original author (@hober?) a couple days to point out problems.
|
I agree that WebGPU is a bit challenging, but I think that a better name "graphicsProcessing" (dropping just "unit") or "graphics" (because all APIs are about processing) is probably just not worth it. The acronym is shorter and the extra baggage isn't too badly distracting from the central theme. That the same hardware can be used for neural processing is fine. Generally, I've observed that most of the naming problems we have are ironed out pretty well. Most of the names we end up with are pretty reasonable at a high level. There are mistakes and some names end up being a worse fit over time as the purpose drifts, but that sort of thing is inevitable. Overall, the purpose of this, like a lot of the document, is not to change how we do things, but to document existing good practice. (I skimmed the high level list at wpt.fyi and saw a few that could have been better named, but nothing egregious. Here are the ones that made me think twice: eyedropper, entries-api, fledge, gyroscope (orientation-sensor?), mediacapture-insertable-streams, parakeet, speculation-rules. A lot of those are either recent and experimental or proprietary, so maybe it's OK and they will resolve into a better name with time, as some already have. Obviously, the WebIDL names at lower layers are probably in a worse state, but that doesn't mean I can't take a positive view of where we are.) |
I found that I needed to redo the whole section here. Changing the focus seemed better than adding text. This is more text, but not a lot more.
Future-proofing is one motivation, but it's not the real motivation for these recommendations.
I also found the key event example to be spectacularly non-compelling. It even made me think that it is almost a bad example. Key events can be synthesized by speech recognition tools in some cases.
To that end, I chose an example that I'm more familiar with.
Closes #507.
Preview | Diff