W3C home > Mailing lists > Public > www-svg@w3.org > March 2009

Re: systemLanguage errata

From: Doug Schepers <schepers@w3.org>
Date: Thu, 19 Mar 2009 00:10:03 -0400
Message-ID: <49C1C59B.2080507@w3.org>
To: Jonathan Chetwynd <j.chetwynd@btinternet.com>
CC: www-svg <www-svg@w3.org>, Erik Dahlström <ed@opera.com>, stuart.morgan+bugzilla@gmail.com, mark@moxienet.com, alqahira@ardisson.org, longsonr@gmail.com
Hi, Jonathan-

Jonathan Chetwynd wrote (on 3/18/09 5:47 AM):
> how is progress regarding the systemLanguage errata logged one year ago?
> http://www.w3.org/2003/01/REC-SVG11-20030114-errata#language-switch-processing
> It seems there may be general agreement* that language preference is desirable
> for the user, but without a published errata it will not be implemented.

As you know, the SVG spec derives the <switch> element from SMIL.  As 
such, we could not define the behavior ourselves in a manner that 
conflicts with SMIL.  However, we recognized the merit in your argument 
regarding the quality values in the Accept-Language request-header 
field, and spent a good deal of time coordinating with the SMIL WG on 
this issue.

As a result, the recent SMIL 3.0 publication contains the following 
provision for your use-case:

Authors should order the alternatives from the most desirable to the 
least desirable. Furthermore, authors may wish to place a relatively 
fail-safe alternative as the last item in the switch so that at least 
one item within the switch is chosen (unless this is explicitly not 
desired). If all alternatives are equivalent an author should signal 
this through the allowReorder attribute on the switch, this gives the 
user agent the freedom to pick the best match (as opposed to the first 
]] [1]


The allowReorder Attribute

The allowReorder attribute signals whether a user agent may reorder the 
direct descendents of the switch element, based on user preferences, if 
it thinks this could lead to a better user experience.

The possible values are 'no', the default, disallowing reordering and 
'yes', allowing reordering.

This section is informative.

User agents are free to ignore the allowReorder attribute, but if they 
implement prioritized language ranges as defined in BCP47 [BCP47] they 
are expected to use that prioritization to reorder children with 
systemLanguage attributes. The effect should be that the users are 
presented with the alternative that best matches their language 
preferences. Any final child without systemLanguage attribute should 
retain its place as the default item to present.

Authors should add the allowReorder attribute if all items in the switch 
are equivalent.
]] [2]

While this was not the fix that the SVG WG proposed, I believe that it 
should address your use case, provided you put @allowReorder="yes" in 
your <switch>.

However, the SMIL WG did not inform the SVG WG of this final resolution, 
so we did not know to include the 'allowReorder' attribute in the SVG 
Tiny 1.2 spec.  It's questionable whether we can retroactively add this 
into SVG 1.1 or SVG Tiny 1.2 (we will if we can), but we do intend to 
add it to SVG 2.0 (though with clearer and more normative prose).

In the meantime, it is up to implementers to decide if they are willing 
to add the attribute.  Certainly, it is in a Recommendation, and SMIL is 
the canonical (and normative) source for the <switch> element in SVG, so 
my view is that it should be perfectly cromulent to implement it on this 

With regard to Mark Mentovai's comment [3], I agree that this would best 
be filed as a new bug, since it doesn't call for a change to current 
<switch> behavior, but rather adds new functionality if the 
'allowReorder' flag is true.  Personally, I would guess this would be a 
pretty trivial patch, and would have no negative impact on existing content.

Thanks for your persistence in following up on this, and for filing the 

[1] http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-content.html#q6
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=326375#c36

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Thursday, 19 March 2009 04:10:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:16 UTC