Aspnetcore: Component tag helper matching should be case-sensitive

[vertonghenb]

Initially started in #1155, make it possible to only match Blazor components as named by the C# class.
The following 2 snippets are not equal:

<Form>
...
</Form>

is not equal to (mind the casing)

<form>
...
</form>

We could make it easier for component libraries as BlazorStrap for example, which has a workaround. Basically this is also what React does.

I'm not really sure if this is Blazor or Razor specific, so if I'm mistaken I do apologise.

[chucker]

As far as I see, Blazor is in a weird in-between state of HTML and XHTML:

• the generated index.html says in its DOCTYPE that it is HTML.
• however, to use component tags, you need to abide by XHTML rules, perhaps as an artifact of Razor. (That is, tags have to explicitly be followed by a close tag or be self-closing).

This issue would make Blazor it even less HTML-like: HTML5 explicitly says that tag names are case-insensitive:

Many strings in the HTML syntax (e.g., the names of elements and their attributes) are case-insensitive, but only for uppercase ASCII letters and lowercase ASCII letters. For convenience, in this section this is just referred to as "case-insensitive".
[..]
In the HTML syntax, tag names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the element’s tag name; tag names are case-insensitive.

As such, the two ways to resolve this discrepancy would be:

1. to explicitly and unapologetically make Blazor XHTML. That is, change the DOCTYPE in the generated index.html.

2. given the origin of this bug (#1155), to _leave_ it an error to have a component named <Summary> (in that issue) or <Form> (in this one), but to make the error message more explicit about what is going wrong, e.g.:

   BL0123: Cannot emit component: component name conflicts with existing HTML5 tag name

I don't think introducing case-sensitivity to extend a language that is explicitly case-insensitive is a good path.

[SteveSandersonMS]

@chucker Razor isn't HTML - it's a combination of HTML and C#. So I don't think there's any moral problem by having Razor-specific rules (e.g., for casing) about Razor-specific tags (e.g., for components).

Having case-sensitivity for the component syntax wouldn't change the doctype. The doctype is an artifact seen by the browser and represents the output from a component rather than the syntax of the original source file on disk.

[vertonghenb]

Since we're doing https://github.com/aspnet/Blazor/issues/610

Can't we also integrate this one in 0.7.0? Component Library creators will be thankfull!

[danroth27]

@rynowak What's the work involved with enabling case sensitivity for components?

[rynowak]

This is not possible to do without changes to Razor and VS

[danroth27]

Moving to backlog

[stsrki]

I'm creating a component library and because of this problem I'm unable to have e meaningful named components like Button, Text, For, etc. Do you have an information when this feature be available? Has anyone actually started fixing this problem?

@rynowak

This is not possible to do without changes to Razor and VS

Do you know if and when is this planned in the Razor?

[danroth27]

@stsrki This work is planned as part of the .NET Core 3.0 & VS 2019 efforts.

[mkArtakMSFT]

@rynowak, @danroth bringing this back to preview4 to handle the case-sensitive components completion.

[ajaybhargavb]

Looks like this work will require VS changes. We don't have any planned insertions to VS preview1. Shouldn't this be post preview4 then?

[rynowak]

Let's get it done when we can. If it doesn't ship right away that's ok.

[ajaybhargavb]

Spoke offline. Moving to preview6.

[vertonghenb]

Agreed that it's not a first priority but keep in mind that component library creators will love this idea.

[rynowak]

Thanks for the feedback. We're using https://github.com/aspnet/AspNetCore/issues/9860 to track this.