Create prefixes for tag helpers #88
Comments
nit: this looks much more like a prefix than a namespace. let's use term "prefix" going forward. |
I think that the attributes should be italicized in the editor so I can tell what's rendered and what isn't. |
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. |
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! |
i prefer like this:
|
I would like data-asp- or asp:-prefix |
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. |
+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 I don't like the |
I'd suggest a custom prefix as this aligns correctly with the custom elements draft. E.G. Attribute names do not need to prefix WRT the custom element draft IIRC. |
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. Remembering that we are talking about ASP_.NET_, and that it runs on the server-side, I think it should either be Just my $0.02. |
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. |
I vote for having a prefix. I'm not traumatized by web forms, so for me something like this looks OK:
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). |
I'd prefer a prefixed version of some sort. |
if the intention is to approach ppl to HTML5, I prefer the prefixed version. btw... good new for ASP.NET |
Ups..... part of the message was deleted because HTML :( 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 |
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. |
I wonder what would happen if the W3C decides to add an |
@HaraldOnline This is why I suggest that this follows the custom-element spec. |
+1 for prefixes, e.g. Fow those who appose. Are you crazy? Want yet another IE6 way of doing things? |
What about this one (from Damian Edwards sample):
which afaiu is the taghelpers replacement for this
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?
|
+1 for |
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. |
+1 for @ prefix for tags, not attributes I agree with @glen-84, this whole thing looks and smells an awful lot like webforms. |
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: ( |
+1 for prefixes Doesn't matter if the prefix is <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> |
After giving this some more thought - I believe TagHelpers are a terrible feature.
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. |
I agree 100%. @DamianEdwards Is it too late for a change like this? |
@danwalkerak and @glen-84,
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.
There you go.
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.
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. |
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, no problem, the answer was also more target at the author.
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 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 You can also do that with the <environment> tag. |
voting to keep html standard and use helpers only inside values of attributes |
My vote is to have a default prefix ( Perhaps even allow a TagHelper library to specify it's own default prefix? I like the 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 I don't like the 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. |
+1 for prefix |
+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. |
+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 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 I do have to say that using an Anyhow, very excited to see this coming to ASP.NET! |
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:
|
Alan Pater (asp), Click the "Unsubscribe" button on the right here. |
+1 for standard attribute. Terseness is beautiful! |
Someone should close this issue... This has already been decided a long time ago. |
@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. |
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 |
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. |
I think that "@" is better that "asp-" .... |
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-_.Should discuss if we want to support prefixes at the C# tag helper level.
The text was updated successfully, but these errors were encountered: