Extension|Author (truncated)|Version
---|---|---
path-intellisense|chr|1.4.2
gitlens|eam|4.1.2
LogFileHighlighter|emi|1.1.1
vscode-reveal|evi|0.0.9
php-debug|fel|1.10.0
php-intellisense|fel|1.4.1
auto-close-tag|for|0.4.2
gc-excelviewer|Gra|1.1.15
GitHubIssues|Hoo|0.1.2
composer|ika|0.5.0
smarty|imp|0.2.0
json-to-ts|Mar|1.4.3
vscode-apache|mrm|1.1.1
cpptools|ms-|0.11.4
php-docblocker|nei|1.2.0
vscode-versionlens|pfl|0.19.0
vscode-statusbar-json-path|ric|1.0.7
vscode-icons|rob|7.9.0
sharecode|Rol|0.4.1
code-spell-checker|str|1.2.0
vscode-todo-highlight|way|0.5.5
highlight-trailing-white-spaces|yba|0.0.2
(1 theme extensions excluded)

have fun.
// cc @ramya-rao-a
I am having a deja vu :)
w gives width
wi and anything further gives widows
This is coming from the way snippets are defined in https://github.com/emmetio/snippets/blob/master/css.json
@sergeche thoughts?
cc @sergeche
I'm starting to get similar results with other properties:

the default hint for font-family is font: fantasy; which is a very loose association and ruins the hinting system
wi and anything further gives widows
but then I would expect that the label updates too...
Not sure what expected behaviour should be if you type full property name and try to expand it as Emmet abbreviation. CSS itself has too much clashing properties/abbreviations. The goal of shortcuts is to provide shorthands for most commonly used properties. Users should learn these shortcuts by typing first letters and seeing autocomplete popup with available options. If the full property names will be considered in abbreviation resolving, they will collide with shorthands, especially ones with embedded shorthand values, like m-a for margin: auto.
So the ultimate goal is to provide matched snippets and expanded abbreviation with previews
Another example:

User expectation would be to match "padding"
@sergeche In this case the only match between "padd" and the suggested shorthand "pgba" is the first letter "p". Aren't we being too eager while matching here?
Indeed, this eager matching to the Emmet shorthands severely breaks (this) user expectations.
When I have almost complete property name, like "borde", "paddin", "margi", etc, I would assume that VS Code does the right thing and expands these widely-used properties. Instead, I get completely random and unrelated (at least that's how it looks) suggestions from Emmet.
My expectation would be that Emmet's suggestions should not always be the number 1 in the suggestion list, and sometimes they should be ranked lower as compared to the almost fully-matched widely used properties.
Suggesting "pgba" shorthand as a top choice for "paddin" is just wrong (at least, to me).
One solution I have in mind here is for the css completion provider (from the css extension that is built in) to call the emmet completion provider (See https://github.com/Microsoft/vscode/issues/29114#issuecomment-310232680) instead of the emmet extension.
As the css extension will also have in hand the other suggestions, it can add some logic to filter/sort appropriately.
I'll look into that next week.
Until then, I am pushing the below changes
The changes will be out in Monday's Insiders build.
Please give it a try then and let me know how the improvements work out for you.
If things are reasonable, then I'll push the work on the css completion provider to next iteration.
Again, thanks for all the feedback!
I have logged #29113 to track the work of moving emmet completion provider to css language service.
Closing this issue for the June milestone as the improvements listed in https://github.com/Microsoft/vscode/issues/28933#issuecomment-310802231 should help most of the cases.
Note to verifier:
Hi @ramya-rao-a , many thanks for the improvements, they significantly improve the user experience w.r.t editing CSS/SCSS files!
The sorting of the suggestions is much, much better now.
There is one issue though (actually two), regarding snippets.
Say, I have a snippet called bidi (for bi-directional SCSS mix-ins).
== Issue 1 ==
I type 'b' and see the following:

The help for my snippet bidi is wrong.
== Issue 2 ==
When I type the full name of the snippet, bidi in this case, it is still listed below the Emmet suggestion (which seems completely unrelated to the name of my snippet):

Should I file separate issues for that?
@vvs wow, the first issue is seriously messed up, thanks for reporting!
This is a separate issue indeed. I have logged #29468
I'm still running into issues with emmet and specifically the width shorthand.
white-space and widows both get priority over width which arguably is one of the most commonly used properties. Is there any way we can reorder the priority and shift some of these lesser-used properties further down the list?
Gif below to show what I'm seeing...

@ekfuhrmann You can set a custom emmet snippet for wid
{
"css": {
"snippets": {
"wid": "width:${1};"
}
}
}
See Using Custom Snippets in Emmet
Or you can take advantage of emmet and instead of typing wid you could say type w10 which would expand to width: 10px (you can use any number instead of 10)
Most helpful comment
I'm starting to get similar results with other properties:
the default hint for
font-familyisfont: fantasy;which is a very loose association and ruins the hinting system