New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create prefixes for tag helpers #88

Closed
NTaylorMullen opened this Issue Aug 18, 2014 · 257 comments

Comments

Projects
None yet
@NTaylorMullen
Member

NTaylorMullen commented Aug 18, 2014

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.

@NTaylorMullen NTaylorMullen added this to the 4.0.0-beta1 milestone Aug 18, 2014

@NTaylorMullen NTaylorMullen self-assigned this Aug 18, 2014

@dougbu

This comment has been minimized.

Show comment
Hide comment
@dougbu

dougbu Aug 18, 2014

Member

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

Member

dougbu commented Aug 18, 2014

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

@danroth27 danroth27 modified the milestones: 4.0.0-rc1, 4.0.0-beta1 Sep 4, 2014

@danroth27 danroth27 added 0 - Backlog and removed 1 - Ready labels Sep 4, 2014

@NTaylorMullen NTaylorMullen changed the title from Tag Helpers: Create namespaces for tag helpers to Tag Helpers: Create prefixes for tag helpers Nov 20, 2014

@shanselman

This comment has been minimized.

Show comment
Hide comment
@shanselman

shanselman Nov 20, 2014

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

shanselman commented Nov 20, 2014

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

@Injac

This comment has been minimized.

Show comment
Hide comment
@Injac

Injac Nov 20, 2014

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.

Injac commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@AnthonyPAlicea

AnthonyPAlicea Nov 20, 2014

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!

AnthonyPAlicea commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge Nov 20, 2014

i prefer like this:

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

luisrudge commented Nov 20, 2014

i prefer like this:

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

@AlexZeitler

This comment has been minimized.

Show comment
Hide comment
@AlexZeitler

AlexZeitler Nov 20, 2014

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

AlexZeitler commented Nov 20, 2014

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 20, 2014

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.

ghost commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bradwestness

bradwestness Nov 20, 2014

+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.

bradwestness commented Nov 20, 2014

+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

This comment has been minimized.

Show comment
Hide comment
@JakeChampion

JakeChampion Nov 20, 2014

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.

JakeChampion commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@robertmclaws

robertmclaws Nov 20, 2014

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.

robertmclaws commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@stevedesmond-ca

stevedesmond-ca Nov 20, 2014

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.

stevedesmond-ca commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@pebezo

pebezo Nov 20, 2014

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).

pebezo commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Tuller

Tuller Nov 20, 2014

I'd prefer a prefixed version of some sort.

Tuller commented Nov 20, 2014

I'd prefer a prefixed version of some sort.

@fabiomaulo

This comment has been minimized.

Show comment
Hide comment
@fabiomaulo

fabiomaulo Nov 20, 2014

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 commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@fabiomaulo

fabiomaulo Nov 20, 2014

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

fabiomaulo commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@nelsonlaquet

nelsonlaquet Nov 20, 2014

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.

nelsonlaquet commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@HaraldMuehlhoffCC

HaraldMuehlhoffCC Nov 20, 2014

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!

HaraldMuehlhoffCC commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@JakeChampion

JakeChampion Nov 20, 2014

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

JakeChampion commented Nov 20, 2014

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

@abatishchev

This comment has been minimized.

Show comment
Hide comment
@abatishchev

abatishchev Nov 20, 2014

+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?

abatishchev commented Nov 20, 2014

+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

This comment has been minimized.

Show comment
Hide comment
@joeriks

joeriks Nov 20, 2014

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">

joeriks commented Nov 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jj09

jj09 Nov 20, 2014

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

jj09 commented Nov 20, 2014

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

@mlmathews

This comment has been minimized.

Show comment
Hide comment
@mlmathews

mlmathews Jan 17, 2015

I think there should be some clear indication that an attribute is an ASP.Net attribute. A prefix convention seems like the simplest solution. The solution should not rely on Visual Studio syntax highlighting.

mlmathews commented Jan 17, 2015

I think there should be some clear indication that an attribute is an ASP.Net attribute. A prefix convention seems like the simplest solution. The solution should not rely on Visual Studio syntax highlighting.

@egorpavlikhin

This comment has been minimized.

Show comment
Hide comment
@egorpavlikhin

egorpavlikhin Jan 19, 2015

+1 for @ prefix for tags, not attributes

