Pre-fetch rough draft

2012-10-30 Thread Charles McCathieNevile

Hi,

I mentioned this and it's somethign we are working on.

Basic idea: site provides list of resources that it uses and can be cached  
for general improvements on the whole site. (We're seeing load-time  
improvement from 50% - 300% in our testing. We are using it on sites -  
mail.yandex.ru/prefetch.txt has an example).


The draft spec here is still very rough, but it shows what we've  
implemented and some of what we think it is good for.


This is meant as input to the appcache/packaging/etc discussion, and may  
or may not be something this group takes on.


cheers

--
Charles McCathie Nevile - private mail accountTitle: Prefetch manifests


  
  
Prefetch manifests 

  Implemented by:
  Sergey Nikitin, Ilya Golubtsov, Alexey Shakin
  Spec edited by:
  Chaals McCathie Nevile
  

Introduction 
Prefetching is a mechanism to enable periodic refreshing of static resources
  used by web pages, that are held in browser cache. It is useful for
  sites which use static resources, but often change which resources are in
  a particular page. 
The method used is to offer a list of resources
  commonly used on a website, so user agents can periodically fetch the list and
  download and cache the specified resources to speed rendering.
Related work
This work is related to cache control information. Prefetch is explicitly designed to optimise for pages which are not currently
  being requested. 
Use cases
http://news.example.com changes the headline image on the front page
  every two hours - but since the static image files themselves don't change, the
  cache-control information never reflects the change. They want to
  help browsers make the site load faster by pre-fetching the new images.
  (R1) 
The Yowser web browser checks prefetch information for current tabs, a
  user-defined number of history pages (default: the last 100 pages opened).
  It also checks for prefetch when an open page has prefetch and a link to
  another page on the same site. (R1, R2)
http://lots-of-apps.example.com has many pages which use its frameworks example.js,
  example.css, example.png, and example.ogv.
  In order to ensure that pages are rendered rapidly when navigating through
  the website, it uses a prefetch manifest to identify files that should be
  readily available even if not required on a given page.
The Amnesia browser compares prefetch information to content in its cache. If it has content that was recorded as prefetch information, and is no longer listed, it expels it from cache to save memory. 
Requirements 
R1: Prefetch information should be accessible via HTTP or HTTPS
R2: It must be possible to specify prefetch information for multiple pages on
  a single site
Defining prefetch information with prefetch.txt
The prefetch manifest is implemented by means of a resource with a
  "well-known location", analagous to robots.txt: SITE_ROOT_PATH/prefetch.txt
The file consists of a list of URLs, or comments, one per
  line. Relative
Example of prefetch.txt:
This would be the body returned by a GET request to http://example.com.prefetch.txt
# prefetch.txt. Version 1.2.34
http://yandex.st/jquery/1.7.1/jquery.min.js
//yandex.st/common/common.js
/1.2.34/css/all.css
1.2.34/js/all.js
Using prefetch information
If an Expires header is received for a resource, user agents should calculate a random delay from
  that should be added to the expiry time, to help avoid a DDOS effect from a large number of browsers making prefetch requests.
Prefetch requests must not include cookies.
A user agent may record prefetch information for URLs.
Unless otherwise specified, browsers should respect cache-control. Do we need to say that, or is it obvious?
When a user agent opens a URL it should check whether it has prefetch information recorded. If there is no information, it should request /prefetch.txt (resolved relative to the URL) and record the result. If there are resources listed in prefetch.txt which are not in the user agent's cache, it may fetch
  the resources specified.
  



Re: CfC: publish new WD of File API; deadline July 3

2012-06-27 Thread Charles McCathieNevile
On Tue, 26 Jun 2012 20:35:46 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


Hi All - Arun is back to actively editing the File API spec and this is  
a Call for Consensus to publish a new WD of the spec. Please note that  
Arun will be committing some changes during this CfC and that the ED  
does not yet use the WD template:


http://dev.w3.org/2006/webapi/FileAPI/

Agreement to this proposal: a) indicates support for publishing a new  
WD; and b) does not necessarily indicate support of the contents of the  
WD.


Please publish.

cheers

If you have any comments or concerns about this proposal, please reply  
to this e-mail by July 3 at the latest.


Positive response to this CfC is preferred and encouraged and silence  
will be assumed to mean  agreement with the proposal.


-Thanks, AB




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Fwd: TPAC 2012 Registration

2012-06-22 Thread Charles McCathieNevile
We are meeting on the Monday and Tuesday. Don't forget to pay the daily  
attendance fee early enough to get the cheap rate.


And see you in Lyon (my favourite TPAC venue so far...)

cheers

Chaals

--- Forwarded message ---
From: Ian Jacobs i...@w3.org
To: W3C Members w3c-ac-fo...@w3.org
Cc: W3C Chairs cha...@w3.org
Subject: TPAC 2012 Registration
Date: Thu, 21 Jun 2012 22:19:56 +0200

Dear Advisory Committee Representatives, Chairs, AB, and TAG,

Registration for TPAC2012 is now open (until 16 October):

   TPAC 2012
   29 October - 2 November
   Lyon, France
   http://www.w3.org/2012/10/TPAC/

We invite you to:

(1) review the week calendar and schedule for group meetings:
 http://www.w3.org/2012/10/TPAC/#GroupSchedule

(2) register (more below):
 http://www.w3.org/2012/10/TPAC/#Registration

(3) make your hotel reservation (more below):
 http://www.w3.org/2012/10/TPAC/#Accommodation

Chairs, please forward this information to participants in your groups.

If you have any questions, please contact Alexandra Lavirotte
a...@w3.org.
We look forward to seeing you in November in Lyon.

Ian Jacobs, Head of W3C Communications

--
On registration and registration fees
--

There is a daily registration fee to offset meeting costs. The fee goes
up for those who have not registered by 16 October.

As in the past, registration is a two-step process:

  1) completing a registration form:
 https://www.w3.org/2002/09/wbs/35125/TPAC2012/

  2) using a payment system:
 If you have a W3C account, please use
https://www.w3.org/2012/10/tpac_reg
 If you do not have a W3C account, please use
https://www.w3.org/2012/10/tpac_guest_reg

For more information about registration fees and the payment system, see
http://www.w3.org/2010/11/TPAC/#Registration

--
On accommodations: please reserve your room early
--

We have not reserved a block of rooms for this meeting, however we have
negotiated
discount rates.  Though there are several hotels convenient to the meeting
location,
we strongly recommend that you reserve your rooms early (before September)
to take
advantage of these discounts.

For more information about accommodations, see:
http://www.w3.org/2012/10/TPAC/#Registration

--
On plenary day
--

We plan to organize the plenary day camp-style, as we did for TPAC 2011.
We encourage you to propose breakout sessions in our wiki:
  http://www.w3.org/wiki/TPAC2012/SessionIdeas

We will develop the plan for the day in more detail over the next couple
of months.

--
On the AC meeting
--

We are still working on the structure and timing of the AC meeting and
will keep you
informed.

--
Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/
Tel:  +1 718 260 9447


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Charles McCathieNevile
On Wed, 20 Jun 2012 16:26:14 +0200, Lachlan Hunt  
lachlan.h...@lachy.id.au wrote:



On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least  
objection.

...
But spending another few months arguing about it hasn't proven that we
are any wiser, nor (importantly) any closer to agreement.


This is why it should be an editorial decision, not a group vote.  The  
least-objectionable alternative is rarely the best alternative, and  
trying to please everyone is a fool's errand.  Hopefully, this time, the  
group will let me, as editor, evaluate the options and supporting  
rationale and make a decision based on that.


Yeah, if that works, it's fine. Back then we were in a position where  
people cared enough to object, so we chose a different way of making most  
of the people unhappy that drew less objection...


cheers

Chaals (You think this is bad, people bikeshed how I should write  
*my*name* ...)


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Tags and origins (was: Re: Web Notifications)

2012-06-21 Thread Charles McCathieNevile
On Wed, 20 Jun 2012 15:07:27 +0200, Anne van Kesteren ann...@annevk.nl  
wrote:



On Wed, Jun 20, 2012 at 3:03 PM, Charles McCathieNevile
cha...@opera.com wrote:

In the default case yes. Can you use something to change that (a la
from-origin)?


I don't really see how. Do you have an example where it makes sense?


Probably by adding something like analgous to CORS as an attribute. Seems  
like a feature creep that should be directed to some future version.


cheers

Chaal

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Charles McCathieNevile
On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu  
kennyl...@csail.mit.edu wrote:



(12/06/20 22:26), Lachlan Hunt wrote:

On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least
objection.
...



The least-objectionable alternative is rarely the best alternative, and
trying to please everyone is a fool's errand.


While I agree that trying to please everyone is foolish, I am curious
about data that can be used to prove the the least-objectionable
alternative is rarely the best alternative statement.


I don't think there is any readily available. There are no clear criteria  
for judging best, although there are some clear criteria for judging bad  
- for example things that often get confused are definitely bad.



Hopefully, this time, the group will let me, as editor, evaluate the
options and supporting rationale and make a decision based on that.


I don't know what happened when the WG decided on the poor name
querySeletor


Pretty much what Lachy said. As chair, I was the one who decided there ws  
too much objection and called for some other process. I don't claim it was  
especially good or came up with a great name, but I don't think it was  
awful and I don't see a better alternative if the situation arises again.



Despite the fact the editor thinks function name X is better than
'querySelector', there were a few people (name goes here) who were
strongly opposed to X and a group vote happened and a decision was made
by (name goes here). Nobody ran a compatibility research.

And this time, I would like to ask whoever is going to make the decision
to take the opinion of the *public* into account. I am not saying it
should be the sole factor, but what I am looking for is an explanation  
like


Compatibility research shows that both name X and Y are fine. 70% of
the Web developers are in favor of name X and therefore X is chosen.


We don't have that data. We don't agree which web developers are the ones  
whose opinions matter - those who type a name once a month and want  
something self-explanatory, or those who type it once every 3 minutes, or  
those who write tools to avoid typing it at all, or ...


And then we don't have representative samples. We know, for example, that  
focus/blur made sense to english-speaking developers but confused millions  
of developers whose first language was something else.


So claiming we are basing a decision on the data will probably give  
results as arbitrary as the process we used, but with a veneer of  
intellectual dishonesty.



Seriously, I don't see why a rationale like this is better than the one
for querySelector as this is pretty much just s/WG/editor/ of that
since the WG vote didn't represent the public


Sure.


In other words, while I can agree that a single +1/-1 statement isn't
strong as a rationale (or even not a rationale) I beg you to take the
sum as a valid and strong rationale, at least in this case where X and Y
don't have much difference.

And I am still interested in what really happened last time.


(It is instructive to think for five minutes about the things that can go  
wrong, and how much effort we should spend on trying to get it right)


Essentially, a bunch of people tossed up all the reasons to object to a  
name that they could think of based on their experience of things that go  
wrong. Based on that, some proposals were rapidly rejected, and then we  
looked at the rest, kicking the tyres of each in turn until we figured out  
which one the most people didn't think was truly problematic. It can be  
dismissed as design by committee, but it can also be characterised as  
applying the wisdom of several smart people to avoid as many pitfalls as  
possible.


Frankly I think that suggesting one is smarter than any committee of smart  
people could be is a bold claim - if nobody is especially happy with the  
outcome, it can often be said that a number of very clever hardworking  
people recognise that it doesn't have any of several obvious problems they  
can name, and they think it is an acceptable outcome.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Charles McCathieNevile
On Wed, 20 Jun 2012 06:19:22 +0200, Elliott Sprehn espr...@gmail.com  
wrote:


On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr.  
jackalm...@gmail.comwrote:



...
This is not a good argument.  qSA is used often enough, and has a long
enough name, that the name is actually a pretty significant
misfeature.  This is a pretty core API, and both it and its precursors
(getElementByID, etc.) are very commonly renamed by libraries
precisely because you need a very short name for such a commonly used
function.



Why does it need a short name? If the name is too long to type then  
that's

an argument for better IDEs. Otherwise you end up with stuff like strncpy
to save typing. gzip eliminates the file size issue.

I'm in agreement with Marat that find() is not as clear as most DOM APIs
usually are. findBySelector() makes much more sense.


In other words we have the same arguments that we had five years ago, when  
we settled on querySelector as the one that provoked least objection.


getElementsB(y)Selector is consistent with the platform, subject to  
getting the s wrong, awfully long. find is too short for a general  
platform that has lots of ways of finding things and things you might be  
finding. querySelector is just sucky.


But spending another few months arguing about it hasn't proven that we are  
any wiser, nor (importantly) any closer to agreement.


If you want quick typing, alias it. If you want to know what it does  
because you only use it once a month (or in my case about once every six  
months), the name is barely clear enough.


There are no good answers here, since there are significant and competing  
needs.


cheers

Chaals


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Tags and origins (was: Re: Web Notifications)

2012-06-20 Thread Charles McCathieNevile
On Wed, 20 Jun 2012 14:30:08 +0200, Anne van Kesteren ann...@annevk.nl  
wrote:


On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay olli.pet...@helsinki.fi  
wrote:

Seems like tags are global. I think they should be per origin.


Yes I believe they should be.

http://dvcs.w3.org/hg/notifications/rev/563e9af218b9


In the default case yes. Can you use something to change that (a la  
from-origin)?


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25

2012-06-19 Thread Charles McCathieNevile
On Mon, 18 Jun 2012 15:57:02 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


Lachlan has made some changes to the Selectors API Level 1 spec (last  
published as a CR) and we consider the changes sufficient to require the  
spec be published as a Working Draft (see the [1] thread). As such, this  
is a Call for Consensus to publish a new LCWD of this spec using the  
following document as the basis  
http://dev.w3.org/2006/webapi/selectors-api/.


Please publish :)

cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Browser Payments API proposal

2012-06-19 Thread Charles McCathieNevile

On Sat, 16 Jun 2012 06:05:35 +0200, Alex MacCaw macc...@gmail.com wrote:


I've been working on a way of integrating one-click payments (and signup)
into the browser, and I wanted to put it in front of a few people to get
some feedback.

The API I was playing about with was pretty simple, and is documented  
here:


http://blog.alexmaccaw.com/preview/MjQxMDcwOTcwNjAYz14YvbdZWrrVg


(that link seems to go nowhere except the front of your blog)


It's basically an API to autocomplete data, already stored in the browser
and containing things like credit card number and name.

For example:

navigator.requestProfile(['firstName', 'email', 'cardNumber'], function(
profile){ console.log('Your name is:', profile.firstName); /* ... */ });


So it seems you are just using an API to support autocomplete, but with  
magic tokens as well as the browser heuristics that are normally used.


This seems to introduce a lot of UI security issues (asking for data for  
hidden form fields or fields that are out of the rendering view, ...).


cheers

Chaals


I've also created a Chrome
extensionhttps://github.com/maccman/request-profile demonstrating
the API. I think the key thing to getting adoption for something like  
this

is to keep it really simple.

Cheers,
Alex




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

2012-06-19 Thread Charles McCathieNevile

On Wed, 06 Jun 2012 14:39:35 +0200, Henri Sivonen hsivo...@iki.fi wrote:

On Sun, May 27, 2012 at 7:45 PM, Anant Narayanan an...@mozilla.com  
wrote:
Well, we haven't received this request from developers explicitly yet,  
but one can imagine a situation in which a developer makes an app only

for mobile phones (Instagram?) and doesn't want users to use it on
desktops.
Even though it'll technically work, it might look ugly due to scaling.


Shouldn't it be up to the user to refrain from using ugly apps instead
of the developer preventing them?


I agree with Henri.

I certainly don't support this use case where it doesn't have any real
requests to back it up.

There are cases where a user chooses for some important reason (e.g.
accessibility) to use the wrong app on their device, and not supporting
*that* use case would be a serious change from how the Web is generally
expected to work. In the tradition of the Web, authors are given
information to help them propose, but it is users who dispose - decide
what it is they will actually use.



--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan
noen
norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: www-dom vs public-webapps WAS: [DOM4] Mutation algorithm imposed order on document children

2012-06-16 Thread Charles McCathieNevile

On Fri, 15 Jun 2012 14:21:09 +0200, Glenn Maynard gl...@zewt.org wrote:


On Fri, Jun 15, 2012 at 12:05 AM, Charles McCathieNevile
cha...@opera.comwrote:

The reason for using it was in part that there were people there who  
were

working on dom and not on the (quite high traffic) webapps list which
discusses many other things.



LKML is a high-traffic list.  Maybe webapps was in the past, but it's
definitely not today. FWIW, this is usually a bad reason to split lists;


True.


it just causes fragmentation of discussions and lots of tiny, isolated
mailing lists.


Sure. But swapping around isn't that helpful either, since it dislocates  
discussion, threading, and people. I'd rather not swap unless there is  
overwhelming consensus (which I don't see so far).


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: www-dom vs public-webapps WAS: [DOM4] Mutation algorithm imposed order on document children

2012-06-14 Thread Charles McCathieNevile
On Thu, 14 Jun 2012 02:35:58 +0200, Bjoern Hoehrmann derhoe...@gmx.net  
wrote:



* Ojan Vafai wrote:
This confusion seems to come up a lot since DOM is part of  
public-webapps

but uses a separate mailing list. Maybe it's time to reconsider that
decision? It's the editors of the specs who have the largest say here  
IMO.


The reason for using it was in part that there were people there who were  
working on dom and not on the (quite high traffic) webapps list which  
discusses many other things.



The confusion is not going to go away by changing the proper mailing
list again


Right :S


the case is a good example, since the commenter references
the right document and that document says to post to www-dom, but he
sent it elsewhere. Others will assume www-dom is the right list for
various reasons


Like, because many DOM documents say so...


and so you will end up with discussions on both lists.


Yeah. By and large (there are exceptions, and editors have to track them,  
but that will always be so) the discussion has managed to sit on www-dom  
for a long time.



The main thing that let's use some other list does where participants
are not very well synchronized is annoying people with You posted to
the wrong list! mails. An option might be to merge them, but that may
be a first for the W3C, so it's unclear that the infrastructure would
support this.


It's probably possible. It is likely a bunch of manual work, and I doubt  
it is justified.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

2012-06-01 Thread Charles McCathieNevile
On Fri, 01 Jun 2012 13:15:24 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:



On 5/31/12 5:23 PM, ext Adam Barth wrote:

Is anyone besides Mozilla interested in implementing this specification?


I don't recall anyone else committing to an implementation (although it  
could be a bit early).


