Show more relevant intellisense suggestions for border utility

[functasti]

What version of VS Code are you using?

v1.100.2

What version of Tailwind CSS IntelliSense are you using?

v0.14.19

What version of Tailwind CSS are you using?

v4.1.7

What package manager are you using?

npm

What operating system are you using?

Ubuntu

Describe your issue

When using the border utility, the same utility prefix is used for both border color and border width, for example:

border-amber-50 (color)
border-1 (width)

Currently, when typing something like border-1, intellisense suggests color values like border-red-100, which is likely not what the user intends. It would be more helpful if suggestions related to border-width appeared instead.

Also, for values like border-0 or border-2, the suggestions shown are related to border-style, which is not very relevant in this context. More accurate suggestions showing border-width would improve dx.

[thecrypticace]

The sorting and filtering of results is done by the extension / language client. So VSCode, Zed, WebStorm, etc… all do their own filtering / sorting of these results.

Afaik the LSP does give us the ability to completely opt out of this and do all the sorting/filtering ourselves but I think editors will still do some level of sorting/filtering since they're potentially combining results across multiple language servers. We can also tweak the editor-driven sorting bit but either way sorting these "intelligently" based on context is likely to be a rabbit hole full of edge cases.

Here's the sorting difference in VSCode vs Zed:

Aside: border-1 does work as a utility but it's not suggested because you can write it as border. Utilities like border-2 which are suggested offer border-width suggestions as the first one in both editors:

We probably can do some work here to make the sorting nicer but I'll need to think about how this needs to work.

[functasti]

The sorting and filtering of results is done by the extension / language client. So VSCode, Zed, WebStorm, etc… all do their own filtering / sorting of these results.

Why is border-red-100 included in the results in the first place when the prefix is border-1 ?

Aside: border-1 does work as a utility but it's not suggested because you can write it as border.

Could you clarify this? I’m not following the reasoning behind why border-1 is de-emphasized, especially if it’s functionally valid.

Utilities like border-2 which are suggested offer border-width suggestions as the first one in both editors:

I was surprised by your observation... the right small portion of the VSCode screenshot you included does seem to indicate that. I double-checked, and it turns out this is not the view I get by default in my environment.

By default, only one declaration is shown.

To view both declarations, I need to click the three dots to expand the view:

This isn't obvious and feels inconsistent compared to how intellisense displays suggestions in a single floating window for length-based utilities like h-* or w-*. I would have expected border-<number> to behave similarly.

[thecrypticace]

Why is border-red-100 included in the results in the first place when the prefix is border-1 ?

All editors do fuzzy matching on word boundaries, so for example if you type jc you'll get a result for justify-center. If there is a prefix match though it usually jumps to the top. Changing this so non-fuzzy filtering was performed at the server level would definitely break some workflows.

Could you clarify this? I’m not following the reasoning behind why border-1 is de-emphasized, especially if it’s functionally valid.

It's just not suggested by core. border-<any-number-here> is a possible utility in v4 but we can't suggest an infinite number of utilities.

By default, only one declaration is shown.

Yes and no. VSCode is showing as much as space will allow. If you resize the completion list it can show more of the details. All border width utilities include two properties and the … at the end signals there's more to the item details than VSCode can fit in the popup. Clicking it then opens the detail / documentation window for that completion item.

This isn't obvious and feels inconsistent compared to how intellisense displays suggestions in a single floating window for length-based utilities like h-* or w-*. I would have expected border- to behave similarly.

With some very limited exception all utilities that contain more than one property show them all in the completion details. (Color utilities override this to display a hex code as that's how VSCode detects color swatches for completions, we remove generated @property stuff, etc…)

Having said that, I could (and should) probably special case these to strip that declaration from the details as it's not really serving any useful purpose for these specific utilities.

[thecrypticace]

Special case for those values: #1384