Re: Element.matchesSelector vs. Element. matches

On 3/20/12 10:38 PM, Bronislav Klučka wrote: Hello, Why there are 2 similar functionalities for selector matching? Because you're reading two versions of the same spec and the spec changed sometime between those versions. http://dev.w3.org/2006/webapi/selectors-api2/#matches boolean match

Element.matchesSelector vs. Element. matches

Hello, Why there are 2 similar functionalities for selector matching? http://dev.w3.org/2006/webapi/selectors-api2/#matches boolean matches(DOMString selectors, optional (Element or sequence)? refNodes); http://www.w3.org/TR/selectors-api2/#matchtesting boolean matchesSelector(in DOMStrin

[Bug 16461] New: what this is importent to me?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16461 Summary: what this is importent to me? Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other

[Bug 8406] Stricter Specifications on Mouse Events Specifically primary, auxillary, and secondary default actions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=8406 Travis Leithead [MSFT] changed: What|Removed |Added Keywords||needsReview Status

Re: [IndexedDB] onsuccess isn’t the best for writes

"Create a transaction" step 4 says "create a transaction", whcih is recursive. The bolded phrase "create a transaction" is never used. It looks like this is out of sync: the phrase actually used is "steps for creating a transaction". They should match exactly, to allow searching. On Mon, Mar 19

Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

On Tue, Mar 20, 2012 at 1:03 PM, Gordon Williams wrote: > ** > I totally understand about the need to deter people from using the UI > thread, however it seems that while synchronous XHR exists at all, > deliberately removing features in some cases just makes developers lives > more difficult - a

Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

On Tue, Mar 20, 2012 at 11:03 AM, Gordon Williams wrote: > Thanks for the suggestions... > > Just so I'm certain: The #3 option is to run in a Worker, and then to put > all WebGL calls in an array, and then use the UI thread to check that array > and execute calls based on its contents? > > There

Re: Where should UA insert text when the focus is changed in a keypress event handler?

On 3/20/12 2:58 PM, Ojan Vafai wrote: With my web developer hat on, I would expect the WebKit/IE behavior. Keypress is fired before the DOM is modified (I tested in Gecko and WebKit on an input element). As such, I'd expect focus changed during a keypress event to change where the text is inserte

Re: Where should UA insert text when the focus is changed in a keypress event handler?

With my web developer hat on, I would expect the WebKit/IE behavior. Keypress is fired before the DOM is modified (I tested in Gecko and WebKit on an input element). As such, I'd expect focus changed during a keypress event to change where the text is inserted. Notably, Gecko does the WebKit/IE beh

Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

I think we should try to get rid of sync XHR in window context. It takes time, and can be painful, but sync APIs in window context are just not acceptable. -Olli On 03/20/2012 08:03 PM, Gordon Williams wrote: Thanks for the suggestions... Just so I'm certain: The #3 option is to run in a Work

Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

Thanks for the suggestions... Just so I'm certain: The #3 option is to run in a Worker, and then to put all WebGL calls in an array, and then use the UI thread to check that array and execute calls based on its contents? There is a small amount of state querying of WebGL going on, so that's

Where should UA insert text when the focus is changed in a keypress event handler?

Hi, We're trying to figure out inside which element the editing operation must be done when a keypress event handler changes the focused element / selection for https://bugs.webkit.org/show_bug.cgi?id=81661. Should it be done at wherever focus is after keypress event is dispatched? Or whatever ke

Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

On Tue, Mar 20, 2012 at 12:09 PM, Gordon Williams wrote: > Hi, > > I recently posted on > https://bugs.webkit.org/show_**bug.cgi?id=72154 > https://bugzilla.mozilla.org/**show_bug.cgi?id=716765 > a

Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

On Tue, Mar 20, 2012 at 9:09 AM, Gordon Williams wrote: > Hi, > > I recently posted on > https://bugs.webkit.org/show_bug.cgi?id=72154 > https://bugzilla.mozilla.org/show_bug.cgi?id=716765 > about the change to XHR which now appears to be working its way into > Mainstream users' browsers. > > As r

Re: [webcomponents] Progress Update

Derp! Apologies for sending a dead link. Here's the link to the first draft: http://dvcs.w3.org/hg/webcomponents/raw-file/c387b50a991a/spec/templates/index.html I also left an unfinished sentence in the status update. Awesome work, Dimitri. The sentence should read: "Even though it may not be p

Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

On 03/20/2012 06:09 PM, Gordon Williams wrote: Hi, I recently posted on https://bugs.webkit.org/show_bug.cgi?id=72154 https://bugzilla.mozilla.org/show_bug.cgi?id=716765 about the change to XHR which now appears to be working its way into Mainstream users' browsers. As requested, I'll pursue o

Recent Sync XHR changes and impact on automatically translated JavaScript code

Hi, I recently posted on https://bugs.webkit.org/show_bug.cgi?id=72154 https://bugzilla.mozilla.org/show_bug.cgi?id=716765 about the change to XHR which now appears to be working its way into Mainstream users' browsers. As requested, I'll pursue on this list - apologies for the earlier bug spa

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

Le lundi 19 mars 2012 à 06:58 -0400, Arthur Barstow a écrit : > Cameron has addressed the comments from Web IDL LC#3 [1] and the bug > list only contains two enhancement requests [2]. As such, this is a call > for consensus to publish a Candidate Recommendation of Web IDL using the > following E

[Bug 16451] New: Clarify the order of the documents

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16451 Summary: Clarify the order of the documents Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2

[Bug 16449] New: requestFullScreen() terminates at the wrong place

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16449 Summary: requestFullScreen() terminates at the wrong place Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Prior

Re: [webcomponents] Progress Update

Sure... Note that tip is in the "wrong" link I sent too, it's just pointing to the wrong doc :) I was just noting that I got it from the "latest version of this doc" link in that revision which is (currently) actually pointing to the tip of shadow, not templates. On Tue, Mar 20, 2012 at 10:14 AM,

Re: [webcomponents] Progress Update

On Tue, Mar 20, 2012 at 10:11 AM, Brian Kardell wrote: > Whoops... that does not appear to be the same file. Appears that the > repo points to > > > http://dvcs.w3.org/hg/webcomponents/raw-file/c2f82425ba8d/spec/templates/index.html > > FYI "tip" will point to the latest revision: http://dvcs.w3

Re: [webcomponents] Progress Update

Whoops... that does not appear to be the same file. Appears that the repo points to http://dvcs.w3.org/hg/webcomponents/raw-file/c2f82425ba8d/spec/templates/index.html However in that doc listed as the latest editors draft is the one for shadow I included below. ?? On Tue, Mar 20, 2012 at 10:0

Re: [webcomponents] Progress Update

on: http://dvcs.w3.org/hg/webcomponents/raw-file/spec/templates/index.html as listed below, it returns "error: revision not found: spec". I think it should be: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html On Mon, Mar 19, 2012 at 3:42 PM, Dimitri Glazkov wrote: > Hel

Re: Call for Review: Web Audio API

An HTML5 version of Quake has already been created.  <- this point to a 1st april joke on techcrunch. maybe you meant http://media.tojicode.com/q3bsp/ demo ? On Mon, Mar 19, 2012 at 7:49 PM, Doug Schepers wrote: > > Hi, folks- > > The Audio Working Group published an updated Working Draft of Web