Re: [css-writing-modes][svg] Embedded SVG and inheritance


> On May 10, 2015, at 2:17 PM, Koji Ishii <kojiishi@gmail.com> wrote:
> 
> After learned a bit of SVG, I understand this issue is more
> complicated than thought.
> 
> Amelia and Leonard suggested that SVG wants to inherit when SVG is
> used to style text within HTML (e.g., decorative headings) cases.
> fantasai and I had a mind that SVG when used as an image should not
> inherit. I understand these are two separate use cases and desired
> behavior vary.

In general an SVG image should be isolated from the context it is put in. This was a strong request that we got from security people in the past as well.

There is a proposal to relay certain values/information into a SVG document which can be referenced within the SVG document (similar to CSS custom properties just that the property is set by the context the SVG image gets embedded to). Jonathan Watt from Mozilla presented this proposal to the SVG WG at a F2F in London at some point. This is probably the opt-in way you are talking about?

However, in all other cases, the SVG context should be isolated from the host context for images. Both, SVG and HTML share the same context for inline SVG on the other hand. For iframe and embed it shouldn’t be any different than for HTML in an iframe.

Greetings,
Dirk

> 
> So the discussions we need are:
> 1. How to allow authors to switch between these two models
> 2. Which is default -- opt-in or opt-out
> 
> My guess is that use-as-image is more common, and I prefer to default
> to it, but I don't have any data on it.
> 
> Tab suggested that moving to opt-in by default can break the web compat.
> 
> The current situation is more complex than I thought.
> 
> The color property, for instance, inherits, but it does not affect
> unless author specifically use, for instance, fill="currentColor".
> Without the fill attribute set to "currentColor", <text> renders in
> black, not the value of the color property, so it's an "opt-in" model
> to inherit.
> 
> The font-variant inherits and has the same syntax on the same
> property, so it's an "opt-out" model to inherit. But practically it's
> unlikely to apply font-variant to whole document.
> 
> The writing-mode has additional complexity here:
> a. Blink/WebKit is opt-in today because of prefix and renaming. IE is
> opt-out, Gecko Nightly is opt-out (but hasn't shipped yet)
> b. Even if we inherit, it'll simply break the SVG document, because
> SVG uses physical coordinates. Changing writing-mode without changing
> coordinate and spacing system will simply result in broken pictures.
> c. Spec-wise, how to interpret "vertical-rl" value in SVG when
> inherited is undefined, which I suppose to mean invalid. Implementing
> this behavior does not make much sense to me, so I wish the spec to
> change. Gecko already handles this according to Jonathan.
> d. Spec-wise, how to interpret "tb-rl" value in HTML is "wish to".
> Should we change this to "should" for better interoperability?
> 
> So for writing-mode, regardless of #1/#2 above, I think we should define:
> 3. writing-mode should not inherit into SVG.
> 4. Consider Tab's nested cases more in depth, and come up with
> necessary actions.
> 5. Clarify how to interpret renamed values better, in HTML and SVG.
> 
> Thoughts?
> 
> /koji
>

Received on Monday, 27 July 2015 08:43:11 UTC