Inline comments moved to new line

[betaorbust]

The problem

Currently, inline comments are moved to a new line when rendered out in CSS.

.my-class{
   left: 20%; /*annotation for further processing*/
}

Turns into:

.my-class{
   left: 20%;
   /*annotation for further processing*/
}

This breaks build steps that rely on other CSS processing systems using inline annotations.

Proposal:

• Comments remain inline with the existing code.
• In situations where the existing code does not render (mixins, etc.) comments appear on their own line. (This is how it works today, just calling it out for completeness.)

Proposed output

Example source:

.my-mixin(){ /*annotation from mixin*/
   top: 20%;
   left: 20%; /*annotation from mixin declaration*/
}
.my-class{ /*selector annotation*/
   border: solid 1px black /*annotation from declaration*/;
   .my-mixin()
}

Example output:

.my-class { /*selector annotation*/
   border: solid 1px black /*annotation from declaration*/;
   /*annotation from mixin*/
   top: 20%;
   left: 20%; /*annotation from mixin declaration*/
}

[seven-phases-max]

This was discussed in details in <sorry, can't find the issue at quick glance, (todo)>.
In summary: currently parser totally ignores whitespaces (incl. new lines), thus the following comments are stored in the AST same way:

foo {
    x: x; /* bar */
    /* bar */
    /* bar */ y: y;
}

therefore the CSS renderer can't restore original formatting. Handling this kind of stuff needs less or more major refactoring... There's related #2477, it's sort of dedicated to "value inlined comments" but I suppose the whole thing to be reworked all together anyway (via the same "comments as separate nodes (attached to meaningful CSS nodes?)" approach).

(Though I'm not sure if we should merge this one to #2477 or not).

[matthew-dean]

Matching output works in simple examples, but since there isn't entirely a 1-to-1 relationship between Less and CSS, comments have to be moved.

.box {
  foo+: bar;  /*  bar */
  foo+: blah; /* blah */
}
// Now what?

The only thing I think should be changed is that any comments get moved before the output, which is far more logical than after. As in:

// output
.box {
  /* bar */
  /* blah */
  foo: bar, blah;
}

I think we would simplify things if comments were always output before that rule / ruleset / etc. Outputting on the line following the rule drastically changes the meaning of the comment, which is probably where this issue stems from.

[betaorbust]

While the whitespace is a larger architectural issue, my 2c on the comments would be to try to keep them as close to where they are generated. There may be corner cases where you simply can't, but here's my proposal for merging the properties in your previous example:

.box {
  foo+: bar;  /*  bar */
  foo+: blah; /* blah */
}

.box {
  foo: bar, blah; /* bar */ /* blah */
}

This follows the principle of least astonishment, in that comments remain where they were written, in the order they were declared and parsed.

Shifting the location (either the line number or the location) means you can't use LESS with inline annotations effectively.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.