Create prefixes for tag helpers

[NTaylorMullen]

This will involve modifying the @taghelper "assemblyname" directive to be something like @taghelper "assemblyname" "prefix".

This in turn will enforce certain restrictions on generating/understanding tag helpers.

Ex: If you do @taghelper "MyAssembly" "r-" that means that all tag helpers in _MyAssembly_ must be prefixed with _r-_.

<r-my-taghelper /> <!-- Runs the my-taghelper helper -->

Should discuss if we want to support prefixes at the C# tag helper level.

[RobCannon]

Please use the prefixes and I prefer asp-. It make it much clearer that these are not HTML attributes. This will become more important with web components when there will be new attribute names that are 'native' to that component. The prefix will make it clear that this is something processed by ASP.Net and is not being handled by something in the browser.

[MichaCo]

+1 for prefix. I think it is important to indicate what happens with the tag.

a) It must be totally transparent which part gets evaluated by razor and what part will stay as it is and just posted to the client b) You don't want to have to think about the meaning of the attribute only because of its name... what it the name collides or is an edge case where both sides could do something with it? Would be a mess...

I'd also prefer the @ syntax, so

<tag @mvcAttribute="value" htmlAttribute="value" />

looks totally logical for me

If @ really doesn't work, lets use namespace syntax

<tag asp:mvcAttribute="value" htmlAttribute="value" />

[chrfin]

Or maybe a new "@-combination" like @: is for text: <tag @~mvcAttribute="value" htmlAttribute="value" />

[no1traveller]

My vote is for a tag-prefix with a different symbol (@something and @:something both already have meaning):

<@!a controller="c" action="a" class="c">Link</@!a>

The advantage of this is that if you have a very long code block, you can still see whether it was an asp.net tag or a html tag at the end easily.

Alternatively using an attribute prefix net-, or a-n- (a sp -n et) would be okay but my second choice.

<a net-controller="c" net-action="a" class="c">Link</a>
<a a-n-controller="c" a-n-action="a" class="c">Link</a>

Not including a prefix increases the chance of collisions with front-end frameworks.

[AlonCG]

I think '@' is simple (maybe even elegant). Regarding @mikakolari ... If we are in a server-side attribute ... would we necessarily need to make that value also server-side? Meaning ... could this be a possibility: ... <a @controller="controller">...</a> The @controller is already depicting something server-side or whatnot, so its' value assigned would also already be from the server-side code. Of course that would only be intuitive for server variables defined close to their usage ... so maybe this is a dumb idea :)

[rikvandenberg]

I'm more of a fan of colons (see example @mikakolari) then the hyphen option. Angular already has it's custom attributes with the prefix 'ng' and I don't want to think about any possible conflicts. It could cause some confusing when people develop application using both ASP.NET MVC/API with AngularJS. What attribute is for what framework? It should be something that is clear for the developer, but also clear in any (omnisharp) editor I work with, as we are targeting OSX and Linux to develop these applications.

[fredrik-holmqvist]

I think @ as a prefix is a great idea, razor already used it today so it's the natural way to go

[rafaelzaccanini]

+1 for prefix (like asp-), in my opinion is absolutely necessary but I also think this has to be configurable.

[kevfromireland]

+1 for prefix.

[jasonmitchell]

+1 for asp-* prefix or @ as suggested above.

It reads well without the prefix (e.g. controller="Home") but I think there should be a distinction between tag helper attributes and standard HTML attributes.

[MikeSQ]

I would prefer having SOME symbol to differentiate server attributes from rendered attributes. Scanning visually down the code it will allow for the feature to pop out and quickly highlight there is server processing going on.

Also, for people who are unfamiliar with the concept of a tag helper, it would help immensely in their Google/Bing searches. "Hey what is going on with this link with this tag with funny attributes" vs a substantially less helpful search of "a controller attribute"

I think @mikakolari makes some sensible points on why @ may not be a good choice, but we need something to decorate the tags in my opinion.

[himynameistim]

+1 for asp- prefix.

