Quick update on WebIDL "Level 1"

2016-07-08 Thread 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

2016-06-13 Thread 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

2016-04-26 Thread 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

2016-03-22 Thread 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?

2015-12-21 Thread 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

2015-12-02 Thread 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

2015-11-05 Thread 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...

2015-10-28 Thread 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

2015-10-23 Thread 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

2015-10-06 Thread 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

2015-09-03 Thread 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

2015-08-07 Thread 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 ann...@annevk.nl
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 art.bars...@gmail.com 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/




alternate view on constructors for custom elements

2015-07-17 Thread 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


RE: alternate view on constructors for custom elements

2015-07-17 Thread 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


[WebIDL] T[] migration

2015-07-16 Thread 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?

2015-07-15 Thread 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

2015-07-02 Thread 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%20APIlist_id=57282product=WebAppsWGresolution=---

 -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 
 travis.leith...@microsoft.com 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] [blink-dev] Removing IME API code from Blink

2015-06-18 Thread 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%20APIlist_id=57282product=WebAppsWGresolution=---

 -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 
 travis.leith...@microsoft.com 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

2015-06-18 Thread 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:
PromiseBlob toBlob();
PromiseImageData 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 
travis.leith...@microsoft.commailto: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:

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

seems sensible to add ☺

From: a...@scirra.commailto:a...@scirra.com 
[mailto:a...@scirra.commailto:a...@scirra.com] On Behalf Of Ashley Gullen
Sent: Wednesday, June 17, 2015 10:00 AM
To: public-webapps@w3.orgmailto: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: Async Image - ImageData conversion

2015-06-17 Thread Travis Leithead
I think solving at least the first-order problem of extracting data from the 
Canvas async is do-able.

Something like:

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

2015-06-08 Thread 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 rn...@apple.com
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 aboxh...@google.com wrote:



 On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote:

 On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote:

 On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote:

  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com 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 `button`, 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 `input` 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

2015-05-28 Thread 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 travis.leith...@microsoft.com 
 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

2015-05-27 Thread 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 ko...@chromium.org
To: blink-dev blink-...@chromium.org



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 http://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
https://groups.google.com/a/chromium.org/forum/#%21msg/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
mailto:blink-dev+unsubscr...@chromium.org.





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

2015-05-21 Thread 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 dglaz...@google.com 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 slot name=some-slot-name rather than content-slot=some-slot-name and 
content slot=some-slot-name.


--
https://annevankesteren.nl/


RE: Shadow DOM: state of the distribution API

2015-05-13 Thread 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=

2015-05-08 Thread 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 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 script and template are allowed pretty much 
 everywhere.
 
 Therefore, I propose that we move subclassing of builtin elements to 
 v2, remove is= from the specification, and potentially open an issue 
 on HTML parser changes.

We (Apple) support this proposal.

- R. Niwa





RE: Custom Elements: is=

2015-05-08 Thread 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:

button is=my-fancy-buttonMe/button
button is=your-fancy-buttonYou/button

-Justin

On Fri, May 8, 2015 at 12:56 PM, Travis Leithead 
travis.leith...@microsoft.commailto: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 
 ann...@annevk.nlmailto: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 script and template are allowed pretty much
 everywhere.

 Therefore, I propose that we move subclassing of builtin elements to
 v2, remove is= from the specification, and potentially open an issue
 on HTML parser changes.

We (Apple) support this proposal.

- R. Niwa





RE: [components] Isolated Imports and Foreign Custom Elements

2015-05-04 Thread 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 link 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 travis.leith...@microsoft.com 
 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 
 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

RE: [components] Isolated Imports and Foreign Custom Elements

2015-05-01 Thread 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 m...@apple.com 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

2015-04-28 Thread 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 a...@microsoft.com 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: Directory Upload Proposal

2015-04-28 Thread 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. jackalm...@gmail.com wrote:

On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon seddon.r...@gmail.com 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: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread 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 ann...@annevk.nl wrote:
 
 On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com 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 content
 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

2015-04-24 Thread 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] 

RE: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread 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 
justinfagn...@google.commailto:justinfagn...@google.com wrote:



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

 On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
 justinfagn...@google.commailto: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 content 
 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:


