Color specs #1524
Color specs #1524
Conversation
| $left: #000; | ||
| $right: true; |
There was a problem hiding this comment.
I don't think you need variables here; I think you can just include these inline.
| <===> null/options.yml | ||
| --- | ||
| :todo: | ||
| - sass/libsass#2413 |
There was a problem hiding this comment.
I think Dart Sass is actually incorrect here. Ruby Sass also produced an error for color + null, and that's not the sort of thing that's particularly useful to change in a new implementation. Same goes for other null operations.
| <==============================================================================> | ||
| <===> error/map/input.scss | ||
| $left: #000; | ||
| $right: ("key": 0); |
There was a problem hiding this comment.
| $right: ("key": 0); | |
| $right: (1: 0); |
Alternately, per this style guide rule this could have a string name but it would have to be a single letter.
| @@ -0,0 +1,93 @@ | |||
| <===> boolean/true/input.scss | |||
There was a problem hiding this comment.
I guess there's not much harm in having all of these test cases explicitly tested, but I think it's probably overkill when the underlying behavior is that and with a color LHS should always return the RHS. Same for the disjunction tests.
|
|
||
| <===> | ||
| <==============================================================================> | ||
| <===> color/equal/input.scss |
There was a problem hiding this comment.
I feel like color-to-color equality warrants substantially more tests. If you want to delay it for now, that's fine, but if so add a README with a TODO that links to #1418.
| @@ -0,0 +1,106 @@ | |||
| <===> boolean/true/input.scss | |||
There was a problem hiding this comment.
Rather than have separate inequality tests that wholly duplicate the equality tests, it's probably better to write a helper mixin that verifies that two values are equal according to both == and !=. I think it's reasonable to delay this until #1418 as well, in which case maybe just leave out inequality specs for now.
| @@ -0,0 +1,47 @@ | |||
| <===> keyword/input.scss | |||
There was a problem hiding this comment.
I think these specs should be substantially expanded:
-
We should verify that these values are actually parsed as colors, not just that they're emitted as written. Maybe pass them to
adjust-color()with no other args, which will both verify that its argument is a color and return a color value without an associated string representation? -
We need to all color names Sass supports, and that those names are case-insensitive.
-
We need to verify that hex digits are parsed correctly into red/green/blue/alpha channels for all hex representations.
See #1516
Adds specs for the value
color.