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.

[dougbu]

nit: this looks much more like a prefix than a namespace. let's use term "prefix" going forward.

[shanselman]

I think that the attributes should be italicized in the editor so I can tell what's rendered and what isn't.

[Injac]

I prefer the standard attribute syntax. Nothing more "natural" than:

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

This will help new developers coming from standard web-development to dive in really quick. Without prefixes.

[AnthonyPAlicea]

Personally I think 'data-asp-' or 'data-customprefix-' as a prefix feels more HTML5 standard, and less likely to be confused when integrating with client-side technologies. Great feature though!

[luisrudge]

i prefer like this:

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

[AlexZeitler]

I would like data-asp- or asp:-prefix

[ripberge]

I think asp- would be a good prefix. If there is no prefix, it would be unclear that ASP.NET is going to process these attributes. If you're using italics like Scott suggests, I think that's a VS only solution.

[bradwestness]

+1 for the no-prefix version. It's the cleanest, most obvious format suggested so far in my opinion. The IDE can highlight, with coloring or italics or whatever, that these are "special" server-side attributes.

The prefixes make them look like part of a client-side framework, like angular's ng-whatever="..." attributes. Putting data-whatever="..." on them seems like it would confuse the issue, since that's specifically for client side code and there's nothing to stop me from using data-asp-controller="..." as a perfectly valid data attribute in an HTML app today. It wouldn't be immediately obvious whether a given data- attribute was part of some Bootstrap plumbing, my own custom stuff, or a server-side tag helper.

I don't like the asp: prefix idea because the colon just looks wrong in an HTML attribute name. If anything, I would say a asp- prefix is probably the least-bad alternative after no prefix.

[JakeChampion]

I'd suggest a custom prefix as this aligns correctly with the custom elements draft.

E.G. <asp-a> for anchor tags.

Attribute names do not need to prefix WRT the custom element draft IIRC.

[robertmclaws]

I do not think they should be just plain attributes... it is confusing to me at that point what is going on, is this being processed on the server or the client? There needs to be a crystal-clear distinction. asp: makes me shudder and brings back bad memories of WebForms, better to not further confuse people by making it look like that.

Remembering that we are talking about ASP.NET, and that it runs on the server-side, I think it should either be aspnet- or server-. I think aspnet- would be better, because then it would allow other companies to build their own taghelpers that have their branding in it. For example, I can see Telerik building a <table> taghelper for Kendo UI that would let you build HTML to look like a normal table but render a Kendo Grid. So you'd have code like: <table kendo-datasource="datasourcename"></table>.

Just my $0.02.

[SteveDesmond-ca]

I agree on the prefix helping identify responsibility, and like the idea of using a colon instead of a dash to make it clear, separating it from "regular" attributes.

[pebezo]

I vote for having a prefix. I'm not traumatized by web forms, so for me something like this looks OK:

<prefix:tag attribute="value" />

I vote against using a dash because that's part of the requirement for custom elements (http://www.w3.org/TR/custom-elements/ -- see section 4).

[Tuller]

I'd prefer a prefixed version of some sort.

[fabiomaulo]

if the intention is to approach ppl to HTML5, I prefer the prefixed version. Standard tags attribute as well custom tags could be leaved untouched.

Home <a href="&routename=myway,&direction=up>New way where 'direction' is a variable defined on the route named 'myway'. The tag attribute does not appear magically, what will be changed is its value.

btw... good new for ASP.NET

[fabiomaulo]

Ups..... part of the message was deleted because HTML :( a href="&controller=home,&action=index" input name="&model.Surname" type="&string" a href="&routename=myway,&direction=up"

In short, tags attributes does not appear magically, I can use my custom tag-attributes; what will be changed are some attribute values.

btw good new for asp.net

[nelsonlaquet]

Prefix, please.

How frustrating would it be for someone to put an attribute on an element expecting it to show up in the rendered HTML, for it only to trigger a "tag helper" and produce wildly unexpected behavior? Language design is all about finding a balance between convenience and clarity - and not having a prefix here, I believe, is quite the opposite of clarity for minimal amounts of convenience.

I don't believe the "but it looks more like HTML so people would be more comfortable with it" argument in the slightest. It isn't HTML. People shouldn't, and won't, be automatically aware of a Razor specific feature if they only know straight HTML. When they do become aware of it as a feature, it should be because "oh, hey - that's odd... what is that 'asp:' prefix all about? Must be something that ASP.NET does. Let's look at the docs." instead of "what the...?! Why is my HTML magically turning into something else?!"

A prefix would be less confusing for a person who knows HTML, but not Razor.

As far as a solution that only works in Visual Studio? Although that would make things clear, it would only affect people using VS. Considering one of ASP.NET vNext's major aspects is all about pushing ASP.NET into the cross platform market; this would, symbolically, be a bad move. In addition, not everyone (especially designers, sometimes) use VS to edit view files.

Finally: a prefix would actually make the experience in Visual Studio better. Now you would be able to get an autocomplete popup that only included tag helpers when you started typing a prefix - instead of getting all elements in addition.

Prefixes would also solve naming collisions.

[HaraldMuehlhoffCC]

I wonder what would happen if the W3C decides to add an action or controller ... attribute to some html tags ... Would I have to change my old code if I want to use these new features? Would I have to prefix them with html: ... Would I even be able to use these new features without your proposed "extension" ... Looks nice but doesn't feel right to me! I'd prefer a namespace prefix - that's what they are for!

[JakeChampion]

@HaraldOnline This is why I suggest that this follows the custom-element spec.

[abatishchev]

+1 for prefixes, e.g. aspnet-bla or at least aspnet:bla. Don't break W3C standards!. Please. It's late 2014 outside.

Fow those who appose. Are you crazy? Want yet another IE6 way of doing things?

[joeriks]

What about this one (from Damian Edwards sample):

<input for="UserName" class="form-control" />

which afaiu is the taghelpers replacement for this

@Html.TextBoxFor(m => m.UserName, new { @class = "form-control" })

So I'm guessing the taghelper will add a value="@m.UserName" to the input tag above. But no one can tell just by looking at the syntax. A runat="server" would be helpful there, or perhaps add a @ somewhere?

<@input for="UserName" class="form-control">

[jj09]

+1 for data-asp- (or something starting with data- Will be more compliant with standards(?)

[kedarvaidya]

+1 for '@' as prefix to attributes. For eg: <li><a @controller="Home" @action="Index">Home</a></li>

This can help prevent collisions, eg: form tag's action attribute.

[mg1075]

+1 for prefixes, and as others have already noted, using the razor @ syntax.

Without prefixes, I could envision the act of deciphering the purpose of an element's attribute becoming rather murky, especially in the cases where it is not code you typed just now but code you wrote a month ago or someone else's code you are reviewing for the first time.

[InstyleVII]

I definitely think a prefix would be good for clarity. After that you have to ask yourself what type of prefix. I personally think 'asp-' as a prefix would be solid as it's specific to the language (therefore easy to search) and it's similar to what other frameworks have done (in this case Angular with 'ng-' as a prefix) and short.

Option 1 - 'asp-'

<li><a asp-controller="Home" asp-action="Index">Home</a></li>

Makes me think "What is 'asp-controller'?" to which I would search 'asp-controller', find documentation and bam.

Option 2 - '@'

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

Makes me wonder what I'm even working in as I've never seen an element with an '@' symbol in it before.

Option 3 - 'data-asp-'

<li><a data-asp-controller="Home" data-asp-action="Index">Home</a></li>

Works, but is extremely long and annoying to type (and this would make your highly-decorated elements even longer and more of a pain to manage on-screen).

Conclusion

By most metrics I personally favor Option 1. Short, simple, and other frameworks use a similar style.

[grprakash]

+1 for having prefix, esp the @ A developer needs to differentiate between C# ones and pure HTML ones.

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

[Zettersten]

Whoa! Let's soak this in a bit.

Summary: The razor engine will look for tags (attributes really) and perform some magic.

The idea is fantastic but gets hairy around symantics and syntax.

Some facts:

This is not a client side feature. It doesn't get evaluated by the browser and it never enters a running DOM.

This is a server side feature. It's parsed and evaluated by C# razor. It transforms special attributes into valid html.

The issue:

It's not HTML. Syntax should reflect syntax standards that razor has long communicated. Using the @ sign is a fantastic idea.

Using prefixes feels like the early 90s.

Using normal attributes feels like we are trying to be compliant with the DOM. This will cause a LOT of confusion.

I will say... The idea of adding more declarative template helpers is a good one.

Keep up the good work. Use the @ sign 😁

[divan-9]

In my previous project we used SparkViewEngine. It allows to configure prefix via web.config. And I know, that some developers of my team would prefer to use that prefixes to determine which attribute is related to SparkViewEngine. But from my experience it doesn't matter, when you work with syntax a little bit longer than a week, you can easy understand when tag is rendered on client side and when it's just template construction. In my opinion markup without prefixes looks cleaner. Example from Spark btw: <div if="model.IsEmpty" > ... </div> vs <div spark:if="model.IsEmpty" > ... </div>

Is it possible to use TagHelper to implement conditions like Spark do?

[pacoweb]

Another vote for (asp- prefix)

If the end both options are allowed (with or without prefix) would also be interesting to optionally define at page/application level the type of prefix to use . I would not be in the same view code with prefixes and code without.

<li><a asp-controller="Home" asp-action="Index">Home</a></li>
<li><a controller="Home" action="Index">Home</a></li>

[joeriks]

I like the initial suggestion just like it is - optional on the tag. Also - one of the most interesting features with tag helpers IMO is transforming plain html just by adding taghelper assemblies to the view. ( If we like to be explicit we can still use the old @-helpers. )

The designer needs to show which tags the taghelper assemblies will interact with (like Scott Hanselman said) + it would be great if it also helped us with intellisense, type checking and go to definition.

[nzwebguy]

We are already used to defining server side code in razor using @ so +1 for the same prefix on the attributes to be processed on the server

[toddmeinershagen]

I am totally in agreement with the comments from InstyleVII. The preferred option being "asp-controller" and "asp-action" respectively,

[judas-christ]

+1 for prefixes, preferably asp-* for many reasons already mentioned and also for Intellisense (might have missed it if it's already been mentioned). Would be totally awesome to just type asp- on a tag and get all available TagHelpers.

data-asp-* I think is a bad idea, because it's quite possible that someone uses data-action for instance already. I know I do. And also, it doesn't have to be valid HTML since it's server side.

[VolkmarR]

+1 for prefixes. maybe you can support "asp-" for everyone that preferes a clearly understandable prefix and "@" as shortcut for everybody that want's to type less..

[Mark320]

+1 for prefixes. Makes sense to use @ since that is what people are used to in Razor. Also highlights difference between client side and server side by using the @ rather than other prefixes.

[mikakolari]

+1 for prefix.

Because maybe next version of html adds foo attribute (or maybe there already is, how knows them all?)

<div foo="process this">...</div>

But @ is not good

@{
    var controller = "foo";
}
<a @controller="@controller">...</a>

I would like to have support for 1) standard tags with mandatory attribute prefix

// configure per page or globally
@prefix x Namespace.Of.The.Aspnet
@prefix y Custom.Namespace
<a class="link" x:controller="foo" x:action="bar" y:class="baz">...</a>

2) custom tags without redundant attribute prefix

<my:img src="@image.Id" />
<your:img src="@image.Id" />

[HaraldMuehlhoffCC]

@mikakolari Agreed! That's what I meant by "I'd prefer a namespace prefix - that's what they are for!". The namespace prefix a: would be ideal as a default for asp.net ;) like <a class="link" a:action="bar" a:controller="foo">...</a>; also <a:img ...

[marinasundstrom]

I like the clean prefix-less syntax:

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

It is clear and expresses the intent within ASP.NET.

And it is just server-side code so I don't see any problem.

I do however think that prefices like "asp-" or "asp:" (XML-ish) or "@" should be optional for those who prefer that because of either esthetics or clarity, or even require that for some reason.

And if those attributes ("controller", "action" etc.) get added to the HTML standard for some currently unimaginable feature then you just can choose to override or enforce them.

Please don't make this such a big issue.

ASP.NET is about giving developers a choice. Within reasonable limits, of course.

Make it optional.

[chrispellett]

+1 for either tag or attribute prefixes (e.g. data-controller, asp-controller or asp-a)

[AlonCG]

Agree with many above, a think a prefix is absolutely necessary. I like "@" or "asp" prefix, just something that would not confuse my "UI guys" that don't use VS.

[flipchart]

+1 for @ prefixed attributes: it seems consistent with current Razor syntax, it very clearly differentiates the server side attributes from any client side attributes, and opens up the potential for more intelligent intellisense (after typing @ the drop down could change to offer only taghelper attributes, rather than standard HTML attributes)

Also, in my mind, the developer always wants these tags replaced, and if they can't (invalid attribute - i.e. doesn't have a taghelper associated), there should be an error. If we use a prefixed attribute like "asp-", then if we use an attribute which isn't associated with a helper (because we misspelled it, or it isn't loaded like we thought it was), then it will end up on the client side - silently. You could then say that all "asp-" prefixed attributes are for taghelpers, and therefore throw an error as in the previous case, but then a user could never have an "asp-" prefixed attribute on the client side, which might be what the user actually wants. Then s/he'd have to escape the attribute which is never pretty

