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:

> 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.
>
>
While inline it is still a standalone document that you cannot style from
host document side.
You cannot say:

.foo { fill:red; }
and  so
.foo:hover { fill:blue; }



>
> *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.
>
>
I am not sure I understand "ambiguous whether you were trying to style the
background SVG or the element itself"

At the moment this
div { fill:red;  }
has no effect in HTML/CSS.

It will have an effect only if we will allow element to have paths. So
there is no ambiguity.

The only problem if we will want to have several background paths and
ability to style them separately.
But that can be tackled by allowing multiple fills / strokes declarations.
Same as in background-*** properties.



> *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.
>
>
Well, SVG is a bit orthogonal to the problem and it's a separate *document*
language with its own CSS properties and  design decisions .



>
> ~ABR
>



-- 
Andrew Fedoniouk.

http://sciter.com