[TASK] Allow whitepace parsing to be stopped at EOL

[JakeQZ]

The whitespace parsing includes extraction of comments to be associated with the content.

There are cases where the comment is after the content, but should be associated with the preceding rather than the following. This will help achieve that.

[coveralls]

coverage: 73.023% (+0.04%) from 72.984%
when pulling e1a0e9b on task/parse-comments-at-eol
into 252bbe1 on main.

[oliverklee]

I don't quite understand this yet: Why should consuming whitespace stop at a linefeed, i.e., what makes the linefeed whitespace character special?

[JakeQZ]

I don't quite understand this yet: Why should consuming whitespace stop at a linefeed, i.e., what makes the linefeed whitespace character special?

It's so we would be able to correctly attribute comments to the relevant declarations as 'before' and 'after' (or 'leading' and 'trailing'), e.g.

/* This is a comment about the font size. */
font-size: 14px;
color: green; /* This is a trailing comment about the colour.  It has nothing to do with the width. */
/* This is a comment about the width. */
width: 50%;

So after parsing a property declaration, we can consume whitespace and any trailing comments up to the next line feed. Then we parse the next property declaration, consuming possibly more whitespace and any leading comments.

It's a building block towards solving #663 and #1445.

[oliverklee]

It's so we would be able to correctly attribute comments to the relevant declarations as 'before' and 'after' (or 'leading' and 'trailing'),

I'm not entirely happy with this approach. We should (or could) be able to have line number information for comments. Comments should not "belong" to CSS elements, though - they could be within a declaration, after a declaration, before a declaration, or between declarations.

Particularly, I'd like to avoid introducing of end-of-line comments belong to the declaration before it. This will avoid a can of complexity worms for us, and I currently don't see a usecase for that.

And in general, I'd strongly prefer we drop the concept of comments belonging to a declaration (maybe, just maybe with the exception of a comment that is within a declaration - but even that can get hairy when a declaration is represented as more than one object).

Would you be okay with dropping this concept, @JakeQZ ?

[JakeQZ]

Would you be okay with dropping this concept, @JakeQZ ?

That's fine by me. It was just an idea I had for solving issues like #663 and #1445, on the basis that currently each declaration owns comments that come before it, but trailing comments become associated with the next declaration, or dropped if there are no more declarations.

So we could instead have RuleSet (as it's currently named) represented as something like array<DeclarationOrComment> as suggested and discussed in #1445, though there will be some awkwardness as IIRC the declarations are keyed by their property name.

And in general, I'd strongly prefer we drop the concept of comments belonging to a declaration

The current design has all the various entities implement the Commentable interface, so changing this will be much wider-reaching.

maybe, just maybe with the exception of a comment that is within a declaration

I suspect something like

color: /* My favourite colour */ purple;

currently gets rendered as

/* My favourite colour */ 
color: purple;

because the placement of the comment is not recorded.