If there's no prefix there will ultimately be a conflict at some point and we'll end up with things like CssClass. One of Razors biggest strengths is that all html is valid to put in a view, if anything ever messed with that it would be a disaster.

[alastairanderson]

+1 for '@' as prefix to attributes as per @kedarvaidya suggestion.

[timplourde]

Please use the asp- prefix.

We have so many attributes these days it's challenging to tell them apart. Whatever additional visual treatment you give them in the IDE is secondary.

[joeriks]

Consider the input-tag as found in Fowlers example again

<input type="text" for="UserName" />

With full-magic-mode that one would transform to

<input type="text" for="UserName" value="@Model.UserName"/>

With some prefix the transformation would indeed be more obvious

<input type="text" asp-for="UserName" />

However - the value-attribute appeared magically from out of nowhere, are you saying we should need a prefix for that one too?

<input type="text" asp-for="UserName" asp-value="UserName" />

Not very handy IMO.

Isn't it the tag which is the starting point for all the magic, and where we should add some kind of syntax to make it obvious something is going to happen at render time? Note that the transformation might happen on any attribute inside the tag, and even sometimes on the tag contents (as on a form):

<asp-input type="text" for="UserName" />

<asp-form>
    <asp-input ...>
</asp-form>

[jameshulse]

Another idea would be to mark the tag as server side in true Razor style:

@<a controller="Home" action="Index">Link Text</a>

This might make the Razor implementation easier, it doesn't seem to clash with existing behaviour but may raise other issues such as what happens with embedded tags in this case:

@<a controller="Home" action="Index"><span>Link</span></a>

Would the <span> be server side rendered too? Just another idea that hasn't popped up yet.

[abelgaxiola]

+1 for prefix. I like to be able to identify outside of the IDE.

[ssteward54]

I second the idea of using the @ prefix for the attributes, simple but also designates them as server side tags.

[jpjerkins]

I would greatly appreciate some kind of prefix on these server-side-only attributes. It would help keep these attributes from getting confused (or even conflicting) with custom client-side attributes. Our team at work is considering Angular for a rewrite of our main business application, and having different prefixes on both server- and client-side attributes would avoid any confusion for developers new to the code.

[ThorstenHans]

I would also prefer the asp- prefex instead of using any kind of visual seperation in visual studio. Think of devs using other editors like sublime or vim.

Having a prefix like asp- would also match the pattern AngularJS is following when it comes to custom directives

[vansimke]

This feels like JSTL from Java which is, in my opinion, one of only areas that I have always felt Java has gotten it better that ASP.NET. They use prefixes to denote the different context (which is, after all, the purpose). I think that

as HTML tag and asp:form as Razor tag gives better hinting to code maintainers about what is going on. As an enterprise developer, maintainability matters.