template

  content select=.header/content

  content select=:not(.footer)/content

  content select=.footer/content

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


template

  content slot=header/content

  content/content

  content slot=footer/content

/template
- R. Niwa



RE: [Imports] Considering imperative HTML imports?

2015-04-16 Thread 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 
travis.leith...@microsoft.com 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?

2015-04-16 Thread 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:

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

2015-04-15 Thread Travis Leithead
Was an imperative form of HTML imports already considered? E.g., the following 
springs to mind:
  PromiseDocument importDocument(DOMString url);

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


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

2015-03-26 Thread 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?

2015-03-26 Thread 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! 


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

2015-03-26 Thread 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 link rel=stylesheet

* 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: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

2015-03-26 Thread 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 art.bars...@gmail.com
To: public-webapps public-webapps@w3.org

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. http://www.w3c-test.org/webmessaging/with-ports/026.html; 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. http://www.w3c-test.org/webmessaging/without-ports/025.html; 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] 
https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html
[All] http://w3c.github.io/test-results/webmessaging/all.html
[2] http://w3c.github.io/test-results/webmessaging/less-than-2.html
[PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/
[CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/
[PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports
[Diff] https://www.diffchecker.com/qswiibb5







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

2015-03-26 Thread 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] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread 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 
travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote:
 From: Justin Fagnani 
 [mailto:justinfagn...@google.commailto: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 div 
id=foo 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] URL-based shadows?

2015-03-20 Thread 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 script src 
the platform takes measures to ensure that the imported content (the code) 
can't be easily observed if it doesn't choose to be.

It seems clear so far that we all want to enable scenarios for both same-origin 
and cross-origin components. I think we understand that cross-origin components 
will need to be more restricted. It also seems like there is agreement to want 
to align the developer experience for the same-origin and cross-origin models 
as closely as possible (rather than having two very different models).

I'd like to get a sense for what folks' thoughts are on the current 
non-URL-based creation model (createShadowRoot)? Are we OK with a non-URL-based 
creation model (as used today) being fairly different from a URL-based creation 
model? If so, then we can work on figuring this out later and/or separately 
from the current approach. If not, and we want to have non-URL and URL-based 
models behave similarly, then it seems like we are signing up to potentially 
change the current shadow DOM creation model--a breaking change for existing 
implementations.

Perhaps there's another approach I haven't considered. My preference is not to 
start over, but to work within the existing creation model framework with 
incremental changes, not major re-designs. Adding in an isolated scripting 
environment for shadow dom (of some form) is a fairly large change in my view.


From: Anne van Kesteren ann...@annevk.nl
Sent: Thursday, March 19, 2015 1:24 AM
To: Travis Leithead
Cc: Ryosuke Niwa; Dimitri Glazkov (dglaz...@google.com); WebApps WG; Arron 
Eicholz
Subject: Re: [Shadow] URL-based shadows?

On Thu, Mar 19, 2015 at 12:08 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
 5. I like this. Though it's really only necessary for the cross-origin use 
 case.

I think it's worth mentioning that the existing setup further
encourages the rather dangerous practice of including and trusting
cross-origin scripts. E.g. if you include an HTML import from
angularjs.org you are effectively surrendering all the user's
localStorage, non-protected cookies, indexed DB, etc. to that origin.
Finding ways to move away from such practices while retaining most of
the functionality has significant value.


--
https://annevankesteren.nl/



RE: [Shadow] URL-based shadows?

2015-03-20 Thread 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 input or 
 select 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?

2015-03-18 Thread 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 input or select 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 travis.leith...@microsoft.com 
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:

link rel=import href=https://webkit.org/components.html; 
defines=like-button”

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

like-button data-url=https://build.webkit.org/;Like 
build.webkit.org/like-button

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?

2015-03-18 Thread 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 script tag, or 
by way of link rel=import which pulls in same-origin or CORS-approved 
cross-origin content.

I hadn’t considered cross-domain components, which is another interesting 
use-case, I agree.

The bit of magic in this proposal that improves on the iframe experience is the 
SharedWorker-like single instance across related components.

Generally speaking, is cross-origin components something that we should be 
looking to address? The strong isolation is a good model, but very restrictive 
and not that far-different from iframes IMO. I also can’t help thinking how the 
discussion of closed vs. open component access relates to cross-origin (or not) 
components.

From: Dimitri Glazkov [mailto:dglaz...@google.com]
Sent: Monday, March 16, 2015 8:07 AM
To: Anne van Kesteren
Cc: Travis Leithead; WebApps WG; Arron Eicholz; Elliott Sprehn
Subject: Re: [Shadow] URL-based shadows?



On Mon, Mar 16, 2015 at 3:55 AM, Anne van Kesteren 
ann...@annevk.nlmailto:ann...@annevk.nl wrote:
On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov 
dglaz...@google.commailto:dglaz...@google.com wrote:
 https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1

That seems really cool. I'm not sure worker is the right terminology
since at the moment worker sort of implies there's no node tree
available due to the complexity that would give. But an isolated
global for a set of reusable components that are mixed into the
document seems roughly in line with what we have with input et al
today.

Agree.

:DG


Re: [Shadow] URL-based shadows?

2015-03-13 Thread 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 dglaz...@google.com
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 
dglaz...@google.commailto: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 
travis.leith...@microsoft.commailto: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?




RE: template namespace attribute proposal

2015-03-12 Thread 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 
bl...@netflix.commailto:bl...@netflix.com wrote:
I'd like to propose that the template 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.:

template id=my-svg-template namespace=http://www.w3.org/2000/svg
  circle cx=10 cy=10 cr=10/
/template

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

template id=tmpl
  svg
circle .../
  /svg
/template

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


[Shadow] URL-based shadows?

2015-03-12 Thread 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?


[UIEvents] telecon minutes 10 March 2015

2015-03-10 Thread Travis Leithead
plh 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...

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

garykac: specifically:

garykac Section: What information should be supplied for keyboards?

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

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

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

plh (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.)

garykac 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

2015-02-13 Thread 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

2015-02-10 Thread Travis Leithead
Contents

  *   Topicshttp://www.w3.org/2015/02/11-webapps-minutes.html#agenda
 *   Bug 27991http://www.w3.org/2015/02/11-webapps-minutes.html#item01
 *   Bug 27990http://www.w3.org/2015/02/11-webapps-minutes.html#item02
  *   Summary of Action 
Itemshttp://www.w3.org/2015/02/11-webapps-minutes.html#ActionSummary



masayuki: Hi!

scribe Scribe: Travis

scribe ScribeNick: Travis

Any topics for today?

masayuki I'm trouble in bug 27991 and bug 27990

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

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

masayuki Travis: Sounds great!

Gary is getting his head in the game.

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

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

garykac Yay!

Great!

garykac 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

masayuki (38 will ship May, 2015)

garykac 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

garykac For 27991

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

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

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

garykac For 27990, my initial thought is NumpadAsterisk and NumpadHash

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

masayuki Wow, is there horizontal layout?

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

garykac masayuki: horizontal as opposed to in a 2d grid

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

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

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

garykac I'm adding a comment to the bug.

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

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

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

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

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

masayuki 
https://www.google.co.jp/search?q=phone%201d%20layoutoe=utf-8gws_rd=crum=1ie=UTF-8hl=jatbm=ischsource=ogsa=Ntab=wiei=Wq_aVJHJM5fz8gXAwIHgAg#um=1hl=jatbm=ischq=featurephone+buttonsimgdii=_
Bug 27990

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

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

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

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

garykac masayuki: unused scancode? why does that matter?

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

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

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

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

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

masayuki garykac: Okay!

garykac That's probably about it for today...


[DOM3Events/UIEvents] Minutes from 27 Jan 2015 teleconference

2015-01-27 Thread 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

masayuki Travis: Hi

masayuki garykac: Hi,

garykac masayuki: Hello

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

masayuki 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

garykac And renaming and moving the spec.

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

garykac 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

garykac * 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?

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

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

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

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

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

garykac 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

garykac Next topic

garykac I removed beforeinput and input from the spec.

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

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

garykac This makes me sad

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

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

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

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

masayuki Oh, I see, bad timing...

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

garykac masayuki: isComposing is part of the input spec

garykac They took their initial draft from the work we did

masayuki garykac: Yeah, thanks, I confirmed.

3 bugs for masayuki

(a new children's story)

j/k

bug 24739, 26019 and 26218

masayuki I updated bug 26218 now.

scribe: [familiarizing ourselves with the bugs again]

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

garykac So, for 24739

garykac Which keys are missing to support the Sun keyboard?

garykac Props is there...

masayuki garykac: its label is Props.

masayuki USB keycode indicates Menu.

garykac vs. ContextMenu

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

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

masayuki It will provide a way to distinguish the keys.

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

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

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

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

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

masayuki garykac: Yeah, it must be mis-used.

masayuki Oh, you added Props already?

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

garykac So, it sounds like the current spec has the definitions is needs? Is 
there 

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

2015-01-20 Thread 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:

26612https://www.w3.org/Bugs/Public/show_bug.cgi?id=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 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26612

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

WebAppsW

DOM3 Eve

travil

NEW

---

Add intention integration point to 'beforeinput' event's interface 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27063

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

WebAppsW

DOM3 Eve

travil

ASSI

---

beforeinput should be fired only when the DOM change is caused by direct input 
by keypress or composition 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23913

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

WebAppsW

DOM3 Eve

travil

ASSI

---

Document unsafe to dispatch events in D3E if it's possible 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25683


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?

2014-12-03 Thread 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



Help with WebIDL v1?

2014-12-01 Thread 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: Help with WebIDL v1?

2014-12-01 Thread 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
travis.leith...@microsoft.com 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


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

2014-11-07 Thread 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 art.bars...@gmail.com 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

2014-10-29 Thread 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:

http://www.w3.org/2014/10/28-webapps-minutes.html

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 http://www.w3.org/


  - DRAFT -


  WebApps WG F2F


28 Oct 2014

Agenda 
https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Tuesday_October_28

See also:IRC log http://www.w3.org/2014/10/28-webapps-irc


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 http://www.w3.org/2014/10/28-webapps-minutes.html#agenda
 1. Introductions
http://www.w3.org/2014/10/28-webapps-minutes.html#item01
 2. Agenda http://www.w3.org/2014/10/28-webapps-minutes.html#item02
 3. Screen Orientation
http://www.w3.org/2014/10/28-webapps-minutes.html#item03
 4. Manifest http://www.w3.org/2014/10/28-webapps-minutes.html#item04
 5. Permissions API
http://www.w3.org/2014/10/28-webapps-minutes.html#item05
 6. SysApps specifications
http://www.w3.org/2014/10/28-webapps-minutes.html#item06
 7. URL http://www.w3.org/2014/10/28-webapps-minutes.html#item07
 8. Editing http://www.w3.org/2014/10/28-webapps-minutes.html#item08
 9. Intentions
http://www.w3.org/2014/10/28-webapps-minutes.html#item09
10. Editing http://www.w3.org/2014/10/28-webapps-minutes.html#item10
11. Next Meeting
http://www.w3.org/2014/10/28-webapps-minutes.html#item11
  * Summary of Action Items
http://www.w3.org/2014/10/28-webapps-minutes.html#ActionSummary



timeless scribe: timeless

ArtB 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

dka '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 jcdufourd: Jean-Claude Dufourd, Institut Mines Telecom, observer

Louay Louay Bassbouss

StephanSteglcih:Stephan Steglich, Fraunhofer Fokus, observer

Dong-Young Dong-Young Lee (LG)

youngwoojo:youngwoojo, LGE, Observer

bryan bryan: Bryan Sullivan

Bill Hsiung, MSTAR Semiconductor,

alia 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 Evangelos Vlachogiannis Fraunhofer FIT, observer

FFF:Observer

GGG:Observer

HHH:LG

Mohammed Dadas Orange

GeunHyung GeunHyung Kim

JJJ

KKK

LLL:Japan, Observer

bryan 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

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

adrianba Adrian Bateman, Microsoft

dka:Dan Appelquist

adrianba:Adrian, Microsoft

IQQ

DQQ

[ Scribe apologizes ]

smaug:Olli Pettay, Mozilla

lgombos:Laszlo Gombos, Samsung

inserted anssik: Anssi Kostiainen, Intel

inserted rubys: Sam Ruby, Apple


  Agenda

ArtB:we were considering talking with sysapps

marcosc_:let's get it out 

RE: innerText spec

2014-10-28 Thread 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

2014-10-27 Thread 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: WebApps-ACTION-734: Start cfc to publish ui events as a gutted wg note

2014-10-27 Thread 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 
travis.leith...@microsoft.com 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: [DOM-Level-3-Events] Synthetic mouse events triggering default action

2014-10-15 Thread 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 bbri...@microsoft.com 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'})))

2014-08-29 Thread 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'})))

2014-06-10 Thread 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'})))

2014-06-06 Thread 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

2014-06-04 Thread 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

2014-05-28 Thread 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.orgmailto: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 div contentEditable id='editRegion'

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 ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


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

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

Thanks!
Ben

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



RE: contentEditable=minimal

2014-05-27 Thread Travis Leithead
+Gary and Masayuki

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

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

On 27/05/2014 01:52 , Ben Peters wrote:
 From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
 Peters wrote:
 As I said I am unsure that the way in which composition events
 are described in DOM 3 Events is perfect, but that's only
 because I haven't used them in anger and they aren't supported
 much.

 My thought is that we can use CommandEvent with
 type=insertText. This would be the corollary to
 execComamnd(insertText), and the data would be the ñ that is
 about to be inserted.

 But if you only get one event you can't render the composition as
 it is carrying out.

 I believe Composition Events are very important for IME input, but we
 should fire CommandEvent with Insert text for all text input,
 including IME. Are you saying we should use Composition Events even
 for non-IME input?

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

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

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

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

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

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

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

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

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



RE: Composition events (was: contentEditable=minimal)

2014-05-27 Thread 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: [Custom Elements] attributeChanged not sufficient?

2014-04-01 Thread 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 ondrej.z...@firma.seznam.cz 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
 
 my-map lat=... lon=... zoom=... controls
 
 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 my-map 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

2014-03-28 Thread 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 
 travis.leith...@microsoft.com 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

2014-03-27 Thread 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%20Serializationlist_id=33524product=WebAppsWGresolution=---


On starting WebWorkers with blob: URLs...

2014-02-19 Thread 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?

2014-02-07 Thread 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 
ann...@annevk.nlmailto:ann...@annevk.nl wrote:
On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking jo...@sicking.cc 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 PS: Disposition of Comments Doc Prepared

2014-02-03 Thread 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

2013-12-11 Thread 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] http://www.w3.org/wiki/Webapps/Interop/WebWorkers
[Tests] http://w3c-test.org/web-platform-tests/master/workers/
[Mins] http://www.w3.org/2013/11/12-webapps-minutes.html#item08






Refactoring SharedWorkers out of Web Workers W3C spec

2013-12-10 Thread 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

2013-12-03 Thread 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 
travis.leith...@microsoft.com 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

2013-11-27 Thread 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 art.bars...@nokia.com 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

2013-11-27 Thread 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 art.bars...@nokia.com 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: publish LCWD of DOM Parsing and Serialization; deadline November 25

2013-11-26 Thread 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
 sysbot+trac...@w3.org
 Reply-To: Web Applications Working Group public-webapps@w3.org
 To:   art.bars...@nokia.com



 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

2013-11-25 Thread 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 
sysbot+trac...@w3.org
Reply-To:   Web Applications Working Group public-webapps@w3.org
To: art.bars...@nokia.com



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

2013-11-18 Thread 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:

   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 
sysbot+trac...@w3.org
Reply-To:   Web Applications Working Group public-webapps@w3.org
To: art.bars...@nokia.com



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

2013-10-22 Thread 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

2013-10-17 Thread 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: [D3E] Seeking status and plan

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

Thanks!

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

Hi Travis and Gary,

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

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

-Thanks, ArtB

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


RE: [uievents] Seeking status and plans

2013-10-03 Thread 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


[DOM3Events] telco minutes published

2013-10-01 Thread 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

2013-06-04 Thread 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?

2013-05-30 Thread 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
http://dev.w3.org/csswg/css-variables/#the-cssvariablesdeclaration-interface
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
https://gist.github.com/jorendorff/5662673, 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

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

Hey,
is there any progress on finding 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.comhttp://www.fiduswriter.com/


RE: Overlap between StreamReader and FileReader

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

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


RE: Overlap between StreamReader and FileReader

2013-05-16 Thread Travis Leithead
 From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
 On Thu, May 16, 2013 at 6:31 PM, Travis Leithead
 travis.leith...@microsoft.com wrote:
  Since we have Streams implemented to some degree, I'd love to hear
 suggestions to improve it relative to IO. Anne can you summarize 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: Proposal for a DOM L3 Events Telecon

2013-05-07 Thread 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 (Кошмарчик) 
gary...@google.com wrote:

 On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano
 masay...@d-toybox.comwrote:

 Hello, sorry for the big delay due to my business trip and holiday 
 week of Japan.

 I'm available on either schedule. When I join the telecon, how can I 
 join it? Skype or something?


 Excellent question - I'm wondering the same thing. Will this be using 
 Zakim
 (http://www.w3.org/2002/01/UsingZakim) and will we have an IRC channel 
 as well?

We can certainly ask for a zakim slot.

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

cheers

Chaals

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




WebApps DOM3 Events Wiki page

2013-05-07 Thread 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: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition?

2013-05-06 Thread Travis Leithead
Works for me!

-Original Message-
From: Cameron McCormack [mailto:c...@mcc.id.au] 
Sent: Sunday, May 05, 2013 12:39 AM
To: Travis Leithead
Cc: public-webapps
Subject: Re: [WebIDL] Bugs - which are for 1.0 and which are for Second Edition?

Travis Leithead wrote:
 There's 50 some-odd bugs under the bugzilla component for WebIDL. Many 
 of them look like simple editorial fixes that could be applied to the 
 CR draft, but others are feature requests, or issues related to new 
 features added to the Second Edition.

 Are you currently tracking which bugs are for which spec(s)?

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

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

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






RE: Proposal for a DOM L3 Events Telecon

2013-05-01 Thread Travis Leithead
I’d like to be sure we get Masayuki in our discussions as this represents at 
least a trio of implementors on the call.

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

From: Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com]
Sent: Wednesday, May 1, 2013 3:23 AM
To: Wez
Cc: Gary Kačmarčík (Кошмарчик); Travis Leithead; masay...@d-toybox.com; 
public-webapps; www-dom
Subject: Re: Proposal for a DOM L3 Events Telecon

If Masayuki-san is joining and the time is JST-friendly, I would also like to 
join,
but feel free to ignore me if not.

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

On 30 April 2013 13:46, Gary Kačmarčík (Кошмарчик) 
gary...@google.commailto:gary...@google.com wrote:
On Mon, Apr 29, 2013 at 12:59 PM, Travis Leithead 
travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote:
I’d like to propose we start a call to begin to work toward resolving the final 
bugs in the spec and for other business related to getting DOM L3 Events to CR. 
On the call we can workout what subsequent meetings we should also arrange.

Does next Tuesday (May 7th), at 11 am PST work your you?

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





--
Takayoshi Kochi


RE: publish FPWD of UI Events; deadline May 4

2013-04-29 Thread Travis Leithead
Microsoft supports this.


-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Saturday, April 27, 2013 7:31 AM
To: public-webapps
Subject: CfC: publish FPWD of UI Events; deadline May 4

As discussed during WebApps' April 25 meeting, this is a Call for Consensus to 
publish a First Public Working Draft of the UI Events spec using the following 
ED as the basis:

   https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm

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

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

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

-Thanks, AB

 Original Message 
Subject:ACTION-682: Start a CfC for FPWD of UI Events (and make sure 
it has a Bugzilla component) (Web Applications Working Group)
Date:   Thu, 25 Apr 2013 17:29:27 +
From:   ext Web Applications Working Group Issue Tracker 
sysbot+trac...@w3.org
Reply-To:   Web Applications Working Group public-webapps@w3.org
To: art.bars...@nokia.com



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

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

On: Arthur Barstow
Due: 2013-05-02

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










  1   2   >