Without committing to anything, Opera is definitely interested in a  
javascript equivalent to packaging and configuration (and we note that  
Google already has one, albeit not standards-based).


The draft is OK for a FPWD (although we have comments we'll make between  
now and any final state).


cheers

Chaals

All - please speak up both on a) Adam's question; and b) the question in  
the Subject: header.


-Thanks, AB




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish WD of DOM 3 Events; deadline June 4

2012-05-29 Thread Charles McCathieNevile
On Mon, 28 May 2012 13:49:01 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


Travis would like to publish a new Working Draft of the DOM 3 Events  
spec and this is a Call for Consensus to do so, using  
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html  
as the basis.


Please do.

cheers

Note this is Not a Last Call WD and the comment tracking document for  
the last LCWD (published 31-May-2011) is  
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html.


Agreement to this proposal: a) indicates support for publishing a new  
WD; and b) does not necessarily indicate support of the contents of the  
WD.


If you have any comments or concerns about this proposal, please reply  
to this e-mail by June 4 at the latest.


Positive response to this CfC is preferred and encouraged and silence  
will be assumed to mean  agreement with the proposal.


-Thanks, ArtB




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Howto spec

2012-05-24 Thread Charles McCathieNevile
There is a list called spec-p...@w3.org which is about things to do with  
making specs. I.e. for editors, in particular. I forwarded some stuff from  
this thread there - there are other preprocessing systems around,  
including XML toolsets. I think this stuff used to be documented  
somewhere, and it might be worth trying to find that and make it look like  
it comes from the 21st century...


cheers

On Wed, 23 May 2012 14:45:05 +0200, Anne van Kesteren ann...@annevk.nl  
wrote:



Hi,

I have made some updates to the howto spec wiki page outlining how
you should go about writing a specification, with some emphasis on
specifications for APIs.

http://wiki.whatwg.org/wiki/Howto_spec

In particular the Patterns and Legacy DOM-style sections are
probably of interest. I would love to have feedback to see what else
people would like to see explained or how what is explained thus far
can be done better.

Thanks,





--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: URL spec parameter-related methods use parameter in a way inconsistent with the URI RFC

2012-05-24 Thread Charles McCathieNevile

+1 (top post FTW)

cheers

On Thu, 24 May 2012 11:29:24 +0200, Maciej Stachowiak m...@apple.com  
wrote:


The current draft URL spec has a number of Parameter-related methods  
(getParameterNames, getParameterValues, hasParameter, getParameter,  
setParameter, addParameter, removeParameter, clearParameters)[1].  
Apparently these methods refer to key-value pairs in the query part of  
the URL as parameters. However, the term parameter is used by the  
URI RFC[2] to refer to something else, a semicolon-delimited part of a  
path (which I think is nearly obsolete in modern use; I am not sure what  
it is for). I understand that for legacy reasons, much of the URL  
interface cannot be consistent with RFC-official terminology. But it  
seems like a bad idea to use the same term for a different piece of the  
URL, worse than using the same term for a different part. At least call  
it something like query parameters to disambiguate.


Another point of feedback on the parameter-related methods: they seem to  
form a dictionary-style interface, and it seems inelegant to have all  
these different methods giving a dictionary-style interface to something  
that is a piece of the URL, rather than something that is the URL.


One possible way to solve both these problems:

interface URL {
StringMultiMap queryParameters;
}

interface StringMultiMap {
 sequenceDOMString keys;
 sequenceDOMString getAll(DOMString name)
 boolean contains(DOMString name)
 DOMString? get(DOMString name);
 void set(DOMString name, DOMString value);
 void add(DOMString name, DOMString value);
 void remove(DOMString name);
 void clear();
}

The StringMultiMap interface could be reusable for other, similar  
key-value list contexts.


Or else use an appropriate dictionary type from ES if one is ever  
provided.


Regards,
Maciej


[1]  
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#dom-url-getparameternames

[2] http://www.ietf.org/rfc/rfc2396.txt



--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Shrinking existing libraries as a goal

2012-05-20 Thread Charles McCathieNevile

On Wed, 16 May 2012 06:32:51 +0200, Yehuda Katz wyc...@gmail.com wrote:

In the past year or so, I've participated in a number of threads that  
were implicitly about adding features to browsers that would shrink the

size of existing libraries.

Inevitably, those discussions end up litigating whether making it easier
for jQuery (or some other library) to do the task is a good idea in the
first place.


I think allowing libraries to shrink is a priori a good idea. The details  
become particuarly devilish when the impact of a proposed change is  
unevenly distributed, making things easier for some and harder for others.


While those discussions are extremely useful, I feel it would be useful  
for a group to focus on proposals that would shrink the size of existing

libraries with the implicit assumption that it was a good idea.


From a webapps perspective that would be very useful if it led to better  
feedback on (or ideally more tests for) specs in development.



If there is a strong reason that people feel that a focused effort to
identify ways to shrink existing popular libraries in new browsers would  
be a bad idea, I'd be very interested to hear it.


No, having a group who *do* this sounds fine. Looking forward to the  
results.


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: History Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-11 Thread Charles McCathieNevile
On Fri, 11 May 2012 19:57:37 +0200, Rafael Weinstein rafa...@google.com  
wrote:



It was wrong for me to editorialize about SVG and MathML -- and
punish was very poor word choice. I apologize to anyone who was
insulted. It certainly wasn't my intent.

I should have just said that I'm frustrated with the world we've
arrived in WRT HTML vs XML and left it at that.


Fair enough...

cheers


On Fri, May 11, 2012 at 3:07 AM, Charles McCathieNevile
cha...@opera.com wrote:
On Fri, 11 May 2012 10:55:27 +0200, Henri Sivonen hsivo...@iki.fi  
wrote:



On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein rafa...@google.com
wrote:


I'm very much of a like mike with Henri here, in that I'm frustrated
with the situation we're currently in WRT SVG  MathML  parsing
foreign content in HTML, etc... In particular, I'm tempted to feel
like SVG and MathML made this bed for themselves and they should now
have to sleep in it.



I think that characterization is unfair to MathML.  The math working
group tried hard to avoid local name collisions with HTML.  They
didn't want to play namespace games.  As I understand it, they were
forced into a different namespace by W3C strategy tax arising from the
NAMESPACE ALL THE THINGS! attitude.



Actually, I think even that is an unfair characterisation. At the time  
both
these technologies were developed (mid-late 90s) everyone assumed that  
XML

was the path of the future for everything, and that de-crentralised
extensibility was a critical requirement for a powerful web platform.

Given that scenario, it is unclear whether there is a better approach.  
The
current HTML approach of if it is important it will get into the  
mainline

spec effectively breaks the key extensibility assumption. Leading
implementors like Adobe, SodiPodi and Inkscape all introduced namespaced
content all over the SVG map - in many cases doing things that active  
SVG WG

members thought were excessive. Likewise Microsoft Office (at the time
probably as widespread as web browsers in general) introduced  
namespaced

content all over HTML (IE didn't support XHTML).

Seven years later, both of those assumptions came under attack from the
nascent WHAT-WG approach to updating HTML - but unlike the case for  
HTML,

where the market leader had clearly resisted implementing XHTML, SVG in
particular was backed by a number of XML-happy engines. It was several  
more

years before SVG and MathML were incorporated into HTML in a way that
clearly made sense.

Punishing people, or even ridiculing them, for using XML in the late  
90s,
seems counter-productive at best. Outside HTML even Microsoft - who  
were one
of the big creative forces behind XML - were pushing it everywhere, it  
was
considered de riguer for making the mobile web a possibility outside  
Opera
(which supported it anyway, but didn't require it), and it had, and  
still

has, huge deployment. It just failed on the web browser platform, for
reasons that are far easier to see in hindsight than they were at the  
time.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
   je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [webcomponents] Custom Elements Spec

2012-05-08 Thread Charles McCathieNevile

On Tue, 08 May 2012 07:00:41 +0200, Ian Hickson i...@hixie.ch wrote:


On Mon, 7 May 2012, Dimitri Glazkov wrote:


If you look at the two alternatives, one (the is attribute) asks the
authors to make the right choice. The other asks the component
developers to make the right choice. In the former case, the pool of
people who need to do the right thing is several orders of magnitude
larger than the latter. From there, it takes pure statistics to figure
out which alternative is likely to get better results.


I don't think those two sets of people are different in any meaningful
way.


Perhaps not in the field of people who write their own websites by hand,  
but I think in the general case they will clearly differ.



Sure, there will be some more advanced authors who write some
higher-profile components, but honestly I would expect the number of
people who write components to be roughly on par with the number of  
people writing CSS style sheets.


Which reinforces the argument. While I write my own CSS for content I  
produce for my own use, most of the content published by Opera is done  
with a stylesheet produced by one of a very few people. This is even more  
the case for large organisations, social networking and news sites,  
Wikipedia and educational material and so on.



After all, people are going to want to write
components whenever they want to make form controls fit their site,
whenever they have the slightest need for a customised widget or other,


In most corporate environments, it doesn't work like that. In many  
organisations that have some commitment to accessibility (even the ones  
who don't get i) there is a clear policy of having a few experts  
(increasingly they actually are) create a set of widgets - analagous to  
the jquery experience Tab mentioned.



etc. If we do this right, this will just be viewed as an extension to CSS
and HTML that everyone can use.


Sure. But vast swathes of HTML are not written by people from scratch, but  
relying on scripts, style snippets or style sheets, and templates which  
someone wrote for them - both to make life easier and as part of  
quality-controlled workflows.


There will certainly be people who don't care about accessibility and  
don't do anything at all (just as there are for simple things like alt  
attributes), and others who care but get it wrong, but aligning with the  
common model for those who care and are trying to get it right strikes me  
as a big benefit.


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [webcomponents] Custom Elements Spec

2012-05-08 Thread Charles McCathieNevile
On Tue, 08 May 2012 10:11:03 +0200, Anne van Kesteren ann...@annevk.nl  
wrote:


On Tue, May 8, 2012 at 9:48 AM, Charles McCathieNevile  
cha...@opera.com wrote:
There will certainly be people who don't care about accessibility and  
don't do anything at all (just as there are for simple things like alt

attributes), and others who care but get it wrong, but aligning with the
common model for those who care and are trying to get it right strikes  
me as a big benefit.


I don't think that's really the argument.


I do. It's about paving cowpaths or inventing new wheels.


The argument is about whether the long tail is going to be accessible
(even if only a little bit) or not at all.


Sure. (To be pedantic, I would suggest it is more specifically about the  
most efficient way to achieve the highest level of overall accessibility -  
and frankly I think even that is a simplistic explanation because even in  
the long tail some content matters more than other content).



That is, do we get

select is=restricted-color-pickeroption value=Redoption
value=Blue/select

styled as a restricted color picker or

restricted-color-picker options=red blue/

styled as a restricted color picker but with no fallback semantics  
whatsoever.


This is a false dichotomy. The common pattern for doing this today would  
be to use aria. There are various other methods, too - what makes


rcp opt=r,b
 select
  option value=red
  option value=blue
 /select
/rcp

unworkable?

Is there any reason to believe that ARIA will not work when it is used?  
Since I assume there isn't, Two competing mechanisms to do the same thing  
introduces a complexity for people trying to learn the right way, and the  
likelihood that they will mix syntax from each and get it wrong.


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish a FPWD of Web Components Explainer; deadline May 9

2012-05-06 Thread Charles McCathieNevile
On Thu, 03 May 2012 00:03:05 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:



On 5/2/12 1:27 PM, ext Olli Pettay wrote:

I don't understand this.
The explainer doesn't look like something which should become a  
recommendation.


And it may never become a Recommendation (f.ex. the group may later  
decide to publish it as a WG Note).


Right. That would be the normal destination for a document like this.


It just, well, explains how the various proposed APIs work.
So, why do we need explainer as FPWD?


Some people in the meeting (including me) thought this would be a useful  
informative (non-normative) wrapper for the Shadow DOM and other related  
specs in Dimitri's queue.


And me. Support publication.

cheers


-AB




-Olli

On 05/02/2012 11:22 PM, Arthur Barstow wrote:

As discussed during WebApps' May 1 f2f meeting [2], the Web Components
Explainer document is ready for a First Public Working Draft (FPWD)
publication and this a Call for Consensus (CfC) to do so:

 
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html


This CfC satisfies the group's requirement to record the group's
decision to request advancement.

By publishing this FPWD, the group sends a signal to the community to
begin reviewing the document. The FPWD reflects where the group is on
this spec at the time of publication; it does not necessarily mean  
there

is consensus on the spec's contents.

Positive response to this CfC is preferred and encouraged and silence
will be considered as agreement with the proposal. The deadline for
comments is May 9. Please send all comments to:

public-webapps@w3.org

-Art Barstow

[1] http://www.w3.org/2012/05/01-webapps-minutes.html#item03

 Original Message 
Subject: ACTION-659: Start a CfC to publish a FPWD of Web  
Components

Explainer (when an ED with TR template is available) (Web Applications
Working Group)
Date: Tue, 1 May 2012 19:16:17 +
From: ext Web Applications Working Group Issue Tracker
sysbot+trac...@w3.org
Reply-To: Web Applications Working Group public-webapps@w3.org
To: art.bars...@nokia.com



ACTION-659: Start a CfC to publish a FPWD of Web Components Explainer
(when an ED with TR template is available) (Web Applications Working  
Group)


http://www.w3.org/2008/webapps/track/actions/659

On: Arthur Barstow
Due: 2012-05-08

If you do not want to be notified on new action items for this group,
please update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings










--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: to stop work on XBL2; deadline May 8

2012-05-02 Thread Charles McCathieNevile

On Wed, 02 May 2012 19:00:48 +0200, Ian Hickson i...@hixie.ch wrote:


On Wed, 2 May 2012, Anne van Kesteren wrote:

On Tue, 01 May 2012 21:35:45 -0700, Ian Hickson i...@hixie.ch wrote:
 What happens if it doesn't pass?

I guess we'll reevaluate then.


How would this be different than what we've been doing for the past year?

As far as I can tell, the current situation is that we've stopped work on
XBL2 -- at least, nobody has worked on it for ages, and nobody is  
planning

on working on it any time soon. But if we actually _decide_ to stop
working on it, then we'll have to _start_ working on it again, in order  
to

publish a note saying we're not working on it, whereas if we decide _not_
to stop working on it, we'll continue doing nothing, having stopped
working on it.

This is like the epitome of committee-driven nonsense.


No. It is slightly more work than reading this thread.

If we get into a meta-argument about the value of time, we will change  
that equation to make publishing the note look more worthwhile.


The opportunity cost incurred by me editing the status section is minimal,  
and we thereby make it clearer that the final stage of this work is  
parked owing to lack of ongoing interest.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: to stop work on XBL2; deadline May 8

2012-05-02 Thread Charles McCathieNevile
On Wed, 02 May 2012 06:26:26 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


During WebApps' May 1 discussion about Web Components, a proposal was  
made ([1],[2]) to stop work on the XBL2 spec and this is a Call for  
Consensus to do do.


please do.

cheers

If you have any comments or concerns about this CfC, please send them to  
public-webapps@w3.org by May 8 at the latest. Positive response is  
preferred and encouraged and silence will be assumed to be agreement  
with the proposal.


If this CfC passes, the spec will be republished as a WG Note (as was  
done with other specs WebApps has stopped such as Web SQL Database).


-Thanks, AB

[1] http://www.w3.org/2012/05/01-webapps-minutes.html#item03
[2] http://www.w3.org/2012/05/01-webapps-minutes.html#item04

 Original Message 
Subject: 	ACTION-658: Start CfC to create a WG Note for XBL2 (and Chaals  
will do the work) (Web Applications Working Group)

Date:   Tue, 1 May 2012 18:22:25 +
From: 	ext Web Applications Working Group Issue Tracker  
sysbot+trac...@w3.org

Reply-To:   Web Applications Working Group public-webapps@w3.org
To: art.bars...@nokia.com



ACTION-658: Start CfC to create a WG Note for XBL2 (and Chaals will do  
the work) (Web Applications Working Group)


http://www.w3.org/2008/webapps/track/actions/658

On: Arthur Barstow
Due: 2012-05-08

If you do not want to be notified on new action items for this group,  
please update your settings at:

http://www.w3.org/2008/webapps/track/users/7672#settings





--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Reminder: May 1-2 f2f meeting: registration deadline is April 16

2012-04-16 Thread Charles McCathieNevile
On Mon, 16 Apr 2012 14:55:42 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


AFAIK, the deadline for registration will not be extended so please  
register today  
https://www.w3.org/2002/09/wbs/1/webappshtml-s2012--meeting/.


Agenda topic requests are welcome  
http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting#Potential_Topics.


(I added some items to the potential topics list.)


FWIW I don't think we should allocate an hour to Web Notifications.  
Unfortunately it was explicitly rejected as work for this WG, and it seems  
unfair to take up our time with it beyond perhaps a 2-minute update on  
status. Any technical discussion of it is inappropriate, and I can't  
imagine that what is left is a good use of an hour of our time.


Cheers


Begin forwarded message:

*Resent-From: *public-webapps@w3.org mailto:public-webapps@w3.org
*From: *ext Arthur Barstow art.bars...@nokia.com  
mailto:art.bars...@nokia.com

*Date: *March 15, 2012 8:13:54 AM EDT
*To: *public-webapps public-webapps@w3.org  
mailto:public-webapps@w3.org
*Subject: **Call for Agenda Topics: May 1-2 f2f meeting; Registration  
deadline April 16*

*archived-at: *http://www.w3.org/mid/4f61dd02.2000...@nokia.com

Hi All,

I created a meeting page for our May 1-2 f2f meeting at a Microsoft  
facility in the Silicon Valley  
http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting.


Participants must register for this meeting via  
https://www.w3.org/2002/09/wbs/1/webappshtml-s2012--meeting/ and the  
deadline for registration is April 16.


As we have done with our previous f2f meetings, I propose a mixture of  
pre-determined topics and topics agreed at the meeting. As such,  
please consider this as a call for agenda topics and if so desired,  
include a proposed day + time slot for the topic.


Since WebApps' revised charter  
http://www.w3.org/2012/03/webapps-proposed-charter.html should be  
formally approved by the meeting, I think we should consider all of  
our new specs as potential candidates for agenda topics.


-Thanks, ArtB





--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish WD of DOM4; deadine April 2

2012-03-26 Thread Charles McCathieNevile
On Mon, 26 Mar 2012 13:20:26 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:


Ms2ger would like to publish a new WD of DOM4 and this is a Call for  
Consensus to do so:


http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Agreement to this proposal: a) indicates support for publishing a new  
WD; and b) does not necessarily indicate support of the contents of the  
WD.