[mikakolari]

Without prefix, how do you know whether the id in the case below is part of the route or the element id? And how can one use both at the same time?

<a controller="Products" action="Edit" id="@product.Id">Edit</a>

[robinsmithuk]

I like the simplicity of

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

but I also want to be able to at a glance see what is a server side tag. How about an additional attribute to denote it is server side.

<li><a controller="Home" action="Index" asp="true">Home</a></li>

Just as long as it's not

<li><a controller="Home" action="Index" runat="server">Home</a></li>

That's too old school... :-)

[chrfin]

@HaraldOnline and @mikakolari - I agree with you. Use a prefix and make it namespace-dependent. a: as a default for ASP.NET and others like e.g. k: can then be used/defined for e.g. KendoUI. Also TAG: has some similarity to XAML, so is not a complete "new invention".

[jameshulse]

Using the razor prefix '@' will make it familiar for developers used to this convention. It also clearly indicates which attributes are evaluated server-side and which will be rendered to the client. So I am a big fan of this:

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

It should allow support for vendor prefixed attributes, and attributes without values:

<input type="text" @my-validation />

[diegofrata]

Use prefixes! Don't even thinking about introducing attributes that will get confused with standard HTML or end up clashing with JS libs.

Go with asp-controller.

[nfplee]

If you go for the prefix approach then do not use data-*. Data is used for valid HTML 5 markup. However since it is not rendered then it is irrelevant. I think this will lead to another level of confusion.

[luisrudge]

I think this has to be Configurable. Put the prefix finder behind an interface and let people use whatever they want.

DONE

[Lejdholt]

+1 for @

[chrfin]

Just @ won't work well - see e.g. @mikakolari example...

[doobiwan]

Prefix +1.

I like @, or @:, it stands out in a simple text editor, but @mikakolari makes a very good point re namespaces, so I would vote for the:

@prefix "foo-" namespace.foo

Which could in theory let you specify '-' or ':' or even '@'.