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

Hi, Folks-

Boris Zbarsky wrote (on 1/23/09 9:25 AM):
> Marcos Caceres wrote:
>>> That really depends on what the goal is.  What _is_ the goal?
>>
>> The goals are as follows:
>>   1. Widget engines optionally support SVG Tiny for the icon format
>> (though they can have the capability to render full SVG).
>>   2. For the purpose of widgets, icons are written by authors to
>> conform to SVG Tiny (not full)
>>   3. Widget engines that support full, can render icons in SVG Tiny...
>> but, for interop, widget engines should not render icons written in
>> SVG Full 1.1 (unless the icon also conforms to SVG Tiny).
> 
> Goal 3 is what my original comment was about, basically.  It means that
> a widget engine cannot make use of various existing SVG implementations
> that just happen to support more than just SVG Tiny.  In particular, it
> means that Gecko, say, would not be able to implement this specification
> without sprinkling code all over to validate SVG files against SVG Tiny
> (something we don't plan to do, since that's not the profile we're
> implementing).
> 
> I understand where you're coming from with this goal, but I'm not sure
> it's worth the restriction it imposes.
> 
> 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.


> 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.

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
 "http://www.w3.org/TR/SVG11/feature#SVG-static"

SVG Tiny 1.2
 "http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-animated"

If you would like me to work up proposed spec text, I could oblige you.

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.

[1] http://www.schepers.cc/svg/blendups/embedding.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Wednesday, 28 January 2009 19:00:03 UTC