API and Property Bikeshedding #17
Comments
|
Some ideas:
"jailed" would be shorthand for also creating a spatnav group. That makes me wonder; do we really need two properties?
|
Interesting. I like the naming on the value side, and this is probably enough for 99% of the cases (minus the ability to set jails without activating spatnav, but that can be added back later with longhands, and it's unclear how important that is). On the property side, I think I'd rather call it "spatial-navigation" or "spatnav" than "key-navigation" though, because:
I'd prefer However, it raises some interesting questions about the behavior. property inheritanceauto vs active is a thing that inherits, jailed vs not jailed is a thing that doesn't. We could say that We can even do it without exposing the long hands, by describing "spatial-navigation" as a non inherited property, with special logic to handle the computed value of I think I like this option. @jihyerish, what do you think? Also, We can possibly mark the longhands at risk and have a note explaining how you do this if you implement only the shorthand. changing semantics of activationAn alternative to the above would be to make the property completely non inherited, but that requires a change in the semantics of how activation works. If I think I like this alternative less, because it removes one thing which I suspect may be important: inside a page in which spatnav is generally activated, the ability for a sub-component to not activate it. I think the situation where a spatnav-using page wants to use a third party component that doesn't play well with spatnav will not be all that rare. We could restore that possiblity by adding an I think we could specify it this way (which is why I've detailed it here), but I don't like it. |
In chromium, spatnav shares quite some code with Tab-key navigation. So from implementors' perspective, it's not too off. Both advance focus.
These have keys as well :)
Voices also have keys :) although of a different kind...
Perhaps it's better to leave the two longhands out from start? A smaller spec is easier to reason about, to study, to convince vendors about, to implement, to test, to ship ... and, in case it turns out to be a fiasco, to deprecate. Same argument applies to #32. |
IMO either
I don't oppose to |
The reasons for proposing
Ultimately, I like @florian's suggestion: |
|
Other naming ideas for the shorthand:
But instead of
|
The underlying implementation of spatnav and sequential nav do share some code, but the effects of this property is not on both, so it should not be named in a way that suggests it affects both, otherwise we'll just confuse people. Unless you want to also change its effects to something that does have an impact on both, but I don't think you've mentioned anything to that effect.
contain, container, containing and so on are frequently used used terms in CSS (grid container, flex container, block container, initial containing block...). I think reusing familiar terminology is good. And it is the word we use in the spec prose anyway, so let's not shy away from it.
I'm very used to it, so I don't mind, but I can see that it looks weird to people who don't have to say that work 50 times per day :)
I agree. That argues in favor of having the longhands as well. Even if people may just use the shorthand in most cases, the longhand are there when needed. With all that in mind, my preference goes to:
Unless someone has strong objections against that, I'm going to put it in the spec shortly. Even if we later find something even better, this seems a genuine improvement over what's in there currently anyway. |
|
Why not call it Isn't "focus" more descriptive than "spatial"... ? It's shorter too. My objection is that I've always found the word "spatial" a bit too spacy. It never made me think of "directional focus movement". What do you think? @jihyerish @Malvoz
I see a risk when one keyword means different things in different contexts.
Yes. And since we're all uncertain whether the longhands will actually be useful or not in the end, let's leave them out for now? Again, I'm only trying to minimize this spec's scope to make it easier to implement. More options, more complexity. @jihyerish, would it be OK if we leave them out? |
Focus navigation implies that it also relates to sequential focus navigation. I would not be against that change in the name the the spec as a whole, since it does talk about both. But this property is not about both, so "focus" alone isn't good.
Spatial and Directional are effectively synonyms here, so replacing spatial with directional would not be wrong. It's just a question of what most people find easier to understand / remember. You prefer directional, so that's one data point. But https://en.wikipedia.org/wiki/Spatial_navigation talks about the concept we're using, while https://en.wikipedia.org/wiki/Directional_navigation does not exist. Since it is established terminology, I am not too keen on changing it. Again, not totally against, since directional isn't wrong, but going with established terminology seems the path of least resistance.
The path without longhands reduces the API surface, but it does not reduce implementation complexity (since you effectively have to reproduce that internally to handle the mixed inherited / non inherited behavior), nor does it reduce spec complexity (since explaining how the computed value logic for a single property works is not easier than declaring the longhands). How about that: I put the longhands in, and mark them at risk, to signal that they may be dropped if implementer would rather skip them. That documents the full idea, without forcing anyone's hand. |
I don't think For consistency across navigational properties, keep "navigation" abbreviated? Resulting in: Shorthand: Longhands:
Take the |
Conceptually, I see the scrolling as something that happens because spatnav had "hijacked" the arrow-keys. When it can't find anything, it returns control to the "normal arrow-key behavior", which is scrolling. I assume arrow-key scrolling is already defined elsewhere so we don't need to redefine it in this spec?
I see spatnav and tab-key navigation as two different methods for moving focus.
Ah, right, ok... maybe that's a problem? I could imagine a property like
Hmm. One property means one enum in C++. One enum to check = low complexity? Inheritance can be checked by walking the DOM up to its root. |
While it may be nice to have and doesn't cost much on top of the processing model, it is non essential, and can be deferred to level 2. Keeping it in the spec for now was distracting: not only were there open issues (especially naming) related to it, but distracted readers from the essential point of this specification. Closes WICG#16. Addresses part of WICG#17.
While it may be nice to have and doesn't cost much on top of the processing model, it is non essential, and can be deferred to level 2. Keeping it in the spec for now was distracting: not only were there open issues (especially naming) related to it, but distracted readers from the essential point of this specification. Closes WICG#16. Addresses part of WICG#17.
At the same time, I have renamed it to the better naming discussed in WICG#17
|
Various changes based on this issue have been committed to the specification. Further bikeshedding should be discussed on a case by case basis. Closing. |
frivoal
added
type:question
The property names and API names used in the spec are probably OK, as they described what they do reasonably well, but I would not go as far as calling them nice.
Better suggestions are very welcome.
In particular,
spatnav-containeris a bit questionable. Maybe we should not use the abbreviation, but if we called itspatial-navigation-containerit would look like it may be a longhand ofspatial-navigation, which it is not. Or maybe it isspatial-navigationthat should be renamed intospatnav-something...The event names (
navnotargetnavbeforefocusnavbeforescroll) aren't too pretty either: the convention that event names should be all lower case without hyphens or underscrores does limit how nice they can be though.The JS APIs are pretty descriptive and tied to the name of algorithms in the processing model, but they are quite a mouthful.:
findSpatNavCandidates()selectSpatNavBestCandidate()sequentialNavSearch(). Are we happy with that?The text was updated successfully, but these errors were encountered: