Re: DOM Mutation Events Replacement: When to deliver mutations

[Travis Leithead]

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) Immediately - i.e. while the operation is underway. [Note: This is
> how current DOM Mutation events work].
>
> 2) Upon completion of the "outer-most" DOM operation. i.e. Immediately
> before a the lowest-on-the-stack DOM operation returns, but after it
> has done all of its work.
>
> 3) At the end of the current Task. i.e. immediately before the UA is
> about to fetch a new Task to run.
>
> 4) Scheduled as a future Task. i.e. fully async.
>
> ---
>
> Discussion:
>
> Options 1&  4 are don't seem to have any proponents that I know of, so 
> briefly:
>
> Option 1, Immediately:
>
> Pro:
> -It's conceptually the easiest thing to understand. The following *always* 
> hold:
>-For calling code: When any DOM operation I make completes, all
> observers will have run.
>-For notified code: If I'm being called, the operation which caused
> this is below me on the stack.
>
> Con:
> -Because mutations must be delivered for some DOM operations before
> the operation is complete, UAs must tolerate all ways in which script
> may invalidate their assumptions before they do further work.
>
>
> Option 4, Scheduled as a future Task:
>
> Pro:
> -Conceptually easy to understand
> -Easy to implement.
>
> Con:
> -It's too late. Most use cases for mutation observation require that
> observers run before a paint occurs. E.g. a widget library which
> watches for special attributes. Script may create a class="FooButton">  and an observer will react to this by decorating
> the div as a FooButton. It is unacceptable (creates visual
> artifacts/flickering) to have the div be painted before the widget
> library has decorated it as a FooButton.
>
> Both of these options appear to be non-starters. Option 1 has been
> shown by experience to be an unreasonable implementation burden for
> UAs. Option 4 clearly doesn't handle properly important use cases.
>


When I proposed watchSelector [2], the idea was clearly to propose an option 
that provided semantics similar to Option 4 as described here.
The primary benefits I sought were:
Pros:
* batching - allow a script to operate on the DOM's cumulative changes, vs. 
incremental changes.
* filtering - provide a well-known mechanism for quickly and precisely 
identifying the nodes in the document that should be observed.
* performance - fully async has the potential to very fast to implement

I think the filtering benefit could be extended to either Option 2 or 3.
I prefer Option 3 because if offer a larger opportunity for batching.

Cons:
* See previously stated use case as argument against this approach
* The approach didn't account for node "movement" within the document 
(reparenting of elements).
* The approach (using Selectors) was deemed "too risky" because web developers 
can provide complex selectors that make running the mutation detection 
algorithm expensive for the UA.

I still like the idea of using selectors, and after a conversation with Jonas, 
I realized that the perf concern can be eliminated yet preserve the filtering 
benefit by only allowing what CSS calls "simple selectors" [3], which are 
basically attribute/class/id selectors w/out combinators. Text mutations are 
generally in an entirely different category (primarily editing scenarios), and 
obviously won't work with Selectors. Additionally, the context information for 
text nodes is different than for elements, which leads me to believe that for 
text mutations, some different API may be necessary.



> ---
>
> Options 2&  3 have proponents. Since I'm one of them (a proponent),
> I'll just summarize the main *pro* arguments for each and invite those
> who wish (including myself), to weigh in with further support or
> criticism in follow-on emails.
>
>
> Option 2: Upon completion of the "outer-most" DOM operation.
>
> Pro:
> -It's conceptually close to fully synchronous. For simple uses
> (specifically, setting aside the case of making DOM operations within
> a mutation callback), it has the advantages of Option 1, without its
> disadvantages. Because of this, it's similar to the behavior of
> current Mutation Events.
>

Pros:
* May be very easy to migrate existing sites/apps from current mutation events 
code to this option. If the message of the new mutation events model we create 
is "we finally fixed mutation events, please use this new code instead" then 
the easier we make the transition to the new model the better.

However, in my experience websites and apps don't just migrate because the new 
model is available. Web sites generally follow the pattern: "if it isn't broke, 
don't fix it." To me, this means that classic Mutation events aren't going 
away, and unless the new model provides significant advanta

RE: publish LC#2 of Web IDL; deadline September 16

[Travis Leithead]

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, September 09, 2011 6:49 AM
>To: public-webapps; public-script-coord
>Subject: CfC: publish LC#2 of Web IDL; deadline September 16
>
>Hi All - based on the changes made to address the comments received [1]
>for Web IDL LC #1, Cameron recommends WebApps publish LC#2 and this is a
>Call for Consensus (CfC) to do so:
>
>   http://dev.w3.org/2006/webapi/WebIDL/
>
>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 the
>significance/meaning of a LCWD:
>
>[[
>http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
>
>Purpose: A Working Group's Last Call announcement is a signal that:
>
>* the Working Group believes that it has satisfied its relevant
>technical requirements (e.g., of the charter or requirements document)
>in the Working Draft;
>
>* the Working Group believes that it has satisfied significant
>dependencies with other groups;
>
>* other groups SHOULD review the document to confirm that these
>dependencies have been satisfied. In general, a Last Call announcement
>is also a signal that the Working Group is planning to advance the
>technical report to later maturity levels.
>]]
>
>Positive response to this CfC is preferred and encouraged and silence
>will be considered as agreement with the proposal. The deadline for
>comments is September 16. Please send all comments to:
>
>   public-script-co...@w3.org
>
>-Art Barstow
>
>[1] http://dev.w3.org/2006/webapi/WebIDL/lc1.txt
>
> Original Message 
>Subject:   publishing Web IDL with a second LCWD
>Resent-Date:   Fri, 9 Sep 2011 13:29:28 +
>Resent-From:   
>Date:  Fri, 9 Sep 2011 23:28:43 +1000
>From:  ext Cameron McCormack 
>To:public-script-co...@w3.org 
>
>
>
>Hello everyone.
>
>I've just finished resolving the LC comments on Web IDL.  The only
>sticking point is the one about modules -- I decided to defer their
>removal just because I don't have the time right now, but it seems like
>that is the right thing to do.  I think it should be OK to drop them
>from the spec after the publication, and not have that be an impediment
>to going to CR afterwards.  Similarly, there was some editorial work
>(making more obvious which features are for legacy APIs only) that I did
>not get to.  I will do that once I am back, too.
>
>There were a couple of questions in Allen Wirfs-Brock's feedback that
>weren't direct requests for changes, but my response questions to him
>might result in some further changes at some point.  Nothing drastic,
>though.
>
>The lc1.txt file is up to date, I believe.  We probably don't need to
>wait for commenter satisfaction indication in all cases, since we are
>not going to CR straight away.
>
>I'm away for the next four week, so it would be good if we could get the
>spec published again.  Art, if you think we are good to go, could you do
>a CfC for LCWD#2 (and assume my +1 to publishing) and handle the
>publication?
>
>Thanks,
>
>Cameron
>
>
>

RE: New tests submitted by Microsoft for WebApps specs

[Travis Leithead]

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 tests submitted by Microsoft for WebApps specs


On Tue, Sep 13, 2011 at 6:26 PM, Adrian Bateman 
mailto:adria...@microsoft.com>> wrote:
WebWorkers (51 tests/assertions)
 Changeset: http://dvcs.w3.org/hg/webapps/rev/7b0ba70f69b6
 Tests: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/

* We believe the tests are all accurate but look forward to wider review from
 the group. IE10 PP3 does not pass all the tests and we are working to fix
 the bugs that cause failures.
Web Worker test issues:

issue 1:
WorkerGlobalScope_ErrorEvent_*.htm uses the onerror function and expected to 
get an error event but instead it should get 3 arguments.

See
  
http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html#runtime-script-errors-0
and

   
http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#report-the-error

issue 2:

postMessage_clone_port_error.htm expects to get INVALID_STATE_ERR but should 
expect to get DATA_CLONE_ERR.

http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages

RE: Reminder: RfC: Last Call Working Draft of Web IDL; deadline October 18

[Travis Leithead]

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: RfC: Last Call Working Draft of Web IDL; deadline
>October 18
>
>On 9/27/11 3:56 PM, ext Arthur Barstow wrote:
>> On September 27 a Last Call Working Draft of Web IDL was published:
>>
>>   http://www.w3.org/TR/2011/WD-WebIDL-20110927/
>>
>> The deadline for comments is October 18 and all comments should be
>> sent to:
>>
>> public-script-co...@w3.org
>>
>> The comment tracking doc for the previous LC is:
>>
>>   http://dev.w3.org/2006/webapi/WebIDL/lc1.txt
>>
>> Cameron, Philippe - if you think it is necessary, please fwd this
>> e-mail to ECMA TC39.
>>
>> -AB
>>
>

Re: QSA, the problem with ":scope", and naming

[Travis Leithead]

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 

RE: What type should .findAll return

[Travis Leithead]

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 kind of host object that is a close approximation of 
> a real ECMAScript Array object.  Such an object could indirectly inherit from 
> Array.prototype, over-ride some inherited methods (such as concat and 
> filter), and define additional DOM related methods.  However, its [[Class]] 
> may not be "Array" and anything in the ES spec that requires 
> [[Class]]==="Array" (such as Array.isArray) won't recognize it as an anything 
> special.


This might be my simplified view of things, but have we just circled back 
around to the two definitions that Cameron already has in WebIDL [1]?
* 3.9.18 Sequences - sequence are the corollary of #1 above (plain-old JS 
arrays)
* 3.9.19 Arrays - T[] are the corollary of #2 above; array-like and even are 
participate in the Array.prototype chain. 

In section 4.2.20, the following note outlines the difference between the 
so-called platform array object and a vanilla JS array:

"Note
"Platform array objects differ from Array objects in the following ways: 
" - they are never sparse
" - their elements are always data properties
" - an ECMAScript-to-IDL value conversion is always performed when storing an 
element
" - their internal [[Class]] property value is different
" - their internal [[Extensible]] property value is always true

Can we pick one of these as a starting point for .find()/.findAll()? For 
consistency with other DOM APIs, I personally see the platform array object as 
the way forward.

[1] http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence

[Workers] Worker same-origin and usage in JS libraries...

[Travis Leithead]

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 subsequently downloaded and executed in 
the context of the current page's domain. Relative URLs to a 
worker script will resolve according to the domain of the hosting
page:

// http://cdn.net/dowork.js which was included from http://test.com/home.htm 
var w = new Worker("lib/workers/w1.js");
// Tries to open http://test.com/lib/workers/w1.js

and absolute URLs will fail due to the cross-origin restrictions 
on the new Worker constructor:

// same setup as before
var w = new Worker("http://cdn.net/lib/workers/w1.js";);
// Cross-origin failure from http://test.com/home.htm 

I looked back through the list and at the original worker proposals
to try and discover why the same-origin restrictions is in place.

The root of the issue seems to be the expectation that WorkerGlobalScope
runs and executes everything according to its own location.URL. 
Thus, allowing http://cdn.net/lib/workers/w1.js to load in the 
previous example, would allow http://test.com/home.htm to potentially 
modify any data associated with cdn.net's domain (like through 
Indexed DB, or XHR, etc).

One way to allow the CDN scenario to work would be to provide an explicit 
way to tell a worker to run in the host context, rather than the context
that the Worker is loaded from (which is what 

RE: publish new LCWD of Web IDL; deadline February 3

[Travis Leithead]

I agree to publish.

>-Original Message-
>From: Arthur Barstow [mailto:art.bars...@nokia.com]
>Sent: Friday, January 27, 2012 4:10 AM
>To: public-webapps; public-script-coord
>Subject: CfC: publish new LCWD of Web IDL; deadline February 3
>
>Cameron has completed addressing open Web IDL comments including LC #2
>comments [1] and the only open bugs are enhancement requests [2]. As
>such, this is Call for Consensus to publish a new Last Call Working
>Draft using the following ED as the basis:
>
>http://dev.w3.org/2006/webapi/WebIDL/
>
>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 the
>significance/meaning of a LCWD:
>
>[[
>http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
>
>Purpose: A Working Group's Last Call announcement is a signal that:
>
>* the Working Group believes that it has satisfied its relevant
>technical requirements (e.g., of the charter or requirements document)
>in the Working Draft;
>
>* the Working Group believes that it has satisfied significant
>dependencies with other groups;
>
>* other groups SHOULD review the document to confirm that these
>dependencies have been satisfied. In general, a Last Call announcement
>is also a signal that the Working Group is planning to advance the
>technical report to later maturity levels.
>]]
>
>Positive response to this CfC is preferred and encouraged and silence
>will be considered as agreement with the proposal. The deadline for
>comments is February 3. Please send all comments to:
>
>   public-script-co...@w3.org
>
>-Art Barstow
>
>[1] http://dev.w3.org/2006/webapi/WebIDL/lc2.txt
>[2]
>https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=WebI
>DL&resolution=---
>
>
> Original Message 
>Subject:   Re: RfC: pre-LC comments for Web IDL; deadline January 17
>Date:  Fri, 27 Jan 2012 17:11:27 +1100
>From:  ext Cameron McCormack 
>To:Arthur Barstow 
>CC:public-script-coord 
>
>
>
>Arthur Barstow:
>>  Rather than immediately starting a CfC to publish a new LCWD, let's
>>  first have a two week pre-LC Request for Comments period using the
>>  latest ED as the basis:
>>
>>  http://dev.w3.org/2006/webapi/WebIDL/
>
>Comments over this period have been addressed.  We should publish now.
>I have begun to prepare the two documents for publication:
>
>   http://dev.w3.org/2006/webapi/WebIDL/
>   http://dev.w3.org/2006/webapi/WebIDL/java.html
>
>The pubrules checker seems to be broken at the moment, so I haven't done
>that yet.
>
>

DOM3 Events - additional editing help to move the spec forward

[Travis Leithead]

(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 opinions out there regarding the DOM L3 Events 
spec, and what should be done with it. I'm going to start with the basis that 
it's a good spec. It provides a great deal of context into the event dispatch 
model (in the form of prose, versus the new algorithmic approach that has been 
popular since the HTML5 spec first hit the scene). It 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. In 
addition to the common event types, it also defines the elusive KeyboardEvent, 
a hallmark of this spec since the beginning.

This spec is certainly aging. It's one of the oldest specs that is still in 
active development. I can see working drafts of DOM Level 3 events dating back 
to September 1st, 2000 [1]. Many, many folks have contributed to, reviewed, and 
provided feedback on this spec along the way. With the relatively youthful DOM4 
spec poised to take the torch for the next round of DOM event functionality, 
I'd prefer to close up any lingering issues with DOM L3 Events, get it done (to 
Recommendation status), and turn my attention to DOM4. Getting DOM L3 Events to 
Rec is a very important milestone for UAs and implementations like IE, that 
have made a commitment to supporting this spec, have an existing 
implementation, and need a stable reference specification for our customers and 
partners.

To support the goal of finishing DOM Level 3 Events (in light of the current 
work happening in DOM4), I'm jumping in to help Jacob finish addressing last 
call comments. I've interested in ensuring that the concepts and normative 
requirements of DOM Level 3 Events do not conflict with the existing model 
described in DOM4. In this way, I think DOM4 will be a natural succession from 
DOM Level 3 Events and will add to the richness of the eventing platform on the 
web.

I've already made a few changes to the spec in regard to some existing last 
call comments [2]. I'm not done. I'll be officially working through bugs filed 
in the "DOM3 Events" component of the W3C Bug Tracker [3], and will be moving 
other issues from Tracker [4] into that system to make my life easier. Please 
file new comments as bugs, and I'll follow up there.

As always, feel free to review the spec. The latest editor's draft is at:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html


[1] http://www.w3.org/TR/2000/WD-DOM-Level-3-Events-2901/
[2] Made WebIDL a normative dependency and updated IDL fragments and exceptions 
accordingly; reviewed and removed RFC2119 normative statements from comments 
and a few other places I found them in.
[3] 
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---
[4] https://www.w3.org/2008/webapps/track/products/2

-Travis

RE: DOM3 Events - additional editing help to move the spec forward

[Travis Leithead]

>-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 about default actions has been quite confusing,
>making people think it was somehow more tied to the event than it actually
>was.

Good feedback. I opened a bug to track reviewing that section and cleaning up 
anything that needs polish.

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

[Travis Leithead]

>-Original Message-
>From: Charles McCathieNevile [mailto:cha...@opera.com]
>
>On Mon, 19 Mar 2012 12:24:23 +0100, Marcos Caceres  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.
>

I also support publication.

RE: [XHR] Constructor behavior seems to be underdefined

[Travis Leithead]

> 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.

RE: Shared workers - use .source instead of .ports[0] ?

[Travis Leithead]

>-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 
>wrote:
>
>> On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters  wrote:
>>
>>> On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking 
>>> wrote:
>>>
>>>  Sounds great to me. The ports attribute is basically useless except in
 this
 one instance since ports are these days expose as part of structured
 clones.

 Avoiding using it in this arguably weird way in this one instance seems
 like a win to me.

>>>
>>> I'd like to have an opinion from WebKit and Microsoft about this
>>> proposal.
>>> Can someone comment or cc relevant people, please?
>>>
>>
>> FWIW this to me seems like a good improvement to the intuitiveness.
>
>OK. To make things clear, are you OK with making this change in WebKit?
>
>> Since
>> a MessageEvent interface is being used, qualifying that *source*
>> WindowProxy
>> is populated is all that's needed?
>
>It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
>IDL for MessageEvent's source member would need to change type from
>WindowProxy? to object?.

IE10 does not implement SharedWorkers at the present time. We also don’t yet 
implement the updated "Transferrable" notion for MessagePorts in the structured 
clone algorithm. We do ship Workers now, and so my primary concern is that the 
spec doesn't remove the "ports" property of the MessageEvent.

I don't mind the proposal to re-use .source of MessageEvent for a "connect" 
event on a SharedWorker. I think it's a bit ugly to swap the "WindowProxy" type 
of .source to "any" just for this case. I am curious to see where this latest 
discussion on perhaps using a different Event interface for "connect" events 
will lead...

RE: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent

[Travis Leithead]

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...@w3c.org; Anne van Kesteren 
(ann...@opera.com); Jacob Rossi
Subject: Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent

On Tue, Apr 24, 2012 at 2:23 PM, Olli Pettay 
mailto:olli.pet...@helsinki.fi>> wrote:
Yes. It should be possible to re-dispatch events. But if a script
running on a web page dispatches event, the event must become
untrusted.

What's the point of isTrusted, anyway?  You have to trust other scripts running 
in the same page anyway.  Does it come into play with cross-origin iframes or 
something?

--
Glenn Maynard

RE: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent

[Travis Leithead]

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16847 to track getting 
DOM3 updated on this point.

Thanks for the info.

BTW: Olli, your email isn't recognized in the Bug DB's CC list. Is there one 
that will work?

>-Original Message-
>From: Olli Pettay [mailto:olli.pet...@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, initEvent makes it possible to transform
>> a trusted event into a non-trusted event and dispatch it. Is that
>> intentional?
>AFAIK, yes
>
>
>> It is only currently supported in Firefox and Opera. In
>> IE, Chrome and Safari, the initEvent call is ignored in this
>> scenario. After the initEvent call is ignored, Chrome will allow you
>> to dispatch the event (unchanged), IE will not (per the prose
>> currently in DOM3 Events). Note, chrome doesn't report the
>> "isTrusted" property, so I can't tell if initEvent would have set
>> that flag to false (hope so)!
>>
>> I'm trying to rationalize the behavior between DOM3 and DOM4.
>>
>> DOM3 Events was pretty clear that you can't dispatch an event that
>> wasn't created with createEvent.
>Sounds like a bug. That wasn't the intention when isTrusted was added.
>
>> Pretty simple. That's contrary to
>> DOM4 at the moment (which allows it as long as it's been
>> initialized); I wonder if there needs to be another check to prevent
>> re-dispatching a trusted event?. Is there a specific reason for the
>> current behavior?
>>
>> DOM3 Events is not very clear about initEvent at the moment. Should
>> it be allowed to convert a trusted event to a non-trusted event?
>Yes. It should be possible to re-dispatch events. But if a script
>running on a web page dispatches event, the event must become
>untrusted.
>
>
>-Olli
>
>
>> Seems like trouble. Given that IE9 and Chrome/Safari don't allow it,
>> it won't be a compatibility issue to disallow it.
>>
>> Let's come to an agreement on this so that the two specs can be
>> harmonious on this point.
>>
>> -Travis
>>
>>
>
>

RE: New tests submitted by Microsoft for WebApps specs

[Travis Leithead]

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); 
Israel Hilerio; Brian Raymor; Kris Krueger
Subject: Re: New tests submitted by Microsoft for WebApps specs

Looks like the WorkerGlobalScope_ErrorEvent_*.htm tests are still in error as 
mentioned below.

dave

On Tue, Sep 20, 2011 at 10:53 AM, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
Thanks! We'll see about getting these updated...

From: David Levin [mailto:le...@google.com<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<mailto:public-webapps@w3.org>); Israel Hilerio; Travis 
Leithead; Brian Raymor; Kris Krueger
Subject: Re: New tests submitted by Microsoft for WebApps specs


On Tue, Sep 13, 2011 at 6:26 PM, Adrian Bateman 
mailto:adria...@microsoft.com>> wrote:
WebWorkers (51 tests/assertions)
 Changeset: http://dvcs.w3.org/hg/webapps/rev/7b0ba70f69b6
 Tests: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/

* We believe the tests are all accurate but look forward to wider review from
 the group. IE10 PP3 does not pass all the tests and we are working to fix
 the bugs that cause failures.
Web Worker test issues:

issue 1:
WorkerGlobalScope_ErrorEvent_*.htm uses the onerror function and expected to 
get an error event but instead it should get 3 arguments.

See
  
http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html#runtime-script-errors-0
and

   
http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#report-the-error

issue 2:

postMessage_clone_port_error.htm expects to get INVALID_STATE_ERR but should 
expect to get DATA_CLONE_ERR.

http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages

RE: DOM3 Events - additional editing help to move the spec forward

[Travis Leithead]

> -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 quickly.
> 
> I know there are a variety of opinions out there regarding the DOM L3 Events
> spec, and what should be done with it. I'm going to start with the basis that 
> it's a
> good spec. It provides a great deal of context into the event dispatch model 
> (in
> the form of prose, versus the new algorithmic approach that has been popular
> since the HTML5 spec first hit the scene). It 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. In addition to the 
> common
> event types, it also defines the elusive KeyboardEvent, a hallmark of this 
> spec
> since the beginning.
> 
> This spec is certainly aging. It's one of the oldest specs that is still in 
> active
> development. I can see working drafts of DOM Level 3 events dating back to
> September 1st, 2000 [1]. Many, many folks have contributed to, reviewed, and
> provided feedback on this spec along the way. With the relatively youthful
> DOM4 spec poised to take the torch for the next round of DOM event
> functionality, I'd prefer to close up any lingering issues with DOM L3 
> Events, get
> it done (to Recommendation status), and turn my attention to DOM4. Getting
> DOM L3 Events to Rec is a very important milestone for UAs and
> implementations like IE, that have made a commitment to supporting this spec,
> have an existing implementation, and need a stable reference specification for
> our customers and partners.
> 
> To support the goal of finishing DOM Level 3 Events (in light of the current 
> work
> happening in DOM4), I'm jumping in to help Jacob finish addressing last call
> comments. I've interested in ensuring that the concepts and normative
> requirements of DOM Level 3 Events do not conflict with the existing model
> described in DOM4. In this way, I think DOM4 will be a natural succession from
> DOM Level 3 Events and will add to the richness of the eventing platform on 
> the
> web.
> 
> I've already made a few changes to the spec in regard to some existing last 
> call
> comments [2]. I'm not done. I'll be officially working through bugs filed in 
> the
> "DOM3 Events" component of the W3C Bug Tracker [3], and will be moving
> other issues from Tracker [4] into that system to make my life easier. Please 
> file
> new comments as bugs, and I'll follow up there.

Quick follow-up:
To my knowledge all remaining Tracker issues and other feedback previously sent 
to Jacob have now been resolved in the Bugzilla component for DOM3 Events save 
one last issue. I'm currently working through the final issue (accessibility 
feedback) but didn't want to wait until that was resolved before sending this 
mail. The spec has been dramatically updated in the past 3 months, and should 
now be quite nicely aligned with DOM4's Events section.

My plan, as mentioned at the March F2F meeting, is to resolve the last issue, 
then ask the chairs to start the LC process for this spec, with advancement to 
CR hopefully following soon thereafter.

This is not yet an official last call, but if you'd like to re-read the spec 
and provide additional feedback--this is a good time to do it. Also, if for 
some reason I missed responding to your previously written feedback, please 
re-send it or file a bug directly.

DOM3 Events (Ed. Draft) 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
DOM4 Events section (WD) http://www.w3.org/TR/dom/#events

Thanks,
-Travis

RE: DOM3 Events - additional editing help to move the spec forward

[Travis Leithead]

> -Original Message-
> From: Pablo Garaizar Sagarminaga [mailto:garai...@deusto.es]
> 
> Hello,
> 
> on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking 
> wrote:
> 
> > > This is not yet an official last call, but if you'd like to re-read
> > > the spec and provide additional feedback--this is a good time to do
> > > it.
> 
> Disclaimer: I don't know how and where to do this proposal. I hope you'll help
> me to find the proper place to send it.
> 
>   During High Resolution Time working draft final call for public comments I
> wrote a suggestion about DOM events' timestamps and the use of
> monotonically increasing values provided by High Resolution Time
> API:
> 
>   I would love to have the chance to get a DOMHighResTimeStamp as a property
> of an DOM event, like event.timeStamp. Events'
> timestamps are also subject to system clock skew and other problems
> mentioned in High Resolution Time working draft, and providing access to HRT
> when triggering events will be very helpful to program accurate interactions.
> 
>   I'm not sure if this could be done adding a new property to the event 
> interface
> (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp
> property (i.e., DOMHighResTimeStamp).
> 
>   It would be great to discuss this feature in future versions of the drafts
> mentioned before.

I discussed this briefly with Jatinder Mann (who works on the High resolution 
timing spec--you might know him?). Based on that discussion it sounds like the 
high-resolution timestamp provides three features:
1. The timestamp is relative to the loaded page (not the Unix epoch)
2. The timestamp can be in microsecond resolution (a best effort-approach)
3. The timestamp is garuanteed to be monotonically increasing.

Based on #1, we can't simply replace the current timestamp property on DOM 
events with a high-resolution time stamp--this would be a change (though 
perhaps not very impactful) to backward compatibility. Therefore, the only 
plausible action could be a new property (e.g., "highResolutionTimeStamp" or 
similar).

However, I wonder what real value this would have. Typically events only fire 
within the scope of the current window and do not bleed out into other windows 
(Message and Storage events are notable exceptions)--so new Date() should be 
self-consistent (coming from the same script engine) even if other script 
engines are suffering from clock-skew. One issue that is present in IE, is Date 
objects that get serialized over from Web Workers--they can have a pretty big 
clock skew pretty quickly, but hypothetically performance.now() can cover those 
scenarios.

Are there other specific use cases that you're finding where the timestamp 
property doesn't meet your needs?

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

[Travis Leithead]

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, 2012 11:10 AM
To: Arthur Barstow
Cc: espr...@gmail.com; www-dom; public-webapps
Subject: www-dom vs public-webapps WAS: [DOM4] Mutation algorithm imposed order 
on document children

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.

Travis, Jacob, Ms2ger, Aryeh, Anne: How would feel about merging DOM 
discussions back into public-webapps@?

Ojan
On Tue, Jun 12, 2012 at 5:15 AM, Arthur Barstow 
mailto:art.bars...@nokia.com>> wrote:
Elliott, All - please use the www-...@w3.org list for 
DOM4 discussions .

(Elliott, since that spec is still in the draft phase, you should probably use 
the latest Editor's Draft 
 instead of the 
version in w3.org/TR/)

-Thanks, AB

 Original Message 
Subject:[DOM4] Mutation algorithm imposed order on document children
Resent-Date:Tue, 12 Jun 2012 01:01:51 +
Resent-From:mailto:public-webapps@w3.org>>
Date:   Mon, 11 Jun 2012 16:39:36 -0700
From:   ext Elliott Sprehn mailto:espr...@gmail.com>>
To: mailto:public-webapps@w3.org>>



I'm working on places where Webkit doesn't follow the DOM4 mutation algorithm 
and one of the bugs is not throwing an exception when a doctype node is 
inserted after an element in a document (or other permutations of the same 
situation).

https://bugs.webkit.org/show_bug.cgi?id=88682
http://www.w3.org/TR/domcore/#mutation-algorithms

After discussing this with some other contributors there were questions on why 
we're enforcing the order of the document child nodes. Specifically since 
inserting a doctype node doesn't actually change the doctype so this situation 
is very unlikely (possibly never happens) in the wild. Not implementing this 
keeps the code simpler for a case that developers likely never see.

Can we leave the behavior when your document is out of order unspecified?

- Elliott

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

[Travis Leithead]

> -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 it Breaks the Web (and the breakage can't
> > be evanged), I suggest we ship the backwards-incompatible change to
> > querySelector() in nightly/aurora (or equivalent) in one or more browsers 
> > for
> some time.
> 
> I didn't read through all the QSA threads, but isn't the function name itself 
> a
> mistake that many people don't want to live with?
> 
> I'd rather like to see querySelector() marked as "deprecated" so it doesn't 
> appear
> in tutorials in the future.

Despite being "non-optimal" according to a vocal sub-set of people, 
querySelector[All] has been deployed in browsers for around 3-4 years. 
I strongly oppose any notion of altering its behavior now.

As to find/findAll, let's just make sure we get the behavior right the 
second time so we don't go through this again.

RE: publish WD of Selectors API Level 2; deadline June 25

[Travis Leithead]

> 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 .
> 
> Positive response to this CfC is preferred and encouraged and silence will be
> assumed to mean  agreement with the proposal.

I support the publication of a new WD.
-Travis

RE: DOMParser Errors Should Be Exceptions

[Travis Leithead]

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 Exceptions

If this is the case, can we consider changing the spec?

Yehuda Katz
(ph) 718.877.1325

On Wed, May 23, 2012 at 12:38 PM, Tony Ross 
mailto:tr...@microsoft.com>> wrote:
> From: João Eiras [mailto:jo...@opera.com]

> Opera thrown an exception long time ago and since version 9.5 it changed
> the behavior to return the bogus parsererror tree because it caused
> yahoo mail to fail back them (among other things).
>
> While the current behavior of returning the parsererror document is
> inappropriate, I afraid it also unchangeable.
Has this been examined recently? In IE9+ DOMParser throws an exception when an 
XML parsing error is encountered. I've yet to hear of this causing a problem.

-Tony

RE: [gamepad] Polling access point

[Travis Leithead]

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
Cc: Ted Mielczarek
Subject: [gamepad] Polling access point

Hi,

It looks like the access point for the polling part of the API 
(navigator.gamepads[]) is not a good idea.

Based on a prototype implementation, pages seem to have a tendency to enumerate 
Navigator. When the .gamepads[] attribute is accessed, it causes possibly 
expensive background resources to be created to access hardware, even though 
the content is not really interested in reading data from the hardware.

Possible solutions:
- change from navigator.gamepads[] to navigator.gamepads() (or 
navigator.getGamepads()) to be more explicit about when the API is actually 
being used
- require something to activate the API (meta tag, calling some sort of "start" 
function)
- require registering for at least one gamepad-related event before data is 
provided in gamepads[].
- make .gamepads[] non-enumerable

Any thoughts or other suggestions?

Thanks,
scott

RE: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

[Travis Leithead]

> 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 unclosed comments should throw a
> SyntaxError.
> 3. Allow comments, define that unclosed comments are silently ignored.

I just checked in IE10, and it looks like we actually do:

4. Allow comments, define that unclosed comments are automatically closed.

Behavior wise, this means that given the following OM:

  


The call: document.querySelector("#parent /* #child");

Returns the parent div successfully. I'm not sure that I'm thrilled about this 
behavior, but it is what it is...

RE: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

[Travis Leithead]

> From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
> 
> On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai  wrote:
> > On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. 
> > wrote:
> >> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai 
> wrote:
> >> > Meh. I think this loses most of the "CSS is so much more convenient"
> >> > benefits. It's mainly the fact that you don't have to worry about
> >> > whether the nodes exist yet that makes CSS more convenient.
> >>
> >> Note that this benefit is preserved.  Moving or inserting an element
> >> in the DOM should apply CAS to it.
> >>
> >> The only thing we're really losing in the dynamic-ness is that other
> >> types of mutations to the DOM don't change what CAS does, and some of
> >> the dynamic selectors like :hover don't do anything.
> >
> >
> > Ah, I missed the "plus a mutation observer that reruns the mutations
> > on any nodes added to the document" bit. Ok, so this timing is very specific
> then.
> > It would get applied at the microtask time, not at the time the DOM
> > was modified. Would it get applied before or after mutation observers
> > get called? Seems like you'd want it to execute first. Calling it
> > after mutation observers would require an extra delivery of mutations
> > after the attributes are applied, which seems silly.
> 
> I presume there's an ordering of mutation observers, such that ones defined
> earlier in document history get the notifications first, or somesuch?  If so,
> CAS should indeed run before any author-defined observers.

So this can basically be completely authored as a script library using existing 
or soon-to-be-implemented technologies? You just need a CAS JS parser, CAS JS 
rule engine, and mutation observers? Tab, you should just supply an 
implementation of this. :)

Editor's draft created of DOM Parsing and Serialization Spec

[Travis Leithead]

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 the Bug tracking system:
https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM%20Parsing%20and%20Serialization&resolution=---

I've also taken the liberty of updating the PubStatus section of the WebApps 
Wiki for this WG deliverable:
http://www.w3.org/2008/webapps/wiki/PubStatus

Thanks!
-Travis

RE: Editor's draft created of DOM Parsing and Serialization Spec

[Travis Leithead]

> 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/innerhtml/raw-file/tip/index.html
> >
> 
> Thanks for creating this ED!
> 
> BTW, what changes (if any) do we want to make before we start a CfC for
> First Public Working Draft?

For the FPWD, I don't believe there's any changes that are necessary.


> > A list of active bugs against the spec are being maintained against
> > this component in the Bug tracking system:
> >
> >
> https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&compo
> nent=DOM%20Parsing%20and%20Serialization&resolution=---
> >
> 
> OK, and I see that Mike created a separate component under the WHATWG
> product for Ms2ger's DOM P&S version at html5.org [1].
> 
> -AB
> 
> [1]
> <https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&compone
> nt=DOM%20Parsing%20and%20Serialization&resolution=--->


Thanks! I want to keep the two spec in sync as much as possible, so if Ms2ger 
doesn't 
mind, I'll cherry-pick fixes from those bug fixes into the ED draft. I'd also 
like to help work
on solutions to some of the existing bugs.

Ms2ger, do have any suggestions on how we might work together on some of those?

RE: Proposal to add USB keycodes to the current DOM3 key events

[Travis Leithead]

> 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:
> https://docs.google.com/document/d/1eJvlUaTBsWa71hIc0X4s6SrCopX9LCPs1YOAuV
> luxBs/edit

Nice. Yes, getting the keyboard layout-independent position of a key was 
specifically out-of-scope for DOM Level 3 Events. I don't know much about the 
USB key codes, but it looks promising as a standard way of getting key location 
interop across OS/languages.

I did want to call out a sentence from you problem statement:

"Games and other applications which treat the keyboard as a large collection of 
buttons need to be able to keep track of which keys are currently being held 
down. ***Since there is no API to query the current keyboard state***, it is 
crucial that apps be able to match every keyup event with the originating 
keydown event."

An old strawman was proposed in 2009 for this: 
http://www.w3.org/2008/webapps/wiki/Query_Key_Status, but is still worth 
pursuing/revising.

RE: In WebIDL, should having a .prototype on interface objects be optional?

[Travis Leithead]

> 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 things like this:
> 
>partial interface URL {
>
>}
> 
>ECMAScript user agents of this specification must ensure that they
>do not expose a prototype property on the URL interface object unless
>the user agent also implements the URL [URL API] specification. In
>other words, URL.prototype must evaluate to true if the user agent
>implements the URL [URL API] specification, and must NOT evaluate
>to true otherwise.
> 
> which flat-out contradicts the WebIDL text.
> 
> At the moment what Gecko is implementing is the following:  An interface
> object only has a .prototype property if it's not a callback interface
> and there can be actual objects with the relevant prototype on their
> proto chain.  So in our case we'd get the behavior File API calls for
> for free as long as we don't implement [URL API], but what we do is not
> compliant with WebIDL as it stands.
> 
> Should WebIDL change here?  Should FileAPI change?

In IE, we have an extended attribute that also provides for an interface object 
w/out a prototype: [msInterfaceObjectOnly]. It was primarily useful for things 
like NodeFilter. With support for the semantics of callback interfaces, most of 
the need for this goes away--however there are just a few cases like window.URL 
for which something like this is useful. In my humble opinion, what File API 
wanted to do was use the legacy WebIDL "module" feature which basically gives 
them what they want as far as a namespace for adding more properties.

I believe that firstly, the File API spec needs to be rationalized against the 
URL API which seems to indicate that the interface URL { } will behave more 
like a "normal" interface object. Once that happens, I wonder if there are any 
other lingering objects for which the "prototype-less" interface object would 
be needed.

RE: In WebIDL, should having a .prototype on interface objects be optional?

[Travis Leithead]

> 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 object and proto object.
> 
> > Once that happens, I wonder if there are any other lingering objects for
> which the "prototype-less" interface object would be needed.
> 
> Well, any interface that only has static stuff and no actual objects
> that implement it, right?

Yep. WebIDL _had_ modules support, but we all suggested it be removed since no 
one needed it. I'm only saying that I'm still not sure we'd need to 
re-introduce it.

I'll side note that Windows 8's WinRT namespace (window.Windows) would require 
modules in order to specify all the supported features using WebIDL.

RE: [XHR] chunked

[Travis Leithead]

> From: Jonas Sicking [mailto:jo...@sicking.cc]
> 
> On Thu, Sep 27, 2012 at 9:26 AM, Anne van Kesteren 
> wrote:
> > On Thu, Sep 27, 2012 at 6:23 PM, Jonas Sicking  wrote:
> >> I do somewhat agree that if we had a full "stream" solution in the
> >> form of a Stream primitive and .responseType="stream", then a better
> >> solution might be to use that in combination with having chunked
> >> delivery on the Stream class instead.
> >
> > Was Microsoft going to take a stab at that? I could write something
> > like that up in XMLHttpRequest I suppose. Although maybe that would
> > require a bunch of coordination with the MediaStream stuff?
> 
> I can't speak to anyone else's plans. But it does seem like a proposal
> was made quite a long time ago and as I recall it it received
> favorable feedback, but so far nothing else has happened.

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/tip/Overview.htm

RE: [XHR] chunked

[Travis Leithead]

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On
> 
> On Thu, Sep 27, 2012 at 7:00 PM, Travis Leithead
>  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/tip/Overview.htm
> 
> Cool. I can integrate the relevant bits into XMLHttpRequest. Do I
> understand it correctly that it does not allow for streaming data
> towards the server? It seems to just copy the data from the Stream
> object that it currently represents and that's that. Is that really
> what we want here?

In my observation of the current IE behavior, the Stream is for download only. 
XHR gets the data from the server and buffers it. The consumer of the stream 
then pulls data as needed which is extracted from the buffer.

RE: [XHR] chunked

[Travis Leithead]

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
> 
> On Thu, Sep 27, 2012 at 7:42 PM, Travis Leithead
>  wrote:
> > In my observation of the current IE behavior, the Stream is for download
> only. XHR gets the data from the server and buffers it. The consumer of
> the stream then pulls data as needed which is extracted from the buffer.
> 
> I see, so the bit where it says you can pass it to send() we should
> maybe not add for now if it's not going to do something useful.

I honestly haven't tested that part, but this seems safe (it can be added-
in later if need be).

RE: In WebIDL, should having a .prototype on interface objects be optional?

[Travis Leithead]

> From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> 
> On 9/28/12 4:28 AM, Cameron McCormack wrote:
> > 1. Should we make it so that if you implement one or more partial
> > interfaces but not the actual one, then an empty actual interface is
> > implied?
> 
> That's fine by me.
> 
> > 2. Is it really important to avoid a prototype from existing on URL in
> > this case?  I think I'd rather just leave it exist.
> 
> I think the idea is to allow object-detection of whether the URL spec is
> supported.

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. I also 
think .prototype removal need not be a special case for
this circumstance.

RE: In WebIDL, should having a .prototype on interface objects be optional?

[Travis Leithead]

> 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 for the file API bits.  How do you
> check whether you can actually work with URL objects?

I guess you'd check for URL.href then? Or try { new URL("/test"); } catch (ex) 
{ console.log("not supported"); }

RE: In WebIDL, should having a .prototype on interface objects be optional?

[Travis Leithead]

I was alluding to this behavior for interface objects (e.g., "URL"):

4.4.1.1. Interface object [[Call]] method 
§<http://dev.w3.org/2006/webapi/WebIDL/#es-interface-call>
If the interface<http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface> is 
declared with a 
[Constructor]<http://dev.w3.org/2006/webapi/WebIDL/#Constructor> extended 
attribute<http://dev.w3.org/2006/webapi/WebIDL/#dfn-extended-attribute>, then 
the interface 
object<http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object> can be 
called as a function to create an object that implements that interface. 
Interfaces that do not have a constructor will throw an exception when called 
as a function.
..."not supported" just means "URL is not a constructor/won't parse a URL 
string parameter". As Cameron noted, it's not an idea test-in the instance you 
note in Chome, that's due to the subtle difference in implementation of WebIDL 
per 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 be 
optional?


On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack 
mailto:c...@mcc.id.au>> wrote:
Travis Leithead:
I guess you'd check for URL.href then? Or try { new URL("/test"); } catch (ex) 
{ console.log("not supported"); }

I agree with Travis, you should be checking the particular features you want to 
use, rather than checking the existence of the prototype as a proxy for that 
test.

If URL.prototype was required to exist, you could just do ("href" in 
URL.prototype).  Since it currently doesn't, you could do ("href" in 
(URL.prototype || {})).

I'm interested in knowing more about what would throw. If URL is not a 
constructor function, it will throw, but if it is what aspect of the above 
would be "not supported". I ask because currently Chrome's URL (webkitURL) can 
construct, but it constructs a fairly useless instance and throws nothing (new 
webkitURL("/test");)

Thanks in advance

Rick

RE: In WebIDL, should having a .prototype on interface objects be optional?

[Travis Leithead]

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 clearer, but I was actually referring to the URL string 
> parameter itself, and how to test if passing an argument to the constructor 
> is supported (the example I gave falls short of answering that question). 
>
>Loosely related... will invalid URL string parameters throw in the same manner 
>that invalid selectors throw? eg. context.querySelector("?")

Hmm, that's not a question for WebIDL, as far as I know. The spec defining the 
constructor behavior would need to specify that.

RE: publish WD of Shadow DOM; deadline Oct 10

[Travis Leithead]

> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> 
> Dimitri would like to publish a new Working Draft of Shadow DOM and this
> is a Call for Consensus to do so, using the following document as the
> basis
>  file/tip/publish/shadow/index.html>.

Publish!

Event.key complaints?

[Travis Leithead]

Hallvord, sorry I missed your IRC comment in today's meeting, related to DOM3 
Events:



 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 with key that 
I've tracked relating to the spec are regarding control key usage in 
International keyboard layouts: 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341.

Thanks,
-Travis

RE: [Clipboard API] The before* events

[Travis Leithead]

>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 content any 
more. The use case of hiding the cut/copy/paste menu options, can be fulfilled 
by replacing the contextmenu with some custom one if desired.

From: o...@google.com [mailto:o...@google.com] On Behalf Of Ojan Vafai
Sent: Wednesday, October 31, 2012 10:21 PM
To: Hallvord R. M. Steen
Cc: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; 
Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events

On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen 
mailto:hallv...@opera.com>> wrote:
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..

