Tab-expanding dash-separated properties

[chriscoyier]

If you TAB after a fully-written CSS property, it has weird effects:

body {
  background-color[CURSOR]
}

Then press tab, you get:

body {
  background: color;
}

Which is pretty weird, you'd think it would either do nothing since it's already expanded, or give you the more complete syntax like:

body {
  background-color: #fff;
}

[jeremypress]

@sergeche we're also running into this. I see that this is the result of the - expansion syntax. Which is in the base emmet repo.

Emmet stylesheet abbreviation element may start with name and followed by values, optionally chained with `-` delimiter. In most cases, actual CSS properties doesn’t have numbers in their names (or at least they are not used in abbreviation shortcuts) so a number right after alpha characters is considered as *embedded value*, as well as colors starting with `#` character: `p10`, `bg#fc0` etc. If implicit name/value boundary can’t be identified, you should use `-` as value separator: `m-a`, `p10-20` etc.

This causes a property like background-color to be split into background: color; as Chris noted. Would you be open to any of these options?

1. Switch - as the value delimiter to something like _ or even : (not sure if that causes a conflict)
2. Bring in the list of valid css props, and skip the value expansion iff the total phrase is equal to a valid css property

I poked around for a bit but couldn't find the exact place that says "if dash, split into property and value"

[sergeche]

I'd better suggest to find a reason why users want to write full CSS property then hit Tab.

Emmet should work as a completion provider: users should pick which completion he wants to expand and provider must sort completions that better match entered prefix. E.g even writing background is meaningless in Emmet since there's no such abbreviation. Expanding it would be a last resort when nothing else works