-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Description
This is a request to support sass/dart-sass#88.
There are a few inconsistencies and difficulties in the way raws work with trailing whitespace. For my purposes the main issue here is that these make it hard to expand on the rules in a PostCSS-compatible Sass parser, but I imagine the inconsistencies also make it difficult to work with raws in general. In particular:
-
raws.betweenrepresents substantially different content for at-rules (where it represents the whitespace after the rule's params) and declarations (where it represents the whitespace and colon after the declaration's name). This makes it difficult to share formatting logic between at-rules and declarations. -
Declarations and at-rules use different raws conventions for the final node in a block when that node doesn't have a semicolon. In particular,
a {@foo }puts the two spaces inAtRule.raws.between, whilea {foo: bar }puts the two spaces inRule.raws.after. -
At-rules have an explicit representation of trailing whitespace that's distinct from the value of the rule in
AtRule.raws.between, but declarations do not. Instead, trailing whitespace in declarations is represented as trailing whitespace inDeclaration.raws.value.raw. This makes it difficult to change the declaration's value while preserving the whitespace.
The final bullet point is particularly problematic for any tool that tries to expose a parsed view of a declaration value in a way that matches the PostCSS API. This view has to be responsible for maintaining all the formatting intrinsic in Declaration.raws.value.raw, which means it must somehow track the trailing whitespace. However, this poses a serious issue: the PostCSS convention for raws in the common case of nodes immediately followed by semicolons or blocks is that a given node tracks the whitespace before it but not after it. If each expression node has to track whitespace after it, then that ends up working substantially differently than PostCSS.
I propose the following changes:
-
Make
Container.raws.afteralways contain the whitespace between}and the previous semicolon, block, or node, whichever is closer. This matches the current behavior of declarations, nested style rules, and at-rules with blocks or semicolons. It only changes the behavior of at-rules without semicolons. -
Add
Declaration.raws.afterValue, which holds any whitespace between the declaration value and the semicolon. If there is no semicolon, this is parsed as the empty string and the whitespace is inContainer.raws.afterinstead. -
(Lower priority) Rename
AtRule.raws.betweento.afterValueto make it fully analogous toDeclaration.raws.afterValue.