Re: Element.matchesSelector vs. Element. matches

[Boris Zbarsky]

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 matches(DOMString selectors, optional (Element or
sequence)? refNodes);


This is the new version.


http://www.w3.org/TR/selectors-api2/#matchtesting
boolean matchesSelector(in DOMString selectors, in optional any refNodes]);


This is the old version.

-Boris

Element.matchesSelector vs. Element. matches

[Bronislav Klučka]

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 DOMString selectors, in optional any refNodes]);

is it because of different signature of second optional parameter or did
someone overlooked something?


Brona Klucka

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

[bugzilla]

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
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Workers (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/workers/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
what this is importent to me?

Posted from: 180.243.5.34
User agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko)
Chrome/17.0.963.79 Safari/535.11

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

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

[bugzilla]

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

Travis Leithead [MSFT]  changed:

   What|Removed |Added

   Keywords||needsReview
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Travis Leithead [MSFT]  2012-03-21 
00:03:20 UTC ---
I've added the notes around:
1. events that still fire during drag operations outside of the window
(mousemove/mouseup)
2. Default actions for mousedown and mouseup (in the table, and in the
individual event descriptions)

Please let me know if this is satisfactory.

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-mousedown

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

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

[Glenn Maynard]

"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, 2012 at 11:49 PM, Jonas Sicking  wrote:

> > It also seems inconsistent: the transaction is aborted if code fails
> inside
>
> onsuccess, but not if it fails almost anywhere else, which seems much more
> > likely anyway.  I don't think anything else on the platform has special
> > error handling like this; I'd recommend just removing it.
>
> What do you mean by "anywhere else"? Most transaction handling will be
> inside event handlers.
>

But inside *other* events, like onclick, not from onsuccess.  From the
beginning of this thread, it sounds like listening for onsuccess may even
be uncommon, and probably more often used for non-database things, like
updating a progress bar (where aborting the transaction doesn't make sense).

In the common case, you have to handle errors yourself:

e.onclick = function() {
  trans = db.transaction(...);
  try {
trans.objectStore(...).put(x());
trans.objectStore(...).put(y());
  } catch(e) {
trans.abort();
throw e;
  }
}

I don't think it helps to do this magically in an uncommon case, when
everyone needs to be in the habit of doing it manually in the common case
anyway.  It just seems confusing and arbitrary.

(Aborting due to exceptions from synchronous callbacks is fine, though,
since it's consistent: *all* requests on the transaction happen inside it.)

-- 
Glenn Maynard

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

[Glenn Maynard]

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 - and may force them into the synchronous JSON option -
> which can't be good for anybody.
>

It doesn't make it any more difficult than if sync XHR never existed in the
first place, which is what we'd like to emulate as closely as possible.

-- 
Glenn Maynard

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

[Jonas Sicking]

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 is a small amount of state querying of WebGL going on, so that's
> probably going to stall quite badly in my case, but it's definitely a
> solution. I suppose if this is going to be the accepted way forwards,
> somebody could write a library that transparently passed WebGL calls from a
> worker into the UI thread, and the transition might be relatively painless.

Long term we've talked about exposing WebGL to workers. That way you
could query the data that you need directly, and avoid having to send
messages to the main thread in order to render things with WebGL. But
it'll likely take a while before we get there.

/ Jonas

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

[Boris Zbarsky]

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 inserted. Notably, Gecko does
the WebKit/IE behavior if you use keydown instead of keypress. I don't
see any reason keypress should be different from keydown.


It's different because if you want to express default actions in terms 
of, say, system event group event handlers, the default action 
corresponds to an event handler for the keypress event... and the 
keypress event fired on the input the focus was shifted from.


This is also why it differs from keydown; shifting focus on keydown 
changes the target of the keypress.


-Boris

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

[Ojan Vafai]

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 behavior if you use keydown instead of keypress. I don't see any
reason keypress should be different from keydown.

On Tue, Mar 20, 2012 at 10:54 AM, Ryosuke Niwa  wrote:

> 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 keypress event's target was?
>
> DOM level 3 events doesn't seem to specify this behavior:
>
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress
>
> According to a fellow WebKit contributor, WebKit and Internet Explorer use
> the current focused element whereas Firefox uses the event target.
>
> Best,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
>
>
>

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

[Olli Pettay]

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 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
probably going to stall quite badly in my case, but it's definitely a
solution. I suppose if this is going to be the accepted way forwards,
somebody could write a library that transparently passed WebGL calls
from a worker into the UI thread, and the transition might be relatively
painless.

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 - and may force them into the synchronous JSON option -
which can't be good for anybody.

- Gordon

On 20/03/12 17:07, Jarred Nicholls wrote:

On Tue, Mar 20, 2012 at 12:09 PM, Gordon Williams mailto:g...@pur3.co.uk>> 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 on this list - apologies for the earlier
bug spam.

My issue is that I have WebGL JavaScript that is machine-generated
from a binary file - which is itself synchronous. It was working fine:

http://www.morphyre.com/scenedesign/go

It now fails on Firefox (and shortly on Chrome I imagine) because
it can't get an ArrayBuffer from a synchronous request. It may be
possible to split the execution and make it asynchronous, however
this is a very large undertaking as you may get an idea of from
looking at the source.

My understanding is that JavaScript Workers won't be able to
access WebGL, so I am unable to just run the code as a worker.

What options do I have here?

* Extensive rewrite to try and automatically translate the code to
be asynchronous
* Use normal Synchronous XHR and send the data I require in text
form, then turn it back into an ArrayBuffer with JavaScript

Are there any other options?

Right now, #2 is looking like the only sensible option - which is
a shame as it will drastically decrease the UX.

- Gordon



#1 is the best option long term.  All web platform APIs in the window
context - going forward - are asynchronous and this isn't going to be
the last time someone runs into this issue.

#2 is a reasonable stop gap; and assuming things like large textures
are being downloaded, the text -> preallocated TypedArray copy will be
shadowed by the wait for large I/O to complete from a remote source.

I believe there is a #3, which is a hybrid of sync APIs, Workers, and
message posting.  You can use a worker to perform these sync
operations and post data back to the main UI thread where an event
loop/handler runs and has access to the WebGL context.  Firefox 6+ and
Chrome 13+ have support for the structured cloning...there's overhead
involved but it works and might be an easier translation than creating
async JS.  Chrome 17+ has transferable objects, so data passing is
wicked fast.

Jarred

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

[Gordon Williams]

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 
probably going to stall quite badly in my case, but it's definitely a 
solution. I suppose if this is going to be the accepted way forwards, 
somebody could write a library that transparently passed WebGL calls 
from a worker into the UI thread, and the transition might be relatively 
painless.


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 - and may force them into the synchronous JSON option - 
which can't be good for anybody.


- Gordon

On 20/03/12 17:07, Jarred Nicholls wrote:
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
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 spam.

My issue is that I have WebGL JavaScript that is machine-generated
from a binary file - which is itself synchronous. It was working fine:

http://www.morphyre.com/scenedesign/go

It now fails on Firefox (and shortly on Chrome I imagine) because
it can't get an ArrayBuffer from a synchronous request. It may be
possible to split the execution and make it asynchronous, however
this is a very large undertaking as you may get an idea of from
looking at the source.

My understanding is that JavaScript Workers won't be able to
access WebGL, so I am unable to just run the code as a worker.

What options do I have here?

* Extensive rewrite to try and automatically translate the code to
be asynchronous
* Use normal Synchronous XHR and send the data I require in text
form, then turn it back into an ArrayBuffer with JavaScript

Are there any other options?

Right now, #2 is looking like the only sensible option - which is
a shame as it will drastically decrease the UX.

- Gordon



#1 is the best option long term.  All web platform APIs in the window 
context - going forward - are asynchronous and this isn't going to be 
the last time someone runs into this issue.


#2 is a reasonable stop gap; and assuming things like large textures 
are being downloaded, the text -> preallocated TypedArray copy will be 
shadowed by the wait for large I/O to complete from a remote source.


I believe there is a #3, which is a hybrid of sync APIs, Workers, and 
message posting.  You can use a worker to perform these sync 
operations and post data back to the main UI thread where an event 
loop/handler runs and has access to the WebGL context.  Firefox 6+ and 
Chrome 13+ have support for the structured cloning...there's overhead 
involved but it works and might be an easier translation than creating 
async JS.  Chrome 17+ has transferable objects, so data passing is 
wicked fast.


Jarred

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

[Ryosuke Niwa]

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 keypress event's target was?

DOM level 3 events doesn't seem to specify this behavior:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-keypress

According to a fellow WebKit contributor, WebKit and Internet Explorer use
the current focused element whereas Firefox uses the event target.

Best,
Ryosuke Niwa
Software Engineer
Google Inc.

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

[Jarred Nicholls]

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
> 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
> spam.
>
> My issue is that I have WebGL JavaScript that is machine-generated from a
> binary file - which is itself synchronous. It was working fine:
>
> http://www.morphyre.com/**scenedesign/go
>
> It now fails on Firefox (and shortly on Chrome I imagine) because it can't
> get an ArrayBuffer from a synchronous request. It may be possible to split
> the execution and make it asynchronous, however this is a very large
> undertaking as you may get an idea of from looking at the source.
>
> My understanding is that JavaScript Workers won't be able to access WebGL,
> so I am unable to just run the code as a worker.
>
> What options do I have here?
>
> * Extensive rewrite to try and automatically translate the code to be
> asynchronous
> * Use normal Synchronous XHR and send the data I require in text form,
> then turn it back into an ArrayBuffer with JavaScript
>
> Are there any other options?
>
> Right now, #2 is looking like the only sensible option - which is a shame
> as it will drastically decrease the UX.
>
> - Gordon
>
>
>
#1 is the best option long term.  All web platform APIs in the window
context - going forward - are asynchronous and this isn't going to be the
last time someone runs into this issue.

#2 is a reasonable stop gap; and assuming things like large textures are
being downloaded, the text -> preallocated TypedArray copy will be shadowed
by the wait for large I/O to complete from a remote source.

I believe there is a #3, which is a hybrid of sync APIs, Workers, and
message posting.  You can use a worker to perform these sync operations and
post data back to the main UI thread where an event loop/handler runs and
has access to the WebGL context.  Firefox 6+ and Chrome 13+ have support
for the structured cloning...there's overhead involved but it works and
might be an easier translation than creating async JS.  Chrome 17+ has
transferable objects, so data passing is wicked fast.

Jarred

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

[Jonas Sicking]

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 requested, I'll pursue on this list - apologies for the earlier bug spam.
>
> My issue is that I have WebGL JavaScript that is machine-generated from a
> binary file - which is itself synchronous. It was working fine:
>
> http://www.morphyre.com/scenedesign/go
>
> It now fails on Firefox (and shortly on Chrome I imagine) because it can't
> get an ArrayBuffer from a synchronous request. It may be possible to split
> the execution and make it asynchronous, however this is a very large
> undertaking as you may get an idea of from looking at the source.
>
> My understanding is that JavaScript Workers won't be able to access WebGL,
> so I am unable to just run the code as a worker.
>
> What options do I have here?
>
> * Extensive rewrite to try and automatically translate the code to be
> asynchronous
> * Use normal Synchronous XHR and send the data I require in text form, then
> turn it back into an ArrayBuffer with JavaScript
>
> Are there any other options?
>
> Right now, #2 is looking like the only sensible option - which is a shame as
> it will drastically decrease the UX.

I think that there's an option #3, which is to run the code inside a
worker and have it use synchronous APIs.

I agree that trying to automatically rewrite large C++ code bases to
change synchronous call into asynchronous calls is a too difficult
task. If it wasn't I'd love to run such a transformation over gecko to
change it to not use synchronous IO anywhere :-)

But I also think that having the translated code do a pile of
synchronous XHR calls will lead to a too poor user experience, so that
doesn't seem like a good option either.

Hence I suggest that you run the translated code in a worker. That way
you'll also be able to do synchronous file handling like using
FileReaderSync which you're bound to want to use in translated code.

/ Jonas

Re: [webcomponents] Progress Update

[Dimitri Glazkov]

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 possible to fully emulate the shadow DOM on
legacy rendering engines, we will try to have at least a functional
equivalent."

:DG<

On Tue, Mar 20, 2012 at 7:24 AM, Brian Kardell  wrote:
> 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, Jarred Nicholls  wrote:
>> 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.org/hg/webcomponents/raw-file/tip/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:09 AM, Brian Kardell 
>>> wrote:
>>> > 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:
>>> >> Hello, public-webapps!
>>> >>
>>> >> Here's another summary of work, happening in Web Components.
>>> >>
>>> >> SHADOW DOM
>>> >> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978)
>>> >> * First bits of the Shadow DOM test suite have landed:
>>> >>
>>> >> http://w3c-test.org/webapps/ShadowDOM/tests/submissions/Google/tests.html
>>> >> * More work in spec, long tail of edge cases and bugs:
>>> >>  - You can now select elements, distributed into insertion points
>>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
>>> >>  - A bug in adjusting event's relatedTarget was discovered and fixed
>>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
>>> >>  - As a result of examining Viewlink (an IE feature), more events are
>>> >> now stopped at the boundary
>>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804)
>>> >>  - Fixed a bug around scoping of styles
>>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16318)
>>> >> * Started restructuring CSS-related parts of the spec to accommodate
>>> >> these new features:
>>> >>  - Specify a way to select host element
>>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15220)
>>> >>  - Consider a notion of shared stylesheet
>>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15818)
>>> >>  - Consider a flag for resetting inherited styles at the shadow
>>> >> boundary (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15820)
>>> >> * Experimental support of Shadow DOM in WebKit is slowly, but surely
>>> >> gaining multiple shadow DOM subtree support
>>> >> (https://bugs.webkit.org/show_bug.cgi?id=77503)
>>> >>
>>> >> HTML TEMPLATES
>>> >> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=15476):
>>> >> * First draft of the specification is ready for review:
>>> >> http://dvcs.w3.org/hg/webcomponents/raw-file/spec/templates/index.html.
>>> >> * Most mechanical parts are written as deltas to the HTML spec, which
>>> >> offers an interesting question of whether this spec should just be
>>> >> part of HTML.
>>> >>
>>> >> CODE SAMPLES
>>> >> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14956):
>>> >> * Web Components Polyfill
>>> >> (https://github.com/dglazkov/Web-Components-Polyfill) now has unit
>>> >> tests and a good bit of test coverage. Contributions are appreciated.
>>> >> Even though it may not
>>> >>
>>> >> ADDITIONAL WAYS TO STAY UPDATED:
>>> >> * https://plus.google.com/b/103330502635338602217/
>>> >> * http://dvcs.w3.org/hg/webcomponents/rss-log
>>> >> * follow the meta bugs for each section.
>>> >>
>>> >> :DG<
>>> >>
>>>
>>

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

[Olli Pettay]

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 on this list - apologies for the earlier bug
spam.

My issue is that I have WebGL JavaScript that is machine-generated from
a binary file - which is itself synchronous. It was working fine:

http://www.morphyre.com/scenedesign/go

It now fails on Firefox (and shortly on Chrome I imagine) because it
can't get an ArrayBuffer from a synchronous request. It may be possible
to split the execution and make it asynchronous, however this is a very
large undertaking as you may get an idea of from looking at the source.

My understanding is that JavaScript Workers won't be able to access
WebGL, so I am unable to just run the code as a worker.

What options do I have here?

* Extensive rewrite to try and automatically translate the code to be
asynchronous
* Use normal Synchronous XHR and send the data I require in text form,
then turn it back into an ArrayBuffer with JavaScript

Are there any other options?

Right now, #2 is looking like the only sensible option - which is a
shame as it will drastically decrease the UX.


#1 sounds like the only reasonable option.
You have now code like:
...
var x = new XMLHttpRequest();
x.open(...);
x.send();
...do something with x.response.


Why couldn't async work?

...
var x = new XMLHttpRequest();
x.open(...);
x.onload = function () { ...do something with x.response. }
x.send();

If you need to prevent user events while XHR is active, put some 
transparent overlay over the page.

If timers shouldn't run, wrap setTimeout with your own stuff which can
suspend timers when XHR is active.



-Olli







- Gordon

Recent Sync XHR changes and impact on automatically translated JavaScript code

[Gordon Williams]

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

My issue is that I have WebGL JavaScript that is machine-generated from 
a binary file - which is itself synchronous. It was working fine:


http://www.morphyre.com/scenedesign/go

It now fails on Firefox (and shortly on Chrome I imagine) because it 
can't get an ArrayBuffer from a synchronous request. It may be possible 
to split the execution and make it asynchronous, however this is a very 
large undertaking as you may get an idea of from looking at the source.


My understanding is that JavaScript Workers won't be able to access 
WebGL, so I am unable to just run the code as a worker.


What options do I have here?

* Extensive rewrite to try and automatically translate the code to be 
asynchronous
* Use normal Synchronous XHR and send the data I require in text form, 
then turn it back into an ArrayBuffer with JavaScript


Are there any other options?

Right now, #2 is looking like the only sensible option - which is a 
shame as it will drastically decrease the UX.


- Gordon

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

[Dominique Hazael-Massieux]

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 ED as the basis:
> 
> http://dev.w3.org/2006/webapi/WebIDL/
> 
> This CfC satisfies: a) the group's requirement to "record the group's 
> decision to request advancement" to CR; and b) "General Requirements for 
> Advancement on the Recommendation Track" as defined in the Process Document:
> 
> http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs
> 
> Positive response is preferred and encouraged and silence will be 
> considered as agreeing with the proposal.

