Hi,

Apologies for the long title. The bug is actually quite simple: when I prepare to add a comment via Atom's default key binding (cmd+/ for me), the text cursor is not placed within the comment as I would expect (so I can begin typing). Instead, the cursor is placed after the comment, which I find rather unintuitive.

Before:

After:

What I was expecting:

Could this be fixed?

Thanks,
Caleb

Maybe it's not just transition that's affected, but I seem to only notice it there:

The .2 is not marked as constant.numeric but it should be:

The leading 0 is properly marked:

As a syntax theme author I would love support for media queries level 4 which allows the following syntax in CSS:

@custom-media --small-viewport ( min-width: 450px );

It would be great to get the at-rule class for @custom-media and the variable class for --small-viewport so I can style consistently between CSS, Sass and Less.

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

The commit: b6081eb restricts identifiers that is causing syntax highlighting failures for css selectors that include a forward slash for namespacing.

At Facebook, we use namespacing in our CSS rule definitions to help modularize our stylesheets. Our asset management pipeline then mangles the selectors to valid CSS selectors when delivering to the browser. Nuclide uses language-css for styling css files resulting in the undesired highlighting.

cc @jgebhardt

Steps to Reproduce

Use a slash in your css selector (e.g. (.something/another).

Versions

This change occured from Atom 1.14 -> Atom 1.15.

kstone@kstone-mbp ~> atom-beta --version
Atom    : 1.15.0-beta0
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0
kstone@kstone-mbp ~> apm-beta --version
apm  1.15.3
npm  3.10.5
node 4.4.5 x64
python 2.7.10
git 2.8.0-rc2

Since CSS can have comments, I'd like to propose a snipped for adding comments to a css file, similar to the docblock snippet in language-javascript. Would this be a welcome addition to the language-css package?

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

Indentation with: {}, [], () do not work using the CSS syntax.

Steps to Reproduce

1. Create a new blank file
2. Change the langauge to Atom's default 'CSS' syntax.
3. Create a simple CSS rule

Where '|' is the I-cursor in Atom, and the indentation setting is set to 'Tabs (4 wide)'...

Expected behavior:

.cssrule'{
'''|
}

Actual behavior:

.cssrule'{
|
}

Reproduces how often:

This happens for me 100% of the time, in my normal work environment and in safe mode.

Versions

Atom : 1.15.0
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0

Additional Information

Auto indentation is enabled in the settings, and works for all other langauges I use.

I for some reason, have two 'CSS' languages when changing, although neither work.

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

flow-root is a new CSS value that's available for the display property. It should be part of the package to provide autocompletion.

As a syntax theme author I would love support for CSS custom properties which allows the following syntax in CSS:

:root {
  --bg-color: rgb( 255, 255, 255 );
}

body {
  background-color: var( --bg-color );
}

It would be great to get the variable class for --bg-color so I can style consistently between CSS, Sass and Less.

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

[Description of the issue]

Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Reproduces how often: [What percentage of the time does it reproduce?]

Versions

You can get this information from copy and pasting the output of atom --version and apm --version from the command line. Also, please include the OS and what version of the OS you're running.

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue.

CSS properties are listed in:

support.type.property-name.css
AND
.source.css .meta.property-list:not(.meta.property-value)

CSS property values are listed in:

support.constant.property-value.css
AND
.source.css .meta.property-value

HTML elements are listed in:

entity.name.tag.css
AND
.source.css:not(.meta.property-list)

Not to mention any lists of HTML elements and such in the language-html file.

This is going to be a pain to maintain and will easily go out of sync. Is there some way each can be defined once and pulled into both places?

Some keywords are missing (not syntax highlighted):

These are:

• All transform ("translate(XYZ)") functions
• Display modes "table-cell" and "table"

I'm pretty sure there are others, but for now, I've only noticed these 3.

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

The syntax highlighting for the keyframes at-rule is not applied correctly if there are vendor prefixes. e.g. @keyframes produces the correct syntax highlighting, but @-moz-keyframes, @-o-keyframes, @-webkit-keyframes and @-ms-keyframes do not.

Steps to Reproduce

Two ways to reproduce.

First way:

1. Create a new file with a .css extension
2. Paste the following text into this file:

@keyframes fadein {
    from { opacity: 0; }
    to   { opacity: 1; }
}

/* Syntax highlighting incorrect for vendor prefixes
/* Firefox < 16 */
@-moz-keyframes fadein {
    from { opacity: 0; }
    to   { opacity: 1; }
}

/* Safari, Chrome and Opera > 12.1 */
@-webkit-keyframes fadein {
    from { opacity: 0; }
    to   { opacity: 1; }
}

/* Internet Explorer */
@-ms-keyframes fadein {
    from { opacity: 0; }
    to   { opacity: 1; }
}

/* Opera < 12.1 */
@-o-keyframes fadein {
    from { opacity: 0; }
    to   { opacity: 1; }
}

3. Open the file in Atom

Second way:

1. Open a blank file (File > New File)
2. Paste the above text into this blank file
3. Switch the syntax to CSS

Expected behavior:
The following behavior for -webkit-keyframes, -o-keyframes, -moz-keyframes, and -ms-keyframes

Actual behavior:

Reproduces how often: 100%

Versions

Atom : 1.15.0
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0
OS : MacOS Sierra 10.12.3

Additional Information

Tested with Seti and Atom Light syntax themes. Seems reproducible on multiple syntax themes.

Looks like the space is included at the start of numeric values in CSS.

Which results in things like:

Seems to be handled fine in other places:

Hi! Media queries don't work over multiple lines, even when separated with a comma. It is then treated as normal text.

    @media (-webkit-min-device-pixel-ratio: 2),
           (min-resolution: 192dpi) {
        width: 200px;
        height: 200px; 
    }

https://tabatkins.github.io/specs/css-apply-rule/

Attribute selectors are not highlighted when are not prefixed with anything.

So these are ok:

span[foo] { font-weight: bold; }
a[href*="bar"] { font-weight: bold; }

And these are not ok:

[foo] { font-weight: bold; }
[class~="bar"] { font-weight: bold; }

The weird thing is that I couldn't find any example of standalone attribute selector in specifications, but they work perfectly. All the examples uses combined selectors like h1[foo]. It seems that [foo] is the same as *[foo].

I'm on Atom 176, ran atom --safe then tried to select a word with cmd-d. The word boundaries are crazy. This only seems to repro in LESS grammar though. Here's a gif - after each click I press cmd-d

See the screenshot below.

The code in the screenshot confuses the syntax highlighter:

[disabled],
[disabled] + p {
    /* styles */
}

Specs:
Atom 1.0
language-css 0.32.0
Mac OS X 10.9

I'm not 100% sure what's going on, but as an example, the following gets improperly syntax highlighted:

p::before {
  content: counter(a) "." counter(b) "." counter(c) "." counter(d) "." counter(e) "." counter(f) "." counter(g) "." counter(h) "." counter(i) "." counter(j) "." counter(k) "." counter(l);
}

In particular, counter(l); gets highlighted as if it is part of a quoted string instead of being marked up like the earlier counter invocations. See attached image.

FWIW, I distilled this example from actual CSS code I was working on.

Selecting all the following code and then trying to comment it out does nothing. I would expect it to comment out the css code.

/* General Overrides */

.codelab code.prettyprint {
  color: white; /* default color in case offline */
}

It seems that -webkit-font-smoothing is not recognized as a valid property name in the current version of atom.

@supports not (-webkit-backdrop-filter: blur(10px)) {
  background: rgba(230, 230, 230, 1);
}

All CSS that comes after the first line loses its color coding. (gets reset later on)

Screenshot:

While punctuation is well defined, the parens in a media query aren't picked up. In Less and Sass this is done correctly. I have looked into it, but there are parts of the grammar definitions I just can't get my head around yet, and those for Sass and Less are written in a completely way than CSS.

similar in less:

The following causes language-css to choke on the lack of quotes:

@font-face {
  src: url(http://example.com/font.woff) format('woff');
}

url() is not a problem outside of @font-face however, as the following works fine:

a {
    background-image: url(http://example.com)
}

text-overflow is not highlighted:

https://developer.mozilla.org/en-US/docs/Web/CSS/text-overflow

(this is for a .less file)

This is super small, but grey isn't properly syntax highlighted / recognized as a valid color value (which it is).

I don't think it's super relevant, but I am using Atom 1.0 on Windows 8.

I’ve put together a list of CSS properties: http://ref.openweb.io/CSS/ .

There are a lot more than are included in language-css.cson . However, not every property is implemented, and the nature of standards work means some will get renamed or dropped.

Is there a policy (or should there be?) of what gets included? If Atom gets auto-updated regularly like Chrome does, I think we can be more flexible on adding and removing CSS properties that are not set in stone. Or maybe a good policy would be just to include features that are supported by at least one browser?

If we decide what should be added, I can work on making a pull request with the properties that are missing.

The parsing of unicode escape sequences is odd. See image.

useful , hope support stylus

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

Using different keywords as transition-property results in different syntax highlighting.

Steps to Reproduce

1. Use the syntax theme 'One Light'.
2. Create a CSS file.
3. Add the following code:

div {
  transition-property: width;
}

div {
  transition-property: color;
}

div {
  transition-property: background;
}

Expected behavior: [What you expect to happen]

The keywords width, color and background should have the same syntax highlighting.

Actual behavior: [What actually happens]

Reproduces how often: [What percentage of the time does it reproduce?]

100%

Versions

Versions

Atom : 1.15.0
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0

apm 1.15.3
npm 3.10.5
node 4.4.5 x64
python 2.7.10
git 2.10.1

Additional Information

MDN lists background as an animated property, it also works in all browsers I have tested so far. Therefore I think it should not be highlighted as invalid. At least width and color I would suspect to have the same syntax highlighting.

#foo { color: #666 }
#bar { display: none }

Using one dark syntax:

This was working in 1.0.2 but not in 1.0.3.

I think this may have been cause by 37fac70 /cc @benogle

@media (min-resolution: 192dpi) {
    width: 200px;
    height: 200px; 
}

Whatever comes after { is treated as normal text when prepended by an at-rule, eg., media query. Replacing @media (min-resolution: 192dpi) with .selector “fixes” the highlighting.

From @ggregoire on March 10, 2017 17:4

• VSCode Version: last one
• OS Version: macOS

Hi,

@media into <style></style> breaks the syntax highlighting.

Copied from original issue: microsoft/vscode#22404

When using colour names from CSS3 extended Color names (originally from SVG/X11) they are highlighting different to basic colour words such as blue. I assume this is because in the source they’re labeled as invalid:

lhttps://github.com/atom/language-css/blob/master/grammars/css.cson#L149

W3Schools is used as a source of them being invalid. W3Schools is often wrong. They are indeed valid, as seen by the link earlier in this report.

when I write @keyframs and Atom complete it perfectly and show @Keyframes myAnimation {

}

but when I write "from" and "to" Atom do not give me some tips .

See following example:

@keyframes line-scale {
}
#test {
  animation: line-scale;
}

: line-scale; generates:

<span class="meta property-value css">
  <span class="punctuation separator key-value css">:</span>
  <span class="support constant property-value css">line</span>
  -scale
  <span class="punctuation terminator rule css">;</span>
</span>

For line is a constant property-value and \b regrads - as a word boundary, it goes wrong.
Same issue with constant font-name.
ES5 doesn't support lookbehind assertions, I'm not sure how to solve it.
Maybe property-values should match <ident-token> first and then constant property-value?

Example:

page-header {
    display: block;
    background: #ff0000;
    height: calc(100% - 100px);
    overflow: auto;
}

The page-header is not colored correctly in atom.

Source of Examples:

Figure 1.

/** Comment */
@media (max-height: 40em /* 640px */){

}

NOTE: It's worth mentioning this affects comments sitting outside brackets, too. For example, this doesn't get highlighted properly either:

@media /* 640px */ (max-height: 40em){
}

Figure 2.

/** 640px */ @media (max-height: 40em){

}

System specs:

• Platform: Mac OS/X 10.9.5 (Screw Yosemite)
• Processor: 2.3 GHz Intel Core i7
• Memory: 16 GB 1600 MHz DDR3
• Atom version: 1.0.0

I would love to have the option to adjust the spacing around the colon (:) between CSS properties and values. I think the setting is currently hard-coded in:

There is no "proper" way to have this formatted; it's simply preference. Personally I prefer to have no space: background:url(img.jpg);

I'm not the only one:
atom/autocomplete-plus#103

Also in the autocomplete-plus issue above they mention that this should be an option in the "autocomplete-plus providers", so I hope I'm in the right place?

I've noticed that syntax highlighting for @import rules seems to be broken atm.

The reference url/path doesn't get highlighted at all. (not to mention the semicolon terminator)

Looks like it all treated as text, it's not being caught by whatever tokenizer is being used.

grid-template-columns
grid-template-rows
grid-template-areas
grid-column-gap
grid-row-gap
grid-gap
grid-auto-columns
grid-auto-rows
grid-auto-flow
grid
grid-column-start
grid-column-end
grid-row-start
grid-row-end
grid-column
grid-row
grid-area

http://www.w3.org/TR/css-grid-1/
https://css-tricks.com/snippets/css/complete-guide-grid/

The Atom CSS language parser is aging fast with the advent of postcss, and, notably, http://cssnext.io/.

The biggest features are nesting, custom selectors and custom variables, which already has an issue here: #48.

“The future of CSS” has, I'd argue, three key features:

• Nesting
• Custom selectors
• Custom variables

The implementation of said features would advance the parser and prepare it for what's to come, and, in part, what's already here.

hello everybody,
the stroke property (related to svg elements) together with all the other properties beginning with stroke- is missing from the regex for support.type.property-name.css;
this causes unconsistent property-name wrapping.

Single Line Comments aren't colored properly, they should be treated the same way as any actual CSS parser handles them (everything after them to be treated as commented out).

Shorthand for 0.3 which is often used is simply .3. However, the language grammar doesn't pick this up properly and doesn't mark the leading . as constant.numeric:

Expected behavior: Custom properties (--custom-property-123) should be offered for the autocomplete-plus Symbol Provider

Actual behavior: Custom properties are not listed by autocomplete

Versions

Atom 1.15.0

Prerequisites

• Can you reproduce the problem in safe mode?
• Are you running the latest version of Atom?
• Did you check the debugging guide?
• Did you check the FAQs on Discuss?
• Are you reporting to the correct repository?
• Did you perform a cursory search to see if your bug or enhancement is already reported?

Description

I was checking out the css file of backgridjs and noticed that text-overflow was not syntax highlighted properly, the file can be found on github: https://github.com/wyuenho/backgrid/blob/master/lib/backgrid.css

As recommended in the Atom slack channel I tested Editor: Log Cursors Scopes on error lines and correct lines and all report the same message.

Scopes at Cursor

source.css
meta.property-list.css
meta.property-value.css
punctuation.terminator.rule.css

There are some additional properties not syntax highlighted in this file. I don't know if any of this is valid css, see images.

cc @50Wliu

Expected behavior: Syntax highlighting is correct because text-overflow appears to be a valid css property https://developer.mozilla.org/en-US/docs/Web/CSS/text-overflow.

Actual behavior: text-overflow is not correctly syntax highlighted.

Versions

Atom 1.7.4
Windows 10