fixed 1px shift when hovering card over holder

[mousewax]

This update breaks the holder CSS apart a little so that when a border-width or other element is set, shifting does not occur in the contents.

[ArnoldSmith86]

PR-SERVER-BOT: You can play around with it here: https://test.virtualtabletop.io/PR-1921/pr-test (or any other room on that server)

After merging, a backup will be available at https://beta.virtualtabletop.io/editor/PR1921-pr-test.

[RaphaelAlvez]

this is gonna be problematic as the more specific properties have higher priorities

[mousewax]

The single biggest issue was the .widget.droppable.droptarget was setting the border width and style and all it should have done was set the border color. So now when the border width is set in the widget's css, the .droppable.droptarget won't come by and mess with that by default.

[mousewax]

I was tempted to change the calculated width to be a plain 1px but decided against it since it's now easily overridden and someone, somewhere may depend on that.

[RaphaelAlvez]

yeah but this would affect anyone who only changed the general border property

[mousewax]

This is very bizarre to me:
border-color: #d8d8d8 #ccc #ccc #d8d8d8;
Those colors are indistinguishable for most people.

[RaphaelAlvez]

This is very bizarre to me: border-color: #d8d8d8 #ccc #ccc #d8d8d8; Those colors are indistinguishable for most people.

yeah this is pointless. would agree on removing

[96LawDawg]

This fixes, for example, dominoes where all of the dominoes are dropped into a giant holder. They all shift by 1px up and left whenever you are dragging one over the play area.

But it does not fix the 1px shift that happens to the individual domino that you are dropping. I don't know if that is fixable or not. Either way, this is already a lot better.

[RaphaelAlvez]

Won't this or break every game where someone used "border" to define "border-width" or "border-style"?

[mousewax]

Won't this or break every game where someone used "border" to define "border-width" or "border-style"?

No. The border shorthand will override the individual declarations.

[RaphaelAlvez]

Yeah this looks confusing. Needs testing if this breaks the border on transparent holders.

[RaphaelAlvez]

Won't this or break every game where someone used "border" to define "border-width" or "border-style"?

No. The border shorthand will override the individual declarations.

I remembered it the other way around. I'll trust you until I can test it.

Damn it's been just a couple of months away from css...

[ArnoldSmith86]

Using border is the same as specifying its components separately AFAIK.

What this does change, I think, is that holders without borders used to show a highlight when dropping but after this PR they wouldn't. I didn't test that though.

[96LawDawg]

What this does change, I think, is that holders without borders used to show a highlight when dropping but after this PR they wouldn't. I didn't test that though.

Transparent holders behave the same. But this statement is correct. Something like "border":"none" on a holder in production shows an outline when dropping. There is no outline in this PR. Some game designers might rely on the existing behavior to indicate where the holders are.

[ArnoldSmith86]

Probably worth it though.

[mousewax]

If they used the transparent class, the borders still show up when dropping on it. That's one of the changes here. Transparent holders still have borders, but they are just set to 'transparent'. If they remove the border, I don't know how to help that.

[96LawDawg]

Agree that even if a couple of games might rely on the existing behavior, way more than that would benefit from the annoying 1px shift. And if the designer was smart enough to make css that would break this, then they are probably smart enough to fix it. Or use the Discord help channel. Approved through test.

[ArnoldSmith86]

This fixes a shift in Expeditions and it doesn't seem to break The Team. Didn't test anything else, I think.

And I totally agree that it should have been like this from the start.

[96LawDawg]

With the most recent change to holder size is a consistent 1px and not variable with room size/scale.

On production:

On this PR:

I like the new one better. Approved again.