Big +1.

Dom

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

[bugzilla]

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
 Component: Fullscreen
AssignedTo: ann...@opera.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


"Let docs be all doc's ancestor browsing context's documents (if any) and doc."

This doesn't say in what order they should be. (The order is observable because
the algorithm queues events and the documents use the same event queue, I
think.)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

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

[bugzilla]

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
  Priority: P2
 Component: Fullscreen
AssignedTo: ann...@opera.com
ReportedBy: sim...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


"If any of the following conditions are true, terminate these steps and queue a
task to ..."

This should be in the other order, since a strict reading would mean that
terminating the steps would *not* queue a task.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [webcomponents] Progress Update

[Brian Kardell]

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, Jarred Nicholls  wrote:
> 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.org/hg/webcomponents/raw-file/tip/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:09 AM, Brian Kardell 
>> wrote:
>> > 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:
>> >> Hello, public-webapps!
>> >>
>> >> Here's another summary of work, happening in Web Components.
>> >>
>> >> SHADOW DOM
>> >> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978)
>> >> * First bits of the Shadow DOM test suite have landed:
>> >>
>> >> http://w3c-test.org/webapps/ShadowDOM/tests/submissions/Google/tests.html
>> >> * More work in spec, long tail of edge cases and bugs:
>> >>  - You can now select elements, distributed into insertion points
>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
>> >>  - A bug in adjusting event's relatedTarget was discovered and fixed
>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
>> >>  - As a result of examining Viewlink (an IE feature), more events are
>> >> now stopped at the boundary
>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804)
>> >>  - Fixed a bug around scoping of styles
>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16318)
>> >> * Started restructuring CSS-related parts of the spec to accommodate
>> >> these new features:
>> >>  - Specify a way to select host element
>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15220)
>> >>  - Consider a notion of shared stylesheet
>> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15818)
>> >>  - Consider a flag for resetting inherited styles at the shadow
>> >> boundary (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15820)
>> >> * Experimental support of Shadow DOM in WebKit is slowly, but surely
>> >> gaining multiple shadow DOM subtree support
>> >> (https://bugs.webkit.org/show_bug.cgi?id=77503)
>> >>
>> >> HTML TEMPLATES
>> >> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=15476):
>> >> * First draft of the specification is ready for review:
>> >> http://dvcs.w3.org/hg/webcomponents/raw-file/spec/templates/index.html.
>> >> * Most mechanical parts are written as deltas to the HTML spec, which
>> >> offers an interesting question of whether this spec should just be
>> >> part of HTML.
>> >>
>> >> CODE SAMPLES
>> >> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14956):
>> >> * Web Components Polyfill
>> >> (https://github.com/dglazkov/Web-Components-Polyfill) now has unit
>> >> tests and a good bit of test coverage. Contributions are appreciated.
>> >> Even though it may not
>> >>
>> >> ADDITIONAL WAYS TO STAY UPDATED:
>> >> * https://plus.google.com/b/103330502635338602217/
>> >> * http://dvcs.w3.org/hg/webcomponents/rss-log
>> >> * follow the meta bugs for each section.
>> >>
>> >> :DG<
>> >>
>>
>

Re: [webcomponents] Progress Update

[Jarred Nicholls]

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.org/hg/webcomponents/raw-file/tip/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:09 AM, Brian Kardell 
> wrote:
> > 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:
> >> Hello, public-webapps!
> >>
> >> Here's another summary of work, happening in Web Components.
> >>
> >> SHADOW DOM (
> https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978)
> >> * First bits of the Shadow DOM test suite have landed:
> >>
> http://w3c-test.org/webapps/ShadowDOM/tests/submissions/Google/tests.html
> >> * More work in spec, long tail of edge cases and bugs:
> >>  - You can now select elements, distributed into insertion points
> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
> >>  - A bug in adjusting event's relatedTarget was discovered and fixed
> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
> >>  - As a result of examining Viewlink (an IE feature), more events are
> >> now stopped at the boundary
> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804)
> >>  - Fixed a bug around scoping of styles
> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16318)
> >> * Started restructuring CSS-related parts of the spec to accommodate
> >> these new features:
> >>  - Specify a way to select host element
> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15220)
> >>  - Consider a notion of shared stylesheet
> >> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15818)
> >>  - Consider a flag for resetting inherited styles at the shadow
> >> boundary (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15820)
> >> * Experimental support of Shadow DOM in WebKit is slowly, but surely
> >> gaining multiple shadow DOM subtree support
> >> (https://bugs.webkit.org/show_bug.cgi?id=77503)
> >>
> >> HTML TEMPLATES (
> https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=15476):
> >> * First draft of the specification is ready for review:
> >> http://dvcs.w3.org/hg/webcomponents/raw-file/spec/templates/index.html.
> >> * Most mechanical parts are written as deltas to the HTML spec, which
> >> offers an interesting question of whether this spec should just be
> >> part of HTML.
> >>
> >> CODE SAMPLES (
> https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14956):
> >> * Web Components Polyfill
> >> (https://github.com/dglazkov/Web-Components-Polyfill) now has unit
> >> tests and a good bit of test coverage. Contributions are appreciated.
> >> Even though it may not
> >>
> >> ADDITIONAL WAYS TO STAY UPDATED:
> >> * https://plus.google.com/b/103330502635338602217/
> >> * http://dvcs.w3.org/hg/webcomponents/rss-log
> >> * follow the meta bugs for each section.
> >>
> >> :DG<
> >>
>
>

Re: [webcomponents] Progress Update

[Brian Kardell]

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:09 AM, Brian Kardell  wrote:
> 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:
>> Hello, public-webapps!
>>
>> Here's another summary of work, happening in Web Components.
>>
>> SHADOW DOM (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978)
>> * First bits of the Shadow DOM test suite have landed:
>> http://w3c-test.org/webapps/ShadowDOM/tests/submissions/Google/tests.html
>> * More work in spec, long tail of edge cases and bugs:
>>  - You can now select elements, distributed into insertion points
>> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
>>  - A bug in adjusting event's relatedTarget was discovered and fixed
>> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
>>  - As a result of examining Viewlink (an IE feature), more events are
>> now stopped at the boundary
>> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804)
>>  - Fixed a bug around scoping of styles
>> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16318)
>> * Started restructuring CSS-related parts of the spec to accommodate
>> these new features:
>>  - Specify a way to select host element
>> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15220)
>>  - Consider a notion of shared stylesheet
>> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15818)
>>  - Consider a flag for resetting inherited styles at the shadow
>> boundary (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15820)
>> * Experimental support of Shadow DOM in WebKit is slowly, but surely
>> gaining multiple shadow DOM subtree support
>> (https://bugs.webkit.org/show_bug.cgi?id=77503)
>>
>> HTML TEMPLATES 
>> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=15476):
>> * First draft of the specification is ready for review:
>> http://dvcs.w3.org/hg/webcomponents/raw-file/spec/templates/index.html.
>> * Most mechanical parts are written as deltas to the HTML spec, which
>> offers an interesting question of whether this spec should just be
>> part of HTML.
>>
>> CODE SAMPLES 
>> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14956):
>> * Web Components Polyfill
>> (https://github.com/dglazkov/Web-Components-Polyfill) now has unit
>> tests and a good bit of test coverage. Contributions are appreciated.
>> Even though it may not
>>
>> ADDITIONAL WAYS TO STAY UPDATED:
>> * https://plus.google.com/b/103330502635338602217/
>> * http://dvcs.w3.org/hg/webcomponents/rss-log
>> * follow the meta bugs for each section.
>>
>> :DG<
>>

Re: [webcomponents] Progress Update

[Brian Kardell]

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:
> Hello, public-webapps!
>
> Here's another summary of work, happening in Web Components.
>
> SHADOW DOM (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978)
> * First bits of the Shadow DOM test suite have landed:
> http://w3c-test.org/webapps/ShadowDOM/tests/submissions/Google/tests.html
> * More work in spec, long tail of edge cases and bugs:
>  - You can now select elements, distributed into insertion points
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
>  - A bug in adjusting event's relatedTarget was discovered and fixed
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176)
>  - As a result of examining Viewlink (an IE feature), more events are
> now stopped at the boundary
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804)
>  - Fixed a bug around scoping of styles
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16318)
> * Started restructuring CSS-related parts of the spec to accommodate
> these new features:
>  - Specify a way to select host element
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15220)
>  - Consider a notion of shared stylesheet
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15818)
>  - Consider a flag for resetting inherited styles at the shadow
> boundary (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15820)
> * Experimental support of Shadow DOM in WebKit is slowly, but surely
> gaining multiple shadow DOM subtree support
> (https://bugs.webkit.org/show_bug.cgi?id=77503)
>
> HTML TEMPLATES 
> (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=15476):
> * First draft of the specification is ready for review:
> http://dvcs.w3.org/hg/webcomponents/raw-file/spec/templates/index.html.
> * Most mechanical parts are written as deltas to the HTML spec, which
> offers an interesting question of whether this spec should just be
> part of HTML.
>
> CODE SAMPLES (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14956):
> * Web Components Polyfill
> (https://github.com/dglazkov/Web-Components-Polyfill) now has unit
> tests and a good bit of test coverage. Contributions are appreciated.
> Even though it may not
>
> ADDITIONAL WAYS TO STAY UPDATED:
> * https://plus.google.com/b/103330502635338602217/
> * http://dvcs.w3.org/hg/webcomponents/rss-log
> * follow the meta bugs for each section.
>
> :DG<
>

Re: Call for Review: Web Audio API

[Jerome Etienne]

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 Audio API 
> [1] on 15 March 2012. From the introduction:
>
> [[
> This specification describes a high-level JavaScript API for processing and 
> synthesizing audio in web applications. The primary paradigm is of an audio 
> routing graph, where a number of AudioNode objects are connected together to 
> define the overall audio rendering. The actual processing will primarily take 
> place in the underlying implementation (typically optimized Assembly / C / 
> C++ code), but direct JavaScript processing and synthesis is also supported.
> ]]
>
> We would appreciate review and feedback on the spec [1] and the use cases and 
> requirements [2] from the participants in the WebRTC, WebApps, and HTML 
> groups and the Media Capture task force.
>
> [1] http://www.w3.org/TR/2012/WD-webaudio-20120315/
> [2] http://www.w3.org/2011/audio/wiki/Use_Cases_and_Requirements
>
> Regards-
> -Doug Schepers
> On behalf of the Audio WG
>