You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm parsing scss files which works wonderfully for the css portions but drops out any properties/values that cannot be perfectly parsed, and I'd like to disable this strictness. I understand that this won't provide full support for less/scss syntax, but it would help drastically even with a few updates.
Update: There is a tolerateInvalidValues parameter in the StylesheetParser constructor method. Setting this to true handles the scss-variables issue (which is now in strikethrough markup).
For example, consider these properties and values:
Currently, the parsed .classname ruleblock will parse in ExCSS as if it's empty, simply because the values are preprocessor variables. For our purposes, it would be much better to store the invalid vanilla css value of $bgColor or $mediumFont in the parsed object instead of acting like the property doesn't even exist.
Remaining Issue
@include mixin-name-here; and @include mixin-with-params(12px, #000); statements are likewise completely dropped. I understand that importing mixin definition property values is outside the scope of this project, but again, I'd like the parse output to at least acknowledge that the @include statement is present. Can an .InvalidProperties or similar collection be added to each IStyleRule object, where @include or other preprocessor-specific statements can at least be recallable?
Lastly, there should be some way (even if using a custom CssStyleFormatter definition) to print out these invalid statements using this library's native .ToCss() method.
For invalid vanilla property values (like the variables in the first example), if the raw value is set inside the parsed property (eg. font-size or background), then .ToCss() would function as expected without further modification. This functionality could of course be walled behind a boolean toggle, such as parser.HonorInvalidValues = true;. See tolerateInvalidValues parameter info above
Thanks!
The text was updated successfully, but these errors were encountered:
I've found that there's a constructor parameter named tolerateInvalidValues which handles the variable parsing issue above, but even with setting all include* and tolerate* param values to true, mixin @include statements are still dropped.
I was able to get around this by calling .Replace("@include ", "scss-include: ") on the raw stylesheet contents in memory, and then when I output the contents, doing the reverse replacement operation, but a more native solution would probably be better.
Hello, great project you all have worked on here.
I'm parsing scss files which works wonderfully for the css portions but drops out any properties/values that cannot be perfectly parsed, and I'd like to disable this strictness. I understand that this won't provide full support for less/scss syntax, but it would help drastically even with a few updates.Update: There is a
tolerateInvalidValues
parameter in theStylesheetParser
constructor method. Setting this to true handles the scss-variables issue (which is now in strikethrough markup).For example, consider these properties and values:Currently, the parsed.classname
ruleblock will parse in ExCSS as if it's empty, simply because the values are preprocessor variables. For our purposes, it would be much better to store the invalid vanilla css value of$bgColor
or$mediumFont
in the parsed object instead of acting like the property doesn't even exist.Remaining Issue
@include mixin-name-here;
and@include mixin-with-params(12px, #000);
statements are likewise completely dropped. I understand that importing mixin definition property values is outside the scope of this project, but again, I'd like the parse output to at least acknowledge that the@include
statement is present. Can an.InvalidProperties
or similar collection be added to eachIStyleRule
object, where@include
or other preprocessor-specific statements can at least be recallable?Lastly, there should be some way (even if using a custom
CssStyleFormatter
definition) to print out these invalid statements using this library's native.ToCss()
method.For invalid vanilla property values (like the variables in the first example), if the raw value is set inside the parsed property (eg.Seefont-size
orbackground
), then.ToCss()
would function as expected without further modification. This functionality could of course be walled behind a boolean toggle, such asparser.HonorInvalidValues = true;
.tolerateInvalidValues
parameter info aboveThanks!
The text was updated successfully, but these errors were encountered: