Color for 'cursor' for sass (SCSS) is wrong

[aeschli]

From @Binaryify on July 18, 2017 7:24

• VSCode Version:1.14.1
• OS Version: 10.12.5
  'cursor' had wrong color in SCSS file, but in the css file it had right color
  
  
  The 'cursor' key had the same scope with html tag in the 'scss' file
  
  

Copied from original issue: microsoft/vscode#30907

[usernamehw]

Also applies to mask, content, filter, font

body {
    cursor: pointer;
    ::before {
        content: '';
    }
    filter: blur(5px);
    font: 12px/14px sans-serif;
    mask: none;
}

[thismarcoantonio]

There is any update to this? I still getting the wrong highlight for cursor, content and mask properties

[gerasimvol]

caret-color same bug

[jdsteinbach]

Currently content, cursor, filter, font, mask are mis-highlighted in scss; possibly related to the property-names vs tag-names overlap

[cssinate]

@gerasimvol - it appears the same, but it isn't. caret-color should be listed in here, but it isn't. https://github.com/atom/language-css/blob/master/grammars/css.cson#L2056

I would guess it's probably because that property is still a recommendation, and not a final draft, but they might accept a PR adding it in. You should try adding it!

[cssinate]

It looks like @dsifford tried to fix this two years ago. Either it didn't fix it, or the problem has come back again for some reason.

#234

[Aerijo]

@cssinate The PR history shows that it caused another error (#237), and so was reverted in #238

[cssinate]

@Aerijo - good catch. Sorry I missed it. I don't think I have the skills to go and fix the problem. But it seems like the logic should be:

"If the string is followed by a : and that : is not followed by one of the pseudo-elements or pseudo-selectors, then it's a property."

Edit: This rule could go on the CSS language definition file, couldn't it? Should it? I know it doesn't affect CSS directly, but the problem does spread into SCSS and LESS. It feels like it should be stopped at the root, by more explicitly setting the pattern of a property.

[cssinate]

I attempted a pull request with a fix for this issue, but the tests are failing. I don't know enough about the tests to understand what they're complaining about. It seems like it breaks because it doesn't like the name or the scope that font has. However, font is both a valid property name and a valid (though deprecated) HTML tag. If someone has some insight about where we can go from here, I'm all for it!

Until that time, anyone on VSCode can use this extension I built: https://marketplace.visualstudio.com/items?itemName=cssinate.scss-language-improvements

[gerasimvol]

@cssinate https://github.com/cssinate/scss-language-improvements/issues/2

[ronilaukkarinen]

Just bumping to say I noticed these too. As I do SCSS daily it would be nice to have these implemented instead of a separate plugin. As not experienced enough, using cssinate.scss-language-improvements for now, as others.

[artuska]

Any progress?

[cssinate]

@artuska - yes. Read the last two references from before you posted.

[cssinate]

So here's a quick update. The problem for VSCode should be solved by the end of this month. The thing is, there's been a fix for this in Atom for 3 years:

https://github.com/atom/language-css/blob/57531cce71821d4bd4493a2a90c12170344a56dd/grammars/css.cson#L2092

For those that aren't super familiar with Regex, there's a bit in there that says, "a tag name can be followed with a : so long as that : isn't followed by a space."

When I edit the grammar file in VSCode directly and locally on my machine, it's fixed. This makes me confident that it will be fixed in VSCode. However, Atom is strange. If you create a SCSS file in Atom, and just write:

div {
  cursor: url('');
}

Cursor is highlighted incorrectly in Atom still! HOWEVER, if I fork atom/language-css and I change nothing, and I run Atom in dev mode using that package, it works properly!

Atom dev mode on the left, and just the regular Atom that I downloaded today on the right. I can't explain why this is happening, and I'm not going to try to fix this. I don't use Atom. But Atom users that still care about this issue, I hope this gets you close enough to figure out what's going on.

EDIT: The fix was committed 3 years ago, but didn't make it into a release of language-css until 17 days ago. As soon as Atom updates the core package version of language-css to 0.44.5, this will be fixed in Atom too. Furthermore, https://github.com/github/linguist is going to update their language definitions probably next week too, so it'll even be fixed in GitHub's syntax highlighting.

[ronilaukkarinen]

Quoting myself after some years.

Just bumping to say I noticed these too. As I do SCSS daily it would be nice to have these implemented instead of a separate plugin. As not experienced enough, using cssinate.scss-language-improvements for now, as others.

SCSS language improvements extension is no longer available and this is present again...

Version: 1.68.0-insider (Universal)
Commit: 688c80245936b49b7ceca494d9edfe97cae06f8a
Date: 2022-05-18T05:15:18.598Z (7 hrs ago)
Electron: 17.4.3
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.13-electron.0
OS: Darwin x64 21.3.0

[cssinate]

@ronilaukkarinen - Here's what I've found.

atom/language-css@21cfdb7

The commit above fixed the issue for syntax highlighting. However, according to this:

atom/language-css#127 (comment)

This change broke auto-completions, so the change was reverted.

So either the regex for property names needs to be written to take pseudo-selectors auto-completion into account or auto-completion needs to be modified to be smarter about what should or shouldn't be auto-completed and how.

[ronilaukkarinen]

Thank you a lot @cssinate for taking a look! This issue definitely needs to be reopened.

[ronilaukkarinen]

Just FYI, I've improved the original extension by @cssinate and re-published my fork to Visual Studio Marketplace so whoever is also bugged by this issue can use it while waiting for the official fix.