Nothing in the official MSDN documentation [1] really explains the interaction 
between beforecopy and copy (given that you can control the data put on the 
clipboard from the copy event without handling beforecopy at all, the demo 
labelled "this example uses the onbeforecopy event to customize copy behavior" 
doesn't really make sense to me either.)

I was under the impression that you could handle the before* events to control 
the state of copy/cut/paste UI like menu entries. However, when tweaking a 
local copy of the MSDN code sample [2], I don't see any difference in IE8's UI 
whether the event.returnValue is set to true or false in the beforecopy 
listener.

Another problem with using before* event to control the state of copy/cut/paste 
UI is that it only works for UI that is shown/hidden on demand (like menus) and 
not for UI that is always present (like toolbar buttons). I'm not aware of web 
browsers that have UI with copy/cut/paste buttons by default, but some browsers 
are customizable and some might have toolbar buttons for this.

I'm wondering if specifying something like

navigator.setCommandState('copy', false); // any "copy" UI is now disabled 
until app calls setCommandState('copy', true) or user navigates away from page

would be more usable? A site/app could call that at will depending on its 
internal state. Or, if we want to handle the data type stuff, we could say

navigator.setCommandState('paste', true, {types:['text/plain','text/html']});

to enable any "paste plain text" and "paste rich text" UI in the browser?

I don't have a strong opinion on the specifics of the API, but I agree that 
this is much more usable than the before* events. In the common case, web 
developers would have to listen to selectionchange/focus/blur events and call 
these methods appropriately.

The downside to an approach like this is that web developers can easily screw 
up and leave the cut/copy/paste items permanently enabled/disabled for that 
tab. I don't have a suggestion that avoids this though. I suppose you could 
have this state automatically get reset on every focus change. Then it would be 
on the developer to make sure to set it correctly. That's annoying in a 
different way though.

-Hallvord

[1] http://msdn.microsoft.com/en-us/library/ms536901(VS.85).aspx
[2] 
http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onbeforecopyEX.htm

RE: Event.key complaints?

[Travis Leithead]

This is great feedback, which will need to be addressed one-way or another 
before we finish DOM 3 Events.

Are there any other implementations of key/char other than IE9 & 10? (And 
Opera's Alpha-channel implementation). I did a quick check in the latest 
Firefox/Chrome stable branches 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 missed your IRC comment in today's meeting,
> >> related to
> >> DOM3 Events:
> >> ** **
> >>  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?
> 
> To which Ojan Vafai replied:
> 
> > I'm not sure what specific issues Hallvord has run into, but WebKit
> > implementing this property is blocked on us having a bit more
> > confidence that the key/char properties won't be changing.
> 
> Probably wise of you to hold off a little bit ;-), and thanks for pointing to
> relevant discussion threads (I pasted your links at the end).
> 
> Opera has done the "canary" implementation of the key and char properties,
> according to the current spec. As such, we've received feedback from JS
> authors trying to code for the new implementation, both from internal
> employees and externals. According to this feedback, although the new spec
> attempts to be more i18n-friendly it is actually a step backwards compared to
> the event.keyCode model:
> 
> If, for example, you would like to do something when the user presses [Ctrl]-
> [1], under the old keyCode model you could write this in a keydown handler:
> 
> if(event.ctrlKey && event.keyCode == 49)
> 
> while if you want to use the new implementation you will have to do
> something like
> 
> if(event.ctrlKey && ( event.key == 1 || event.key == '&' || event.key == '1' 
> ))
> 
> and possibly even more variations, depending on what locales you want to
> support. (That's three checks for English ASCII, French AZERTY and Japanese
> hiragana "wide character form" layouts respectively - I don't know of other
> locales that assign other character values to this key but they might exist).
> Obviously, this makes it orders of magniture harder to write cross-locale
> applications and places a large burden of complexity on JS authors.
> 
> In the current spec, event.key and event.char are actually aliases of each
> other for most keys on the keyboard! If the key you press doesn't have a
> "key name" string, event.key and event.char are spec'ed as being the same
> value [1].
> 
> This "aliasing" doesn't really add up to a clear concept. If two properties 
> have
> the same value almost always, why do we add *two* new properties in the
> first place?
> 
> This is also the underlying cause for other reported problems with the new
> model, like the inability to match [Shift]-[A] keydown/up events because
> event.key might be a in keydown but A in keyup or vice versa.
> 
> I would like the "story" of event.char and event.key to be that event.char
> describes the generated character (if any) in its
> shifted/unshifted/modified/localized glory while event.key describes the
> key (perhaps on a best-effort basis, but in a way that is at least as stable 
> and
> usable as event.keyCode).
> 
> Hence, what I think would be most usable in the real world would be making
> event.key a mapping back to un-shifted character values of a normal QUERTY
> (en-US) layout. Authors are asking for stable reference values for identifying
> keys, and that's the most stable and widely known reference keyboard
> layout.
> 
> Alternatively, we can spec that event.key describes the un-shifted, un-
> modified key state from the current keyboard layout AND standardise
> event.keyCode they way it's already implemented rather than deprecating it,
> because it covers some use cases better than what our new stuff does. But
> my preference would be going the event.key = QUERTY (en-US) route, and I
> plan to report a bug or two on making that happen.
> -Hallvord
> 
> [1] Spec describes event.key as follows: "If the value is has a printed
> representation, it must match the value of the KeyboardEvent.char
> attribute"
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-
> Events.html#events-KeyboardEvent-key
> 
> http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0010.html
> http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0713.html
> http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html
> http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0030.html
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341

RE: [Clipboard API] The before* events

[Travis Leithead]

You are right, that it doesn't solve the "disabling the option in the browser 
chrome" case-but is that really necessary? Why would a site want to do this?

The only reason I can imagine is the old "we want to prevent the casual user 
from copying this image because it is copyrighted" scenario. In the cut/paste 
interaction, there are other ways to handle this such as making the control 
read-only, or stoping the action at the keyboard event level.

IE10 (and other UAs) have another solution-allow more fine-grained control over 
the management of selection (css 
property<http://msdn.microsoft.com/en-us/library/ie/hh781492(v=vs.85).aspx>, 
and example usage<http://ie.microsoft.com/testdrive/HTML5/msUserSelect/>). I 
can imagine a similar model for specific control over cut/copy/paste from 
certain parts of the page if this is a hard requirement. The CSS property means 
that the developer's 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; Aryeh Gregor; Daniel Cheng; 
Bjoern Hoehrmann; Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events

On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
>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 content any 
more. The use case of hiding the cut/copy/paste menu options, can be fulfilled 
by replacing the contextmenu with some custom one if desired.

You don't want to disable the other items in the context menu though. This also 
doesn't solve disabling cut/copy/paste in non-context menus, e.g. Chrome has 
these in the Chrome menu.


From: o...@google.com<mailto:o...@google.com> 
[mailto:o...@google.com<mailto:o...@google.com>] On Behalf Of Ojan Vafai
Sent: Wednesday, October 31, 2012 10:21 PM
To: Hallvord R. M. Steen
Cc: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; 
Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events

On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen 
mailto:hallv...@opera.com>> wrote:
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..

Nothing in the official MSDN documentation [1] really explains the interaction 
between beforecopy and copy (given that you can control the data put on the 
clipboard from the copy event without handling beforecopy at all, the demo 
labelled "this example uses the onbeforecopy event to customize copy behavior" 
doesn't really make sense to me either.)

I was under the impression that you could handle the before* events to control 
the state of copy/cut/paste UI like menu entries. However, when tweaking a 
local copy of the MSDN code sample [2], I don't see any difference in IE8's UI 
whether the event.returnValue is set to true or false in the beforecopy 
listener.

Another problem with using before* event to control the state of copy/cut/paste 
UI is that it only works for UI that is shown/hidden on demand (like menus) and 
not for UI that is always present (like toolbar buttons). I'm not aware of web 
browsers that have UI with copy/cut/paste buttons by default, but some browsers 
are customizable and some might have toolbar buttons for this.

I'm wondering if specifying something like

navigator.setCommandState('copy', false); // any "copy" UI is now disabled 
until app calls setCommandState('copy', true) or user navigates away from page

would be more usable? A site/app could call that at will depending on its 
internal state. Or, if we want to handle the data type stuff, we could say

navigator.setCommandState('paste', true, {types:['text/plain','text/html']});

to enable any "paste plain text" and "paste rich text" UI in the browser?

I don't have a strong opinion on the specifics of the API, but I agree that 
this is much more usable than the before* events. In the common case, web 
developers would have to listen to selectionchange/focus/blur events and call 
these methods appropriately.

The downside to an approach like this is that web developers can easily screw 
up and leave the cut/copy/paste items permanently enabled/disabled for that 
tab. I don't have a suggestion that avoids this though. I suppose you could 
have this state automatically get reset on every focus change. Then 

RE: CfC: publish WD of XHR; deadline November 29

[Travis Leithead]

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
> 
> On Fri, Nov 23, 2012 at 6:11 PM, Glenn Adams  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 the context of participating in the W3C process, ...
> 
> It seems you are missing the fact that I am neither a Member nor an Invited
> Expert of this WG since August this year.
> 
> The W3C does have the legal right to publish my work, since I publish it under
> CC0, but the way the W3C goes about it is not appreciated.

Perhaps we should add the concept of a "concurrent work" section (and 
concurrent work editor)? 

The main difference I see between the usage of previous editors in the W3C's 
past and the current situation, is that in the past, when an editor was 
replaced it was because the previous editor was no longer working on the spec. 
In the current situation, we now have editors leaving the W3C, but wishing to 
continue to edit their spec elsewhere. The W3C then replaces editors, but then 
we have parallel documents and parallel editors.

RE: Re: Event.key complaints?

[Travis Leithead]

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, which will be 
the successor to DOM3 Events. I brought this up at TPAC and there were no 
objections. Gary, I'd love you collaboration on specifying your new "code" 
property in that spec.

-Travis

From: gary...@google.com [mailto:gary...@google.com] On Behalf Of Gary 
Kacmarcik (?)
Sent: Friday, November 30, 2012 2:11 PM
To: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org
Subject: Re: Re: Event.key complaints?

On Thu, Nov 8, 2012 at 6:37 AM, Hallvord Reiar Michaelsen Steen wrote:

>>> Hence, what I think would be most usable in the real world would be
>>> making event.key a mapping back to un-shifted character values of a
>>> normal QUERTY (en-US) layout. Authors are asking for stable reference
>>> values for identifying keys, and that's the most stable and widely
>>> known reference keyboard layout.

Gary responded:

>> The main problem with using unmodified 'en-US' values is that it doesn't
>> define values for keys that are not found on US keyboards. So, it's great
>> for US keys, but completely ignores the rest of the world.

Hallvord replied:

> Yep, and the solution to that is listing those keys and figuring out what
> their preferred key name should be. [...]
>
> Thanks for coming up with your list :-)

That wasn't really supposed to be a list, just a few obvious problematic 
examples. ^_^

However, I've spent some time over the past few weeks working to identify all 
the problem cases so that we can have a more concrete proposal.

But first (for background), I extended your key event "stories" into 3 basic 
scenarios that I refer to (for lack of better, unambiguous terms) as CHAR, 
MEANING and CODE.


CHAR (high-level character info)

The CHAR use-case is for users who are interested only in the printable final 
character that the user typed (or entered through some other means).
The user gets the char info by handling 'keypress' (deprecated) or HTML5 
'input' events and reading the 'char' field from the KeyboardEvent.
Example use-case: Detect character input (to validate field after each char is 
entered)

MEANING (high-level key info - virtual key meaning)
---
The MEANING use-case is for users who are interested in the meaning of the key 
being pressed, taking into account the current keyboard layout (and IME and 
dead keys).
Example use-case: Detect modified keys or bare modifier keys (to perform an 
action in response to shortcut)

CODE (low-level key info - physical keys)
-
The CODE use-case is for users who are interested in the key that was pressed 
by the user, without any layout modifications applied.
Example use-cases: Games (detect WASD keys for movement), Remote desktop client 
(trap all keys to send to remote host)


I was hoping that the MEANING and CODE scenarios could be satisfied with a 
single field in the KeyboardEvent structure, but further reflection has 
convinced me that this is not possible.

Consider these examples that demonstrate the difference between MEANING and 
CODE, and why both are needed:

Left/Right Alt key:
CHAR MEANING   CODElocation
   US Keyboard   ""   "Alt"   "AltLeft"left
   US Keyboard   ""   "Alt"   "AltRight"   right
   French Keyboard   ""   "Alt"   "AltLeft"standard
   French Keyboard   ""  "AltGr"  "AltRight"   standard
   Notes:
  MEANING permits matching "Alt" regardless of which Alt key was
pressed.
  CODE permits matching "AltRight" regardless of which layout is in
effect.
  The location for "Alt" and "AltGr" is 'standard' since there's only one
of each key. Arguably, these values could be 'left'/'right' to match
the US layout.

Single Quote key:
CHAR MEANING   CODE
   US Keyboard   "'"   "'""Quote"
   Japanese Kbd  ":"   ":""Quote"
   US Intl Kbd   """DeadAcute""Quote"
   Notes:
  For US Intl Kbd, we can't use the unmodified US key ("'") in the
MEANING since that's where the dead key is specified.

Equal Sign (with Left Alt pressed):
CHAR MEANING   CODEmodifiers
   US Keyboard   """=""EqualSign"  Alt
   Korean Kbd"""JunjaMode""EqualSign"  Alt

Two (with Shift key pressed):
CHAR MEANING   CODE
   US Keyboard   "@"  "@" "Digit2"
   UK Keyboard   """  """ "Digit2"
   French Keyboard   "2"  "2" "Digit2"
   Notes:
  If we adopted MEANING = unmodified US key, then the MEAN

RE: Re: Event.key complaints?

[Travis Leithead]

>> When were you thinking of kicking off the DOM4 Events process?

I'd like to have a draft up this week. We may also ask for a FPWD if we're 
ready by the 10th.

I want to have D4E rolling so that stuff we chose to punt from D3E has a 
landing pad.

From: gary...@google.com [mailto:gary...@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 
mailto:travis.leith...@microsoft.com>> wrote:
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, which will be 
the successor to DOM3 Events. I brought this up at TPAC and there were no 
objections. Gary, I'd love you collaboration on specifying your new "code" 
property in that spec.

Sounds good to me.  I still have some comments to make on the DOM3 Events spec, 
but I'll still send them out knowing that some of them will need to be punted 
to DOM4.

When were you thinking of kicking off the DOM4 Events process?

-Gary

RE: [Workers] Worker same-origin and usage in JS libraries...

[Travis Leithead]

> 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
> > want to opt-in to being run in such a way start with a line line:
> >
> >// Cross-Origin Worker for: http://example.net
> >
> > ...or (for multiple domains):
> >
> >// Cross-Origin Worker for: http://example.com https://example.org
> >
> > ...or (for any domain):
> >
> >// Cross-Origin Worker for all origins
> >
> > ...but that doesn't seem super neat.
> 
> Just as an update, I still plan to do this, but I'm currently waiting for
> browser vendors to more widely implement the existing Worker,
> SharedWorker, MessagePort, and PortCollection features before adding more
> features to this part of the spec. It would also be helpful to have
> confirmation from browser vendors that y'all actually _want_ cross-origin
> workers, before I spec it.

I've had many folks as me why they can't just refer to a cross-origin work in 
the Worker constructor; after all, they can import the worker's dependent 
scripts via importScripts cross-origin...

The only rationale I could give is that the spec indicates the new worker's 
origin info was based on the document's that spawned it. If the new worker's 
origin info is established via the requested resource, then you should get the 
same functionality, but without the same-origin initial restriction. (This may 
be an oversimplification, but it worked for me.)

As to whether we _want_ it, these same folks are apparantely able to live with 
the current restrictions. They may just be deferring the bulk of the worker's 
content to importScripts at present to work-around this limitation.

RE: publish FPWD of HTML Templates; deadline January 31

[Travis Leithead]

> -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
> basis:
> 
>  file/tip/spec/templates/index.html>
> 
> This spec is part of the Web Components deliverable in the group's
> [Charter].
> 
> 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.
> 
> If you have any comments or concerns about this CfC, please reply to
> this e-mail by January 31 at the latest. Positive response is preferred
> and encouraged, and silence will be considered as agreement with the
> proposal.

Microsoft supports this publication.

RE: HTML5 web messaging - postMessage

[Travis Leithead]

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 participants in the working 
group (include myself) would be very hesitant to change their implementations 
due to existing web compatibility.

Having said that, I don't believe that the existing design of postMessage is as 
bad is you make it sound :-)

-Travis

> -Original Message-
> From: Jack (Zhan, Hua Ping) [mailto:jackis...@gmail.com]
> Sent: Sunday, January 27, 2013 7:04 PM
> To: i...@hixie.ch
> Cc: public-webapps@w3.org; wha...@whatwg.org
> Subject: Re: HTML5 web messaging - postMessage
> 
> 
> The postMessage design outlined in the W3C document edited by Ian
> Hickson is not good!
> The design of the cross document messaging by Ian Hickson (Google,
> Inc.) is very bad.
> Even the last version is not good either. The design can be sketched
> here as follows.
> 
> The sender:
> var o = document.getElementsByTagName('iframe')[0];
> o.contentWindow.postMessage('Hello world', 'http://b.example.org/');
> 
> 
> The receiver:
> window.addEventListener('message', receiver, false);
> function receiver(e) {
>   if (e.origin == 'http://example.com') {
> if (e.data == 'Hello world') {
>   e.source.postMessage('Hello', e.origin);
> } else {
>   alert(e.data);
> }
>   }
> }
> 
> 
> This design was messed up by pulling "origin" (a word that some people
> put too much attention more than should).
> Even worse, it requires "o.contentWindow", this is really no
> professional sense. Because of this design, if I open two tabs with
> the same url http://www.google.com/ they are not able to communicate.
> 
> My proposal is discard the "o.contentWindow" part requirement.
> 
> 
> My better proposal
> 
> the sender:
> window.postMessage(messageObject,targetDomain optional,windowIDs
> optional);
> 
> Either targetDomain or windowIDs should present.
> I propose to use ID rather than name (though window can have a name),
> since window.name is not required to be unique within the browser.
> 
> 
> then the user agent(i.e. the browser, such as firefox) will do the
> following
> 
> var e={source: {href: get the sender's window.location.href,
> windowID: unique windowID within this browser
>},
>target: {domain: targetDomain as the sender requested,
> windows: the array of windowID
>},
>data: JSON.parse(JSON.stringtify(messageObject)),
>ts: the timestamp when the post is requested
>   };
> if(windowIDs presents){
>   postEvent to those windows.
> } else {
>   traverse the list of all windows
>   for (each window){
> if(the domain of the window matches the target domain of the message)
> {
> postEvent(e);
>   }
> }
> 
> 
> the receiver
> /*
> return true to indicate to continue to receive message from this sender
> return false to indicate to deny messages from this sender forever
>   (as long as the browser can remember this)
> */
> function receiver(e) {
>   if (e.source is accepted) {
> take the e.data to do whatever as desired.
> return true;
>   }
>   return false;
> }
> 
> window.addEventListener('message', receiver, false);
> 
> 
> 
> if the receiver wants to respond to the sender
> window.postMessage(messageObject,targetDomain optional,windowIDs
> optional);
> targetDomain can be found from e.source.href
> windowID can be found from e.source.windowID
> messageObject is the message object intended to be sent.
> 
> 
> 
> 
> 
> About domain match
> the specification of the target domain can be
> 
> 
> www.google.com
> or google.com  this should match *.google.com
> or com  this should match *.com
> or ""  as for all
> or https://www.google.com
> or http://www.google.com:9876/abc/
> 
> For the last case, if a
> window.location.href=="http://www.google.com:9876/def/";, then they do
> not match.
> 
> About Security
> As long as the receiver check who is the sender which is identified by
> the user agent, there is no security issue at all.
> About context sharing within the browser
> Whether session data should be shared among the different processes of
> the same browser. such as cookies. It seems that firefox does not
> allow 2 different processes unless use different profile.
> 
> Here, one more setting, whether the windowIDs should be unique across
> different process. Within the same process among different tabs, they
> must be unique. If no more than one process is allowed, then such
> setting is not relevant.
> 
> 
> 
> 
> 
> Challenge
> A bad design waste people's energy & time, to promote the better
> solution. I am offering a reward for the 1st one who implement my
> proposal. If you can do this before march 1st, 2013, I will give you
> $10.
> 
> 
> 
> 
> jackis...@gmail.com
>

RE: Re: Keyboard events for accessible RIAs and Games

[Travis Leithead]

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., queryKeyLocaleName(code)?

From: Florian Bösch [mailto:pya...@gmail.com]
Sent: Thursday, January 31, 2013 7:52 AM
To: Hallvord Reiar Michaelsen Steen
Cc: Gary Kacmarcik (Кошмарчик); Webapps WG
Subject: Re: Re: Keyboard events for accessible RIAs and Games

Note that the www-dom WG has objected to querying the localized, accessible, 
user-friendly, keyboard symbol on grounds that it adds more bits (or tiny 
fractions of bits) to the user identifyable information. Contrieved usecases 
and advanced handwaving where employed. This is most likely ending with A) not 
doing accessible, localized, user friendly things or B) doing more user 
unfriendly things like popping "allow ..." dialogs all over. I have forked 
issue B in its own thread, hopefully so that neither A or B will be necessary.

On Thu, Jan 31, 2013 at 11:57 AM, Florian Bösch 
mailto:pya...@gmail.com>> wrote:
Sounds fine to me, any objections to add it to the Event Level 4 spec?

On Thu, Jan 31, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen 
mailto:hallv...@opera.com>> wrote:
> What/where would be a good place to put the API for say queryKeyCap(code) ?
Given that the implementation will have a KeyboardEvent property specified on 
the global object (i.e. window) I'd propose


window.KeyboardEvent.queryKeyCap(code)


which returns a string with the symbol shown on the key.



I.e.


On QWERTY:
KeyboardEvent.queryKeyCap('Digit2') === '2' // true


On AZERTY:

KeyboardEvent.queryKeyCap('Digit2') === 'é' // true


etc.

--
Hallvord R. M. Steen
Core tester, Opera Software

RE: exposing CANVAS or something like it to Web Workers

[Travis Leithead]

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 
supports some set of canvas 2d/3d APIs as appropriate, and can “push” a 
completed frame onto a stack in the internal frame buffer. Thus the worker can 
produce frames as fast as desired.

On the document side, canvas gets a 3rd kind of context—a WorkerRemoteContext, 
which just offers the “pop” API to pop a frame from the internal frame buffer 
into the canvas.

Then you just add some basic signaling events on both ends of the frame buffer 
and you’re good (as far as synchronizing the worker with the document). The 
producer (in the worker) is free to produce multiple frames in advance (if 
desired), while the consumer is able to pop frames when available. You could 
even have the framebuffer depth configurable.

From: Gregg Tavares [mailto:g...@google.com]
Sent: Thursday, February 7, 2013 2:25 PM
To: Ian Hickson
Cc: Charles Pritchard; Web Applications Working Group WG
Subject: Re: exposing CANVAS or something like it to Web Workers

I put up a new proposal for canvas in workers

http://wiki.whatwg.org/wiki/CanvasInWorkers

Please take a look.

This proposal comes from offline discussions with representatives from the 
various browsers as well as input from the Google Maps team. I can post a 
summary here if you'd like but it might be easier to read the wiki

Looking forward to feedback.



On Tue, Jan 8, 2013 at 10:50 AM, Ian Hickson 
mailto:i...@hixie.ch>> wrote:
On Wed, 2 Jan 2013, Gregg Tavares (社ç~T¨) wrote:
>
> Another issue as come up and that is one of being able
> to synchronize updates of a canvas in
> worker with changes in the main page.
For 2D, the intended solution is to just ship the ImageBitamp from the
worker canvas to the main thread via a MessagePort and then render it on
the canvas at the appropriate time.

I don't know how you would do it for WebGL.


> Similarly, let's say you have 2 canvases and are rendering to both in a
> worker.  Does
>
>context1.commit();
>context2.commit();
>
> guarantee you'll see both commits together?
No, unfortunately not. There's no synchronisation between workers and the
main thread (by design, to prevent any possibility of deadlocks), and
there's not currently a batching API.

However, if this becomes a common problem (which we can determine by
seeing if we get bugs complaining about different parts of apps/games
seeming to slide around or generally be slightly out of sync, or if we see
a lot of authors shunting multiple ImageBitmap objects across MessagePort
channels) we can always add an explicit batching API to make this kind of
thing easy.

Note that in theory, for 2D at least, shunting ImageBitmaps across threads
can be as efficient as commit().

--
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

RE: exposing CANVAS or something like it to Web Workers

[Travis Leithead]

>> What would be the advantage? If you wanted to keep dom elements in sync with 
>> the canvas you'd still have to post something from the worker back to the 
>> main thread so the main thread would know to pop.

Well, it's not a fleshed out proposal by any stretch, but you could imagine 
that an event 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: exposing CANVAS or something like it to Web Workers



On Thu, Feb 7, 2013 at 10:46 PM, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
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 
supports some set of canvas 2d/3d APIs as appropriate, and can “push” a 
completed frame onto a stack in the internal frame buffer. Thus the worker can 
produce frames as fast as desired.

On the document side, canvas gets a 3rd kind of context—a WorkerRemoteContext, 
which just offers the “pop” API to pop a frame from the internal frame buffer 
into the canvas.

Then you just add some basic signaling events on both ends of the frame buffer 
and you’re good (as far as synchronizing the worker with the document). The 
producer (in the worker) is free to produce multiple frames in advance (if 
desired), while the consumer is able to pop frames when available. You could 
even have the framebuffer depth configurable.

What would be the advantage? If you wanted to keep dom elements in sync with 
the canvas you'd still have to post something from the worker back to the main 
thread so the main thread would know to pop.



From: Gregg Tavares [mailto:g...@google.com<mailto:g...@google.com>]
Sent: Thursday, February 7, 2013 2:25 PM
To: Ian Hickson
Cc: Charles Pritchard; Web Applications Working Group WG
Subject: Re: exposing CANVAS or something like it to Web Workers

I put up a new proposal for canvas in workers

http://wiki.whatwg.org/wiki/CanvasInWorkers

Please take a look.

This proposal comes from offline discussions with representatives from the 
various browsers as well as input from the Google Maps team. I can post a 
summary here if you'd like but it might be easier to read the wiki

Looking forward to feedback.



On Tue, Jan 8, 2013 at 10:50 AM, Ian Hickson 
mailto:i...@hixie.ch>> wrote:
On Wed, 2 Jan 2013, Gregg Tavares (社ç~T¨) wrote:
>
> Another issue as come up and that is one of being able
> to synchronize updates of a canvas in
> worker with changes in the main page.
For 2D, the intended solution is to just ship the ImageBitamp from the
worker canvas to the main thread via a MessagePort and then render it on
the canvas at the appropriate time.

I don't know how you would do it for WebGL.


> Similarly, let's say you have 2 canvases and are rendering to both in a
> worker.  Does
>
>context1.commit();
>context2.commit();
>
> guarantee you'll see both commits together?
No, unfortunately not. There's no synchronisation between workers and the
main thread (by design, to prevent any possibility of deadlocks), and
there's not currently a batching API.

However, if this becomes a common problem (which we can determine by
seeing if we get bugs complaining about different parts of apps/games
seeming to slide around or generally be slightly out of sync, or if we see
a lot of authors shunting multiple ImageBitmap objects across MessagePort
channels) we can always add an explicit batching API to make this kind of
thing easy.

Note that in theory, for 2D at least, shunting ImageBitmaps across threads
can be as efficient as commit().

--
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

RE: [editing] Is this the right list to discuss editing?

[Travis Leithead]

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: public-webapps@w3.org
Subject: [editing] Is this the right list to discuss editing?

It looks like "Editing API" draft is currently abandoned and there isn't any 
activity on the topic in this list for a while (as far as I can find in the 
archives)...

I am working on editing in IE, have issues of various scale that could benefit 
from a discussion in standards environment. Short of creating a new working 
group (which might be a good idea, but is pretty involved), is this the right 
forum to carry on a conversation? If not, any other suggestions?

Thanks
Alex

RE: Streams and Blobs

[Travis Leithead]

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 tool.  There are times when a developer just needs to 
connect a data stream from a provider to a consumer and doesn't necessarily 
care about seeing the raw bytes.  (The data may not even be available in the 
address space of the process running the developer's script.)  So, I can 
imagine some optimization opportunities when we work with a handle to a stream 
of data rather than the data itself.

-Darin

RE: publish WD of Input Editor Method (IME) API; deadline March 28

[Travis Leithead]

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 publish a new WD of Input Editor Method
> (IME) API, using the following ED as the basis:
> 
> 
> 
> 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 March 28 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
> 

[IME] Preparing some feedback

[Travis Leithead]

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 system's IME (vs. a 
JavaScript-implemented IME). Long term, we think that it makes sense to have an 
IME API Spec that supports both system and JavaScript-based IME scenarios. We 
would like to work with you to land on a unified design that includes the right 
set of API for working with both system and JavaScript-based IMEs. We'll write 
up a proposal to start the discussion.

Thanks,
Travis

RE: Reminder: Please register for Face to face by Friday

[Travis Leithead]

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: Wednesday, April 3, 2013 3:49 AM
To: public-webapps WG
Subject: Reminder: Please register for Face to face by Friday

Hi folks,

a reminder that Paypal (our meeting hosts) have asked us to have registration 
done by Friday to help their planning.

If you expect to attend, but haven't got around to telling us, please do so at 
https://www.w3.org/2002/09/wbs/42538/webapps-april-2013/

If you are hoping to come but unable to confirm by Friday, please go ahead and 
register now, and note in the general comments section that you are not 
confirmed and when you expect to know for sure.

If you do not register by the deadline, and later decide you want to attend, 
please contact Art and me, and we will see what we can do.

cheers

Chaals

--
Chaals - standards declaimer

RE: Reminder: Please register for Face to face by Friday

[Travis Leithead]

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 is the same, 
although I think the building number is different).

On Wed, Apr 3, 2013 at 3:06 PM, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
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<mailto:w...@chaals.com>]
Sent: Wednesday, April 3, 2013 3:49 AM
To: public-webapps WG
Subject: Reminder: Please register for Face to face by Friday

Hi folks,

a reminder that Paypal (our meeting hosts) have asked us to have registration 
done by Friday to help their planning.

If you expect to attend, but haven't got around to telling us, please do so at 
https://www.w3.org/2002/09/wbs/42538/webapps-april-2013/

If you are hoping to come but unable to confirm by Friday, please go ahead and 
register now, and note in the general comments section that you are not 
confirmed and when you expect to know for sure.

If you do not register by the deadline, and later decide you want to attend, 
please contact Art and me, and we will see what we can do.

cheers

Chaals

--
Chaals - standards declaimer

RE: [webcomponents] self-documenting component.html files

[Travis Leithead]

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 are 
probably already available.

From: Mike Kamermans [mailto:niho...@gmail.com]
Sent: Friday, April 5, 2013 4:51 AM
To: public-webapps@w3.org
Subject: [webcomponents] self-documenting component.html files

Hi all,

a short while back I'd been working on a web components demo, with one result 
being a components.html that also acted as its own documentation (since as a 
components.html anything that isn't 'more components', script, or element, gets 
ignored), which sparked a small discussion on how self-documentation might be 
done at all. I've been trying to think of some way to do this while staying 
within the custom element specification, but I keep ending up with needing bits 
that aren't in the spec. So, let me just list what I have, and perhaps some of 
the bits are useful enough for further discussion, while some other bits can be 
shown to be silly, with much better alternatives. This is what I come up with 
if the idea is to make a custom element as self-descriptive as 
possible:https://gist.github.com/Pomax/5304557

One obvious difference is that for attributes that you actually want to do 
anything with (i.e., you're creating your own custom audio element, and setting 
the src should reload the data and start autoplaying or something), you want to 
be able to specify the getter/setter and events that will occur. I didn't see 
anything in the webcomponents/custom element specs that would currently allow 
for this. I did hear from Scott Miles that some work had already been done, and 
that the custom element shim now already supports an attributeChangedCallback 
function to do just this thing, but that's a bit broader level than specific 
get/set behaviour on attributes. Consider my gist to be some thinking out loud 
=)

Also, out of the discussion on fully documenting vs. docstripped (essentially 
the develop vs. production question): I'd make this something that people who 
deploy their components for others to use are responsible for in the same way 
they are responsible for full vs. minified javascript libraries right now. If 
you only put up a fully-documented components.html you're probably 
inconveniencing your audience, but having it available next to a minified 
version is great for when people want to look something up - they'll know where 
to go by simply removing the ".min" part in a CND'ed components.html URL. So as 
long as the minification process is easily performed, that should be enough (so 
my gist also contains a description of what "minification" would look like)

- Mike "Pomax" Kamermans

RE: [webcomponents] self-documenting component.html files

[Travis Leithead]

By "we" do you mean Presto-now-Blink? I expect there's too much web compat risk 
to remove Mutation Events anytime soon from a browser implementation.

-Original Message-
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of 
Anne van Kesteren
Sent: Friday, April 5, 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  
wrote:
> 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 are probably already available.

We are planning on removing mutation events so anything that must depend on 
them is a non-starter.


--
http://annevankesteren.nl/

RE: [IME] Preparing some feedback

[Travis Leithead]

Kenji, et al.:



We appreciate the work you've put into this IME API spec so far and hope that 
this feedback will help further improve it! Jianfeng Lin, another program 
manager from the IE team put the following feedback together, as well as 
drafted the proposal, which I've uploaded to the mercurial server for easy 
viewing at: 
https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html. The 
proposal contains API designs that are the result of various feedback from 
several different teams inside of Microsoft including use cases from Microsoft 
Japan team, and designs from the folks who work on the in-box Windows IMEs and 
the IME integration layer inside Internet Explorer.



Thanks for taking the time to review,

-Travis



Some Points of feedback:



Composition Dictionary



dictionary Composition {

readonly attribute Nodetext;

readonly attribute Range   caret;

};



We can see exposing IME clauses as child nodes of "text" node, and making them 
real DOM nodes with styles being useful for a JS-based IME as the IME needs to 
tell the web application how to render the composition, but if JS IME is not a 
goal, is there any other scenarios that will benefit from this? If not, how 
about a simple design that expose the text being composed as DOMString?



For "caret" attribute, if it's for enabling JS-based IME, then exposing the 
caret ranges of IME clauses is helpful, but if it's not for JS IME, is there 
any other usage? We understand that web applications want to know about the 
whole string of the tentative composition, but we are not sure in which case 
they want to know how the whole tentative composition string is divided into 
several parts. Another issue is that the range type only tells the start and 
end offsets of the composition from its immediate parent. Web application 
usually wants to know the offset from the beginning of the text field so that 
it could combine the composition alternate with the text before it to create a 
full text string. But the beginning of the text field can be up in the parent 
tree if it's a contentEditable element and requires JavaScript code to trace up 
in the parent tree to get the right offset.



So instead of a dictionary type for composition, we suggest this directly under 
InputMethodContext interface. Please let us know if you have scenarios that 
need to be the other way.



readonly attribute DOMStringcompositionText;

readonly attribute unsigned long   compositionStartOffset;

readonly attribute unsigned long   compositionEndOffset;



Beyond that, we also propose exposing the composition alternatives. For example 
a search engine can use the current non-committed alternatives to fine tune the 
real-time search suggestion list.



sequencegetCompositionAlternatives ();



For the following in your proposal, is there any usage scenario besides 
enabling IME on non-editable elements like canvas?



 attribute boolean   enabled;

 void   setCaretRectangle (Node anchor, long x, long y, long w, long h);

 boolean   open ();



As we raised in the following discussion threads before, we don't think using 
canvas to create an editor is the right way to go. Please let's discuss about 
issues you are trying to solve and find out a better solution.

http://lists.w3.org/Archives/Public/public-html/2011Nov/0210

http://lists.w3.org/Archives/Public/public-html/2011Dec/0157.html

http://lists.w3.org/Archives/Public/public-canvas-api/2012JanMar/0029.html



For the following function



 void   setExclusionRectangle (Node anchor, long x, long y, long w, long h);



We recommend replacing with this



 ClientRect   getCandidateWindowClientRect ();



Because although setExclusionRectangle can ensure that the IME candidate window 
doesn't overlap with some specific UI that the web application doesn't want to 
be occluded (e.g. search suggestion list), it doesn't seem to be able to ensure 
that the two UIs layout in a desirable way. For example, if the web application 
wants to render a search suggestion list that docks below the IME candidate 
window and aligns nicely without gap, it can't do so with 
setExclusionRectangle()  because it doesn't know where is the candidate window, 
how tall it is below the text field, and whether it is horizontally shifted to 
follow the caret position. Therefore we are proposing 
getCandidateWindowClientRect together with a group of CSS properties to give 
more flexibility for the UI design.



We also propose several new APIs in InputMethodContext, CSS properties and 
attributes to provide more information and more control around IME. Please 
refer to the HTML version of our proposal for more detail.



-Jianfeng Lin




From: Kenji Baheux [mailto:kenjibah...@google.com]
Sent: Tuesday, April 02, 2013 4:32 PM
To: Travis Leithead
Cc: hb...@google.com; ko...@google.com; public-web

[WebIDL] Bugs - which are for 1.0 and which are for Second Edition?

[Travis Leithead]

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 are for which spec(s)?

Do you have any suggestions for making this easier to track going forward?

Thanks,
-Travis

RE: publish FPWD of UI Events; deadline May 4

[Travis Leithead]

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 to 
publish a First Public Working Draft of the UI Events spec using the following 
ED as the basis:

   

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.

If you have any comments or concerns about this CfC, please reply to this 
e-mail by May 4 at the latest. Positive response is preferred and encouraged, 
and silence will be considered as agreement with the proposal.

-Thanks, AB

 Original Message 
Subject:ACTION-682: Start a CfC for FPWD of UI Events (and make sure 
it has a Bugzilla component) (Web Applications Working Group)
Date:   Thu, 25 Apr 2013 17:29:27 +
From:   ext Web Applications Working Group Issue Tracker 

Reply-To:   Web Applications Working Group 
To: 



ACTION-682: Start a CfC for FPWD of UI Events (and make sure it has a Bugzilla 
component) (Web Applications Working Group)

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

On: Arthur Barstow
Due: 2013-05-02

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

Proposal for a DOM L3 Events Telecon

[Travis Leithead]

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?

If not, I’m open to suggestions!
-Travis

RE: Proposal for a DOM L3 Events Telecon

[Travis Leithead]

I’d like to be sure we get Masayuki in our discussions as this represents at 
least a trio of implementors on the call.

The 4pm PDT (Tue) / 8am JST (Wed) will work for me. I’ll set up the telco 
details and send them out.

From: Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com]
Sent: Wednesday, 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 if not.

On Wed, May 1, 2013 at 6:30 PM, Wez mailto:w...@google.com>> 
wrote:
Hi guys, mind if I tag along with Gary on the call?

On 30 April 2013 13:46, Gary Kačmarčík (Кошмарчик) 
mailto:gary...@google.com>> wrote:
On Mon, Apr 29, 2013 at 12:59 PM, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
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?

Note that 11am PDT = 3am JST.  If Masayuki is interested in joining, we should 
pick a late afternoon PDT time:
   4pm PDT (Tue) = 8am JST (Wed)
   5pm PDT (Tue) = 9am JST (Wed)





--
Takayoshi Kochi

RE: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition?

[Travis Leithead]

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 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 are for which spec(s)?

No, I've just been making changes to whichever version they seemed to apply to 
as I got to them.

> Do you have any suggestions for making this easier to track going forward?

IIRC the Version field in Bugzilla applies to the Product, not the Component, 
so I think we can't use that.  How about just putting something in the 
Whiteboard field, like "[v1]"?

RE: Proposal for a DOM L3 Events Telecon

[Travis Leithead]

Yeah, we'll be on #webapps, and I can invite Zakim. I can also provide call-in 
instructions for the Microsoft bridge from irc.

-Original Message-
From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] 
Sent: Tuesday, May 7, 2013 3:01 PM
To: Masayuki Nakano; Gary Kačmarčík (Кошмарчик)
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 (Кошмарчик) 
 wrote:

> On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano
> wrote:
>
>> Hello, sorry for the big delay due to my business trip and holiday 
>> week of Japan.
>>
>> I'm available on either schedule. When I join the telecon, how can I 
>> join it? Skype or something?
>>
>
> Excellent question - I'm wondering the same thing. Will this be using 
> Zakim
> (http://www.w3.org/2002/01/UsingZakim) and will we have an IRC channel 
> as well?

We can certainly ask for a zakim slot.

I strongly suggest using IRC as well, especially to help Masayuki follow (which 
means someone needs to scribe...)

cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
   cha...@yandex-team.ru Find more at http://yandex.com

WebApps DOM3 Events Wiki page

[Travis Leithead]

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 section for Meetings, and a place 
to propose an agenda.

The minutes span the mightnight rollover on some server, so they are not 
contiguous, and I failed to find a way to automatically stich them together, so 
they are in two parts. Art, I’d love any pointers to how to clean them up… ☺

Thanks everyone for the call. See you in two weeks.

RE: Overlap between StreamReader and FileReader

[Travis Leithead]

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
> 
> On Thu, May 16, 2013 at 5:58 PM, Takeshi Yoshino 
> wrote:
> > StreamReader proposed in the Streams API spec is almost the same as
> > FileReader. By adding the maxSize argument to the readAs methods (new
> > methods or just add it to existing methods as an optional argument)
> > and adding the readAsBlob method, FileReader can cover all what
> > StreamReader provides. Has this already been discussed here?
> >
> > I heard that some people who had this concern discussed briefly and
> > were worrying about derailing File API standardization.
> >
> > We're planning to implement it on Chromium/Blink shortly.
> 
> The Streams API
> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm is no good as
> far as I can tell. We need something else for IO. (See various threads on this
> list by me.)
> 
> Alex will tell you the same so I doubt it'd get through Blink API review.

Since we have Streams implemented to some degree, I'd love to hear suggestions 
to improve it relative to IO. Anne can you summarize the points you've made on 
the other various threads?

RE: Overlap between StreamReader and FileReader

[Travis Leithead]

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
> On Thu, May 16, 2013 at 6:31 PM, Travis Leithead
>  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 the points
> you've made on the other various threads?
> 
> I recommend reading through
> http://lists.w3.org/Archives/Public/public-
> webapps/2013JanMar/thread.html#msg569
> 
> Problems:
> 
> * Too much complexity for being an Blob without synchronous size.
> * The API is bad. The API for File is bad too, but we cannot change it, this
> however is new.
> 
> And I think we really want an IO API that's not about incremental, but can
> actively discard incoming data once it's processed.

Thanks, I'll review the threads and think about this a bit more.

RE: [editing] nested contenteditable

[Travis Leithead]

As far as I know, there is no actively maintained editing spec at the moment. 
Aryeh's document is a great start but by no means should it be considered 
complete, or the standard to which you should target an implementation... I 
think we would [currently] prefer to discuss specific issues here on the 
mailing list until a regular editor can be found-so thanks for bringing this up!

By the way, what you suggest sounds reasonable for the behavior.

From: johannesw...@gmail.com<mailto:johannesw...@gmail.com> 
[mailto:johannesw...@gmail.com] On Behalf Of Johannes Wilm
Sent: Tuesday, May 28, 2013 6:36 AM
To: public-webapps@w3.org<mailto:public-webapps@w3.org>; 
ro...@w3.org<mailto:ro...@w3.org>; Alex Mogilevsky; Travis Leithead; 
a...@aryeh.name<mailto:a...@aryeh.name>; 
yo...@chromium.org<mailto:yo...@chromium.org>
Subject: [editing] nested contenteditable

Hey,
is there any progress on finding out who is to maintain this spec: 
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still a 
fulltime student?

There is an effort at Chromium to make deletion of non-editable subelements 
work according to the spec, but the spec doesn't seem to anything about this.

See: https://code.google.com/p/chromium/issues/detail?id=238000


Who could we ask to get the sepcification updated with information about this?

Our current suggestion is that backspacing/deleting into it selects it, and a 
second hit on backspace/delete will remove it. The most important to me though 
is to have clarity on this.


--
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com<http://www.fiduswriter.com/>

RE: [webidl] Add a [Maplike] tag?

[Travis Leithead]

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 interface at

from an "object map"* to an actual Map, so that it uses a (soon-to-be) familiar 
API and interoperates with other code that works on Maps.  I recently talked 
about this on es-discuss a bit (see the threads "Overriding Map/etc with 
get/set hooks?" and "Non-generic traps for non-generic objects"), and the 
conversation seems to have ended with the conclusion "do it in WebIDL instead". 
 So!

I propose that we have some way to tag an interface as "map-like".
This means that it exposes the same methods and properties as Map and has Map 
on the prototype chain, but specifies potentially custom behavior for 
getting/setting/deleting values.

This could be based on the gist at
, in terms of defining the 
operations.  The spec author would have to define similar things to today's 
"object maps" - a list of map tuples (for the iterator), a mapgetter, a 
mapsetter, and a mapdeleter.

For my specific example, I'd define:
* the list of map tuples are the custom properties defined on the associated 
CSSStyleRule,
* the mapgetter coerces the argument to string, mangles it appropriately, then 
calls getPropertyValue() on the associated CSSStyleRule,
* the mapsetter coerces both arguments to strings, mangles the first 
appropriately, then calls setProperty() on the associated CSSStyleRule,
* the mapdeleter coerces+mangles the argument, then calls
removeProperty() on the associated CSSStyleRule.

There are a lot of other interfaces that could benefit from being changed to 
Maps, so I think there's an obvious strong argument for this being used in the 
future.  For example, we're having a conversation about the interface for 
@font-feature-values, and it would likely benefit from this as well.

While we're at it, do the same thing for "set-like", which is the same but for 
the Set class.

~TJ

* Why change from an "object map"?  This kind of interface is subject to 
accidental or malicious corruption when things are added to any of its 
prototypes (including Object.prototype), where it *looks* like there's a value 
on it, but there really isn't, and the only way to actually set that key on the 
actual object map is to use Object.defineProperty().  It's also harder to 
extend in the future; if you ever want to add a method or property to it, you 
have to be careful about existing usage possible using your desired name as a 
key, and add a restriction disallowing that key from being used to the 
appropriate spec.  Maps gets around all these issues nicely.

RE: inputmode attribute

[Travis Leithead]

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 Kochi (河内 隆仁) [mailto:ko...@google.com]
Sent: Monday, June 3, 2013 2:26 AM
To: public-webapps
Subject: inputmode attribute

Hi all,

For IME API (http://www.w3.org/TR/ime-api/), we got comment from Microsoft to 
change some of types
from inputmode, which is currently defined as
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute

and the new proposal is
https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#inputmode-attribute

As Mounir already discussed in WHAT WG list back in February,
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038914.html
there was a discussion to separating mode and script for the attribute.

Can we discuss what the attribute should be here in this list?

--
Takayoshi Kochi

[DOM3Events] telco minutes published

[Travis Leithead]

Gary, Masayuki, Kochi, et al.,

The minutes for our teleconference have been posted to the wiki [1] (along with 
previous meeting minutes). Thanks everyone for another successful call. As 
stated, I hope we can get the draft read for publication before TPAC!

[1] http://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings#DOM_3_Events

RE: [D3E] Seeking status and plan

[Travis Leithead]

Yes, we are working through the last of our issues and hope to be ready to 
issue a publication request. We've made many improvements since the last 
publication, and with UI Events waiting in the wings, and multiple UAs starting 
to implement we think we may at last be approaching CR. We'll know more in the 
next couple of weeks.

Thanks!

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Wednesday, October 2, 2013 9:29 AM
To: Travis Leithead; "Gary Kacmarcik (Кошмарчик)"
Cc: public-webapps
Subject: [D3E] Seeking status and plan

Hi Travis and Gary,

If any of the data for D3E in [PubStatus] is not accurate, please provide 
corrections.

Also, please provide a short update re the plan and time-frame to publish a new 
LCWD. [Hint: it would be really nice to get a new LCWD of D3E published as soon 
as possible ;-)]

-Thanks, ArtB

[PubStatus] <http://www.w3.org/2008/webapps/wiki/PubStatus>

RE: [uievents] Seeking status and plans

[Travis Leithead]

I think we're spending most of our energy on DOM3Events at the moment, so I 
don't know how much this spec has changed. Gary should chime-in, but if there's 
material changes, it would be nice to re-publish it before TPAC.

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Wednesday, October 2, 2013 9:32 AM
To: "Gary Kacmarcik (Кошмарчик)"; Travis Leithead
Cc: public-webapps
Subject: [uievents] Seeking status and plans

Hi Gary, Travis,

If any of the data for the UI Events spec in [PubStatus] is not accurate, 
please provide corrections.

Also, if you have any new information re your plans for the spec - last 
published 25-July-2013 - or the spec's status with respect to being feature 
complete, implementation status, etc., please let us know.

-Thanks, ArtB

[PubStatus] <http://www.w3.org/2008/webapps/wiki/PubStatus>

RE: Shadow DOM and Fallback contents for images

[Travis Leithead]

From: Jonas Sicking [mailto:jo...@sicking.cc] 

> Though I'd also be interested to hear how other implementations feel about 
> the Gecko solution of allowing selection to be comprised of multiple DOM 
> Ranges.

Seems totally reasonable; only problem is that pretty much all content on the 
web assumes one range per selection: getSelection().getRangeAt(0); and this 
programmatic selection-extraction would miss part of the selection if it were 
broken up. Ideally not the what that code should be doing, but since 
user-multi-selection isn't interoperable, there's no critical mass to change 
this practice, in practice.

Request for publication: DOM L3 Events & UI Events

[Travis Leithead]

The editors of the DOM Level 3 Events specification have reached a milestone 
where we believe most of the major open issues are now resolved in the editor's 
draft, and we would like to issue a call to publish an updated *working draft* 
of the spec for wider review. (It has also been quite a while since the working 
draft was updated, and we'd like to have it be more current for TPAC.)

At the same time, we've made a few updates to the UI Events spec, and feel that 
now would be an appropriate time to get that document re-published as a working 
draft as well.

Note: there are only a few remaining issues in the DOM L3 Events spec which we 
hope to resolve at or around TPAC in order to be prepared to request a last 
call working draft (number 4, I believe, but who's counting?) by end-of-year.

Chairs: can you assist us in starting the publication process for both *DOM L3 
Events* and *UI Events*? Gary will take charge in preparing the documents.

Thanks!

RE: publish LCWD of DOM Parsing and Serialization; deadline November 25

[Travis Leithead]

If possible, I'd like to delay this CfC, for a week--I have some major updates 
to the ED in-flight, and I want to make sure we base the CfC on the right ED 
content :-)

Hopefully this is workable to the group. Thanks!

-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Monday, November 18, 2013 4:00 AM

This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and 
Serialization, using the following ED as the basis:

   

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 the significance/meaning of a LCWD:

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

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant technical 
requirements (e.g., of the charter or requirements document) in the Working 
Draft;

* the Working Group believes that it has satisfied significant dependencies 
with other groups;

* other groups SHOULD review the document to confirm that these dependencies 
have been satisfied. In general, a Last Call announcement is also a signal that 
the Working Group is planning to advance the technical report to later maturity 
levels.
]]

Currently, this spec has one Editorial bug [18939] that is open and Travis will 
fix this before the LCWD is published.

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

The proposed review period for this LC is 4 weeks.

Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, 
I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, 
please let me know.

-Thanks, AB

[18939] 

 Original Message 
Subject:ACTION-701: Start a cfc to publish lcwd of dom parsing and 
serialization (Web Applications Working Group)
Date:   Mon, 11 Nov 2013 01:59:39 +
From:   ext Web Applications Working Group Issue Tracker 

Reply-To:   Web Applications Working Group 
To: 



ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web 
Applications Working Group)

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

On: Arthur Barstow
Due: 2013-11-18

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

RE: publish LCWD of DOM Parsing and Serialization; deadline November 25

[Travis Leithead]

I've finished the major updates. Today's ED draft at:
https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html
should be ready to use as the baseline for the Last Call CfC.

Thanks, 
Travis

-Original Message-----
From: Travis Leithead 
Sent: Monday, November 18, 2013 11:26 AM
To: Webapps WG
Subject: RE: publish LCWD of DOM Parsing and Serialization; deadline November 25

If possible, I'd like to delay this CfC, for a week--I have some major updates 
to the ED in-flight, and I want to make sure we base the CfC on the right ED 
content :-)

Hopefully this is workable to the group. Thanks!

-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Monday, November 18, 2013 4:00 AM

This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and 
Serialization, using the following ED as the basis:

   <https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html>

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 the significance/meaning of a LCWD:

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

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant technical 
requirements (e.g., of the charter or requirements document) in the Working 
Draft;

* the Working Group believes that it has satisfied significant dependencies 
with other groups;

* other groups SHOULD review the document to confirm that these dependencies 
have been satisfied. In general, a Last Call announcement is also a signal that 
the Working Group is planning to advance the technical report to later maturity 
levels.
]]

Currently, this spec has one Editorial bug [18939] that is open and Travis will 
fix this before the LCWD is published.

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

The proposed review period for this LC is 4 weeks.

Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, 
I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, 
please let me know.

-Thanks, AB

[18939] <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938>

 Original Message 
Subject:ACTION-701: Start a cfc to publish lcwd of dom parsing and 
serialization (Web Applications Working Group)
Date:   Mon, 11 Nov 2013 01:59:39 +
From:   ext Web Applications Working Group Issue Tracker 

Reply-To:   Web Applications Working Group 
To: 



ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web 
Applications Working Group)

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

On: Arthur Barstow
Due: 2013-11-18

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

RE: publish LCWD of DOM Parsing and Serialization; deadline November 25

[Travis Leithead]

Resolved it today. Took one more change to the ED draft to update the SOTD, 
Acknowledgements section, and document headers.

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Tuesday, November 26, 2013 5:46 AM
To: Travis Leithead
Cc: Webapps WG
Subject: Re: publish LCWD of DOM Parsing and Serialization; deadline November 25

Travis - what is the plan for 
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938>?

-Thanks, AB

On 11/25/13 7:23 PM, ext Travis Leithead wrote:
> I've finished the major updates. Today's ED draft at:
> https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html
> should be ready to use as the baseline for the Last Call CfC.
>
> Thanks,
> Travis
>
> -----Original Message-
> From: Travis Leithead
> Sent: Monday, November 18, 2013 11:26 AM
> To: Webapps WG
> Subject: RE: publish LCWD of DOM Parsing and Serialization; deadline November 
> 25
>
> If possible, I'd like to delay this CfC, for a week--I have some major 
> updates to the ED in-flight, and I want to make sure we base the CfC on the 
> right ED content :-)
>
> Hopefully this is workable to the group. Thanks!
>
> -
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Monday, November 18, 2013 4:00 AM
>
> This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and 
> Serialization, using the following ED as the basis:
>
> <https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html>
>
> 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 the significance/meaning of a LCWD:
>
> [[
> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
>
> Purpose: A Working Group's Last Call announcement is a signal that:
>
> * the Working Group believes that it has satisfied its relevant technical 
> requirements (e.g., of the charter or requirements document) in the Working 
> Draft;
>
> * the Working Group believes that it has satisfied significant dependencies 
> with other groups;
>
> * other groups SHOULD review the document to confirm that these dependencies 
> have been satisfied. In general, a Last Call announcement is also a signal 
> that the Working Group is planning to advance the technical report to later 
> maturity levels.
> ]]
>
> Currently, this spec has one Editorial bug [18939] that is open and Travis 
> will fix this before the LCWD is published.
>
> If you have any comments or concerns about this CfC, please send them to 
> public-webapps@w3.org by November 25 at the latest. Positive response is 
> preferred and encouraged and silence will be considered as agreement with the 
> proposal.
>
> The proposed review period for this LC is 4 weeks.
>
> Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, 
> I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, 
> please let me know.
>
> -Thanks, AB
>
> [18939] <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938>
>
>  Original Message 
> Subject:  ACTION-701: Start a cfc to publish lcwd of dom parsing and
> serialization (Web Applications Working Group)
> Date: Mon, 11 Nov 2013 01:59:39 +
> From: ext Web Applications Working Group Issue Tracker
> 
> Reply-To: Web Applications Working Group 
> To:   
>
>
>
> ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web 
> Applications Working Group)
>
> http://www.w3.org/2008/webapps/track/actions/701
>
> On: Arthur Barstow
> Due: 2013-11-18
>
> 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
>
>
>
>

RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

[Travis Leithead]

Fair enough. 

By the way, I don't see the reference to DOM L2 Core in the Editor's draft 
(there's a reference to it in the source code, but not in the rendered HTML). I 
did end up talking about the (historical) internalSubset property of the 
Doctype object for serialization--since browsers will include it if they 
support it. Is this what you're referring to?

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Wednesday, November 27, 2013 6:19 AM
To: Anne van Kesteren
Cc: public-webapps
Subject: Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline 
December 3

On 11/27/13 8:52 AM, ext Anne van Kesteren wrote:
> On Wed, Nov 27, 2013 at 1:41 PM, Arthur Barstow  wrote:
>> WebApps has a relatively long history of giving Editors quite a bit 
>> of "artistic freedom" aka edit-first-review-later policy so I don't 
>> see what Travis has done as anything "different". (BTW, this is codified in 
>> Webapps'
>> Work Mode document 
>> .)
>>
>> If there are any technical issues with the spec, please do raise them 
>> on the list and/or create bugs.
> I think if you plan to reinstate features planned for removal or add 
> dependencies on specifications thought obsolete you ought to have at 
> least brought that up for discussion with the WG. Substantial changes 
> to drafts should have some kind of trail, even if it's the editor 
> filing a bug or emailing the list post commit.

Yes, I agree and I just updated that section accordingly.

All, and Editor's in particular, please note:

[[


Editors in this Working Group have wide freedom to update (add, change,
delete) text in Editor's Drafts without explicit consensus from the group. This 
method is referred to as Edit First and Review Later and is contrary to other 
WGs that follow a Review First and Edit Later editing model. Despite this 
policy, when a substantive change is made to a specification (for example, 
adding or removing a featured, adding a normative reference, etc.), Editors are 
expected to create a paper trail for the change such as creating a bug report 
and/or notifying the appropriate e-mail list.
]]

-Thanks, ArtB

RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

[Travis Leithead]

Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23936 to track this LC 
comment :-)

-Original Message-
From: Travis Leithead 
Sent: Wednesday, November 27, 2013 9:23 AM
To: 'Arthur Barstow'; Anne van Kesteren
Cc: public-webapps
Subject: RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline 
December 3

Fair enough. 

By the way, I don't see the reference to DOM L2 Core in the Editor's draft 
(there's a reference to it in the source code, but not in the rendered HTML). I 
did end up talking about the (historical) internalSubset property of the 
Doctype object for serialization--since browsers will include it if they 
support it. Is this what you're referring to?

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Wednesday, November 27, 2013 6:19 AM
To: Anne van Kesteren
Cc: public-webapps
Subject: Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline 
December 3

On 11/27/13 8:52 AM, ext Anne van Kesteren wrote:
> On Wed, Nov 27, 2013 at 1:41 PM, Arthur Barstow  wrote:
>> WebApps has a relatively long history of giving Editors quite a bit 
>> of "artistic freedom" aka edit-first-review-later policy so I don't 
>> see what Travis has done as anything "different". (BTW, this is codified in 
>> Webapps'
>> Work Mode document
>> <http://www.w3.org/2008/webapps/wiki/WorkMode#Editors>.)
>>
>> If there are any technical issues with the spec, please do raise them 
>> on the list and/or create bugs.
> I think if you plan to reinstate features planned for removal or add 
> dependencies on specifications thought obsolete you ought to have at 
> least brought that up for discussion with the WG. Substantial changes 
> to drafts should have some kind of trail, even if it's the editor 
> filing a bug or emailing the list post commit.

Yes, I agree and I just updated that section accordingly.

All, and Editor's in particular, please note:

[[
<http://www.w3.org/2008/webapps/wiki/WorkMode#Editors>

Editors in this Working Group have wide freedom to update (add, change,
delete) text in Editor's Drafts without explicit consensus from the group. This 
method is referred to as Edit First and Review Later and is contrary to other 
WGs that follow a Review First and Edit Later editing model. Despite this 
policy, when a substantive change is made to a specification (for example, 
adding or removing a featured, adding a normative reference, etc.), Editors are 
expected to create a paper trail for the change such as creating a bug report 
and/or notifying the appropriate e-mail list.
]]

-Thanks, ArtB

RE: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3

[Travis Leithead]

Internal Subset:

The latest Firefox, Chrome and IE all support the doctype.internalSubset 
property in the DOM. Their behavior diverges slightly when parsing and 
serializing:
For HTML parsing the internalSubset is ignored as specified in HTML5. This 
property returns null. For XHTML parsing, IE and Firefox parse the literal 
contents of the internal subset up until the closing angle bracket into the 
'internalSubset' property. Chrome does not.
For Serializing, if the browser has stored an internalSubset property, it is 
serialized as part of the Doctype.

Since this is two out of three main browsers, I added this serialization step 
as optional, conditional on the browser storing an internalSubset. If browsers 
choose to remove their internalSubset support, then they will still be 
conformant to this specification.

CDATASection:

From what I can determine from the DOM spec (DOM4), the CDATASection object has 
been removed to "simplify the DOM platform" (Section 10.2). Which seems nice 
since CDATASections cannot be parsed by the HTML parser defined in HTML5. 
However, CDATASection (as a parser concept) is alive and well in XHTML and XML 
documents and as such these get parsed into CDATASection objects today on all 
browsers. In these cases (XHTML & XML documents), I presume that the DOM spec 
would like browsers to store parsed CDATASection content as Text objects? 
Today, no browser does this.

There shouldn't be any material problem that I can see for browsers to treat 
XHTML/XML parsed CDATASections as Text. Characters accepted without escaping in 
CDATASections like "<" and ">" would be put into a Text node literally, and 
then escaped out on serialization. This will make serialized text containing 
lots of angle brackets much larger than the original text content, but that's 
not a technical downside. There may be compat risk to making this change, but 
that's another story. Since it doesn't hurt browsers to leave it in the 
platform, I wonder whether there are browser implementations who want to make 
this change? It certainly isn't on IE's radar. 

I suppose I could make CDATASection serialization a historical (optional) 
behavior for platforms that preserve the identity of CDATASection objects in 
the DOM. I hate to pull it out altogether, because this is something that all 
platforms support interoperably today. Leaving it in the spec is not a problem 
because once a browser starts converting CDATASection input to Text, then the 
identity of the object to serialize is now Text, and the CDATASection 
serialization rules don't apply.

It seems like there may be a separate concern with the references though. I 
don't currently make a reference to DOM L3 Core for CDATASection or 
internalSubset. Should I be?

-Travis

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] 
On Wed, Nov 27, 2013 at 5:22 PM, Travis Leithead 
 wrote:
> I did end up talking about the (historical) internalSubset property of the 
> Doctype object for serialization--since browsers will include it if they 
> support it. Is this what you're referring to?

Do all browsers include it or only some?

I was referring to CDATASection. I had not noticed this doctype-related change, 
which also seems substantive. If you want to change the tree model relative to 
DOM, you really ought to argue that against the DOM specification, and not make 
willy-nilly changes on the serialization side.

--
http://annevankesteren.nl/

Refactoring SharedWorkers out of Web Workers W3C spec

[Travis Leithead]

During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove Shared 
Workers from the W3C Web Workers spec [3] in order for the spec to pass the 
first of the two stated CR exit criteria in the spec itself.

It is my intention to start this work soon. My question for the group-should I 
transplant the Shared Worker spec prose into a separate REC-track editor's 
document, or simply remove it outright? (Removing it would be easier of course 
:0)



[1] http://www.w3.org/2008/webapps/track/actions/709

[2] http://krijnhoetmer.nl/irc-logs/webapps/20131112#l-661
[3] http://www.w3.org/TR/2012/CR-workers-20120501/

RE: Refactoring SharedWorkers out of Web Workers W3C spec

[Travis Leithead]

From: Arthur Barstow [mailto:art.bars...@nokia.com] 
> wrote:
> Travis - would you please add results for IE?

Done.
Note: IE's implementation generates a Syntax Error on 'new Worker("#")' which 
causes a huge chunk of these tests to fail, where otherwise, I think we would 
be passing them if we could actually start the worker.

[IR] 
[Tests] 
[Mins] 

RE: Refactoring SharedWorkers out of Web Workers W3C spec

[Travis Leithead]

Thanks James. I'll wait till the broken tests are fixed to re-review the IE 
results.

From: James Graham
Sent: 12/16/2013 9:55 AM
To: public-webapps@w3.org
Subject: Re: Refactoring SharedWorkers out of Web Workers W3C spec

On 16/12/13 16:43, Arthur Barstow wrote:
> On 12/16/13 11:20 AM, ext James Graham wrote:
>> On 12/12/13 16:20, James Graham wrote:
>>> On 12/12/13 15:13, Boris Zbarsky wrote:
 On 12/11/13 8:42 AM, Arthur Barstow wrote:
> [IR] 

 Looking at this link, there are passes marked for obviously incorrect
 tests (e.g. see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24077
 which says that
 http://w3c-test.org/web-platform-tests/master/workers/interfaces/DedicatedWorkerGlobalScope/postMessage/second-argument-null.html


 should fail in any conformant UA, but it's marked as passing in Opera
 and Chrome.

 So presumably we will need to rerun the tests in all UAs again once all
 the bugs have been fixed, yes?
>>>
>>> Yes. I have found another couple of trivial bugs in the tests which I
>>> will fix up. I will also have a got at fixing Ms2ger's test runner to
>>> work in a better way, sort out some way to automate the visual output,
>>> and hopefully we can generate a new implementation report with minimal
>>> effort.
>>
>> So, I made a sample implementation report [1] using an in-browser test
>> runner based on Ms2ger's earlier work (see public-test-infra for more
>> details). The browsers are those that happened to be on my computer. I
>> don't intend for anyone to take these results as authoritative, and
>> more work is needed, but it is much better than editing a wiki. And
>> has revealed yet more bugs in the tests.
>>
>> In time we can use this approach in collaboration with vendors to
>> fully automate generating implementation reports.
>>
>> [1] http://hoppipolla.co.uk/410/workers.html
>
> James - this is excellent!
>
> Did you run the tests via ?
> What would it take to include Travis's IE results?

No, this is based on a new-ish tool that itself depends on the
self-hosted-tests changes [1].

If Travis can make the results available in the same JSON format the
tool uses then we can incorporate them directly; having a common,
machine-writable format is the essential point of this work. However I
would suggest that he waits until we fix the broken tests and land the
self-hosted-tests changes and test runner / report generator. If people
are interesting in speeding this process up, the most valuable thing
they can do is help finish the review at [1].

[1] https://critic.hoppipolla.co.uk/r/368

DOM P&S: Disposition of Comments Doc Prepared

[Travis Leithead]

Hey folks, with the completion of the Last Call period for DOM Parsing and 
Serialization (last month on January 7th), I've collected all the technical 
comments that came in during that time in a disposition of comments document:

https://dvcs.w3.org/hg/innerhtml/raw-file/tip/LC1_comments.htm

Please check that these comments were recorded accurately, and that I haven't 
left anything out.

"No response yet" means I haven't started working on the issue. I will begin 
working on addressing these comments shortly using the existing bugzilla bugs 
already filed. Thanks!

-Travis

RE: "Officially" deprecating main-thread synchronous XHR?

[Travis Leithead]

As I understand it, that is one of the scenarios covered by the recently 
proposed Beacon API:
http://www.w3.org/TR/beacon/


Sent from my Windows Phone

From: Scott González
Sent: 2/7/2014 9:33 AM
To: Anne van Kesteren
Cc: Jonas Sicking; Domenic Denicola; o...@pettay.fi; public-webapps@w3.org
Subject: Re: "Officially" deprecating main-thread synchronous XHR?

What about developers who are sending requests as the page is unloading? My 
understanding is that sync requests are required. Is this not the case?

On Friday, February 7, 2014, Anne van Kesteren 
mailto:ann...@annevk.nl>> wrote:
On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking  wrote:
> Agreed. I think for this to be effective we need to get multiple browser
> vendors being willing to add such a warning. We would also need to add text
> to the various versions of the spec (whatwg and w3c).

For what it's worth, was done when Olli brought this up in #whatwg:
http://xhr.spec.whatwg.org/#sync-warning


--
http://annevankesteren.nl/

On starting WebWorkers with blob: URLs...

[Travis Leithead]

Seems like our specs are getting a little behind implementations. In IE11 we 
are finding that several new sites, notably those using WebGL content, have a 
dependency on starting web workers with a Blob URL. As I understand it:

The W3C Web Workers spec (CR stage) forbids use of the data and [implicitly] 
blob protocols
The WHATWG HTML spec (Living stage) allows data protocol, but not blob.
Implementations of Firefox and Chrome support blob protocols

1. Seems like a spec should say this somewhere...
2. In the W3C where would we spec this? (Workers V2?)

[Dom-Parsing] LC1 Comments Addressed for DOM Parsing and Serialization

[Travis Leithead]

By way of general information, the Last Call Comments [1] collected from the 
DOM Parsing and Serialization W3C spec have now been addressed in the latest 
editor's draft. [2]

In the course of working on those bugs, additional bugs were found and filed 
[3].

My goal is to have these additional bugs resolved by the time of the 
face-to-face WebApps meeting in a few weeks.

Thanks!
-Travis

[1] https://dvcs.w3.org/hg/innerhtml/raw-file/tip/LC1_comments.htm
[2] https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html
[3] 
https://www.w3.org/Bugs/Public/buglist.cgi?component=DOM%20Parsing%20and%20Serialization&list_id=33524&product=WebAppsWG&resolution=---

RE: [Dom-Parsing] LC1 Comments Addressed for DOM Parsing and Serialization

[Travis Leithead]

> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf 
> Of Anne van Kesteren
>> On Thu, Mar 27, 2014 at 10:09 PM, Travis Leithead 
>>  wrote:
>> My goal is to have these additional bugs resolved by the time of the 
>> face-to-face WebApps meeting in a few weeks.
>
>If you fix a bug, please post a link to the commit in the bug for ease of 
>review and historical record. "Fixed in last commit" doesn't mean much even a 
>week from now.

Agree--sorry about the short note in the bug. I've retroactively added the 
correct changelist diff links for this bug and all previous fixed bugs.

RE: [Custom Elements] attributeChanged not sufficient?

[Travis Leithead]

As a point of information, IE supports an "elementresize" event in order to 
support this scenario. It's not great because it puts a lot of implementation 
requirements on our layout engine, but it's one potential approach to 
addressing this scenario.

(Note, the event is prefixed in our implementation: "mselementresize")

-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com] 
Sent: Monday, March 31, 2014 5:24 PM
To: Ondřej Žára
Cc: public-webapps@w3.org
Subject: Re: [Custom Elements] attributeChanged not sufficient?


> On Mar 31, 2014, at 8:20 PM, Ondřej Žára  wrote:
> 
> Hi,
> 
> let me introduce my Custom Element scenario: an interactive map element, 
> powered by one of the well-known JS APIs (such as Google Maps API or so).
> 
> Typically, the markup will be like
> 
> 
> 
> However, the underlying JS needs to know when this element's rendered size 
> changes; the viewport needs to be filled with new map tiles and other geo 
> data.
> 
> Typically, when using a plain JS API (and not a custom declarative markup), 
> users are used to call a size synchronization routine, shall the map viewport 
> change. This is no longer the case when a Custom Element is introduced (and 
> scripting is replaced by declarative HTML).

I don't think this problem is specific to custom elements. Users can always 
affect the size of the element with or without custom elements.

> A user may insert a map element anywhere in the page (see 
> http://api4.mapy.cz/ for reference), including a variable-width box in a 
> sidebar or so. This means that the  element itself cannot determine 
> when its own (rendered) size changes, as the attributeChanged callback only 
> applies to own attributes.

Right.

> Is there some recommended way of dealing with this?

I think the only way to detect this would be constantly querying the size of 
your custom element, which will be a performance nightmare.

Perhaps we can add asynchronous event that fires whenever the dimension of an 
element changes? The hardest part of spec'ing such an event will be figuring 
how often the change will be checked. We can't do it after every DOM 
modification, every micro task, etc... due to performance constraints.

- R. Niwa

RE: [April2014Meeting] Seeking status and plans from Editors not attending meeting; deadline April 9

[Travis Leithead]

>> * DOM P&S: Travis; plan and expectations to get the spec back to LC

I finished the last of the bugs today. It's now ready to head back to LC and 
then on to CR!

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Wednesday, April 2, 2014 4:05 AM
To: Hallvord Steen; Travis Leithead; "Gary Kacmarcik (Кошмарчик)"; Eric 
Uhrhane; Ted Mielczarek; Scott Graham; Vincent Scheib; Kinuko Yasuda; Bryan 
Sullivan; EDUARDO FULLEA CARRERA
Cc: public-webapps
Subject: [April2014Meeting] Seeking status and plans from Editors not attending 
meeting; deadline April 9

Hi All,

The people in the To: list are spec Editors that are not registered for 
WebApps' April 10-11 meeting. Since you _won't_ attend the meeting, I would 
appreciate it if you would please provide a short status, plans, expectations 
and such for your spec(s). In general: what are the major issues blocking the 
spec; implementation status; testing status; what can others do to help; plan 
for next Technical Report publication; etc. 
Here are the specs including more specific questions for a few:

* Clipboard: Hallvord;

* D3E: Travis and Gary; plan and expectations to get the spec back to LC; 
testing status

* DOM P&S: Travis; plan and expectations to get the spec back to LC

* File API: {Directories and System, Writer}; Eric

* Gamepad: Ted and Scott; plan and expectations to get the spec to feature 
complete state (aka Last Call) and implementation status

* Push API: Bryan and Eduardo; plan to address TAG feedback

* Quota: Kinuko

Please send your status by April 9 at the latest (and feel free to use a 
spec-specific Subject: such as [quota-api]).

If you are a spec Editor and _will_ attend the meeting, please feel free to 
provide your status info in advance of the meeting although you will have an 
opportunity to discuss your spec at the meeting.

-Thanks, AB

[PubStatus] <http://tinyurl.com/WebAppsWG-PubStatus>
[Bugs] <http://tinyurl.com/WebAppsWG-Bugzilla>

RE: contentEditable=minimal

[Travis Leithead]

+Gary and Masayuki

--This seems very related to the discussion we are having regarding when to 
fire "beforeinput". "beforeinput" might be duplicating some of the use-cases 
that the insertText command event might be supporting.

-Original Message-
From: Robin Berjon [mailto:ro...@w3.org] 
Sent: Tuesday, May 27, 2014 2:39 AM
To: Ben Peters; Julie Parent
Cc: Johannes Wilm; public-webapps@w3.org
Subject: Re: contentEditable=minimal

On 27/05/2014 01:52 , Ben Peters wrote:
>> From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
>> Peters wrote:
 As I said I am unsure that the way in which composition events
 are described in DOM 3 Events is perfect, but that's only
 because I haven't used them in anger and they aren't supported
 much.
>>>
>>> My thought is that we can use CommandEvent with
>>> type="insertText". This would be the corollary to
>>> execComamnd("insertText"), and the data would be the ñ that is
>>> about to be inserted.
>>
>> But if you only get one event you can't render the composition as
>> it is carrying out.
>
> I believe Composition Events are very important for IME input, but we
> should fire CommandEvent with Insert text for all text input,
> including IME. Are you saying we should use Composition Events even
> for non-IME input?

I am not using an IME, and yet I could not type in French on my keyboard 
without composition.

Obviously, if I switch to Kotoeri input, I'll get composition *and* an 
IME popup. But for regular French input (in a US keyboard) I need:

   é -> Alt-E, E
   è -> Alt-`, E
   à -> Alt-`, A
   ô -> Alt-I, O
   ü -> Alt-U, U
   ñ -> Alt-˜, N (for the occasional Spanish)
   (and a bunch more)

Some older apps (you pretty much can't find them anymore) used to not 
display the composition as it was ongoing and only show the text after 
composition had terminated. That was survivable but annoying, and it 
only worked because composition in Latin-script languages is pretty 
trivial (except perhaps for all you Livonian speakers out there!), but I 
don't think it would be viable for more complex compositions. And even 
in simple cases it would confuse users to be typing characters with no 
rendering feedback.

Without composition events you can't render the ongoing composition. See 
what's going on at:

 
https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L81

That is basically inserting text in a range that's decorated to be 
underlined to show composition in progress. Composition updates 
*replace* the text in the range. And at the end the range is removed and 
text is inserted.

The above is for Mac, but I have distant memories of using something 
similar on Windows called the "US International Keyboard" where you 
could have apostrophes compose as accents, etc.. I don't recall how it 
was rendered though.

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

RE: Composition events (was: contentEditable=minimal)

[Travis Leithead]

+Gary/Masayuki who can help with deciphering DOM L3 Events :-)

-Original Message-
From: Robin Berjon [mailto:ro...@w3.org] 
Sent: Tuesday, May 27, 2014 2:15 AM
To: Ben Peters; Jonas Sicking
Cc: public-webapps@w3.org
Subject: Composition events (was: contentEditable=minimal)

On 27/05/2014 01:52 , Ben Peters wrote:
> Composition Events for IMEs, CommandEvents with type insertText for
> all text input (including after Composition Events for IMEs)

I think we should be careful not to mix up composition events and IMEs. 
They may happen together, but IMEs have their own specific issues (e.g. 
popping up a window) that inline composition does not necessarily have. 
Also, IMEs can happen without composition: you could arguably popup a 
handwriting IME that would just insert text on commit without any 
composition taking place.

To stick to what I think is the simplest case, diacritic composition, 
here is what I believe the current D3E specification says (not that it's 
really clear on the matter, but I'm assuming best case scenario). For ñ 
you basically get:

   compositionstart "~"
   compositionend "ñ"

 From what you're saying above you'd like to replace that with:

   compositionstart "~"
   input "ñ"

I think we can make that work, it drops on event and moves the code 
around. If you look at the "Twitter Box" code:

 
https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L102

It basically would need to move what's in the compositionend handler 
inside the beforeinput handler, with a check to see if compoRange exists 
(or the event has isComposing=true).

(I'm assuming that compositionupdate stays as is since we need to update 
the rendering with it.)

Is that the sort of flow you had in mind?

PS: note I just noticed that the code in the Gist was not the latest I 
had and had a lot of "TODO" bits - I've udpated it to the latest.

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

RE: [editing] CommandEvent and contentEditable=minimal Explainer

[Travis Leithead]

Be careful with having events fire before the DOM is updated—at a minimum 
you’ll want to consider whether you will allow dangerous situations like the 
legacy MutationEvents could cause (start a change -> pre-change notification -> 
make another change -> pre-change notification … unexpected things can happen 
(can be especially challenging to implement securely).

HTML5’s focus event model nicely prevents these recursions from looping. I’ve 
proposed a similar mitigation for the “beforeinput” event of DOM Level 3 
Events: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25683

Seems like the Intention Events, if firing before the change is committed, 
might want a similar mitigation strategy.

From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Wednesday, May 28, 2014 1:40 PM
To: Julie Parent
Cc: public-webapps@w3.org
Subject: RE: [editing] CommandEvent and contentEditable=minimal Explainer

Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable="minimal" makes me wonder if contentEditable="minimal" is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, "minimal" is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable="true" is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable="minimal" be equivalent to:

// Let editRegion be 

var editRegion = document.getElementById("editRegion");
editRegion.addEventListener("command", handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable="minimal" on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters mailto:ben.pet...@microsoft.com>>
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: "public-webapps@w3.org" 
mailto:public-webapps@w3.org>>


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm

RE: contentEditable=minimal

[Travis Leithead]

DOM L3 does require implementations to fire composition event for dead-key 
combinations, so insofar as the (Alt-`) combo results in a dead key for 
accent-grave (and other dead key combos mentioned below), the composition 
events should (or are supposed to) fire as a result.

-Original Message-
From: Ben Peters [mailto:ben.pet...@microsoft.com] 
Sent: Monday, June 2, 2014 2:00 PM
To: Robin Berjon; Julie Parent
Cc: Johannes Wilm; public-webapps@w3.org
Subject: RE: contentEditable=minimal

Great context. Thanks! Let me ask my question another way- should 
CompositionEvents be used when there isn't a composition? Should typing 'a' 
fire CompositionEnd? If not we still need a CommandEvent of type insertText, 
and it seems inconsistent not to fire it for all typing, doesn't it?

> From: Robin Berjon [mailto:ro...@w3.org]
> 
> On 27/05/2014 01:52 , Ben Peters wrote:
> >> From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben 
> >> Peters wrote:
>  As I said I am unsure that the way in which composition events 
>  are described in DOM 3 Events is perfect, but that's only because 
>  I haven't used them in anger and they aren't supported much.
> >>>
> >>> My thought is that we can use CommandEvent with type="insertText".
> >>> This would be the corollary to execComamnd("insertText"), and the 
> >>> data would be the ñ that is about to be inserted.
> >>
> >> But if you only get one event you can't render the composition as 
> >> it is carrying out.
> >
> > I believe Composition Events are very important for IME input, but 
> > we should fire CommandEvent with Insert text for all text input, 
> > including IME. Are you saying we should use Composition Events even 
> > for non-IME input?
> 
> I am not using an IME, and yet I could not type in French on my 
> keyboard without composition.
> 
> Obviously, if I switch to Kotoeri input, I'll get composition *and* an 
> IME popup. But for regular French input (in a US keyboard) I need:
> 
>é -> Alt-E, E
>è -> Alt-`, E
>à -> Alt-`, A
>ô -> Alt-I, O
>ü -> Alt-U, U
>ñ -> Alt-˜, N (for the occasional Spanish)
>(and a bunch more)
> 
> Some older apps (you pretty much can't find them anymore) used to not 
> display the composition as it was ongoing and only show the text after 
> composition had terminated. That was survivable but annoying, and it 
> only worked because composition in Latin-script languages is pretty 
> trivial (except perhaps for all you Livonian speakers out there!), but 
> I don't think it would be viable for more complex compositions. And 
> even in simple cases it would confuse users to be typing characters with no 
> rendering feedback.
> 
> Without composition events you can't render the ongoing composition. 
> See what's going on at:
> 
> 
> https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html
> -
> L81
> 
> That is basically inserting text in a range that's decorated to be 
> underlined to show composition in progress. Composition updates
> *replace* the text in the range. And at the end the range is removed 
> and text is inserted.
> 
> The above is for Mac, but I have distant memories of using something 
> similar on Windows called the "US International Keyboard" where you 
> could have apostrophes compose as accents, etc.. I don't recall how it 
> was rendered though.
> 
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

RE: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))

[Travis Leithead]

Well, in IE's defense, this is not specifically allowed by: 
http://www.w3.org/TR/workers/#dom-worker. Regardless, the product team is 
working to fix this so that it works in IE as well. Stay tuned. I updated the 
Connect bug below.

-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com] 
Sent: Friday, June 6, 2014 6:25 AM
To: Web Applications Working Group WG (public-webapps@w3.org)
Cc: Travis Leithead
Subject: IE - Security error with new Worker(URL.createObjectURL(new 
Blob([workerjs],{type:'text/javascript'})))

Why IE(11) does not allow this while this is working on FF and Chrome? 
[1] seems to suggest that it is "by design".

Regards

Aymeric

[1] 
https://connect.microsoft.com/IE/feedback/details/779379/unable-to-spawn-worker-from-blob-url

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

RE: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))

[Travis Leithead]

Unfortunately, there is not presently a way for you to track it externally. :-(

MS Connect is the best we have so far, and I know that it is not great. We 
recognize this is a problem and hope to be able to improve the situation soon.
 
-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com] 
Sent: Tuesday, June 10, 2014 3:00 AM
To: Travis Leithead; Web Applications Working Group WG (public-webapps@w3.org)
Subject: Re: IE - Security error with new Worker(URL.createObjectURL(new 
Blob([workerjs],{type:'text/javascript'})))

Thanks, any way to track/be notified when this will be available?

Regards

Aymeric

Le 06/06/2014 19:42, Travis Leithead a écrit :
> Well, in IE's defense, this is not specifically allowed by: 
> http://www.w3.org/TR/workers/#dom-worker. Regardless, the product team is 
> working to fix this so that it works in IE as well. Stay tuned. I updated the 
> Connect bug below.
>
> -Original Message-
> From: Aymeric Vitte [mailto:vitteayme...@gmail.com]
> Sent: Friday, June 6, 2014 6:25 AM
> To: Web Applications Working Group WG (public-webapps@w3.org)
> Cc: Travis Leithead
> Subject: IE - Security error with new Worker(URL.createObjectURL(new 
> Blob([workerjs],{type:'text/javascript'})))
>
> Why IE(11) does not allow this while this is working on FF and Chrome?
> [1] seems to suggest that it is "by design".
>
> Regards
>
> Aymeric
>
> [1]
> https://connect.microsoft.com/IE/feedback/details/779379/unable-to-spawn-worker-from-blob-url
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

RE: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))

[Travis Leithead]

Just a quick followup: this bug fix has been shipped in our recent Windows 
Phone 8.1 update [1]. It will come to a Desktop browser near you soon.

[1] 
http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx
 

-Original Message-
From: Travis Leithead 
Sent: Tuesday, June 10, 2014 5:54 PM
To: Aymeric Vitte; Web Applications Working Group WG (public-webapps@w3.org)
Cc: Adrian Bateman
Subject: RE: IE - Security error with new Worker(URL.createObjectURL(new 
Blob([workerjs],{type:'text/javascript'})))

Unfortunately, there is not presently a way for you to track it externally. :-(

MS Connect is the best we have so far, and I know that it is not great. We 
recognize this is a problem and hope to be able to improve the situation soon.
 
-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com] 
Sent: Tuesday, June 10, 2014 3:00 AM
To: Travis Leithead; Web Applications Working Group WG (public-webapps@w3.org)
Subject: Re: IE - Security error with new Worker(URL.createObjectURL(new 
Blob([workerjs],{type:'text/javascript'})))

Thanks, any way to track/be notified when this will be available?

Regards

Aymeric

Le 06/06/2014 19:42, Travis Leithead a écrit :
> Well, in IE's defense, this is not specifically allowed by: 
> http://www.w3.org/TR/workers/#dom-worker. Regardless, the product team is 
> working to fix this so that it works in IE as well. Stay tuned. I updated the 
> Connect bug below.
>
> -Original Message-
> From: Aymeric Vitte [mailto:vitteayme...@gmail.com]
> Sent: Friday, June 6, 2014 6:25 AM
> To: Web Applications Working Group WG (public-webapps@w3.org)
> Cc: Travis Leithead
> Subject: IE - Security error with new Worker(URL.createObjectURL(new 
> Blob([workerjs],{type:'text/javascript'})))
>
> Why IE(11) does not allow this while this is working on FF and Chrome?
> [1] seems to suggest that it is "by design".
>
> Regards
>
> Aymeric
>
> [1]
> https://connect.microsoft.com/IE/feedback/details/779379/unable-to-spawn-worker-from-blob-url
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms