I'm trying to design a map using images that overlap in an isometric format.
Right now, i have 2 different designs, each one fixes the other's issue. Here is the current setup:
http://mc1.empirebattles.com/map/maplayout.html
The display on the left has issues with the vertical overlap, and the display on the right has issues with the horizontal overlap.
I know that the reason is due to the fact that when a z-index is applied to the parent container, the subsequent z-indexes applied to the children is localized inside the parent.... but i still need the 'row' effect to span across the multiple parent divs.
I know one solution is to just not assign a z-index to the parent divs, and just assign ascending/descending z-indexes to each row, but in the final product, the parent divs will be created dynamically, and I'm trying to avoid having to do calculations at each row for relative z-index....
I cant think of any other way to do it though... anyone else have any ideas on how to apply z-index relatively?
I have never found a way to interweave z-indexes for things in different relative or absolute containers.
I think of it like two books. In real life, you could kind of half-open both books and wedge them together so some of the pages are in between each other, like this:
http://4.bp.blogspot.com/_e3GqvYXugb8/Se11YQaT-YI/AAAAAAAAAGQ/ljKewd_WMj0/s320/PhoneBook.jpg
In CSS, this isn't possible.
I think the most straightforward thing is to decide on an absolute frame, like the screen size, or the whole map, and position and z-index all objects against that single parent. Then you can treat all game objects like... well like independent objects and not worry about these odd row containers and other layout specific elements.
A way to avoid calculations is to reserve ranges ahead of time for each row. Let's say you can have a max number of 100 units in each row then elements in each row will get an offset of 100*n where n is the row number.
Is that workable for you?
Related
I am looking for a solution to keep an (approximately) equal number of items per row when flexbox wraps, for a case with an arbitrary number of children. The closest answers I found were really about specifying a fixed number of children per row at different breakpoints - that is, if six (somehow all the examples are six) children will fit on a line at a certain breakpoint then great, if not then three per line, etc. I know how to change widths per breakpoint, and I know at least four ways to hardcode a flexbox line wrap after a specific arbitrary element - if I know which elment to break on in advance.
This case is different in that I can't know how many children the element will have, however. I know that at a certain breakpoint, I can fit up to five on a row; so if there are five children, then I want a single row, but if there are six children, then I want two rows of three elements. If there are eight, then two rows of four, if ten, then two rows of five, at twelve we get three rows of four, etc. (other numbers need to end up with one fewer on the bottom row - that's all fine.)
I have complete control over the markup, and I'm willing to use javascript if necessary (it probably is). I'm not currently using jQuery and don't particularly want to add a package just for this, but I can if needed and I'm decent at translating jQuery back into vanilla javascript anyway, so go ahead and give me a jQuery solution if that's what you've got. I'm not married to flexbox on principle either, but I'm using align-items: stretch to get the look I want when there's an different number in the last row, so I'm pretty sure grid can't do what I want. If it'll come close, I'll at least learn something. Heck, I'll even look at weird hacky things with floats and max/min width at this point.
I am using Vue-draggable-next along with Vue 3 to implement draggable lists. My application sometimes requires users to drag items from other lists into initially empty lists. I found that the dragging detection area is determined by how much space its elements are occupying: when there is no item in a list, it is super frustrating to drag one into the list because the detection area is soooooo small (only a dozen pixels at the start of the list on the page). This is demonstrated by the following GIF:
Is it possible to somehow set the detection range height of each list?
with this property you can expand the gap empty area:
:emptyInsertThreshold="50"
The parameter I received is positive numbers, try it, it worked for me.
you can easily solve this problem by adding a minimum size to the draggable, min-heigh: 200px this is because the drop zone is not specified and needs a min-height to be set
I have project where I would like to display sensor readings from the building. It contains temperature, date and name of the room. It is in one small simple square.
I would like it to be displayed on the TV monitor( I am unaware of what the resolution will be, but that can be calculated with JS).
Problem is, I don't know how many readings there are going to be and I need to show them all on the screen(Since it is going to be on monitor without possibility to scroll). I don't know how to calculate their dimension so they would fit. I didn't find any miraculous css property for this so I am fine with creating some JS function. However, I don't have an idea where to start. I would know the number of sensors and resolution, that is all. This number of readings will change over time though.
Any JS libraries that could do this? If none, what function should I write?
Edit: Touffy's solution works great! I found this article for others in needs: Dynamic number of rows and columns with CSS Grid Layout and CSS variables
You can probably decide which browser will be used for this sort of application, so you can pick one that supports CSS Grid Layout. With that, you can do what you want without any JavaScript by specifying the grid container to take the whole viewport (100vh and 100vw), and letting it arrange the grid items with the constraints you like (number of columns, spacing…).
My page is running a touchmove event which captures the position of the user's finger on the screen via:
xPos = e.originalEvent.touches[0].pageX;
yPos = e.originalEvent.touches[0].pageY;
The page has many layers (created with position:absolute divs) and at this point, I want to calculte how many such layers exist below the user's current position on the screen.
The only method I can think of is to have an array of all the layers' positions and loop through that. However that seems rather processor intensive when there may be hundreds of layers on screen at once.
Is there a simple way in js or JQuery to count the items that exist in a position, or a better practise way to do it than my array suggestion.
As far as I know, there is no such way. My approach would be to give all layers a certain class, select them all and iterate through them. Depending on what you are trying to achieve with this and how often you'll have to perform this calculation, it may be possible to use caching and approximation (e.g. not checking a certain pixel but an area of x^2 pixels and caching the result, etc) to make things run faster.
That being said, I encourage you to first try the solution that you've thought of and see how fast it actually runs. Browsers are pretty fast for such standard operations (think layer drag & drop with boundary checks), so I'm pretty confident that it won't be as slow as you think it will be :)
I have a number of elements that I need to add to a page using javascript with data pulled from the server with their position information. I want to arrange them so that there is no overlap. For example, element 5 would be moved to where the thin green box is, so that it doesn't overlap element 3.
I have successfully created a function which decides whether two boxes overlap. For example, if I ran overlaps($('#element5')[0],$('#element3')[0]) it would return true.
However, with this function I would have to loop through each element and compare it with every other element. So for 50 elements I would need to do run the overlays function 1275 times which would take a long time to load.
I decided I would best creating an rtree to organise the elements first so that I could easily work out which 2 elements I would need to run the overlay function with, significantly reducing the number of runs of the overlay function. However, I am extremely confused on how this would work. How would I organise them so that I would only have to run the function with a small number? Wouldn't 2 of the rtree's bounding boxes overlap and make this technique redundant? What would be the best way to do this?
In an R-tree, rectangular pages can indeed overlap.
When searching for overlaps, you would have to explore both groups then.
But the number of overlapping pages in the r-tree shouldn't be too big (unless the tree was built very badly), so this will still yield a good speedup. Assuming you have 50 elements in 5 pages of 10 elements each, you will first have to test the 5 top level pages, then maybe test the 10 elements in 0-2 of these pages, so maybe just 15 overlap tests instead of 50.
The exact numbers will of course vary a lot.
For a HTML solution, however, I would consider a grid based approximation instead.
Divide your surface in 10x10 cells. Each cell contains references of the rectangles that overlap with this grid cell.
When testing for overlap, you look at the grid cells the query rectangle touches, collect all referenced existing rectangles, and then overlap test only those. If you store two lists in each cell - "overlaps partially" and "overlaps completely", you can even skip many of the overlap tests: if any grid cell touched by one is overlapped completely by the other, they will overlap somewhere.
Yet another approach would be to sort the rectangles by X axis, to quickly narrow down the number of rectangles that can actually overlap with a binary search. This also should drastically reduce the number of intersection calls.
Oh, and last but not least: 1275 overlap tests should not take a lot of time anyway. This is by any means a tiny data set that you are talking about. R-trees and similar approaches are meant for data sets with millions of items.