How to select elements based on their position?

Hi folks!
I have an interesting problem here.

Exact problem: Need to select elements that are placed dynamically in the masonry grid.

Summary: I need to implement keyboard navigation, and currently I’m able to navigate through tabbing which happens in DOM order.
But the blocks/elements will be placed randomly.

How can I implement navigation on dynamically placed elements?

More detail with diagram in the following link :point_down:

I think we need a little more detail on what you are trying to do here. In general you want the tab order to go in the order the elements are placed in the DOM. Moving them around with CSS so they appear out of order is not recommended. But again, until we know exactly what you are trying to do it is hard to give advice.

Perhaps you have a link to this project you could share?

Essentially I want to implement a big drop down menu with masonry layout, which will have several items (blocks with sub-items).
I wish to navigate it with arrow keys.
So a dropdown with items in masonry layout & when we decrease the window size, the blocks rearrange themselves (as in the diagram) .

The foremost question I had is whether or not it can be done? If you take a look at pinterest, they don’t have arrow navigations on masonry layout.

And secondly, how to achieve it, given that mostly we try to implement arrow navigation by fetching the element from DOM and that gives us the navigation in DOM order, which may not work here.

p.s. unfortunately I can’t share the code but the problem essentially is navigating masonry elements with arrow keys.

Interesting question, but I’m not sure I understand correctly. How “random” is the layout really? Would it be the same as long as the viewport size is the same?

Generally I think you’d have to read the position values (like from top, from left) and then have some logic like “if right arrow, go to the element one column to the right that is closest to the current scroll-from-top position”.

If the block sizes are always the same, it should be possible to calculate a lot of stuff in advance (like a block grid map for different viewport sizes), but if their sizes/number change, you’d have to do that “on-the-fly” which might have impact on performance.

All depends on details, especially what you mean by “elements are dynamically placed”.

2 Likes

Thanks for the insight, & apologies for confused wording.
So by “random” & “dynamically placed,” I don’t really mean placement is random.

What I mean is that, suppose Block A & Block B have a gap(vertical) after it (say gap-A & gap–B) {where gap-A > gap-B}.

Now if sub-items in Block D are less than sub-items in Block C, then Block C goes below Block A, otherwise Block D goes below block A.

In essence, the block with more items, goes below block with more gap.

  • At a later point of time, if sub-items in blocks change, we don’t want the behaviour to break. Right! We would still expect, the block with more items, to go below block with more gap.

  • The layout will be same as long as the viewport is same. The only thing that’ll change the positioning of the blocks is the block sizes & the vertical gaps remaining at the end of the blocks.

My question is why are you navigating the cards with arrow keys? Is there something special about these cards that calls for that? Most keyboard navigation is done with the Tab key. There are some specific instances where the arrow keys are used, but I’m not quite sure I see how these cards would fit into that. Please give me a little more insight into the need for arrow key navigation here. The up/down arrow keys are used by screen readers to move through content so you should not hijack those keys without good reason.

1 Like

Thanks for the interest @bbsmooth
These are not cards. The blocks that I represent are group of links in a big drop down menu.
So Block A is a level 1 topic link, which has sub topic links (level 2 topic links) represented with solid dashed lines.

I should have added this detail in the question itself. Sorry for the confusion.

If these are all links then you would just navigate them with the Tab key. I would highly recommend you not hijack the arrows keys for this.

As for the order, if you have A → B → C → D in the DOM then can’t you keep the same order in the masonry layout?

A     
       B
C   
       D
1 Like

Not really! I need to conserve the viewport space. And since this is going to be a giant drop down menu, I need to consider accessibility and thus arrow navigation for easy navigation.

That is a nonstandard use of the arrow keys, which hurts accessibility.

1 Like

OK, I guess I didn’t understand this part. In fact I’m not sure I still do. I drop down menu that rearranges itself.

I’m not sure how having a masonry layout will conserve more vieport space over a simple one column design. Usually you are concerned with horizontal scrolling, not vertical scrolling. A single column design seems to be best for that.

Anyhoo, it sounds like an interesting approach. I would try to keep the keyboard nav order as close to the DOM order as possible.

Have fun.

1 Like

if you could dynamically render a 2d array which represents the dom elements and with arrow keys navigate among them. For example, up and down would subtract/add a row(subarray) and left/right would subtract/add column number(subarray index). Something like that:

[
  [ 1, 2, 3, 4 ], 

  [ 5, 6, 7, 8 ], 

  [ 9, 10, 11, 12 ]
]

Lets say you want to target the 3rd element(row 1, column 3). You can do arr[0][2], consider arrays are zero index. The question is how to dynamically target the elements, or how your elements change dynamically.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.