Use spec purpose

[ai]

There is W3C spec purpose to define SVG colors in CSS: https://tabatkins.github.io/specs/svg-params/

.foo {
  background-image: url("image.svg" param(--color var(--primary-color)));
}

<svg>
  <g style="fill: var(--color);">
    <path d="..." />
  </g>
</svg>

Maybe we should add this syntax as alias? Or create other postcss-svg-params plugin?

@Pavliko what do you think?

[jonathantneal]

I have just added these features to svg-fragments, but it seems very unfitting, so I have not published this.

I would like to deprecate svg-fragments in favor of postcss-svg. What do you think of brining this in, @Pavliko, @ai?

These features would include:

• Support for SVG Fragments: url("image.svg#some-id").
• Support for SVG Parameters: url("image.svg" param(--fill blue)) url("image.svg" param(--fill var(--primary-color)).
• Support for Modules: url("some-installed-package") url("some-installed-package/another-image.svg")

[ai]

@jonathantneal postcss-svg is dead too :(. postcss-inline-svg is more active.

[jonathantneal]

Oh, I’m unaware postcss-svg is dead. How are we certain (just based on last commit)?

I did consider making a PR to inline-svg, but after reviewing that plugin carefully, its wonderful magic comes from its proprietary syntax. That syntax is very helpful for developers who may be uninterested in (or unaware of) SVG Fragments, SVG Parameters, and Modules.

Changing inline-svg to use url() and param() would break all existing implementations, and that would be very hard on users, especially if that plugin is active and popular. I think inline-svg should stay “Sassy”. Would you agree, or what do you think, @TrySound, @ai?

IMHO, merging these two smaller plugins (svg-fragments, svg) means a cleaner plugin store, and a more accurate name for what the plugin does.

[TrySound]

I like the idea to follow spec features, but this syntax sugar can't give ability maintain those vars dynamically. Touching url syntax looks hakish until something changed in realization officially. That's why custom functions exist.

[ai]

@jonathantneal maybe we could convert SVG Fragments syntax to postcss-inline-svg call? And check in SVG Fragments plugin, that result.processor.plugins contains postcss-inline-svg after?

[jonathantneal]

@TrySound, very much agreed about dynamic a var() being passed into param() being a bit confusing, and that reminds me of what Chris described in “The Issue with Preprocessing CSS Custom Properties”. I don’t think param() is hacky, because var() already has me comfortable with nested functions, like var(--color, var(--primary-color)).

Hopefully, outside examples of passing a var() into a param(), the param() syntax does always work as expected, as image urls don’t have access to the css variables anyway; which is why that Parameters spec exists.

@ai, also agreed. I think adding Fragments and Module support to inline-svg is a great idea. Would you want those features, @TrySound?

And @Pavliko, I’m interested in knowing if you’d like to merge our plugins.

Thanks for all the great input so far.

[TrySound]

Yeah, let's try with it.

[sbstnmsch-zz]

Hey folks, hey @ai (remember me meeting at DOT.js in Paris?) & hey @Pavliko the owner seems to be online and merging/ answering irregularly. That's ok but i think it's all about the simple and valuable name postcss-svg we and others long for and want to keep using on. So maybe @Pavliko you may just add us as contributors to help to maintain and progress. This is such a useful tool, and i use it every day 👍

I'd love to maintain this.

[jonathantneal]

@sbstnmsch, I am now a collaborator of this repository. Would you be interested in helping as well? Would you mind reviewing this page?

https://github.com/jonathantneal/postcss-svg/tree/feature/2.0.0#readme

Merging that version will resolve a number of issues in this repository, as well as refine the PostCSS ecosystem by allowing me to deprecate svg-fragments.

I would then like to see feature parity with inline-svg, which I will try to help with, because I really like the idea of having specs-driven and sassy-driven solutions, much like postcss-nesting / postcss-nested or postcss-import / postcss-easy-import.

[sbstnmsch-zz]

@jonathantneal yeah let's do this! Give me one or two days...

[jonathantneal]

param() support is now in v2!