- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Mar 2024 21:51:07 +0000
- To: public-css-archive@w3.org
Lots of conjecture about what is hard for beginners being thrown around 🙃 From a usability pov, **it's not the density of symbols that hinders understanding, it's the recognizability**. ASCII symbols in programming languages are analogous to icons in GUIs. When an icon has a widely understood meaning, it facilitates understanding, because the circuit in our brains that recognizes pictures is *much* faster than the neural pathway that processes written language. However, when an icon is used that has no widely understood meaning, this benefit is moot, and instead it simply adds friction to the interaction, as we have to hover over it to figure out what it does from the tooltip. If we stick to the interface, we eventually learn what the icon means, and then it goes through the faster pathway, but that can take a while and I can't remember if it ever becomes 100% as fast as it is for a widely recognized symbol. Depending on the constraints of the use case, sometimes that may be an acceptable tradeoff, but usually it isn't. A happy medium is UIs that have both, so you can fall back to the text if image recognition fails, but not every UI can afford that kind of real estate. The same applies to programming languages: ASCII characters are *their* "icons". That’s why `width < 500px` makes more sense than `max-width: 500px` but `Boolean(foo)` is more readable than `!!foo`. Often this is intuitively understood by language designers, but the specifics of *what* exactly is widely recognized by the target audience is a bit more murky (e.g. for my previous example, I'm sure many would argue `!!foo` is perfectly fine because it's widely understood as a JS convention). On to this particular case, I would argue using a wildcard to mean "any string of symbols" is a *very* widespread convention. It extends beyond programming languages as well, as it's a common convention in many searching GUIs. On the contrary, strings of symbols like `^~=` are far more esoteric. Sure, you'd be able to tell that `[class^~="foo"]` has to do with classes, but beyond that, you'd be stuck. And once we need to come up with a selectors for element types or attribute names, we have to invent two _other_ conventions, whereas using wildcards across the board to mean "this part is variable" means authors only need to learn a single concept that they can then apply to multiple places, which tends to be a characteristic of good UI design (few flexible concepts that can be combined in many different ways, rather than many rigid ones that have to be learned separately). Also, whether beginners can understand the difference between `.foo-*` and `.foo- *` is a pretty easily testable hypothesis. 😄 -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10001#issuecomment-2008194553 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 March 2024 21:51:09 UTC