Re: ACTION-669: Work with PLH on an announcement seeking IRC fragments (Web Applications Working Group)

2012-11-01 Thread Arthur Barstow
FYI -the title of this action is not correct - this action is about me working with Travis and Philippe to get Web IDL fragments to test Web IDL specper the Web IDL CR's exit criteria #exit. (This action has _nothing_ to do with IRC fragments [what ever that is ;-)].) -Thanks, AB #exit

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2012-11-01 Thread Maciej Stachowiak
On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@google.com wrote: Hi folks! While you are all having good TPAC fun, I thought I would bring this bug to your attention: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562 There's been several comments from developers about the

RE: [Clipboard API] The before* events

2012-11-01 Thread Travis Leithead
I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected.. I'm not sure that the use case that these events were originally designed for (which have been obscured by time), are at all relevant to site

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2012-11-01 Thread Tab Atkins Jr.
On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@google.com wrote: Hi folks! While you are all having good TPAC fun, I thought I would bring this bug to your attention:

Re: Event.key complaints?

2012-11-01 Thread Hallvord R. M. Steen
Travis wrote: Hallvord, sorry I missed your IRC comment in today's meeting, related to DOM3 Events: ** ** hallvord_ event.key is still a problem child, authors trying to use it have been complaining both to me and on the mailing list ** ** Could you point me to the

Re: [webcomponents] More backward-compatible templates

2012-11-01 Thread Maciej Stachowiak
On Nov 1, 2012, at 1:57 PM, Adam Barth w...@adambarth.com wrote: (5) The nested template fragment parser operates like the template fragment parser, but with the following additional difference: (a) When a close tag named +script is encountered which does not match any currently

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2012-11-01 Thread Maciej Stachowiak
On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@google.com wrote: Hi folks! While you are all having good TPAC fun, I thought I would bring

Re: [webcomponents] More backward-compatible templates

2012-11-01 Thread Adam Barth
On Thu, Nov 1, 2012 at 6:33 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 1:57 PM, Adam Barth w...@adambarth.com wrote: (5) The nested template fragment parser operates like the template fragment parser, but with the following additional difference: (a) When a close

RE: Event.key complaints?

2012-11-01 Thread Travis Leithead
This is great feedback, which will need to be addressed one-way or another before we finish DOM 3 Events. Are there any other implementations of key/char other than IE9 10? (And Opera's Alpha-channel implementation). I did a quick check in the latest Firefox/Chrome stable branches and

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2012-11-01 Thread Boris Zbarsky
On 11/1/12 7:41 AM, Tab Atkins Jr. wrote: There was no good *reason* to be private by default Yes, there was. It makes it much simpler to author non-buggy components. Most component authors don't really contemplate how their code will behave if someone violates the invariants they're

Re: FW: Draft Minutes: 29 October 2012

2012-11-01 Thread Arthur Barstow
On 10/29/12 8:15 PM, ext Travis Leithead wrote: To clear up and potential confusion about IE's Shared Worker implementation status, I'd like to change this: Travis: we don't support shared workers in any form ... with the possible exception of automatic GC to: Travis: we don't support

Re: [Clipboard API] The before* events

2012-11-01 Thread Ojan Vafai
On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead travis.leith...@microsoft.com wrote: I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected.. ** ** I’m not sure that the use case that these

Re: [webcomponents] More backward-compatible templates

2012-11-01 Thread Jonas Sicking
On Thu, Nov 1, 2012 at 3:14 PM, Adam Barth w...@adambarth.com wrote: On Thu, Nov 1, 2012 at 6:33 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 1:57 PM, Adam Barth w...@adambarth.com wrote: (5) The nested template fragment parser operates like the template fragment

Re: WebApps' File: Writer File: DS specs and SysApps' File System and Media Storage specs

2012-11-01 Thread Adam Barth
On Thu, Nov 1, 2012 at 9:31 AM, Arthur Barstow art.bars...@nokia.com wrote: [ My apologies in advance for cross-posting but I'd like feedback from both the WebApps and SysApps communities ... ] Hi Eric, Adam, WonSuk, All, During WebApps' Oct 29 discussion about the File: Writer (#Writer) and

WebApps' File: Writer File: DS specs and SysApps' File System and Media Storage specs

2012-11-01 Thread Arthur Barstow
[ My apologies in advance for cross-posting but I'd like feedback from both the WebApps and SysApps communities ... ] Hi Eric, Adam, WonSuk, All, During WebApps' Oct 29 discussion about the File: Writer (#Writer) and File: Directories and System (#DS) specs (#Mins), someone mentioned SysApps

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2012-11-01 Thread Tab Atkins Jr.
On Thu, Nov 1, 2012 at 2:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@google.com wrote: Hi

RE: [Clipboard API] The before* events

2012-11-01 Thread Travis Leithead
You are right, that it doesn't solve the disabling the option in the browser chrome case-but is that really necessary? Why would a site want to do this? The only reason I can imagine is the old we want to prevent the casual user from copying this image because it is copyrighted scenario. In the

Re: [Clipboard API] The before* events

2012-11-01 Thread Ojan Vafai
I agree that this use case is not very important and possibly one we shouldn't bother trying to solve. Hallvord's initial point, I think is that there's really no use case for the before* events. We should kill them. *If* we want to meet the use case those events purported to meet (not displaying

Re: Event.key complaints?

2012-11-01 Thread Ojan Vafai
WebKit does not implement key/char, but does support keyIdentifier from an older version of the DOM 3 Events spec. It doesn't match the current key property in a number of ways (e.g. it has unicode values like U+0059), but I do think it suffers from some of the same issues Hallvord mentioned. On

Re: Event.key complaints?

2012-11-01 Thread Joshua Bell
On Thu, Nov 1, 2012 at 11:58 AM, Ojan Vafai o...@chromium.org wrote: WebKit does not implement key/char, but does support keyIdentifier from an older version of the DOM 3 Events spec. It doesn't match the current key property in a number of ways (e.g. it has unicode values like U+0059), but

Re: [Clipboard API] The before* events

2012-11-01 Thread Hallvord Reiar Michaelsen Steen
Den 1. nov. 2012 kl. 19:38 skrev Ojan Vafai o...@chromium.org: I agree that this use case is not very important and possibly one we shouldn't bother trying to solve. Hallvord's initial point, I think is that there's really no use case for the before* events. We should kill them. Makes it

Re: [Clipboard API] The before* events

2012-11-01 Thread Glenn Maynard
On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: The most IMHO elegant solution is what we implemented in Opera: we simply keep relevant menu entries enabled if there are event listeners registered for the corresponding event. This sort of goes against