I have the perfect, simple solution for arranging the cards layout in lovelace

upps, that was not , left to right

And your idea of scroll inside card that was higher than the min-heigh-card in a row , i think not, what on a phone 2-3 card in a row With scroll ?

And you havent either “pointed out” how this view should respond upon resolution changes, 2 columns instead of 3 , what about 1 column, when the card spans 2 ? , how/what to move, well it must be a whole column ( i.e like a vertical stack )(Use vertical-stack-card ) … or do you serious mean we all should start make individual views, for when a PAD, or phone is in vertical/horizontal mode, and have views for every resolution devices in the family

yeah It has to be responsive, for every possible use-cases ( kind of like layout-card, with CSS options, to define the grids structure and behavior ) … or ofcause a default-fixed behavior , decided by a dev, cording to your wishes, not all the others who have other ideas, who dont like scroll-bars every second card, and want to build an UI that looks good/are usable on all the family’s devices, even after next Xmas or birthday, , or black friday sale

What you and maybe OP wants, is the ability to adapt a grid to your specific needs, beside this should be with a click on a button, not because you can’t read or learn, but because ( it’s convenient ) For You ! , and if OP then find that he want to move a card, to another place in the Grid, this should be doable with another click on a button … ofcause if the card spans 2 rows, or column, then the grid per Magic should be re-written cording to your wishes. and the cards who have to (leave space) needs also per Magic re-locate to the spot you want

Moving left and right, like the OP, is only possible with a grid, not masonry.
And the OP is in that direction, only a grid is using x,y coordinates.

I’m not trying to do as my liking, I’m trying to build on the OP idea with something that seems realistic.
I’m now muting this post. You and others arguing that my idea (or the OP) is not doable is useless as for my part I never ever say it was as it or mature in any way.

And the OP is like me, doing a proposal that makes sense as masonry is never reacting as we want. It needs to mature of course.

“They did not know it was impossible so they did it”
― Mark Twain

I never said or mention , it’s not doable, but as i have a working solution , Layout-Card , i really don’t care about your , Convenience , ok 1 thing is to request a New Native View-type.
Another thing is to request multiple , conflicting features in the UI, for moving cards, within cards, within cards, by Buttons , and hoping that every Custom-cards developers follow-up on this, is somehow utopi, or just lead to less custom cards , if it’s made mandatory , to build this into the cards.
Take Custom button-card , try to request buttons in the UI-edit-mode, to move around the objects in the grid used in this card ,
A native , limited grid featured card is already in stock, and it is also fairly easy to add an limited grid-view, where you can choose columns and rows, and then a , build in feature as 1 card in each cell, move to next column-cell , fill in order as you mentioned.

But im sure you know a great deal about programming, so You also know, that every little detail have to be specified in the code, for a , Button, Select UI , and the more build-in features the more complex Editor-UI, the more complex code, the more prone , And then we come to the 100000 different points of view, how/which features should be , Native , And supported by the already busy HA-Dev team .
In Specific when everyone can install Layout-card, and copy paste code, as a first step, in understand GRID And CSS
Building a whole new Card/View editor might be on the Dev-teams which list, but we are talking about an Application in an Application , and for every small feature , multiple bugs and additional feature request will arise

And as mentioned , to your ability to find / move your card, in nested view structure , Layout-Card , or common GRID structure / feature have this as my example above
You don’t have to write your Dashboard in any particular order.
You can manually change 1 word in view-layout-grid area , 2 as you also have to change the word in the grid area you want to move your card to

view_layout:
   grid-area: header2

Example: name is irrelevant , Could be as OP’s, A2 , everything under this is the code that define the card , or nested cards
Then you want to move this code to C2 , just change A to C , done , PS you dont move the code, in this case, as i assume you are aware of

So Yes it’s doable to create a UI, Card/View editor, which perform this, you mention ( HTML ), colpan rowspan , so im sure you also know how these humongous , Design-tools are build, and how much code need to be maintained, and how it breaks, when a user find it’s way to manually editing the code , instead of clinking a button, And then breaks his whole damn View.

Im sure you have noticed the , Numbering of Cards, which recently was added, to the Views, as per FR, click / type the number , in order , you want to move your card to , It work on Level 1, the bottom-View, so you move a single card, or several, if they are in a grid/stack card, or i.e glace etc, in this Implementation , they move the code , Shuffle around the actual card-code
This works in masonry, and even in a horizontal / vertical-layout , VIEW Level ,

