Instead of having a fixed list of events that are stopped, maybe
instead we can pass a flag to the dispatch algorithm with respect to
whether or not the event being dispatched should exit the shadow
boundary it started in, if any. That way you can have your own private
event handling in the shadow
* Anne van Kesteren wrote:
Instead of having a fixed list of events that are stopped, maybe
instead we can pass a flag to the dispatch algorithm with respect to
whether or not the event being dispatched should exit the shadow
boundary it started in, if any. That way you can have your own private
On Thu, Feb 7, 2013 at 2:27 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Such behavioral oddities would have to be exposed on the event objects
anyway because authors would otherwise have a hard time debugging this,
much like event objects expose whether they bubble. I assume the current
list
Hi All,
We created an agenda page for WebApps' April 25-26 f2f meeting, hosted
by eBay in San Jose CA US [Agenda].
The proposed meeting format is similar to our previous f2f meetings - a
mix of preassigned time slots for some specific topics use an
`unconference` style meeting to determine
On Thu, Feb 7, 2013 at 7:02 AM, Anne van Kesteren ann...@annevk.nl wrote:
Instead of having a fixed list of events that are stopped, maybe
instead we can pass a flag to the dispatch algorithm with respect to
whether or not the event being dispatched should exit the shadow
boundary it started
FYI, Marcos started a thread about IDB and API design on the www-tag
list. If you have any replies, please send them to www-...@w3.org
http://lists.w3.org/Archives/Public/www-tag/2013Feb/0003.html
Original Message
Subject: IndexedDB, what were the issues? How do we stop it
On Thu, Feb 7, 2013 at 5:02 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
I think this is a nicer solution. Will we have defaults associated with some
types of events or is it completely up to the shadow tree author to decide
the fate of the events?
You cannot associate defaults with event
On Thu, Feb 7, 2013 at 9:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 7, 2013 at 5:02 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
I think this is a nicer solution. Will we have defaults associated with
some
types of events or is it completely up to the shadow tree
I think we have the solution for polyfills: return a slightly different
object from document.register. Should we do the same thing for ES5/3 or
should we spec this as overwriting of the [[Construct]] method?
:DG
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17681
Eliot Graff eliot...@microsoft.com changed:
What|Removed |Added
Status|NEW |RESOLVED
I put up a new proposal for canvas in workers
http://wiki.whatwg.org/wiki/CanvasInWorkers
Please take a look.
This proposal comes from offline discussions with representatives from the
various browsers as well as input from the Google Maps team. I can post a
summary here if you'd like but it
On Wed, Feb 6, 2013 at 10:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/6/13 5:07 PM, Erik Arvidsson wrote:
This refactoring is needed for ES6 anyway so it might be worth looking
into no matter what.
Well, yes, but it's a matter of timeframes. It's incredibly unlikely that
a complete
In my excitement for getting something that worked on the Big Three
(webkit, IE, FF), I inadvertently cheated by adding an extra parameter to
'document.register'.
TL;DR version:
Solutions to the extra parameter problem:
1. go ahead and have an (optional) extra parameter to document.register
Good reminder. On webkit/ff at least, we have made polyfills which can
generate:
x-element // for elements derived from HTMLUnknownElement
button is=x-element // for all other elements
Since both syntaxes are now (to be) supported by spec, I think we are ok?
Scott
P.S. 100% of the custom
Scott is right, there isn't a great polyfill answer for this part of the
spec, but fortunately it doesn't affect too potential many use-cases.
Developers will still go bananas for the functionality we can provide in
legacy UA versions.
- Daniel
On Feb 7, 2013 8:51 PM, Scott Miles
Having thought about this before, I wonder why we don’t use a producer/consumer
model rather than a transfer of canvas ownership model?
A completely orthogonal idea (just my rough 2c after reading Gregg’s proposal),
is to have an internal frame buffer accessible via a WorkerCanvas API which
16 matches
Mail list logo