If I were making the call, I would keep the @ syntax and add in the tag helpers with namespace prefixes ala JSTL (https://jstl.java.net/)

[LeapingGorilla]

Definitely prefer a prefix. It signals intent - the intent being that these are parsed on the server. How can you output a reserved attribute name without it triggering a tag helper? If some framework in the future decides it wants a controller="blah" attribute for the Next Big Thing(tm) prefixing will help us pre-emptively sidestep it before it begins.

As for the style of prefix, I prefer asp- but also like the suggested @ syntax. asp- implies namespacing which I like. It's clean and clear.

Bonus points for calling it out in the editor as well.

[burtonrodman]

I vote for no prefix or a prefix on the ELEMENT, not the attributes

[jwheron]

If you're serious modifying text styles, give us a set of options in the font settings in Visual Studio. I vote against italics because I have a difficult time reading italicized text. I would rather have these attributes appear with different colors, and certainly it sounds like different people feel other ways..

I vote for data-asp- as a prefix for this functionality.

I dislike the WebForms style of having an asp: tag prefix. We're talking about modifying a few of the attributes on a tag -- taking over the entire tag to denote that we're using a few specialized properties strikes me as a code smell and bad design.

[chrfin]

IMO it needs to be defined on the attribute and not on the tag, as you could have different helpers for different attributes within the same tag...

[pebezo]

It seems to me like the question was about TAG prefixes while most people are talking about ATTRIBUTE prefixes. Basically:

<my-tag class="test" style="color:red" controller="Home" action="Index />

1. Should tag elements have a prefix, like <vendor:my-tag ... /> or <@my-tag ... /> or just <my-tag ... />?
2. Should server-side attributes have prefixes, so controller="Home" vs asp:controller="Home" or asp-controller="Home" or "@controller="Home" or ~controller="Home" etc.

Thoughts (after reading most comments)

1. Tags should have a prefix by default, like <asp:my-tag ... /> (using just dashes like <asp-my-tag .. /> would conflict with HTML custom elements), but should be optional (maybe I want to change how all the <a> tags work in all the views).
2. For attributes, if I understand how tag helpers work, it would be pointless to mark certain attributes as server-side since the tag helper could access/change any of the attributes anyway. So if I have <a href="#something" class="foo" controller="Home" /> the tag helper could change the "class" or "controller" attribute whether I mark it as server-side or not. So once a tag element is "linked" with a tag helper all bets are off (all attributes are up for grabs).

[ahmedshuhel]

+1 for non prefixed syntax. It's clean.

This is a razor feature which is exclusively server side. So being html5 compliant by adding data-* seems not to be the issue here as long as it gets rendered as standard compliant html later.

[rodrigopires]

+1 for Prefix.

[Codeglee]

Just to be counted, my preference is for @controller @index syntax. Anything else just adds extra characters and reduces it's readability imo, especially with the longer overrides, I don't think anyone longs for the days of asp:HyperLink let's not drive backwards.

Also there are some confused arguments in the thread, this is at compile time, when the page is being rendered, not what the client receives. Look up Razor syntax and HTML Helpers, they're awesome (compared to what we had before).

[toddsay]

+1 for a prefix, such as the "asp:" namespacing concept (or make it configurable and make everybody happy, but definitely a prefix by default). "asp-" would work too, but I like the namespacing because that is really what we are dealing with here. Without a prefix it's just too confusing as to what is HTML vs. HTML vNext vs. client extensions vs. server extensions. You may know the difference, but the next person looking at your code may not.

[jusbuc2k]

I think the @ sign prefix makes the most sense since we use that all over in razor anyway.

<@a controller="Home" action="Index">Home</a> or maybe... <a @controller="Home" @action="Index">Home</a>

The former could have the entire element colored differently in VS to show that parts of it are server side rendered.

[StuartQ]

My vote is for an escape character, preferably @:

<a @controller="Home" @action="Index">Home</a>

However, I accept that using the actual @ character could cause issues, as mentioned by above. It looks to me like you're trying to assign "Home" to a variable named controller. Having said that, the above is currently illegal markup, so could Razor be smart enough to infer the correct behaviour based on the fact that you're inside a tag?

I'm very strongly against the current proposed prefix-less solution. What if you ever wanted an actual attribute called controller? Could we add our own tag helpers, and might these server side attributes clash with the names of existing client attributes?

Given the new focus on not relying on VS support, the fact that Scott feels the need for some tooling to indicate when an attribute is rendered server-side and when it's simply passed to the client is an indicator that the current design isn't obvious. The behaviour should be obvious in Notepad and as it stands, it's not.

[WilldotNET]

I would go with either @ prefix or just colour it differently in VS - purple works for me!

[TheSavage]

+1 for (a short) prefix

[awh112]

+1 for prefix, for reasons many have mentioned above (clear intent, clean, etc.). As for the style, I prefer @, as most would already be familiar with it for Razor and it clearly differentiates from standard HTML attributes.

[mikece]

Ideally: @ syntax. Fallback: asp- syntax. Reasoning: don't blur the lines between what designers are allowed to touch and what is the domain of the devs.

[deckmc]

+1 for prefix, my personal preference would probably be asp-, but anything simple would work.

[calvin-fisher]

It must have a prefix, otherwise it would create confusing and opaque behavior. If I wanted to have an Angular directive called "action" in my front-end code, un-prefixed tags would seem to prevent that.

The @ prefix seems best, since it would clearly indicate that there is server-side logic going on.

I think the @mikakolari example misunderstands the @ proposal; note how there are two @ symbols in one statement. This is how @ prefix would look with a convoluted HTML tag:

<a id="@model.HomeLinkId" class="homeLink" @controller="Home" @action=model.HomeAction>
    @model.HomeLinkText
</a>

[eric-king]

Another vote in favor of using a prefix. I prefer @, for the same reason as many others: it would clearly indicate that the tag exists for server-side processing.

[TheCloudlessSky]

+1 for using the @ prefix since it creates familiar Razor code (@ is already a convention) and clearly shows that it's server rendered. The non-prefix or even "asp-" prefix really aren't clear. I don't want to mix HTML and C# to the point where we're back to Web Forms...

[InstyleVII]

One thing to note for people in favor of the '@' prefix, it isn't searchable. It doesn't make it clear that it's server side but searching @Controller is not going to give good results. Something more unique like 'asp-' wont have that issue, and it isn't used by tons of social networks (such as Twitter).

Another note for people in favor of editor showing it grayed out to denote server side, what about people not working in Visual Studio? I don't think relying on that alone will be enough for most end users, it should have a prefix. Maybe you can still gray out in editors with the prefix to denote it's server side, but a prefix should still be there.

[calvin-fisher]

@InstyleVII do you mean searchable in Google? Actually, at a glance, the searches Controller, @Controller, and "@Controller" all produce different results, the last one all dealing with the Spring MVC usage of @Controller.

[InstyleVII]

@calvin-fisher Yeah, with quotes would produce the best results, but with asp-controller it would be specific enough that quotes wouldn't be needed, neither would a reference to .net or other terms. Just a nice to have imo. Also different engines for different people, in Bing all three bring up controller.com as the top result. asp-controller brings up a w3c page and other related results.

[ctolkien]

I think this should be an element prefix, not attribute - that way it's much easier to determine what is server side and what is client side.

I also have some concerns about editors (other than VS, which obviously will have support) whinging about attributes which aren't valid HTML.

I'd prefer something like @<a or <@a or even <asp-a (but now it starts to feel like we're heading back to webforms territory).

