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

Hi Andrew,

There are a few different aspects to your proposal, so I'm going to break
them down step by step:

*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.


*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?

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.


*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


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.


~ABR