Proposal for v-slot syntax shorthand

[yyx990803]

<foo #default="{ msg }">
  {{ msg }}
</foo>

<foo>
  <template #header="{ msg }">
    Message from header: {{ msg }}
  </template>

   <template #footer>
    A static footer
  </template>
</foo>

Full rendered proposal

[henriqemalheiros]

Mismatched tags.

[henriqemalheiros]

I like it. I don't mind being #, maybe I like it even better than & now.

I don't see the use of the shorthand on a default slot as a drawback because it'll only be used when destructuring the slot props and I think people will naturally read it as "slot". If it becomes a problem, a possible solution would be

<foo #default="{ msg }">
  {{ msg }}
</foo>

This could be optional, though, allowing people to choose between # and #default for more readability.

[Akryum]

If we go with a shorthand, I think we should not allow #="...", it's a strange syntax and isn't consistent with v-on and v-bind.

[darrenjennings]

Posting this also as it seemed that it seemed favorable by some:

<foo &default="{ msg }"> <!-- to @Akryum's point -->
  {{ msg }}
</foo>

<foo>
  <template &header="{ msg }">
    Message from header: {{ msg }}
  </template>

   <template &footer>
    A static footer
  </template>
</foo>

Benefits:

• It is communicated in languages like C to yield the address of a pointer. So it could be translated to mean "what's at the address of this slot?"
• Compared with #, the & operator is not used as much as in HTML templates, maybe to denote character codes (e.g.  ). # is the id selector in css as well as the hex code prefix, but both operators aren't common inside the templates themselves, in my experience.

Drawbacks:

• In javascript it is used as logical or operator (&&) and it is also used as a bitwise operator

As @yyx990803 mentioned before, most of the qualms with the aesthetic appeal can be fixed via syntax highlighting.

[brophdawg11]

From the proposal:

Maybe we only support the shorthand for named slots? For default slot usage on component, full v-slot usage is required. It would also be consistent with v-on and v-bind where the shorthand does not apply if there is no argument.

Echo-ing what @Akryum said above, I agree with this. Disallowing the shorthand on default slots seems very consistent and clear to me.

[Justineo]

For consistency, I think we can define a shorthand as a replacement for v-<directive-name>:, which means it requires the directive to have arguments:

• v-bind:args → :args
• v-on:args → @args
• v-slot:args → #args

For the argument-less case, we enforce the use of the full syntax. To declare a default slot scope, either of the following usage will be legitimate:

• v-slot="{...}"
• #default="{...}"

[znck]

The shorthand syntax has quite grown on me, I like both full syntax and shorthand. But for a hypothetical component accepting multiple named slots, I'd prefer shorthand.

<TestComponent v-slot="{ name }">
  <template v-slot:one="props">Hello {{ props.name }}</template>
  <template v-slot:two="{ name }">Hello {{ name }}</template>
  <template v-slot:[dynamicSlot1]="props">Hello {{ props.name }}</template>
  <template>Bye {{ name }}</template>
</TestComponent>

<TestComponent #="{ name }">
  <template #one="props">Hello {{ props.name }}</template>
  <template #two="{ props }">Hello {{ props.name }}</template>
  <template #[dynamicSlot1]="props">Hello {{ props.name }}</template>
  <template>Bye {{ name }}</template>
</TestComponent>

Even the default slot shorthand feels quite okay, I would like to extend it to v-bind.

<div v-bind:foo="bar" v-bind:[foo]="bar" v-bind="someObject"></div>
<div :foo="bar" :[foo]="bar" :="someObject"></div>

Or even v-on can use shorthand too.

<div v-on:foo="bar" v-on:[foo]="bar" v-on="someObject"></div>
<div @foo="bar" @[foo]="bar" @="someObject"></div>

[jameshulse]

When I read the initial proposal and saw the alternative shorthand & I really liked it - the similarity to passing an object by reference clicked with me.

Now that I've seen the # alternative, it actually feels clearer because the shorthand is linked more to the name of the slot and less to the props. The # is nicely reminiscent to how anchors work in a URL.

[leopiccionia]

Like (), # is also used in Angular templates:

1. #header is similar to ref="header" (this.header is an ElementRef)
2. #formName="ngForm" is used to bind a "template-driven form" for validation, etc. (this.formName is a NgForm)

Newcomers with Angular experience may still be confused, but # is much rarer in Angular templates than (). The second form, particularly, may be less confusing (ngForm is the only valid literal I've ever seen).

[chrisvfritz]

I've been thinking about this a lot today and the more I do, the more strongly I'm against a shorthand for v-slot. I've tried to summarize what I understand to be the advantages and disadvantages below.

Undisputed Advantages

• Whenever using v-slot, users could save 5 keystrokes.

Counters to Claimed Advantages

• For some people, #header stands out more visually than v-slot:header. I'm not one of these people, but if the goal is to make named slots more visually distinct, that's a problem best solved by tooling, not new syntax. We could just have Vetur and similar tooling use distinct highlighting for v-slot:xxx. An editor plugin could even treat v-slot as a ligature for # if some people really want to see that symbol in place of v-slot.

• As a less frequently used feature that's only ever used once per element, the potential benefit is miniscule compared to the benefit of the existing shorthands. Here are some stats after taking a look through a few large projects I have access to:

  • On average, 17% of components used slot or slot-scope.
  • In components using slot or slot-scope, the shorthand could be applied 2 times, on average.

  Comparing that to v-on:

  • On average, 53% of components used v-on.
  • In components using v-on, the shorthand could be applied 3 times, on average.

  By that math, there's about 5 times as many uses for v-on's shorthand. I didn't bother including stats for v-bind, because it's in a league of its own.

• Through the poll in the other thread, most people were for the shorthand, but it was definitely not an overwhelming victory. A fair number of people - even on the core team like myself, @shentao, @phanan, and probably others - would actively avoid the shorthand and possibly even ban it from our projects, because we feel the very small convenience isn't worth the lost explicitness and potential confusion. As a general rule, when at least several core team members feel a feature would make Vue worse and would actively avoid it, I think the advantages should have to be incredibly compelling. In this case, the only inarguable benefit I've seen is being able to save keystrokes - and probably only a few tweets worth in a 500 component project.

• No one is actually using v-slot in the wild yet, so by adding syntax sugar at this stage, we're solving a problem that doesn't exist. It might exist later. Maybe when v-slot is released, users will constantly complain about how verbose it is. In that case, we could always come back and investigate this further, but it's easier to add a feature later than to remove it later.