publish please :)

If you have any comments or concerns about this proposal, please send  
them to public-webapps by April 2 at the latest.


Positive response to this CfC is preferred and encouraged and silence  
will be assumed to mean  agreement with the proposal.


-Thanks, ArtB




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish Candidate Recommendation of Web IDL; deadline March 26

2012-03-19 Thread Charles McCathieNevile

On Mon, 19 Mar 2012 12:24:23 +0100, Marcos Caceres w...@marcosc.com wrote:

On Monday, 19 March 2012 at 10:58, Arthur Barstow wrote:


Cameron has addressed the comments from Web IDL LC#3 [1] and the bug
list only contains two enhancement requests [2]. As such, this is a call
for consensus to publish a Candidate Recommendation of Web IDL using the
following ED as the basis:

http://dev.w3.org/2006/webapi/WebIDL/

This CfC satisfies: a) the group's requirement to record the group's
decision to request advancement to CR; and b) General Requirements for
Advancement on the Recommendation Track as defined in the Process  
Document:


http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs

Positive response is preferred and encouraged and silence will be
considered as agreeing with the proposal. The deadline for comments is
March 26 and all comments should be sent to public-webapps at w3.org  
(http://w3.org).



Would be nice if there was a test suite before progressing to CR…


Indeed. It would be nice to have a pony. I support the proposal.

cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Regarding app notification and wake up

2012-03-12 Thread Charles McCathieNevile
On Fri, 09 Mar 2012 09:10:19 +0100, Stefan Hakansson LK  
stefan.lk.hakans...@ericsson.com wrote:


The webrtc WG has identified that the ability to notify, and possibly  
wake up, a web application of incoming events is important. This to  
enable support of use cases such as incoming calls. And in certain  
scenarios the resource use (e.g. power) is very important.


However, this kind of functionality is not in scope of the webrtc WG,  
but seems to belong to the Web Applications WG. So this is a message  
that the webrtc WG is interested in seeing technology that supports this  
being developed. We have also noted discussions in Web Apps around use  
cases for connection-less push:  
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html  
- especially the third one is very relevant for us.


Stefan and Harald (chairs) for the webrtc WG.


In the current charter proposal (which is under review at the moment) we  
have


[[[
Server-Sent Events
An API for opening an HTTP connection for receiving push notifications  
from a server in the form of DOM events. The API is designed such that it  
can be extended to work with other push notification schemes such as Push  
SMS.

]]] - http://www.w3.org/2012/03/webapps-proposed-charter.html

I'm not sure if that is enough, sounds like you would like something more.  
In which case the best thing is to get people who are interested in  
developing it to say so, through their review and in this working group.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [widgets] Request for a CFC about Widget URI and Updates

2012-03-06 Thread Charles McCathieNevile

On Tue, 28 Feb 2012 13:32:04 +0100, Marcos Caceres
marcosscace...@gmail.com wrote:

I think it might be time to have a CFC to propose moving Widget URI and  
Widget Updates to WG Notes. Although both specs have gotten implemented,  
I'm not interested in continuing the work unless I have industry backing.


As already noted, Opera is certainly interested in moving Widget Updates
to Recommendation - we implement and rely on it.

We could live with Widget URI being a note for now unless there is further  
interest in moving it forward.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish WD of File API: Writer + File API: Directories and System; deadline March 3

2012-02-26 Thread Charles McCathieNevile
On Sat, 25 Feb 2012 13:19:55 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:


This is a Call for Consensus to publish new WDs of the File API: Writer  
+ File API: Directories and System specs, using the following EDs as the  
basis of the publications:


http://dev.w3.org/2009/dap/file-system/file-writer.html
http://dev.w3.org/2009/dap/file-system/file-dir-sys.html


Publish away...

cheers

Agreement to this proposal: a) indicates support for publishing a new  
WD; and b) does not necessarily indicate support of the contents of the  
WD.


If you have any comments or concerns about this CfC, please send them to  
public-webapps@w3.org by March 3 at the latest. Positive response is  
preferred and encouraged and silence will be assumed to be agreement  
with the proposal.


-Thanks, AB




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: April face-to-face meetings for HTML and WebApps

2012-02-12 Thread Charles McCathieNevile

On Wed, 08 Feb 2012 12:11:52 +0100, timeless timel...@gmail.com wrote:


It's Passover [1]. Passover begins in the evening of Friday, April 6,
2012, and ends in the evening of Saturday, April 14, 2012.

...

Thank you for asking in advance so that we can *not* do it at this time.


So the upshot is that Josh will be attending for the days he is able to,  
and will not be available on Friday. This may apply to others (which is  
why we asked the question), or there may be other reasons why people  
cannot attend.


can you attend is not the question we asked, which is is there a very  
good reason not to hold this meeting. Bearing in mind that in the case of  
each group the meeting is not able to take binding decisions between the  
people who are there, and that we recognise the difficulty some people  
will have in getting to it.


Cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: April face-to-face meetings for HTML and WebApps

2012-02-10 Thread Charles McCathieNevile
On Thu, 09 Feb 2012 19:11:05 +0100, Andres Riofrio ariof...@cs.ucsb.edu  
wrote:



Or the other way around. In any case, I was only making a point against
systematic avoidance of major religious holidays, in favor of a more
case-by-case basis.


As ne of the chairs who was involved in scheduling... I try to avoid major  
holidays that I know will cause problems for many people. And events which  
will do the same - a lot of the group might go to Google I/O or SxSW, or  
somehow think the world knows or cares when thanksgiving is and why we  
should avoid holding meetings then.


In the end, there will always be someone who can't make a meeting - this  
is one of their inherent drawbacks. Thinking about how to make sure it  
isn't always the *same* someone is important. (And Josh has a fair point,  
there *are* jewish people involved here who take their religion seriously  
enough that it causes them a problem). I made an assumption about when  
passover is that was incorrect, instead of checking, which contributed to  
the problem.


I don't actually believe that your religious holiday/kids' special  
event/wife's anniversary/much-anticipated holiday is less important than  
the future of the web. But nor do I know of any individual alive whose  
presence is critical to the success of a webapps / HTML meeting. There are  
many people who will, should they be able to, contribute greatly to that  
success, and if we can't get enough people to the meeting we won't run it.


The current W3C process allows people to object to other people having  
formal meetings (which strikes me as very asymmetrical - you can't object  
to a self-selected bunch of people meeting without inviting anyone else)  
without sufficient notice. It also (quite reasonably) allows people to  
point out that we have what amounts to a systemic bias in the way we  
organise them (more than one - we have a very conscious bias towards  
helping out Bay Area residents at the cost of everyone else :( ), which is  
what happened here.


If you're likely to attend, please say so. If you're unlikely to attend  
wherever and whenever the meeting is, you don't need to say anything. If  
you would attend under different circumstances, feel free to say what they  
are...


For the record: I prefer to hold meetings in Europe (in the large,  
including Russia, North Africa, ...) as it is easier to have Opera people  
present at them. But we will make the effort to contribute when- and  
wherever the meeting may be.


cheers


On Thu, Feb 9, 2012 at 6:38 AM, Marcos Caceres w...@marcosc.com wrote:





On Thursday, February 9, 2012 at 4:18 AM, Andres Riofrio wrote:

 Regarding the checklist: perhaps these things are only relevant if  
there

are Christian/Jewish/Muslim people in the group. And if there are people
that prefer not to meet on Saturday. It seems to me more reasonable to
expect people with prior commitments, that plan to attend, to speak up,  
and

expect the rest to understand and try to come to a consensus. That's why
people ask for objections anyway.

Right, sometimes one might have to make sacrifices and forgo a Saturday  
or
observing some religious thingy out of respect for the sectarian nature  
of
the W3C membership (and for the advancement of our beloved and sacred  
Web).


Kind regards,
Marcos







--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC by 02-14: Add IME API to the charter

2012-02-09 Thread Charles McCathieNevile

On Wed, 08 Feb 2012 22:38:51 +0100, Robin Berjon ro...@berjon.com wrote:


On Feb 8, 2012, at 13:29 , Charles McCathieNevile wrote:
thanks to Mike and the Google guys, we have  
http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html  
which explains what an IME API would do and why it would be useful. I  
believe we have editors but it doesn't name a test facilitator (don't  
blame me, Art chose that as the name ;) ) and we need one. I am  
assuming that will be forthcoming, so this is a formal call for  
Consensus to add this item to the charter.


Silence will be considered assent, positive response is preferred, and  
the deadline is the end of Tuesday 14th February.


A strong and hearty +1.


Opera is in favour too.

cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



CfC by 02-14: Add IME API to the charter

2012-02-08 Thread Charles McCathieNevile

Hi,

thanks to Mike and the Google guys, we have  
http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html  
which explains what an IME API would do and why it would be useful. I  
believe we have editors but it doesn't name a test facilitator (don't  
blame me, Art chose that as the name ;) ) and we need one. I am assuming  
that will be forthcoming, so this is a formal call for Consensus to add  
this item to the charter.


Silence will be considered assent, positive response is preferred, and the  
deadline is the end of Tuesday 14th February.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Charter addition proposal: screen orientation lock

2012-02-06 Thread Charles McCathieNevile

On Mon, 30 Jan 2012 12:22:30 +0100, Robin Berjon ro...@berjon.com wrote:
...
I will let implementers speak for themselves, but my understanding is  
that there is interest in this feature. It is certainly a regular  
request from developers.


In previous discussions we haven't hashed out who would stand up as  
editor and test facilitator, but I'm confident that we can find people.  
If no one else steps up, I'll take the testing hat.


With Robin as test coordinator and Mounir as editor, we seem to have  
consensus on taking this on as a work item. So I'll add it to the charter  
draft...


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Charter clarification: common manifest

2012-02-06 Thread Charles McCathieNevile

On Mon, 30 Jan 2012 17:51:14 +0100, Robin Berjon ro...@berjon.com wrote:


On Jan 30, 2012, at 13:38 , Marcos Caceres wrote:

On Monday, 30 January 2012 at 21:26, Robin Berjon wrote:
It's not something that has happened to date, but I'm hearing  
indications that there could be interest in quickly aligning on a  
manifest for web apps (that would I presume differ from the one used  
in Widgets).


Interesting… pointer to these indicators would be nice (or would be  
nice to hear from WG members).


Tobie kicked up some dust here:

http://blog.tobie.me/post/14262541286/app-manifests-an-anthology

I can't seem to track down pointers right when I need them, but this  
spurred a fair amount of commentary, including from some people who work  
for implementers agreeing that the current situation is stupid and needs  
to be fixed.


It would be a shame to close the door right as it looks like it might  
happen.


Agree. However, an alternative serialisation of the Widget's metadata  
can be specified in the Native Web Apps CG and then a WG home can be  
found.


Sure, I'm happy for the work on this to take place in the NWA CG since  
that seems like a fit home for it, but it needs a place to be properly  
standardised. My hope is that this place can be the WebApps WG. Given  
that the discussion would take place elsewhere, and that the result is  
pretty much in charter, I would hope that this should be agreeable to  
all.


I'll write it that way into the charter draft. I also hope that it is seen  
that way by the WG.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: to add Speech API to Charter; deadline January 19

2012-02-01 Thread Charles McCathieNevile
On Mon, 30 Jan 2012 08:43:26 +0100, Charles McCathieNevile  
cha...@opera.com wrote:



Further explanation from Apple...

--- Forwarded message ---

...
2. Speech is an area with IPR -- it's been an active research area for  
decades; we may have some. Without doing a lot more work I don't know  
the extent to which the proposed work would encounter IPR, but I think  
it would be prudent to think about that.  It may be best to have the  
work done in a less general-purpose WG (though, as I say above, I  
don't think WebApps should really be seen as general-purpose), and  
actively seek to set a scope and a membership that minimize issues  
down the road.


This feedback has been essentially replicated but more forcefully in  
Team-confidential responses. While it is theoretically possible to put the  
proposal in the charter anyway, in practice it will just get shot down in  
AC review by Team-confidential responses, so it would be a waste of time.


Given that, there is not consensus to add the item.

Chairs

Chaals (and Art)

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CG for Speech JavaScript API

2012-02-01 Thread Charles McCathieNevile

Hi Satish,

On Wed, 01 Feb 2012 10:50:25 +0100, Satish S sat...@google.com wrote:


Re the mail list, if we turn this around and look at it from the
perspective of someone that is mostly interested in the CG and not  
WebApps, they would then receive close to an additional 2K emails

per quarter.



 I really don't think you want that so I recommend against using
public-webapps.


Speech API discussions could use a [speech api] prefix in the email
subject so that participants can filter emails based on that. I see this
style being used by File API and possibly others in the webapps mailing
list.


True, but those are deliverables of the Web Apps group. Which already has  
a number of deliverables, and a lot of mail traffic for work it has agreed  
to take on. We have already moved various kinds of work to other lists to  
reduce that traffic.



As Glen mentioned keeping discussions in the webapps mailing list
will provide visibility to a wider audience, with a balanced web-centric
view for new JavaScript APIs.


The wider audience are welcome to subscribe to a list for the group  
working on the API - but they may not want to. The fact that you add  
messages to people's inbox doesn't mean that they will read them, as we  
all know already. I do not think it is reasonable to use this list for the  
work given that it has not been accepted as a work item by the group.


Cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



CfC Re: Charter addition proposal: screen orientation lock

2012-01-30 Thread Charles McCathieNevile
OK, since I was planning to have the charter up today, let's have a quick  
call for consensus on this. Please reply by end of business Wednesday if  
you support or object to this - silence will be taken as not explicitly  
supporting it, and without support it isn't going to get into the draft  
charter. If it does go there, there will still be opportunities to object  
but it will be harder to squeeze in.


cheers

Chaals

On Mon, 30 Jan 2012 12:22:30 +0100, Robin Berjon ro...@berjon.com wrote:


Hi all!

Sorry for bringing this to the group this late, but it's a topic that's  
been discussed in other places and that I believe is both useful and  
mature enough to be ready for standardisation.


Some applications are designed in such a way that they only make sense  
in one device orientation. The archetypical example would be a game that  
only works in landscape mode, but there are other examples. Right now  
native apps can support this rather easily, but web apps have been stuck  
with silly hacks such as detecting that the orientation is wrong and  
asking the user to rotate. This further leads to trouble when the device  
itself is used as a controller (e.g. in racing games) as this can  
sometimes trigger an undesired orientation change mid-game — hardly a  
user-friendly experience.


Note that this is not about system-level orientation lock (which would  
be fodder for another group) but application-level orientation.


Options to address this have been discussed (amongst other places) here:


http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/f38bb05e66c01a77#

There is discussion as to whether this ought to be only an API or if it  
should use a meta element (which would also give it an API since it  
could be changed dynamically), with an overall leaning towards the  
latter. I am rather confident that we should be able to agree on the  
best approach relatively quickly.


I will let implementers speak for themselves, but my understanding is  
that there is interest in this feature. It is certainly a regular  
request from developers.


In previous discussions we haven't hashed out who would stand up as  
editor and test facilitator, but I'm confident that we can find people.  
If no one else steps up, I'll take the testing hat.


WDYT?




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Fwd: Re: CfC: to add Speech API to Charter; deadline January 19

2012-01-29 Thread Charles McCathieNevile

Further explanation from Apple...

--- Forwarded message ---
From: David Singer sin...@apple.com
To: Arthur Barstow art.bars...@nokia.com
Cc: Maciej Stachowiak m...@apple.com, Doug Schepers  
schep...@w3.org, Philippe Le Hegaret p...@w3.org, Charles  
McCathieNevile cha...@opera.com, Edward O'Connor eocon...@apple.com

Subject: Re: CfC: to add Speech API to Charter; deadline January 19
Date: Sat, 28 Jan 2012 10:19:54 +0100

That's fine.  Sorry, I am in Europe (between the said tracking meeting,
and the 3gpp meeting, so I only just saw the message.  To save me digging
around and finding the lists, and/or finding that they don't accept emails
 from non-members, could someone volunteer to forward to the list?


On Jan 27, 2012, at 13:39 , Arthur Barstow wrote:

[ + Charles (other WG Chair) and PLH (I think Doug is traveling this  
week) ]


This is good feedback that should be shared with the WG so I would  
appreciate it if you or someone else at Apple would please send your  
comments to at least the group's member list although the public list is  
my preference. Can this please be done today?


-Art

On 1/27/12 3:04 AM, ext David Singer wrote:

Hi Art

following up to Ted's message, I think I have three concerns at this  
time.


1.  I think there is some temptation to have WebApps take on any new  
API work, because of course web applications could indeed use almost  
anything.  But that risks losing the focus of the WebApps group as the  
place where work that is uniquely needed, or most needed to enable  
improved client-side application development on the Web [webapps  
charter].  Speech is here a user-interface, input/output mechanism, not  
really specific to that domain.


2.  Historically, the user interface to the web was a virtual  
keyboard/mouse, and quite wide variation in physical instantiation has  
been possible (and used). There is a lot of temptation to make specific  
provision of other input/output methods, but doing so brings two large  
issues when the content then ties itself to those particular  
input/output methods, that I don't think the W3C has really got to  
grips with:  what happens to content portability (is the method  
available or usable on all platforms?), and what happens to  
accessibility (are there alternative modalities available for those for  
whom this method is inaccessible?).  I raised this concern about other  
UI method-specific APIs under consideration, and I think it's still  
largely unexplored.


2. Speech is an area with IPR -- it's been an active research area for  
decades; we may have some. Without doing a lot more work I don't know  
the extent to which the proposed work would encounter IPR, but I think  
it would be prudent to think about that.  It may be best to have the  
work done in a less general-purpose WG (though, as I say above, I don't  
think WebApps should really be seen as general-purpose), and actively  
seek to set a scope and a membership that minimize issues down the road.


I'm sorry this has taken a while; for me, the do-not-track meeting  
proved rather time-consuming.


Best wishes, I hope this helps


On Jan 19, 2012, at 20:02 , Arthur Barstow wrote:


David, Maciej - what is Apple's position on this proposal?

I would greatly appreciate it, if you would please reply on  
public-webapps by January 19 or if you need a couple of days  
extension, please let me know.


-Thanks, Art

 Original Message 
Subject:CfC: to add Speech API to Charter; deadline January 19
Resent-Date:Thu, 12 Jan 2012 12:36:21 +
Resent-From:public-webapps@w3.org
Date:   Thu, 12 Jan 2012 07:31:06 -0500
From:   ext Arthur Barstowart.bars...@nokia.com
To: public-webappspublic-webapps@w3.org
CC: public-xg-htmlspe...@w3.org



Glen Shires and some others at Google proposed [1] that WebApps add
Speech API to WebApps' charter and they put forward the Speech
Javascript API Specification [2] as as a starting point. Members of
Mozilla and Nuance have voiced various levels of support for this
proposal. As such, this is a Call for Consensus to add Speech API to
WebApps' charter.

Positive response to this CfC is preferred and encouraged and silence
will be considered as agreeing with the proposal. The deadline for
comments is January 19 and all comments should be sent to  
public-webapps

at w3.org.

-AB

[1]  
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html

[2]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html



David Singer
Multimedia and Software Standards, Apple Inc.



David Singer
Multimedia and Software Standards, Apple Inc.


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



The Web, and security models Re: Reporting of CORS error in the XHR API callbacks

2012-01-27 Thread Charles McCathieNevile

On Fri, 20 Jan 2012 20:32:33 +0100, Ian Hickson i...@hixie.ch wrote:


On Fri, 20 Jan 2012, Tim Berners-Lee wrote:



There of course places where XHR is used and there is no
cross-sitescripting security needed

1)  in a browser extension
2)  in node.js code trusted apps


These aren't the Web, so they're probably out of scope of the CORS and  
XHR specs, but Anne can comment if he disagrees. :-)


I'm not Anne, but I disagree with both of you. These things are related to
the Web and have the potential to become part of it, and the idea that
they don't need to worry about security in the way the web does seems to
me ridiculous, for the reasons Ian outlines below...


3)  in web apps when web apps can, in I hope the near future, be
installed, and flagged as trusted code


Personally I think the idea of installing a Web app is anathema.


The range of options for web apps which go from using local storage
through appcache to full installability means that this horse seems to
have bolted. Personally I think that's a good thing - being able to work
with the Web even when there isn't a permanent and perfect connection is
still important (as I was reminded again this month when trying to use
normal infrastructure in Melbourne Australia...).

There are plenty of use cases for some kind of installability, just as
there is lots of use for bits of the Web behind a firewall (every time
someone tries to share something with me developed using Google's services
I am required to have a Google log-in - the fact that the firewall
includes zillions of people doesn't make it public, just as it doesn't
mean that it isn't on the Web).


The best thing about Web apps is that the browser can be trusted such
that even the most hostile app can't do anything bad.


This is not true. One of the good things about the Web is that it has a
robust security model (compared to alternatives) which is designed to
protect users from hostile apps to a greater extent than other platforms.

IMHO (and I think this is simply a subjective assertion of values rather
than a question that can be objectively determined) the best thing about
web apps is that they are built with a very widespread, well understood
and relatively simple technology stack that is successfully implemented by
many providers, such that no provider cannot be replaced.


If we start allowing users to install apps, we'll just change the
security model of the Web from you can't do anything bad without an
implicit permission gesture from the user to all you have to do is
convince the user to install you and then you can own them.


Only if we make the assumption Tim made above - which I think is based in
turn on the assumption that installable web apps come from one source.
Having to go through some particular app store for them leads to such an
assumption. It also breaks important use cases.

It should be straightforward for ACME co to produce a web app that is
useful for its employees, and distribute it internally from some trusted
point. They should also be able to distribute that to others, either
directly (based on other people trusting ACME) or through a third party
which people trust (widgets.opera.com or google's app store or appsRus or
whoever...)

This requires a trust and security model where the decisions can be made
by a user, or further back in the distribution chain.


Basically, moving us from the Web's security model today, a fantastic
and successful security model that has withstood a decade or more of
sustained attack, to the Windows security model.


I think you're overstating the success of the Web security model, and
missing the fact that it has caused us to have a web which until recently
is far less capable than installed applications. But yes, as I said above
in agreement with you, the model is designed to match reality better than
most of the alternatives, and we should think carefully before abandoning
it any time we are tempted to do so...

cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: to add Speech API to Charter; deadline January 24

2012-01-26 Thread Charles McCathieNevile

On Wed, 25 Jan 2012 00:47:45 +0100, Glen Shires gshi...@google.com wrote:


Art, Charles,
We are very pleased to see the positive responses to the CfC.


Me too. FWIW Opera is happy to have this work done. We think it would  
ideally be a joint deliverable (despite the fact that we don't like those  
in general) between WebApps (where there is a lot of expertise in design  
of web APIs, plus a lot of the relevant players) and the Voice group where  
there is a lot of specific expertise, unless we can get all the relevant  
people to join one or other of those groups.


In particular, we believe this meets all the criteria that Art suggested  
in [1].


There is the outstanding question of Apple's position...


What is the next step for adding this to the charter?


Wait for me to propose a new draft charter. As it happens, I am waiting on  
Google people (Ian Fette is the named target because he brought the  
initial proposal) to explain their IME proposal better, but I intend to  
draft a charter in the next week with whatever we have agreed as a group  
to add, and start it along the approval process (it has to be agreed by  
the W3C membership as a whole).


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Obsolescence notices on old specifications, again

2012-01-24 Thread Charles McCathieNevile

On Tue, 24 Jan 2012 11:02:55 +0100, Ms2ger ms2...@gmail.com wrote:


On 01/24/2012 01:58 AM, Bjoern Hoehrmann wrote:

* Ms2ger wrote:
The recent message to www-dom about DOM2HTML [1] made me realize that  
we still haven't added warnings to obsolete DOM specifications to  
hopefully avoid that people use them as a reference.


If you want to say more than that the specifications are no longer being
maintained and which newer specifications might contain more recent de-
finitions for the features covered you will have to create a process for
that first (it would require Advisory Committee review for instance, as
otherwise you are likely to create unnecessary drama).


I should have been clearer; this is indeed all I intend to say.


OK, this looks like the sort of message that Opera would support. As Art  
said, I think we need individual proposals per spec.


And I am not sure that rescinding specs we don't like much is necessarily  
a good idea.


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: to add Speech API to Charter; deadline January 24

2012-01-23 Thread Charles McCathieNevile

On Fri, 20 Jan 2012 18:37:35 +0100, Glen Shires gshi...@google.com wrote:


Some of the reasons we believe that the JavaScript Speech API is best
suited for WebApps, instead of it's own working group, include:

1. Speech is likely to become a core API, like other WebApps deliverables
such as File API. It is important that it be compatible and consistent
with, and interact well with other JavaScript API components.


Agreed.


2. WebApps provides a balanced web-centric view for new JavaScript APIs.
 The XG group consisted of a large number of speech experts, but only a  
few with broad web API expertise. We believe the formation of a new WG

would have a similar imbalance,


I'm not sure this is necessarily the case, and the reverse possibility,  
that the Web Apps group would not have enough speech experts should also  
be considered a potential risk.



whereas the WebApps WG can provide valuable, balanced guidance and
feedback.


(FWIW I don't have a strong opinion on whether this is likely to be a real  
problem as opposed to a risk, and I think this conversation helps us work  
that out).



3. The scope of this effort is well-defined and bounded. All that have
responded to this CfC have agreed that JavaScript API portions of the XG
Final Report are relevant to WebApps, and that the wire protocol portions
of the XG Final Report are not relevant to WebApps (and should be pursued
in another group, such as IETF).


I think that's a fair summary


 The differing opinions seem only about the specific starting point of
this effort, whether to base it on the full JavaScript API in the XG's
Final Report [1] or a subset of that JavaScript API, which supports the
majority of use cases, as proposed by Google [2].


Or a subset that supports a majority of use cases as currently proposed by
Debbie, developed by whittling down from [1] based on what implementors are
prepared to do.


For this first recommendation-track document, we believe a subset will
accelerate implementation, interoperability testing, standardization and
ultimately developer adoption. However, in the spirit of consensus, we  
are willing to broaden this subset to include additional API features in

the XG Final Report.


That makes sense. We do think that it is important to be working on stuff  
that gets implemented, as a good guide to what ends up in a recommendation  
and what's in the list for an expanded version. One point of the WG  
process is that we can have more than one input document, and we develop  
consensus as we go on what gets deployed and is therefore ripe for further  
formal standardisation, and what is still waiting...


cheers

Chaals


[1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/
[2]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html

Bjorn Bringert
Satish Sampath
Glen Shires


On Fri, Jan 20, 2012 at 3:58 AM, Arthur Barstow  
art.bars...@nokia.comwrote:



The deadline for comments is extended to January *24*.


On 1/20/12 6:55 AM, ext Arthur Barstow wrote:


The deadline for comments is extended to January.

Andrian, Maciej - I would appreciate it you would please provide some
feedback on this CfC.

On 1/12/12 7:31 AM, ext Arthur Barstow wrote:


Glen Shires and some others at Google proposed [1] that WebApps add
Speech API to WebApps' charter and they put forward the Speech  
Javascript
API Specification [2] as as a starting point. Members of Mozilla and  
Nuance
have voiced various levels of support for this proposal. As such,  
this is a

Call for Consensus to add Speech API to WebApps' charter.

Positive response to this CfC is preferred and encouraged and silence
will be considered as agreeing with the proposal. The deadline for  
comments

is January 19 and all comments should be sent to public-webapps at
w3.org.

-AB

[1] http://lists.w3.org/Archives/**Public/public-webapps/**
2011OctDec/1696.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html
[2] http://lists.w3.org/Archives/**Public/public-webapps/**
2011OctDec/att-1696/speechapi.**htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html









--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Testing Expectations (was: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization)

2012-01-23 Thread Charles McCathieNevile

On Thu, 12 Jan 2012 17:06:34 +0100, Doug Schepers schep...@w3.org wrote:

As such, the creation of tests should not be left to CR... there should  
be a plan in place (e.g. a person, and a loose policy, like as we  
implement, we'll make tests and contribute them to the WG), and a  
person responsible for collecting and maintaining the tests (i.e. making  
sure that the tests are adapted to meet the changing spec).


Indeed, we agreed recently that this would be something we require in any  
work the group takes on...


So rather than warm fuzzies, we're really after a warm body to take  
responsibility for driving it.


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization

2012-01-11 Thread Charles McCathieNevile

On Wed, 11 Jan 2012 22:36:28 +1100, Michael[tm] Smith m...@w3.org wrote:


Satish S sat...@google.com, 2012-01-11 10:04 +:

The Community Groups [1] page says they are for anyone to socialize  
their

ideas for the Web at the W3C for possible future standardization.


I don't think that page adequately describes the potential value of the
Community Group option. A CG can be used for much more than just
socializing ideas for some hope of standardization someday.

The HTML Speech Incubator Group has done a considerable amount of work  
and the final report [2] is quite detailed with requirements, use cases

and AP proposals. Since we are interested in transitioning to the
standards track now, working with the relevant WGs seems more
appropriate than forming a new Community Group.


I can understand you seeing it that way, but I hope you can also  
understand me saying that I'm not at all sure it's more appropriate for

this work.


And I hope you all understand me saying that I think it is indeed more  
appropriate to move it to a formal working group, for reasons explained  
below...


I think everybody could agree that the point is not just to produce a  
spec that is nominally on the W3C standards track. Having something on

the W3C standards track doesn't necessarily do anything magical to ensure
that anybody actually implements it.


Indeed. But the same goes for a community group. Implementation commitment  
doesn't come from people writing a spec.



I think we all want is to for Web-platform technologies to actually get
implemented across multiple browsers, interoperably -- preferably sooner
rather than later. Starting from the WG option is not absolutely always  
the best way to cause that to happen. It is almost certainly not the best

way to ensure it will get done more quickly.


Actually, I don't think that what kind of group the work happens in is  
relevant one way or another to how fast it gets implemented - and not very  
relevant to the rate of developing the spec.


You can start up a CG and have the work formally going on within that CG  
in a matter of days, literally. In contrast, getting it going formally as

a deliverable within a WG requires a matter of months.


In the general case this is true. But *starting* work is easy - as Mike  
said above the goal is to get stuff interoperably implemented, in other  
words, *finished*. And the startup time only has an impact on the finish  
time in very trivial cases.


Among the things that are valuable about formal deliverables in WGs is  
that they get you RF commitments from participants in the WG. But one

thing that I think not everybody understands about CGs is that they also
get you RF commitments from participants in the CG; everybody in the CG
has to agree to the terms of the W3C Community Contributor License
Agreement -

  http://www.w3.org/community/about/agreements/cla/

Excerpt: I agree to license my Essential Claims under the W3C CLA RF
Licensing Requirements. This requirement includes Essential Claims that  
I own


There are important differences in what WGs and CGs offer, and each has  
both advantages and disadvantages in terms of the overall level of  
protection offered. A fair criticism of the process applied to HTML5 is  
that the editor claims to accept input from the working group, plus the  
WHAT-WG (whose participants have made no commitment on patents at all)  
plus anything he reads in email, blogs, the side of milk cartons, etc.  
There is a theoretical risk that he will read something placed in front of  
him by someone who has avoided joining the WG (and therefore makes no  
patent commitment) and introduce it into the spec not knowing it carries a  
patent liability. I think that in practice this is unlikely to be a real  
problem for HTML - but that doesn't mean it is unlikely to be a real  
problem for any Web technology. In particular, I think that the work being  
proposed here would benefit from being in a real working group - either  
the Voice WG or the Web Apps WG seem like sensible candidate groups, a  
priori. Web Apps has the benefit that we are in the middle of the  
rechartering process, so adding deliverables is as painless now as it can  
ever be (and the truth is that this doesn't mean trivial - broad patent  
licensing doesn't always come without some effort, which is why it is  
considered valuable).



Anyway, despite what it may seem like from what I've said above, I'm not
trying to do a hard sell here. It's up to you all what you choose to do.
But I would like to help make sure you're making a fully informed  
decision based on what the actual benefits and costs of the different

options are.


Indeed.

cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?

2011-12-20 Thread Charles McCathieNevile

TL;DR: JC and Leonard are right.

Pointing to a moving target makes any statement about conformance pretty
much unusable in the real world. Which is significantly worse than having
a statement of conformance to something known to contain errors and bugs.

Browsers don't implement living standards. They implement something  
undefined for an open environment where people are continually innovating,  
and they make considerable and expensive efforts to tell the community  
what it is they implement.


Browsers like Opera who have commercial enterprise customers work with  
those customers to establish sensible conformance requirements that take  
into account the evolutionary nature of the web (rather than arbitrary  
stacks of requirements that happened to be easy to test), but neither side  
wants a Statement of Work that doesn't actually clarify what is expected  
to be delivered under a legally binding contract.


A lack of stability and precision about which version of a specification  
is meant also makes it harder to get a decent royalty-free license.


Details below...

On Mon, 19 Dec 2011 14:03:58 +0100, Marcos Caceres w...@marcosc.com wrote:


I'm sorry, but Leonard is not correct: this is the W3C, not ISO.


Yes, so far so good...

ISO is a real standards body (i.e., can be legally binding for  
governments). W3C is a business/community consortium (i.e., not a  
legal standards body and specs are not legally binding): W3C makes  
recommendations, which are not (and should not be) legally binding.


So what? In practice, people make contracts (legally binding documents)
that include such terms as conformance to


In ISO specs, undated references are forbidden. There is a team of
people (called ITTF) whose job includes checking these things and
bugging spec editors to fix them.


Yes, but this is not ISO. And just because they operate in that manner,  
it also doesn't mean that ISO is right.


True, but it also doesn't mean they are wrong.


There is such a thing as certification. It is impossible to do if the
spec is not fixed, including references.


What if there is a bug in the spec? or a test is wrong and it's fixed  
after someone has claimed compliance?


This happens all the time, and has done for decades.

Wat happens is tha by dating explicit versions, you can deal with a known
state. Something that conforms to the earlier, buggy version, or to the
later better (but almost certainly not bug-free, as you seem to freely
acknowledge) version, have a set of known properties. This is helpful when
you are trying to include them as *parts* of an ecosystem.


What you are advocating is entirely counterproductive given the source
of the discussion (= a PAG): if the spec has undated references, you
cannot make sure it is royaltee-free.


Yes you can: the /latest/ always points to the latest REC. REC is  
royalty free.


No, that is not guaranteed. Under the current process any substantive
change between last call and Recommendation means, as far as I can tell
  from carefully reading what gets licensed, that the change cannot be
assumed to be covered by the patent license unless it happened to be in
the first public working draft. Even in that situation I can see a legal
argument that the technology is not covered by any license. And of course
*until* Recommendation, there is no license.


If the scope of one reference
changes, there is a new risk. It is not only a problem of conformance
testing.


Not if the /latest/ always points to a REC (or a periodical snapshot  
where IPR commitments to RF have been made).


If you always ensure you are pointing to a particular version of
reference, over which you guarantee that a commitment has been made, then
you are correct. I haven't heard that condition even suggested (let alone
specified in a practical manner) for any living standard before.


Your vision of fluid standards is completely unmanageable in practice.


Yet, somehow, every browser vendor manages? Seems like an enigma.


Actually, I dispute that *any* browser vendor has achieved this. After
years of effort and refinement, most browsers have pretty good coverage of
CSS 2.1 - precisely because it stopped being a living standard and
became a stable target. On the contrary, anyone who claims they conform to
HTML5 is either stupid, since that is a meannigless claim while the
definition of HTML5 is known to be in flux, or thinks we are stupid enough
to believe it. I don't believe any browser makes, nor could make without
being laughed at, such a claim.

What browser vendors do is implement pieces of what they think HTML5 will
be, changing them as the spec changes in an effort to find emergent
patterns from what other browser developers, content producers with big
enough market share to insist on people doing what they want, and hope
(forlornly in many cases) that the developers who relied on what happened
before will actually change their code, so the browser can minimise the
multiple 

Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]

2011-12-18 Thread Charles McCathieNevile
On Sat, 17 Dec 2011 16:24:47 +0100, Olli Pettay olli.pet...@helsinki.fi  
wrote:



On 12/17/2011 04:30 PM, Anne van Kesteren wrote:

On Thu, 24 Nov 2011 14:08:55 +0100, Arthur Barstow
art.bars...@nokia.com wrote:

All - What are the opinions on what, if anything, to do with XBL2
vis-a-vis the charter update? Leave it on the REC track, stop work and
publish it as a WG Note, something else?


I would leave it as, but add a note we might abandon it at some point in
favor of Components. No need to make an early call on that.


That sounds good to me.


Yeah, in drafting the new charter I think that is the approach I took.  
I'll check again when we have figured out what teh story is with things  
people wanted but needed to provide more info for...


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: add Quota API to WebApps' charter; deadline December 20

2011-12-17 Thread Charles McCathieNevile
On Fri, 16 Dec 2011 10:10:45 +0100, Kinuko Yasuda kin...@chromium.org  
wrote:


On Thu, Dec 15, 2011 at 9:19 PM, Arthur Barstow  
art.bars...@nokia.comwrote:



Hi Kinuko, All,

Besides the Chromium team, I think it would be helpful if other browser
vendors would state their level of interest for this API (e.g. would  
review drafts, prototype, deploy, etc.).


We will at least review - in principle this is really useful for  
application developers.


(Comment 1 - why does this need to use callbacks?)

Kinuko - do you have a commitment for the Editor role and testing  
related tasks e.g. creating a test suite?



Yes I'm willing to play the Editor role.
As for the testing related tasks I'm not fully sure the necessary steps  
and deliverables,


Making sure there are tests for the specification so it can be completed  
and anyone can use them to demonstrate interoperability between any two  
implementations...


Given the basic nature of the spec I guess it doesn't need to be an  
enormous test suite - the most complex question is probably checking that  
it really works as advertised with different types of storage. (Although I  
am not sure what the quota would actually *mean* for a database).



but yes I'm willing to do the tasks that need to be done to
move this forward.


In light of the above explanation?

cheers

Chaals


-AB



On 12/13/11 7:23 AM, ext Arthur Barstow wrote:


Subject corrected ...

On 12/13/11 7:22 AM, Arthur Barstow wrote:


As IanF mentioned before, Google would like to add a Quota API to
WebApps' charter and Kinuko has now provided a link to a document that
provides some details about this API:

  http://wiki.whatwg.org/wiki/**Quotahttp://wiki.whatwg.org/wiki/Quota

As such, this is a Call for Consensus to add this API to WebApps'
charter (see [CharterChanges] for latest data on WebApps' charter  
update).


If you have any comments or concerns about this proposal, please send
them to public-webapps by December 20 at the latest.

As with all of our CfCs, positive response is preferred and encouraged
and silence will be assumed to be agreement with the proposal.

-AB

[CharterChanges]  
http://www.w3.org/2008/**webapps/wiki/CharterChangeshttp://www.w3.org/2008/webapps/wiki/CharterChanges



 Original Message 
Subject: Re: Quota API and WebApps [Was: Re: Consolidating charter
changes]
Date: Tue, 13 Dec 2011 17:22:38 +0900
From: ext Kinuko Yasuda kin...@chromium.org
To: Arthur Barstow art.bars...@nokia.com
CC: public-webapps public-webapps@w3.org, Ian Fette 
ife...@google.com



Hi Arthur,

On Wed, Nov 23, 2011 at 10:20 PM, Arthur Barstow  
art.bars...@nokia.commailto:

art.bars...@nokia.com** wrote:

  Hi IanF, All,

  Following up on Quota API vis-à-visCharterChanges wiki [1] ...

  Does the group want to add Quota API to the group's charter? If yes,
  where is a draft/strawman proposal?


We have an early draft for Quota API spec here:
http://wiki.whatwg.org/wiki/**Quota  
http://wiki.whatwg.org/wiki/Quota


I think we want to add it to the group's charter.

  -AB

  [1]  
http://www.w3.org/2008/**webapps/wiki/CharterChangeshttp://www.w3.org/2008/webapps/wiki/CharterChanges


  On 11/8/11 12:37 PM, ext Arthur Barstow wrote:

  During the October 31 meeting, we discussed [1] various
  additions, changes and deletions for WebApps' current charter
  [2]. To consolidate the various proposals, I created the
  following doc:

http://www.w3.org/2008/**webapps/wiki/CharterChangeshttp://www.w3.org/2008/webapps/wiki/CharterChanges


  My expectation is that Doug will this information when he drafts
  our updated charter.

  Comments on this doc and our future charter welcome. However, if
  we are going to add any new deliverables, I think there should
  be broad agreement on the spec, including prior commitment to
  drive the spec through all of the phases of the process
  including testing and implementations.

  Chaals, IanF - I included some actions/questions for you (mostly
  recorded at the f2f meeting).

  -AB

  [1]  
http://www.w3.org/2011/10/31-**webapps-minutes.htmlhttp://www.w3.org/2011/10/31-webapps-minutes.html
  [2]  
http://www.w3.org/2010/**webapps/charter/http://www.w3.org/2010/webapps/charter/











--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Publishing XHR (level 1 and 2)...

2011-12-12 Thread Charles McCathieNevile
Hi All - the CfCs to publish a WD of the new XHR [1] and a WG Note of  
the old XHR [2] resulted in different opinions expressed. We think it is  
important to provide a clear message (especially for those not closely  
following WebApps' related discussions) that: 1) the group agreed to stop  
working on the old XHR (effectively obsoleting the XHR CR); and 2) the  
group will continue work on the new XHR.


As such, we will move forward this way:

1. Publish a WG Note of XHR in /TR/XMLHttpRequest1/. The Status section of  
the NOTE will use the same style as used in for the Web SQL Database Note  
[3] and include: 1) a warning re the work has stopped; and 2) a link to  
the new XHR spec. The XHR CR, the last version of the spec with a recorded  
agreement on the contents, will be used as the basis of the CR.


