Re: Proposed Text for Unresolved Resources

Hello Doug.

I agree that it’s good to have this defined.  Some specific comments
below.

Doug Schepers:
> In response to an email by Jonathan Chetwynd regarding the behavior of  
> unresolved resources, I added proposed wording to the spec for how to  
> deal with this [2][3], and tightened up the definition of bounding box  
> [4] to say:
>
> "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]?

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

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?  Also I don’t know what “that
matches the same criteria” is referring to.

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”?

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?

If the <title> or <desc> is used as the fallback (and I think this
should be mandated to be both if both are present), 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?  What about for <use>,
where no size (only position) can be supplied, or <audio> which doesn’t
have any location?

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

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.

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.

Also note that you seem to have checked in some conflicts in intro.html.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Sunday, 27 July 2008 01:40:51 UTC