Drop-zones inaccessible when slots are wrapped by flexbox containers

I'm going to take a stab at this.

This seems to work for me, but I'm not entirely sure what you're after and this is my first exposure at Experience Builder.

This is what I added to the CSS

.example-flexbox-break > [data-xb-component-id="slot"] {
  flex: auto;
}

I think this one might be dependent on how https://www.drupal.org/project/experience_builder/issues/3491021 ✨ Leverage HTML comment annotations, remove wrapping div elements Active pans out.

https://www.drupal.org/project/experience_builder/issues/3491021 ✨ Leverage HTML comment annotations, remove wrapping div elements Active has landed and this issue needs re-triaged. Self-assigning and will get around to this tomorrow between 8:30 and 5:00 ET.

This is certainly still an issue, except now the .xb--sortable-slot-empty-placeholder class doesn't specify a minimum width, and will collapse down to 0px wide if the parent element has display: flex.

I think that the safest bet here is to give the .xb--sortable-slot-empty-placeholder a width of 100%. The rationality here being that there should only ever be one empty placeholder per slot, right? As soon as a component is added, the placeholder goes away. I can't think of any reason why we wouldn't want the placeholder's drop-zone to be smaller than it could be!

I.S. update + NR

Setting back to Needs Work. Here's a slack chat to document where things are.

balintbrews
23 minutes ago
@lleber
I might be doing something wrong, but I can’t reproduce the issue on 0.x anymore.

lleber
:male-scientist: 23 minutes ago
I'll double check, but I was just able to around 8:30 :sweat_smile:

lleber
:male-scientist: 16 minutes ago
Ah, so it may be a dependency based thing :open_mouth:.
I added an example-flexbox-break component and here's the CSS inheritance...

(XB styles override example-flexbox-break component styles here)

9:38
Then I added a header (custom) component and here's the inheritance!

(header component styles override XB styles here)

9:39
The [data-xb-slot-id] selector seems to have nondeterministic loading order, meaning the example in the I.S. seems to work, but another component does not!
9:40
I'll dig a little deeper to see if I can sleuth a better example.

balintbrews
13 minutes ago
I can see that you have CSS aggregation turned on. Maybe that comes into play as well?

lleber
:male-scientist: 13 minutes ago
I can try disabling it, but the only reason the example component in the I.S. seems to work is because its display: flex is being overridden.

balintbrews
13 minutes ago
Yes, I saw that happening on my end as well.

lleber
:male-scientist: 12 minutes ago
I do think that if the SDC had a dependency injected on the preview CSS, it'd straighten itself out, but that seems odd.

balintbrews
12 minutes ago
Yeah, we don’t want that.
9:44
@lleber
I’m leaning towards just committing the width: 100% you suggested, I can’t see how that would hurt us. And it may help you now. :slightly_smiling_face: If we see more of these styling issues, we can do a deeper investigation. What do you think?

lleber
:male-scientist: 8 minutes ago
I think it'd definitely help in the short-term, but it may be a harbinger of deeper issues. I think it has to do with the SMACSS layer the libraries are loaded at.
9:46
The component displaying problems is registered at the component layer. Trying to figure out which layer SDCs are registered at.
9:46
I wonder if the XB styles should load at the lowest layer so that everything can override them? Or will that cause issues (see: layout builder off-canvas :smile:)? (edited)
New

balintbrews
2 minutes ago
Our styles in preview.css are unlayered, so they will take precedence over other layers.

lleber
:male-scientist: 1 minute ago
Hm..then I wonder how our custom header is winning there. I'm out of time this morning to debug, but I'm unblocked to find a root cause now.

I think a deeper investigation is needed to see what exactly is going on.