2. Publish a new WD of the new XHR spec in /TR/XMLHttpRequest/ and titled  
XMLHttpRequest Level 2.


If the publications can be made pub ready by December 12, they will be  
published on December 15; otherwise the publication will be in January.


-Chaals and Art

[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1250.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1306.html
[3]  
http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/#status-of-this-document


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Publishing XHR (level 1 and 2)...

2011-12-12 Thread Charles McCathieNevile
On Mon, 12 Dec 2011 14:47:06 +0100, Charles McCathieNevile  
cha...@opera.com wrote:


Hi All - the CfCs to publish a WD of the new XHR [1] and a WG Note of  
the old XHR [2] resulted in different opinions expressed. We think it  
is important to provide a clear message (especially for those not  
closely following WebApps' related discussions) that: 1) the group  
agreed to stop working on the old XHR (effectively obsoleting the XHR  
CR); and 2) the group will continue work on the new XHR.


As such, we will move forward this way:

1. Publish a WG Note of XHR in /TR/XMLHttpRequest1/. The Status section  
of the NOTE will use the same style as used in for the Web SQL Database  
Note [3] and include: 1) a warning re the work has stopped; and 2) a  
link to the new XHR spec. The XHR CR, the last version of the spec with  
a recorded agreement on the contents, will be used as the basis of the  
CR.


Err, we meant the CR will be the basis of the Note. :(

2. Publish a new WD of the new XHR spec in /TR/XMLHttpRequest/ and  
titled XMLHttpRequest Level 2.


If the publications can be made pub ready by December 12, they will be  
published on December 15; otherwise the publication will be in January.


-Chaals and Art

[1]  
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1250.html
[2]  
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1306.html
[3]  
http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/#status-of-this-document





--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish Proposed Recommendation of WARP; deadline December 5

2011-11-28 Thread Charles McCathieNevile
On Mon, 28 Nov 2011 13:40:55 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:


The Patent Advisory Group for the WARP spec recommended the WG should  
continue to work on the spec [1] (Member-only) and there is no need to  
modify the CR [2]. Given this recommendation, plus the CR's exit  
criteria have been met [3], this is a Call for Consensus to publish a  
Proposed Recommendation of WARP using the following ED as the basis:


   http://dev.w3.org/2006/waf/widgets-access/


Opera supports.

cheers

Note the Process Document includes the following regarding the entrance  
criteria for a PR and the WG's requirements:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

* Shown that each feature of the technical report has been implemented.  
Preferably, the Working Group SHOULD be able to demonstrate two  
interoperable implementations of each feature.

]]

Positive response to this CfC is preferred and encouraged and silence  
will be considered as agreement with the proposal. The deadline for  
comments is December 5. Please send all comments to:


public-webapps@w3.org

-Art Barstow

[1] http://www.w3.org/2009/11/widgets-pag/pagreport.html
[2] http://www.w3.org/TR/2010/CR-widgets-access-20100420/
[3] http://dev.w3.org/2006/waf/widgets-access/imp-report/




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: PointerLock and Gamepad APIs

2011-11-24 Thread Charles McCathieNevile

On Thu, 24 Nov 2011 09:04:19 +0100, Darin Fisher da...@google.com wrote:


I'd like to therefore propose that instead of expanding the charter of
WebEvents to include PointerLock and Gamepad, that we instead add those
APIs to another WG such as WebApps.  I believe they make sense in WebApps
given the scope of work being done there and the parties involved.

Thoughts?


1. This is unfortunate (to put it politely).
2. Opera can live with the work being done in WebApps.

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [Widgets] CfC: add WidgetStorage interface to API spec; deadline December 1

2011-11-24 Thread Charles McCathieNevile

On Thu, 24 Nov 2011 15:42:08 +0100, Robin Berjon ro...@berjon.com wrote:


On Nov 24, 2011, at 15:36 , Arthur Barstow wrote:
Marcos asserted in followups to his proposal that this change would not  
affect any implementations nor applications. As such, the change  
request, if applied, will not require republication as a new (LC)WD.


+1


Me Too !1!


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Dropping XMLHttpRequest 1 (just do 2)?

2011-11-23 Thread Charles McCathieNevile
On Wed, 23 Nov 2011 15:54:10 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:


[[ removed the chairs list since I think this is now mostly a WebApps  
thing ... ]]


I haven't seen any objections to dropping XHR1 and voices of support to  
redirect the XMLHttpRequest2 shortname to XMLHttpRequest.


I think it would be helpful to some readers if the new XHR spec (i.e.  
the spec formerly titled XHR2) included a short note about the  
consolidation of the work and after a publication or two, the note could  
be removed.


It seems like the main points to include in a new WD of the new XHR spec  
are:


* All work has stopped on the spec that was formerly titled  
XMLHttpRequest  (also referred to as XMLHttpRequest Level 1 and XHR1)  
and last published as a Candidate Recommendation on 2 August 2010.


* WebApps will only work on what was previously titled the  
XMLHttpRequest Level 2 spec (aka XHR2) but note that spec is now  
titled XMLHttpRequest and uses the XMLHttpRequest shortname  
(w3.org/TR/XMLHttpRequest) that was previously used for XHR1.


Chaals, All - WDYT?


Yep, agree.

(I'm not sure what, if anything, to do about the Previous Version links  
in the new XHR spec. Perhaps the old XHR previous versions should just  
be ignored?)


well, they are previous versions. The question about dealing with old  
drafts and how they advertise that they have been replaced is applicable  
here, but orthogonal to what we do with XHR.


cheers


-AB

On 11/9/11 12:40 PM, ext Charles McCathieNevile wrote:

Hi,

ACTION-629 from the webapps meeting at TPAC is to check whether any  
group has a normative dependency on XMLHttpRequest level 1. Otherwise  
we are likely to request the AC to let us drop it from our list of  
deliverables. We don't have an editor to finish whatever needs to be  
done, and we don't have implementation of the complete spec (people are  
not ready to fix the last outstanding bits, and nobody is ready to  
remove them).


If nobody objects, our plan is to stop work on level 1, and move ahead  
only with level 2.


cheers

Chaals




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Dropping XMLHttpRequest 1 (just do 2)?

2011-11-23 Thread Charles McCathieNevile
On Mon, 14 Nov 2011 19:35:22 +0100, Giuseppe Pascale giusep...@opera.com  
wrote:


On Mon, 14 Nov 2011 19:31:55 +0100, Anne van Kesteren ann...@opera.com  
wrote:


On Mon, 14 Nov 2011 19:19:37 +0100, Marcos Caceres w...@marcosc.com  
wrote:
Better yet, dump the 2 version number and just have  
/XMLHttpRequest2/ point to /XMLHttpRequest/.


Everything in 1 is in 2, so making a big deal out of this is a  
valuable waste of time justifying the decision.


There is no point in having Level 1 and Level 2 since there is no  
Level 1… there is just XMLHttpRequest :)


I favor this approach.

If that's the case would be possible to replace xhr 1 spec text with xhr  
2 text spec and drop 2?

Any issue in doing that?


I think it is essentially the same thing. If you go to a specific version,  
you get that specific version. If you go to /XMLHttpRequest you get the  
latest version, which is what is in XHR2.


FWIW I would like to have had the resources to finish this spec and park  
it, instead of having the whole lot left unfinished. We don't - both in  
terms of editing, and because the implementations won't match it - XHR1  
changed from documenting what someone did to documenting what we were all  
working towards, and since what we are all working towards (and haven't  
achieved yet) is XHR2, merging them seems like the most sensible and  
helpful way forward.


cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Identifying Test Spec Editors; deadline Nov 11

2011-11-13 Thread Charles McCathieNevile
On Sat, 12 Nov 2011 14:09:15 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:



On 11/11/11 7:53 PM, ext Adrian Bateman wrote:

On Friday, November 04, 2011 4:59 PM, Arthur Barstow wrote:

One of the topics discussed this week was to designate a Test Spec
Editor(s) for each of our specs.

We're supportive of this idea.


(BTW, the title of Test Spec Editor is a bit of a straw-man, so
proposals for other titles are also welcome.)
I wonder if Test Suite Facilitator (or similar) is a better title. We  
use Facilitator
in HTML WG and I think it may be more of a coordination role than a  
person that does
all the editing work of the test suite (that's how it seems to work in  
HTML at the

moment).


If anyone objects to Test Facilitator, please speak up; otherwise, at  
the end of next week I will add that role to PubStatus' Testing column  
and issue some type of Call for Test Facilitators for our various test  
suites:


I positively support it, basically for the reasons Adrian outlined.

cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Consolidating charter changes

2011-11-10 Thread Charles McCathieNevile
On Thu, 10 Nov 2011 14:36:24 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:



On 11/10/11 4:36 AM, ext Robin Berjon wrote:

Hi,

On Nov 9, 2011, at 00:25 , James Hawkins wrote:

Under 'Additions Agreed':
* Web Intents - this will be a joint deliverable with DAPI WG

Pedantically, not politically: My recollection is that the agreement  
was only to add Web Intents to the Webapps charter (neither accepting  
nor denying a joint deliverable with DAPI).  The status of the joint  
deliverable is still a possibility, just technically not agreed upon  
as of yet.  It may be best to reword this to state that the  
possibility still exists, so those not in attendance don't get the  
idea that we agreed to a joint deliverable at the meeting.


My recollection, which seems to be supported by the minutes, is that  
Chaals supported moving this to DAP, Google (collectively) wouldn't  
object to a joint deliverable, Maciej said Apple couldn't join DAP  
as-is but I don't recall issues with joint work. Rough consensus seemed  
to drift towards joint work. At the DAP meeting, where the notion of a  
joint deliverable was accepted, Jonas (amongst several others)  
specifically requested that this happen on a separate mailing list. So  
unless we are keen to rathole on politics I'd suggest we just go with  
that, no? An additional plus is that doing it jointly means we can  
start right now and not wait for WebApps to recharter.


I'll have a joint TF proposal out here very soon.


As the discussion on October 31 was ending, I asked if anyone objected  
to a joint deliverable and no one did [1]. Given DAP is agreeable with  
cooperating with WebApps on Web Intents, it seems like the most  
expeditious and practical way forward is to create a list for related  
discussions.


Agreed.

cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [DRAFT] Web Intents Task Force Charter

2011-11-10 Thread Charles McCathieNevile

On Thu, 10 Nov 2011 14:54:36 +0100, Robin Berjon ro...@berjon.com wrote:

here is a draft of the Intents joint Task Force charter for comments  
from WebApps and Device APIs... 
The Web Intents Task Force works on a joint deliverable of the WebApps  
and Device APIs WGs that aims to produce a way for web applications to  
register themselves as handlers for services, and for other web  
applications to interact with these through simple requests brokered by  
the user agent (a system commonly known as Intents, or Activities).


The mailing list on which the TF's discussions take place is  
public-inte...@w3.org. The chair is Robin Berjon.


Operational modalities such as whether or not to have phone and/or face  
to face meetings, as well as where to store the draft document are left  
to the TF to decide for itself. Decisions are made by consensus inside  
of the task force and do not require separate ratification by the wider  
groups.


It is important to note that until such a time as the WebApps WG is  
rechartered with Intents in its list of deliverables, it will be  
necessary for participants in WebApps who are not in Device APIs and  
wish to make substantive contributions (just joining the discussion and  
providing comments is always fine) to make an RF commitment for this  
deliverable (not necessarily for other DAP deliverables, naturally). For  
more details on this, please contact the W3C Team.





WDYT?


Works fine for us. Let's get on with the Real Work™

cheers


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Dropping XMLHttpRequest 1 (just do 2)?

2011-11-09 Thread Charles McCathieNevile

Hi,

