garden
garden copied to clipboard
Remove redundant declarations from output
When the same attribute is included multiple times in a CSS clause it seems like they should be merge rather than concatted, which produces the same attribute twice. Would this make sense as the default behavior, rather than us needing to call merge manually as is shown below to not generate two color attributes?
think.ui.repl=> (require '[garden.core :refer [css]]) nil think.ui.repl=> (css [[:body {:color :red} {:color :blue}]]) "body {\n color: red;\n color: blue;\n}"
think.ui.repl=> (css [[:body (merge {:color :red} {:color :blue})]]) "body {\n color: blue;\n}"
I only wonder how important this might be; if it were style-sheet wide it would make sense (those common cases where something is redefined 500 lines later in the file), but might also be a real pain to implement in that case. Would it be better to just leave developers to take responsibility for their redundancy?
Yeah, not sure. In our case it's because we've started importing some large CSS files into garden as a bunch of functions we can mixin. This means we have style definitions along these lines:
[:ul.product-list (mdl/vertical-list) {:margin-left (em 1)}]
And so if the mixin vertical-list function has a margin-left it will now result in a duplicate attribute. Without knowing about every attribute produced by a mixin you can't really know in advance whether you need to (merge ...) or not.
This is something that could be added to the compiler. Let me think about it. A new compiler is about to land in the 2.0.0
branch (that uses and actual AST) and this would be trivial to implement and offer as optional behavior.
The current behavior can be used to provide a fallback declaration for older browsers. As an example, I might include two width declarations in order to provide a px
fallback when using viewport units. A browser that does not recognize vw
units will ignore the second declaration and use the first declaration instead.
[:.myclass
{:width (px 100}}
{:width (vw 10}]
.myclass {
width: 100px;
width: 10vw;
}
If you decide to implement this optimization, you can continue to support the use case above by making the optimization optional or by providing a means to protect the fallback declarations from removal.