New-UDMenu [[-ClassName] ], not typed correctly?!

Hello nickzohren,

Thank you for reporting this behavior.

To help us determine whether `New-UDMenu -ClassName` is not being applied correctly or is targeting a different HTML element than expected, could you please provide:

* Your exact PowerShell Universal version and build.
* A minimal reproducible example containing the `New-UDMenu`, the CSS class definition, and one component where the same class works correctly.
* The expected result and the actual result.
* Confirmation of whether the class appears anywhere on the menu element or its parent container when inspected using the browser developer tools.
* A screenshot of the relevant DOM element and computed CSS rules, if available.

This will allow us to compare the behavior under the same conditions and determine whether the issue is functional, related to CSS specificity, or limited to the parameter description.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

Best regards,
Ruben Tapia

Hi Ruben Tapia,

Thank you for your response. We just upgraded to 2026.2.3 previously we were on version 5.6.12 , altough i only noticed this behaviour after the upgrade since we did not use the menu component before.

function New-CategoryBar {
    [CmdletBinding()]
    param(
        $NavIndex = $Session:DashboardNavIndex,
        [string[]] $Roles,
        [string]   $ActiveCategory
    )
 
    $categories = @(Get-AccessibleCategories -NavIndex $NavIndex -Roles $Roles)

    New-UDElement -Tag 'div' -Id 'category-bar' -Content ({

            foreach ($category in $categories) {
                $className = ($category.Key -eq $ActiveCategory) ? 'category-button active' : 'category-button'

                <#New-UDButton -ClassName $className `
                    -Text $category.Label `
                    -Icon (New-UDIcon -Icon $category.Icon) `
                    -OnClick ([scriptblock]::Create("Invoke-UDRedirect -Url '$($category.DefaultUrl)'"))#>

                New-UDElement -Tag 'div' -ClassName $className -Content {
                    New-UDMenu -Icon (New-UDIcon -Icon $category.Icon) -Text $category.Label -Children {
                        foreach ($pageKey in $category.Pagekeys) {
                            $page = $NavIndex.Pages[$pageKey]
                            New-UDMenuItem -Text $page.Title `
                                -Icon (New-UDIcon -Icon $page.Icon -Size lg) `
                                -OnClick ([scriptblock]::Create("Invoke-UDRedirect -Url '$($page.Url)'"))
                        }
                    }
                }
            }
            
        }.GetNewClosure())
}

For Context i inclued the custom component function, nut just the snippet of the New-UDMenu. This shows both the current workaround by adding a wrapper around the New-UDMenu component aswell as the previous implementation using the New-UDButton. In the css codeblock below i am also targeting the MuiButton-root to style the UDMenu components button, which would not be nessesary if t he .category-button class could be added using the -ClassName parameter directly.

.category-button {
  &>.MuiButton-root {
    font-size: medium;
    font-weight: 400;
    color: var(--esh-teal-soft);
    height: 100%;
    width: calc(5*var(--category-bar-h));
    margin: 0px -6px !important;
    padding: var(--category-margin) 30px 0px;
    border-radius: 0;
    clip-path: shape(from bottom left,
        line to calc(var(--category-slant) - var(--category-radius) / 2) calc(var(--category-radius) + var(--category-margin)),
        curve to calc(var(--category-slant) + var(--category-radius) / 2) var(--category-margin) with var(--category-slant) var(--category-margin),
        hline to calc(100% - var(--category-slant) - var(--category-radius) / 2),
        curve to calc(100% - var(--category-slant) + var(--category-radius) / 2) calc(var(--category-radius) + var(--category-margin)) with calc(100% - var(--category-slant)) var(--category-margin),
        line to 100% 100%);
  }

  &.active>.MuiButton-root {
    background-color: var(--esh-surface);
    color: var(--esh-text);
    font-weight: bold;
    z-index: 1100;
  }
}

I would expect the -ClassName parameter to function just like other components (in my example New-UDButton) and add the CSS class name of type [string] to the html element.

As for your other requests about the DOM Element and the confirmation about the class appearing on the element. The since the -ClassName is of type [ParameterAttribute], meaning its type is not set correctly or not at all. For example [Parameter]$ClassName instead of [Parameter()][string]$ClassName could cause this. Since setting this parameter of this type is impossible the entire function fails and my apps New-AppHeader including the New-CategoryBar is not rendered in the DOM at all.

In my example code adding -Classname $className to the New-UDMenu component will result in this error and the enitre component to not render.

i hope this clears up the issue and this should be VERY easily reproducible by just adding anything to New-UDMenu -ClassName since it will result in a exception.
I do hope this is helpfull.

regards,
Nick

Hello nickzohren,

First, I apologize for the delay in getting back to you, and thank you for your patience.

I was able to reproduce the issue successfully in the lab using PowerShell Universal 2026.2.3.

The testing confirmed that `New-UDMenu -ClassName` is currently exposed as `System.Management.Automation.ParameterAttribute`, while the equivalent `ClassName` parameter on `New-UDButton` and `New-UDElement` is exposed as `System.String`.

Both a literal string and an explicitly typed `[string]` value produced the same parameter-binding exception you reported. I repeated the primary test three times with the same result.

I also successfully validated your `New-UDElement` wrapper workaround.

For comparison, I tested 5.6.12 and observed the same behavior there. Based on the current evidence, this does not appear to be a regression introduced in 2026.2.3.

I am preparing the reproduction evidence for internal escalation and will update this thread when there is additional information to share.

Thank you again for providing such a clear reproduction and workaround. It was very helpful in isolating the issue.

Best regards,

Ruben Tapia

Hello nickzohren,

Thank you again for your patience.

I wanted to let you know that the case has now been escalated internally for Development review based on the successful lab reproduction and the parameter metadata we collected.

The escalation includes the 2026.2.3 reproduction results, the `ClassName` type comparison, the repeated binding failures, the validated workaround, and the 5.6.12 comparison.

At this point, we will wait for Development to review the findings and confirm the intended behavior and any required product correction.

I will update this thread as soon as we have additional information to share.

Best regards,
Ruben Tapia