Blazor Allow PascalCased Component Names Matching Reserved HTML Tags

[xiety]

Describe the bug

Custom component with name Input works fine until I've added RenderFragment parameter to it and put the component into a @foreach loop.

To Reproduce

Page.razor

@foreach (var column in new string[] { "1", "2" })
{
    <Input>
        <Lookup></Lookup>
    </Input>
}

Input.razor

@code
{
    [Parameter]
    public RenderFragment Lookup { get; set; }
}

Expected behavior

Compile without errors.

Actual behavior

error RZ1026: Encountered end tag "Input" with no matching start tag.  Are your start/end tags properly balanced?

Additional information

Doesn't compile inside @if as well.

Workaround

Rename component from Input to CustomInput

[javiercn]

@xiety thanks for contacting us.

This is by design. You are trying to "override" an HTML element and that's not possible as HTML tags are case-insensitive. If you want to have a component named Input then you need to fully qualify its name.

If you switch that to the following it works as expected. ``

` ``

[xiety]

@javiercn, it seems to me that the error is not very informative. And my original sample works normally if you remove only foreach or if you remove only RenderFragment. If this is by design that it should not work anyway.

[rynowak]

This is by design. You are trying to "override" an HTML element and that's not possible as HTML tags are case-insensitive. If you want to have a component named Input then you need to fully qualify its name.

While this isn't something we'd recommend, it also doesn't make sense that we'd err-out in this case. We should take a look at this.

[javiercn]

@rynowak putting this on your plate as its something likely you can only investigate. If you think @ajaybhargavb or @NTaylorMullen can feel free to pass it on.

[NTaylorMullen]

Oh boy this is an interesting one. Without debugging through it and going purely off of memory what I believe is happening is our initial parse of the Razor document is what's generating this error. When the parse sees a void Input tag (tags are case insensitive) inside of a C# block (we enforce well-formed tags) it treats the tag as "complete. When it then sees the end Input tag it has already completed previous Input so it handles the end tag as a malformed unmatched endtag. Later on when we apply Components to the Razor parse tree we then allow the non-void behavior for Input; however, it's too late. An error was already logged from the first parsing phase which we don't end up removing (we don't ever remove errors from the original phase) and it ends up flowing to the end-user.

[mkArtakMSFT]

Given the complexity involved we will be able to achieve this if we enforce "Pascal-casing means Razor component" approach.

[davidmilligan]

encountering a very similar issue when you name a blazor component 'Text'. It works fine most of the time, but there will be random situations where you have to fully qualify the name (e.g. directly inside ifs or foreachs) because it thinks you're trying to use <text> instead of <Text>

[TanayParikh]

Seems like this is an issue with using the Pascal cased names of reserved tag names, in very specific contexts. While this should work in theory, it does have the very simple workaround of not using the reserved names (ie. if a lowercase tag is reserved, consider the Pascal cased tag as reserved as well).

I'm going to leave this open for future tracking, however this'll probably be pretty low on our backlog.

[NTaylorMullen]

While this should work in theory, it does have the very simple workaround of not using the reserved names (ie. if a lowercase tag is reserved, consider the Pascal cased tag as reserved as well).

IIRC I've seen several people use these types of tags indirectly by consuming packages from component vendors 😢