Virtualize should allow customization of the spacer element type

[SteveSandersonMS]

Blazor's <Virtualize> component renders a spacer element to define the vertical height of the scroll region. It's hardcoded to use a div element like:

<div style="height: 12345px"></div>

This works fine in just about all cases. It even works fine when being dynamically injected at runtime into a parent element that wouldn't normally directly contain a div, such as a tbody element, as it can have the CSS rule display: table-row.

However, it does not work correctly with prerendering. If the server emits some markup like this:

<table>
   <tbody>
      <div style="height: 0px"></div>
      ... normal rows here ...
      <div style="height: 12345px"></div>
   </tbody>
<table>

... then the browser's HTML parser will decide that the div elements shouldn't really be inside the tbody, and will actually create an initial DOM structure equivalent to this markup:

<div style="height: 0px"></div>
<div style="height: 12345px"></div>
<table>
   <tbody>
      ... normal rows here ...
   </tbody>
<table>

Most of the time people don't notice the difference, because after a fraction of a second, the page switches into "interactive" mode and rebuilds the DOM dynamically, and this time the structure is as expected.

So, the problem is that in between prerendering and switching to interactive mode, the DOM structure is incorrect. This can lead to a flash of malformed content, e.g., making the table header row appear to be further down the page, and then jumping back to the top once the site becomes interactive.

Proposed solution

Add a new parameter to Virtualize to enable controlling at least the tag name used for the spacer element.

Consider even make it into a whole [Parameter] RenderFragment SpacerTemplate { get; set; } parameter, though TBH I'm not sure what the use case would be for customizing this in any other way beyond the tag name.

This will be needed for "base grid" to behave correctly with prerendering when being virtualized.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.