Re: minutes, SVG F2F Pymont, Sydney day 5 (08/02/2013)

I think everyone was in agreement that we don't want to limit the SVG
feature set or add features just for SVG OpenType fonts.
We can let it up to the user agent to gracefully degrade the experience if
they don't support a particular feature (ie video could just show the
poster frame).

We were thinking of not allowing foreignObject since that can pull in HTML
and might be harder to control securily.

Rik

On Fri, Feb 8, 2013 at 8:28 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> One other thing: I don't think we should be too eager to define a new SVG
> subset for fonts, mainly because the problem we'd be trying to solve with
> that is purely theoretical at this point. We don't know of any platforms
> that have non-Web-capable SVG renderers that need fonts with SVG glyphs.
> I'm not eager to spend time and energy specifying and implementing
> restrictions on SVG glyphs for a problem that may never exist. It's similar
> to how, not all that long ago, we spent time and effort (and messed up SVG
> somewhat) to make SVG not dependent on CSS --- a requirement that is no
> longer relevant and really never was. Let's not tackle another such
> non-problem.
>
> A precedent: we've already deployed SVG images widely with no particular
> SVG subset defined for SVG image content and things seem to be going OK ---
> we haven't heard about platforms with limited SVG renderers trying to use
> SVG images and failing. The fact that unsupported SVG features often
> degrade gracefully helps.
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
>