I agree with @glen-84, this whole thing looks and smells an awful lot like webforms.

egorpavlikhin commented Jan 19, 2015

+1 for @ prefix for tags, not attributes

I agree with @glen-84, this whole thing looks and smells an awful lot like webforms.

@DWAK-ATTK

This comment has been minimized.

Show comment
Hide comment
@DWAK-ATTK

DWAK-ATTK Jan 22, 2015

I agree with @michaelherndon's comment. Prefixes on both the html element (tag) and attribute level should be optional and left up to the designer/coder.

Personally I like the syntax that has no prefixes.

I definitely hate the data- prefix. Server-side and client-side should never "see" each other. If you force the data- syntax (e.g. data-action) then there would be no way to specify that data- attribute for the client. As data- attributes are part of the HTML 5 spec (a client-side technology) it would be very confusing for people to start seeing it in the context of server-side code. Especially when data- tags are mixed: (

  • ). Can you tell what is server-side and what is client side just by looking at that?

  • DWAK-ATTK commented Jan 22, 2015

    I agree with @michaelherndon's comment. Prefixes on both the html element (tag) and attribute level should be optional and left up to the designer/coder.

    Personally I like the syntax that has no prefixes.

    I definitely hate the data- prefix. Server-side and client-side should never "see" each other. If you force the data- syntax (e.g. data-action) then there would be no way to specify that data- attribute for the client. As data- attributes are part of the HTML 5 spec (a client-side technology) it would be very confusing for people to start seeing it in the context of server-side code. Especially when data- tags are mixed: (

  • ). Can you tell what is server-side and what is client side just by looking at that?

  • @NTaylorMullen NTaylorMullen changed the title from Tag Helpers: Create prefixes for tag helpers to Create prefixes for tag helpers Jan 23, 2015

    @safakgur

    This comment has been minimized.

    Show comment
    Hide comment
    @safakgur

    safakgur Jan 28, 2015

    +1 for prefixes
    If I write a plain attribute, I expect it to show up on the client side.
    So there must be a prefix that's illegal in plain HTML to make it crystal clear that the attribute is not intended to be rendered directly, but to manipulate the tag using a server-side "tag helper".

    Doesn't matter if the prefix is @, asp: or some other thing.

    <a action="Index">Just no.</a>
    <a data-asp-action="Index">Nothing that starts with "data-", no.</a>
    <a asp-action="Index">"asp-" is not a valid prefix for an HTML attribute, that's good.</a>
    <a asp:action="Index">Same with "asp-", it's clear that it is server-side.</a>

    safakgur commented Jan 28, 2015

    +1 for prefixes
    If I write a plain attribute, I expect it to show up on the client side.
    So there must be a prefix that's illegal in plain HTML to make it crystal clear that the attribute is not intended to be rendered directly, but to manipulate the tag using a server-side "tag helper".

    Doesn't matter if the prefix is @, asp: or some other thing.

    <a action="Index">Just no.</a>
    <a data-asp-action="Index">Nothing that starts with "data-", no.</a>
    <a asp-action="Index">"asp-" is not a valid prefix for an HTML attribute, that's good.</a>
    <a asp:action="Index">Same with "asp-", it's clear that it is server-side.</a>
    @DWAK-ATTK

    This comment has been minimized.

    Show comment
    Hide comment
    @DWAK-ATTK

    DWAK-ATTK Jan 30, 2015

    After giving this some more thought - I believe TagHelpers are a terrible feature.

    1. You will never find a syntax that makes designers AND developers happy.
    2. We already have these kinds of helper tools via @html and @url helpers.
      a. If @html and @url helpers don't have what you need, write an extension method that suits you.
    3. The potential for absolute mayhem is very high with this feature. It dilutes the MVC/Razor framework.
    4. It doesn't add anything to Razor. I would think this would be much more appropriate in the WebForms engine rather than the Razor engine.

    I, apparently, fail to see what problem TagHelpers is trying to solve. Is there a legitimate need for this or is it just someone's idea of a fun syntactic sugar?

    Instead of TagHelpers I would think making the Razor engine extensible so that things like TagHelpers can be plugged into the engine would be a better use of Team Razor's time. Make Razor extensible and then write TagHelpers as an example optional plugin that can be loaded via NuGet.

    DWAK-ATTK commented Jan 30, 2015

    After giving this some more thought - I believe TagHelpers are a terrible feature.

    1. You will never find a syntax that makes designers AND developers happy.
    2. We already have these kinds of helper tools via @html and @url helpers.
      a. If @html and @url helpers don't have what you need, write an extension method that suits you.
    3. The potential for absolute mayhem is very high with this feature. It dilutes the MVC/Razor framework.
    4. It doesn't add anything to Razor. I would think this would be much more appropriate in the WebForms engine rather than the Razor engine.

    I, apparently, fail to see what problem TagHelpers is trying to solve. Is there a legitimate need for this or is it just someone's idea of a fun syntactic sugar?

    Instead of TagHelpers I would think making the Razor engine extensible so that things like TagHelpers can be plugged into the engine would be a better use of Team Razor's time. Make Razor extensible and then write TagHelpers as an example optional plugin that can be loaded via NuGet.

    @glen-84

    This comment has been minimized.

    Show comment
    Hide comment
    @glen-84

    glen-84 Jan 30, 2015

    Instead of TagHelpers I would think making the Razor engine extensible so that things like TagHelpers can be plugged into the engine would be a better use of Team Razor's time. Make Razor extensible and then write TagHelpers as an example optional plugin that can be loaded via NuGet

    I agree 100%.

    @DamianEdwards Is it too late for a change like this?

    glen-84 commented Jan 30, 2015

    Instead of TagHelpers I would think making the Razor engine extensible so that things like TagHelpers can be plugged into the engine would be a better use of Team Razor's time. Make Razor extensible and then write TagHelpers as an example optional plugin that can be loaded via NuGet

    I agree 100%.

    @DamianEdwards Is it too late for a change like this?

    @nvivo

    This comment has been minimized.

    Show comment
    Hide comment
    @nvivo

    nvivo Jan 30, 2015

    @danwalkerak and @glen-84,

    Instead of TagHelpers I would think making the Razor engine extensible so that things like TagHelpers can be plugged into the engine would be a better use of Team Razor's time.

    Unless you are their manager, or you are a a very very active team member, it is quite arrogant of you to say how people that have been working on something for years should spend their time.

    Now, based on your points, you apparently don't understand what it is and what it can do, even though you provided many arguments on why it shouldn't be done.

    I, apparently, fail to see what problem TagHelpers is trying to solve.

    There you go.

    Is there a legitimate need for this or is it just someone's idea of a fun syntactic sugar?

    They make the code more readable, allow better tooling and also allow certain tag and attribute manipulation that are currently not possible unless you code the entire thing into a method, which again makes the code harder to understand. It's a good problem to solve.

    There are some articles you can google for and the Community Standup on @shanselman's youtube channel gives some of explanations on why it was built and what they are planning to do with it.

    Personally I think it is great that Razor is getting a better way to parse and generate html. This idea works great for angular and web components, worked great for asp.net webforms for years, there is no reason it wouldn't work for razor. People are completely used to this concept of translating a tag or attribute to something else.

    Make Razor extensible and then write TagHelpers as an example optional plugin that can be loaded via NuGet

    It doesn't make sense to provide a separate dll for it because it is part of the compilation process. It makes as much sense as saying the C# compiler should require a nuget package to be able to parse "switch/case" statements.

    You are probably confusing the tag helper as a "razor feature" that is being discussed here with the tag helpers that will be provided by default with MVC 6 for inputs and things like that. Those will come in nuget packages as part of mvc6 but that is a different project.

    Also I'm amazed that the only point of this issue is to decide if tag helpers should have configurable prefixes or not. But very few people actually answered that.

    nvivo commented Jan 30, 2015

    @danwalkerak and @glen-84,

    Instead of TagHelpers I would think making the Razor engine extensible so that things like TagHelpers can be plugged into the engine would be a better use of Team Razor's time.

    Unless you are their manager, or you are a a very very active team member, it is quite arrogant of you to say how people that have been working on something for years should spend their time.

    Now, based on your points, you apparently don't understand what it is and what it can do, even though you provided many arguments on why it shouldn't be done.

    I, apparently, fail to see what problem TagHelpers is trying to solve.

    There you go.

    Is there a legitimate need for this or is it just someone's idea of a fun syntactic sugar?

    They make the code more readable, allow better tooling and also allow certain tag and attribute manipulation that are currently not possible unless you code the entire thing into a method, which again makes the code harder to understand. It's a good problem to solve.

    There are some articles you can google for and the Community Standup on @shanselman's youtube channel gives some of explanations on why it was built and what they are planning to do with it.

    Personally I think it is great that Razor is getting a better way to parse and generate html. This idea works great for angular and web components, worked great for asp.net webforms for years, there is no reason it wouldn't work for razor. People are completely used to this concept of translating a tag or attribute to something else.

    Make Razor extensible and then write TagHelpers as an example optional plugin that can be loaded via NuGet

    It doesn't make sense to provide a separate dll for it because it is part of the compilation process. It makes as much sense as saying the C# compiler should require a nuget package to be able to parse "switch/case" statements.

    You are probably confusing the tag helper as a "razor feature" that is being discussed here with the tag helpers that will be provided by default with MVC 6 for inputs and things like that. Those will come in nuget packages as part of mvc6 but that is a different project.

    Also I'm amazed that the only point of this issue is to decide if tag helpers should have configurable prefixes or not. But very few people actually answered that.

    @glen-84

    This comment has been minimized.

    Show comment
    Hide comment
    @glen-84

    glen-84 Jan 30, 2015

    @nvivo,

    I shouldn't have quoted the "better use of Team Razor's time" part, I was just agreeing with the opinion that TagHelpers would be better suited as a plug-in. I have a huge amount of respect for Damian and the rest of the team.

    I also watch all of the Community Standup videos, but I can't remember anything (apart from the @Html.ActionLink example) that explained why TagHelpers are an improvement over HTML helpers.

    As for being more readable:

    <a action="x">Link</a>

    Is "action" a client or server attribute? How do you know?

    Anyway, you're right about the fact that this is not the correct place to discuss this. In fact, there's no reason to discuss it at all anymore, as it's very unlikely that anything will change at this late stage.

    glen-84 commented Jan 30, 2015

    @nvivo,

    I shouldn't have quoted the "better use of Team Razor's time" part, I was just agreeing with the opinion that TagHelpers would be better suited as a plug-in. I have a huge amount of respect for Damian and the rest of the team.

    I also watch all of the Community Standup videos, but I can't remember anything (apart from the @Html.ActionLink example) that explained why TagHelpers are an improvement over HTML helpers.

    As for being more readable:

    <a action="x">Link</a>

    Is "action" a client or server attribute? How do you know?

    Anyway, you're right about the fact that this is not the correct place to discuss this. In fact, there's no reason to discuss it at all anymore, as it's very unlikely that anything will change at this late stage.

    @nvivo

    This comment has been minimized.

    Show comment
    Hide comment
    @nvivo

    nvivo Jan 30, 2015

    @glen-84, no problem, the answer was also more target at the author.

    Is "action" a client or server attribute? How do you know?

    I think this is exactly the point of this discussion. One way is to add something like a prefix. They are proposing set the prefix at the top of the page, so you can do whatever you want to identify them.

    @taghelper "System.Web.Mvc.MvcDefaultHelpers" "asp-"
    @taghelper "Telerik.PurchasedComponent.Helpers" "telerik-"
    @taghelper "MyProject.MyHelpers" "myproject-"
    ...
    <a asp-action="foo" telerik-something="bar" myproject-anotherthing />

    This is very similar to how web controls were registered in asp.net, and that worked fine. In the end, you will probably have one or two prefixes registered in the web.config/config.json and get used to it. Visual Studio will have some syntax highlighting to differentiate registered server tags, and if you don't use VS, you can just lookup in the config file.

    With Angular for example, you add a single ["module"] to your config file, and suddenly a lot of tags that have nothing to do with the name of the module become valid in your html. You don't have any way to identify them, and you need to look at the documentation to know that an attribute "allow-select-row" will be valid if you add the ["ngsmartgrid"] to your app, and people seem fine with that. Razor is going in a much better path allowing you to add prefixes in my opinion.

    Also there are some interesting uses. Imagine you could do something like:

    <script asp-src-debug="~/src/**/*.js" />
    <script asp-src="~/bundle.min.js" />

    That would render a single script tag for production and multiple for development. Integrates both with grunt/gulp and web optimization and seems much nicer than the current approach with Html Helpers and method calls.

    nvivo commented Jan 30, 2015

    @glen-84, no problem, the answer was also more target at the author.

    Is "action" a client or server attribute? How do you know?

    I think this is exactly the point of this discussion. One way is to add something like a prefix. They are proposing set the prefix at the top of the page, so you can do whatever you want to identify them.

    @taghelper "System.Web.Mvc.MvcDefaultHelpers" "asp-"
    @taghelper "Telerik.PurchasedComponent.Helpers" "telerik-"
    @taghelper "MyProject.MyHelpers" "myproject-"
    ...
    <a asp-action="foo" telerik-something="bar" myproject-anotherthing />

    This is very similar to how web controls were registered in asp.net, and that worked fine. In the end, you will probably have one or two prefixes registered in the web.config/config.json and get used to it. Visual Studio will have some syntax highlighting to differentiate registered server tags, and if you don't use VS, you can just lookup in the config file.

    With Angular for example, you add a single ["module"] to your config file, and suddenly a lot of tags that have nothing to do with the name of the module become valid in your html. You don't have any way to identify them, and you need to look at the documentation to know that an attribute "allow-select-row" will be valid if you add the ["ngsmartgrid"] to your app, and people seem fine with that. Razor is going in a much better path allowing you to add prefixes in my opinion.

    Also there are some interesting uses. Imagine you could do something like:

    <script asp-src-debug="~/src/**/*.js" />
    <script asp-src="~/bundle.min.js" />

    That would render a single script tag for production and multiple for development. Integrates both with grunt/gulp and web optimization and seems much nicer than the current approach with Html Helpers and method calls.

    @glen-84

    This comment has been minimized.

    Show comment
    Hide comment
    @glen-84

    glen-84 Jan 30, 2015

    @nvivo You can also do that with the <environment> tag.

    glen-84 commented Jan 30, 2015

    @nvivo You can also do that with the <environment> tag.

    @mvkorobkov

    This comment has been minimized.

    Show comment
    Hide comment
    @mvkorobkov

    mvkorobkov Jan 30, 2015

    voting to keep html standard and use helpers only inside values of attributes
    like <a href="@Url.Action("Index", "Home")" - just maybe good to implement short smart version that will understand attribute name and react correctly - mean <a href="@(Home, Index, ... )"

    mvkorobkov commented Jan 30, 2015

    voting to keep html standard and use helpers only inside values of attributes
    like <a href="@Url.Action("Index", "Home")" - just maybe good to implement short smart version that will understand attribute name and react correctly - mean <a href="@(Home, Index, ... )"

    @henriksen

    This comment has been minimized.

    Show comment
    Hide comment
    @henriksen

    henriksen Jan 31, 2015

    My vote is to have a default prefix (asp:) and allow custom prefixes at the top of the file (or in Layouts) like so:
    @taghelper "System.Web.Mvc.MvcDefaultHelpers" "asp-"
    @taghelper "Some.Custom.Component" "xyz:"

    Perhaps even allow a TagHelper library to specify it's own default prefix?

    I like the : since that makes a clear separation between client prefixes (xyz-) and server prefixes (xyz:), but that could be overridden with a custom prefix. I'm assuming it won't break a lot of existing tools that work with HTML.

    I'd like to keep the prefixes on the attributes since I'd like minimal confusion for non-server-side-developers (designers, front-end) and better compatibility with tools that wants to parse your HTML. For instance, it's not a given that your HTML guy is working in Visual Studio and most tools will not understand <asp:a ...>.

    I don't like the data-prefix-attribute suggestion. These names will never make it to the client, seems like a waste to make them conform to some client-specific standard. Although, it would prevent a bunch of validation errors if you pull a Razor file into some other HTML designer. In the end, I personally think the benefit is too small.

    I agree that a prefix is needed, the confusion and ambiguity is just to much without, like demonstrated so many times in this thread.

    I think taghelpers can be a valuable tool for increasing the compatibility between different tools and different groups of people.

    henriksen commented Jan 31, 2015

    My vote is to have a default prefix (asp:) and allow custom prefixes at the top of the file (or in Layouts) like so:
    @taghelper "System.Web.Mvc.MvcDefaultHelpers" "asp-"
    @taghelper "Some.Custom.Component" "xyz:"

    Perhaps even allow a TagHelper library to specify it's own default prefix?

    I like the : since that makes a clear separation between client prefixes (xyz-) and server prefixes (xyz:), but that could be overridden with a custom prefix. I'm assuming it won't break a lot of existing tools that work with HTML.

    I'd like to keep the prefixes on the attributes since I'd like minimal confusion for non-server-side-developers (designers, front-end) and better compatibility with tools that wants to parse your HTML. For instance, it's not a given that your HTML guy is working in Visual Studio and most tools will not understand <asp:a ...>.

    I don't like the data-prefix-attribute suggestion. These names will never make it to the client, seems like a waste to make them conform to some client-specific standard. Although, it would prevent a bunch of validation errors if you pull a Razor file into some other HTML designer. In the end, I personally think the benefit is too small.

    I agree that a prefix is needed, the confusion and ambiguity is just to much without, like demonstrated so many times in this thread.

    I think taghelpers can be a valuable tool for increasing the compatibility between different tools and different groups of people.

    @kayzser

    This comment has been minimized.

    Show comment
    Hide comment
    @kayzser

    kayzser Feb 2, 2015

    +1 for prefix

    kayzser commented Feb 2, 2015

    +1 for prefix

    @autonomatt

    This comment has been minimized.

    Show comment
    Hide comment
    @autonomatt

    autonomatt Mar 5, 2015

    +1 for standard attributes. A prefix is just more to type. I still like Spark the best, but these tag helpers are making me reconsider Razor.

    autonomatt commented Mar 5, 2015

    +1 for standard attributes. A prefix is just more to type. I still like Spark the best, but these tag helpers are making me reconsider Razor.

    @pdaoust

    This comment has been minimized.

    Show comment
    Hide comment
    @pdaoust

    pdaoust Mar 12, 2015

    +1 for prefixed attributes, and I'm not sure whether I like hyphenated prefixes or 'illegal' characters as @safakgur recommended. If hyphenated, I don't like the data- prefix, because then it looks like it's for client-side use. asp- looks the nicest so far, because it's clear that it's meant for the server side.

    As for custom elements, I'm not sure. I'd lean towards a prefix there too, in keeping with HTML5 custom elements, but then it won't be clear from the code that an element is server-side rather than client-side. I think you might have to use an xmlns-style (or WebForms-style) prefix, like <asp:custom-element />.

    I do have to say that using an @ is in keeping with current Razor syntax; then you'd see stuff like <@custom-element /> or <label @for="Model.FirstName"> and know right away, 'hey, this is where Razor is doing stuff'.

    Anyhow, very excited to see this coming to ASP.NET!

    pdaoust commented Mar 12, 2015

    +1 for prefixed attributes, and I'm not sure whether I like hyphenated prefixes or 'illegal' characters as @safakgur recommended. If hyphenated, I don't like the data- prefix, because then it looks like it's for client-side use. asp- looks the nicest so far, because it's clear that it's meant for the server side.

    As for custom elements, I'm not sure. I'd lean towards a prefix there too, in keeping with HTML5 custom elements, but then it won't be clear from the code that an element is server-side rather than client-side. I think you might have to use an xmlns-style (or WebForms-style) prefix, like <asp:custom-element />.

    I do have to say that using an @ is in keeping with current Razor syntax; then you'd see stuff like <@custom-element /> or <label @for="Model.FirstName"> and know right away, 'hey, this is where Razor is doing stuff'.

    Anyhow, very excited to see this coming to ASP.NET!

    @asp

    This comment has been minimized.

    Show comment
    Hide comment
    @asp

    asp Mar 12, 2015

    Please remove me from this thread. Is it my fault my initials are "asp"?

    On Thu, Mar 12, 2015 at 5:57 PM, pdaoust notifications@github.com wrote:

    +1 for prefixed attributes, but prefixed in the HTML5-like way. And
    without a data- prefix, because then it looks like it's for client-side
    use. asp- looks the nicest so far, because it's clear that it's meant for
    the server side.

    As for custom elements, I'm not sure. I'd lean towards a prefix there too,
    in keeping with HTML5 custom elements, but then it won't be clear from the
    code that an element is server-side rather than client-side. I think you
    might have to use an xmlns-style (or WebForms-style) prefix, like <asp:custom-element
    />.

    Anyhow, very excited to see this coming to ASP.NET!


    Reply to this email directly or view it on GitHub
    #88 (comment).

    asp commented Mar 12, 2015

    Please remove me from this thread. Is it my fault my initials are "asp"?

    On Thu, Mar 12, 2015 at 5:57 PM, pdaoust notifications@github.com wrote:

    +1 for prefixed attributes, but prefixed in the HTML5-like way. And
    without a data- prefix, because then it looks like it's for client-side
    use. asp- looks the nicest so far, because it's clear that it's meant for
    the server side.

    As for custom elements, I'm not sure. I'd lean towards a prefix there too,
    in keeping with HTML5 custom elements, but then it won't be clear from the
    code that an element is server-side rather than client-side. I think you
    might have to use an xmlns-style (or WebForms-style) prefix, like <asp:custom-element
    />.

    Anyhow, very excited to see this coming to ASP.NET!


    Reply to this email directly or view it on GitHub
    #88 (comment).

    @glen-84

    This comment has been minimized.

    Show comment
    Hide comment
    @glen-84

    glen-84 Mar 13, 2015

    Alan Pater (asp),

    Click the "Unsubscribe" button on the right here.

    glen-84 commented Mar 13, 2015

    Alan Pater (asp),

    Click the "Unsubscribe" button on the right here.

    @Bryan-Legend

    This comment has been minimized.

    Show comment
    Hide comment
    @Bryan-Legend

    Bryan-Legend Mar 26, 2015

    +1 for standard attribute. Terseness is beautiful!

    Bryan-Legend commented Mar 26, 2015

    +1 for standard attribute. Terseness is beautiful!

    @nvivo

    This comment has been minimized.

    Show comment
    Hide comment
    @nvivo

    nvivo Mar 27, 2015

    Someone should close this issue... This has already been decided a long time ago.

    nvivo commented Mar 27, 2015

    Someone should close this issue... This has already been decided a long time ago.

    @pdaoust

    This comment has been minimized.

    Show comment
    Hide comment
    @pdaoust

    pdaoust Mar 27, 2015

    @nvivo Oh! What was the final decision? Perhaps someone with the authority to close this issue should put it as the final comment before they close it.

    pdaoust commented Mar 27, 2015

    @nvivo Oh! What was the final decision? Perhaps someone with the authority to close this issue should put it as the final comment before they close it.

    @StuartQ

    This comment has been minimized.

    Show comment
    Hide comment
    @StuartQ

    StuartQ Mar 27, 2015

    I think @DamianEdwards is probably best placed to clear things up? I believe from watching the community standups that the design has evolved quite a bit since this was raised. This Youtube link should help https://www.youtube.com/watch?v=Tv9pv1FYP1A

    StuartQ commented Mar 27, 2015

    I think @DamianEdwards is probably best placed to clear things up? I believe from watching the community standups that the design has evolved quite a bit since this was raised. This Youtube link should help https://www.youtube.com/watch?v=Tv9pv1FYP1A

    @DamianEdwards

    This comment has been minimized.

    Show comment
    Hide comment
    @DamianEdwards

    DamianEdwards Mar 27, 2015

    Member

    This is resolved by #309. You can now set an optional prefix at any level that must be present on an element for it to be considered for Tag Helper processing.
    Thanks for all the feedback.

    Member

    DamianEdwards commented Mar 27, 2015

    This is resolved by #309. You can now set an optional prefix at any level that must be present on an element for it to be considered for Tag Helper processing.
    Thanks for all the feedback.

    @DamianEdwards

    This comment has been minimized.

    Show comment
    Hide comment
    @DamianEdwards

    DamianEdwards Mar 27, 2015

    Member

    And here's what the VS editor currently looks like when working with Tag Helpers:

    image

    Member

    DamianEdwards commented Mar 27, 2015

    And here's what the VS editor currently looks like when working with Tag Helpers:

    image

    @jerrydx

    This comment has been minimized.

    Show comment
    Hide comment
    @jerrydx

    jerrydx Mar 16, 2017

    I think that "@" is better that "asp-" ....

    jerrydx commented Mar 16, 2017

    I think that "@" is better that "asp-" ....

    @rynowak rynowak removed this from the Backlog milestone Dec 17, 2017

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment