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
FYI: I buffed up the explainer to conform to PubRules:
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
:DG
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.
--
Anne van Kesteren
http://annevankesteren.nl/
During WebApps' May 1 f2f meeting, a proposal was made [1] to stop work
on the From-Origin spec [2] and this is a Call for Consensus to do do.
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
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
On Wed, May 2, 2012 at 10:00 AM, 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
On Wed, 2 May 2012, Tab Atkins Jr. wrote:
So you're blocking the resolution on Process grounds? ^_^
Not blocking anything, I am just baffled by the concept that we need to
agree to tell people the truth, and by the concept that if we agree to not
work on something, we have to do more work
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
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
As discussed during WebApps' May 1 f2f meeting [2], the Gamepad spec 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/gamepad/raw-file/tip/gamepad.html
This CfC satisfies the group's requirement to record
As discussed during WebApps' May 1 f2f meeting [2], the Pointer Lock
spec 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/pointerlock/raw-file/tip/index.html
This CfC satisfies the group's requirement to record
As discussed during WebApps' May 1 f2f meeting [2], the Shadow DOM spec
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/spec/shadow/index.html
This CfC satisfies the group's requirement
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
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
:
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
As discussed during WebApps' May 1 f2f meeting [2], the Input Method
Editor (IME) spec 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/ime-api/raw-file/tip/Overview.html
This CfC satisfies the group's
As discussed during WebApps' May 1 f2f meeting [2], the Screen
Orientation spec 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/screen-orientation/raw-file/tip/Overview.html
This CfC satisfies the group's
As discussed during WebApps' May 1 f2f meeting [2], the URL spec is
ready for a First Public Working Draft (FPWD) publication and this a
Call for Consensus (CfC) to do so. Mike agreed to prepare the spec for
publication using the following draft:
http://dvcs.w3.org/hg/url/raw-file/tip
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.
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
On Tue, 1 May 2012, Arthur Barstow 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.
If this CfC passes, the spec will be republished as a WG Note (as was
done with other
for the CR will be the same as that used for the other
widget specs, namely that two or more implementations must pass each
test case.
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
Now that the normative references for the Widget Interface spec have
advanced and we have documented the spec only uses stable features of
HTML5 [1], the Widget Interface is ready for publication as a Proposed
Recommendation. As such, this is Call for Consensus to publish a PR of
this spec
for Consensus to publish a new LCWD with these bugs open, using
the latest ED as the basis http://dev.w3.org/html5/eventsource/.
This CfC satisfies the group's requirement to record the group's
decision to request advancement for this LCWD. Note the Process
Document states the following regarding
On Mar 30, 2012, at 2:25 PM, ext Eric U wrote:
On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow
art.bars...@nokia.com wrote:
Hi All - the publication of the File API LC was delayed because of
some logistical issues for Arun as well as some additional edits
he intends to make.
This
On Mar 30, 2012, at 2:25 PM, ext Eric U wrote:
On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow art.bars...@nokia.com wrote:
Hi All - the publication of the File API LC was delayed because of some
logistical issues for Arun as well as some additional edits he intends to
make.
This delay
and this is a Call for Consensus to agree on this text. If this CfC passes, the text will be added to the top of the Recommendations as was done with [D2V]: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/att-0044/warnings.htmlDaniel, Peter - please note the CSS WG is mentioned in the proposed text
During the comment period for the March 13 LCWD of Web Workers, no comments
were submitted nor were any new bugs filed. The Worker bug list contains the
same 2 bugs that were present when the CfC for LC was started (14086 which is
marked as an enhancement and 14214 which is editorial
During the comment period for the March 13 LCWD of HTML5 Web Messaging, no
comments were submitted nor were any new bugs filed. This spec's bug list
contains the same bug that was present when the CfC for LC was started (13686
which is a request for a non-normative example). The latest ED
Arthur Barstow:
All - If you have any comments or concerns about this proposal, please
send them to public-webapps@w3.org mailto:public-webapps@w3.org by
April 2 at the latest.
April 18?
+1 to the warnings, I think they're worded well and useful.
On Apr 4, 2012, at 8:00 PM, ext Cameron McCormack wrote:
Arthur Barstow:
All - If you have any comments or concerns about this proposal, please
send them to public-webapps@w3.org mailto:public-webapps@w3.org by
April 2 at the latest.
April 18?
Ooops - yes, April 18!
* Arthur Barstow wrote:
Msger's (Mozilla) proposed text is in the following document and this is
a Call for Consensus to agree on this text. If this CfC passes, the text
will be added to the top of the Recommendations as was done with [D2V]:
http://lists.w3.org/Archives/Public/public-webapps
spec have been addressed and since there are no open bugs, this is a Call for
Consensus to publish a LCWD of the File API spec using the latest ED as the
basis:
http://dev.w3.org/2006/webapi/FileAPI/
This CfC satisfies the group's requirement to record the group's decision to
request
have been addressed and since there are no open bugs, this is a Call
for Consensus to publish a LCWD of the File API spec using the latest ED as
the basis:
http://dev.w3.org/2006/webapi/FileAPI/
This CfC satisfies the group's requirement to record the group's decision
to request
On 02/15/2012 10:09 AM, Vincent Scheib wrote:
Mounir, I ran into the same confusion regarding how does the API expose
locking?. May I suggest that you explicitly state in the abstract that
the API is pending?
I just updated the draft so the locking part is now part of it.
Cheers,
--
Mounir
Great!
Am 30.03.12 11:28 schrieb Mounir Lamouri unter mou...@lamouri.fr:
On 02/15/2012 10:09 AM, Vincent Scheib wrote:
Mounir, I ran into the same confusion regarding how does the API expose
locking?. May I suggest that you explicitly state in the abstract that
the API is pending?
I just
After the start of this CfC, Ms2ger announced [1] that he fixed several
bugs in the Infraware's Web Storage tests [2] and his changes were made
directly in their submission directory rather that the 'approved'
directory. Consequently, this CfC is modified as such:
1. The directory of tests
.
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
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
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
the approved tests are now ready for WG wide review.
Since Web Storage is now in CR [CR], this is a Call for Consensus to
assess whether these approved tests should be considered sufficient to
meet the CR's exit criteria [ExitCriteria].
Assuming this CfC passes, my expectation on the next step
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
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
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
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
Marcos would like to publish a Last Call Working Draft of the Widget
Updates spec and this is a CfC to do, using the following document as
the basis:
http://dev.w3.org/2006/waf/widgets-updates/pub/
This CfC satisfies the group's requirement to record the group's
decision to request
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
All - WebAppSec has agreed to publish a LCWD of CORS. Since this spec is
a joint deliverable with WebApps, we are now having a short CfC to
publish this LC.
If you have any comments or concerns about this CfC, please send them to
public-webapps@w3.org by March 9 at the latest. Positive
/widgets-uri/
If you have any comments or concerns about this CfC, please send them to
public-webapps@w3.org by March 9 at the latest. Positive response is
preferred and encouraged and silence will be assumed to be agreement with the
proposal.
+1
--
Robin Berjon - http://berjon.com
The Web Messaging spec has one open bug [13686] and it is a request for
a non-normative example. I'd like to get this spec moving on the REC
track so this is a Call for Consensus to publish a new LCWD using
http://dev.w3.org/html5/postmsg/ as the basis.
This CfC satisfies the group's
The Web Messaging spec has two open bugs: [14086] is marked as an
enhancement and [14214] is a minor editorial comment. I'd like to get
this spec moving on the REC track so this is a Call for Consensus to
publish a new LCWD using http://dev.w3.org/html5/workers/ as the basis.
This CfC
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.
Kind regards,
Marcos
Hi,
is there any reason why the File API: Writer and File API: Directories and
System specifications still use FileException/FileError-Objects? The File API
uses DOM4's DOMException/DOMError [1].
Best regards,
Felix
[1] http://dev.w3.org/2006/webapi/FileAPI/#ErrorAndException
Yeah, the reason is that Arun's more on-the-ball than I am. I'll be
updating the spec quite soon, I hope.
On Mon, Feb 27, 2012 at 2:35 AM, Felix-Johannes Jendrusch
felix-johannes.jendru...@fokus.fraunhofer.de wrote:
Hi,
is there any reason why the File API: Writer and File API: Directories
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
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
Comments and bugs submitted during the pre-LC comment period for File
API spec have been addressed and since there are no open bugs, this is a
Call for Consensus to publish a LCWD of the File API spec using the
latest ED as the basis:
http://dev.w3.org/2006/webapi/FileAPI/
This CfC satisfies
Given the various issues and questions raised about this proposal, I
don't support adding it to WebApps (at least not now).
I do support work in this area and agree a new CG is one possibility. It
also seems like the work could be argued as in scope for the native Web
apps CG which includes
Hi Arthur,
In the Screen Orientation API draft, I don't see any references to
locking. Is this by design?
Thanks,
Paul
Am 06.02.12 13:19 schrieb Arthur Barstow unter art.bars...@nokia.com:
Given the positive responses to this CfC, the Screen Orientation API has
now been added to the Additions
In the Screen Orientation API draft, I don't see any references to
locking. Is this by design?
It's in the abstract:
The Screen Orientation API's goal is to provide an interface for web
applications to be able to read the screen orientation state, to be
informed when this state changes and to be
...@gmail.com
Cc: Paul Bakaus pbak...@zynga.commailto:pbak...@zynga.com,
public-webapps@w3.orgmailto:public-webapps@w3.org
public-webapps@w3.orgmailto:public-webapps@w3.org
Betreff: Re: CfC: Proposal to add web packaging / asset compression
I would agree with this. My initial thought when reading
I'm not particularly set on one direction to solve this problem. I just
want to get it solved, and if SPDY, along with a much improved
programmatically controllable appCache is the preferred solution, let's
go for it.
I, along with probably plenty of other web developers, am still
inexperienced
On 02/15/2012 04:29 AM, Tobie Langel wrote:
In the Screen Orientation API draft, I don't see any references to
locking. Is this by design?
It's in the abstract:
The Screen Orientation API's goal is to provide an interface for web
applications to be able to read the screen orientation
Cool, thanks for the update!
Am 15.02.12 13:21 schrieb Mounir Lamouri unter mou...@lamouri.fr:
On 02/15/2012 04:29 AM, Tobie Langel wrote:
In the Screen Orientation API draft, I don't see any references to
locking. Is this by design?
It's in the abstract:
The Screen Orientation API's
Mounir, I ran into the same confusion regarding how does the API expose
locking?. May I suggest that you explicitly state in the abstract that the
API is pending?
On Wed, Feb 15, 2012 at 8:34 AM, Paul Bakaus pbak...@zynga.com wrote:
Cool, thanks for the update!
Am 15.02.12 13:21 schrieb
Hi everybody,
This is a proposal to add a packaging format transparent to browsers to the
charter. At Zynga, we have identified this as one of our most pressuring
issues. Developers want to be able to send a collection of assets to the
browser through a single request, instead of hundreds.
On 2/14/2012 1:24 AM, Paul Bakaus wrote:
window.loadPackage('package.webpf', function() {
var img = new Image();
img.src = package.webpf/myImage.png;
})
Or alternatively, with a local storage system (I prefer option one):
window.loadPackage('package.webpf', function(files) {
Though I don't know what shape this will take, I think this is
definitely worth vigorous research and discussion.
Without trying to derail this effort, I am somewhat interested in how
this thinking can be applied to Web Components, since components may
want to be coupled with various assets.
:DG
I have the itching feeling that a Community Group might be the right place to
do the exploratory work. Once there is a solid proposal for standardization
(and hopefully a prototype), it should be brought back here.
To start a community group:
http://www.w3.org/community/
And since we are
On Tue, Feb 14, 2012 at 1:24 AM, Paul Bakaus pbak...@zynga.com wrote:
Hi everybody,
This is a proposal to add a packaging format transparent to browsers to the
charter. At Zynga, we have identified this as one of our most pressuring
issues. Developers want to be able to send a collection of
I would agree with this. My initial thought when reading the proposal was
SPDY as well.
That said, there is ongoing discussion about improving the app-cache that
is also relevant[1]. I am also planning on opening a discussion about
programmatic control of a cache (probably not piggy-backed onto
This is a Call for Consensus to publish a new WD of the Clipboard API
and events spec using the latest ED as the basis (Hallvord has not yet
prepared it for publication in /TR/):
http://dev.w3.org/2006/webapi/clipops/clipops.html
Agreement to this proposal: a) indicates support for
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
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
will there be liaison/participation with I18N Core WG on this work?
On Wed, Feb 8, 2012 at 5:29 AM, Charles McCathieNevile cha...@opera.comwrote:
Hi,
thanks to Mike and the Google guys, we have http://dvcs.w3.org/hg/ime-api/
Hi Glenn,
@2012-02-08 08:33 -0700:
will there be liaison/participation with I18N Core WG on this work?
I've already given Richard Ishida and Felix Sasaki a heads-up about it. I
believe Richard is planning to propose an agenda item for it on the i18n WG
call today. But anyway certainly there
thanks, i was just checking; i'll defer to Addison and the editor of the
proposed work to handle the details
On Wed, Feb 8, 2012 at 9:02 AM, Michael[tm] Smith m...@w3.org wrote:
Hi Glenn,
@2012-02-08 08:33 -0700:
will there be liaison/participation with I18N Core WG on this work?
I've
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
Given the positive responses to this CfC, the Screen Orientation API has
now been added to the Additions Agreed section of charter changes wiki
http://www.w3.org/2008/webapps/wiki/CharterChanges.
On 1/30/12 8:26 AM, ext Charles McCathieNevile wrote:
OK, since I was planning to have the charter
the case, we
need a home for it.
(If it turns out that it does have a home and I simply couldn't figure out
which one it is, then please consider this CfC as null and void.)
We have a draft, I'm pretty sure that I've seen implementer interest, and it's
very obvious that there's a lot of developer
On Tue, 31 Jan 2012 18:07:39 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
On 1/31/12 11:04 AM, ext Robin Berjon wrote:
We have a draft
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
I'm pretty sure that I've seen implementer interest, and it's very
obvious that there's a
On Thu, Feb 2, 2012 at 11:37 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 31 Jan 2012 18:07:39 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
On 1/31/12 11:04 AM, ext Robin Berjon wrote:
We have a draft
On Fri, 03 Feb 2012 00:09:44 +0100, Glenn Adams gl...@skynav.com wrote:
On Thu, Feb 2, 2012 at 11:37 AM, Anne van Kesteren ann...@opera.com
wrote:
I'm fine with publishing this through WebApps.
is there any reason this should be done as part of CSSOM View? i notice a
to do listed at [1] as:
On Thu, Feb 2, 2012 at 4:14 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 03 Feb 2012 00:09:44 +0100, Glenn Adams gl...@skynav.com wrote:
On Thu, Feb 2, 2012 at 11:37 AM, Anne van Kesteren ann...@opera.com
wrote:
I'm fine with publishing this through WebApps.
is there any reason
We support adding orientation lock to the charter.
--tobie
Zynga wholeheartedly supports screen orientation locking!
Am 30.01.12 14:26 schrieb Charles McCathieNevile unter
cha...@opera.com:
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
I can help if needed, though I have never been an editor before.
Kenneth
On Tue, Jan 31, 2012 at 3:22 PM, Mounir Lamouri mou...@lamouri.fr wrote:
On 01/31/2012 03:19 PM, Arthur Barstow wrote:
Robin agreed to take the lead on testing but I don't see a commitment
for the Editor role.
If
On 01/31/2012 05:04 PM, Robin Berjon wrote:
Fullscreen API
Support.
We support this as well.
--tobie
On 1/31/12 5:51 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
I support having that as well. Very much needed and requested, and
implemented by, I believe, Gecko and WebKit
On Tue, Jan 31, 2012 at 5:47 PM, Ms2ger ms2...@gmail.com wrote:
On 1/31/12 11:04 AM, ext Robin Berjon wrote:
We have a draft
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
I'm pretty sure that I've seen implementer interest, and it's very obvious that
there's a lot of developer interest in it. My understanding is that it has an
editor.
It
On Jan 31, 2012, at 18:07 , Arthur Barstow wrote:
On 1/31/12 11:04 AM, ext Robin Berjon wrote:
We have a draft
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
I'm pretty sure that I've seen implementer interest, and it's very obvious
that there's a lot of developer interest in
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
I support, but I think it tied into the device adaptions spec, fullscreen
and also splash screen support.
Kenneth
On Mon, Jan 30, 2012 at 2:26 PM, Charles McCathieNevile cha...@opera.comwrote:
OK, since I was planning to have the charter up today, let's have a quick
call for consensus on
On 01/30/2012 02:26 PM, Charles McCathieNevile wrote:
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
, 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
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
On Jan 23, 2012, at 12:39 PM, Arthur Barstow wrote:
On 1/23/12 12:17 PM, ext Charles McCathieNevile wrote:
On Fri, 20 Jan 2012 18:37:35 +0100, Glen Shires gshi...@google.com wrote:
2. WebApps provides a balanced web-centric view for new JavaScript APIs.
The XG group consisted of a large
/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
On Jan 24, 2012, at 7:50 AM, Dan Burnett wrote:
On Jan 23, 2012, at 12:39 PM, Arthur Barstow wrote:
On 1/23/12 12:17 PM, ext Charles McCathieNevile wrote:
On Fri, 20 Jan 2012 18:37:35 +0100, Glen Shires gshi...@google.com wrote:
2. WebApps provides a balanced web-centric view for new
Art, Charles,
We are very pleased to see the positive responses to the CfC.
In particular, we believe this meets all the criteria that Art suggested in
[1].
1. Relatively clear scope of the feature(s)
The scope is well-defined and bounded. [1] [2]
2. Editor commitment(s)
Google
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
501 - 600 of 995 matches
Mail list logo
