:55 PM
To: Webapps
Cc: Sunava Dutta; Travis Leithead
Subject: Re: Agenda+ DOM3 Events (was: Agenda and logistics...)
On Wed, 25 Jun 2008 05:32:20 +0200, Doug Schepers [EMAIL PROTECTED] wrote:
At the upcoming F2F, I would also like to spend an hour or two
discussing DOM3 Events, if we find
Sorry I have a family commitment at this time today and won't be able to make
it.
I also had some urgent business that has come up--please also have my regrets.
-Travis
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Emmons
Sent: Wednesday, August 06, 2008 9:13 AM
To: public-webapps@w3.org
Subject: RE: Agenda: DOM3 Events
a shadowed property on the DOM, but never actual
delete the underlying built-in property. I wondered if WebIDL makes any
mention of the behavior of ECMAScript operators on host objects and how they
should behave?
- Travis Leithead - OM Program Manager - Internet Explorer
Seems as if this startMouseCapture() and stopMouseCapture() could be
implemented by re-using DOM event's capture phase by adding event handlers to
the capture phase of the #document and then firing those events directly on
the target node.
In fact, I thought this was one of the primary
Excellent.
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Charles McCathieNevile
Sent: Monday, February 02, 2009 7:39 AM
To: WebApps WG
Subject: restarting DOM 3 Events calls
Hi,
It would be nice to get DOM 3 Events rolling
I went through the test results in IE8 just to see what the breakdown was and
thought I'd pass this info along. I appreciate the thoroughness of these tests,
though it bothers me a bit that we get hammered because of the various WebIDL
binding issues (e.g., IE8's exception can't be mapped to
My regrets for missing this. Thanks for sending out the notes.
I will be unable to make the next meeting on the 18th as well--if any of you
will be attending MIX'09, perhaps I'll see you there.
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
Carmelo and I waited for awhile, but ultimately send our regards. Hopefully
we'll be able to meet up with the rest of the group next week.
PS. Doug, please update the editor's draft!
Proposal for event iterator
Following up on last year's discussion on adding support for querying DOM
elements about already registered event handlers:
Travis Leithead wrote on Apr 09, 2008; 08:07pm
In considering a design for the event iterator (allow devs to
enumerate what events have been
Anne, are you building tests for these assertions as you work out some of these
details (or more specifically, are you collecting them in a public place)?
(I didn't see anything here:
http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest/ )
Thanks,
-Travis
-Original Message-
From:
http://www.w3.org/2008/webapps/track/actions/375
As part of this action, I've taken two approaches to answer the question: what
are the guiding principles for event usage?
1. Circumstances when an author would use an event
2. Principles behind when a new feature should consider
Adding WWW-DOM to widen the audience a bit.
Having the attributes not be read only and allowing their modification
before the Event is dispatched seems better to me. But changing this for
DOM Events in general seems like a larger issue for discussion.
Note that this is how it works in IE
Cameron et al.,
I have a couple pieces of feedback on this draft.
Let me start by saying that this is a wonderful spec-much needed by the working
group, and much appreciated by the IE team in relation to the additional
clarity it provides for interpretation of other specs.
Before I launch
relevant. The meta-point is that it's more about being able to improve
the utility of extending or replacing the behavior of these properties.
-Travis
-Original Message-
From: Shiki Okasaka [mailto:sh...@google.com]
Sent: Wednesday, September 02, 2009 7:10 AM
To: Travis Leithead
Cc
Based on the last round of feedback [1], I've updated the proposal for
Selector-based mutation events (which I keep calling fast mutation events
for some reason...). Doug, I'm sure you're hard at work on a better acronym...
In this edition, I expanded the background sections and enumerated many
Hi webapps and DOM events folks!
(Cross-posting this)
This topic came up internally on the IE team, and we thought it would be
noteworthy to put this question before the working groups in hopes of getting a
spec clarification made.
The question is: for XHR and other non-DOM related objects
Hey folks, just wondering what the justification behind the current
{DontDelete} semantics are in WebIDL 4.4 [1] and 4.5 (second bullet) [2]. When
our IE9 binding ported this to ES5, it translated to configurable: false,
which completely destroyed the ability to set accessors on the interface
this is too restrictive, especially forward-looking
considering how much the DOM is changing and evolving.
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, August 03, 2010 5:22 PM
To: Travis Leithead
Cc: Cameron McCormack; Sam Weinig (wei...@apple.com); public
For IE9, we've adopted this attribute as well [msDoNotCheckDomainSecurity]
It has different meanings for different types of properites (fields vs.
accessors) and causes some proxies to be setup, but generally speaking it does
allow requests for the property to go through without an access
Thanks for your response Ian. I also appreciate your quick response to the bug;
I believe I can resolve it now :-)
-Original Message-
From: Ian Hickson [mailto:i...@hixie.ch]
Sent: Thursday, January 20, 2011 4:44 PM
To: Travis Leithead
Cc: public-webapps; Adrian Bateman
Subject: Re
Drew Wilson (atwil...@google.com) wrote:
I think this alternate lifetime model is practically unimplementable in a
world where
workers and pages live in multiple processes. The reason is that the linkage
between
nodes in your graph depends on reachability of ports which can't really be
(This time before the deadline :)
Microsoft has the following additional feedback for this Last Call of Web
Workers.
We are concerned about the privacy implications we discovered when reviewing
the current web workers editor's draft in its treatment of shared workers [1].
Specifically, the
-and-privacy-introducing-tracking-protection-v8.aspx
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Wednesday, April 20, 2011 6:55 PM
To: Andrew Wilson
Cc: Tab Atkins Jr.; Travis Leithead; Arthur Barstow;
public-webapps-requ...@w3.org; Adrian Bateman; public-webapps
Subject
The editors' draft of the typed array spec has been updated with a
strawman proposal for this zero-copy, transfer-of-ownership behavior:
http://www.khronos.org/registry/typedarray/specs/latest/
Feedback would be greatly appreciated. For the purposes of keeping the
conversation
-of-ownership? Or a new configuration option for
postMessage ( { transferOwnership: true } )?
-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Thursday, June 02, 2011 9:02 AM
To: ext Jonas Sicking; Kenneth Russell; Ian Hickson
Cc: Travis Leithead; g
From: Andrew Wilson [mailto:atwil...@google.com]
Sent: Friday, June 03, 2011 2:15 PM
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking
jo...@sicking.ccmailto:jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell
k...@google.commailto:k...@google.com wrote:
On Fri, Jun 3, 2011 at
Honestly, there's something about this whole discussion that just doesn't feel
right.
I looks like we're trying to graft-in this new concept of transfer of ownership
into the existing postMessage semantics (i.e., object cloning). Any way I try
to make it work, it just looks like peaches
From: Kenneth Russell [mailto:k...@google.com], Sent: Thursday, June 09, 2011
11:15 PM
On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
Honestly, there's something about this whole discussion that just
doesn't feel right.
I looks like we're trying
From: Arthur Barstow [mailto:art.bars...@nokia.com]
On Jun/8/2011 5:24 PM, ext Kenneth Russell wrote:
My understanding is that we have reached a proposal which respecifies
the ports argument to postMessage as an array of objects to
transfer, in such a way that we:
- Maintain 100% backward
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12947
-Original Message-
From: Travis Leithead
Sent: Monday, June 13, 2011 10:49 AM
To: Arthur Barstow
Cc: Andrew Wilson; Glenn Maynard; Jonas Sicking; Dmitry Lomov; David Levin; ben
turner; public-webapps@w3.org; Ian Hickson; ext
From: Ian Hickson [mailto:i...@hixie.ch]
Sent: Tuesday, June 14, 2011 12:19 PM
On Wed, 9 Mar 2011, Adrian Bateman wrote:
Based on our understanding of the web worker lifetime model (Section
4.4), dedicated workers are allowed to enter into an orphaned state
where they have a message port that
On 08/11/2011 03:44 AM, Rafael Weinstein wrote:
Although everyone seems to agree that mutations should be delivered
after the DOM operations which generated them complete, the question
remains:
When, exactly, should mutations be delivered?
The four options I'm aware of are:
1)
I support publishing this LC#2. I will do a second review of the updated text
to see if Microsoft has any further LC comments. Thanks!
-Original Message-
From: public-script-coord-requ...@w3.org [mailto:public-script-coord-
requ...@w3.org] On Behalf Of Arthur Barstow
Sent: Friday,
Thanks! We'll see about getting these updated...
From: David Levin [mailto:le...@google.com]
Sent: Monday, September 19, 2011 6:33 PM
To: Adrian Bateman
Cc: Web Applications Working Group WG (public-webapps@w3.org); Israel Hilerio;
Travis Leithead; Brian Raymor; Kris Krueger
Subject: Re: New
Is there a comment tracking doc for this LC (e.g., lc2)?
-Original Message-
From: public-script-coord-requ...@w3.org [mailto:public-script-coord-
requ...@w3.org] On Behalf Of Arthur Barstow
Sent: Tuesday, October 11, 2011 4:37 AM
To: public-script-coord; public-webapps
Subject: Reminder:
This has been an interesting debate, but I'm still a little confused with the
outcome (if any).
Will someone summarize the current position on these issues:
1. Should find() and findAll() follow style scoped rules or not and how?
2. How does the presence of :scope affect find() and findAll()
3.
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Monday, November 14, 2011 6:12 PM
For right now, there are two ways you could quickly go that don't conflict
with ES5.1 at all:
1) you can specify that .findAll returns a plain vanilla ECMAScript Array
object.
2) you can define
A new scenario just came to my attention that I thought I might
pose to the list. Given the current same-origin restrictions on
new Worker(), it is problematic for Worker usage by any JS
libraries on a CDN.
A site using a CDN simply provides an absolute URL reference to
the library, and it is
(Cross-post to www-dom for visibility, sorry for dups)
Hey folks,
I'm joining Jacob Rossi to help work on editing the DOM L3 Events spec; I have
some time to address some of the editorial last call comments, and I hope to
move through them all pretty quickly.
I know there are a variety of
-Original Message-
From: Anne van Kesteren [mailto:ann...@opera.com]
It [DOM3 Events] also describes basic concepts such as default actions and
their
effect on cancelable events, trusted events, etc., for which having a
central reference is quite informative.
Except the way it talks
-Original Message-
From: Charles McCathieNevile [mailto:cha...@opera.com]
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
alerts true in Gecko, Chrome, Safari, and Opera. No IE on hand right now...
That
would be consistent with associating the image with the document that the
constructor object is associated with.
alert's true in IE too, FYI.
-Original Message-
From: Simon Pieters [mailto:sim...@opera.com]
Sent: Tuesday, April 10, 2012 5:27 AM
To: Jarred Nicholls
Cc: Jonas Sicking; public-weba...@w3c.org
Subject: Re: Shared workers - use .source instead of .ports[0] ?
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls
Glenn, isTrusted is the indicator that helps the web developer distinguish
between an event fired by the UA, or one fired by JavaScript (e.g.,
dispatchEvent).
From: Glenn Maynard [mailto:gl...@zewt.org]
Sent: Tuesday, April 24, 2012 12:38 PM
To: o...@pettay.fi
Cc: Travis Leithead; public-weba
...@helsinki.fi]
Sent: Tuesday, April 24, 2012 12:23 PM
To: Travis Leithead
Cc: public-weba...@w3c.org; Anne van Kesteren (ann...@opera.com); Jacob
Rossi
Subject: Re: [DOM3 Events/DOM4] re-dispatching trusted events with
initEvent
On 04/24/2012 09:43 PM, Travis Leithead wrote:
Based on my reading of DOM4
Thanks. It looks like IE's implementation missed this detail. I'll see about
having these tests updated shortly.
From: David Levin [mailto:le...@google.com]
Sent: Sunday, May 06, 2012 2:47 AM
To: Travis Leithead
Cc: Adrian Bateman; Web Applications Working Group WG (public-webapps@w3.org
-Original Message-
From: Travis Leithead
Sent: Thursday, March 8, 2012 3:31 PM
Hey folks,
I'm joining Jacob Rossi to help work on editing the DOM L3 Events spec; I have
some time to address some of the editorial last call comments, and I hope to
move through them all pretty
-Original Message-
From: Pablo Garaizar Sagarminaga [mailto:garai...@deusto.es]
Hello,
on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking jo...@sicking.cc
wrote:
This is not yet an official last call, but if you'd like to re-read
the spec and provide additional
I wouldn't mind. I'm on both lists anyway. Schepers originally saw it as a way
of scoping DOM3 Events discussions away from the noise on public-webapps. I'm
not sure that's a real big concern anymore.
From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai
Sent: Tuesday, June 12,
-Original Message-
From: Kang-Hao (Kenny) Lu [mailto:kennyl...@csail.mit.edu]
(12/06/18 22:45), Simon Pieters wrote:
I think we should instead either fix the old API (if it turns out to
not Break the Web) or live with past mistake (if it turns out it
does). To find out whether
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Lachlan would like to publish a new Working Draft of the Selectors API Level 2
spec and this is a Call for Consensus to do so using the following Editor's
Draft as
the basis http://dev.w3.org/2006/webapi/selectors-api2/.
Positive
Note, I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17775
to make this change.
From: wyc...@gmail.com [mailto:wyc...@gmail.com] On Behalf Of Yehuda Katz
Sent: Wednesday, July 11, 2012 9:12 PM
To: Tony Ross
Cc: João Eiras; public-webapps@w3.org
Subject: Re: DOMParser Errors Should Be
Going to a function-based design is typically preferable (especially to making
an attribute non-enumerable). This is the approach taken by getUserMedia.
From: scot...@google.com [mailto:scot...@google.com] On Behalf Of Scott Graham
Sent: Thursday, July 26, 2012 4:02 PM
To: public-webapps@w3.org
From: Lachlan Hunt [mailto:lachlan.h...@lachy.id.au]
I'd like feedback from implementers about how best to address the issue.
The options I can think of:
1. Disallow all comments within the selector for this API. Throw SyntaxError
when they are used.
2. Allow comments, but define that
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org
wrote:
Meh. I think this
Folks, following up on my action item from TPAC 2011 (yeah, I know...), the DOM
Parsing and Serialization Editor's Draft specification has been created!
http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html
A list of active bugs against the spec are being maintained against this
component in
From: Arthur Barstow [mailto:art.bars...@nokia.com]
On 8/29/12 7:55 PM, ext Travis Leithead wrote:
Folks, following up on my action item from TPAC 2011 (yeah, I know...),
the DOM Parsing and Serialization Editor's Draft specification has
been created!
http://dvcs.w3.org/hg
From: gary...@google.com [mailto:gary...@google.com] On Behalf Of Gary
Hi all,
I've written up a brief proposal to enhance the current DOM Level 3
key events by adding USB keycodes.
Here is a link to the proposal document:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
The spec currently says[1]:
The value of the prototype property of an interface object for a
non-callback interface MUST be an object called the interface
prototype object.
At the same time, we have specs like File API defining
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
On 9/21/12 12:39 PM, Travis Leithead wrote:
I believe that firstly, the File API spec needs to be rationalized
against the URL API
They're already there. File API explicitly says that if you support URL
API then you get a normal interface
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On
On Thu, Sep 27, 2012 at 7:00 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
It hasn't been updated in a while, but we're still keen on seeing it
move forward AFAIK:
http://dvcs.w3.org/hg/streams-api/raw-file
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
On Thu, Sep 27, 2012 at 7:42 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
In my observation of the current IE behavior, the Stream is for download
only. XHR gets the data from the server and buffers
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
On 9/28/12 12:38 PM, Travis Leithead wrote:
It seems more important to check for the features of the spec, rather
than spec support in general. I would expect if (URL.createObjectURL) for
example.
You have it backwards. That's checking
the above requirement.
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, September 28, 2012 4:24 PM
To: Cameron McCormack
Cc: Travis Leithead; Boris Zbarsky; public-script-co...@w3.org; public-webapps
Subject: Re: In WebIDL, should having a .prototype on interface objects
From: Rick Waldron [mailto:waldron.r...@gmail.com]
I wasn't specific enough in my original question, but I did note that I
wasn't referring to construction exceptions, so I'm guessing by your response
that you actually _just_ meant testing for constructability. I apologize
for not being
Hallvord, sorry I missed your IRC comment in today's meeting, related to DOM3
Events:
hallvord_ event.key is still a problem child, authors trying
to use it have been complaining both to me and on the mailing
list
Could you point me to the relevant discussions? The only issues
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I expected..
I'm not sure that the use case that these events were originally designed for
(which have been obscured by time), are at all relevant to site
and couldn't detect it, but wanted to be sure.
-Original Message-
From: Hallvord R. M. Steen [mailto:hallv...@opera.com]
Sent: Thursday, November 1, 2012 1:37 PM
To: Ojan Vafai
Cc: Travis Leithead; public-weba...@w3c.org
Subject: Re: Event.key complaints?
Travis wrote:
Hallvord, sorry I
request can be honored by the user agent without script
getting in the way of (and possibly delaying) the action.
From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai
Sent: Thursday, November 1, 2012 4:38 PM
To: Travis Leithead
Cc: Hallvord R. M. Steen; WebApps WG; Ryosuke Niwa
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
On Fri, Nov 23, 2012 at 6:11 PM, Glenn Adams gl...@skynav.com wrote:
As I have pointed out above, W3C specs do not track authorship or
individual contributions to the WG process. If Anne performed his work
as author in
Awesome stuff Gary.
(And I like that we won't need to change the behavior of key or char in your
proposal—that part made me really nervous, since IE has shipped this stuff
since 9, and I know our new Win8 app model is using it.)
I'm planning in the short term to start a new DOM4 Events spec,
...@google.com] On Behalf Of Gary
Kacmarcik (?)
Sent: Friday, November 30, 2012 6:09 PM
To: Travis Leithead
Cc: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org
Subject: Re: Re: Event.key complaints?
On Fri, Nov 30, 2012 at 4:29 PM, Travis Leithead
travis.leith
From: Ian Hickson [mailto:i...@hixie.ch]
On Tue, 17 Jul 2012, Ian Hickson wrote:
My plan is to make it so that cross-origin URLs start cross-origin
workers. The main unresolved question is how to do this in an opt-in
manner. The best idea I've come up with so far is having scripts that
-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Rafael and the other Editors of the HTML Templates spec would like to
publish a First Public Working Draft (FPWD) of HTML Templates and this
is a Call for Consensus (CfC) to do so, using the following ED as the
Jack,
With all due respect, this feedback is a little late. The spec in question is
now at candidate recommendation, and there are multiple interoperable
implementation in existence. While this is not to say that the spec cannot be
changed at this point, I would anticipate that many
I think we should give it another try by including it in our UI Events spec. I
like the idea of adding the static queryKeyCap(code) API to Keyboard events. I
wonder about the name though. A key capability doesn't sound right. Are we
querying for a key's locale name? e.g.,
Having thought about this before, I wonder why we don’t use a producer/consumer
model rather than a transfer of canvas ownership model?
A completely orthogonal idea (just my rough 2c after reading Gregg’s proposal),
is to have an internal frame buffer accessible via a WorkerCanvas API which
could be used to signal that new frames were ready from the
producer—then the main thread would know to pop.
From: Gregg Tavares [mailto:g...@google.com]
Sent: Friday, February 8, 2013 3:14 AM
To: Travis Leithead
Cc: Ian Hickson; Charles Pritchard; Web Applications Working Group WG
Subject: Re
Alex, work on Editing APIs was ongoing in the Community Group
(http://www.w3.org/community/editing/) though their draft is just under a year
old.
Aryeh may have more current info...
From: Alex Mogilevsky [mailto:alex...@microsoft.com]
Sent: Monday, February 18, 2013 8:14 PM
To:
Also, the Stream object lets you pipe the data from to/from Web Workers, which
can be handy in certain scenarios.
From: da...@google.com [mailto:da...@google.com] On Behalf Of Darin Fisher
[snip]
Another thing not to lose sight of is that a Stream abstraction could be useful
as an optimization
Microsoft supports this publication.
-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Thursday, March 21, 2013 9:40 AM
To: public-webapps
Subject: CfC: publish WD of Input Editor Method (IME) API; deadline March
28
This is a Call for Consensus (CfC) to
Thanks for submitting these updates to the Input Method Editor API. I've had an
opportunity to review them and would like to offer some feedback for the spec.
On the IE team, we have also been working on building an IME-related API, but
one geared specifically toward working with the operating
Chaals,
The wiki says the host is eBay with an address given. Is the address still
accurate? If not, will someone who knows the correct address update the wiki?
http://www.w3.org/wiki/Webapps/April2013Meeting
-Original Message-
From: Chaals Nevile [mailto:w...@chaals.com]
Sent:
Ah, good to know. Thanks.
From: Chris Wilson [mailto:cwi...@google.com]
Sent: Wednesday, April 3, 2013 3:15 PM
To: Travis Leithead
Cc: Chaals Nevile; public-webapps WG
Subject: Re: Reminder: Please register for Face to face by Friday
Paypal is in the same building complex with eBay (the address
For the attribute changes, you can use MutationObservers, unless you need to
have the values updated synchronously, in which case, you can always fallback
to Mutation Events or hook the relevant APIs with ES5 defineProperty
overrides…? Generally, I think all the tools you need for notifications
, 2013 11:38 AM
To: Travis Leithead
Cc: Mike Kamermans; public-webapps@w3.org
Subject: Re: [webcomponents] self-documenting component.html files
On Fri, Apr 5, 2013 at 7:29 PM, Travis Leithead travis.leith...@microsoft.com
wrote:
For the attribute changes, you can use MutationObservers, unless you
...@google.com]
Sent: Tuesday, April 02, 2013 4:32 PM
To: Travis Leithead
Cc: hb...@google.com; ko...@google.com; public-webapps
Subject: Re: [IME] Preparing some feedback
Thanks Travis.
We are eager to hear your feedback.
The spec was down scoped to exclude Javascript based IME because we could
Cameron,
There's 50 some-odd bugs under the bugzilla component for WebIDL. Many of them
look like simple editorial fixes that could be applied to the CR draft, but
others are feature requests, or issues related to new features added to the
Second Edition.
Are you currently tracking which bugs
Microsoft supports this.
-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Saturday, April 27, 2013 7:31 AM
To: public-webapps
Subject: CfC: publish FPWD of UI Events; deadline May 4
As discussed during WebApps' April 25 meeting, this is a Call for Consensus
I’d like to propose we start a call to begin to work toward resolving the final
bugs in the spec and for other business related to getting DOM L3 Events to CR.
On the call we can workout what subsequent meetings we should also arrange.
Does next Tuesday (May 7th), at 11 am PST work your you?
, May 1, 2013 3:23 AM
To: Wez
Cc: Gary Kačmarčík (Кошмарчик); Travis Leithead; masay...@d-toybox.com;
public-webapps; www-dom
Subject: Re: Proposal for a DOM L3 Events Telecon
If Masayuki-san is joining and the time is JST-friendly, I would also like to
join,
but feel free to ignore me
Works for me!
-Original Message-
From: Cameron McCormack [mailto:c...@mcc.id.au]
Sent: Sunday, May 05, 2013 12:39 AM
To: Travis Leithead
Cc: public-webapps
Subject: Re: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition?
Travis Leithead wrote:
There's 50 some-odd bugs
(Кошмарчик)
Cc: Travis Leithead; public-webapps; www-dom
Subject: Re: Proposal for a DOM L3 Events Telecon
On Tue, 07 May 2013 23:07:28 +0200, Gary Kačmarčík (Кошмарчик)
gary...@google.com wrote:
On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano
masay...@d-toybox.comwrote:
Hello, sorry for the big delay
Hey folks,
I just posted the raw minutes to the DOM 3 Events wiki page:
http://www.w3.org/2008/webapps/wiki/DOM3Events
http://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings
The page itself is a derelict from ages past, and I haven’t made much of an
effort to clean it up, but it does have a new
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
On Thu, May 16, 2013 at 5:58 PM, Takeshi Yoshino tyosh...@google.com
wrote:
StreamReader proposed in the Streams API spec is almost the same as
FileReader. By adding the maxSize argument to the readAs methods (new
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
On Thu, May 16, 2013 at 6:31 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
Since we have Streams implemented to some degree, I'd love to hear
suggestions to improve it relative to IO. Anne can you summarize
6:36 AM
To: public-webapps@w3.orgmailto:public-webapps@w3.org;
ro...@w3.orgmailto:ro...@w3.org; Alex Mogilevsky; Travis Leithead;
a...@aryeh.namemailto:a...@aryeh.name;
yo...@chromium.orgmailto:yo...@chromium.org
Subject: [editing] nested contenteditable
Hey,
is there any progress on finding
Would you mind posting to public-script-coord? This sounds like a good addition
to WebIDL.
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Wednesday, May 29, 2013 3:24 PM
To: public-webapps
Subject: [webidl] Add a [Maplike] tag?
I want to convert the
Even though our proposal has the combined list, we don’t have a strong opinion
about whether this should all be in one attribute or in two. Primarily, our
concern was to add the values are that currently not present in the spec, such
as full/half width, hiragana/katakana, etc.
From: Takayoshi
1 - 100 of 190 matches
Mail list logo
