Re: SVG <glyph> element spec

On Fri, 21 Dec 2012 14:04:02 +0100, Stephen Chenney  
<schenney@chromium.org> wrote:

> On Fri, Dec 21, 2012 at 7:47 AM, Tavmjong Bah <tavmjong@free.fr> wrote:
>
>> On Thu, 2012-12-20 at 08:02 -0800, Dirk Schulze wrote:
>> > On Dec 20, 2012, at 2:45 AM, "David Dailey" <ddailey@zoominternet.net>
>> wrote:
>> >
>> > > The Adobe ASV viewer supports arbitrary content inside <glyph>.  
>> Please
>> let me know if a proposal to drop support for colors and other non-path
>> content inside <glyph> gains traction. Emoji contain color as a semantic
>> aspect of Unicode defininitions of characters, and as those who saw our
>> presentation in Boston about geometric accessibility, accessibility to
>> special textual affects is permanently impaired if SVG is crippled in  
>> this
>> way.
>> > >
>> > > It will be a good opportunity for me to learn to file formal
>> objections through the W3C process, and I will be certain to do so!
>> >
>> > Is there a recording of the presentation? Or do you have a link to the
>> documentation? This sounds like you are addressing pure visual aspects  
>> of
>> styling.
>> >
>> > For WebKit we decided not to support arbitrary shapes because of
>> different security considerations.
>>
>> I am curious to know what security consideration there would be to
>> arbitrary shapes as compared to paths.
>>
>> Tav
>
>
> It's not shapes that are a problem, it's arbitrary content. For example,
> SVGImage or foreign object are allowed by the spec as written, and those
> may link to external resources. Same, to a lesser extent, for <use>
> elements or anything with a href. Loading external resources has security
> implications, particularly when fonts themselves are frequently external
> resources.
>
> Stephen.

That problem applies when the svgfont is a separate (external) resource.  
The spec currently makes no difference between inline-in-svg and external  
svg fonts, or at least it's not explicitly called out or described. It  
probably should be, but it's not. It's similar to external fill, stroke,  
mask, filter, marker and clip-path, but slightly different because it's an  
@-rule (the svg markup equivalent of @font-face).

If an svgfont is inline in an svg document that allows scripting and  
linking to external resources then that applies to the inline svgfont as  
well since it's in the same document. Anything else would be strange.


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 3 January 2013 10:00:38 UTC