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

Re: On being humane

From: Doug Schepers <schepers@w3.org>
Date: Thu, 19 Mar 2009 19:51:33 -0400
Message-ID: <49C2DA85.6010609@w3.org>
To: www-archive <www-archive@w3.org>
CC: process-issues@w3.org
Hi, Jonathan-

The specified behavior in the SMIL 3.0 Recommendation is not what I 
would have chosen (indeed, I worked out a detailed proposal that had, I 
believe, more intuitive behavior, on behalf of the SVG WG).  However, I 
think you left out some important details that an objective audience 
might like to know, and which affected the decision to specify the 
behavior as it is.

1) <switch> is intended for a larger set of conditional decisions than 
just language (I understand that that is your primary use case, but 
there are others who use it for a wide variety of other purposes [1]), 
which have only single settings, not the complex combinations possible 
with systemLanguage; having other behavior would impact performance for 
all the non-systemLanguage uses;

2) the user would only get their non-preferred language if they had 
listed a selection of acceptable languages, *and* one of their 
non-preferred language choices was higher in the <switch> options than 
their preferred language, *and* the author did not set @allowReorder="yes".

While setting multiple languages and their relative order of preference 
is an option available in several browsers, but it is not enabled by 
default and it's not clear how commonly it's used.  For those people who 
use the default setting of having only their language listed (my guess 
is, the majority of people), the default behavior of <switch> would just 
work.

If an author is so conscientious as to provide multiple language options 
using <switch> with @systemLanguage, they would be likely to also take 
the small extra step of using @allowReorder="yes" (easily done, and a 
best practice when language-switching is the primary purpose of that 
<switch> element).

So, I agree this is not ideal for your use case, but it is a fairly 
reasonable solution.  Things that are easy to explain in plain language 
are not always easy to specify in a way that is efficient or easy to 
implement (it's easy to talk about a mobile device reading a street-sign 
to a blind person, harder to make it work).

I see this case as a small success of the W3C process, and the Open Web 
in general:
* you, a person not affiliated with any large corporation, notice an 
edge case that does not work as you'd expect
* you, on a volunteer basis, filed a bug with all the major browsers
* you were given the explanation for the behavior by other volunteers 
and by people working for the vendors
* you reported the flawed behavior in late 2006 to the SVG WG
* I picked up the issue (I was also essentially a volunteer at the 
time), and figured out that it was actually a SMIL (not SVG) issue
* I came up with a proposed solution, talked it over with you and other 
interested parties in a public forum
* I brought my proposal to the SYMM WG (the group responsible for SMIL) 
as an inter-group liaison
* the SYMM WG did some tests, and figured out some challenges to my 
approach (though I don't completely agree with the results)
* the SYMM WG came up with a solution that address the common case 
without breaking existing content, even though it wasn't their primary 
use case
* SMIL 3.0 was published as a Recommendation in late 2008, with a 
workable solution to your issue, 2 (not 6) years after you reported the 
problem
* based on the Recommendation status of SMIL 3.0, browser vendors can 
implement this fix right now (since that was their chief objection).

Could things have gone faster or smoother?  Yes.  The browser vendors 
could identified the problem, figured out its real origin, could have 
devised and implemented a solution, and gone directly to the SYMM WG, 
participated in correcting the spec and providing resources to move it 
to Rec faster.  But everyone has limited resources, and this is (let's 
be realistic) an edge case (even if a reasonable one).  But though it's 
an edge case, a set of people each took part of the load, and worked out 
something that solves one of your use cases.  Other people will now 
benefit, and will never know the details of the erstwhile problem.

If this were, as you allude, a process controlled by large corporations, 
you could have complained until you were blue in the face, and unless 
they saw a large enough profit in solving the problem (and I can't see 
that being the case), they would have done nothing.

Relax.  This one worked out okay so far.  Just go back to the browser 
vendors with the solution in hand, ask them again to implement it, and 
in future content, use <switch allowReorder="yes">.

The W3C (that is, the people who participate, the companies and 
organizations who are Members, and the Team) is always trying to improve 
how we get stuff done, but we're never going to be perfect.  Thanks for 
your active part in this small success.


[1] The various options, per 
http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-content.html#edef-switch, 
are:
system-overdub-or-caption
systemAudioDesc
systemBaseProfile
systemBitrate
systemCaptions
systemComponent
systemCPU
systemLanguage
systemOperatingSystem
systemOverdubOrSubtitle
systemScreenDepth
systemScreenSize
systemVersion


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Jonathan Chetwynd wrote (on 3/19/09 3:32 PM):
> On being humane
>
> I claim that developers and in particular the large corporations that
> fund w3c have undue influence.
> The result is a failure to include users in, and put them at the centre
> of the w3c specification process,
>
> A relatively simple example*:
>
> If someone publishes a document in a variety of languages, the average
> reader is free to choose which one to read.
> They may be expected to choose to read most documents in their preferred
> language.
> the order chosen by the author is not usually important.
>
> However until very recently, the first language when using <switch> in
> an SVG document that the user accepted was the one displayed.
>
> This is clearly unhelpful, to the user.
>
> The very recent SMIL 3.0 workaround is allowReorder="yes"
> however the default is "no"
> this again empowers the author.
>
> The user centred remedy is to ask the user, would you like this
> document, or documents in general, displayed in the authors preferred
> language, or your own? The default being your own, one would expect...
>
> This requires no action on the part of the author, and very little on
> the part of UA developers.
>
> instead of which it's taken more than six years to specify a broken kludge.
> When the proper solution is completely obvious when stated in English.
>
> unfortunately, this process also ensures that some UA developers, insist
> on implementing standards, even out-dated and old ones, rather than on
> being humane.
>
> http://www.w3.org/TR/SMIL3/smil-content.html#adef-allowReorder
> http://lists.w3.org/Archives/Public/www-svg/2009Mar/0166.html
>
> *my grandmother who is ninety six understood and was amused by this
> short story, that continues to elude the W3c process.
Received on Thursday, 19 March 2009 23:51:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:21 GMT