ACTION-629 from the webapps meeting at TPAC is to check whether any group  
has a normative dependency on XMLHttpRequest level 1. Otherwise we are  
likely to request the AC to let us drop it from our list of deliverables.  
We don't have an editor to finish whatever needs to be done, and we don't  
have implementation of the complete spec (people are not ready to fix the  
last outstanding bits, and nobody is ready to remove them).


If nobody objects, our plan is to stop work on level 1, and move ahead  
only with level 2.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [ElementTraversal] Moving traversal from Element Traversal to DOM4?

2011-11-09 Thread Charles McCathieNevile

On Wed, 09 Nov 2011 15:54:31 +0100, Robin Berjon ro...@berjon.com wrote:


On Nov 9, 2011, at 15:19 , Arthur Barstow wrote:
Doug, All - as a followup to the short conversation on October 31 re  
moving the traversal part of Element Traversal to DOM4, do you have any  
thoughts on what, if anything, should be done?


Is there any reason that more than pasting it into DOM4 plus whatever  
stylistic arrangements the editor likes would be needed?


None that I can see, and no reason not to do that that I can think of.

cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Dropping XMLHttpRequest 1 (just do 2)?

2011-11-09 Thread Charles McCathieNevile

On Wed, 09 Nov 2011 20:46:45 +0100, Karl Dubost ka...@opera.com wrote:


ACTION-629

I found only 2 references found to XMLHttpRequest CR version (3 August  
2010) [1]


Thanks for looking around.


# Resource Timing [2]


  Reference to XHR in the interface
  4.3 The PerformanceResourceTiming Interface
  http://www.w3.org/TR/2011/WD-resource-timing-20110524/#type-xhr


Which simply declares a constant to mean XHR without a requirement for  
any particular flavour.



# Guidelines for Web Content Transformation Proxies 1.0 [3]

  4.1.3 Treatment of Requesters that are not Web browsers


Which is a note, and not under further development.


[1]: http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803
[2]: http://www.w3.org/TR/2011/WD-resource-timing-20110524/
[3]: http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/


Cheers

Chaals


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: new WD of File API; deadline Oct 17

2011-10-14 Thread Charles McCathieNevile
On Mon, 10 Oct 2011 18:25:42 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


This is a Call for Consensus to publish a WD of the File API spec (last  
published 26-Oct-2010):


Do it...


   http://dev.w3.org/2006/webapi/FileAPI/

Positive response to this CfC is preferred and encouraged and silence  
will be considered as agreement with the proposal. The deadline for  
comments is October 17. Please send all comments to:


 public-webapps@w3.org

-AB




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish new WD of Indexed Database API; deadline Oct 21

2011-10-14 Thread Charles McCathieNevile
On Fri, 14 Oct 2011 22:04:06 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


This is a Call for Consensus to publish a new Working Draft of the  
Indexed Database API spec (last published 19-Apr-2011):


Yes please.

cheers


http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

Agreement to the proposal: a) indicates support for publishing a new WD;  
and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please send  
them to public-webapps by October 21 at the latest.


As with all of our CfCs, positive response is preferred and encouraged  
and silence will be assumed to be agreement with the proposal.


FYI, the open bug list for this spec is at [1].

-AB

[1]  
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Indexed%20Database%20APIresolution=---






--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Adding Web Intents to the Webapps WG deliverables

2011-09-25 Thread Charles McCathieNevile

On Tue, 20 Sep 2011 16:04:29 +0200, Ian Fette (イアンフェッティ)
ife...@google.com wrote:

With all due respect, I think that if we have to re-charter or create a  
new working group each time a new API comes up we are all doomed. The  
overhead of creating and monitoring so many WGs is not appealing to

many of us.


Agreed - but at the same time if people start doing work that others are
doing in another group, so they can do it with different people, we are
all doomed. It is generally not a helpful way to get to a common standard.

There is a group where the work you're interested in was already agreed as
a deliverable. Which to some extent suggests this isn't a new API, it's
Yet another API for doing something people knew they wanted to do.

Reading this discussion and understanding the issue multiplied out over
the people who effectively have to follow the discussion seems far more
process overhead than you and MS just joining that group. Even if MS
doesn't join, they can (and with all the rest of webapps will be invited
to) comment and make an IPR commitment. And as noted, discussing on the
same list doesn't guarantee attention from the other subscribers anyway.

We are unlikely to stop you holding discussion here, but it would appear
that it makes more sense to do it in a group which is already chartered to
produce the deliverable.

So with all due respect, I suggest that joining DAP and doing the work is
an efficient way forward, while carrying on a process discussion here is
sidetracking a lot of people whose time could otherwise be spent making
technical progress on something.

Part of the value of W3C standards, as compared to random spec proposals
from a vendor or three, comes from a process that gives many kinds of
stakeholders confidence in what that means. Chartering a group with a
reasonable scope definition and then doing that work there is part of the
way that process works. You could always ask Google's W3C Advisory
Committee representative T V Raman to raise the process discussion to the
AC forum, where it is directly in scope. The point of this group, DAP, and
other WGs is to focus on doing their chartered technical work.

cheers


On Tue, Sep 20, 2011 at 6:55 AM, Robin Berjon ro...@berjon.com wrote:


Hi James,

thanks for bringing this forward, it is indeed a very interesting  
approach.


On Sep 19, 2011, at 22:27 , James Hawkins wrote:
 I've read through the Webapps charter, and I believe Web Intents fits  
the

goals and scope of the WG.

It does fit the goal and scope, but then most web client technology  
does ;)
Where you may run into issues is that it does not fit in the  
deliverables

list. Since that is what members makes their IP commitment on, a new
deliverable of non-negligible content might require rechartering. Last  
time

we did that, it wasn't very pleasant.

Thankfully, there is already a group that was chartered with Intents  
(or,

in the poetic phrasing of charters, with an API that allows web
applications to register themselves as handlers/providers based on data
string identifiers and an API that enables other web applications to
discover these handlers/providers and gain permission to interact with  
them

— but Intents is what that means): the Device APIs group,
http://www.w3.org/2011/07/DeviceAPICharter. It'd save a lot on the
bureaucracy and allow us all to just go straight to work.

We'd certainly be happy to accept your draft input. The new DAP is  
meant to

be completely flexible in how it is organised. Notably, if you prefer to
conduct work on this spec without necessarily getting all the email  
from the
rest of the group we can setup a dedicated Task Force with its own  
mailing

list and chair (if there's a volunteer, otherwise I'll do it). TFs can
decide whether they want to have telcons or not.

--
Robin Berjon - http://berjon.com/ - @robinberjon






--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
  je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Joystick support

2011-08-25 Thread Charles McCathieNevile

On Thu, 25 Aug 2011 16:23:19 +0200, Tran, Dzung D dzung.d.t...@intel.com
wrote:

This seems like it could fit more into the Web Events WG. In the Web  
Events, we deal with touch events, which are user inputs, this seems to  
be in the same category.


Yes, I also think this belongs in Web events.

Cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
  je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish Last Call WD of Progress Events; deadline August 2

2011-07-26 Thread Charles McCathieNevile
On Tue, 26 Jul 2011 16:12:40 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


The pre-LC comment period for Progress Events resulted in no comments  
[1]. As such, Anne proposes a new LC be published and this is a CfC to  
do so:


Opera supports publishing.

cheers

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish Proposed Recommendation of view-mode Media Feature; deadline July 27

2011-07-24 Thread Charles McCathieNevile
On Wed, 20 Jul 2011 16:30:41 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


As mentioned in [1], the exit criteria of the view-mode Media Feature  
Candidate Recommendation [2] has been met (at least two implementations  
pass every test):


   http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/

As such, this is Call for Consensus to publish a Proposed Recommendation  
(PR) of this spec.


Opera supports publication as PR

cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



CfC: IETF Media Type Specifications and Registration Procedures

2011-07-24 Thread Charles McCathieNevile

FYI

--- Forwarded message ---
From: Philippe Le Hegaret p...@w3.org
To: w3c-html-cg w3c-html...@w3.org, w3c-xml...@w3.org
Cc:
Subject: Media Type Sepecifications and Registration Procedures
Date: Sun, 24 Jul 2011 22:00:26 +0200

W3C Working Groups are *highly* encouraged to review
[[
Media Type Specifications and Registration Procedures
draft-freed-media-type-regs-00
June 13, 2011
]]
  http://tools.ietf.org/html/draft-freed-media-type-regs-00

Deadline for comments is end of summer,

Thank you,

Philippe


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Test suites and RFC2119

2011-07-12 Thread Charles McCathieNevile

On Mon, 11 Jul 2011 19:06:57 +0200, Karl Dubost ka...@opera.com wrote:


Le 11 juil. 2011 à 12:58, Aryeh Gregor a écrit :

The standards we're discussing are not coercive.


Just a minor semantics point. Web Standards are never coercive.
They might be used by legal framework aw as a reference point for a  
certification process.


Actually, the question is important because some standards *are* used by  
legal frameworks in this way, and even more important because many are  
used in this way in contracting processes. In both cases this can affect  
many people's livelihood, so understanding the impacts of what we do is  
probably worth the effort.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Fwd: Discontinuing UK and FR dial-in numbers for Zakim

2011-07-11 Thread Charles McCathieNevile

FYI

--- Forwarded message ---
From: Ted Guild t...@w3.org
To: w3c-tools w3c-to...@w3.org, chairs cha...@w3.org
Cc:
Subject: Discontinuing UK and FR dial-in numbers for Zakim
Date: Mon, 11 Jul 2011 19:06:43 +0200

Previously we announced our intent to discontinue the UK and FR
telephone dial-in numbers for Zakim in favor of a VoIP solution.

http://www.w3.org/2006/tools/wiki/Zakim-SIP

We have found the providers used to be costly and inconsistent not to
mention it raises inquiries of supporting additional dial-in numbers for
more countries.  We chose to instead invest in VoIP as an international
solution.

We will drop these numbers at the end of the month, please alert your
Working Groups.

The US number will remain available.


--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: publish Last Call Working Draft of Web IDL; deadline July 7

2011-07-10 Thread Charles McCathieNevile

On Sun, 10 Jul 2011 20:01:17 +0200, timeless timel...@gmail.com wrote:

On Sat, Jul 9, 2011 at 7:23 AM, Arthur Barstow art.bars...@nokia.com  
wrote:
Although there are ongoing discussions regarding exceptions, there were  
no

objections to this CfC. As such, I will request publication of a LC
specification to encourage broader review and comments.


Sorry, I'm in the midst of sending comments on WebIDL. I should be
done by Tuesday...


Hi Josh,

do you think these comments should hold up the request for last call, or  
are you happy for that to go ahead?


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Test suites and RFC2119

2011-07-10 Thread Charles McCathieNevile
On Wed, 06 Jul 2011 00:32:42 +0200, Aryeh Gregor  
simetrical+...@gmail.com wrote:



Generally, if something is important enough for interop that we want
to test it, we don't want to make it a should requirement.  It
should be a must.  What examples do you have of should
requirements that you want to test?


Privacy and security restrictions leap to mind. There are things that  
really are should requirements because there are valid use cases for not  
applying them, and no reason to break those cases by making the  
requirement a must. In the normal case where they are applied you want  
to be able to test.


But the difference between should and must is already two sets of  
conformance profiles (or whatever you want to call it), where one applies  
always and the other applies unless there's a reason not to do the thing  
that is assumed to be normal.


cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Test suites and RFC2119

2011-07-10 Thread Charles McCathieNevile
On Sun, 10 Jul 2011 22:34:59 +0200, Aryeh Gregor  
simetrical+...@gmail.com wrote:



On Sun, Jul 10, 2011 at 3:59 PM, Charles McCathieNevile
cha...@opera.com wrote:
Privacy and security restrictions leap to mind. There are things that  
really are should requirements because there are valid use cases for

not applying them, and no reason to break those cases by making the
requirement a must. In the normal case where they are applied you
want to be able to test.


Were you thinking of specific examples?  I can't think of any offhand.


The most recent example is the Contacts API from the DAP group, but this  
is a pretty common pattern. Geolocation went through a long discussion on  
the topic.



But the difference between should and must is already two sets of
conformance profiles (or whatever you want to call it), where one  
applies always and the other applies unless there's a reason not to

do the thing that is assumed to be normal.


The difference is that if you have must requirements that are
specific to a single conformance class, you can write a test suite and
expect every implementation in that class to pass it.


Yep.


For should requirements, you're saying it's okay to violate it, so
test suites don't make a lot of sense.


Not quite. I'm saying that there are cases where violoating the  
requirement is reasonable, so test results shouldn't determine simple  
conformance.


On the other hand, where these are things that in *most* cases we want  
interoperability, it makes sense to have test suites so people who don't  
violate the requirement can check that what they are doing is consistent  
with what others do.


Essentially the question shouldn't revolve around the tests themselves -  
tests can be useful even when they're not determining pure conformance.  
What matters is how you use the results.


Performance tests are another class of tests that can be very useful,  
allowing people to understand what sort of things work well and what sort  
of things might cause real-world problems, without normally giving any  
information about actual conformance.


cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Where to discuss TR process issues? [Was: Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1

2011-07-09 Thread Charles McCathieNevile

On Wed, 06 Jul 2011 23:50:48 +0200, Ian Hickson i...@hixie.ch wrote:


On Wed, 6 Jul 2011, Arthur Barstow wrote:


So, rather than continuing to complain about this process on
public-webapps, I would appreciate it if you would please move TR
process type discussions to another Public list.


I'm not asking to have a discussion about it at all; I'm asking that you
stop trying to prioritise my work based on it.


Hi Ian,

in so far as the Web Apps group is currently chartered under the existing  
W3C process, and you are an editor of some specs under the terms of that  
charter, I find it hard to understand what us unreasonable about  
prioritising the work of the group (some of which you have volunteered to  
do) according to the existing agreements about how the group functions.


For what it's worth, I am a member of the Advisory Board, and in that  
capacity I share some of your concerns. I, and I believe the advisory  
board as a whole, would appreciate you taking the time to make some  
proposals on process to that forum - a...@w3.org with a cc to e.g.  
www-archive if you want a public track. As an employee of a W3C member,  
you could also ask your member representative (TV Raman) to present  
concerns through the Advisory Committee forum.


Whether you chose to do so or not, these issues are being followed in the  
relevant fora - but this group isn't really it.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Test suites and RFC2119

2011-07-04 Thread Charles McCathieNevile

On Mon, 04 Jul 2011 11:47:22 +0200, Rich Tibbett ri...@opera.com wrote:

RFC2119 'Key words for use in RFCs to Indicate Requirement Levels'  
defines the keyword 'SHOULD' as:


This word, or the adjective RECOMMENDED, mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

Generally, I think we can agree that anything less than MUST or MUST NOT  
requirements in a spec are pretty useless when it comes to conformance  
testing. We try to write specs to these keywords but other keywords tend  
to creep in to most specifications.


Hmm. No, I think a spec that uses these correctly has requirements where  
there are legitimate reasons not to do the usual thing, but a strong case  
for doing it unless there is a clear reason.


We currently define tests in test suites for SHOULD requirements. A  
problem occurs when those tests are used to gauge the overall compliance  
of an implementation to the full test suite. An implementation could  
theoretically be 100% compliant without needing to pass non-MUST and  
non-MUST NOT tests.


I don't think so. RFC 2119 is pretty clear about what must and should  
mean. As Bjoern said a numerical score for tests is generally not that  
useful. But compliance is doing all the things you must, and in practical  
terms that can readily be translated to *at least* passing all the test  
that test things the spec says must happen.


Perhaps we should introduce 'bonus' points for SHOULD/SHOULD NOT/MAY and  
RECOMMENDED tests and not have them contribute to overall compliance  
output, thereby allowing implementations to claim 100% compliance to  
MUST/MUST NOT tests. An implementation can then optionally collect any  
available, optional bonus points as available from requirements marked  
up with other keywords.


Wondering if there is any set W3C thinking on this or a way of including  
SHOULD tests in test suites but clearly indicating that they are,  
basically, optional and do not count towards the overall compliance  
score? I couldn't find anything in [1].


I don't think it's a good idea to do numerical scoring of conformance. Yu  
would need to be sure that the things being tested are of equal  
importance, or work out how to balance the scores. And the cost of that  
already outweighs the benefit by so much it seems pointless to go there.


just my 2 cents

chaals


- Rich

[1] http://www.w3.org/TR/test-methodology/



--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [Widgets] Mozilla open apps

2011-06-29 Thread Charles McCathieNevile
-specific behaviour)  
but it doesn't feel like its either within the scope of Widgets itself  
nor a blocker for MOWA using Widgets. Indeed, the MOWA APIs themselves  
could be exposed as features, or directly injected into applications  
regardless if running on a MOWA-capable Widget server.




XML vs. JSON
Cultural nit: many web developers have trouble with complex XML  
encodings.  It's frustrating, but true.  Would the specification of a  
JSON dialect be amenable, or is it that a non-starter?


JSON makes it a little bit easier to implement a UA, and a little bit  
harder to write a widget manifest in a text editor. If you are writing  
some sort of app store you could easily generate any representation you  
fancied supporting based on the requested content-type (JSON, XML, YAML,  
RDF...) So I don't think its a big spec issue. (This might be part of a  
Note for web apps  - e.g. MUST support getting the manifest as XML,  
SHOULD support getting it as JSON, MAY support any other formats.)