[plioi]

The @ symbol would be the idea prefix because we already use it in Razor views to signify the shift from client side to server side, and then you also avoid naming conflicts such as "action means controller action here, but action means form action in a form tag" malarkey. Anything more than "@" will just be noise.

[eddiegroves]

+1 for the prefix optionally applying to the tag and the attributes

@<form controller="blah" @action="blah" // @action to clearly state this is TagHelper magic

[Meligy]

If you are going this route (more markup-focused than code-focused), just give us SparkViewEngine, I mean really. If you are going more code focused, give us HtmlTags.

If you prefer to go with what you have, I agree using a prefix is a must, and I agree using @ will be nice but I also imagine it'll be very hard technically to implement, as it's being used already for invoking existing good old Razor @helpers.

In that case, I'd go with asp- (not data-asp-, for two reasons: it's NOT Html -which needs to be obvious-, and it's longer for no good reason). Not fussed about - or : or whatever either.

[manigandham]

+1 for prefixes on the attributes.

That's the purest way to signal that this is a HTML element that has some attributes that will be processed server side. No prefixes muddles the intent and causes nothing but confusion for (front-end) developers who might not be familiar with asp.net.

[drmcclelland]

+1 for the @ prefix - if TagHelpers are a Razor-specific idea it makes sense to me to keep going forward with that syntax. A prefix is important to me so I can see what is my "server-side" code vs. my "client-side" code when I'm in the IDE.

[TimMurphy]

Prefix is a must.

• @ is terse & clearly server side attribute
• asp: less terse but clearly server side attribute
• asp- is ok but possibly confused with client side