- From: Doug Schepers <schepers@w3.org>
- Date: Sun, 26 Apr 2009 22:48:01 -0400
- To: public-svg-wg@w3.org
Hi, Cameron-
Thanks for the review! Replies inline...
Cameron McCormack wrote (on 4/26/09 4:38 AM):
> In the Introduction:
>
> To address this, this specification also extends the defaultView
> interface to provide a generic and secure means of passing parameters
> into a referenced file.
>
> it’d be more accurate to say:
>
> To address this, this specification defines an interface to provide a
> generic and secure means of passing parameters into a referenced file.
> This interface is intended to be implemented on all objects that
> implement the Window interface.
Changed. Since Window isn't stable, and HTML5 is unlikely to be done
anytime soon, and we don't define Window for SVG, I'd like to explore
options around defaultView... isn't defaultView equivalent to Window,
effectively?
> In the Requirements section:
>
> Any valid SVG 1.1 Referenced Parameter Variables must be a valid SVGx
> Referenced Parameter Variables.
> …
> Conformance test suites for other uses of SVGx (e.g. prepress
> guidelines) may be developed.
>
> I’m not sure what these mean.
>
> A dynamic SVGx viewer must support the SVGx scripting feature set.
>
> Not sure what this means either, but the wording sounds familiar. Was
> this copied from another spec?
All that is just template stuff (which I think I originally got from
Filters or Vector Effects, maybe). I've commented most of it out, and
will remove it if it's not applicable.
> Some of the definitions come from 1.2T, I guess. Is it best to copy
> these over into this spec or just to link to the 1.2T definitions
> directly? Same for the data types.
Almost all of them, though I tweaked them not to be SVGT1.2-specific. I
included definitions inline to err on the side of making it easy to
read. I don't have a strong policy opinion, though I'd like to see
these definitions in their own spec, so we could reference them more easily.
> In the The ‘ref’ element section:
>
> When acting as a paint server, the child character data content shall
> be treated the value (as text) of the ‘ref’ element; this is unlike
> other paint servers, which provide the value of the paint as an
> attribute value, the ‘ref’ element.
>
> s/treated/treated as/
>
> I don’t really understand the bit after the semicolon. How do paint
> servers provide the value of a paint as an attribute value?
It's very simple, really...
/me waves hands
> As mentioned briefly on last Wednesday’s telcon, I don’t think it’s a
> good idea for the <ref> element to actual change its own child text
> content, so that <tref> behaviour can work with parameters without
> modification. I think it would be better to have <tref> referencing a
> <ref> element mean that special behaviour is needed (looking up the
> parameter instead of looking at the textContent).
I don't have a problem having text-content mutable any more than
attribute content. An advantage of it being child content is that you
could put anything in there, including markup (<tspan>, etc.).
Actually, that's not true, never mind... <tref> wouldn't pull that in
anyway...
I can see it your way.
> I think at the beginning section there should be a definition of what
> the value of a<ref> element means. For example:
>
> Every<ref> element has an associated /value/, which is determined
> based on the ‘param’ attribute and the set of name/value parameter
> pairs that are available for reference.
>
> so that later on when it says “The value of the ‘ref’ element shall be
> derived …” the concept of a<ref> element having a value has been
> introduced.
Added.
> Is the value of a <ref> element always a string?
The way I thought of it, more or less, was that it is... this is also a
question we might have with regards to allowing constraints-based syntax
or any kind of evaluated values.... and this raises the larger subject
of allowing CSS to set most/any attribute values. This is a can of
worms, but since we've been meaning to fish for improvements to SVG,
that might be unavoidable.
> If the parameter information changes, and a the new information does
> not contain a name that was previously matched by the value of the
> ‘param’ attribute, then the existing child character data content
> shall reflect the existing content; it must not change back to the
> original child character data content.
>
> Any reason for this? I would think it makes more sense for it to revert
> to the default that was specified.
Depends on the model. Is the content changing, or is it being animated?
I can see arguments either way.
> The ‘ref’ element can also act as a mechanism to pass parameters to
> externally referenced resources, in a manner similar to the HTML
> ‘param’ element of the HTML ‘object’ element [HTML4]. In this case,
> the ‘param’ attribute must act as the ‘name’ portion of the name-value
> pair, and the child character data content must act as the ‘value’
> portion of the name-value pair.
>
> How does this work?
I haven't described it in detail, but this is the idea... Given 2 files,
'farm.svg' and 'shinyDonkey.svg':
farm.svg:
<svg ...>
<image x="50" y="50" width="333" height="502"
xlink:href="shinyDonkey.svg">
<ref param="color" default="gray"/>
</image>
</svg>
shinyDonkey.svg:
<svg ...>
<defs>
<ref id="pelt" param="color" default="gray"/>
</defs>
<path id="donkey" d="..." fill="url(#pelt)"/>
</svg>
Basically, <ref> can be used inside SVG files the same way <params> is
used in <html:object> elements. One interesting side effect of this
would be that you could nest multiple levels of SVG files, and pass
parameters down the chain, using a single <ref> element.
> The ‘ref’ element shall be referenced in two ways:
> …
> * as the value in any attribute, as a<FuncIRI>
>
> There are attributes other than xlink:href="" on <tref> where a string
> that matches FuncIRI is already a valid attribute value, such as
> unicode="" or glyph-name="" on<glyph>, the various value-related
> attributes on animation elements, and the RDFa-ish attributes.
Will have to think about that...
> An alternative syntax strawman (not to solve the previous paragraph):
>
> <g>
> <rect id="button_rect" x="5" y="5" width="100" height="30" rx="15" ry="15"
> fill="param(color, blue)" stroke="param(outline, navy)" />
> <text id="button_label" x="55" y="30" text-anchor="middle"
> font-size="25" fill="black" font-family="Verdana">
> <tspan content="param(text-label, 'button')" />
> </text>
> </g>
>
> where content="" is a presentation attribute for the CSS ‘content’
> property. An advantage would be that param() could be used in CSS
> without the need for an <svg:ref> element, so it could easily be used in
> HTML+CSS content.
My original idea looked like this, but then I mutated it to match the
tref/filter/gradient mechanism. I was actually toying with similar
syntax again, and I think it might actually be better in some ways.
For 'fill' and 'stroke', we already allow fallbacks, so we could reuse
that functionality:
<rect ... fill="param(color) blue" stroke="param(outline) navy" />
I like the idea of adding a new fallback content mechanism on <tref>,
since FF doesn't support <tref> yet (and if the reference doesn't
resolve, the user has no idea that some text should have been there).
I'm not so convinced that it should be an attribute rather than child
content, but I also don't want to complicate the mechanism.
> If the IRI reference is invalid (for example, it points to an object
> that doesn’t exist or the object is not a valid paint server or it is
> a non-local IRI reference and the viewer does not support it), then
> the fallback value (if specified) is used; otherwise it must be
> treated as if none was specified.
>
> I guess this wording needs to be updated from when only paint servers
> were referenceable.
Right... assuming we go with the original mechanism, and don't change to
the simpler "param(name)" syntax.
> In the DOM interfaces section:
>
> For parameters that are passed in via the HTML ‘param’ element, the
> user agent must add to this list only values which have the
> ‘valuetype’ of ‘data’.
>
> I’m intrigued by this valuetype="" attribute. :) What other types do
> you expect to support?
I didn't plan to support any of them, which is why I called it out
'data' specifically as the only one supported. In HTML4 [1], the
following values are listed, but I don't know if they are implemented or
used:
valuetype = data|ref|object
>Is valuetype="" on <ref>?
No.
> Objects that implement the defaultView or Window interfaces must also
> implement the WindowParameters interface:
>
> I think you can just say:
>
> Objects that implement the Window interface must also implement the
> WindowParameters interface.
That's assuming we want to yoke this to some as-yet-undone Window
specification.
> I think you need two interfaces: one, WindowParameters, which is
> simplemented by all Window objects and would look like this:
>
> interface WindowParameters {
> readonly Parameters parameters;
> };
>
> and Parameters, as currently in the spec.
Ok. Added the skeleton of that.
> This interface is read-only. Should there be a read-write interface
> available to the referencing document, to allow easy script access to
> parameters, so they can be changes without modifying the URL query
> string or creating ‘param’ elements?
>
> It might be handy, but I don’t think it’s critical. I guess you would
> need to define, for a given embedding context, what parameters get
> updated when you change them (e.g. the <param> or the URL parameter).
Maybe something for a later version of the spec, if this is successful.
> Does allowing the author of the referencing document to override
> parameters defined in the URL strings constitute a security or
> propriety risk? What if a site serves a customized resource based on
> a URL string, and that is overridden at the param or script layer, so
> that what is served (think of an ad) is not what what intended by the
> SVG’s content provider. Changing the URL in this case would let the
> content provider know, while changing the ‘param’s or modifying the
> parameters list through script would not. Is this a legitimate
> concern?
>
> Perhaps then the content shouldn’t be using the <ref> mechanism to allow
> the content to be parameterisable. In HTML, allowing<param> to
> override the URL query string parameters in the Parameters object
> wouldn’t change what resource is fetched, I imagine.
I still think it's useful to have a generalized way of getting at
parameters, and in any case, the issue of multiple parameters has to be
addressed.
> Should we expose where the parameter came from, in terms of URL query
> string, ‘param’ element, or other? Should we expose the domain of the
> document where the parameter was set?
>
> Might be a cross-domain problem. In a frame, you can’t get
> window.parent.document.domain unless it’s same domain. (Though I
> suppose with CORS that could be alleviated.) What’s the use case for
> exposing the domain? To determine whether to “trust” the parameter or
> not?
Yeah, I was just musing through various kinds of data that might be exposed.
> Consideration will need to be given to how parameter references on
> attributes are exposed in the SVG DOM. For example with:
>
> <circle r="url(#whatever)"/>
>
> what is circle.baseVal.value and circle.animVal.value? Do these
> parameter references work at the same level as animated values?
Agreed, I thought about that but didn't dig into it. We will face this
same thing if we allow any kind of functional values, like constraints,
too. How does this work for gradients?
> That’s all for now. I don’t think any of these need prevent
> publication. I look forward to the functionality being implemented. :)
I've already implemented it! Oh, you mean in browsers... :)
Unfortunately, not that useful in Batik, maybe... unless you're using
the URL query string. But I know you're busy.
[1] http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3.2
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Monday, 27 April 2009 02:48:12 UTC