Disadvantages

• It would increase the API surface area, meaning there's more for everyone to learn in order to be able to read Vue code, without allowing any new possibilities.

• Shorthands are more difficult to google, which is important for users who see the syntax for the first time in examples, blog posts, articles, etc. Our current shorthands for v-bind and v-on compensate for this by being introduced very early in the docs. Named and scoped slots aren't even in the Essentials. To give some context, every time I give a workshop, I do a poll to see how much of the docs participants have read. Looking only at my advanced workshops, the number of people who've read all the Essentials is always between 40% and 55%. From our traffic analytics, it seems that out of the minority who do read all the Essentials, about 35% also read the guide on Component Slots, where named and scoped slots are introduced. This suggests that optimistically, more than 80% of users will never read the docs on this shorthand syntax and are likely to encounter it for the first time when they see it in an example, blog post, tutorial, etc. Unless that content is specifically about slots and the shorthand, that means a potentially a terrible onboarding experience for named/scoped slots for most users.

• In a former career, I was a linguist and language teacher. From research, I found out that when learning a new word, adults needed to be introduced to it 7 times (on average) before they'd be able to integrate it into their own vocabulary. One exception was "false friends", which are words that look/sound similar to a word with a completely different meaning in a familiar language. Extremely common false friends are sometimes easier to learn, strangely, but less common false friends typically require orders of magnitude more reinforcement. In the linguistic context of HTML/templating, we're introducing # as a new word that's also a false friend, because outside of Vue templates, it's commonly understood to mean referencing/adding an id attribute (and means something else in Angular). So this syntax will not only be initially confusing for people unfamiliar with the shorthand, but worse - they'll often falsely assume they already know what it does and because it's a relatively less common false friend, it will likely take most people orders of magnitude more reinforcement to learn.

• As @Akryum and others have already mentioned, for the object syntax for v-bind and v-on, we decided not to allow shorthands, because :="" and @="" didn't provide enough context (and looked pretty strange). Given that, it seems inconsistent to allow #="" when the same problem exists here.