Localization Model
The xml:lang based approach is structural analogous (though somewhat  
tedious to handle in JSON, but that's not really important).  In the  
absence of a content element, the folder-based localization strategy  
could hit some bumps.  Perhaps extending lang to a couple more elements  
would be sufficient - we are trying to fit into existing user-agent  
localization approaches, which might mean that we need to identify a  
different set of hostnames or launch URLs as well.


We can't mandate a folder-based localization model since we are trying  
to describe existing web content.


We use Widgets on a web server, and implement folder-based localisation  
using a server-side resource filter. I don't think rewriting requests  
for my.widget.site/index.html to my.widget.site/locales/fr/index.html  
based on HTTP locale headers ought to be a big challenge for a  
server-based UA. The only problem you would face is with purely static  
file servers, where the developer also has no way of creating a server  
rewrite or forwarding rule.



Widget features we can adopt
I think name, description, author, license, icon, and feature are all  
straightforward enough.  Is the assumption that the value space of  
feature is going to be the W3C Permissions set [2], or something else?


(Prior warning: I apologize if I disappear from the list at short  
notice in a day or two; I have a new baby coming imminently)


[1] http://code.google.com/chrome/apps/docs/developers_guide.html
[2] http://www.w3.org/TR/2010/WD-api-perms-20101005/


Features/capabilities was dropped from later versions of MOWA.

In general I don't think there are any serious barriers to implementing  
Mozilla Open Web Apps directly using Widgets as-is.  A lot of the  
value-add for MOWA is in the app repository trust model that seems  
outside the scope of the Widget itself - this looks a bit odd bolted  
onto the manifest but looks great as the starting point for a broader  
app repository/federation spec regardless of the flavour of apps  
involved (Widgets, MOWA, OpenSocial... add 17 others here). So maybe one  
way forward is for Mozilla to promote these specific features/use-cases  
in the Federated Social Web activity.


In any case I think looking at where we are now its more a case of  
Widgets + MOWA rather than Widgets or MOWA: in other words, MOWA  
could be rather like WAC in taking the Widget specs and developing  
standardised services and identity/trust rules for implementers. I think  
if I were so inclined I could make Wookie into a MOWA store for serving  
Widgets without any big architecture changes, for example.


Anyway, sorry for reviving a dead thread, but thought it might be of  
interest.


S



Best,
Mike
--
Michael Hanson, Mozilla Labs





--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: RfC: moving Web Storage to WG Note; deadline June 29

2011-06-27 Thread Charles McCathieNevile
On Mon, 27 Jun 2011 17:43:15 +0200, Adrian Bateman  
adria...@microsoft.com wrote:



On Wednesday, June 22, 2011 3:24 PM, James Robinson wrote:
On Wed, Jun 22, 2011 at 2:42 PM, Aryeh Gregor  
simetrical+...@gmail.com wrote:
 On Mon, Jun 20, 2011 at 10:50 PM, Boris Zbarsky bzbar...@mit.edu  
wrote:
  Note that there are currently major browsers that do not follow the  
  spec as currently written and have explicitly said that they have no

  plans to do so.
 If browsers can agree on what to implement, update the spec to reflect
 that.  If they can't and we don't think they ever will, update the
 spec to say behavior is undefined.  Either way, it's no less worthy of
 REC-track specification than other preexisting features that are
 flawed but in practice not removable from the platform.

...
I agree - the current API isn't ideal but it is what it is and there is  
reasonable interoperability at this point. Microsoft would prefer not to

see the spec move to WG Note status and instead see the spec modified to
reflect the current implementations: removing the SCA, removing the  
mutex,

and adding a warning about the race conditions would get us most of the
way. There are certainly uses of this feature where the race is unlikely
to cause a problem.


Yep, Opera agrees. So, do you have someone available to edit the spec thus
and help it through the Rec track?

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Is Progress Events spec ready for Candidate Rec? [Was: Re: RfC: Last Call Working Draft of Progress Events; deadline June 1]

2011-06-07 Thread Charles McCathieNevile
On Thu, 02 Jun 2011 18:25:18 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:



Hi All,

The comment period for Progress Events LC ended on June 1 and my take on  
the status is: no comments were submitted to public-webapps during the  
LC comment period; there are no open bugs for this spec (Webapps has no  
related component in Bugzilla and Tracker has 0 bugs); and the ED [ED]  
has not changed since the LC was published.


Given this, the next step should be to publish a Candidate  
Recommendation. However, AFAIK, Anne is still off-grid and I don't know  
when he will return.


Chaals, All - if there are any reasons to not start a CfC to publish a  
CR for this spec, please speak up.


Anne has been looking after the spec, and is on leave for about another  
week. I suggest waiting until Anne is back to check that this makes  
sense...


cheers


-AB

[ED] http://dev.w3.org/2006/webapi/progress/


On Mar/10/2011 7:33 PM, ext Arthur Barstow wrote:
This is a Request for Comments for the March 10 Last Call Working Draft  
of Progress Events:


http://www.w3.org/TR/2011/WD-progress-events-20110310/

If you have any comments, please send them to the following list by 1  
June 2011 at the latest:


public-webapps@w3.org

-Art Barstow




--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [WARP] it's just too strict...

2011-06-02 Thread Charles McCathieNevile
On Thu, 02 Jun 2011 09:40:33 +0200, Marcos Caceres  
marcosscace...@gmail.com wrote:



I want to again voice my concerns about WARP's strictness; The
following requirement has to be relaxed in the future (v2?):


If origin is not a valid IRI, if it has components other than scheme
and iauthority, if it has no host component, or if it has a iuser info
component, then this element is in error and the user agent MUST
ignore this element.


The offending part is if it has components other than scheme and
iauthority. This means that the following URLs are out:

http://foo.com/
http://foo.com?
http://foo.com#

I think this needs to be changed to just extract the origin the
developer is trying to access. We should be more liberal and forgiving
in what we accept in WARP.


Agree.

cheers


As I have already pointed out in other
emails, Opera already had to relax conformance to the above
requirement because it was causing issues for developers. I don't
doubt that this will cause more problems in the future.

Kind regards,
Marcos




--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [widgets] localizing author

2011-05-24 Thread Charles McCathieNevile
On Tue, 24 May 2011 11:28:55 +0200, Marcos Caceres  
marcosscace...@gmail.com wrote:



Hi Charles,

As this was a comment on a Last Call draft, I just wanted to close the
loop on this so we can record it in the Disposition of Comments.

Are you ok with leaving localization of the author element until
version 2 of the spec? Are you ok for the specification to progress
down the REC track?


Yep :|

Cheers

Chaals


Please let us know by the 27th of May; otherwise we will have to
assume you are ok with that (which I'm hopeful you are:)).

Kind regards,
Marcos



On Thu, May 5, 2011 at 12:02 PM, Marcos Caceres
marcosscace...@gmail.com wrote:


On Thursday, May 5, 2011 at 6:38 AM, Charles McCathieNevile wrote:

On Wed, 04 May 2011 18:29:50 +0200, Marcos Caceres
marcosscace...@gmail.com wrote:

  Hi,
 
  I just realised that I actually localise my own name...
  But I cannot do that in config.xml. Likewise, I would
  like to localise the href for me which would be possible if I could
  localise the author element but isn't at the moment.

 Yes, this was a mistake.

If we were at REC I would suggest this go into an erratum...


Although it seems like a small thing, it's a significant change to the  
parsing model for this kind of element. And if we change it for author,  
we should also change it for icon too.




  I don't know if this is too late for the current version, in which  
case

  please log it as an issue for the future.

 I think it is too late for this version. We have runtimes now at 99%  
and

 even 100% conformance and adding this would make most runtimes
 non-conforming. I think its more important now to push this spec to  
REC

 and address these kinds of cases in a future version of the spec.

Do we have a test for this? I propose that we allow our run-time (and
other implementations, such as the validation used by Opera stores) to
localise author, and if that makes us non-conforming we're letting  
good be

an enemy of better (and the argument that we have conformant run-times
then looks weaker). If we don't have a test for it, then we know there  
is

a requirement in our spec that isn't tested anyway.


There are no tests that combine xml:lang and the author element - so I  
think you are in the clear wrt conformance (this also means that spec  
is in the clear to allow this feature to be added later). So, :D. There  
are tests to make sure that only the first author element in document  
order encountered is selected:


http://dev.w3.org/2006/waf/widgets/test-suite/#user-agent/ta-LYLMhryBBT/tests

So, adding the behavior you are proposing could keep Opera conforming  
for the purpose of the test suite: when author elements with no  
xml:lang are present in a config.xml, behave as the spec says today.  
Otherwise, behave as if author was localizable via xml:lang.




In paticular, since we have at least one live product (addons.opera.com
submission process) that validates against the existing schema, we have
the choice of either supporting the spec or supporting best practice  
here.

What would you prefer us to do?
If I could have one wish, I wish Opera would first claim 100%  
conformance by fixing the empty name element bug. Then, after that,  
we create a new spec that makes both author (and icon!) localizable  
via xml:lang. Existing content will continue work with the introduction  
of this new behavior and can even be kept backwards compatible with  
existing runtimes if a few simple rules are followed during authoring.  
However, if you can get both implemented in a timely manner, that's  
also a huge win for authors.




  Changing it to allow localisation would mean a change to the  
schema -
  and at least to Opera's implementation. I haven't yet checked (I  
only
  realised I want to do this but it isn't allowed today) whether we  
have

  any preference for making that change now or later.

 I think we should definitely add this to any future versions of the
 spec. In fact, authors could actually start using multiple localized
 author elements today and have them work in the future.

 If it is ok with you, we will add this to a future version of the  
spec?


Notwithstanding the above, given that if you do add localised versions  
the

required behaviour is clear in v1
processing, I can live with that if the group decides to take that
approach.

Pity though. Turns out we're not infallible yet ;)
It's amazing the things one finds when people actually start using  
stuff we specify :)











--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [widgets] WARP usability issue

2011-05-12 Thread Charles McCathieNevile
On Thu, 12 May 2011 12:27:33 +0200, Marcos Caceres  
marcosscace...@gmail.com wrote:



Hi,

The following rule is too restrictive in WARP:

If origin is not a valid IRI, *if it has components other than scheme
and iauthority*, if it has no host component, or if it has a iuser
info component, then this element is in error and the user agent must
ignore this element.

... While I
was at Opera working on extensions, we noticed in the Opera Extensions
catalog that people were doing all sorts of interesting things with
WARP declarations (e.g., adding /* and other things assuming some
kind of pattern matching).

Anyway, an easy solution is to simply ignore any / or simply ignore
all but the scheme and iauthority.

WDYT?


At a minimum. I suspect there are use cases for actually allowing paths to  
be a real part of the access statement, but I haven't thought hard about  
it yet.


cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [widgets] localizing author

2011-05-04 Thread Charles McCathieNevile

On Wed, 04 May 2011 18:29:50 +0200, Marcos Caceres
marcosscace...@gmail.com wrote:


Hi,

I just realised that I actually localise my own name...
But I cannot do that in config.xml. Likewise, I would
like to localise the href for me which would be possible if I could
localise the author element but isn't at the moment.


Yes, this was a mistake.


If we were at REC I would suggest this go into an erratum...


I don't know if this is too late for the current version, in which case
please log it as an issue for the future.


I think it is too late for this version. We have runtimes now at 99% and  
even 100% conformance and adding this would make most runtimes  
non-conforming. I think its more important now to push this spec to REC  
and address these kinds of cases in a future version of the spec.


Do we have a test for this? I propose that we allow our run-time (and  
other implementations, such as the validation used by Opera stores) to  
localise author, and if that makes us non-conforming we're letting good be  
an enemy of better (and the argument that we have conformant run-times  
then looks weaker). If we don't have a test for it, then we know there is  
a requirement in our spec that isn't tested anyway.


In paticular, since we have at least one live product (addons.opera.com  
submission process) that validates against the existing schema, we have  
the choice of either supporting the spec or supporting best practice here.  
What would you prefer us to do?



Changing it to allow localisation would mean a change to the schema -
and at least to Opera's implementation. I haven't yet checked (I only
realised I want to do this but it isn't allowed today) whether we have
any preference for making that change now or later.


I think we should definitely add this to any future versions of the  
spec. In fact, authors could actually start using multiple localized  
author elements today and have them work in the future.


If it is ok with you, we will add this to a future version of the spec?


Notwithstanding the above, given that if you do add localised versions the  
required behaviour is clear in v1
processing, I can live with that if the group decides to take that  
approach.


Pity though. Turns out we're not infallible yet ;)

cheers

--
Charles McCathieNevile  Opera Software, Standards Group
  je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Proposal for a web application descriptor

2011-05-02 Thread Charles McCathieNevile
On Mon, 02 May 2011 10:04:58 +0200, Simon Heckmann  
si...@simonheckmann.de wrote:


There is a new version of the proposal out:  
http://www.simonheckmann.de/proposal/draft2


You're thinking along very similar lines to the way we are thinking inside  
Opera about this problem, in terms of UI.


However, I'm not so sure about having an object that authors can interact  
with for permissions. While the positive side is always good, letting  
malicious authors into this is known to be a major problem.


Have you seen the work done by the Web Security Context group?  
http://www.w3.org/TR/wsc-ui/


cheers

Chaals


Am 29.04.2011 um 15:33 schrieb Simon Heckmann:


Hello everyone,

I have read a lot in the last month about the future of html and web  
applications and I am very impressed by the progress this makes.  
However, I have come across some thing that annoys me: Permissions. I  
know they are important and I know they are needed but currently I find  
this quite inconvenient. And with more and more permissions coming up  
this might get worse so I spent some time thinking about it.


I have written a short document covering my proposal:  
www.simonheckmann.de/download/Proposal.pdf (PDF, 3 pages, ~200KB) or  
www.simonheckmann.de/proposal/ (HTML version).


It should just take only a few minutes to read and includes examples  
and screenshots. I am really looking forward to hearing your thoughts  
on this. Please feel free to share this idea with whomever you want to.  
If you think I should post this proposal somewhere else please say so.


Kind regards,
Simon Heckmann





--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Model-driven Views

2011-05-01 Thread Charles McCathieNevile
On Sat, 23 Apr 2011 02:35:53 +0200, Rafael Weinstein rafa...@google.com  
wrote:



Myself and a few other chromium folks have been working on a design
for a formalized separation between View and Model in the browser,
with needs of web applications being the primary motivator.

Our ideas are implemented as an experimental Javascript library:
https://code.google.com/p/mdv/ and the basic design is described here:
http://mdv.googlecode.com/svn/trunk/docs/design_intro.html. It's not
complete and there are things we're not happy with, but it's
self-consistent enough that you can start to imagine what a full
design might look like.


It looks an *awful* lot like the templating part of Web forms. If you get  
a copy of Opera 9.5 (we removed the code when it became clear that nobody  
else would implement in the last 3 years), you can see that in action with  
the attached code:


div class=entry
 div id=repeatformcontainer
  div id=tem1 repeat=template repeat-min=2 repeat-max=5
   input type=text name=product.[tem1] value=one thing
   button type=removeRemove/button
   button type=move-upMove Up/button
   button type=move-downMove Down/buttonbr /
  /div
  pbutton type=add template=tem1Add/button
 /div
/div

That in turn was a pretty straight rip-off from Xforms which allows the  
same thing with a little more power, and is even closer to what it seems  
you're looking to do.



We hope to get others interested in collecting requirements/use cases
and fleshing out a good solution.


I used it to create simple tools that created templates, and tools that  
used templates for collecting information. My first use case was a  
multilingual international court case (i.e. something that really mattered  
and not just a test), and the ability to easily generate custom systems  
was fantastic.


I greatly appreciated the ability to have models without needing to use  
script - as Steven Pemberton says of Xforms, this makes development much  
faster by reducing complexity in the code, and my experience conincides  
with that perfectly. While I could readily use scripting to develop the  
same systems I would expect the work to take longer and be substantially  
more complex to maintain and debug.


FWIW as far as you do make something script-based, I agree with the  
sentiment expressed that it should work well with existing libraries,  
helping them to reduce the towe-of-babel problem by converging rather than  
increasing it by adding yet another set of libraries to the mixture.



We're starting the discussion here because a few people in this group
from whom we got early feedback felt that it would be most appropriate
place


It probably makes sense to ask the Forms group as well, given that it  
doesn't require much squinting to get to the perspective where you're  
pretty much reinventing a wheel they've already got two of.



and, further, that this work bears some relation to XBL.


As well, at least conceptually.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: new WD of Clipboard API and Events; deadline April 5

2011-04-10 Thread Charles McCathieNevile

comments on a couple of timeless' comments.

On Sun, 10 Apr 2011 18:20:35 +0200, timeless timel...@gmail.com wrote:

On Tue, Mar 29, 2011 at 2:37 PM, Arthur Barstow art.bars...@nokia.com  
wrote:

 http://dev.w3.org/2006/webapi/clipops/clipops.html

If you have any comments or concerns about this proposal, please send  
them

to public-webapps by April 5 at the latest.


Sorry, i've been doing other stuff

[editorial]


Mathematical information
With content such as mathematics, simply copying rendered text and  
pasting it into another application generally leads to most of the  
semantics being lost.


I think math is more appropriate here.


Disagree. In explanatory text the more correct term is clearer. math is  
only american in usage, and avoiding the feeling that it is a typo would  
reduce congitive dissonance without being incorrect.


Calling clearData() empties the system clipboard, or removes the  
specified type of data from the clipboard. See HTML5 for details  
[HTML5].


This has issues. If the user has inserted something the user cares
about into the system clipboard, then allowing a web page to stomp on
it is annoying.  Something needs to protect the user from such web
apps.


Yes - should that comment be on HTML5 though, or alternatively is there a  
reason not to copy it?



The user might paste hidden data which the user is not aware of.


.. not aware of is kinda messy. Also, perhaps hidden data already
indicates the user doesn't know about it?


not realising it is there?

Remove all of the following elements: SCRIPT, APPLET, OBJECT, FORM,  
INPUT, BUTTON, TEXTAREA, SELECT, OPTION, OPTGROUP and comment nodes.  
For all mentioned elements except FORM, also remove all child nodes.


I can imagine doing magical things with a style tag...

However, removing the active value from a select seems suboptimal.

If you see:

State: [  |v]

And use it to get:

State: [ Washington |v]

When you copy it, do you expect:

State:  or State: Washington? I expect the latter, it's
considerably more useful.


Agree.

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [widgets] localizing author

2011-04-09 Thread Charles McCathieNevile
On Sat, 09 Apr 2011 01:22:07 +0200, Scott Wilson  
scott.bradley.wil...@gmail.com wrote:



On 8 Apr 2011, at 09:42, Charles McCathieNevile wrote:


Hi,


I just realised that I actually localise my own name in certain  
languages ... But I cannot do that in config.xml. Likewise, I would  
like to localise the href ...


I guess the workaround at present is to use the element to do something  
like


author王密 (Michelle Wang)/author

... which is not completely ideal as you don't get different hrefs.


Right. It's also not ideal in general, since in a localised presentation  
it makes sense to present the localised information, and this requires you  
to choose which one is going to predominate for e.g. sorting.



I presume the change would be to make Author multiple with xml:lang.


That's what I had in mind.

I think a risk is that developers might reasonably interpret this as  
meaning one author element for each person rather than one author  
element per locale.


Hmm. Given the way localisation works, I think it would take a  
particularly dumb reading of an example to assume that - although I agree  
it is possible, and therefore someone will do it at some point. It would  
also be reasonable if we want to restrict to one author to allow  
internationalised author elements, while maintaining that only the first  
match *for a given language* will be used.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



[widgets] localizing author

2011-04-08 Thread Charles McCathieNevile

Hi,

I just realised that I actually localise my own name in certain languages  
(most particularly to ensure that I get my preferred transliterations when  
I am publishing). But I cannot do that in config.xml. Likewise, I would  
like to localise the href for me which would be possible if I could  
localise the author element but isn't at the moment.


I don't now if this is too late for the current version, in which case  
please log it as an issue for the future. Changing it to allow  
localisation would mean a change to the schema - and at least to Opera's  
implementation. I haven't yet checked (I only realised I want to do this  
but it isn't allowed today) whether we have any preference for making that  
change now or later.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: new WD of Clipboard API and Events; deadline April 5

2011-03-29 Thread Charles McCathieNevile
On Tue, 29 Mar 2011 13:37:46 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


This is a Call for Consensus to publish a new Working Draft of  
Hallvord's Clipboard API and Events spec:


   http://dev.w3.org/2006/webapi/clipops/clipops.html


Please do...

cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Status of Selectors API Level 1 Candidate

2011-02-22 Thread Charles McCathieNevile

Hi folks,

I am putting together an implementation report for Selectors API, but I  
don't have handy access to a copy of Windows/IE9 - if anyone who does has  
the couple of minutes needed to visit

http://dev.w3.org/2006/webapi/selectors-api-testsuite/001.html
http://dev.w3.org/2006/webapi/selectors-api-testsuite/002.html
http://dev.w3.org/2006/webapi/selectors-api-testsuite/003.html

and copy the list of failing tests if any, I would be grateful. (I have  
Safari, Chrome and Firefox as well as Opera handy). Likewise I'd be  
interested in reports about the blackberry browser...


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [FileSystem]: URI format, uses

2011-01-23 Thread Charles McCathieNevile

On Sun, 23 Jan 2011 22:27:56 +0100, Glenn Maynard gl...@zewt.org wrote:


On Sun, Jan 23, 2011 at 1:55 PM, Robin Berjon ro...@berjon.com wrote:


On Jan 22, 2011, at 01:04 , Glenn Maynard wrote:
 Putting family photos in a directory and giving a webpage access to it
 isn't the same as putting them on a publically-accessible webserver.

How so?



One makes them accessible to a single webpage, the other makes them
publically accessible to the entire world.


Not in my experience. People put them somewhere on facebook.com or  
skype.com or something, which makes them accessible through a very small  
number of single webpages. And often without loggin in, those are not  
actually available to anyone.


So as a user, it seems functionally the same except the particular hoops  
for putting things online which are different in every single case.


cheers

Chaals


--
Charles McCathieNevile  Opera Software, Standards Group
  je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [widgets] Removed LocalizableString interface from Widgets API

2011-01-21 Thread Charles McCathieNevile

On Fri, 21 Jan 2011 19:32:57 +0100, timeless timel...@gmail.com wrote:


note that you don't *need* to duplicate html files.

the format allows for one to have json based localizations.

a nokia maps application uses json for localization and could be
easily ported to the widget format.


Could you automatically port it?

I agree with Marcos that it is very valuable to automatically be able to  
move a localised app from one environment (e.g. app store, or dev toolkit)  
to another and know how the localisation works...


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Proposal for a page visibility API

2011-01-20 Thread Charles McCathieNevile
On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske  
komoro...@chromium.org wrote:



Hi all,

There is currently no good way for a web page to detect that it is
completely invisible to the user...


We have implemented something like this for our extensions framework,  
where it is common to have messaging between a tb and the background tab  
where the main extension logic runs. It would also make sense for  
applications that might want to communicate with each other client-side,  
rather than having to pass everything through a server (not so relevant to  
the common Google models, but very relevant to applications that  
explicitly don't want to share with a cloud provider).



Use cases


* An app can provide notifications (using the Web Notification stuff that  
is under developemnt) when it is not visible/focused, but skip them when  
it is to minimise distractions and reduce cognitive load
* An application can (try to) communicate with the currently focused  
application. This is essentially what a whole class of extensions does in  
practice. Enabling it for general HTML would be a step towards making it  
possible to share different functionality extensions. Right now, it would  
rely on out-of-band agreement about how to communicate, but that is  
perfectly feasible in practice. It also introduces a clear requirement for  
a security discussion (see the paper that Art posted recently...).



With these use-cases in mind, there are a number of requirements.

Requirements

* Easy for developers to write scripts that fall back on old behaviors  
for browsers that do not implement this API

* Ability to query the document’s current visibility state
* Events fired when the document transitions between visibility states
* Ability for browser vendors to add new visibility states in the future


Proposed API

document.visible

Returns true if document.visibilityState’s current value is in the set of
visibility states considered to be visible (see the next section for
information on document.visibilityState).  In practice document.visible  
is merely a convenience property that is well-suited to simple uses.

In most implementations, only the “visible” state is considered visible--
although some implementations may consider other values to be visible as
well (for example, an implementation that makes use of nearly-full-size
thumbnail previews may consider “preview” to be a visible state).


The idea that a thumbnail, or popup, can mean that more than one document  
is visible is interesting.


In our API we have getFocused() (which mostly does what it says on the  
box, although certain special tabs don't respond to it)



document.visibilityState

A read-only property that returns a string


It would make sense to have this relate to the ViewModes stuff that was  
originally developed for widgets, no?



visibilitychange

A simple event, fired at the document object immediately after
document.visibilityState transitions between visibility states.  The  
event has a property, fromState, that is set to the value of

document.visibilityState just before it was changed to the current value.
 Note that visibility has nothing to do with whether the document’s  
contents have fully loaded or not, which implies that for any given

visibility transition event, onload may or may not have already fired.


We have tabs.onblur and tabs.onfocus - which is not the same as visibility  
state since it is about more than just rendering, like where input will  
actually go.


Note that our API is currently implemented from a global perspective - you  
can find out what the current tab is, but a tab would have to do that then  
compare to itself, rather than being able to directly query its state. I  
am finding that there are disadvantages to not ahving that information  
readily available.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: The Emperor's New APIs: On the (In)Secure Usage of New Client-side Primitives

2011-01-20 Thread Charles McCathieNevile
On Mon, 17 Jan 2011 14:16:58 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:



Hixie recently mentioned to me the following paper from UC Berkeley that
includes some analysis of the Web Storage [webstorage] and HTML5 Web
Messaging [webmessaging] specs.

The Abstract:

[[
http://www.eecs.berkeley.edu/~sch/w2sp2010ena.pdf

Several new browser primitives have been pro- posed to meet the demands
of application interactivity while enabling security. To investigate
whether applications consistently use these primitives safely in
practice, we study the real-world usage of two client-side primitives,
namely postMessage and HTML5's client-side database storage. We examine
new purely client-side communication protocols layered on postMessage
(Facebook Connect and Google Friend Connect) and several real-world web
applications (including Gmail, Buzz, Maps and others) which use client-
side storage abstractions. We find that, in practice, these abstractions
are used insecurely, which leads to severe vulnerabilities and can
increase the attack surface for web applications in unexpected ways. We
conclude the paper by offering insights into why these abstractions can
potentially be hard to use safely, and propose the economy of
liabilities principle for designing future abstractions. The principle
recommends that a good design for a primitive should minimize the
liability that the user undertakes to ensure application security.
]]

I mention this in case this article identifies issues the specs should
or must address.


Seems to be pretty clear: The design hands some important responsibilities  
to the developer, and developers of extremely-high-profile services from  
extremely-high-profile companies have repeatedly got it wrong. A priori*,  
their suggestions regarding improvements to the way origin checking and  
control over recipients are handled for postMessage seem to make sense...



*I might change that opinion after discussion with security people

Cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [widgets] Removed LocalizableString interface from Widgets API

2011-01-05 Thread Charles McCathieNevile
On Wed, 05 Jan 2011 12:39:05 +0100, Marcos Caceres marc...@opera.com  
wrote:


I have removed LocalizableString interface from the Widgets API  
specification because no one has proposed any use cases for it.


The purpose of the interface was to allow a developer to interrogate an  
attribute of the widget object to find out what language that attribute  
may be written in (if such information was declared via xml:lang in the  
widget's configuration document).


You can't directly query the xml:lang attribute?

cheers

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: FPWD of Web Messaging; deadline November 13

2010-11-12 Thread Charles McCathieNevile

Hi Ian,

On Thu, 11 Nov 2010 18:47:18 +0100, Ian Hickson i...@hixie.ch wrote:


On Thu, 11 Nov 2010, Arthur Barstow wrote:


When WebApps re-chartered last Spring, Web Messaging was added to our
Charter thus there is an expectation we will publish it.


I really don't think that what our charters say sets much of an
expectation. There would be much more concern over them being accurate if
that was the case. :-)


Possibly somewhat true, but we should aim to make it more the case rather  
than less...


On the other hand there is certainly concern raised about what that  
charter does and doesn't say which implies that people already think it  
sets expectations, and there are also concerns raised when those are not  
met. So I suspect it isn't quite as irrelevant as you seem to suggest :)



Assuming we get consensus to publish the FPWD, one way to move forward
with the publication would be for me [and Mike Smith if he's available]
to copy the latest ED and only make required changes to the text to pass
Pub Rules e.g. update the Status of the Doc section. Would that be OK?


Honestly I don't really see what value publishing this draft has. Just
doing it because our charter says to do it is just bureaucracy for
bureaucracy's sake. In any case, I do not think we should publish this
draft without first solving these problems:


There are a couple of bits of value.
1. As Maciej already pointed out, the structure of the Patent Policy means  
there is value in having the FPWD.
2. There are a lot of people who are only tangentially involved in W3C but  
use its specs, and it signals to them that this is still something moving  
actively.
3. It motivates (some of) us to fix the problems with the current approach  
to publishing.


 I'm also a bit concerned that every time we publish anything on the   
TR/ page, we end up littering the Web with obsolete drafts (since the   
specs are maintained much faster than we publish them). I'd really

 rather just move away from publishing drafts on the TR/ page at all,
 if we could update the patent policy accordingly.

...

These problems are technically easy to solve, only politics would prevent
us from addressing them.


Unfortunately politics are real things, not just some imaginary bogeyman  
we use to frighten children away from questioning us.



I'm not really interested in discussing the politics, though.


This, for example, is a political statement (as well as a rational  
sentiment).



The problems are pretty obvious to anyone who's involved
in the development of actively-used Web standards;


The problems for people who are developing web-standards are obvious to  
those people. Unfortunately there are other problems faced by people  
actively using them. Judging from your proposal, they may not be so  
obvious to people who are actively developing standards.


For example, when setting requirements that standards be used in an  
industry (as opposed to mandating particular products), there is a common  
and natural reluctance to simply assume that any changes to the standards  
will be benign, or of little impact. (I would also characterise this as  
common sense). Before a standard is completed (and in the rapid  
development model, usually therefore only of historical interest) it is  
important to refer to it in various ways, and some of those will require  
the ability to reference something where there is faith that it really is  
stable.



IMHO it's just something W3C staff should fix,
there's no need for any discussion really.


While I believe we agree on a lot of what the problem you talk about is,  
and probably in large part on the solution, I think it's a little more  
complex than you make out, and involves more of the 'stakeholder  
community' (yay corporate-speak) with different impacts on different  
parts. So I would be (pleasantly) surprised if no discussion is needed.


Either way, I don't see why it should directly hold up publication.  
Naturally this discussion takes time away from preparing a draft, but  
someone other than you can do that - it isn't very time-consuming or  
complicated work.


The question here is whether there is a strong reason not to publish one -  
i.e. do you object to the Working Group publishing its work according to  
the normal process, or do you just want to point out that there are things  
we really need to improve in that process, and that in any event you  
currently don't have the time to do the mechanical work for publishing?


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: CfC: FPWD of Web Messaging; deadline November 13

2010-11-11 Thread Charles McCathieNevile
On Sat, 06 Nov 2010 12:48:40 +0100, Arthur Barstow art.bars...@nokia.com  
wrote:



Ian, All - during WebApps' November 1 gathering, participants expressed
in an interest in publishing a First Public Working Draft of Web
Messaging [1] and this is a CfC to do so:

   http://dev.w3.org/html5/postmsg/


Opera supports publication.

cheers


This CfC satisfies the group's requirement to record the group's
decision to request advancement.

By publishing this FPWD, the group sends a signal to the community to
begin reviewing the document. The FPWD reflects where the group is on
this spec at the time of publication; it does not necessarily mean there
is consensus on the spec's contents.

As with all of our CfCs, positive response is preferred and encouraged
and silence will be assumed to be assent.

The deadline for comments is November 13.

-Art Barstow

[1] http://www.w3.org/2010/11/01-webapps-minutes.html#item04

 Original Message 
Subject:ACTION-598: Start a CfC to publish a FPWD of Web Messaging
(Web Applications Working Group)
Date:   Mon, 1 Nov 2010 11:35:29 +0100
From:   ext Web Applications Working Group Issue Tracker
sysbot+trac...@w3.org
Reply-To:   Web Applications Working Group WG public-webapps@w3.org
To: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com


ACTION-598: Start a CfC to publish a FPWD of Web Messaging  (Web  
Applications Working Group)


http://www.w3.org/2008/webapps/track/actions/598

On: Arthur Barstow
Due: 2010-11-08





--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: DOM3 Events last call comment

2010-10-21 Thread Charles McCathieNevile

On Fri, 22 Oct 2010 01:38:28 +0200, Doug Schepers schep...@w3.org wrote:

... I'm saying that when DOMActivate was first specced, in 1999-2000,  
there wasn't a clean mobile-web model or significant use of inputs other  
than keyboard and mouse, so click seemed to serve content authors just  
as well as DOMActivate... they didn't need to think as much about an  
abstraction that covered keyboard, mouse, touch inputs, voice, and  
whatever, equally well.


That dynamic has since shifted, and there is more need for an activation  
event... just not necessarily DOMActivate, because of the other problems  
with it.


For what it is worth, DOMActivate is largely my fault (although credit for  
good stuff is due to Rich Schwerdtfeger, Al Gilman, Philippe le Hegaret  
and many others).


The idea at the time was to replace the UI events around at the time with  
a set that were based on intentions rather than hardware-specific  
interactions, because I predicted that the existing problems of people  
building interactions that required a specific hardware paradigm would  
only get worse over time. I think that came true...


In the meantime, abstract intention-based events were added in parallel.  
Given the lack of good interoperable implementation and the ability to  
continue doing what they had done and figuring it more or less worked, Web  
developers didn't take them up, and the hardware-based events became more  
and more common.


Meanwhile, browser vendors and others worked to make the hardware-events  
sort of abstract (being able to fire a click in multiple ways, or adding  
extensions that synthesised events from a non-WIMP interface). So the  
abstract events continued to rot.


(Again, that wasn't a surprise, as discussed at the time).

I understand Doug's suggestion (in its strict relationship to this  
comment) to be give up DOMActivate as a failure, and accept that the  
click event has effectively taken the role, for now. The Web APIs group  
(one of the fore-runners to Web apps) actually resolved that in 2006 at  
its first meeting, and I think we were right at the time and still do.


Meanwhile, there is now momentum to specify a better approach to events,  
and make it work. I think that deserves support as the best way to use our  
energy to get something better.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: Fwd: Re: CfC: publish a new WD of Progress Events; deadline October 14

2010-10-07 Thread Charles McCathieNevile
On Thu, 07 Oct 2010 20:13:22 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:



  Below is  a +1 below from Jonas (fwd'ed here with his permission).

I'll add +1 too.


Likewise Opera supports this.

cheers


 Original Message 
Subject: 	Re: CfC: publish a new WD of Progress Events; deadline October  
14

Date:   Thu, 7 Oct 2010 19:59:59 +0200
From:   ext Jonas Sicking jo...@sicking.cc
To: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com



I agree to this.

On Thu, Oct 7, 2010 at 10:44 AM, Arthur Barstowart.bars...@nokia.com   
wrote:
   Anne and Chaals suggested WebApps publish a new Working Draft of  
Progress

 Events so this is a Call for Consensus (CfC) to do so:

   http://dev.w3.org/2006/webapi/progress/

 If you have any comments or concerns about this proposal, please send  
them

 to public-webapps by October 14 at the latest.

 As with all of our CfCs, positive response is preferred and encouraged  
and

 silence will be assumed to be assent.

 -Art Barstow








--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



Re: [progress-events] Update

2010-10-05 Thread Charles McCathieNevile
On Tue, 05 Oct 2010 19:36:27 +0200, Anne van Kesteren ann...@opera.com  
wrote:


Thanks for taking this over Anne.

On Tue, 05 Oct 2010 19:31:12 +0200, Olli Pettay  
olli.pet...@helsinki.fi wrote:

May I ask why you think the interface member names are terrible?


I should probably have left out that comment. It is just that they are  
inconsistent — lengthComputable vs total — and seem to imply a specific  
kind of process — loaded. I would have preferred hasMax, value, and max  
/ hasTotal/totalKnown, current, and total or some such. Anyway, changing  
this is not worth it.


Right. I am not overly fond of the names either. As I recall, they were  
copied from SVG where people were actually using this already, to reduce  
incompatibility.


I agree that changing them is probably not worth the effort (or the  
bike-shedding of *exactly* what new names would be the best... I would  
vote for Sarah, John, Stuart, and Mary, because they're nice names and if  
you have a cartoon in mind of the different characters with their  
different functions they are as memorable as anything else. Which is to  
say, not actually all that much more intuitive in the grand scheme of  
things).


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



  1   2   3   >