Re: [idea] lighweight inline vector images in CSS and HTML

On Sun, Mar 20, 2016 at 10:22 PM, Amelia Bellamy-Royds
<amelia.bellamy.royds@gmail.com> wrote:
> 1) Create a shorthand-notation for defining an SVG-style image consisting of
> a single shape within CSS.
>
> This is certainly feasible.  There are pre-processor tools that are already
> doing this (without the limitation to a single shape), compiling to a data
> URI with SVG markup.  It is logically consistent to the CSS gradient
> functions creating an image data type.

Agree that this is possible and consistent, but I question its value.
Simple shapes aren't all that useful, particularly as one-offs.

> 2) Have SVG-related CSS properties declared on the same element apply to the
> generated image
>
> This is not feasible, at least not in the way you proposed.  For many
> properties, it would be ambiguous whether you were trying to style the
> background SVG or the element itself.  This would be especially true if
> proposed fill + stroke for CSS-styled text is adopted.  And what if you
> wanted to layer together multiple background shapes? Or declare a shape for
> a list-image custom bullet instead of a background-image?

Strongly agree.  No way this would work, ever.

> The pre-processor approaches address this by either including all SVG
> styling rules within the mix-in function notation, or by using a custom
> @-rule to declare the SVG content and styles as a structured object, which
> can then be used in individual elements (similar to how font-face declares
> all the data for a named font that can then be assigned in font-family
> declarations).
>
> With SVG code generated by a pre-processor, you cannot create live styling
> changes or animations.  However, with a function notation this should be
> possible, similar to the proposal (already implemented in some browsers) for
> animating gradients.

I have the start of a draft to be able to write SVG directly in your
CSS stylesheet and then ref it as an image - it's what the PostCSS
@svg rule was directly based on.  (I haven't actually written it up,
it looks like, but the idea is trivial - just convert elements into
@-rules and attributes into properties.  There are some questions to
deal with about IDs and such, which def need to be answered, but the
gist is easy to understand.)

> 3) Develop a new syntax to define SVG paths with certain points that stretch
> relative to 100% width or height
>
> This is not feasible in the way you proposed, but should be feasible in
> general.  However, it should be defined for SVG in general, not just a
> special CSS syntax.  It's certainly something that's been requested on the
> SVG side previously.  Negative numbers already have a valid meaning in SVG
> paths, so that won't work, but other syntaxes could.
>
> I've just posted a proposal to the SVG working group's issue tracker to
> encourage us to think seriously about it:
> https://github.com/w3c/svgwg/issues/72

Yes, this would be useful, but it also needs to take place as part of
an overall overhaul of path syntax.  Current path syntax is
*terrible*: it tries to satisfy both "hand authorability" and "minimal
byte size" and only succeeds in being pretty bad at both; it's not
extensible in many ways (letters always start new path commands, so
it's very hard to add anything like units); some commands are
inscrutable and very difficult to hand-author, like the curve
commands.

> As others have noted, CSS shapes is already adopting SVG path notation for
> things such as clip-path and motion path.  A new image-generation function
> would want to be compatible with these syntaxes.

Yup.

~TJ

Received on Monday, 21 March 2016 18:34:49 UTC