[API Proposal]: CSS Class List String Syntax

[Peter-Juhasz]

Background and motivation

It would help to support many web development scenarios (especially Blazor) and unlock potential cross-language editor features if we had a StringSyntax for CSS Class Lists:

• syntax error checking
• reference highlight of CSS class names
• code completion for class names

API Proposal

namespace System.Diagnostics.CodeAnalysis;

public sealed class StringSyntaxAttribute : Attribute
{
    public const string CssClassList = "CssClassList";
}

API Usage

Customers could annotate that Blazor components which accept additional CSS classes:

using Microsoft.AspNetCore.Components;
using System.Diagnostics.CodeAnalysis;

public class MyComponent : ComponentBase
{
	[Parameter]
	[StringSyntax(StringSyntaxAttribute.CssClassList)]
   	public string? CssClass { get; set; }
}

<MyComponent CssClass="first second" />

Or other helper methods:

using System.Diagnostics.CodeAnalysis;

public static class CssBuilder
{
	public static string? Combine([StringSyntax(StringSyntaxAttribute.CssClassList)] string? class1, [StringSyntax(StringSyntaxAttribute.CssClassList)] string? class2) => (class1, class2) switch
	{
		(not null, null) => class1,
		(not null, not null) => $"{class1} {class2}",
		(null, null) => null,
		(null, not null) => class2,
	};
}

<div class="@CssBuilder.Combine("first", "second")"></div>

Alternative Designs

No response

Risks

It is a simple feature with a very simple grammar, which is broadly used everywhere, I see no risks with adding it.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

[tannergooding]

CC. @stephentoub and @CyrusNajmabadi as I think you’re the two that have done the most around this space

I expect this would potentially require IDE work and other considerations

[CyrusNajmabadi]

We (roslyn) woudl be willing to do the same thing we did with the runtime for ASP.Net route syntax. Specifically, using an internal extensibility point to allow another 1p to do the lexing/parsing and other feature work. We would expose the hookup points for this.

--

I'd also have to lookup how we did the asp.net route stuff. It's possible that this work can just piggy back off of what is already available there.

Roslyn is fine with helping with htis. But we have a hard rule that we're not going to own any more languages (including having the code live in our repo). That has to be owned by another team in an external repo.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Peter-Juhasz]

I expect this would potentially require IDE work and other considerations

I did not mean implementing the actual IDE tooling work or grammar in Roslyn in this ticket, only unlocking any potential work related by adding a new string syntax definition.

I'd also have to lookup how we did the asp.net route stuff. It's possible that this work can just piggy back off of what is already available there.

I'm not sure though this belongs to the runtime repository. Alongside Json and Xml it may make sense. Adding it to ASP.NET may also make sense just like the route syntax, but as it is right now in ASP.NET codebase, is not that easily consumable: because it is simply a "Route" constant without any registry like the StringSyntaxAttribute class itself. What do you think would be the right place?