• I fear this could set a precedent where power users (especially solo devs who don't have to think about team dynamics) will start asking for more shorthands, making Vue look more and more like Lisp. It could be difficult to say no, too. Unlike v-bind and v-on, named/scoped slots are less commonly used feature that's not even in the Essentials of our guide, where only a single instance will ever exist on an element. I can easily imagine just as compelling arguments for adding shorthands for class bindings (they're used so frequently and the attribute's value is often really long), v-model (it already has modifiers and in Vue 3, will also likely gain an argument to replace v-bind.sync), etc. Then come requests to extend custom directives to allow custom shorthands to be defined...

[yyx990803]

@chrisvfritz

Counters to Counters of Claimed Advantages

If the goal is to make named slots more visually distinct, that's a problem best solved by tooling, not new syntax

Just because it can be helped by tooling doesn't mean we can ignore visual distinctiveness from syntax discussions. Also, we cannot assume that everyone will be using the same tooling.

As a less frequently used feature that's only ever used once per element, the potential benefit is miniscule compared to the benefit of the existing shorthands.

The primary reasoning for including a shorthand is not just saving keystrokes - instead, it's about increasing the signal/noise ratio in cases where it gets used in high density. In that sense, the absolute number of times it occurs within the project is not the sole determinant of its overall benefits. On the other hand - I don't think 17% is an insignificant usage rate, and the ratio may get higher for projects that rely on component libraries with a primarily slot-based API.

When at least several core team members feel a feature would make Vue worse and would actively avoid it, I think the advantages should have to be incredibly compelling.

If I'm not mistaken, I think @shentao and @znck have both changed their minds and are now ok with # being the shorthand. I'd encourage team members who were involved in earlier discussions to read the latest RFC and voice their opinions here directly.

No one is actually using v-slot in the wild yet, so by adding syntax sugar at this stage, we're solving a problem that doesn't exist. It might exist later. Maybe when v-slot is released, users will constantly complain about how verbose it is. In that case, we could always come back and investigate this further, but it's easier to add a feature later than to remove it later.

The verbosity and lack of visual distinctiveness has been a problem since the slot + slot-scope time - v-slot was partially conceived to remedy that, and the shorthand is an extension on top of v-slot to take it a step further.

As mentioned in the adoption strategy - it actually creates a problem if we ship the base syntax and the shorthand separately. Shipping them together ensures everyone reading about the v-slot syntax also know about the shorthand. Shipping separately runs the risk of people only know about v-slot and miss the shorthand later.

Counters to Disadvantages

Increased API surface

The API surface increase is objectively minimal. If someone already knows the v-slot syntax (which is required to be able to read Vue code), the learning needed to know its shorthand is minimal since the shorthand rules can be 100% consistent with existing shorthands if we disallow #= usage.

Shorthands are more difficult to google

This is true - but I doubt it is a problem significant enough to block this RFC, since Google isn't the only way to find answers to syntax issues. There are forums, chat rooms, alternative search terms like "Vue shorthands", and the fellow developer who wrote that code to ask from.

I fear this could set a precedent where power users (especially solo devs who don't have to think about team dynamics) will start asking for more shorthands, making Vue look more and more like Lisp.

I think such a fear is unwarranted. The discussion we are having right now shows good arguments from both sides and actually helps us argue against unnecessary shorthands in the future. Landing it in no way indicates we are open to more shorthands without proper, case-by-case discussions.

[yyx990803]

Updated: dropped #= usage and now enforces full syntax (v-slot) or explicit name (#default) for on-component default slot usage.

[posva]

I'd encourage team members who were involved in earlier discussions to read the latest RFC and voice their opinions here directly.

I like that # was dropped in favor of #default because we cannot do :="bindings" nor @="events". To me, I feel a lack of consistency between v-slot and v-bind/v-on because you can use multiple v-bind/v-on on a single element but you can only use a single v-slot. I think that as long as we clearly error this during compilation, it's fine though.

Differently, from bind and on, which are completely necessary to build a Vue application, a person may develop an application without ever developing components using slots. Only using them through 3rd party components. I think it's fine to use the classic syntax in these scenarios, leaving the shorthand syntax for more advanced and intensive scoped slot usages. Even mixing both syntaxes in a project sounds fine.

However, I'm also concerned about the syntax looking magical, especially if we add more like v-slot:[name]="hey", making Vue hostile to beginners and not as intuitive as it was before. I will show this to other developers with little experience in Vue to collect some extra Feedback.

Overall I'm for the shorthand, one of the main points for me is Drawbacks i

[bencodezen]

From my experience, one of the major selling points of Vue has always been the fact that it is intuitive. It doesn't take much effort to read or comprehend what's going on regardless of your JS experience level because you all did that good of a job. All of the APIs and mental models required to understand Vue fit within the traditional frontend technology stack.

That said, the shorthand syntax for v-slots is one of the first times where I had to stare and question what was going on. After all, as someone who writes a lot of CSS, seeing # immediately made me think of an ID. So from a concept mapping perspective, I'm already on the wrong path.

The reason the shorthand of v-bind and v-on work so well is that they used symbols which were unique and intuitive to what was happening. They are subtle but distinctive characters that were practically instantaneous to learn and acquire. I've never had a student tell me that the shorthand didn't make sense .

While I know that many of the advanced Vue.js developers may be okay with the shorthand, I want to make sure we are considering new and future new Vue.js developers who won't have a chance to weigh in on this. I would be remiss if we started to lose how approachable Vue is to developers of all walks of life over something like shorthand syntax.

Anyhow, just my two cents and I welcome any counter points if I missed something. Cheers!

[yyx990803]

@bencodezen

I think there's a fundamental flaw in this argument: you can't judge a shorthand by people's reaction when they are exposed to it without proper context - that's not how we teach the framework, and that's not how people learn.

We tell people what v-bind and v-on do before introducing shorthands for them. That's exactly what we do in the docs.

Similarly, this proposal has the pre-requisite of proper context from the new slot syntax proposed in #2. The shorthand should and will only be introduced AFTER the user has properly learned how v-slot works. Once they understand how v-slot works, the full-syntax to shorthand translation is a natural progression. In addition, slot is also definitely introduced AFTER v-on and v-bind, so the user is already aware of the shorthand conversion rules for v-bind and v-on:

• v-bind:id -> :id
• v-on:click -> @click
• v-slot:header -> #header

Another aspect of the analogy here is that v-bind and v-on themselves are very self-explanatory. In comparison, slots itself, especially including scoped slots, is an inherently complex concept in its own.

So when I see "stare and question what was going on", I think it's a combination of:

1. The inherent complexity of the slot mechanism
2. Unfamiliarity with the new v-slot base syntax
3. (Because of 2) confusion of the # symbol and its relation to CSS ids

I'd say it's inaccurate to attribute the confusion all to the shorthand itself, and I don't think users learning about the new syntax from the documentation or structured materials will have a similar problem. I honestly doubt this shorthand can be so disastrous as to cause Vue to lose its approachable-ness - that's a bit hyperbole to me.

[bencodezen]

@yyx990803

My apologies if it came across as a hyperbole. It was more an expression of concern more than anything else and a thought experiment at best.

I agree that with the appropriate context and background, shorthand syntax is merely a conversion rule for a person's mental model. The only point I wanted to raise was that the interesting phenomenon I found with v-bind and v-on is that people could almost reverse engineer the symbol to its purpose without any explanation because it was just that intuitive.

So my comment on the # shorthand is simply based on the notion that it's not as intuitive in comparison to the other shorthands. Other than that, love all the great work going on here for v-slot and for v3.0 in general!

[yyx990803]

@bencodezen no worries. I think the fundamental cause is because v-on and v-bind themselves are simple concepts whereas slot is an advanced concept in itself. It's like you can guess simple words from a different language that describes everyday objects, but unlikely to be able to do that for words that describes ideas that require explaining in the first place. It's not really the fault of the choice of words.

[yyx990803]

Based on the poll from #2 we have about 80% of users who voted in favor of introducing a shorthand. Some of the users had different opinions on what symbol to use, but after the switch to # in this proposal, it seems there's no longer a strong disagreement regarding the symbol choice anymore.

Most of the opposition to this RFC is against the addition of the shorthand on the ground of shorthands being hostile for beginners. I think there are several aspects of this:

• ✅ For future new users who have never used Vue before, and learning it from scratch: they will first learn about v-on and v-bind and be introduced to their respective shorthands. Then they will learn about how slots work using the base v-slot syntax. Then they will learn about the shorthand. I think this progression makes the shorthand a rather natural step in the learning process, so we are not making Vue harder to learn.

• ✅ For existing users upgrading to 2.6: they will read the new documentation and learn about the new v-slot syntax along with the shorthand. Again, shorthand is only introduced AFTER the base syntax. We are not making it difficult to upgrade.

• ❌For existing users who missed the update but happen to later work on a project that uses the shorthand syntax: this is the group that might get confused, and they will have to ask around to figure out what this new syntax does. Unlike v-slot which indicates what it likely does, the shorthand may be more difficult to guess or Google for. This is a real drawback of the shorthand.

I think it finally comes down to whether the drawback is significant enough to block this RFC from landing, and my opinion is no. I don't believe this drawback is anything close to affecting Vue's overall approachable-ness - instead, it's a transitional churn that may cause some inconvenience to a particular group of users, which will ease out over time. This is also what happens to the introduction of any new syntax (to a lesser degree if they are more easily-googlable), which is why we do it very carefully and very infrequently. (The 3 active RFCs are the only ones we currently have planned regarding templates in 3.0, and non of them are breaking)

I want to reiterate that I absolutely value Vue's approachable-ness as a core design principle, but we also shouldn't underestimate people's ability to learn. In this case, I consider the tradeoff acceptable.

[chrisvfritz]

Re-evaluating premises

@yyx990803 I think we're starting the get to the core of the disagreement here. I worry that some of the premises you're building on may not be accurate. Based on the data I've seen from analytics and workshops, and my background in educational psychology, I believe I have strong evidence that:

1. Most users will not learn about v-slot through the docs, so are likely to see this shorthand for the first time in a blog post, tutorial, etc that is likely to assume knowledge of the shorthand.

2. Learning a shorthand in addition to the base v-slot concept adds a higher cognitive cost to already more difficult-to-learn concepts.

If these are true, then then your two ✅ premises would be inaccurate and Vue's overall approachableness would suffer for most users (not just some outliers) that would persist for as long as we keep getting new users. I'll explore these points now.

1. Most users will not learn about v-slot through the docs

For future new users [the order of concepts in the docs] makes the shorthand a rather natural step in the learning process, so we are not making Vue harder to learn.

You're arguing the learning path is pretty nice if people learn about slots for the first time from the docs, but it looks like that wouldn't happen. Based on the data I mentioned earlier, it seems more than 80% of users are not introduced to slots through the docs. That means when they're first exposed to v-slot and its shorthand, it will likely be through an article/tutorial/example that will probably assume knowledge of the shorthand unless specifically introducing v-slot.

For existing users upgrading to 2.6: they will read the new documentation and learn about the new v-slot syntax along with the shorthand. Again, shorthand is only introduced AFTER the base syntax.

Again, based on the data I have access to, this seems extremely unlikely. Looking at the analytics for our docs, we didn't see any spike in page views when v2.5 released with new features. This leads me to assume that once again, when v2.6 is released, the number of people revisiting the docs will also be minimal. This also matched my anecdotal experience, as I still meet a lot of users who don't know about scoped slots and of those who do know, almost everyone says they learned about it from a blog post or course.

I've also witnessed this behavior first-hand in my consulting work. When people upgrade a dependency to a new minor version, they will almost always just run tests (if they exist) and load up the app to manually check if things still seem to be working. The vast majority of people aren't reading changelogs, release announcements, or coming back to the docs to read up on new/updated features.

I agree we'd be in a better place if existing users did these things, but all my experience and all the data I have access to indicate that it's not the reality.

2. The shorthand adds a higher cognitive cost to already more difficult-to-learn concepts

This is where my ed psych background comes in. Learning is messier than we usually think of it. People won't read a section and immediately have it cemented and organized in their minds. So when learning about named/scoped slots for the first time, users will still be mentally digesting that information even after they feel they "get" it. It won't be until sleeping on it, being re-exposed to it a few more times, and using it a few times, that it'll really be a solid foundation they can easily build new knowledge on. So learning the shorthand directly afterwards will increase the time and effort it takes to learn named/scoped slots in general, by increasing the total number of discrete concepts that need to be digested at once.

The shorthand is worse than just one extra concept though, it's an extra layer of abstraction that users will have to mentally translate before they're "fluent", when reading examples in that shorthand.

A deeper look at the tooling alternative

If I understand correctly, we both agree that all the benefits of this proposal could be accomplished through tooling - your worry is that not everyone will be using the same tooling. That means there would be duplicated effort in implementing the syntax highlighting (and potential ligature) and potentially a delay in when some users have access to it.

First, since this isn't a feature that opens any new possibilities, even from a development perspective, is it really important if some people don't have access to it right away? Plus, I don't get the impression that even those in favor of the proposal want it very badly. Apart from you, the most impassioned arguments for the shorthand have had a tone of mild enthusiasm, bordering on indifference:

it's beginning to grow on me

I like both full syntax and shorthand

I like it

Or the strongest endorsement I saw:

The # is nicely reminiscent to how anchors work in a URL

Which I think should actually be an argument against the shorthand, since slots have nothing to do with anchors.

Meanwhile, most people who commented on the shorthand in the 3 issues (including those quoted above) have expressed concerns about the possible confusion, even after settling on #.

On the other hand, making this shorthand opt-in through tooling would solve every disadvantage. We wouldn't have to cover it in documentation, it would never appear in community learning resources, and those who find it confusing because # means something completely different in HTML/JS and Angular would never have to see it.

Sidenotes

GitHub polls

As a sidenote, out of those people who would enjoy it:

we have about 80% of users who voted in favor of introducing a shorthand

That 80% is exclusively power users and others with enough free time to browse random Vue issues. A poll on GitHub is so unrepresentative of our overall userbase that when the perspective of new/normal users is concerned, I don't think the results are relevant.

A similar precedent

This actually reminds me of the rejected proposal to allow :foo to be shorthand for :foo="foo". It would save keystrokes and reduce syntax noise, but we decided against it, twice, because your intuition (and later, user testing) suggested it would confuse a lot of people - and resolving that confusion would be difficult through Google. We decided the mild convenience just wasn't worth it, even though that pattern is even more common than named/scoped slots. It didn't even matter that in user testing, most users eventually correctly guessed what :foo was shorthand for, suggesting that it was somewhat intuitive.

While providing similar benefits, the argument for v-slot's shorthand is even weaker, because:

• It's a less frequently used feature.

• In guessing what # means, most (if not all) users would be wrong, because #foo already means id="foo" in HTML/JS and ref="foo" in Angular.

[yyx990803]

Most users will not learn about v-slot through the docs

I'd be curious to see where this analytics comes from. I honestly doubt the 80% number. I know it's an estimate, but as someone who also teaches Vue a lot, I honestly have no clue what percentage it really could be, so that makes it hard for me to take any number for granted. Workshop attendees are such a small sample and is highly skewed (they are attending the workshop likely because they are still learning).

Even if this is the case, it does not change the fact that:

• They will be learning about v-slot after v-on and v-bind. In fact, this means they will be learning about v-slot when they are already more familiar with the framework (and v-on/v-bind shorthands) then they would be if they were reading the docs in one go.

• They will highly likely be learning v-slot and its shorthand together.

So the first premise may be discounted, but still holds.

we didn't see any spike in page views when v2.5 released with new features

We didn't introduce anything close to a "change" in 2.5. v-slot is different. This is probably the single biggest major change for an existing feature in over a year. There will be blogs, newsletters, videos talking about it. This covers much more ground than the release notes. Admitted, some of them will learn in a less convenient fashion (encountered the new syntax and forced to look it up), but they will learn.

The shorthand adds a higher cognitive cost to already more difficult-to-learn concepts

I strongly disagree. And I think this can actually be supported by the vote here: voters are most likely users who are already familiar with slots. They voted in favor of it because the shorthand makes sense given slot knowledge. The shorthand is a small, one-time upfront cost in return for reduced cognitive cost in the long run. Once learned, it pays dividends forever. This is the main reason I'm strongly for the shorthand.

A poll on GitHub is so unrepresentative of our overall userbase that when the perspective of new/normal users is concerned, I don't think the results are relevant.

Like I said above, I'm using poll to gauge whether the shorthand makes sense for users who already know how slot works. I'm not using it to argue about the learning cost for beginners, nor am I suggesting it should be the sole base of merging this RFC. It validates the "pros" of the proposal. I think the poll serves its purpose.

A similar precedent in :foo shorthand for :foo="foo"

The reason I rejected that one was because of the potential confusion with boolean attribute, and unlike #, boolean attribute is something that exists in HTML itself, AND the positioning of the shorthand overlaps with where normal boolean attributes can appear. In comparison:

• There is no equivalent of # in HTML, it's only a CSS concept.
• The shorthand only appears on <template> elements inside a custom component, or on a custom component itself. The context is very specific whenever it appears. This makes it highly unlikely to be mistaken for something else.

In guessing what # means, most (if not all) users would be wrong

No empirical evidence here. Seems a bit too subjective to make such an assertion.

[Akryum]

I'm still not convinced yet another syntax is beneficial just to save 5 key strokes. We already have this new dynamic argument syntax which is adding some noise in the template but which actually opens new possibilities, so I like it, but this one is I'm really not sure... Maybe we should try to not end up closer to Angular with a absurd amount of special characters everywhere in the templates?

[phanan]

I'd tend to agree with @chrisvfritz and @Akryum here. Slots (especially scoped) are a more advanced concept, mostly used by power users (I personally had a hard time wrapping my head around the idea, and am still not using it as frequently or fluently as I want to be). This essentially means several things:

• The vote we have on GitHub, and even this discussion, only involve users who are familiar with the concept and its practical usage enough to raise their opinions. Now, we can go the easy road by saying that this is OSS with every discussion open and those who don't contribute should just accept whatever decision made by those who do, but being widely known as an extremely beginner-friendly and approachable framework, I think Vue can do better than that.

• The shorthand, though with the undeniable advantages as stated by @yyx990803, would arguably benefit only those power users. Beginners and immediate-level users will instead be introduced with a weird, confusing syntax which is of no benefits for them. This is where the approachable-ness of Vue is prone to harm.

• Even in the case of power users, the benefits of the shorthand would be minimal because, well, as power users, they must already have tools and tricks up their sleeves to achieve the same result without the need of support from the framework level – I'm talking about shortcuts, autocompletes, even editor extensions and whatnot.

Last but not least, for the arguments saying this is a small upfront cost for a long run benefit, I am not so sure about that. This upfront cost might just be costly enough for me for example, as a team lead, to disallow the use of the syntax in our codebase entirely, to not raise the bar for newcomers unnecessarily. This again defeats the purpose of introducing a concept whose audience consists of mostly power users.

[yyx990803]

I'm still not convinced yet another syntax is beneficial just to save 5 key strokes

It's not just about saving 5 keystrokes. As stated in the proposal, it's also about increasing the signal/noise ratio when it is used in high density. "yet another syntax"

Maybe we should try to not end up closer to Angular with a absurd amount of special characters everywhere in the templates

That is certainly something we want to avoid, which is exactly why we are having this lengthy discussion here on the introduction of one single extra special shorthand. I'm pretty sure we are not adding yet another shorthand any time soon (maybe never).

Slots (especially scoped) are a more advanced concept, mostly used by power users... Even in the case of power users, the benefits of the shorthand would be minimal

This brings up an interesting topic on perspective here - the dynamics of power users vs. beginners. It seems some of the arguments here makes the assumption that DX for beginners automatically trumps that of power users. I don't think that is the case - DX for both groups are important, but it has to be measured in a case by case manner.

I think it's good that we have a part of the team that lean towards conservativeness whenever it comes to approachability, but we also have to realize that Vue is not just for beginners. We have been around for 4 years and we have people building sophisticated systems using Vue in all kinds of settings. We sure do have a lot of power users as well as beginners. Should we always lean towards a particular side? No. Our ultimate target is all Vue users. In this particular argument, I feel that the negative impact of the shorthand may have on beginners is being exaggerated, while the cognitive benefits for power users are being dismissed as just "saving keystrokes". That, in my opinion, is not a balanced take, and I'm essentially playing the advocate for the power users here.

To re-emphasize a point regarding the learning barrier cost: the inherent learning barrier is in slots itself. For a user that never learned about slots but encountered it in a coworkers code, they'd be forced to learn it regardless of shorthand or not - and the majority of the learning will be about slot itself, not the shorthand. The only actual negative impact of the shorthand is not being as easy to Google as v-slot.

Overall, I'm still not convinced that the potential downside for beginners outweigh the potential upside for power users.

[chrisvfritz]

@yyx990803

I'd be curious to see where this analytics comes from.

I provided a breakdown earlier, but I'll summarize again. In my advanced workshops, after removing the people who are not already using Vue (thus eliminating the true beginners), consistently only 40-55% report having read all the Essentials in a poll I have everyone fill out at the beginning. Then tracking unique visitors in Google Analytics, it looks like only about 35% of people who read all the Essentials also go on to read the slots page. That means optimistically, 55% * 35% = 19%. That left more than 80% who would not read on to learn slots from the docs.

I honestly have no clue what percentage it really could be, so that makes it hard for me to take any number for granted.

Let's forget the exact number for a moment. Even assuming 100% of current users read all the Essentials (which would contradict all my personal experience), that would still leave at least 35% who don't go on to read more according to our site analytics. So the number is undeniably a huge proportion of users.

Workshop attendees are such a small sample and is highly skewed (they are attending the workshop likely because they are still learning).

Most of my advanced workshop content goes beyond the documentation. But also, outside the core team, almost everyone I know who leads a team and even teaches Vue isn't familiar with 100% of Vue's features. I even learn new things sometimes, so I think pretty much everyone is "still learning". 😄

They will highly likely be learning v-slot and its shorthand together.

Not if they learn v-slot by stumbling upon it in an article/example somewhere. Most articles and examples I see about Vue assume knowledge of the shorthands for v-bind and v-on (unless they're specifically introducing those features). I have no reason to believe the same wouldn't be true for a v-slot shorthand.

Admitted, some of them will learn in a less convenient fashion (encountered the new syntax and forced to look it up), but they will learn.

My argument isn't that the shorthand is impossible to learn - it's just an extra barrier. But I also guarantee you that it's a large enough barrier that some users will give up, unsure what question to even Google when they see something like #header.

I strongly disagree [the shorthand adds a higher cognitive cost]. And I think this can actually be supported by the vote here: voters are most likely users who are already familiar with slots.

The idea that quantitatively more discrete concepts and layers of abstraction add higher cognitive costs to learning isn't a matter of opinion - there's 50+ years of research to confirm this. Also, as you mentioned, the voters are most likely users who are already familiar with slots, so they have no idea what it would be like to learn about v-slot and the shorthand at the same time. Learning one more concept is easier now, because they're already comfortable with named/scoped slots.

The shorthand is a small, one-time upfront cost in return for reduced cognitive cost in the long run.

Do you have any evidence to suggest the cost will be small? My evidence and intuition suggest it won't be insignificant. And what's your evidence that it will reduce cognitive cost in the long run? You're adding a new layer of abstraction (increased cognitive cost) that defies the traditional meaning of #xxx in HTML (increased cognitive cost) and assuming the decreased syntax noise would make up for it. I really doubt it, personally.

We didn't introduce anything close to a "change" in 2.5. v-slot is different. This is probably the single biggest major change for an existing feature in over a year. There will be blogs, newsletters, videos talking about it.

The same was true for introducing slot-scope, but I still meet a lot of users, even now, who don't know about scoped slots. What's different in this case?

There is no equivalent of # in HTML, it's only a CSS concept.

In HTML templating languages like Pug, Haml, and Slim, #xxx means "add id="xxx" to this element. Also, when # appears in CSS, JavaScript, and even Vue itself (e.g. $mount('#app')), we're always referring to HTML.

No empirical evidence here [to suggest that in guessing what # means, most (if not all) users would be wrong]. Seems a bit too subjective to make such an assertion.

I admit I haven't done any user testing on this, but it seemed to be the logical outcome based on these facts:

• In other templating languages, #xxx has always meant id="xxx"
• In Angular, it means ref="xxx"
• I'm not aware of any history where # is used in reference to content distribution
• Most people commenting on this proposal (even those in favor of it) have mentioned potential confusion as a concern, due to the points above
• If I weren't aware of this proposal, I would assume #xxx meant id="xxx"

While I agree it's not necessarily definitive, that seems to be a fair amount of evidence to me. What's your evidence that people seeing #xxx for the first time, with no context, would assume it's short for v-slot:xxx?

[yyx990803]

it looks like only about 35% of people who read all the Essentials also go on to read the slots page

This doesn't mean they didn't learn slots from the docs. It only means they didn't get to slots on their first reading. I'm afraid this number doesn't actually support your argument.

The same was true for introducing slot-scope, but I still meet a lot of users, even now, who don't know about scoped slots.

This actually means the shorthand will not affect them either.

What's your evidence that people seeing #xxx for the first time, with no context, would assume it's short for v-slot:xxx?

Because it most likely only appears in the following form:

<SomeComponent>
  <template #header>
    <div>Header message</div>
  </template>

  <template #item="{ item }">
    <div class="item">{{ item.text }}</div>
  </template>

  <template #footer>
    <div>Footer message</div>
  </template>
</SomeComponent>

In this case, <template> is being passed to a component as children. This only happens when you are using slots in Vue. Put it another way, it's almost impossible to see the # syntax without proper context. So most of the arguments about that it could be confused for something else doesn't really hold.

[chrisvfritz]

This brings up an interesting topic on perspective here - the dynamics of power users vs. beginners. It seems some of the arguments here makes the assumption that DX for beginners automatically trumps that of power users. I don't think that is the case - DX for both groups are important, but it has to be measured in a case by case manner.

@yyx990803 I agree. That's why I, as a power user myself, suggested this as opt-in editor tooling. That way, beginners are unaffected and the power users who might find this helpful can enable it for their own code. Isn't that the best of both worlds?

I think this is more than power users vs beginners though. I think there's also a solo devs vs team dynamic. I think power users who also happen to be solo devs are most likely to gravitate toward this feature, because their knowledge is cemented enough that learning one more thing is easier. They never have to worry about the cost of other people learning it. Or, they're students and not even building real apps. (I think not many people besides students have the free time to browse random Vue issues. 😄)

On the other hand, those of us working in a team would rather not suffer productivity by having team members stumble over #header and not being sure what it means, or assuming wrongly, then having to explain it. We have more important things to focus on. That's why I and other team leads like @phanan would ban it from our projects, even though we're power users. We also want Vue to scale - and part of scaling is working well in team settings.

[yyx990803]

I think there's also a solo devs vs team dynamic. I think power users who also happen to be solo devs are most likely to gravitate toward this feature, because their knowledge is cemented enough that learning one more thing is easier. They never have to worry about the cost of other people learning it.

Valid point - but I would argue that there are two different problems here:

1. Some team members using a feature that the rest of the team are not even aware of: this can happen with or without shorthands.

2. Some team members using the shorthand, while other team members know about the feature but not aware of the shorthand: this seems to be a much less likely scenario, and blocking the shorthand based on that seems quite a stretch to me.

Banning certain features is a team choice. If Vue can work without any sort of enforced team opinion, then we wouldn't have the need for the ESLint plugin or the style guide.

On the other hand - it seems to me a better approach would be a proper onboarding document/process that primes any new member of the features the team is using to make sure everyone is on the same page, rather than hoping that they somehow will figure out things they didn't know themselves.

[chrisvfritz]

Some team members using a feature that the rest of the team are not even aware of: this can happen with or without shorthands.

Yes, but the features are normally easy to Google. The shorthand changes that.

Banning certain features is a team choice. If Vue can work without any sort of enforced team opinion, then we wouldn't have the need for the ESLint plugin or the style guide.

I think we should try to avoid adding features that many teams will want to ban though. Do you not agree? The only other Vue feature I've had to ban is .native, which we're deprecating in v3. Even features like $parent I won't completely ban - just be very critical of. Sometimes, it can be acceptable for a prototype or to get a feature shipped on time.

On the other hand - it seems to me a better approach would be a proper onboarding document/process that primes any new member of the features the team is using to make sure everyone is on the same page, rather than hoping that they somehow will figure out things they didn't know themselves.

I have an onboarding process, internal documentation, and many code comments linking to documentation for every project I lead. Some documentation is required reading during onboarding, some just for reference, because I usually don't find it realistic to have everyone on the team learn about everything before they start any work on the codebase. For example, let's say we're using Vue, Vue Router, Vuex, Lodash, Axios, and Rx.js - all common libraries that I use in a lot of projects. Especially after several months of development, getting all new devs (especially juniors) familiar with every feature we might be using just isn't practical.

Wherever possible, I try to make it easy for devs to learn independently, because then our most advanced devs don't get bogged down explaining things to our less advanced devs and can work on features themselves. With <template v-slot:header>, devs can Google v-slot if they're not familiar with it, read the docs, then problem solved. With <template #header>, we'd have to leave a comment linking to the docs whenever we used the shorthand for the same experience, defeating its purpose.

it's almost impossible to see the # syntax without proper context. So most of the arguments about that it could be confused for something else doesn't really hold.

Everyone who's saying the syntax would be confusing, including myself and most other commenters, are seeing it in the proper context. So what would convince you? I could do some user testing, similar to what I did for :xxx and we could find out what people would assume <template #header> would do. What percentage are you hoping would assume it's a shorthand for slots / content distribution?

[chriscalo]

Private class fields in JavaScript (partially implemented in Babel 7.3.0) use the # symbol:

class Counter extends HTMLElement {
  #x = 0;

  clicked() {
    this.#x++;
    window.requestAnimationFrame(this.render.bind(this));
  }

  constructor() {
    super();
    this.onclick = this.clicked.bind(this);
  }

  connectedCallback() { this.render(); }

  render() {
    this.textContent = this.#x.toString();
  }
}

I could see a future where people have a learned association that prefixing a property with a # means it's private. Does that cause any problems here?

[yyx990803]

@chriscalo those are used in a completely different context so unlikely to cause any confusion, just like @click won't be confused as a decorator.

[yyx990803]

Did a poll on Twitter. As of this writing we have over 1,000 votes, where 55% guessed correctly, 16% guessed wrong, and 29% wasn't able to guess what it means. The percentage was very stable ever since it got over 100 votes, so I think it is a big enough sample size. I also think Twitter represents a diverse enough user base - probably including a decent percentage of casual or even non-users who are simply interested in participating in the design discussion.

The follow up poll also shows that over half (56%) of the voters who wasn't able to guess what it means do not having working experience with slots (either never used it or don't even use Vue). I should have phrased it to include those who guessed wrong as well - but I think it's fair to assume a decent percentage of them also lacked prior slot knowledge. Let's assume it's a bit lower, maybe 40%.

So if we filter out users who don't even know slots, and then re-calculate the percentage of those who guessed it right, we get (55% / (55% + 29% * (1 - 56%) + 16% * (1 - 40%)) ~= 71%.

That is to say, for users with prior slots knowledge, over 70% were able to guess what the syntax means just by looking at it point blank, without reading any documentation, or even learning about the new v-slot full syntax. That means the syntax is intuitive to some extent - or, at the very least, not confusing. I believe with proper documentation or learning, the vast majority of users will be able to "get it" right on the spot.

[victornpb]

Idk if that’s up to discussion but what about

<template $header>

Like $ standing for slot

The only thing I was confused about slots when I first learned about it was the a lot tag vs slot attribute, my first intuition was that I had to wrap my code in a slot tag when I’m fact I had to add a slot attribute.

I can see the same argument about $ being confused with like ${} interpolations but for me it seems less confusing than the #.

I don’t think the $ is used for anything else in the context of html.

I don’t have a bias towards Angular but I like how #foo is used for ref=foo tho

[abellion]

Hi everyone,

Giving my two cents ! Does having a shorthand syntax makes sense at all ? Is it worth the confusion it can bring to save literally 5 characters ?

Furthermore, I don't consider the # as a shorthand for v-slot because that's in no ways a contraction of v-slot. Take v-on and its @ alternative. In both cases, we can read "On click" and "At click", which refers to an event. But when seeing # I personally read "hashtag", and as far as I know, this doesn't refer or even make think about something related to a slot.

[thelinuxlich]

I can't wait to use this with Vuetify!

[smolinari]

But when seeing # I personally read "hashtag", and as far as I know, this doesn't refer or even make think about something related to a slot.

That's why I suggested two pipes ||. At least it looks like a slot. 😄

But, I think I agree too. For v-slot, abbreviation isn't necessary or rather :slot is short enough.

Edit: And, from a visual standpoint, not abbreviating helps readability, because it's easy to match up the slotted template with the actual slot. Here for example.

<template id="questions-template">
  <div>
    <div v-for="question in questions" :key="question.id"> 
      <slot name="text" :text="question.text" />
      <slot :name="question.id" :input="question.input" />
    </div>
  </div>
</template>

<div id="q-app">
  <p class="caption"><strong>{{ title }}</strong></p>
  <questions-component :questions="questions">
    <template :slot:text="{ text }">
      <div>
        {{ text }}
      </div>
    </template>    
    <template 
      v-for="question in questions"
      :key="question.id"
      :slot:[question.id]="{ input }"
    >
      <q-field :helper="input.help">
        <component v-if="input.type === 'input'"
          is="q-input"
          v-model="input.value">
        </component> 
        <component v-if="input.type === 'select'"
          is="q-select"
          v-model="input.selection"
          :options="input.options">
        </component> 
        <component v-if="input.type === 'multi-select'"
          is="q-select"
          v-model="input.selection"
          multiple
          :options="input.options">
        </component> 
      </q-field><br/>
    </template>        
  </questions-component>
</div>

This, to me, this looks cleaner more concise.

    <template 
      v-for="question in questions"
      :key="question.id"
      :slot:[question.id]="{ input }"
    >

than this.

    <template 
      v-for="question in questions"
      :key="question.id"
      #[question.id]="{ input }"
    >

Scott

[bencodezen]

I also think Twitter represents a diverse enough user base - probably including a decent percentage of casual or even non-users who are simply interested in participating in the design discussion.

From my experience running research studies, it is important to remember that the audience from Twitter is a very particular subgroup of people. I think it would be a mistake to assume that it contains a spread of users that represent Vue's user base because the kinds of people who would:

1. Use Twitter
2. Follow Vue.js
3. Happen to encounter the poll in their feed
4. Take the time to read the thread
5. Answer the poll

represents a very small and specific cross section of individuals who are often highly invested in tech and the Vue.js ecosystem itself. In addition, I would have loved to give my opinion but was not even aware of the poll until I saw you mention it on this thread. (And I consider myself a fairly active Twitter user).

While I cannot provide hard evidence of this off the top of my head, it's really important to understand the inherent bias that exists with polling and data since oftentimes it ignores the incredibly influential (but often forgotten) variable of the silent population who can be just as opinionated. The only difference is that when they give up, the data is never surface. And if you need a recent example, the recent presidential election should be enough evidence for that.

To be clear though, I'm not saying that the Twitter poll is invalid by any means. I think it's incredibly valuable and insightful to hear additional feedback. It's just that I want to make sure we must be careful to interpret the data with the awareness of the blind spots that exist with this type of data collection in order to avoid social phenomenons like confirmation bias.

EDIT:

Just to clarify, my critique is not that Twitter itself cannot be representative for this kind of research. It's that we have to be careful about how conclusions are drawn based on how data is gathered.

[chrisvfritz]

@yyx990803 I don't agree with @bencodezen that the userbase on Twitter isn't representative enough for this kind of research. I think it can be a reasonable proxy, as long as the poll is well-designed. It's at least much more representative than places like GitHub and Reddit and I don't know of a better option for widescale Vue user testing. 😄

But the way you conducted that poll does not follow user testing best practices as I understand them. First, the phrasing makes it seem like a contest ("Can you guess what this syntax does?"), where people are now invested in guessing "correctly". Second, by providing the "correct" answer at all, many users will read it before answering (even though you told them not to), biasing their answer toward guessing correctly. Third, the example you provided is probably the most ideal scenario for guessing correctly, not the most typical. Fourth, while it makes counting up votes easier, we lose so much valuable nuance in the data by having people choose from limited options, rather than having them explain exactly what their guess is.

Then you assumed that the votes of people not familiar with slots don't matter - which I'm confused by. If new users can't even intuit that this is for content distribution, that's still important! So you can't just make up a percentage (I've been trying to keep all my numbers coming from real data) and decide to throw out the votes you don't like. 😄

But keeping all the data, and even knowing the design of the poll will skew results toward the answer you want, that still left 46% of people who would be very confused by this syntax and having a more difficult time Googling it. That seems like a very significant negative impact to me. That's only 6% below the number of people who were confused by the :xxx/:xxx="xxx" shorthand when we tested it, which we all agreed was unacceptable (despite the fact that :xxx had a higher impact than this shorthand).

Earlier, I asked you what percentage of confusion you would find acceptable, because I think it's important to have that discussion. Even for :xxx/:xxx="xxx", which I initially proposed (and would have had a higher impact), I was unhappy with anything above 10%. So with 52% confusion (from an unbiased poll design), I immediately withdrew my support. I had to agree it just wasn't worth the small reduction in syntax noise - especially when tooling can do the same job without the disadvantages. This is an even smaller reduction in syntax noise, with a very similar initial confusion rate, while also adding complexity to an already more complex feature and is so controversial that some core team members would ban it from their projects, requiring yet more tooling. So why is this proposal getting special treatment? Have I missed some critical difference?

Also, you never addressed my full argument about moving this to opt-in tooling. If we can avoid all the disadvantages, while still giving power users all the benefits, isn't that a better solution?

[yyx990803]

the phrasing makes it seem like a contest

I agree that can potentially skew the result, however - Twitter polls are anonymous. People don't get any reward for voting as guessed right when they did not, so the skewing is rather limited.

assumed that the votes of people not familiar with slots don't matter

I'm not saying it doesn't matter. These users are indeed a relevant metrics for the percentage that would have a hard time Googling it. However it's definitely not relevant when evaluating the intuitiveness of the shorthand. If a user doesn't understand slots, they don't even have the possibility of not being confused by the shorthand. This happens even without the shorthand, so counting these confused users as victims of the shorthand would result in a very different narrative, which leads to:

...still left 46% of people who would be very confused by this syntax

1. As explained above, it's 29%, not 46%.

2. "very confused" is inaccurate. This percentage is the combination of all level of confusion, from mild to very. You can't just cast them all the one extreme.

3. They are confused because they were asked to look at some new syntax, which is in turn a shorthand of another new syntax, which is in turn a syntax for a concept that is inherently complex in itself, point blank, without any other context. Ignoring that context and phrasing as if that percentage of people will get confused by the syntax under any situation distorts the narrative quite a bit.

I asked you what percentage of confusion you would find acceptable, because I think it's important to have that discussion

Again, context is important. "29% of users don't get it even after proper explanation" is completely different from "71% of users get it even without proper explanation". I think the former is not acceptable while the latter is.

why is this proposal getting special treatment? Have I missed some critical difference?

Because of what's explained above. Context is important.

you never addressed my full argument about moving this to opt-in tooling

That doesn't seem to address the situation when an advanced team member opts-in without telling the rest of the team, or when beginners learn from open sourced code that happens to opt-in. They'd still have the exact same problems. In fact, this makes it even worse: because we actively try to hide the information, beginners that do run into it will have an even harder time finding resources about such usage, since it's not even in the docs.

---

I think we have conducted enough discussion here. What we can agree on is that some users want it, and some users do not. Among those that do not, some simply dislike it and prefer the full syntax (but they have no problem understanding the shorthand); some actively want to prevent it from shipping due to concerns about increased learning barrier.

I've read all the feedback, I've looked at all the data. I have no problem admitting that I personally am strongly in favor of the syntax, from a user's perspective. I also admit that this will result in some learning churn, but my assessment is that the churn is acceptable. We still have disagreements, but the arguments have started to shift towards minute details in things that either cannot be empirically proven, or - in cases where data has been collected - how to interpret the data. The arguments can be continued indefinitely and at this point I believe the time investment from core team members is starting to hinder progress in other parts. This is probably the first time I have to say this, but it has to be said: as the BDFL, I've made my decision, and we are shipping it. Case closed.

[laander]

@yyx990803 The majority of the discussion in this RFC seems to have been about whether to add a shorthand symbol or not, and I understand your position on wanting to move pass that point.

Given the Twitter thread, comments on the gist and comments in the previous RFC, I feel that the choice of symbol still remains undecided/undiscussed. It seems to me that not an insubstantial amount of concerns is regarding the # symbol.

There's been quite a few different alternatives suggested the past days, so I'd suggest we have a vote to gauge the preference sentiment in the community. It could be here on Github or on Twitter.

To keep it pragmatic, a maximum 5 different options should be presented. Here's all the different ones I've seen in the wild so far:
# $ & ^ || % ? *

What's your thoughts?

[victornpb]

I expressed previously my opinion in favor of the $ symbol, $ standing for slot

<template $header>

[yyx990803]

@laander choice of symbol has already been extensively discussed in #2 - in fact it was changed to # based on feedback. At this point I believe there will be people dissatisfied with any symbol choice - however most of the opinions are purely subjective and is more or less bikeshedding. Function-wise none of these symbols are inherently superior to another - we have to pick one that works, because it's impossible to pick one that pleases everyone.