fix: apply masterSize to master area even without detail content

[DiegoCardoso]

Summary

• Remove [has-detail] requirement from CSS selectors that set master width/height from masterSize, so the master area respects its fixed size even when no detail content is present
• Add tests for horizontal and vertical orientations verifying master sizing without detail

Fixes #10318

Root Cause

The CSS selectors applying masterSize to the master part required [has-detail]:

:host([orientation='horizontal'][has-master-size][has-detail]) [part='master'] {
  width: var(--_master-size);
}

Without detail content, has-detail is absent, so the width/height rules never applied. Combined with flex-shrink: 0 (which IS applied) and no flex-grow/flex-basis (blocked by has-master-size), the master ended up with no sizing — causing children without intrinsic size (e.g., <vaadin-grid>) to collapse to zero.

Fix

Removed [has-detail] from the two selectors. This is safe because:

• max-width: 100% / max-height: 100% on [part] prevents overflow
• !important overrides in drawer/stack mode are unaffected

Test plan

• Existing tests pass (79/79)
• New test: horizontal master gets 400px width without detail
• New test: vertical master gets 200px height without detail
• Manual: dev/mdl-size.html — grid should have 400px width

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sissbruecker]

Currently, the master expands once you open the detail, which looks quite jarring:

Bildschirmaufnahme.2026-02-17.um.07.18.56.mov

But keeping the master on a fixed size when the details are displayed as an overlay is also weird. I think I would expect that if the details are going to be opened as an overlay, the master size would still cover the full size. It would only respect the width if details would be shown next to it. The problem with that is that we can only detect that once the details are actually added to the DOM, otherwise we have nothing to measure.

ping @rolfsmeds

[rolfsmeds]

Hmm, that (the master becoming full-size again once the detail goes overlay) is an issue also with a non-fixed-size master (it looks a bit jarring regardless, because at that point the master has already shrunk down to its min-size).

It would probably look better if the detail popping out didn't affect the size of the master, but with a semitransparent detail, it might look weird that there's just empty space next to the master? But maybe that would still be better?

If we change this, it would mean that

• With a fixed-size master, the master would always be exactly that size (except if viewport is smaller)
• With an auto-sized master (with a min-size), the master would be fixed to its min-size when the detail is overlay.