There is only 1 way to make this work in a grid, by defining each cell in the grid , With i.e grid-area , as you have to move from A to B, or 3 to 4 , or A3 to B2, this can be accomplice by select buttons or drag-and drop, with quite some additional code :wink: , which needs to be maintained, and before you know it, HA will need another GB of ram, and additional disk-space.
You mention grid, in grid, and above poster also use this, meaning this should not only work in a dedicated View-Editor, it should work on Cards , Within Grid-Cells , And cross-functional , Move 1 card from a Cell-Grid, 2nd layer, to a Cell in The 1st-Layer Grid , Ofcause this is also Doable
Someone just have to write the code and implement it, and support it :wink:

Minister of traffic infrastructure: I want to make a bridge from here to there.
Engineer: that is not possible
Minister of traffic infrastructure: and who says that?
Engineer: the law of nature
Minister of traffic infrastructure: then we will have to change that law.

Some things just can’t be changed. Whether we like it or not.
We are many that would love a drag and drop solution, but if you can not right down a recipe for for how the layout should be structured, then a developer would not be able to code it either.
Computer programming is pretty much like following a recipe to the dot.

1 Like

There actually drag and drop UI’s for Grid-Views, but …

here is a light example

True, but they have lots of limitations and can therefore not be applied to the HA use case.
Limitations can among others be card sizes that are fixed in the layout setup, so cards can not expand or shrink, and card numbers are fixed in the layout setup, so cards might not be able to be hidden without it leaving an empty spot.

1 Like

@Olivier1974 thx for standing by me :wink:

i do not think this is only possible with a grid because you can (with a lot of shuffeling around) get the cards at the wanted position. so below the UI there has to be a system that records the position of the card or something, maybe they do use a column/row system to store the positions, i don’t know how it’s programmed. if we knew that it would be easier to find the simplest solution.

so i think just a right/left button to move it is a small addition since all needed functions are already in place. it would be nice if one of the devs could confirm this. then we’d know.

a grid is a posibilty too if it doesn’t create blank spaces. i mean when using cards of different heights, that the intersections between the cards are NOT a straight line, but rather are at where the cards end, not making them uneccesary high/ fill up with blank space.
and that it will be a static view does not matter to me, but it would be really great if you can store the layout per device.

yeah, but, common be open and ( receiving ) :slightly_smiling_face: , how about if the underlying .js Layout is build upon a lot variables, and the user then inject values into these variables, in the .js, with a click on a button, which also at the same time triggers the .js to reload, and ajust/adapt to the requested/injected variables :slightly_smiling_face:

that’s a nice way of fixing it. i’m not shure how good text will look when scaled…

Nope. The system takes the cards from a single list and plops them where they fit to minimize vertical scrolling.

As i mentioned about, and you can see for your self, this implementation is done by (moving the code)
I.E Read View-Yaml , Usually at View-Level it’s kind of like this:
05.01.2024_15.10.36_REC

So you see the cards in the View-Level, is defined by
Cards:
-type1
-type2

When your click to a lower number, it takes the code under type2 and move it above type1
Well im not sure whether it actually reads YAML, or .json … either was that is how it’s ( numbered/defined )

it’s been a while i viewed that yaml, but that makes sense. thx

hi Petro,
so there is no simple solution then?
do you have an idea to improve card positions?

PS: Just Teasing ! :smile: … Sorry for the lousy quality, had to convert to GIF
ezgif.com-optimize

PS: No grid ( in yaml ) plain list as masonry

that looks awesome!
are you making that?

Nope, old card that previously was available in HACS, it build upon the View type ( the 4+ year old Default-View) ( Basically the same Way Layout-out card does in View ), but as you notice it cant figure out what to do, when you i.e place a card in the middle of columns (which are auto defined columns) , also it has problems (remembering) 2 moves, without saving, and it always fill the view in order, left-to-right-top-to-bottom, It builds upon layout-keys
So i guess the authors .js-file do what he tried to accomplice , beside a few refresh glitches ( haven’t checked )
And it basically follow the Masonry, when resizing from 4-3-2-1 Column

Again, Layout-card is The Most Versatile correct way to go, if you want a grid-layout

PS: Nope, im not saying more ! … read about Grid-Layout / View-Layout and CSS in common , and hope , wish for some kind of PRE-Defined drag and drop, and maybe a default-native grid-view ( if native-grid-card in Panel-View don’t meet your expectations )