W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

Re: UA: indicate missing content

From: Doug Schepers <schepers@w3.org>
Date: Tue, 29 Jul 2008 05:37:55 -0400
Message-ID: <488EE4F3.5090304@w3.org>
To: www-svg <www-svg@w3.org>

Hi, Helder-

First, let me thank you for your research and thoughtful comments. 
However, I think you are conflating the wording in SVG 1.1 with the new 
proposed wording.  SVG 1.1 is simply unclear, and doesn't provide for 
all the use cases.  Consider the proposed wording to supersede the 
wording in SVG 1.1.

Comments inline...

Helder Magalhães wrote (on 7/29/08 4:42 AM):
>> If this doesn't meet your needs, let us know specifically where it needs
>> work, and suggest specific remedies.  The current working plan is that if no
>> fallback content is provided for an element with no specified dimensions,
>> nothing would be displayed.  Note that for SVG Full, <use> does have 'width'
>> and 'height' attributes.
> 
> I've read the clarifications but (please correct me if I didn't
> understood them as expected) I don't feel they address what's being
> discussed within this thread. I'd suggest clarifying what should
> happen with the bounding box while external resources bring (can this
> happen?) the main document to an error state:
>  * While the resources aren't yet available and
> "externalResourcesRequired" is set to "false" or not specified;
>  * When "externalResourcesRequired" is set to "true" and resource
> fetching has reached a dead end (timeout or not found);
>  * If an external resource is available but contain an error (parse
> error, invalid attribute values, etc.);
>  * Probably more I'm missing at a first glance.

Thanks, I'll clarify this in the wording.  (Note that some of this is 
already covered by the current wording).

"externalResourcesRequired" is a red herring.  It applies equally to 
missing or not-yet-available local resources equally, something that 
SVG1.1 doesn't deal with.


> Note that I haven't found evidence that external resources will bring
> the document which refer them into an error state: I didn't found
> information regarding this but I believe that, if this specific
> behavior isn't already specified, then IMHO it should be (too). :-)

SVG 1.2 Tiny (and Full) have a more forgiving error-handling mechanism 
than SVG 1.1, such that most unsupported attribute values do not 
actually trigger an "error state" per se.  We are discussing making 
unresolved references (broken links) one of these less drastic 
unsupported attribute values.


> I agree with Jonathan in respect to the need of somehow marking these
> error situations in a coherent way, so that it's clear across
> different implementations that the external resources which should be
> there are erroneous. Although I wasn't able to find a reference to
> related HTML recommendations on the subject, I believe the behavior
> for broken images (for example) is more or less familiar across
> implementations. Specifying general fall back mechanisms [1] for
> external content and placing alternate text as mandatory [2] (though
> also commonly misused just to pass validation) were important steps
> taken by HTML in the past. 

I'm a little confused.  Is there something wrong with the proposed 
wording, such that it doesn't satisfy some of these requirements?


> SVG already contains equivalent (and IMO
> even more powerful) mechanisms, such as the "switch" for fall back
> behavior and the "title"/"desc" elements for alternate text (which,
> for example, can be used  for cases when a given element can't be
> rendered).

The proposed wording significantly improves upon the fallback options.


> (Erik)
>>>> In case a checkerboard pattern is desired here note that <use> elements
>>>> in general don't specify their dimensions, and that in 1.2T there are no
>>>> 'width' and 'height' attributes on <use>.
> Oops, this is no good regarding what's being discussed here... Doug
> has stated that SVG full does have these properties so, if visual
> marking for unresolved external resources is to be made, this may need
> to be revised... :-|

That's what my proposal does... it clarifies a part of the spec that's 
been a little fuzzy up until now.

Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF
Received on Tuesday, 29 July 2008 09:38:34 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:39 GMT