Re: SVG as Widget Icon (was: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009)

Hi Doug,
On Wed, Jan 28, 2009 at 6:59 PM, Doug Schepers <> wrote:
> Hi, Folks-
> Boris Zbarsky wrote (on 1/23/09 9:25 AM):
>> Things will get even worse once SVG Tiny 1.2 is a REC, since at that
>> point I fully expect pretty much all SVG engines supporting SVG Tiny to
>> implement that specification, and at that point there will be no SVG
>> engines that can be used for Widgets at all (since all of them will
>> render things that are not valid SVG Tiny 1.1).
> SVG Tiny 1.2 became a Recommendation in December 2008, and even previous
> to that, most commercial SVG Tiny UAs (those for mobile devices) had
> already implemented SVG Tiny 1.2.

Ok, good to know.

>> So unless you really mean to exclude SVG engines that happen to
>> implement SVG Full 1.1, SVG Tiny 1.2, SVG Basic 1.1 from being used in
>> widget implementations (possibly forcing the widget UA to ship two
>> separate SVG engines, one for widgets and one for everything else it's
>> doing), I think you should drop goal 3 and leave the authoring requirement.
>> That is, just have image/svg+xml work the same way in Widgets as it does
>> over HTTP, with the authoring requirement, presumably enforced by
>> validators of widgets but not widget UAs, that the images conform to SVG
>> Tiny (1.1 or any version; up to you).
> I think that rather than specifying a particular spec or profile, the
> Widgets spec should instead reference a feature set that is appropriate
> for use as a icon.

Ok, we want to keep this as the authoring level as to not force
implementations to have to ship with stripped down SVG renderers.

> My recommendation is that you include normative references not only to
> SVG Tiny 1.1, but also SVG Full 1.1 (which is largely implemented in
> desktop browsers, and probably has the most current implementations),
> and SVG Tiny 1.2 (which is the most recent SVG Rec, and is deployed most
> widely on mobiles).  That way, as Boris said, any SVG-capable UA can
> meet the conformance requirements.
> In the next version of the SVG spec, we will make it easier to reference
> particular needs and use cases, but in the meantime, I think the best
> thing would be to outline what capabilities should and should not be
> allowed for presenting an SVG icon.  Specifically, static image
> rendering must (or should) be required, but for security reasons, no
> script and no interaction (not even linking) should be allowed; however,
> declarative animation should be allowed, so that authors can provide
> animated icons (assuming the UA supports it... right now, FF doesn't,
> but should soon).  It is rather more questionable whether video or audio
> should be allowed, or things like HTML embedded in <foreignObject>
> (which seems okay to me).
> This is the same set of restrictions we would expect for referencing an
> SVG as an <img>, as I discuss in my little overview page on the matter.
> [1]  Again, this is something I think FF and WebKit are working on this,
> and Opera supports this already.
> I wish it were easier to simply point to a section of an SVG spec that
> describes these capabilities (again, next spec version...), but for now,
> the Widgets spec should describe these constraints explicitly (if
> briefly), referencing these featurestrings:
> SVG 1.1
>  ""
> SVG Tiny 1.2
>  ""
> If you would like me to work up proposed spec text, I could oblige you.

That would be great! The relevant sections are:

> On another topic, I would like to use Widgets with pure SVG content,
> rather than including HTML... I didn't see a clear way to do this, nor
> was it explicitly disallowed.  I'll review the spec more to see if there
> are problems in this regard.

You will be happy to hear that it's relatively easy to make an SVG only widget:

  <content src="some.svg" type="image/svg+xml" />

Kind regards,

Marcos Caceres

Received on Thursday, 29 January 2009 12:53:59 UTC