- From: Doug Schepers <schepers@w3.org>
- Date: Sun, 27 Jul 2008 04:45:07 -0400
- To: SVG WG <public-svg-wg@w3.org>
Hi, Cameron-
Cameron McCormack wrote (on 7/26/08 9:39 PM):
>
> Doug Schepers:
>>
>> "Elements in the rendering tree which reference unresolved resources
>> shall still have a bounding box, defined by the position and dimensions
>> specified in their attributes, or by the lacuna value for those
>> attributes if no values are supplied."
>
> To be clear, this means that <use xlink:href='#bad' x='10' y='10'/> has
> a bounding box of [10,10,0,0]?
Correct. I've added this, and we should put in a test for it.
>> I took the liberty of adding it to the spec, rather than proposing it
>> first. I know this is unorthodox, but I thought it might save us time
>> and steps, and also provide context for the additions, which is often
>> missing from simple excerpts in email. Obviously, this still needs to
>> be discussed and accepted or rejected, but since we already have the
>> ability to back out of changes via CVS, or modify the proposed changes,
>> I thought this might streamline things. If people are not comfortable
>> with this method of working, I won't do it anymore. However, I suggest
>> we give it serious consideration.
>
> Actually, I am happy with working in this manner (commit-then-review for
> changes that aren’t too controversial) and monitoring member-svg-editors
> for changes, since it moves things along more quickly.
Glad to hear it. I hope others feel the same. I think it's important
that we always check in with other WG participants to summarize and
formally propose the changes, of course, so we get the benefit of solid
feedback, consensus, and accountability.
> I like the idea of having fallback child content of <use>, <image>, etc.
> Is this only for the case when externalResourcesRequired="false"?
>
> I am not quite sure about some things in the following text, though:
>
> If an element in the rendering tree (e.g., 'use', 'image',
> 'animation', 'audio', 'video') contains a invalid reference, the user
> agent must display instead any fallback content supplied as a child of
> the element, in the following order of preference: any element in the
> rendering tree which does not contain invalid references, or its child
> content that matches the same criteria; or the contents of any 'title'
> or 'desc' element.
>
> By “any element” does it mean that just one element can be rendered, or
> should it be all graphical content?
Good point. Yes, for example, failing display of a raster, I might
provide a rough vector equivalent with multiple elements.
> Also I don’t know what “that matches the same criteria” is referring to.
Nesting... the UA would keep trying while there is fallback content,
until it finds something that will render. In this example, "good.png"
would render, but "nevermind.png" wouldn't.
<image xlink:href="bad.png">
<image xlink:href="also-bad.png">
<image xlink:href="good.png">
<image xlink:href="nevermind.png"/>
</image>
</image>
</image>
I'll try to rework that without being too vague or too verbose.
> Presumably this paragraph shouldn’t apply to things like:
>
> <image xlink:href='good' width='100' height='100' filter='url(#bad)'/>
>
> which I’d say is “an element in the rendering tree [that] contains an
> invalid reference”?
Good catch, correct. Instead of "contains a invalid reference", I've
updated the spec to say, "has an unresolved reference for the
'xlink:href' attribute". Maybe I should say instead that it has to do
with "replaced content" elements (which are listed in Rendering Model
[1] but not defined... should there be a definition for that?)?
> If you specifically don’t want anything to render if a reference is bad,
> I suppose you would do:
>
> <image xlink:href='bad' width='100' height='100'>
> <g/>
> </image>
>
> Should we mention that explicitly, perhaps in an example?
Yes, nice anti-fallback.
> If the <title> or <desc> is used as the fallback (and I think this
> should be mandated to be both if both are present),
Agreed.
> how should they be rendered? As if their contents were in a
> <textArea> that has the same dimensions as the element
> with the bad reference?
Maybe. I'm inclined to leave that up to implementors, honestly.
> What about for <use>,
> where no size (only position) can be supplied, or <audio> which doesn’t
> have any location?
Maybe something that doesn't have a bounding box shouldn't have
title/desc fallback content rendered either?
> I don’t think the placeholder graphic should use a “custom dimension” if
> a width/height isn’t given on the element, rather it should just not
> render (as is the usual behaviour for elements with zero width/height).
Sure.
> I don’t know if it’s helpful for an outline to be displayed if the
> fallback is invoked. Perhaps if the <title>/<desc> was used, but not
> for graphical fallback content.
You're probably right. I put it as a "may" in case there are UAs that
have special use cases, but I honestly can't think of one off the top of
my head.
> I think the definition for rendering tree should be updated to state
> that graphical content children of one of these referencing elements
> whose reference is OK are not in the rendering tree. The text you have
> in linking.html#unresolved-resources seems to assume that these fallback
> children are already in the rendering tree, and then says that these
> must then be rendered.
Yes, you're right. Looking at the definition for rendering tree [2], I
don't see any mention of this circumstance at all. Obviously, a
<circle> child of a <rect> element shouldn't render, but I'm having
trouble finding that explicitly in the spec. If anyone can point me to
it, please do... otherwise I will update the spec to state the details.
> Also note that you seem to have checked in some conflicts in intro.html.
Fixed, thanks.
[1]
http://dev.w3.org/SVG/profiles/1.2T/publish/render.html#TypesOfGraphicsElements
[2] http://dev.w3.org/SVG/profiles/1.2T/publish/intro.html#TermRenderingTree
Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF
Received on Sunday, 27 July 2008 19:15:42 UTC