On 04/02/2013 20:06 , Ian Hickson wrote:
Geolocation can use a similar asynchronous UI:
++
| (+) example.org wants to know your location. [ San Jose (IP)|V] X|
+---| Mountain View
Hi,
I'm new to this forum and I'm not completely sure if I'm posting to right
list. I hope I am.
I've been playing with IndexedDB to learn how to use it and around this
experiment I wrote a blog article about my experiences.
While writing my article, I realized there is no way to add event
One solution would be to don't call directly to IndexedDB methods but
instead use custom wrappers that fit better with your application
(this is what I'm doing), but definitelly I totally agree with you
that IndexedDB should raise events when a row has been
inserted/updated/deleted. I think it was
The problem with emitting change notification on writes is that they dont
propogate across tabs, my library has to use localstorage to emit events
across tabls and keep track of a change sequence in each tab
This would be a welcome addition to the spec (after we get to enumerate
databases) :)
On
Why it can propagate over tabs if all of them are accessing to the
same database?
2013/2/5 Dale Harvey d...@arandomurl.com:
The problem with emitting change notification on writes is that they dont
propogate across tabs, my library has to use localstorage to emit events
across tabls and keep
The way document.register is currently proposed makes it
future-hostile to ES6. I've heard several people from different
organizations say that this is a blocking issue.
Over the last couple of days we (me, Dimitri and others) have worked
on some alterations to the current spec proposal. The
They can, I was just saying that they wont do that by default (as I assume
a native implementation would), you need to write your own messaging system
out of band
Cheers
Dale
On 5 February 2013 22:12, pira...@gmail.com pira...@gmail.com wrote:
Why it can propagate over tabs if all of them are
This should also be added, then...
2013/2/5 Dale Harvey d...@arandomurl.com:
They can, I was just saying that they wont do that by default (as I assume a
native implementation would), you need to write your own messaging system
out of band
Cheers
Dale
On 5 February 2013 22:12,
On 2/5/13 10:12 PM, Erik Arvidsson wrote:
In ES6 speak, we have split the new Foo(...args) expression into
Foo.call(Foo[@@create](), ...args) which means that creating the
instance has been separated from the call to the function.
So in particular this allows creation of uninitialized
This could be accomplished with a separate pub/sub capability, instead of
complicating the IDB interfaces and allocating new functions to that
component.
We (chromium project) have open bug about a broadcastMessage function.
https://code.google.com/p/chromium/issues/detail?id=161070
On Tue, Feb
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So in particular this allows creation of uninitialized instances in some
sense, yes?
Depends how much logic is put in the constructor vs @@create. For DOM
Elements I think we want to put *all* the logic in create. @@create
On 2/5/13 11:01 PM, Erik Arvidsson wrote:
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So in particular this allows creation of uninitialized instances in some
sense, yes?
Depends how much logic is put in the constructor vs @@create. For DOM
Elements I think we want
TL;DR: Being able to declare the permissions that an app asks for might be useful. User agents are and should continue to be free to innovate in ways they present the requests to the user, because a block dialogue isn't a universal improvement on current practice (which in turn isn't the same
On Tue, Feb 5, 2013 at 3:25 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/5/13 11:01 PM, Erik Arvidsson wrote:
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So in particular this allows creation of uninitialized instances in
some
sense, yes?
Depends how much
I have two questions:
1. Does this affect our ability to polyfill doc.register in current
browsers?
2. Are you saying we're going to nix the ability to easily register
insertion, removal, and attribute change callbacks from the API?
I believe #2 is very important and should not be
*
So this won't work?*
var MyButton = document.register(‘x-mybutton’, {
prototype: Object.create(HTMLButtonElement.prototype, { ... })
});
class MySuperButton extends MyButton { ... };
document.register('x-superbutton', MySuperButton);
*But this will?*
function MyButton() {
This direction of placing permissions up there in the site info expansion in
Chrome feels like the right direction. That spot where they show where an SSL
cert is valid/expired.
Now I can easily see cookies and flip various settings in one click as I look
at site info.
I've been working on a
I don't think you can say either an up front dialog or popups do not work.
There are clear examples of both working, Android and iPhone respectively.
Each has a different set of trade-offs and is better in some circumstances,
worse in others.
In my opinion an API should allow for both, so that
18 matches
Mail list logo
