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

Re: UA: indicate missing content

From: Doug Schepers <schepers@w3.org>
Date: Sat, 26 Jul 2008 10:15:17 -0400
Message-ID: <488B3175.2020607@w3.org>
To: www-svg <www-svg@w3.org>

Hi, Jonathan-

You're right, this is not adequately defined in the spec, particularly 
in the case where a <use> references an element that isn't there.

I made a number of clarifications to the spec in particular places, 
which you can read and see if you think this behavior suits your use cases:


Keep in mind that these changes are not yet approved by the SVG WG, but 
I am confident that we will make some clarification, even if it's 
different than my suggested changes.

-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

Jonathan Chetwynd wrote (on 7/26/08 8:16 AM):
> Helder,
> thanks once again, I'm content to file bugs with the UAs, however this 
> wasn't my intent.
> Rather that the description given is not sufficient.
> Graphics are a complex area, and describing what is missing and where, 
> will be hard if it is to be consistent across UA.
> which users expect, perhaps demand...
> as you indicate there appears to be no guidance on the author providing 
> 'alt' content, nor a method or technique.
> a test case is here: http://www.openicon.org/feeds/exResReq.svg
> What is the rationale for the default being false?
> this must inherently be confusing for the user, as they will not be 
> aware of the issue.
> and the author too who has not considered this matter, does not refer to 
> the specs or uses a tool that does not require or automate this matter.
> regards
> Jonathan Chetwynd
> j.chetwynd@btinternet.com
> http://www.openicon.org/
> +44 (0) 20 7978 1764
> On 26 Jul 2008, at 11:43, Helder Magalhães wrote:
>>> current UA do not indicate missing content either with graphic or text.
>>> iirc batik wont display at all, others ignore.
>>> Is there a recommendation on this issue?
>> [...]
>>> html UA generally provide an empty box with a cross or similar and alt
>>> content
>> The external resources property [1] seems to imply a recommendation on
>> this: error processing notes [2] states that:
>> «A highly perceivable indication of error shall occur. For visual
>> rendering situations, an example of an indication of error would be to
>> render a translucent colored pattern such as a checkerboard on top of
>> the area where the SVG content is rendered.»
>> I'd interpret the whole as: if a document portion is marked with
>> "externalResourcesRequired" set to "true" and the external resource(s)
>> is(are) not available, then mark that portion with a checkerboard (or
>> similar). Please correct me if this sounds naive!
>> So, if your findings are correct (didn't check implementations
>> myself), user agents seem to be the ones which need to catch up. ;-)
>> As an implementation suggestion, one might use conditional processing
>> [3] to achieve a desired fall back. Using a "switch" containing
>> external resources required feature string [4] for UA which support
>> external resource loading (with proper error processing) and
>> alternative content for cases (where the UA doesn't contain the
>> feature string) might do the trick! :-)
>>> I recognise the SVGWG may not be chartered to consider UA issues, 
>>> however
>>> and there does not seem to be another suitable public space to raise 
>>> this.
>> I believe the SVGWG is the proper place for discussing user agent
>> matter (which relates to SVG, of course). For instance, there are
>> guidelines for user agent behavior spread over the specification (for
>> example, in implementation notes section [5]).
>> Hope this helps,
>> Helder Magalhães
>> [1] http://www.w3.org/TR/SVG/struct.html#ExternalResourcesRequired
>> [2] http://www.w3.org/TR/SVG/implnote.html#ErrorProcessing
>> [3] http://www.w3.org/TR/SVG/struct.html#ConditionalProcessing
>> [4] http://www.w3.org/TR/SVG/feature.html#ExternalResourcesRequired
>> [5] http://www.w3.org/TR/SVG/implnote.html

Received on Saturday, 26 July 2008 14:15:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:19 UTC