Skip to content
This repository has been archived by the owner on Dec 19, 2018. It is now read-only.

Create prefixes for tag helpers #88

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

Create prefixes for tag helpers #88

NTaylorMullen opened this issue Aug 18, 2014 · 257 comments

Comments

@NTaylorMullen
Copy link
Member

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
Copy link
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
@NTaylorMullen NTaylorMullen changed the title Tag Helpers: Create namespaces for tag helpers Tag Helpers: Create prefixes for tag helpers Nov 20, 2014
@shanselman
Copy link

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

@Injac
Copy link

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
Copy link

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
Copy link

i prefer like this:

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

@AlexZeitler
Copy link

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

@ripberge
Copy link

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
Copy link

+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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

Tuller commented Nov 20, 2014

I'd prefer a prefixed version of some sort.

@fabiomaulo
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

@abatishchev
Copy link

+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
Copy link

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
Copy link

jj09 commented Nov 20, 2014

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

@mlmathews
Copy link

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
Copy link

+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
Copy link

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 Tag Helpers: Create prefixes for tag helpers Create prefixes for tag helpers Jan 23, 2015
    @safakgur
    Copy link

    +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
    Copy link

    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
    Copy link

    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
    Copy link

    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
    Copy link

    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
    Copy link

    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
    Copy link

    glen-84 commented Jan 30, 2015

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

    @mvkorobkov
    Copy link

    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
    Copy link

    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
    Copy link

    kayzser commented Feb 2, 2015

    +1 for prefix

    @autonomatt
    Copy link

    +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
    Copy link

    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!

    @ghost
    Copy link

    ghost 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
    Copy link

    glen-84 commented Mar 13, 2015

    Alan Pater (asp),

    Click the "Unsubscribe" button on the right here.

    @Bryan-Legend
    Copy link

    +1 for standard attribute. Terseness is beautiful!

    @nvivo
    Copy link

    nvivo commented Mar 27, 2015

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

    @pdaoust
    Copy link

    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
    Copy link

    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
    Copy link
    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.

    @DamianEdwards
    Copy link
    Member

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

    image

    @jerrydx
    Copy link

    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 subscribe to this conversation on GitHub. Already have an account? Sign in.
    Projects
    None yet
    Development

    No branches or pull requests