Better syntax and multiplexing

Question

Better syntax and multiplexing

yisibl opened this issue 10 years ago · 18 comments

We can define a @svg name

@svg 1px-border {
    width: 100%;
    height: 1px;
    rect {
      fill: #c8c7cc;
      x: 0;
      y: 0;
      w: 100%;
      height: 0.5;
    }
}

@svg others {  }

Use svg():

.bar {
  background-image: svg(1px-border);
}

.baz {
  border-image: svg(1px-border) 2 stretch;
}

Output:

.bar {
  background-image: url('data:image/svg+xml;charset=utf8,<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="1"><rect fill="#c8c7cc" x="0" y="0" width="100%" height="0.5"/></svg>');
}

.baz {
  border-image: url('data:image/svg+xml;charset=utf8,<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="1"><rect fill="#c8c7cc" x="0" y="0" width="100%" height="0.5"/></svg>') 2 stretch;
}

We can use in different properties. Not only in background-image.

This is like Sass @function

@function svg() {
  @return ...;
}

antife-yinyue commented 10 years ago

mixin?

Answer 1 · 2015-09-15T04:02:33.000Z

O~ It's function.

Answer 2 · 2015-09-15T21:18:26.000Z

I think this is a great idea.

Answer 3 · 2015-09-16T03:09:47.000Z

@tabatkins What do you think?

Answer 4 · 2015-09-16T15:21:09.000Z

I had the @svg idea some time ago, and it's one of the motivating examples for custom at-rules. I strongly agree with the suggested changes here. In particular, the original proposal assuming that an svg would always and only be the sole background image in an element is not very useful; it shuts down a lot of other great usages, like multiple backgrounds, list bullets, and reusing the same SVG in several rules.

The only thing I don't like about this suggested syntax is the intermingling of properties and qualified rules; that's grammatically ambiguous, and wouldn't fly in normal CSS. I suggest making the nested elements with further at-rules, like @rect.

Other than that, thumbs up, this matches my intent well and has a better syntax (expressing all attributes as properties, so you don't have to distinguish between presentation attributes and normal CSS properties) than I was coming up with.

Answer 5 · 2015-09-16T15:46:30.000Z

Thanks, @tabatkins and @yisibl . The next release will follow these parameters. One thing that @yisibl and I chatted about was how the current version acts like an echo, whereas the next version should work more like @counter-style. Which leaves me with these questions:

@svg generate a keyword like @counter-style does, or should the name only be reference-able in an svg() function as this issue suggests?
If the new version uses an svg() function, should that function accept additional parameters to control fill, etc?

Answer 6 · 2015-09-16T15:49:25.000Z

@tabatkins Thank you very much for your reply.

Answer 7 · 2015-09-16T16:20:09.000Z

About 2, you meaning like this? https://github.com/pascalduez/SassySVG#api

svg-update($svg, circle, (fill: white));

Answer 8 · 2015-09-16T16:41:27.000Z

@svg generate a keyword like @counter-style does, or should the name only be reference-able in an svg() function as this issue suggests?

Better to have a dedicated function. @counter-style was trying to "explain" counter styles, and so it merged in with other counter styles. In hindsight, that was a bit troublesome and possibly should have worked differently, but in any case it's limited to a single very locked-down property. Images aren't like that, they need to be namespaced properly.

If the new version uses an svg() function, should that function accept additional parameters to control fill, etc?

That seems hard to do in a generic way. However, it would be great to align with the proposal draft I sent out yesterday for SVG Parameters - let the svg() function accept param() functions like url() does. If you're only passing "real" values (or var() values that PostCSS can recognize and handle), you can just do a rewrite as you generate the SVG.