Quick update on WebIDL "Level 1"

[Travis Leithead]

While editing work continues on the "second edition" of WebIDL here: 
http://heycam.github.io/webidl/, we have been fine-tuning the "Level 1" CR 
snapshot [1] to replace and supersede the 2012 version [2].

The "Level 1" editors are making final tweaks to the draft and tests, and hope 
to be ready to transition to Proposed Recommendation status by the end of July.

The purpose of the "Level 1" document is to serve as a stable reference for W3C 
specs that link to WebIDL. It contains a subset of the WebIDL syntax that is 
considered stable (as verified by interoperable tests). Implementations should 
not use the Level 1 document as a guide, but instead track changes to the 
editors draft. We expect to follow-up Level 1 with a Level 2 as additional 
editor's draft syntax and behavior stabilizes, are implemented as part of other 
specs, and shown to be interoperable.

-Travis & Yves

[1] https://cdn.rawgit.com/ylafon/webidl/post-cr/l1-respec.html
[2] http://www.w3.org/TR/WebIDL/

RE: Republish Pointer Lock as CR

[Travis Leithead]

+1 in favor of supporting a republishing as CR.

-Original Message-
From: Léonie Watson [mailto:t...@tink.uk] 
Sent: Monday, June 13, 2016 9:13 AM
To: 'public-webapps WG' 
Subject: CFC: Republish Pointer Lock as CR

Hello WP,

This is a Call For Consensus (CFC) to request that W3C republish Pointer Lock 
as a Candidate Recommendation (CR). Extensions to the MouseEventInit Dictionary 
[1] constitute substantive changes to the specification that were made after 
the current CR was published in 2013 [2].

Please reply to this CFC no later than 21st June 2016. Positive responses are 
preferred and supporting comments (beyond just +1) are encouraged, but silence 
will be considered as consent.

Thank you.

Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
[1] 
https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictionary
[2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/
--
@LeonieWatson tink.uk Carpe diem

RE: Publish as W3C Notes

[Travis Leithead]

Publish as note and Incubate +1

-Original Message-
From: Léonie Watson [mailto:t...@tink.uk] 
Sent: Tuesday, April 26, 2016 11:06 AM
To: public-webapps@w3.org
Subject: CFC: Publish as W3C Notes

Hello,

At the AC meeting in March 2016 the WP co-chairs indicated that the following 
two specifications would benefit from further incubation before continuing 
along the Recommendation track:

Quota Management API [1]
Input Method Editor API [2]

This is a CFC to publish each of these specifications as a W3C note, under the 
Software and Document License. Anyone wishing to take these ideas further is 
then welcome to use the notes to seed incubation within WICG or elsewhere.

If the CFC passes, the transition of each specification to note status will be 
done within the current WP WG charter.

If you have comments or concerns about this CFC, please send them to 
public-webapps@w3.org no later than Wednesday 4th May 2016. Positive responses 
are preferred and encouraged, and silence will be considered as agreement with 
the proposal.

Léonie on behalf of the WP chairs and team.
[1] https://w3c.github.io/quota-api/
[2] https://w3c.github.io/ime-api/
--
@LeonieWatson tink.uk Carpe diem

RE: Alex Danilo introduction

[Travis Leithead]

Welcome, and nice to have you with us!

From: adan...@google.com [mailto:adan...@google.com] On Behalf Of Alex Danilo
Sent: Monday, March 21, 2016 9:56 PM
To: public-weba...@w3c.org
Subject: Alex Danilo introduction

Hi All,

My name is Alex Danilo and I've joined the Web Platform Working Group.

I work for Google on the Developer Relations team, specifically focussing on 
Web technology.

I first joined the W3C SVG Working Group in January, 2002 and was a founding 
member of the (now defunct) Compound Document Formats Working Group back in 
2004 and have been participating in various W3C groups for much of my time 
since.

My areas of interest cover a broad range, including the IntersectionObserver 
proposal, web components, typography, graphics, layout primitives and pretty 
much anything HTML related.

Looking forward to working with you all.

Alex

RE: Can we land heycam's WebIDL tests as-is and address review comments following?

[Travis Leithead]

Yves and I have been reviewing these tests and revising them according to 
recent WebIDL changes and we think they may be ready to be integrated. The 
updates are in a PR on heycams page. Let’s not integrate heycam’s original PR 
until our update is done first please…







From: Simon Pieters
Sent: Monday, December 21, 2015 1:13 AM
To: public-webapps; Zhang, 
Zhiqiang
Subject: Re: Can we land heycam's WebIDL tests as-is and address review 
comments following?



On Mon, 21 Dec 2015 07:34:12 +0100, Zhang, Zhiqiang
 wrote:

> Hi,
>
> 2+ years ago, heycam submitted WebIDL tests at
>
> https://github.com/w3c/web-platform-tests/pull/271
>
> These tests have been reviewed by several guys but get no update ever
> since.
>
> I wonder if we could land the tests as-is and address the review
> comments in further pull requests? Then we can make a test suite to
> advance the specification and for people to understand the specification.
>
> Thoughts?
>
> Thanks,
> Zhiqiang

Personally I don't object to that plan, but an alternative is to create a
new branch in w3c/web-platform-tests with these changes, and anyone with
push access to w3c/web-platform-tests can make changes to that branch, and
then we can merge to master when it's ready.

 git fetch origin refs/pull/271/head:refs/remotes/origin/pr/271 --force
 git checkout -b webidl-tests origin/pr/271
 git push -u origin webidl-tests

--
Simon Pieters
Opera Software

RE: Meeting date, january

[Travis Leithead]

25th works for me.

-Original Message-
From: Domenic Denicola [mailto:d...@domenic.me] 
Sent: Tuesday, December 1, 2015 8:32 AM
To: Chaals McCathie Nevile ; 'public-webapps WG' 
; Léonie Watson 
Cc: Anne van Kesteren 
Subject: RE: Meeting date, january

From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru]

> Yes, likewise for me. Anne, Olli specifically called you out as 
> someone we should ask. I am assuming most people are OK either way, 
> having heard no loud screaming except for Elliot...

I would be pretty heartbroken if we met without Elliott. So let's please do the 
25th.

RE: Callback when an event handler has been added to a custom element

[Travis Leithead]

Interesting. Alternatively, you can add .onwhatever handlers, as well as define 
your own overload of addEventListener (which will be called instead of the 
EventTarget.addEventListener method). That way you can capture all attempts at 
setting events on your element.

-Original Message-
From: Mitar [mailto:mmi...@gmail.com] 
Sent: Thursday, November 5, 2015 4:05 PM
To: public-webapps 
Subject: Callback when an event handler has been added to a custom element

Hi!

We are using message ports to communicate with our logic and are wrapping the 
API into a custom element. The issue is that we would like to call start on a 
message port only after user has registered an event handler on the custom 
element instance. But it seems there is no way to get a callback when an event 
handler is added.

So I am suggesting that there should be a callback every time an event listener 
is added to a custom element (and possibly one when removed).


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

RE: [Web Components] proposing a f2f...

[Travis Leithead]

I would prefer a late January date so as to allow me to arrange travel. 
Otherwise, I’m happy to attend remotely anytime.

From: Dimitri Glazkov [mailto:dglaz...@google.com]
Sent: Thursday, October 29, 2015 2:52 AM
To: Olli Pettay 
Cc: Chaals McCathie Nevile ; public-webapps WG 

Subject: Re: [Web Components] proposing a f2f...

I am available on all of those days. Will also be happy to help with logistics.

:DG<

RE: Shadow DOM and SVG use elements

[Travis Leithead]

Well, since SVG 'use' is mostly about replicating the composed tree anyway, it 
seems that is should probably render the composed tree--e.g., this seems 
natural, because use would "replicate" the host element, which would then 
render it's shadow DOM. The interactivity behaviors associated with the shadow 
dom is an interesting question though.. today you are expected to attach event 
handlers to the ElementInstance 
(http://www.w3.org/TR/SVG/struct.html#InterfaceSVGElementInstance) which is the 
DOM representation of the "replicated" tree--I'm not sure what this would look 
like for Elements with an attached shadow.

I'd love to know what the folks on www-...@w3.org working on SVG2 think about 
this.

-Original Message-
From: rn...@apple.com [mailto:rn...@apple.com] 
Sent: Thursday, October 22, 2015 6:16 PM
To: public-webapps@w3.org
Subject: Shadow DOM and SVG use elements

Hi all,

What should happen when a SVG use element references an element (or its 
ancestor) with a shadow root?

Should the use element show the composed tree underneath it or ignore shadow 
DOM altogether?

I'm a little inclined towards the former (uses the composed tree).

- R. Niwa

RE: ISSUE-187: Https://github.com/w3c/uievents/issues/20

[Travis Leithead]

I closed this--it was opened by accident.

-Original Message-
From: Web Applications Working Group Issue Tracker 
[mailto:sysbot+trac...@w3.org] 
Sent: Tuesday, October 6, 2015 5:26 PM
To: public-webapps@w3.org
Subject: ISSUE-187: Https://github.com/w3c/uievents/issues/20

ISSUE-187: Https://github.com/w3c/uievents/issues/20

http://www.w3.org/2008/webapps/track/issues/187

Raised by: 
On product: 

RE: Tests for new shadow DOM API

[Travis Leithead]

Why not deprecate/remove the existing tests in the current folder structure? 
Presumably we can replace them with new tests that are aligned with the recent 
spec changes?

If the existing tests really aren't relevant anymore, I don't see a reason to 
keep them around.

From: rn...@apple.com [mailto:rn...@apple.com]
Sent: Thursday, September 3, 2015 1:07 PM
To: public-webapps 
Subject: Tests for new shadow DOM API

Hi all,

Where should we put tests for new shadow DOM API?  It looks like the tests in 
https://github.com/w3c/web-platform-tests/tree/master/shadow-dom/shadow-trees 
are mostly obsolete and I'm not certain how many of them could be adopted for 
the new API.

Would it make sense to rename this old one to "deprecated-shadow-don" and then 
create a new top-level directory "shadow-dom"?  We can then migrate or write 
new tests there.

- R. Niwa

Re: PSA: publish WD of "WebIDL Level 1"

[Travis Leithead]

This is, at a minimum, incremental goodness. It's better than leaving the prior 
L1 published document around--which already tripped up a few folks on my team 
recently. I strongly +1 it.


From: Anne van Kesteren 
Sent: Friday, August 7, 2015 5:55 AM
To: Arthur Barstow
Cc: Tab Atkins Jr.; public-webapps
Subject: Re: PSA: publish WD of "WebIDL Level 1"

On Fri, Aug 7, 2015 at 2:45 PM, Arthur Barstow  wrote:
> The L2 version (by Cameron and Boris) has not been published as a TR
> and if there no objections to proceeding as above, I will start working on
> making this all happen.

I still don't understand why L1 is even published. It cannot be
implemented so only furthers confusion.


--
https://annevankesteren.nl/

RE: alternate view on constructors for custom elements

[Travis Leithead]

From: Domenic Denicola [mailto:d...@domenic.me] 
>
>From: Travis Leithead [mailto:travis.leith...@microsoft.com] 
>
>> Something magical happens here. The use of super() is supposed to call the 
>> constructor of the HTMLElement class—but that’s not a normal JS class. It 
>> doesn’t have a defined constructor() method [yet?].
>
>Yep. We'd need to define one; it's absolutely required. ES2015 classes that 
>don't call super() in their constructor simply aren't allowed, which means 
>inheriting from a constructor that throws (like HTMLElement currently does) is 
>impossible.
>
>https://github.com/domenic/element-constructors is a start at this.

Hmm. This does help. A lot. I wasn't aware that ES2015 classes added all these 
restrictions on top of the syntactic sugar over the classing function 
technique. Now I have some study to do to catch up. One question though before 
I do that: if super() is absolutely required for a constructor in a class that 
extends something, is there a requirement about when in the constructor method 
it be invoked? Must it always be the first call? Can it be later on, say at the 
end of the function? 

>I take it when you said in [1]:
>
> I've discussed this issue with some of Edge's key parser developers. From a 
> technical ground, we do not have a problem with stopping the parser to 
> callout to author code in order to run a constructor, either during parsing 
> or cloning. For example, in parsing, I would expect that the callout happens 
> after initial instance creation, but before the target node is attached to 
> the DOM tree by the parser.
>
>you were not aware of this? Maybe now you better understand my follow-up 
>question in [2],

Yep. :-|

>> window.XFoo = document.registerElement(‘x-foo’, XFooStartup);
>
>Why is XFoo different from XFooStartup? If I define a method in XFooStartup, 
>does it exist in XFoo?

This won't work as I described it, given what you've told me, but my assumption 
was essentially, that XFooStartup would act as if it didn't really depend on 
HTMLElement for construction. So, it's constructor wouldn't be linked to the 
actual custom element creation. Therefore XFoo (the platform-provided 
constructor function is the thing that is actually used to trigger 
construction, which would then result in the XFooStartup constructor running. 
Basically, like this (reverting to non-class syntax):

function XFooStartup(val1, val2) {
  this.prop = val1;
  this.prop2 = val2;
}
window.XFoo = document.registerElement(‘x-foo’, XFooStartup);

all I was trying to express different from the current design is: 
1) replacing the createdCallback with the function constructor (and passing the 
new element instance as 'this' when calling it)
2) passing through params from the XFoo platform-native constructor to the 
XFooStartup function
3) calling XFooStartup synchronously

alternate view on constructors for custom elements

[Travis Leithead]

OK, after reading Dominic's proposal [1], I'm a little confused. I thought that 
I understood how constructors should work, but there's some magic going on that 
I can't follow... I'm sure you folks can help.

```
class CustomElement extends HTMLElement {
   constructor() {
  super();
   }
}

Something magical happens here. The use of super() is supposed to call the 
constructor of the HTMLElement class-but that's not a normal JS class. It 
doesn't have a defined constructor() method [yet?]. Also, as has been pointed 
out, running the CustomElement constructor code _before_ instantiating the 
actual element (at parse-time for example) opens up a world of potential 
problems as have been explored:

*Javascript classes are mutable-what if CustomElement's proto chain is 
mutated later?

*What if the constructor throws?
...just to name a few.

I'm trying to rationalize the custom elements previous design with the use of 
constructors. Basically, I think it should still be a two-stage creation model:

1.  Native [internal] element is created with appropriate tag name, 
attributes, etc.

2.  JS constructor is called and provided the instance (as 'this')

#1 is triggered by the parser, or by a native constructor function. That 
constructor function could either be provided separately like it is returned 
from registerElement today, or in some other way (replacing the original 
constructor?). Since replacing the original constructor sounds weird and 
probably violates a bunch of JS invariants, I'll assume sticking with the 
original model.

This makes it much safer for implementations, since the native custom element 
can always be safely created first, before running JS code. It also means 
there's no magic super() at work-which seems to leave too much control up to 
author code to get right.

Basic example of what I'm thinking:

class XFooStartup extends HTMLElement {
   constructor(val1, val2) {
  this.prop = val1;
  this.prop2 = val2;
   }
}
window.XFoo = document.registerElement('x-foo', XFooStartup);

// (1)
var x1 = new XFooStartup("first", "second");
// (2)
var x2 = new XFoo("first", "second");

Calling (1) does not create a custom element. Extending from HTMLElement is not 
magical, it's just a prototype inheritance, as can be done today. super() would 
do whatever super() does when the super class has no defined method to invoke. 
x1 is a regular JS object with a .prop and .prop2.

Calling (2) runs the platform-provided constructor function which internally 
inits a new HTMLElement in the C++ (or could be Element if in XML document?). 
Then the platform immediately (synchronously) invokes the provided constructor 
function as if:
XFooStartup.apply(newHTMLElementInstance, argsPassedThroughFromCall);
so that XFooStartup's constructor operates on the 'this' being the instance 
created by the platform.


[1] 
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Optional-Upgrades-Optional-Constructors.md

[WebIDL] T[] migration

[Travis Leithead]

Hey folks,

Now that WebIDL has added FrozenArray<> and dropped T[], it's time to switch 
over! On the other hand, there are a number of specs that have already gone to 
Rec that used the old syntax.

Recommendations:

*HTML5

*Web Messaging

Other references:

*CSS OM

*Web Sockets

*WebRTC

Legacy/Deprecated references:

*TypedArrays (replaced by ES2015)

*Web Intents

Thoughts on what to do about this? Should we consider keeping T[] in WebIDL, 
but having it map to FrozenArray<>? Should we issue errata to those Recs?

RE: The key custom elements question: custom constructors?

[Travis Leithead]

I've discussed this issue with some of Edge's key parser developers. From a 
technical ground, we do not have a problem with stopping the parser to callout 
to author code in order to run a constructor, either during parsing or cloning. 
For example, in parsing, I would expect that the callout happens after initial 
instance creation, but before the target node is attached to the DOM tree by 
the parser.

Having put my support in for this design, which I believe to be the most 
straightforward approach that most closely matches how the platform itself 
works, and which would not be a problematic issue for our implementation, I did 
have a chance to discuss this briefly with Alex Russell, who felt that running 
synchronous author code at such early stages in the loading pipeline (e.g., 
while initial parsing due to a previously encountered document.registerElement 
call was an anti-pattern that he'd like to avoid. He is a strong supporter of 
the proto-swizzle technique that happens later with retro-active upgrades to 
previously-seen custom elements. I am sympathetic to this concern, but have my 
own reservations about the proto-swizzle technique.

-Original Message-
From: Domenic Denicola [mailto:d...@domenic.me] 
Sent: Thursday, July 16, 2015 2:45 AM
To: public-webapps
Subject: The key custom elements question: custom constructors?

Hi all,

Ahead of next week's F2F, I'm trying to pull together some clarifying and 
stage-setting materials, proposals, lists of open issues, etc. In the end, they 
all get blocked on one key question:

**Is it OK to run author code during parsing/cloning/editing/printing (in 
Gecko)/etc.?**

If we allow custom elements to have custom constructors, then those must run in 
order to create properly-allocated instances of those elements; there is simply 
no other way to create those objects. You can shuffle the timing around a bit: 
e.g., while cloning a tree, you could either run the constructors at the normal 
times, or try to do something like almost-synchronous constructors [1] where 
you run them after constructing a skeleton of the cloned tree, but before 
inserting them into the tree. But the fact remains that if custom elements have 
custom constructors, those custom constructors must run in the middle of all 
those operations.

We've danced around this question many times. But I think we need a clear 
answer from the various implementers involved before we can continue. In 
particular, I'm not interested in whether the implementers think it's 
technically feasible. I'd like to know whether they think it's something we 
should standardize.

I'm hoping we can settle this on-list over the next day or two so that we all 
come to the meeting with a clear starting point. Thanks very much, and looking 
forward to your replies,

-Domenic

[1]: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0098.html

RE: [ime-api] [blink-dev] Removing IME API code from Blink

[Travis Leithead]

Arrg. It's far-less used than I thought.

It turns out that it _was_ used in production last year, but then it was 
removed from production when a UI change interfered and the bug to fix it is 
still open :(

So, my guess is that as of today, we have infinitesimal-small usage of this API 
in IE.

-Original Message-
From: Travis Leithead 
Sent: Thursday, June 18, 2015 11:49 AM
To: 'Arthur Barstow'; Ryosuke Niwa
Cc: public-webapps
Subject: RE: [ime-api] [blink-dev] Removing IME API code from Blink

I've posted the notice on the editor's draft as suggested below. If there is 
help to continue to advance the direction of this spec, I'd love to see it 
continue to evolve.

Note, that our Chinese Bing home page (http://www.bing.com/?mkt=zh-CN) employs 
the use of a version of this API (prefixed, in IE11 & Edge), but the API only 
lights up when you use built-in Microsoft IMEs (not 3rd party IMEs at the 
moment :( ).

-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com] 
Sent: Thursday, June 11, 2015 3:42 AM
To: Travis Leithead; Ryosuke Niwa
Cc: public-webapps
Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink

On 5/28/15 2:04 PM, Travis Leithead wrote:
> That sounds good to me (working the UI challenges for IME together with 
> grammar/spell checking). Is this a direction the current IME spec could 
> take--possibly with a big refactor to consider dropping the ClientRect 
> exposure--or would it be better to publish as Note the current approach and 
> start a new spec?
>
> Perhaps it doesn't really matter as the above is a process question, and what 
> is really needed is someone to start suggesting some concrete proposals 
> here--I've been pretty much ignoring this spec for the past year, and I don't 
> see that changing in the near future. It's still something I'd like to see 
> moved forward, I just don't believe I have the time to move it substantially 
> forward at the present moment :)

Given this, it seems like the SoTD section should include some type of 
large-ish warning/note that include text along the lines of `no one is 
actively working on this spec nor its implementation` + `help wanted`. 
Also, if the spec's [Issues] and [Bugs]  haven't properly captured the 
ClientRect exposure issue, perhaps one should be created (and/or the 
spec updated to reflect this).

On the other hand, if you propose to formally stop work on the spec "as 
it is" now, then it would be appropriate to have a CfC to publish a WG 
Note (and if/when there is a firm commitment to do some type of followup 
work, a new spec can be created).

WDYT?

-Thanks, ArtB

[Issues] https://github.com/w3c/ime-api/issues
[Bugs] 
https://www.w3.org/Bugs/Public/buglist.cgi?component=IME%20API&list_id=57282&product=WebAppsWG&resolution=---

> -Original Message-
> From: Ryosuke Niwa [mailto:rn...@apple.com]
> Sent: Wednesday, May 27, 2015 7:00 PM
> To: Travis Leithead
> Cc: Arthur Barstow; public-webapps
> Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink
>
>
>> On May 27, 2015, at 11:46 AM, Travis Leithead 
>>  wrote:
>>
>> I believed the use-cases for avoiding UI clashes between site-driven 
>> auto-complete lists and IME auto-complete boxes is still a valid use case, 
>> and I think the spec is still valid to try to push to recommendation. 
>> However, I'd also like to follow up on usage of the ms- prefixed API so that 
>> I can get an idea of what its real usage is.
> I agree avoiding UI clashes between auto-completions of IME and web page is a 
> great use case but I'm not convinced that exposing ClientRect for IME is the 
> right API as many Web developers aren't even aware of UI challenges IME 
> imposes. For example, a similar UI challenge emerges when dealing with 
> auto-corrections in grammar/spell checking features as well.  It would be 
> ideal if IME and spell/grammar corrections are handled in a similar manner so 
> that Web apps supporting either feature will "just work" with both features.
>
> - R. Niwa
>

RE: Async Image -> ImageData conversion

[Travis Leithead]

Cool. Want to write it up as a small extension spec? We have a new Incubator 
Community Group coming up soon that would be an ideal place to drop a small 
spec into and let implementers experiment with it and get broader community 
feedback on the idea.

From: a...@scirra.com [mailto:a...@scirra.com] On Behalf Of Ashley Gullen
Sent: Wednesday, June 17, 2015 2:06 PM
To: Travis Leithead
Cc: public-webapps@w3.org
Subject: Re: Async Image -> ImageData conversion

That seems like a good start. I suppose there should be a putImageDataAsync 
counterpart too? Then we can do:

Blob -> Image via: load blob URL
Blob -> ImageData via: load blob URL -> Canvas drawImage -> getImageDataAsync
Image -> Blob via: Canvas drawImage -> Canvas toBlob
Image -> ImageData via: Canvas drawImage -> getImageDataAsync
ImageData -> Blob via: Canvas putImageDataAsync -> Canvas toBlob
ImageData -> Image via: Canvas putImageDataAsync -> Canvas toBlob -> load blob 
URL

I think the potential problems with this are:
- putImageDataAsync is the logical counterpart to getImageDataAsync, but what 
happens if you make other synchronous draw calls while putImageDataAsync is 
processing? What actually ends up in the canvas and how is this defined?
- some of the conversion steps seem pretty long winded, in particular Blob -> 
ImageData and ImageData -> Image. If implementors think they can optimise these 
to be as efficient as direct conversion that's fine, but is that actually 
doable with such a roundabout API?

If ImageData has:
Promise toBlob();
Promise fromBlob(blob);

then we can use the following conversions without new canvas functions:

Blob -> Image via: load blob URL
Blob -> ImageData via: ImageData.fromBlob
Image -> Blob via: Canvas drawImage -> Canvas toBlob
Image -> ImageData via: Canvas drawImage -> Canvas toBlob -> ImageData.fromBlob
ImageData -> Blob via: ImageData.toBlob
ImageData -> Image via: ImageData.toBlob -> load blob URL

That looks like a much more reasonable set of conversions to me, and is all 
async.

I was thinking about toImage and fromImage, but it seems to be a bigger step to 
add a new way to make images, and there's the question of what the src for the 
image returned by toImage should be.




On 17 June 2015 at 18:59, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
I think solving at least the first-order problem of extracting data from the 
Canvas async is do-able.

Something like:

Promise getImageDataAsync(x,y,w,h);

seems sensible to add ☺

From: a...@scirra.com<mailto:a...@scirra.com> 
[mailto:a...@scirra.com<mailto:a...@scirra.com>] On Behalf Of Ashley Gullen
Sent: Wednesday, June 17, 2015 10:00 AM
To: public-webapps@w3.org<mailto:public-webapps@w3.org>
Subject: Async Image -> ImageData conversion

I was wondering if there is anything on the standards track to asynchronously 
get an ImageData object from an Image?

We have a web app dealing with large sprite sheets (up to 2048x2048), and at 
some point we need to get an ImageData for this. Currently the only way I know 
of doing this is via a canvas 2d context like so:

function ImageToImageData(img)
{
let w = img.width;
let h = img.height;

let canvas = document.createElement("canvas");
canvas.width = w;
canvas.height = h;
let ctx = canvas.getContext("2d");
ctx.drawImage(img, 0, 0);
return ctx.getImageData(0, 0, w, h);
};

This whole function is synchronous. With large images, in Chrome the 
getImageData call can jank for well over 100ms on a high-end desktop machine. 
Maybe this can be faster but I really doubt this whole function is likely to be 
done in <16ms on low-end devices, so I believe there ought to be an async 
alternative. As far as I am aware there is none.

Ideally we could have an async ImageData.fromImage(img) method or similar. It 
would also be useful if we could decode directly from Blob to ImageData without 
having to go via an Image as well (perhaps ImageData.fromBlob(blob) ?).

More broadly, it would be good to have a comprehensive set of async conversion 
functions between Blob, Image, and ImageData. Blob -> Image can already be done 
by setting the image src to a blob URL, but basically everything else requires 
going synchronously through a 2D canvas, which janks apps which have to process 
lots of large images. Running a canvas in a worker could possibly help, but 
that would require both Blob and Image to be transferable to be useful.

Ashley Gullen
Scirra.com

RE: [ime-api] [blink-dev] Removing IME API code from Blink

[Travis Leithead]

I've posted the notice on the editor's draft as suggested below. If there is 
help to continue to advance the direction of this spec, I'd love to see it 
continue to evolve.

Note, that our Chinese Bing home page (http://www.bing.com/?mkt=zh-CN) employs 
the use of a version of this API (prefixed, in IE11 & Edge), but the API only 
lights up when you use built-in Microsoft IMEs (not 3rd party IMEs at the 
moment :( ).

-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com] 
Sent: Thursday, June 11, 2015 3:42 AM
To: Travis Leithead; Ryosuke Niwa
Cc: public-webapps
Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink

On 5/28/15 2:04 PM, Travis Leithead wrote:
> That sounds good to me (working the UI challenges for IME together with 
> grammar/spell checking). Is this a direction the current IME spec could 
> take--possibly with a big refactor to consider dropping the ClientRect 
> exposure--or would it be better to publish as Note the current approach and 
> start a new spec?
>
> Perhaps it doesn't really matter as the above is a process question, and what 
> is really needed is someone to start suggesting some concrete proposals 
> here--I've been pretty much ignoring this spec for the past year, and I don't 
> see that changing in the near future. It's still something I'd like to see 
> moved forward, I just don't believe I have the time to move it substantially 
> forward at the present moment :)

Given this, it seems like the SoTD section should include some type of 
large-ish warning/note that include text along the lines of `no one is 
actively working on this spec nor its implementation` + `help wanted`. 
Also, if the spec's [Issues] and [Bugs]  haven't properly captured the 
ClientRect exposure issue, perhaps one should be created (and/or the 
spec updated to reflect this).

On the other hand, if you propose to formally stop work on the spec "as 
it is" now, then it would be appropriate to have a CfC to publish a WG 
Note (and if/when there is a firm commitment to do some type of followup 
work, a new spec can be created).

WDYT?

-Thanks, ArtB

[Issues] https://github.com/w3c/ime-api/issues
[Bugs] 
https://www.w3.org/Bugs/Public/buglist.cgi?component=IME%20API&list_id=57282&product=WebAppsWG&resolution=---

> -Original Message-
> From: Ryosuke Niwa [mailto:rn...@apple.com]
> Sent: Wednesday, May 27, 2015 7:00 PM
> To: Travis Leithead
> Cc: Arthur Barstow; public-webapps
> Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink
>
>
>> On May 27, 2015, at 11:46 AM, Travis Leithead 
>>  wrote:
>>
>> I believed the use-cases for avoiding UI clashes between site-driven 
>> auto-complete lists and IME auto-complete boxes is still a valid use case, 
>> and I think the spec is still valid to try to push to recommendation. 
>> However, I'd also like to follow up on usage of the ms- prefixed API so that 
>> I can get an idea of what its real usage is.
> I agree avoiding UI clashes between auto-completions of IME and web page is a 
> great use case but I'm not convinced that exposing ClientRect for IME is the 
> right API as many Web developers aren't even aware of UI challenges IME 
> imposes. For example, a similar UI challenge emerges when dealing with 
> auto-corrections in grammar/spell checking features as well.  It would be 
> ideal if IME and spell/grammar corrections are handled in a similar manner so 
> that Web apps supporting either feature will "just work" with both features.
>
> - R. Niwa
>

RE: Async Image -> ImageData conversion

[Travis Leithead]

I think solving at least the first-order problem of extracting data from the 
Canvas async is do-able.

Something like:

Promise getImageDataAsync(x,y,w,h);

seems sensible to add ☺

From: a...@scirra.com [mailto:a...@scirra.com] On Behalf Of Ashley Gullen
Sent: Wednesday, June 17, 2015 10:00 AM
To: public-webapps@w3.org
Subject: Async Image -> ImageData conversion

I was wondering if there is anything on the standards track to asynchronously 
get an ImageData object from an Image?

We have a web app dealing with large sprite sheets (up to 2048x2048), and at 
some point we need to get an ImageData for this. Currently the only way I know 
of doing this is via a canvas 2d context like so:

function ImageToImageData(img)
{
let w = img.width;
let h = img.height;

let canvas = document.createElement("canvas");
canvas.width = w;
canvas.height = h;
let ctx = canvas.getContext("2d");
ctx.drawImage(img, 0, 0);
return ctx.getImageData(0, 0, w, h);
};

This whole function is synchronous. With large images, in Chrome the 
getImageData call can jank for well over 100ms on a high-end desktop machine. 
Maybe this can be faster but I really doubt this whole function is likely to be 
done in <16ms on low-end devices, so I believe there ought to be an async 
alternative. As far as I am aware there is none.

Ideally we could have an async ImageData.fromImage(img) method or similar. It 
would also be useful if we could decode directly from Blob to ImageData without 
having to go via an Image as well (perhaps ImageData.fromBlob(blob) ?).

More broadly, it would be good to have a comprehensive set of async conversion 
functions between Blob, Image, and ImageData. Blob -> Image can already be done 
by setting the image src to a blob URL, but basically everything else requires 
going synchronously through a 2D canvas, which janks apps which have to process 
lots of large images. Running a canvas in a worker could possibly help, but 
that would require both Blob and Image to be transferable to be useful.

Ashley Gullen
Scirra.com

Re: Custom Elements: is=""

[Travis Leithead]

My current understanding of "is=" is a request for an implementation to 
"plug-in" a native element's backing behavior under a custom element name. This 
feature would otherwise not be available without is=, as custom elements are 
always generic by design.

As Dimitri has noted in the past, I think this feature nicely solves some 
accessibility gaps in the platform. It's not ideal, but I believe it is useful. 
I'm not wedded to the syntax or API for doing this though, and I'd welcome 
suggestions to improve it.


From: Ryosuke Niwa 
Sent: Monday, June 8, 2015 5:58 PM
To: Alice Boxhall
Cc: Anne van Kesteren; Léonie Watson; WebApps WG
Subject: Re: Custom Elements: is=""

> On Jun 8, 2015, at 4:37 PM, Alice Boxhall  wrote:
>
>
>
> On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa  wrote:
>>
>>> On Jun 8, 2015, at 3:23 PM, Alice Boxhall  wrote:
>>>
>>> On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa  wrote:

 > On Jun 8, 2015, at 2:16 PM, Alice Boxhall  wrote:
 Web developers are already writing their own "custom elements" as a bunch 
 of nested div's.  How does introducing custom elements make it worse?
>>>
>>> I believe the rest of my comment already addressed this.
>>
>> Sorry, I don't follow.
>>
 >> - I realise that to some extent developers already aren't using native 
 >> elements, in part because of the styling issues we've discussed which 
 >> also affect is=. My concern here is that custom elements will further 
 >> legitimise this habit, which we've been making some recent progress in 
 >> changing - we stand to backslide on that effort. Having is= would allow 
 >> us to roll it into the "use native elements where possible" message 
 >> rather than diluting it with "unless you're using a custom element in 
 >> which case here's a checklist which you're not going to look at of 
 >> everything it should do" until we come up with an alternative.

 In the case of stylizing elements, it doesn't really matter if authors 
 attach a shadow DOM on top of a builtin input element or to a div because 
 as soon as the shadow DOM replaces the rendered contents, we can't make 
 assumptions about how to expose that element to AT.
>>>
>>> That's simply not true at all. If someone replaces the rendered content of 
>>> a ``, we know that their intent is to create an element which is 
>>> semantically a button, and may even be rendered as a button in some cases. 
>>> Similarly for `` with a `type` attribute. This is no different to 
>>> using an ARIA role as far as assistive technology is concerned.
>>
>> Perhaps I should have said "we can't _always_ make assumptions about how to 
>> expose that element to AT."
>>
>> Consider creating a date picker in the time we haven't added type=date yet.  
>> Inside the shadow DOM of this color picker may contain various buttons and 
>> controls to move between months and pick a date.  Treating the entire 
>> control as a text field will provide a very poor user experience.
>
> Ah, I see what you're saying now, thanks for clarifying.
>
> In this case, the custom element author can add semantic markup inside Shadow 
> DOM just as the browser does for a date picker currently - no assumptions 
> need to be made, since even in the case of type extensions the Shadow DOM is 
> available to the accessibility tree. I don't think it will ever treat the 
> entire control as a text field.

If you're fine with that, why don't you just let authors just put ARIA role in 
buttons' shadow DOM as well?

It would also mean that the author must override the ARIA role implicitly set 
(text field) by UA in this case.  I'd say that's exactly the kind of "feature" 
that makes the Web platform annoying.

>> All the use cases I can think of that let UA can safely make assumptions 
>> about the ARIA role of the element involves tweaking the appearance, which 
>> is better served by better styling mechanisms for form controls.
>>
> I don't think it's an either/or question between is= and styling mechanisms 
> for form controls. I actually think we need both.

Why?  Having authors use two completely different mechanisms to define 
semantics seems like the worst of the both worlds.

- R. Niwa

RE: [ime-api] [blink-dev] Removing IME API code from Blink

[Travis Leithead]

That sounds good to me (working the UI challenges for IME together with 
grammar/spell checking). Is this a direction the current IME spec could 
take--possibly with a big refactor to consider dropping the ClientRect 
exposure--or would it be better to publish as Note the current approach and 
start a new spec?

Perhaps it doesn't really matter as the above is a process question, and what 
is really needed is someone to start suggesting some concrete proposals 
here--I've been pretty much ignoring this spec for the past year, and I don't 
see that changing in the near future. It's still something I'd like to see 
moved forward, I just don't believe I have the time to move it substantially 
forward at the present moment :)

-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com] 
Sent: Wednesday, May 27, 2015 7:00 PM
To: Travis Leithead
Cc: Arthur Barstow; public-webapps
Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink


> On May 27, 2015, at 11:46 AM, Travis Leithead  
> wrote:
> 
> I believed the use-cases for avoiding UI clashes between site-driven 
> auto-complete lists and IME auto-complete boxes is still a valid use case, 
> and I think the spec is still valid to try to push to recommendation. 
> However, I'd also like to follow up on usage of the ms- prefixed API so that 
> I can get an idea of what its real usage is.

I agree avoiding UI clashes between auto-completions of IME and web page is a 
great use case but I'm not convinced that exposing ClientRect for IME is the 
right API as many Web developers aren't even aware of UI challenges IME 
imposes. For example, a similar UI challenge emerges when dealing with 
auto-corrections in grammar/spell checking features as well.  It would be ideal 
if IME and spell/grammar corrections are handled in a similar manner so that 
Web apps supporting either feature will "just work" with both features.

- R. Niwa

RE: [ime-api] Fwd: [blink-dev] Removing IME API code from Blink

[Travis Leithead]

I believed the use-cases for avoiding UI clashes between site-driven 
auto-complete lists and IME auto-complete boxes is still a valid use case, and 
I think the spec is still valid to try to push to recommendation. However, I'd 
also like to follow up on usage of the ms- prefixed API so that I can get an 
idea of what its real usage is.

-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com] 
Sent: Wednesday, May 27, 2015 5:59 AM
To: public-webapps
Subject: [ime-api] Fwd: [blink-dev] Removing IME API code from Blink

Below is a proposal to remove the "experimental" IME API implementation from 
Blink.

Is there sufficient interest from other implementers to keep this spec on the 
TR track or should we formally stop work on it and publish a WG Note?

Travis, All, WDYT?

-Thanks, ArtB

 Forwarded Message 
Subject:[blink-dev] Removing IME API code from Blink
Date:   Wed, 27 May 2015 14:15:15 +0900
From:   Takayoshi Kochi 
To: blink-dev 



IME API, experimentally implemented a while ago, has been under experimental 
flag but we haven't got enough signal from users to get it out of experimental.
Therefore I'm thinking of removing the code from Blink (and Chromium) for code 
health.
This is not an intent to deprecate, and if we get enough interest we may 
readd/reimplement the spec.

We don't have real-world usage number of IME API.  Even though IE11 implements 
IME API, theirs are ms- prefixed (while Blink's is unprefixed) and some of 
their API are available under Metro mode only due to their implementation 
details, so we guess the number of people who depend on the existence of the 
API is quite small.

Any objections?

spec: http://www.w3.org/TR/ime-api/
bug: crbug.com/226938 
chromestatus: https://www.chromestatus.com/features/6366722080636928
Intent to implement: 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/sxuEbPN6pPY/QpNxXgJyoScJ

caniuse: http://caniuse.com/#cats=JS%20API
--
Takayoshi Kochi
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org
.

RE: [webcomponents] How about let's go with slots?

[Travis Leithead]

This works for me too.

And I like the proposed new bikeshed-ed names Anne suggests below.

-Original Message-
From: Anne van Kesteren [mailto:ann...@annevk.nl] 
Sent: Wednesday, May 20, 2015 9:10 PM
To: Dimitri Glazkov
Cc: Scott Miles; Ryosuke Niwa; Edward O'Connor; Travis Leithead; Maciej 
Stachowiak; Arron Eicholz; public-webapps
Subject: Re: [webcomponents] How about let's go with slots?

On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov  wrote:
> Given that all vendors agreed that "C" can wait until v2, we could 
> just focus on concretizing the "slots" proposal and then put a lid on 
> Shadow DOM v1.
>
> What do you think, folks?

This probably works for Mozilla. It would be good to see the proposed 
processing model and its implications for an eventual imperative API.
It's somewhat troubling we don't agree on synchronous vs 
when-layout-or-event-dispatch-happens.

Also, I suggest we bikeshed the markup in the direction of slot=some-slot-name 
and  rather than content-slot=some-slot-name and 
.


--
https://annevankesteren.nl/

RE: Shadow DOM: state of the distribution API

[Travis Leithead]

I wonder if there is some sort of imperative-declarative model that we could 
adopt here? I mean, allow script to specify the distribution logic, but do it 
with a static model. After all, what is being asked for is a relatively simple 
mapping from candidate node to content distribution point.

I’m just thinking out loud here, but what about something like:

assignDistributionMap( {
   source: {
 /* examples… */
 tagName: “foo”,
 className: “bar”
 childIndex: 2,
 selector: “”,
 textContains: “some text”,
   },
   target:
} );

And then providing a mechanism to notify the app when the set of distribution 
targets changes (which should be a relatively rare occurrence)?

Thinking creatively, this could be modified to be an ordered list of “fill” 
candidate rules, where the first filled rule takes the selection…?

This could also be used to provide flags indicating whether children, or 
subtrees should be considered for distribution candidates, etc.

RE: Custom Elements: is=""

[Travis Leithead]

Yes, I think you are understanding correctly, and it appears this would be a 
side-effect ☺. You have the same problem with two implementations of x-button 
though the pool of custom element names is going to be larger.

Do you think this will be a problem in practice?

From: Justin Fagnani [mailto:justinfagn...@google.com]
Sent: Friday, May 8, 2015 1:06 PM
To: Travis Leithead
Cc: Ryosuke Niwa; Anne van Kesteren; WebApps WG
Subject: Re: Custom Elements: is=""

If I'm understanding your proposal correctly, wouldn't this limit any document 
to have a single subclass per native element?

How would you express:

Me
You

-Justin

On Fri, May 8, 2015 at 12:56 PM, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
The 'is' attribute is only a declarative marker; it's the indicator that the 
native element has a [potential] custom prototype and hierarchy, right?

I don't mean to drudge up past history and decisions already laid to rest, but 
if subclassing native elements is a good compromise until we get to the 
underlying behaviors that make up native HTML elements, why should we limit 
registerElement to hyphenated custom element names?

In other words, why not simplify by:
1. Allow any localName to be used by registerElement. (This would imply the 
HTML namespace by default; we can later add registerElementNS if needed :)
2.  Drop the 'extends' member from the ElementRegistrationOptions dictionary.

With this simplification, serializing elements wouldn't include any sign that 
they are 'customized' in any way (as is done with 'is' today). I don't see this 
as a problem, since web devs today can already do this, but without the help of 
the parser.

It always seemed weird to me that 'prototype' of ElementRegistrationOptions can 
inherit from anything (including null), and be completely disassociated from 
the localName provided in 'extends'.

If we drop support for 'is' in v1, then we can consider later bringing back 
subclassing in v2 without introducing 'extends' in the 
ElementRegistrationOptions or the 'is' attribute.

If we opt to keep the feature, I'd like to see it simplified as described above.

(In general: I'd also like to see a 'constructor' property added automatically 
to the prototype so that you can always get to the native constructor function 
from script even if you don't save the return value of registerElement.)


> On May 6, 2015, at 6:25 AM, Anne van Kesteren 
> mailto:ann...@annevk.nl>> wrote:
>
> Open issues are kept track of here:
>
>  https://wiki.whatwg.org/wiki/Custom_Elements
>
> I think we reached rough consensus at the Extensible Web Summit that
> is="" does not do much, even for accessibility. Accessibility is
> something we need to tackle low-level by figuring out how builtin
> elements work:
>
>  https://github.com/domenic/html-as-custom-elements
>
> And we need to tackle it high-level by making it easier to style
> builtin elements:
>
>  http://dev.w3.org/csswg/css-forms/
>
> And if the parser functionality provided by is="" is of great value,
> we should consider parsing elements with a hyphen in them differently.
> Similar to how 

RE: Custom Elements: is=""

[Travis Leithead]

The 'is' attribute is only a declarative marker; it's the indicator that the 
native element has a [potential] custom prototype and hierarchy, right?

I don't mean to drudge up past history and decisions already laid to rest, but 
if subclassing native elements is a good compromise until we get to the 
underlying behaviors that make up native HTML elements, why should we limit 
registerElement to hyphenated custom element names?

In other words, why not simplify by:
1. Allow any localName to be used by registerElement. (This would imply the 
HTML namespace by default; we can later add registerElementNS if needed :)
2.  Drop the 'extends' member from the ElementRegistrationOptions dictionary.

With this simplification, serializing elements wouldn't include any sign that 
they are 'customized' in any way (as is done with 'is' today). I don't see this 
as a problem, since web devs today can already do this, but without the help of 
the parser.

It always seemed weird to me that 'prototype' of ElementRegistrationOptions can 
inherit from anything (including null), and be completely disassociated from 
the localName provided in 'extends'.

If we drop support for 'is' in v1, then we can consider later bringing back 
subclassing in v2 without introducing 'extends' in the 
ElementRegistrationOptions or the 'is' attribute.

If we opt to keep the feature, I'd like to see it simplified as described above.

(In general: I'd also like to see a 'constructor' property added automatically 
to the prototype so that you can always get to the native constructor function 
from script even if you don't save the return value of registerElement.)


> On May 6, 2015, at 6:25 AM, Anne van Kesteren  wrote:
> 
> Open issues are kept track of here:
> 
>  https://wiki.whatwg.org/wiki/Custom_Elements
> 
> I think we reached rough consensus at the Extensible Web Summit that 
> is="" does not do much, even for accessibility. Accessibility is 
> something we need to tackle low-level by figuring out how builtin 
> elements work:
> 
>  https://github.com/domenic/html-as-custom-elements
> 
> And we need to tackle it high-level by making it easier to style 
> builtin elements:
> 
>  http://dev.w3.org/csswg/css-forms/
> 
> And if the parser functionality provided by is="" is of great value, 
> we should consider parsing elements with a hyphen in them differently.
> Similar to how 

RE: [components] Isolated Imports and Foreign Custom Elements

[Travis Leithead]

>> (1) All of the parameters to registerElement() should really be provided by 
>> the cross-origin element itself. It makes no sense for prototype and extends 
>> to come from the hosting environment.

It does makes sense for the cross-origin component to own the element name and 
extends that it defines, as this name may be important for its documentation 
and potentially sub-classing behavior. So +1 to that, though when handing that 
naming control to the host, the host can independently manage naming 
collisions. I'm just mentioning that--not suggesting that we should design for 
that particular use case.

On the API control:
One other approach I considered was to use ES6 proxies in some way, because the 
drawback with the property descriptor approach (if you consider it a drawback) 
is that you can't create cross-origin components whose elements act like DOM 
Collections (e.g. the behavior of 'window' or 'form' which have named 
property/indexed property getters). Perhaps these 'feature' of the current DOM 
should be discouraged in component creation, but if not, you'd need something 
with the flexibility of ES6 Proxies. I stuck with property descriptors in the 
proposal because Proxy use seems like overkill for the simple API definition 
scenarios (in other words, for a simple property, I don't want to have to 
define the proxy handler methods: has, get, deleteProperty, enumerate, ownKeys, 
etc. I'm not sure to what extent your two-way membrane proxy would handle this 
case...


-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com] 
Sent: Friday, May 1, 2015 2:57 PM
To: Travis Leithead
Cc: Anne van Kesteren; WebApps WG
Subject: Re: [components] Isolated Imports and Foreign Custom Elements


Your proposal seems conceptually very similar to mine. I guess that’s a good 
sign!

It seems the biggest difference is the foreign registration hook - whether it’s 
done at class registration time (registerElement) or done at import time.

The reasons I did not go with class registration time are:

(1) All of the parameters to registerElement() should really be provided by the 
cross-origin element itself. It makes no sense for prototype and extends to 
come from the hosting environment.
(2) You need to define an elaborate protocol for the outside origin to do the 
“inside” of the registration operation.
(3) At least in the obvious way to do it, you need one external document per 
custom element type.
(4) It’s less aligned with regular HTML imports, which are the non-cross-origin 
non-isolated tool for importing a bunch of element definitions.
(5) Documents referenced by  can be preloaded aggressively, but loads 
initiated from a script parameter cannot.

On these grounds, I think doing the loading at import time, and explicit 
import/export lists, are a simpler and cleaner solution. It sounds like you 
agree with some of the reasons below.

I guess the other big difference is that your approach allows customizing what 
API is exposed, rather than proxying everything defined by the custom element 
instance in its own world. That is intriguing to me, but I’m not sure it’s 
necessary. The custom element can have truly private methods and slots by using 
ES6 symbols, and my proposed rule to do extended structured cloning on 
parameters and returns limits the risk of exposing everything. But I agree with 
you that if we need fine-grained API control, it’s better to do it with 
property descriptor-like structures than in a fully programmatic way.

Regards,
Maciej

> On May 1, 2015, at 10:46 AM, Travis Leithead  
> wrote:
> 
> If you take a look at [1], we extend the custom elements registration 
> mechanism so that the constructor is still available in the hosting global, 
> yet the implementation is defined in the isolated environment.
> 
> An approach to solving this might address another concern I have...
> 
> I've been thinking about the way that the APIs are created with my proposal 
> and the design wherein you have an explicit API to create the API signature 
> on the prototype (and instances) leaves a lot of room for potential issues. 
> For example:
> * Nothing requires the isolated component to create any APIs initially 
> (leaving the custom element without any API until some random later time of 
> the isolated component's choosing).
> * There is no way to know when the isolated component's APIs creation is 
> "done"
> * The isolated component can remove APIs at any time; this is not a 
> pattern that user agents ever make use of and there's no use case for 
> it--doesn't seem appropriate to give this power to the isolated 
> component
> 
> To address these problems, if you change the model to work more like what 
> Maciej proposed where you can have N number of custom elements defined by one 
> globa

RE: [components] Isolated Imports and Foreign Custom Elements

[Travis Leithead]

If you take a look at [1], we extend the custom elements registration mechanism 
so that the constructor is still available in the hosting global, yet the 
implementation is defined in the isolated environment.

An approach to solving this might address another concern I have...

I've been thinking about the way that the APIs are created with my proposal and 
the design wherein you have an explicit API to create the API signature on the 
prototype (and instances) leaves a lot of room for potential issues. For 
example:
* Nothing requires the isolated component to create any APIs initially (leaving 
the custom element without any API until some random later time of the isolated 
component's choosing).
* There is no way to know when the isolated component's APIs creation is "done"
* The isolated component can remove APIs at any time; this is not a pattern 
that user agents ever make use of and there's no use case for it--doesn't seem 
appropriate to give this power to the isolated component

To address these problems, if you change the model to work more like what 
Maciej proposed where you can have N number of custom elements defined by one 
global, then in the creation of a particular custom element (specifically it's 
prototype) you can specify what APIs should be defined on it in one shot 
(creation time) and don't provide any other way to do it. This naturally 
satisfies my above concerns. So, a rough sketch might be something like:

   void exportElement(DOMString customElementName, PropDescDictionary 
definitions);

usage example:

```js
document.exportElement("element-name", {
api1: { enumerable: true, value: function() { return "hello, from the 
isolated component"; }},
api2: { /* etc... */ }
});
// returns void (or throws is "element-name" is already defined/exported?)
```

Once you divorce the isolated component in this way, you rightly point out the 
problem of how to get the custom element's constructor function exported 
outside of the isolated environment. One possible approach to solve this allows 
the host to ask for the custom element constructor function explicitly. Rough 
idea:

Function importConstructor("element-name");

usage example:

```js
window.MyElementName = document.importConstructor("element-name");
// now new MyElementName(); returns an instance of "element-name" element
```

You can imagine this might be useful for any custom element (either those 
exported as shown above, or those defined using registerElement -- the 
non-isolated custom elements).

Just some food for thought.

[1] 
https://github.com/w3c/webcomponents/wiki/Cross-Origin-Custom-Elements:-Concept-and-Proposal

-Original Message-
From: Anne van Kesteren [mailto:ann...@annevk.nl] 
Sent: Friday, May 1, 2015 9:48 AM
To: Maciej Stachowiak
Cc: WebApps WG
Subject: Re: [components] Isolated Imports and Foreign Custom Elements

On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak  wrote:
> I wrote up a proposal (with input and advice from Ryosuke Niwa) on a 
> possible way to extend Web Components to support fully isolated components:
>
> https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal
>
> I welcome comments on whether this approach makes sense.

I don't get the bit where you create a node in one global, but run its 
constructor in another. That seems rather Frankenstein-esque. Would love to see 
more details overall, as the direction this is going in certainly seems like 
the kind of thing we want. Allowing a dozen Facebook Like buttons to appear on 
a page using only one additional global.


--
https://annevankesteren.nl/

RE: Directory Upload Proposal

[Travis Leithead]

>> Aaron opened an issue for this on GitHub [1] and I agree that it is a 
>> problem and we should definitely rename it to something else! One option 
>> might be to change dir to directory, but we would need a different name for 
>> directory (the attribute that gets back the virtual root holding the 
>> selected files and folders).

I wonder, is it necessary to have a separate "dir"/"directory" attribute from 
"multiple"? Adding a new DOM attribute will allow for feature detecting this 
change. UA's can handle the presentation of a separate directory picker if 
necessary--why force this distinction on the web developer?

-Original Message-
From: Ali Alabbas [mailto:a...@microsoft.com] 
Sent: Tuesday, April 28, 2015 4:21 PM
To: Tab Atkins Jr.; Ryan Seddon
Cc: Web Applications Working Group WG
Subject: RE: Directory Upload Proposal

On Tue, Apr 28, 2015 at 4:15 PM, Tab Atkins Jr.  wrote:

>On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon  wrote:
>>> To enable developers to build future interoperable solutions, we've 
>>> drafted a proposal [4], with the helpful feedback of Mozilla and 
>>> Google, that focuses strictly on providing the mechanisms necessary 
>>> to enable directory uploads.
>>
>> The use of the dir attribute seems odd since I can already apply dir="rtl"
>> to an input to change the text direction.
>
>Good catch; that's a fatal naming clash, and needs to be corrected.
>The obvious one is to just expand out the name to "directory".
>
>~TJ

Aaron opened an issue for this on GitHub [1] and I agree that it is a problem 
and we should definitely rename it to something else! One option might be to 
change dir to directory, but we would need a different name for directory (the 
attribute that gets back the virtual root holding the selected files and 
folders).

[1] https://github.com/InternetExplorer/directory-upload/issues/1

RE: Directory Upload Proposal

[Travis Leithead]

>> Second, rather than adding a .directory attribute, I think that we should 
>> simply add any selected directories to the .files list. My experience is 
>> that having a direct mapping between what the user does, and what we expose 
>> to the webpage, generally results in less developer confusion and/or 
>> annoyance.

I like this consolidation, but Ali concern (and one I share) is that legacy 
code using .files will not expect to encounter new Directory objects in the 
list and will likely break unless the Directory object maintains a 
backwards-compatible File-like appearance.

In the proposed model, the "directory" would be a virtual wrapper around any 
existing selected files, and could wholly replaces .files, while providing a 
nice extension point for additional behavior later.

I have a concern about revealing the user's directory names to the server, and 
suggested anonymizing the names, but it seems that having directory path names 
flow through to the server intact is an important scenario for file-syncing, 
which anonymizing might break.

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Monday, April 27, 2015 9:45 PM
To: Ali Alabbas
Cc: Web Applications Working Group WG
Subject: Re: Directory Upload Proposal

On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas  wrote:
> Hello WebApps Group,

Hi Ali,

Yay! This is great to see a formal proposal for! Definitely something that 
mozilla is very interested in working on.

> If there is sufficient interest, I would like to work on this within the 
> scope of the WebApps working group.

I personally will stay out of WG politics. But I think the proposal will 
receive more of the needed attention and review in this WG than in the HTML WG. 
But I'm not sure if W3C policies dictate that this is done in the HTML WG.

> [4] Proposal: 
> http://internetexplorer.github.io/directory-upload/proposal.html

So, some specific feedback on the proposal.

First off, I don't think you can use the name "dir" for the new attribute since 
that's already used for setting rtl/ltr direction.
Simply renaming the attribute to something else should fix this.



My understanding is that the current proposal is mainly so that if we in the 
future add something like Directory.enumerateDeep(), that that would 
automatically enable deep enumeration through all user options.
However that could always be solved by adding a
HTMLInputElement.enumerateFilesDeep() function.

/ Jonas

RE: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Travis Leithead]

Nice work folks, and thanks for writing this up so quickly! Anne's Gist 
captured exactly what I was thinking this would look like.

One nit: it would be nice if the callback could be registered from _inside_ the 
shadowRoot, but I couldn't come up with a satisfactory way to do that without 
adding more complexity. :)

-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com] 
Sent: Saturday, April 25, 2015 10:13 AM
To: Anne van Kesteren
Cc: WebApps WG; Erik Bryn; Dimitri Glazkov
Subject: Re: Imperative API for Node Distribution in Shadow DOM (Revisited)


> On Apr 25, 2015, at 9:28 AM, Anne van Kesteren  wrote:
> 
>> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
>> In today's F2F, I've got an action item to come up with a concrete workable
>> proposal for imperative API.  I had a great chat about this afterwards with
>> various people who attended F2F and here's a summary.  I'll continue to work
>> with Dimitri & Erik to work out details in the coming months (our deadline
>> is July 13th).
>> 
>> https://gist.github.com/rniwa/2f14588926e1a11c65d3
> 
> I thought we came up with something somewhat simpler that didn't
> require adding an event or adding remove() for that matter:

That's the second approach I mentioned.  Like I mentioned in the gist, this 
model assumes that redistribution is done by UA and only direct children can be 
distributed.  I realized that those constraints are no longer necessary given 
we don't have content select or multiple generations of shadow DOM.

>  https://gist.github.com/annevk/e9e61801fcfb251389ef
> 
> I added an example there that shows how you could implement  select>, it's rather trivial with the matches() API. I think you can
> derive any other use case easily from that example, though I'm willing
> to help guide people through others if it is unclear. I guess we might
> still want positional insertion as a convenience though the above
> seems to be all you need primitive-wise.
> 
> 
> -- 
> https://annevankesteren.nl/
> 

Web Components Viewpoint from the Microsoft Guy

[Travis Leithead]

Like Mozilla and Apple [1] [2], I would also like to briefly lay out my 
viewpoint on Web Components in advance of the face-to-face meeting.

I love the work that has been done thus far on the web components specs, and 
while Microsoft has not yet begun development of these features [3] I know they 
support the use cases and are excited to see the success that early 
implementations have had. As has been said, I also feel that there are some 
rough edges among the present set of web components specifications. I also 
believe that some important additional features are necessary to complete the 
web components usage and development experience for web developers. Finally, 
I'm also a fan of simplification where appropriate, both in terms of helping 
facilitate quicker interoperability, as well as making an implementations 
easier :-)

I make reference to some proposals below (special thanks to Arron Eichols for 
helping me navigate the weird waters of CSS). I want to emphasize that these 
are primarily Arron and I's own work and should not be considered an official 
Microsoft proposal. 

The following views are organized by spec. They cover the breadth of web 
component features. At the face-to-face meeting, our shared goal is to 
primarily resolve issues in Shadow DOM--the rest of this viewpoint is provided 
for reference and in case the scope of the meeting is expanded ;-)

--Shadow DOM---

Open vs. closed
* I think that both types of shadow doms should be available in the platform, 
but believe that developers asking for a closed shadow dom often want more 
strict encapsulation [4] than simply closing off access to the shadowRoot. I'm 
not sure whether it makes sense to have 1) a "simple" closed shadow root as 
well as 2) a fully encapsulated closed shadow root in the platform. Similar to 
Apple's "isolated imports" and Mozilla's "isolated Shadow DOM" ideas, I'd like 
to propose "isolated custom elements" [5], but think such a feature is additive 
and doesn't need to block progress of any of the existing specs.

Generational Shadow DOMs
* I support Apple's proposal to simplify this concept in favor of some form of 
named slots.

Imperative Distribution API
* I'm in favor of pursing this, but don't feel it needs to block progress.

Event Retargeting
* I believe that for open Shadow DOM's this isn't necessary. I think some form 
of event retargeting is necessary for a closed component.

Declarative Syntax
* I support Mozilla's idea for a straightforward Shadow DOM declarative syntax 
to help with serialization and parsing scenarios. We don't think this blocks 
progress on the current spec.

--Custom Elements

Construction
* I support synchronous or the "almost-synchronous" construction options for 
their simplicity and rationality.

Inheritance
* I don't object to inheritance from any arbitrary element--though I've heard 
that many developers expect to inherit _behavior_ and element _semantics_ 
(e.g., Accessibility behaviors) as well, and that this might lead to failed 
expectations.

--Styling/CSS---

Default Styles
* Both Microsoft internal and external customers have told me they need the 
ability to style components (not necessarily just those that might have a 
Shadow DOM) with "default" styles that can be overridden by author styles. I 
offer a proposal to support this [6].

Shadow Piercing
* I believe that the correct platform technique for achieving style isolation 
is through Shadow DOM, and that it might be necessary to have the shadow 
piercing combinator. I'm interested in exploring other ideas that may obviate 
the need for the combinator. *If* the shadow piercing combinator is retained as 
currently defined, then it should be tempered with the ability for component 
authors to control which styles it can affect. Such a feature might look like a 
new general technique for styling control [7] which limits the capability of 
the shadow dom piercing combinator. The proposal could also be used to open up 
styling control to iframes using the combinator in order to help fix the 
current iframe[seamless] situation.

--Template--

Databinding
* I think it is still premature to standardize any particular data-binding 
syntax on top of the template element. There is a thriving set of existing 
JavaScript-based data-binding libraries and there doesn't appear to be a 
particular dominant technique.

--HTML Imports

link[rel=import]
* I would like to focus our efforts on developing and understanding the ES6 
module loader before pursuing an implementation of this spec.

-Travis

[1] http://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0052.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0225.html
[3] https://status.modern.ie/?term=web%20components
[4] 
http://www.w3.org/2008/webapps/wiki/C

RE: Proposal for changes to manage Shadow DOM content distribution

[Travis Leithead]

I like that the light-side DOM elements must opt-in to being redistributed. 
While appearing at first like a hindrance, it does ensure that elements can't 
be arbitrarily re-distributed without their consent. If you imagine allowing 
redistribution into a cross-origin shadow dom, then it becomes somewhat more 
important to be a bit more cautious (or at least declarative). I like the 
cooperative symmetry.

I also like the idea of being able to drop the multiple shadow trees 
requirement. Can this still be accomplished if select="" is not used? I'm still 
grokking the details...

From: Ryosuke Niwa [mailto:rn...@apple.com]
Sent: Wednesday, April 22, 2015 2:37 PM
To: Justin Fagnani
Cc: Daniel Freedman; WebApps WG; Edward O'Connor; Jan Miksovsky
Subject: Re: Proposal for changes to manage Shadow DOM content distribution


On Apr 22, 2015, at 10:16 AM, Justin Fagnani 
mailto:justinfagn...@google.com>> wrote:



On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa 
mailto:rn...@apple.com>> wrote:

> On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
> mailto:justinfagn...@google.com>> wrote:
>
> I do want the ability to redirect distributed nodes into a holes in the base 
> template, so that part is welcome to me. However, my first reaction to the 
> slot idea is that forcing users to add the content-slot attribute on children 
> significantly impairs the DOM API surface area of custom elements.
>
> For the single-level distribution case, how is this different from  select="[content-slot=name]"> except that content select can distribute based 
> on features of the children that might already exist, like tag names or an 
> attribute?

At the conceptual level, they're equivalent.  However, we didn't find the extra 
flexibility of using CSS selectors compelling as we mentioned in our proposal 
[1].

I personally would like to see more power, especially positional selectors. 
Some components would be better off selecting their first child, rather than 
requiring a class.

What are concrete use cases that require such flexibility?

[1] See points 3 and 4 in 
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec

Point 4 is interesting, because unless I'm missing something (which could be!) 
it's incorrect. You can create selectors with :not() that exclude the content 
selectors that come after in document order. I would rewrite the example as:




  

  

  


Our point wasn't so much that it's not achievable.  With enough hackeries and 
"techniques", we can.  The problem is the developer ergonomics of content 
element with select attribute with common real world use cases.  For example, 
the above code is a lot more verbose and less intuitive than




  

  

  


- R. Niwa

RE: [Imports] Considering imperative HTML imports?

[Travis Leithead]

Hmmm. Well, regardless, this is tracked here: 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319, so I'll add a few 
comments to that bug.

-Original Message-
From: Anne van Kesteren [mailto:ann...@annevk.nl] 
Sent: Thursday, April 16, 2015 12:54 PM
To: Travis Leithead
Cc: Boris Zbarsky; public-webapps@w3.org
Subject: Re: [Imports] Considering imperative HTML imports?

On Thu, Apr 16, 2015 at 9:36 PM, Travis Leithead 
 wrote:
> Oh! XHR slipped my mind. It would be identical :) (Though perhaps a 
> tiny-bit easier to use.)

Would it? Imports load subresources and execute scripts within the global of 
the importer. (Forgot what happens to stylesheets.)


--
https://annevankesteren.nl/

RE: [Imports] Considering imperative HTML imports?

[Travis Leithead]

Oh! XHR slipped my mind. It would be identical :) (Though perhaps a tiny-bit 
easier to use.)

-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu] 
Sent: Thursday, April 16, 2015 11:30 AM
To: public-webapps@w3.org
Subject: Re: [Imports] Considering imperative HTML imports?

On 4/16/15 12:37 AM, Travis Leithead wrote:
> Was an imperative form of HTML imports already considered? E.g., the 
> following springs to mind:
>
>Promise importDocument(DOMString url);

How is this different from a promise-ified version of XHR, exactly? 
(Not that there's anything wrong with that; just trying to understand the 
proposal.)

-Boris

[Imports] Considering imperative HTML imports?

[Travis Leithead]

Was an imperative form of HTML imports already considered? E.g., the following 
springs to mind:
  Promise importDocument(DOMString url);

I was thinking about Worker's importScripts(DOMString... urls), and the above 
seems like a nice related corollary.

RE: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

[Travis Leithead]

Microsoft supports publishing this. Thanks to all involved!

-
Subject:CfC: publish Proposed Recommendation of Web Messaging; 
deadline March 28
Date:   Sat, 21 Mar 2015 08:51:45 -0400
From:   Arthur Barstow 
To: public-webapps 

As previously mentioned on [p-w], the test results for Web Messaging 
[All] indicate significant interoperability with only two tests that 
have less than two passes [<2]. The two tests, including a short 
analysis of the failure, are:

1. ; this test 
failure (which passes on Firefox) can be considered more of a Web IDL 
implementation issue and thus not a significant interop issue.

2. ; this 
test failure (which passes on IE) is considered an implementation bug 
(MessageChannel and MessagePort are supposed to be exposed to Worker) 
that is expected to be fixed.

Cindy created a Draft PR [PR] that includes Hixie's updates since the 
[CR] was published (but not the PortCollection interface [PC] which is 
not broadly implemented). Overall, we consider the changes since the CR 
as non-substantive bug fixes and clarifications that align the spec with 
current implementations, and that the test suite tests the updated spec. 
See [Diff] for all of changes between the CR and the draft PR and note 
the draft PR's status section includes a short summary of the changes.

As such, this is a Call for Consensus to publish a Proposed 
Recommendation of Web Messaging using the [PR] as the basis. Agreement 
with this CfC means you consider the test results shows interoperability 
and the changes since CR are not substantive.

If you have any comments or concerns about this CfC, please reply to 
this e-mail by March 28 at the latest. Positive response is preferred 
and encouraged, and silence will be considered as agreement with the 
proposal. If there are no non-resolvable objections to this proposal, 
the motion will carry and we will request the PR be published.

-Thanks, ArtB

[p-w] 

[All] 
[<2] 
[PR] 
[CR] 
[PC] 
[Diff] 

RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

[Travis Leithead]

You make a series of excellent points.

In the sense that you have a new set of nodes to manage holistically, then 
having some sort of “document” container does makes sense for that (a 
ShadowRoot) in order to place all your search/navigation APIs.

You got me thinking though—getElementById is currently not available on 
ShadowRoot right? Does that API in the host’s document find IDs in the shadow? 
I presume not given the guidelines you mentioned. I wonder what other APIs from 
Document are desired?

Back to the original question though… is removal of previously-created shadow 
roots something that makes sense?

From: Elliott Sprehn [mailto:espr...@chromium.org]
Sent: Thursday, March 26, 2015 12:59 PM
To: Travis Leithead
Cc: Justin Fagnani; Dimitri Glazkov (dglaz...@google.com); Arron Eicholz; Anne 
van Kesteren (ann...@annevk.nl); Ryosuke Niwa; WebApps WG
Subject: Re: [Shadow] Q: Removable shadows (and an idea for lightweight 
shadows)?



On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
> From: Justin Fagnani 
> [mailto:justinfagn...@google.com<mailto:justinfagn...@google.com>]
>> Elements expose this “shadow node list” via APIs that are very similar to
>> existing node list management, e.g., appendShadowChild(), 
>> insertShadowBefore(),
>> removeShadowChild(), replaceShadowChild(), shadowChildren[], 
>> shadowChildNodes[].
>
>This part seems like a big step back to me. Shadow roots being actual nodes 
>means
>that existing code and knowledge work against them.

"existing code and knowledge work against them" -- I'm not sure you understood 
correctly.
Nodes in the "shadow child list" wouldn't show up in the childNodes list, nor 
in any of the
node traversal APIs (e.g., not visible to qSA, nextSibling, previousSibling, 
children, childNodes,
ect.

Trivially speaking, if you wanted to hide two divs that implement a "stack 
panel" and have some
element render it, you'd just do:
element.appendShadowChild(document.createElement('div'))
element.appendShadowChild(document.createElement('div'))

Those divs would not be discoverable by any traditional DOM APIs (they would 
now be on the
"shadow side"), and the only way to see/use them would be to use the new 
element.shadowChildren
collection.

But perhaps I'm misunderstanding your point.

>The API surface that you'd have to duplicate with shadow*() methods would be 
>quite large.

That's true. Actually, I think the list above is probably about it.

So if I want to query down into those children I need to do 
element.shadowFirstChild.querySelectorAll or shadowFirstChild.getElementById? 
That requires looking at all siblings in the shadowChildList, so I suppose 
you'd want shadowQuerySelector, shadowGetElementById, etc? You also need to 
duplicate elementFromPoint (FromRect, etc.) down to Element/Text or add special 
shadow* versions since right now they only exist on Document and ShadowRoot.

I have to admit I have an allergic reaction to having an element like  and then doing element.parentNode.querySelector("#foo") != div.

Another fundamental requirement of Shadow DOM is that you never accidentally 
"fall out" or "fall into" a shadow and must always take an explicit step to get 
there. Having shadow node's parentNode be the host breaks that.

We could make the parentNode be null like ShadowRoot of today, but you're still 
stuck adding API duplication or writing code to iterate the shadowChildren list.

- E

RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

[Travis Leithead]

>From: Daniel Freedman [mailto:dfre...@google.com] 
>How would you style these "shadow" children? Would the main document CSS 
>styles affect these children?

I don’t know :-)

Let's assume that main document CSS styles wouldn't affect them, as that seems 
to be a fundamental requirement for shadowDOM.

So, then how to style them? Here's a few thoughts--but what do you think?

* Require scoped style elements. This is today's model. I don't like it much 
because of the developer ergonomics--it's not as natural as the way styles are 
applied to documents today with 

* provide new APIs to manage stylesheets for the shadow content. Maybe: 
element.importShadowStyleSheet(url), and then a corresponding 
element.shadowStyleSheets[] collection. This seems vaguely reminiscent of an 
imperative @import. Might be better to just add this capability [generally] to 
the styleSheets collection [1] come to think of it...

* other ideas?

[1] http://dev.w3.org/csswg/cssom/#stylesheetlist
 

RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

[Travis Leithead]

> From: Justin Fagnani [mailto:justinfagn...@google.com] 
>> Elements expose this “shadow node list” via APIs that are very similar to 
>> existing node list management, e.g., appendShadowChild(), 
>> insertShadowBefore(), 
>> removeShadowChild(), replaceShadowChild(), shadowChildren[], 
>> shadowChildNodes[].
>
>This part seems like a big step back to me. Shadow roots being actual nodes 
>means 
>that existing code and knowledge work against them. 

"existing code and knowledge work against them" -- I'm not sure you understood 
correctly. 
Nodes in the "shadow child list" wouldn't show up in the childNodes list, nor 
in any of the 
node traversal APIs (e.g., not visible to qSA, nextSibling, previousSibling, 
children, childNodes,
ect.

Trivially speaking, if you wanted to hide two divs that implement a "stack 
panel" and have some
element render it, you'd just do:
element.appendShadowChild(document.createElement('div'))
element.appendShadowChild(document.createElement('div'))

Those divs would not be discoverable by any traditional DOM APIs (they would 
now be on the
"shadow side"), and the only way to see/use them would be to use the new 
element.shadowChildren 
collection.

But perhaps I'm misunderstanding your point.

>The API surface that you'd have to duplicate with shadow*() methods would be 
>quite large.

That's true. Actually, I think the list above is probably about it.

RE: [Shadow] URL-based shadows?

[Travis Leithead]

>From: Anne van Kesteren [mailto:ann...@annevk.nl] 
>
>Depending on the changes we make based on
>  https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits
>
>this might already be the case. Also, I believe currently the Web
>Components polyfill makes some assumptions about all of Web Components
>being supported if you support one of them. So you can't e.g. ship
>Custom Elements without HTML Imports... So API changes might already
>be necessary just to avoid breaking the web.

I'm looking forward to the meet-up! 

[Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

[Travis Leithead]

Hi folks,

Today's ShadowDOM model is designed around only adding shadow roots to element 
in the 'light side'. I assume this is intentional, but was hoping someone could 
describe why this design was chosen? Or said another way, if there was an 
imperative API to _remove_ a shadow DOM, would that symmetry be bad?

In full transparency, I'm thinking about potential solutions for a simplified 
shadow dom, and it occurs to me that it can't get much simpler than the 
following:

*Elements only [ever] have one "shadow side" which is essentially a 
secondary child node list. Whenever anything's in this list the Element renders 
that content instead of its "light" children. (Or maybe there's a switch to 
tell the element which side to render: light or dark?)

*Elements expose this "shadow node list" via APIs that are very similar 
to existing node list management, e.g., appendShadowChild(), 
insertShadowBefore(), removeShadowChild(), replaceShadowChild(), 
shadowChildren[], shadowChildNodes[].

*No special Event swizzling, no security boundary, no alternate script 
engine, no intermediate shadow root object,  etc. This minimalist approach only 
provides node 'hiding' and potentially an alternate rendering path.

*Another feature could then provide the stronger "component" boundary, 
specifically the javascript global scope isolation. This delineation may more 
closely match the division we are seeing between the "React-like" scenarios and 
more robust component-kitchen-style custom element deployments.

RE: [Shadow] URL-based shadows?

[Travis Leithead]

>Ryosuke Niwa [mailto:rn...@apple.com] wrote:
>
>> Travis wrote:
>> 2.&4. I keep running into trouble when thinking about a declarative model 
>> for web components because declarative models are based on persistent 
>> objects in the DOM, and those persistent objects are fully mutable. In other 
>> words, you have to either accept and spec accordingly what happens when key 
>> attributes are changed (e.g., your "defines" and "interface" attributes), or 
>> you have to limit mutability such that changes are only read-once (for 
>> example). I prefer to let frameworks write the declarative syntactic sugar 
>> in the case of web components, and steer clear of declarative models unless 
>> the mutability works in favor of the proposal.
>
>This approach works for same-origin use cases but we couldn’t come up with a 
>good imperative API for cross-origin scenarios.

Focusing on the imperative API for cross-origin scenarios sounds like a useful 
endeavor to continue. Can you refer me to older proposals to review?

>> 3. I don't have an opinion here yet. It seems like limiting to custom 
>> elements makes shadow dom easier to implement. But I can also imagine cases 
>> where the component really wants to hook up to an element like  or 
>>  in order to extend its host's feature set.
>
>That use case comes up frequently on this list but I think that needs to be 
>addressed by CSS-based decorators.  If we let custom “appearance” add a JS 
>API, then UA wouldn’t be able to rip it apart for accessibility or for new 
>platforms.

Can you clarify what you mean by that last sentence? I don't follow...?

Re: [Shadow] URL-based shadows?

[Travis Leithead]

Yes, loading components via imports today is "use at your own risk" since you 
pull that content directly into your trust boundary. At least with 

RE: [Shadow] URL-based shadows?

[Travis Leithead]

> From: Ryosuke Niwa [mailto:rn...@apple.com]
>I think this idea resonates well with the cross-origin use case / API change 
>proposal we made two years ago [1].  In that proposal, we went a step further 
>and tied custom elements with URLs so that those shadow DOM can be 
>automatically instantiated by simply using those custom elements.

Thanks for the referral Ryosuke!

In reading the proposal [1], I understood the following points (that interested 
me anyway):
1. Separate (isolated) script engine (your point #1 wanting to modify imports). 
Facilitates iframe-like isolation between host and root to enable cross-origin 
use case.
2. Importing document manually declares the desired custom elements. Very 
elegant.
3. Shadow DOMs limited to custom elements.
4. Many declarative extensions to template to enable custom element bindings. I 
see you recognized template's powers at creating a non-rendered shadow-dom 
already, and just took the leap to figure out how to auto bind them to custom 
elements :-)
5. Expose dataset to the root (even cross-domain)

I'm not sure if you are still interested in pursuing all of these features, or 
what their importance/weight is at this point (two years later).

Some of my opinions, matching the numbering up to the above list:
1. I think one of the things that makes web components separate and interesting 
from existing iframes is the fact that they load and run "in context", in other 
words, in the context of the global script engine of the hosting page. I don't 
think there's anything inherently wrong with how "components" loaded via 
iframes work today, so the cross-origin use case for web components is not 
something I'm motivated to solve (using web components). I suspect that a 
cross-origin use case is important, but its level of integration will of 
necessity be more limited, and I suspect it will lead to a different design 
than what we have with current web components.
2.&4. I keep running into trouble when thinking about a declarative model for 
web components because declarative models are based on persistent objects in 
the DOM, and those persistent objects are fully mutable. In other words, you 
have to either accept and spec accordingly what happens when key attributes are 
changed (e.g., your "defines" and "interface" attributes), or you have to limit 
mutability such that changes are only read-once (for example). I prefer to let 
frameworks write the declarative syntactic sugar in the case of web components, 
and steer clear of declarative models unless the mutability works in favor of 
the proposal.
3. I don't have an opinion here yet. It seems like limiting to custom elements 
makes shadow dom easier to implement. But I can also imagine cases where the 
component really wants to hook up to an element like  or  in 
order to extend its host's feature set.
5. I like this. Though it's really only necessary for the cross-origin use case.

[1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html


From: Ryosuke Niwa [mailto:rn...@apple.com] 
Sent: Wednesday, March 18, 2015 2:26 PM
To: Travis Leithead
Cc: Dimitri Glazkov (dglaz...@google.com); WebApps WG; Anne van Kesteren 
(ann...@annevk.nl); Arron Eicholz
Subject: Re: [Shadow] URL-based shadows?


On Mar 12, 2015, at 5:46 PM, Travis Leithead  
wrote:
 
   Has the idea of loading/parsing a Shadow DOM directly from a URL been 
discussed already? (e.g., a sort-of “micro-import” or an import that parses its 
document directly into the ShadowRoot container?) I’m curious to know if 
there’s some obvious flaw that I’m missing.
 
element.createShadowRoot(“path to my component”);
 
  This is an idea around building components from the “inside out”, and using 
the URL as the basis for script-level access control to the Shadow contents.

Hi Travis,

I think this idea resonates well with the cross-origin use case / API change 
proposal we made two years ago [1].  In that proposal, we went a step further 
and tied custom elements with URLs so that those shadow DOM can be 
automatically instantiated by simply using those custom elements.

e.g. if “like-button” element was defined in 
https://webkit.org/components.html, then we can use that component by simply 
"importing" the definition:

https://webkit.org/components.html"; 
defines="like-button”>

and using it in the same document (that imported components.html):

https://build.webkit.org/";>Like 
build.webkit.org

We thought this model was more developer friendly than having each user of the 
component manually create shadow root.  We also didn’t want to make component 
authors deal with situations like a shadow root being attached to an iframe, 
input, etc..

[1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html

- R. Niwa

RE: [Shadow] URL-based shadows?

[Travis Leithead]

I think ‘Worker’ threw me off at first ☺.

My original use case was to make the current model of loading components more 
“local”, as AFAIK, these components can only presently be loaded by code you 
trust, e.g., via some script library somewhere imported via a 

Re: [Shadow] URL-based shadows?

[Travis Leithead]

Ah, thanks Dimitri.


After reading that, I'm also receiving it rather "coolly". It's a very 
interesting idea, but as it relates to web components, its errs strongly on the 
side of isolation to the degree that the component would be more isolated than 
an iframe today; at least in same-domain, non-sandboxed iframes, you can 
directly access the document via the contentWindow property if desired; 
furthermore styling of this DOMWorker thing which is running in a separate 
thread would be complex to say the least from an implementation standpoint. I 
definitely want to stay firmly on the same thread for Shadow DOMs ??.


Back to what I'm thinking...


The way I see it, an HTML Import is already a shadow DOM builder (from a URL). 
Imports point to a URL, fetch it, parse it (in the context of the parent's 
scripting global environment), and then drop the completed document (and it's 
dependents) in the 'import' property of the Link element. HTML Imports don't 
render the imported document anywhere ('cause it ain't bound to an element 
yet--where would you render it?).


If ShadowRoot constructors had the ability to load from a URL, I would propose 
that the good parts of HTML Imports be used as the model for the loaded shadow 
dom. There would be a few tweaks of course, but the model appears sound to me.


Why is this alluring to me?

* Loading a custom element is more... componentized. The element's shadow dom 
(and behavior) can be imported locally in relation to the element host. >From 
what I have heard recently, custom elements (of sufficient complexity) without 
shadow dom doesn't make much sense.
* The URL can be the basis for script-level access control to the component's 
shadow dom (a known and well-established pattern that exists for iframe).
* We can reuse much of the existing investment in imports
* Shadow dom components are allowed to independently load resources (e.g., 
notably stylesheets) behind a potentially access-controlled boundary
* Existing patterns for synchronously loading a shadow dom as work today 
(without a URL) may be largely unaffected.


____
From: Dimitri Glazkov 
Sent: Friday, March 13, 2015 10:44 AM
To: Travis Leithead
Cc: WebApps WG; Anne van Kesteren (ann...@annevk.nl); Arron Eicholz; Elliott 
Sprehn
Subject: Re: [Shadow] URL-based shadows?

... found it: 
https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1

:DG<

On Thu, Mar 12, 2015 at 6:05 PM, Dimitri Glazkov 
mailto:dglaz...@google.com>> wrote:
Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly 
received (can't remember the details).

:DG<

On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead 
mailto:travis.leith...@microsoft.com>> wrote:
Dimitri et al.,

   Has the idea of loading/parsing a Shadow DOM directly from a URL been 
discussed already? (e.g., a sort-of "micro-import" or an import that parses its 
document directly into the ShadowRoot container?) I'm curious to know if 
there's some obvious flaw that I'm missing.

element.createShadowRoot("path to my component");

  This is an idea around building components from the "inside out", and using 
the URL as the basis for script-level access control to the Shadow contents.

  Thoughts?

[Shadow] URL-based shadows?

[Travis Leithead]

Dimitri et al.,

   Has the idea of loading/parsing a Shadow DOM directly from a URL been 
discussed already? (e.g., a sort-of "micro-import" or an import that parses its 
document directly into the ShadowRoot container?) I'm curious to know if 
there's some obvious flaw that I'm missing.

element.createShadowRoot("path to my component");

  This is an idea around building components from the "inside out", and using 
the URL as the basis for script-level access control to the Shadow contents.

  Thoughts?

RE: template namespace attribute proposal

[Travis Leithead]

I would also prefer to enable this to work without any extra annotation. So 
much of the rest of how SVG/MathML are handled in HTML is seamless by design.

From: ad...@google.com [mailto:ad...@google.com] On Behalf Of Adam Klein
Sent: Thursday, March 12, 2015 11:17 AM
To: Benjamin Lesh
Cc: WebApps WG
Subject: Re: template namespace attribute proposal

On Wed, Mar 11, 2015 at 8:32 PM, Benjamin Lesh 
mailto:bl...@netflix.com>> wrote:
I'd like to propose that the  tag have a namespace="" attribute that 
allows the user to specify namespaces such as "http://www.w3.org/2000/svg";, so 
that the document fragment that comes from `.content` is created properly.

e.g.:

http://www.w3.org/2000/svg>
  


For clarity, is this significantly different from the below (which works today)?


  

  


Clearly there's an extra step here, in that accessing the SVG elements requires 
hopping into firstElementChild, but adding new namespace-related features seems 
unfortunate.

- Adam

[UIEvents] telecon minutes 10 March 2015

[Travis Leithead]

 https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html
status of the editor's draft

garykac: we hadn't moved locale and getKeyboardState into D3E because they 
required more spec work.
... we also knew that keyboard locale was underspecified.
... there was one other thing...

 See the Input Device API Sketch : 
https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit

garykac: specifically:

 Section: "What information should be supplied for keyboards?"

 It was suggested that there should a sourceDevice field in the events.

garykac: I think the immedate problem is the difference between real touch vs. 
synthesized touch.

Seems like 'isTrusted' is the answer to that.

garykac: Browsers have created "fake" mouse events when some touch events 
happen--trying to find the 'real' events.

Should we fork off the old UIEvents to continue to develop those concepts, or 
fold them into D3E/UIEvents?

garykac: I really don't want to put the old UIEvents content back--it would 
slow us down.

plh: Trying to understand
... shelf old UI Events as a note
... but give someone else the option of picking it up in the future?
... if someone started working on it later, would it go into the new UIEvents, 
or something else?

garykac: if they wanted 'locale' it might go to the spec that Rik is proposing.
... for queryKeyCap, it's more nebulous
... could go anywhere

plh: Whoever wanted to pick it up would need to figure out how to move it 
forward.

garykac: Yes, we can solve that problem later.

I think publishing as a note reflects they way things are.

garykac: are there practical implications to leaving active vs. publishing as a 
note.

plh: would the note be the current contents of UIEvents (old)?

garykac: yes, minus the boilerplate.

plh: Would someone write that up, and let me know? I can then take the next 
step?

garykac: It should say:

This was originally part of the original D3E spec which we've shelved for now, 
as we don't have time to work out the details of 'locale' and other features 
may be subsumed by a [potential] input events spec

plh: That's sufficient, thanks!
... I'll let you know what phraseology I come up with and then go from there.

garykac: We can still fix as many bugs as possible, but this is a good time to 
re-publish (with the new name).
... we'd rather do this sooner than later.

 https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html

 should be http://www.w3.org/TR/uievents/

 (instead of http://www.w3.org/TR/UI-Events/)

I think we are then ready to re-publish D3E/UIEvents.

(Gary is fixing the bug in the header, so that the link to the latest published 
version is updated.)

 The link in the header is fixed to point to w3.org/tr/uievents/
looking at bugs

garykac: 27991 - looks like we need a spot to clarify this in the spec
... maybe resolved with just a note?

RE: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

[Travis Leithead]

Marc,

I'd first mention that I am keenly interested in improving the state-of-the-art 
in DOM (I'm driving the project to update IE's 20-year-old DOM as my day job.) 
I've also done a lot of thinking about thread-safe DOM designs, and would be 
happy to chat with you more in depth about some ideas (perhaps off-list if 
you'd like).

I'd also refer you to a breakout session I held during last TPAC on a similar 
topic [1]. It had lots of interested folks in the room and I thought we had a 
really productive and interesting discussion (most of it captured in the IRC 
notes).

[1] https://www.w3.org/wiki/Improving_Parallelism_Page

-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu] 
Sent: Wednesday, February 11, 2015 12:34 PM
To: public-webapps@w3.org
Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous 
XMLHttpRequest

On 2/11/15 3:04 PM, Brendan Eich wrote:
> If you want multi-threaded DOM access, then again based on all that I 
> know about the three open source browser engines in the field, I do 
> not see any implementor taking the huge bug-risk and opportunity-cost 
> and
> (mainly) performance-regression hit of adding barriers and other 
> synchronization devices all over their DOM code. Only the Servo 
> project, which is all about safety with maximal hardware parallelism, 
> might get to the promised land you seek (even that's not clear yet).

A good start is defining terms.  What do we mean by "multi-threaded DOM access"?

If we mean "concurrent access to the same DOM objects from both a window and a 
worker, or multiple workers", then I think that's a no-go in Servo as well, and 
not worth trying to design for: it would introduce a lot of spec and 
implementation complexity that I don't think is warranted by the use cases I've 
seen.

If we mean the much more modest "have a DOM implementation available in 
workers" then that might be viable.  Even _that_ is pretty hard to do in Gecko, 
at least, because there is various global state (caches of various sorts) that 
the DOM uses that would need to either move into TLS or become threadsafe in 
some form or something...  Again, various specs (mostly DOM and HTML) would 
need to be gone over very carefully to make sure they're not making assumptions 
about the availability of such global shared state.

> We should add lighter-weight workers and immutable data structures

I should note that even some things that could be immutable might involved a 
shared cache in current implementations (e.g. to speed up sequential indexed 
access into a child list implemented as a linked list)...  Obviously that sort 
of thing can be changed, but your bigger point that there is a lot of risk to 
doing that in existing implementations remains.

-Boris

[DOM3Events/UIEvents] Minutes from 10 Feb 2015 teleconference

[Travis Leithead]

Contents

  *   Topics
 *   Bug 27991
 *   Bug 27990
  *   Summary of Action 
Items



masayuki: Hi!

 Scribe: Travis

 ScribeNick: Travis

Any topics for today?

 I'm trouble in bug 27991 and bug 27990

 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27991

 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27990

We can look at those.

Any other topics?

I've been working on a fix for 26019 :-)

Should have it checked in tomorrow.

 Travis: Sounds great!

Gary is getting his head in the game.

(Still sore at the recent Seahawks loss, I'm sure.)

 Ah, I have a news. Gecko will support .code in release build 
starting 38.

 Yay!

Great!

 I realize that I need to update the specs for the rename -> UIEvents 
and then ping "the powers that be" to have them redirect the short URLs as 
appropriate

 (38 will ship May, 2015)

 We're working on getting 'code' exposed as well. I don't recall the 
release schedule, though.

OK.

Gary and I have some updates to finish from last telco which we should be able 
to do this week.

Let's take a look at those bugs masayuki reference earlier.
Bug 27991

 For 27991

 I *think* that Numpad makes more sense (because of the arrangement of 
the keys)

 But NumLock is not present, so I don't think that hacking NumLock to 
be true makes sense

 Okay, so, if they input [0-9], NumLock should be hacked, otherwise, 
shouldn't be hacked?

 For 27990, my initial thought is NumpadAsterisk and NumpadHash

 masayuki: I don't think we should set NumLock at all for these keys.

I commented in the bug--I suggested Digit for the horizontal layout.

scribe: I'd expect more common code would look for digits, rather than numpad 
keys.

 Wow, is there horizontal layout?

 The 'Digit*' keys are the one that have punct in their shifted state 
(US layout). They do not produce digits for some other layouts (like French), 
so the Digit codes don't seem appropriate for the phone numpad keys.

 masayuki: horizontal as opposed to in a 2d grid

 masayuki: 1d (horizontal row) vs. 2d (3x4 grid)

 garykac: Thanks, I've never seen 1d in Japan.

 I still have no idea which is better... (Numpad* vs. Digit*)

 I'm adding a comment to the bug.

 I don't think that Digit is appropriate for Phone keypads.

I think it's mostly arbitrary, but we should recommend one or the other. Digit 
works for me.

scribe: but I could go with either.
... but not both :-)

If we do Numpad*, then bug 27990 is easier to resolve.

scribe: code of Digit3 doesn't conflict with code of NumpadHash
... or we could have the numbers be Numpad*, and just reuse Digit3 for the code 
of #.

 I think there are two scenarios one is some developers use scancode 
which is used by PC keyboard, the other is some developers use scancode which 
is NOT used by PC keyboard.

 masayuki: Phone keypads in the US have '#' and '*', but is that 
universal?

 For the former, Digit3 and Digit8 may make sense. For the latter, 
NumpadHash and NumpadAsterisk may be good values.

 gacykac: I'm not sure, but Japanese phones have them and in some 
countries, they are.

 
https://www.google.co.jp/search?q=phone%201d%20layout&oe=utf-8&gws_rd=cr&um=1&ie=UTF-8&hl=ja&tbm=isch&source=og&sa=N&tab=wi&ei=Wq_aVJHJM5fz8gXAwIHgAg#um=1&hl=ja&tbm=isch&q=featurephone+buttons&imgdii=_
Bug 27990

 I think that NumpadAsterisk and Hash make the most sense for phones 
in all cases. If you hook up your phone to a PC, I would still expect to see 
the Numpad values.

 Digit3 and Digit8 just happen to match (shifted) the # and *, but 
that's only for the US locale and that seems very arbitrary.

 garykac: yeah, but there might be no unused scancode.

 masayuki: thanks for the link. The '#' and '*' keys seem pretty 
universal.

 masayuki: unused scancode? why does that matter?

 garykac: If so, vendors might map scancode which are used by PC 
keyboard. Then, browsers cannot distinguish the key event comes from the keys 
on feature phone or connected PC keyboard.

 Ah, but it could be solved with virtual keycode values if the 
platform has specific keycode values for them.

 Anyway, I'd like you to add featurephone section into D3E 
KeyboardEvent code spec.

 masayuki: we could expand the "Numpad" section to include a feature 
phone keypad. Since the other keypad values are there, it seems like a good 
place for that info to live.

 masayuki: File a bug for me to add a section for that.

 garykac: Okay!

 That's probably about it for today...

Anything else to go over?

 Nothing.

 See you all in two weeks.

Awesome. Two weeks!

 I hope to have the renaming in place by then.

 And the phone keys shouldn't take long to add.

 Bye!

 Thanks!

[DOM3Events/UIEvents] Minutes from 27 Jan 2015 teleconference

[Travis Leithead]

Minutes logged at: http://www.w3.org/2015/01/28-webapps-minutes.html
Previous minutes: https://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings

 Travis: Hi

 garykac: Hi,

 masayuki: Hello

 Travis is having trouble with IRC. He's working on a fix right now.

 Oh, I see.

We have a few things to follow up on from last meeting.

Spec name change is one

3 bugs from Masayuki blocking Gecko progress

Removal of beforeinput and friends from the spec

 And renaming and moving the spec.

 Oops! I see that was already mentioned

Spec name change

garykac: Not done yet.
... will do next.
... hesitated since there are redirects to old one, etc.
... renaming and moving to new URL?
... can't remember the details.
... Are we going to move it to D4E?
... [and other questions]

So, latest TR published is here: http://www.w3.org/TR/DOM-Level-3-Events/

So, the shortname is "DOM-Level-3-Events"

Editor's draft is here:  
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html

So, under HG's "dom3events" folder.

 Basically, we need to agree on the exact order that we do things in.

One thing we should do is re-publish the current spec with a re-direct to it's 
new home

So, unordered list first :)

* Modifiy Editor's draft to change name

* Copy editor's draft new location

 * Decide where the editor's draft should live: the current D3E, 
current UIE, or a new place

* Change current published doc's "editor's draft" link to point to new location.

* Publish new draft in TR with new name and valid links

* Update bug database component name?

 I'm going to dig up the email where this was last discussed to remind 
myself what it says...

 Philip suggested publishing an updated version (new name) and having 
*both* shortnames point to it.

OK, well, first step is probably "modify editor's draft" so that we can do that 
:-)

As for location, where do we put the editor's draft?

 We need to make sure that both ED links point to the correct editor's 
draft

 I think it makes sense to keep using the dom3events location

I don't mind the mercurial path staying D3E (vesus a new location or D4E)

 OK. so that means that we rename dom3events in-place

So, scrap the "Copy editor's draft to new location"

garykac: New shortname?
... nope, it'll be UIEvents

Do you want to change the name of the file in mercurial?

 I don't think it's necessary, but we can do that later if we need to.

garykac: I would avoid doing that now--we can always do it later.

beforeinput removal

 Next topic

 I removed beforeinput and input from the spec.

 But we still have a few links that need to be updated

 But I don't have a real spec to link them to.

 This makes me sad

 I'm waiting until we have a real link before fixing them - I'm 
assuming that we can get the links soon.

 Ben's unofficial spec is at: 
http://w3c.github.io/editing-explainer/input-events.html

http://w3c.github.io/selection-api/

 Where the input spec go to? .isComposing is important and useful. 
So, it should be defined by somebody.

Oh, I don't think my link was right...

 Oh, I see, bad timing...

 The link I sent is an "unofficial draft", so I'd like to see a more 
semi-official draft before fixing up all the links.

 masayuki: isComposing is part of the input spec

 They took their initial draft from the work we did

 garykac: Yeah, thanks, I confirmed.

3 bugs for masayuki

(a new children's story)

j/k

bug 24739, 26019 and 26218

 I updated bug 26218 now.

scribe: [familiarizing ourselves with the bugs again]

 Our Linux's module owner, karlt, doesn't like adding "Super" and 
"Hyper" to the modifier key, but I like them.

 So, for 24739

 Which keys are missing to support the Sun keyboard?

 Props is there...

 garykac: its label is "Props".

 USB keycode indicates "Menu".

 vs. ContextMenu

 So, do we need Menu and ContextMenu (with Props mapping to Menu)?

 But it's different from "ContextMenu" and Sun's keyboard also has 
"ContextMenu" key. Therefore, we should provide different name for "Props".

 It will provide a way to distinguish the keys.

 Sun has ContextMenu and Props. But if Props -> Menu, isn't that 
sufficient.

 I guess "Props" is a good name? "Menu" sounds like not good.

 This assumes that we add Menu (in a way that clearly distinguishes it 
from ContextMenu)

 masayuki: Yeah. "Menu" sounds to generic and will be probably be 
mis-used.

 ContextMenu and Props are what we currently have in the spec.

 garykac: Yeah, it must be mis-used.

 Oh, you added "Props" already?

  
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html#code-Props

 So, it sounds like the current spec has the definitions is needs? Is 
there anything else that has to happen for this bug?

 garykac: just close it ;-)

 masayuki: yes, 'props' is in the legacy section and has a bunch of 
other Sun keys

 Yay!

On to bug 26019

 OK, 26019... (reading bug)

 I also filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27902 
and https://www.w3.org/Bugs/Public/s

[D3E/UIEvents] Transferring related Bugzilla bugs to github issues

[Travis Leithead]

Hi Ben/Gary,

Per the discussion in our recent telecon, here is a list of the bugs currently 
active in the DOM3 Events component on bugzilla, that you should consider 
migrating into your github issue tracking system:

26612

WebAppsW

DOM3 Eve

travil

NEW

---

D3E defines input event should be fired immediately after the DOM as been 
updated but it shouldn't be so if the editor value is changed by setting value 
attribute 

27063

WebAppsW

DOM3 Eve

travil

NEW

---

Add "intention" integration point to 'beforeinput' event's interface 


23913

WebAppsW

DOM3 Eve

travil

ASSI

---

beforeinput should be fired only when the DOM change is caused by direct input 
by keypress or composition 


25683

WebAppsW

DOM3 Eve

travil

ASSI

---

Document "unsafe to dispatch events" in D3E if it's possible 



To confirm the transfer, please leave a comment in each bug with a link to 
where interested parties can continue to follow the fate of the bug in the 
newly created github issue. This traceability is the important part. Thanks!

RE: Help with WebIDL v1?

[Travis Leithead]

> From: Sam Ruby [mailto:ru...@intertwingly.net]
> 
> Another way to phrase this question: what would the CR exit criteria be for
> such a WebIDL v1?  The reason why I bring this up is that if they are too low
> to be meaningful, that brings into the question whether or not this exercise
> is meaningful.  Similarly, if they are too high to be likely to be met.

I think just having the syntax in v1 does not make progressing v1 a useful 
indeavor. My understanding of how V1 was being maintained up-to-date was that 
updates to the binding that were shared across common syntax in both v1 and v2 
were being back-ported to v1 so that there were no inconsistencies in binding. 
In other words, if you were looking at v1, you'd see the latest algorithms and 
bindings, but for areas of v2 that were wholly new concepts, those would not 
exist in v1. 

Based on what Boris has said, I'm guessing that this practice has been 
discontinued :(

I don't think we need to have a requirement of maintaining an "ES5-level" goal 
for v1. Large parts of ES6 are now shipping in various browsers, so we really 
have no reason to keep an ES5-based spec in development.

Coming back to CR exit criteria, I think we need to hold v1 to the same 
standard we're holding v2, which means [at least] porting back the updated 
algorithms for handling sequences, named properties, indexed properties, etc. 
which have diverged.

I suspect that there are still some shared areas of v2 and v1 that are not yet 
locked down yet, and we should focus our collective efforts on stabilizing 
those features before working on v2-only syntax features.

> If, on the other hand, there is a "sweet spot" some place in the middle; then
> perhaps this effort should proceed.

I'm not sure what a middle-ground would look like--perhaps a less-strenuous 
test suite? E.g., HTML's "passive-permissive" testing approach?

> By analogy, the parsing of http: absolute URLs is solid and unlikely to 
> change,
> but determining the origin of file: URLs isn't.  Clearly identifying what 
> parts
> are widely deployed and unlikely to change vs those that aren't may be a
> path forward.

And I think that v1 should be that slice of "widely deployed" and unlikely to 
change features. If that means pulling out sequence from v1, then perhaps 
that's another approach.

I'm of the view that we should publish something soon to enable the stable 
reference for a variety of specs. Publishing is a process that helps focus and 
direct our efforts, and even if it's not perfect, it becomes a building block 
for future updates. We've let WebIDL just "hang-out" for too long now, and 
folks new to the area don't know what's more stable and what isn't.

Again, publishing WebIDL is important to Microsoft, and we believe important to 
a lot of other customers. Consequently I'm ready to put pen to paper to make 
this happen if we can agree on a direction. Ideally, this effort doesn't 
distract too much from active work on v2.

> - Sam Ruby

RE: Help with WebIDL v1?

[Travis Leithead]

I believe so; this will give many specs a baseline WebIDL document to point to 
in their references at the very least. Many specs don't rely on the more 
advanced feature set being defined in WebIDL Second Edition.

However, let's not hijack this thread; I'd love to hear what the next steps are 
for moving this v1 forward. If there are bug fixes and improvements that need 
to go back to v1, than I'm volunteering to help get that work done.

-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] 
Sent: Monday, December 1, 2014 1:36 PM
To: Travis Leithead
Cc: Yves Lafon; Adrian Bateman; public-webapps
Subject: Re: Help with WebIDL v1?

On Mon, Dec 1, 2014 at 12:57 PM, Travis Leithead
 wrote:
> At TPAC, I mentioned wanting to help move along WebIDL v1 to REC. Can you
> enumerate the next steps, and where I might be able to help? Thanks!

Is there any actual value in doing this, since v2 has many additions,
improvements, and bug fixes over the contents of v1?

~TJ

Help with WebIDL v1?

[Travis Leithead]

Yves,

At TPAC, I mentioned wanting to help move along WebIDL v1 to REC. Can you 
enumerate the next steps, and where I might be able to help? Thanks!

-Travis

RE: CfC: publish WG Note of UI Events; deadline November 14

[Travis Leithead]

To clarify: are you asking to rename "DOM Level 3 Events" to "UI Events"? 

Perhaps a fresh name would help get that spec done faster :)

Gary what do you think?

-Original Message-
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of 
Anne van Kesteren
Sent: Friday, November 7, 2014 7:36 AM
To: Arthur Barstow
Cc: public-webapps; www-...@w3.org
Subject: Re: CfC: publish WG Note of UI Events; deadline November 14

On Fri, Nov 7, 2014 at 4:28 PM, Arthur Barstow  wrote:
> If anyone has comments or concerns about this CfC, please reply by 
> November
> 14 at the latest.

My concern is that we previously agreed that UI Events would be a much more 
suitable name for the contents of DOM Level 3 Events. But we would keep using 
DOM Level 3 Events because it would be done quickly and then we'd move on to UI 
Events. As we now know we did not finish DOM Level 3 Events quickly. So I would 
like us to abandon that name and settle on UI Events.


--
https://annevankesteren.nl/

RE: [minutes] 2014-Oct-28 f2f meeting in Santa Clara, CA

[Travis Leithead]

For folks involved in the URL discussion; please review my scribed notes to 
make sure they are accurate--I had someone point out that I may have swapped a 
"W3C" for a "WHATWG" (or vice-versa) a couple of times which was accidental. 
Thanks!

-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com] 
Sent: Wednesday, October 29, 2014 7:15 AM
To: public-webapps
Subject: [minutes] 2014-Oct-28 f2f meeting in Santa Clara, CA

The minutes from the October 27 f2f meeting are at the following and 
copied below:



If anyone wants any major corrections, please speak up.

Thanks to all the Scribes: Josh, Chaals, Travis and anyone else that 
helped.

-Thanks, AB

W3C 


  - DRAFT -


  WebApps WG F2F


28 Oct 2014

Agenda 


See also:IRC log 


Attendees

Present
Brian_Raymor, Art_Barstow, Josh_Soref, chaals, Yves_Lafon,
Ben_Peters, Xiaoqian_Wu, Adrian_Bateman, Ali_Alabbas, Mohammed,
Dadas, Sam_Weinig, Hiroyuki_Aizu, Shijun_Sun, Sakari_Poussa,
Alan_Iida, dom, Kenneth_Christiansen, Jonas_Sicking, Olli_Pettay,
Laszlo_Gombos, Israel_Hilerio, Wooglae_Kim, Claes_Nilsson, igarashi,
Anssi_Kostiainen, Jungkee_Song, Robin_Berjon, Benjamin_Poulain,
Bryan_Sullivan, Dan_Appelquist, Ted_Oconnor, Joerg_Heuer,
Marcos_Caceres, Mounir_Lamouri, Sam_Ruby, Stephan_Steglich,
Travis_Leithead, Kevin_Hill, miterho, Mikko, Terho, Huawei,
Mark_Nottingham, Larry_Masinter, Peter_Linss, Phillipe_LeHegaret,
Paul_Cotton, Mike_Smith, Alex_Russel, James_Craig, Michael_Cooper,
Richard_Schwerdtfeger, Katie_Haritos-Shea, Janina_Sajka,
Norbert_Lindenberg
Regrets
Chair
ArtB, chaals
Scribe
timeless, Travis, Travis_


Contents

  * Topics 
 1. Introductions

 2. Agenda 
 3. Screen Orientation

 4. Manifest 
 5. Permissions API

 6. SysApps specifications

 7. URL 
 8. Editing 
 9. Intentions

10. Editing 
11. Next Meeting

  * Summary of Action Items




 scribe: timeless

 ScribeNick: timeless


  Introductions

chaals:good morning
... We'll wait until 9:30 until we start our first item
... as we traditionally do, we'll go around the room asking people to 
introduce themselves
... I'm chaals, from Yandex, co-chair of this group

ArtB:Arthur, I work for Nokia
... i'm also one of the chairs

Josh_Soref:Josh Soref, BlackBerry, Scribe, Observer

spoussa:Sakari Poussa, Intel

kenneth_:Kenneth Christiansen, Intel

weinig:Sam Weinig, Apple

 'ello

benjamp:Ben Peters, Microsoft

sicking:Jonas Sicking, Mozilla

ShijunS:Shijun Sun, Microsoft

alan-i:Ali, Microsoft

xiaoqian:Xiao, W3 Team Contact

Yves:Yves, W3C

a12u:XXX,

 jcdufourd: Jean-Claude Dufourd, Institut Mines Telecom, observer

 Louay Bassbouss

StephanSteglcih:Stephan Steglich, Fraunhofer Fokus, observer

 Dong-Young Lee (LG)

youngwoojo:youngwoojo, LGE, Observer

 bryan: Bryan Sullivan

Bill Hsiung, MSTAR Semiconductor,

 s/alia: Alan/alia: Ali

richt:Rich Tibbet, Opera

shoko:Shoko Okuma, Tomo-Digi Corporation, Observer

ZZZ

AAA

BBB

CCC

DDD:France Telecom, Obs

EEE

 Evangelos Vlachogiannis Fraunhofer FIT, observer

FFF:Observer

GGG:Observer

HHH:LG

Mohammed Dadas Orange

 GeunHyung Kim

JJJ

KKK

LLL:Japan, Observer

 s/PPP PPZ/ Bill Hsiung, MSTAR Semiconductor

MMM:Oracle

marcosc_:Marcos Caseras, Mozilla

VVV

WWW

XXX Observer

dom:Dominique, W3C

EWQ Softbank

RFE

WQQ

POQ

LMN

Xitong Huang Tencent

 Dan Appelquist: dka, @torgo; WebApps wg member; TAG Co-Chair; URL 
fan; #FirefoxOS fanboy; also A.C. rep for Telefónica.

 Adrian Bateman, Microsoft

dka:Dan Appelquist

adrianba:Adrian, Microsoft

IQQ

DQQ

[ Scribe apologizes ]

smaug:Olli Pettay, Mozilla

lgombos:Laszlo Gombos, Samsung

 anssik: Anssi Kostiainen, Intel

 rubys: Sam Ruby, Apple


  Agenda

ArtB:we were considering talking with sysapps

marcosc_:let's get it out of the way
... what APIs can be salvaged from SysApps
... brou

RE: innerText spec

[Travis Leithead]

There was interest in the room at TPAC at making this a new unique spec 
deliverable under webapps.

Ryosuke: See also: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145

-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com] 
Sent: Tuesday, September 16, 2014 7:28 PM
To: Ms2ger; Simon Pieters
Cc: Webapps WG; Ian Hickson
Subject: innerText spec

Hi,

Is either one of you working on innerText specification?
(http://lists.w3.org/Archives/Public/www-archive/2014Mar/0008.html)

I think we need it for the selection API specification because the concept of 
being "visually equivalent" and selection.toString need to be defined in terms 
of it.

- R. Niwa

RE: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note

[Travis Leithead]

>From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf 
>Of Anne van Kesteren
>On Mon, Oct 27, 2014 at 8:06 PM, Travis Leithead 
> wrote:
>> We should have a plan for the bugzilla component (there are some good 
>> "future" bugs logged there). Would the bugzilla component stay open? Would 
>> >> we need to move the bugs to D3E otherwise? (We can mark them future, or 
>> something to distinguish them.)
>
>What's the context for this new plan?

Sorry, this came out of comments from Marcos and others that having UI Events 
on WebApps's PubStatus (and in Google Search results) along with DOM Level 3 
Events was confusing--e.g., which is the spec to be looking at? It turns out 
that the current UI Events spec has very little in it at the moment (we've 
back-ported most of its content into DOM Level 3 Events), and is now understood 
to be a home for future "UI Events" features (after wrapping up DOM Level 3 
Events). So, the suggestion was that we officially stop working on UI Events 
(as a current deliverable) and potentially re-start it later when we're ready. 
This should alleviate the confusion. This lead to my questions above.

>What draft is going to define event constructors? 

DOM Level 3 Events (already done)

>When are we going to see the hit testing part of mouse events 
>defined? What draft will integrate with the event loop model and 
>deal with relative ordering of the events and which happen as part 
>of the same task and which as part of a distinct task, etc?

Scheduled for inclusion in DOM Level 3 Events (Bug 25927)

...and other bugs yet to be fixed.

RE: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note

[Travis Leithead]

We should have a plan for the bugzilla component (there are some good "future" 
bugs logged there). Would the bugzilla component stay open? Would we need to 
move the bugs to D3E otherwise? (We can mark them future, or something to 
distinguish them.)

-Original Message-
From: Web Applications Working Group Issue Tracker 
[mailto:sysbot+trac...@w3.org] 
Sent: Monday, October 27, 2014 9:26 AM
To: public-webapps@w3.org
Subject: WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg 
note

WebApps-ACTION-734: Start cfc to publish ui events as a "gutted" wg note

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

Assigned to: Arthur Barstow

RE: [DOM-Level-3-Events] Synthetic mouse events triggering default action

[Travis Leithead]

-Original Message-
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of 
Anne van Kesteren
> On Wed, Oct 15, 2014 at 2:40 AM, Bogdan Brinza  wrote:
>> http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events
>
>That text is utterly broken as we've discussed several times now.

Yeah, I've got a bug to fix that. Will probably refactor to match basically 
what Sicking wrote in 12230.

>Events do not cause action. Actions cause events (that can then prevent 
>further action). There is one issue here with some implementations around a 
>limited set >of events, discussed to great length in this bug:
>https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230

It looks like that bug is trending in the right direction. We have additional 
data to drop into that bug now to help Rick and others identify additional 
behaviors and sites that depend on them.

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

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]

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

[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=---

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?)

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/

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

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] 

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: 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/

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]

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: 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: 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]

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

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

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: [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>

[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: 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

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: [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: 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: 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?

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

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]"?