I think that there would be many uses for a mechanism that allows
developers to take part in letting the UA known when it is ready. For
example, we would use then when analyzing extension code server-side.
Another example would be systems that take screenshots of web pages for use
in browser start
On Mon, Jun 14, 2010 at 7:27 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 27 May 2010 18:22:03 +0200, Aaron Boodman a...@google.com wrote:
On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
meta name=application-name content=...
You're right -- that one
On Wed, Jul 7, 2010 at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Jul 7, 2010 at 5:28 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
This is about the fourth time I've said it here. Can the person in
charge of writing the slow and buggy ajvascript on the HTML 5 spec
please
On Tue, Jun 8, 2010 at 1:17 PM, Adam Barth w...@adambarth.com wrote:
Yes, doing this correctly is quite subtle. I'd pitch the feature more
as developer connivence rather than for security. Apps that are
hosted in the same origin need to trust each other.
That is what we were planning on.
-
On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2010-05-26 19:10, Aaron Boodman wrote:
On Wed, May 26, 2010 at 4:30 AM, Henri Sivonenhsivo...@iki.fi
wrote:
There's a zip file with a .crx extension that contains an icon, a
permission manifest and potentially
Hello Henri,
Thank you for the thoughtful mail. I really appreciate you taking the
time to understand the proposal.
On Wed, May 26, 2010 at 4:30 AM, Henri Sivonen hsivo...@iki.fi wrote:
I don't think it's a given that everyone who is talking about installable
Web apps is talking about HTTP
On Wed, May 26, 2010 at 10:10 AM, Aaron Boodman a...@google.com wrote:
!-- for UAs that want a button in the Chrome to appify --
button onclick=navigator.installApplication()install/button
Sorry, I meant for UAs that want a button in the content area to appify.
- a
This has come up before, but since Google has officially announced the
project at IO, and Mozilla has voiced interest in the idea on their
blog, I felt like it might be a good to revisit.
Google would like to make today's web apps installable in Chrome.
From a user's point of view, installing a
On Wed, Sep 16, 2009 at 3:36 PM, Jeremy Orlow jor...@chromium.org wrote:
Code wise, what Robert suggested is MUCH simpler. Almost for free in
WebKit. Creating an asynchronous access method and exposing this in the
page is much more complex. It also defeats the main purpose of LocalStorage
On Fri, Sep 11, 2009 at 9:03 AM, Mike Shaver mike.sha...@gmail.com wrote:
Aaron,
You're right, my recollection is quite incorrect. My apologies for
unfairly describing the origin of the proposal.
I forgive you :).
In fact, the many design changes to the database API were made
precisely
On Wed, Sep 9, 2009 at 10:55 AM, Darin Fisherda...@chromium.org wrote:
I imagine a simple lock API:
window.acquireLock(name)
window.releaseLock(name)
I do not think it is a good idea to allow long-lived (past a stack
frame) locks on the types of things we've been discussing (local
storage,
On Wed, Sep 9, 2009 at 11:23 AM, Darin Fisherda...@chromium.org wrote:
On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman a...@google.com wrote:
There would presumably have to be a separate name value for each API,
though, right? So we're talking about the difference between:
window.acquireLock
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodmana...@google.com wrote:
I see.
So you are suggesting the localStorage could have zero concurrency
guarantees and it is simply up to the developer to arrange things
themselves using this new primitive.
That is an interesting idea. You're right
On Wed, Sep 9, 2009 at 9:13 PM, Darin Fisherda...@chromium.org wrote:
If I call showModalDialog from within a database transaction, and then
showModalDialog
tries to create another database transaction, should I expect that the
transaction
can be started within the nested run loop of the
On Wed, Sep 9, 2009 at 10:07 PM, Darin Fisherda...@chromium.org wrote:
Well, the problem is that the creator of the transaction and the code
associated with the showModalDialog call may not be related. The
showModalDialog code might normally be used outside the context of a
transaction, in
On Fri, Sep 4, 2009 at 12:02 AM, Chris Jonescjo...@mozilla.com wrote:
I propose adding the functions
window.localStorage.beginTransaction()
window.localStorage.commitTransaction()
or
window.beginTransaction()
window.commitTransaction()
I think this is a good idea! I would modify it to
On Tue, Sep 8, 2009 at 12:54 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodmana...@google.com wrote:
On Fri, Sep 4, 2009 at 12:02 AM, Chris Jonescjo...@mozilla.com wrote:
I propose adding the functions
window.localStorage.beginTransaction()
On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:07 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009 at 12:54 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodmana...@google.com wrote:
On Fri, Sep 4,
On Tue, Sep 8, 2009 at 1:20 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:18 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 1:07 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009
On Tue, Sep 8, 2009 at 2:02 AM, Robert O'Callahanrob...@ocallahan.org wrote:
Looking back over previous threads on the storage mutex, I can't seem to
remember or find the reason that implementing the storage mutex for cookies
can't easily be done with a mutex per domain. Ian pointed out this
beginTransaction()/commitTransaction() for a window.transaction() wrapper
that implicitly does those.
Cool, that is the only point I was trying to make.
Aaron Boodman wrote:
On Tue, Sep 8, 2009 at 1:41 AM, Robert O'Callahanrob...@ocallahan.org
wrote:
What is the intended semantics here? Chris' explicit
On Tue, Sep 8, 2009 at 12:02 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Sep 8, 2009 at 11:53 AM, Aaron Boodmana...@google.com wrote:
On Tue, Sep 8, 2009 at 11:23 AM, Chris Jonescjo...@mozilla.com wrote:
In general, I agree with Rob about this proposal. What problem with storage
mutex as
On Tue, Sep 8, 2009 at 4:27 PM, Chris Jonescjo...@mozilla.com wrote:
With my proposal, a web app that tests whether localStorage is available
with |window.localStorage === undefined| would conclude that it's not,
because that object would not be available until |window.transaction| or
whatever
On Wed, Aug 26, 2009 at 8:23 PM, Linus Upsonli...@google.com wrote:
I simply want clicking on links to be safe. In a previous thread I wrote
safe and stateless but I'm coming to the opinion that stateless is
a corollary of safe. Clicking on links shouldn't, either by filling my disk
or hitting
On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlowjor...@chromium.org wrote:
I still don't understand what use local storage has outside of 'cloud
storage'. Even in the extensions use case (which I think is out of scope
for this spec), there's no reason you can't sync user preferences and such
to
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org wrote:
Ok, well I guess we should go ahead and have this discussion now. :-) Does
anyone outside of Apple and Google have an opinion on the matter (since I
think it's pretty clear where we both stand).
FWIW, I tend to agree
On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilsonmike...@hotmail.com wrote:
Another thing:
From the proposal it seems it will be possible for the GlobalScript context
to keep references to objects (DOM, JS data, etc) private to pages, and vice
versa possible for pages to keep references to
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote:
Michael Nordman wrote:
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote:
Threading:
This is the unavoidable question ;-) How do you envision
multiple threads accessing this shared context to be
[If this has been discussed before, feel free to just point me there]
I frequently see the comment on this list and in other forums that
something is too late for HTML5, and therefore discussion should be
deferred.
I would like to propose that we get rid of the concepts of versions
altogether
On Sun, Aug 9, 2009 at 9:21 AM, Tab Atkins Jr.jackalm...@gmail.com wrote:
A feature that is not widely supported is a feature we authors can't
depend on. If we're lucky, we can put in some extra effort to work
around the lack and still deliver a decent experience. If we're not,
we simply
On Mon, Jul 27, 2009 at 9:51 PM, David Levinle...@chromium.org wrote:
It sounds like most of the concerns are about the 2nd part of this proposal:
allowing a background page to continue running after the visible page has
been closed.
However, the first part sounds like it alone would be useful
On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sickingjo...@sicking.cc wrote:
On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyteawh...@google.com wrote:
When a page is loaded from an AppCache, even when online, external resources
such as images will not be loaded at all.
If foo.com has an image img
2009/6/15 Ian Fette (イアンフェッティ) ife...@google.com:
In the event of a collision there would be huge issues - imagine running
someone else's script in your application. Basically XSS - someone could
take over your app, steal passwords, do bank transactions on your behalf,
etc.
Collisions are
This isn't a localstorage specific question, this is a general
question about overriding methods on any host object.
The comments about shooting yourself in the foot are good points, but
the same exact thing is possible on every single API in the entire
environment. It doesn't make sense to worry
I like the basic idea, but I think drawing too much inspiration from
DOM events is a bad idea. What does it mean to capture a pure JS
event? Further, the DOM event model has problems. It would be nice if
events were first-class, not strings. It would be more idiomatic JS, I
would argue, to do
On Fri, Apr 24, 2009 at 2:09 PM, Alex Russell slightly...@google.com wrote:
Even in the XHR case, adding more than one listener is currently a
pain. Part of the goal here would be to make event dispatch across
lists of listeners as natural in JS as it is in DOM.
Nit: I believe this has been
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson atwil...@google.com wrote:
I've thought about this more, and I'm afraid that if you start making the
API cumbersome (forcing only async access) then apps are just going to use
document.cookies instead of localStorage. I'd hate to see us radically
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
What we could do, is to have an API like
getLocalStorage(callback);
This function returns immediately, but will then call the callback
function as soon as the localStorage becomes available and the lock
been acquired.
On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson atwil...@google.com wrote:
That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.
It seems like they
On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking jo...@sicking.cc wrote:
The problem with synchronously grabbing the lock is that we can only
ever have one feature that uses synchronous locks, otherwise we'll
risk dead-locks.
Say that we make document.cookie behave the same way (to prevent
I think the best option is to make access to localstorage asynchronous
for workers. This reduces the amount of time a worker can hold the
localstore lock so that it shouldn't be a problem for normal pages. It
sucks to make such a simple and useful API aync though.
- a
On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson [EMAIL PROTECTED] wrote:
We could have a .writeTransaction() and a .readTransaction(), where the
former always run in isolation.
Any preferences?
My preference is for separating read transactions from write
transactions. Then the API could throw if
On Tue, Nov 18, 2008 at 10:09 PM, Dmitry Titov [EMAIL PROTECTED] wrote:
Ok, it makes sense for OOM to treat it as other OOM cases.
If I may ask your opinion about related thing: SharedWorkers potentially
would run cross-process. IPC can stop/stuck for many reasons, taret process
can die in the
PROTECTED] wrote:
Indeed. Blobs is a great idea. We'll probably have to create further JSON
extensions to support that.
/ Jonas
Aaron Boodman wrote:
+1, because I think it will be useful to pass other things to workers
that JSON cannot represent (blobs) in the future.
- a
On Mon, Nov 17
.
- a
On Mon, Nov 17, 2008 at 8:18 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Well, you'd probably want to support things like
w.postMessage({ command: do cool thing,
data: myBlob });
/ Jonas
Aaron Boodman wrote:
If you support worker.sendMessage(stuff), where stuff
Ian,
Thanks for taking the time to read and understand all the feedback.
Although this is not my most preferred design for the API, I can live
with it. I'm happy that we removed startConversation(). I think that
was just extra complexity on top of an already large API.
As for putting forward
On Thu, Nov 13, 2008 at 10:17 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Aaron Boodman wrote:
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Actually, i think we should remove the location accessor as well. I
can't think
On Fri, Nov 14, 2008 at 4:33 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Hmm.. this makes a lot of sense for importScripts, but for XHR you probably
want the baseURI to be that of the opening page, since it's quite likely
that the opening page gave you a URI to open and process.
My expectation
Jonas asked me about this in IRC, and specifically why I suggested
appCodeName (since everyone claims they are Mozilla). My thinking was:
a) Browser detection is a mess, scripts use everything on the
navigator object (often incorrectly) to try and figure out which
browser is which
b) HTML5 may
2008/11/13 Jonas Sicking [EMAIL PROTECTED]:
So at this point the main problem with making any changes is that we
are very close to shipping Firefox 3.1. I.e. it is extremely hard to
make changes. It is very unfortunate that we have ended up in this
situation again. We were in a very similar to
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Actually, i think we should remove the location accessor as well. I
can't think of a common enough use case that warrants an explicit API.
You can always transfer the data through
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]:
Nov 4, 2008, в 10:08 AM, Aaron Boodman написал(а):
* Add startConversation() to SharedWorker, but rename it connect()
and make the onconnect event fire inside the worker each time it is
called.
What event do you suggest to dispatch
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]:
Well, that's what MessagePort.startConversation() sends, and the proposal
only said that connect() is a renamed startConversation() from Worker (also,
The postMessage() and startConversation() methods on Worker objects must
act as if, when
2008/11/12 Alexey Proskuryakov [EMAIL PROTECTED]:
The startConversation(message) method is a convenience method that
simplifies create a new MessageChannel and invokingpostMessage() with one of
the new ports. - it doesn't do anything postMessage() couldn't do.
Receivers are supposed to
Jonas, Hixie, and I talked about this yesterday on IRC (logs start
here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go
into the next day).
Jonas is still against removing postMessage/onmessage from the Worker
interface in favor of connect() only. Also, several people feel like
2008/11/4 Alexey Proskuryakov [EMAIL PROTECTED]:
Nov 4, 2008, в 10:08 AM, Aaron Boodman написал(а):
Here's an example in code:
// dedicated workers (outside)
var worker = new Worker(foo.js);
var port = worker.connect();
port.onmessage = function() { }
port.postMessage(ping);
// dedicated
Hello all,
A few months ago, I suggested that we combine the DedicatedWorker and
SharedWorker interfaces
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016228.html),
but we never reached consensus.
Since Mozilla and Apple are both working on implementing this now, I'd
like
On Mon, Nov 3, 2008 at 11:08 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
sendMessage()
I'm sorry, please excuse my mixing the names 'sendMessage' and
'postMessage'. The Gears API is named 'sendMessage' and I keep
accidentally using that.
The name in Web Workers should of course be 'postMessage
2008/10/1 Kristof Zelechovski [EMAIL PROTECTED]:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-642250288 contains
the
same deprecating statement.
I think it would be really unfortunate if we followed through with this, and
I definitely think that input.placeholder should work.
The
On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Please. This thread is not abort how to write JavaScript code in general.
It is about how to write the feature detection code. This kind of code
should be especially robust and relying on deprecated features does
2008/9/30 Alexey Proskuryakov [EMAIL PROTECTED]:
I'm not sure it's so good in the case of dedicated workers either, as they
can be used from other contexts via additional message ports. The close()
method could just close the default port.
Sure, but in order for that to have happened, whoever
2008/9/30 Alexey Proskuryakov [EMAIL PROTECTED]:
Hmm... So this is more about how you use the interface, not what the object
behind it is. If one chooses to never call close() on a shared worker (or,
say, sets myWorker.close to null right after invoking constructor), it
becomes
On Wed, Sep 24, 2008 at 6:26 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Sorry about the slow feedback, has been on vacation most of the time.
np.
So first off I don't think we can remove the ability to pass
MessagePorts around. This ability exists in Window.postMessage already
per spec so
On Wed, Sep 24, 2008 at 8:27 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
In the current design, there are three separate mechanisms to connect
to and communicate with a worker:
a) DedicatedWorker::sendMessage() + DedicatedWorkerGlobalScope::onmessage
b) DedicatedWorker::startConversation
Ping? Thoughts? Anyone?
Jonas, I know you are the one most likely to be affected by this in
the near term. Thoughts?
I know you are generally in favor of something close to the current
Gears API, and generally against the concept of MessagePorts.
But I think introducing a MessagePort object is
Thinking about this some more, having the port convenience
properties gets confusing when there are multiple clients sending
messages, and doesn't make a whole lot of sense with shared workers.
I think we should just get rid of these. It only adds one line of code
to the simple case. Also, I
I've reviewed and digested the latest workers update
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015853.html).
I think we're converging :).
There are still a few improvements and simplifications I'd like to
see, however. With these (relatively minor) changes, I'd be really
On Thu, Aug 28, 2008 at 3:11 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
I think that example could be solved simpler actually. An audio element
can be moved between two documents without requiring any interference in its
functionality. So if pandora used an audio to play music they could easily
I encounter sites frequently that want to pop out part of their
application free of the page, into a smaller window. For example,
Pandora radio (http://pandora.com) does this. The player starts out
embedded in the normal content area, but users have the option to pop
it out into a smaller,
On Wed, Aug 27, 2008 at 5:23 PM, Robert O'Callahan [EMAIL PROTECTED] wrote:
On Thu, Aug 28, 2008 at 9:59 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
I encounter sites frequently that want to pop out part of their
application free of the page, into a smaller window. For example,
Pandora radio
On Wed, Aug 27, 2008 at 6:46 PM, Robert O'Callahan [EMAIL PROTECTED] wrote:
Works on Firefox trunk :-). Testcase attached. (The Vorbis file takes a
while to download so you should probably let it play through once before
trying the test.)
What is the rationale behind having to call play()
On Wed, Aug 13, 2008 at 11:50 AM, Shannon [EMAIL PROTECTED] wrote:
The WebWorkers implementation (scary! hide your children!!):
--- worker.js ---
updateGlobalLa = function (e) {
var localLa = someLongRunningFunction( e );
workerGlobalScope.port.postMessage(set la = + localLa);
}
On Tue, Aug 12, 2008 at 4:50 AM, Shannon [EMAIL PROTECTED] wrote:
If a WebWorker object is assigned to local variable inside a complex script
then it cannot be seen or stopped by the calling page. Should the
specification offer document.workers or getAllWorkers() as a means to
iterate over
On Tue, Aug 12, 2008 at 8:24 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
A very interesting post, too bad nobody from Google bothered to give an
exhaustive reply. Just a couple of thoughts below.
Just as an FYI, most of the Gears team is located in Mountain View
which is PST. This message
On Sun, Aug 10, 2008 at 5:54 PM, Shannon [EMAIL PROTECTED] wrote:
* each coroutine gets a real OS thread (if available).
snip
Coroutines in Lua are not operating system threads or processes.
Coroutines are blocks of Lua code which are created within Lua, and
have their own flow of control like
Some quick notes/questions...
- I think the manifest should be some structured, extensible format
such as XML or JSON. The current text-based format is going to quickly
turn into a mess as we add additional fields and rows.
- I like the fallback entry feature, but I don't understand why it is
On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 5, 2008, at 11:30 PM, Aaron Boodman wrote:
Some quick notes/questions...
- I think the manifest should be some structured, extensible format
such as XML or JSON. The current text-based format is going
a separate Worker object and
having the two-step process of creating the worker, then sending it a
message. It means that creating a new channel to a worker is always
the same.
On Mon, 4 Aug 2008, Aaron Boodman wrote:
So for example, I would be for moving over a subset of the navigator and
location
On Wed, Aug 6, 2008 at 7:08 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
HTTP caching can't promise that all the resources you load when your Web App
loads will be available offline.
But neither can this feature, since a resource is only there if the
application previously loaded it for some
On Wed, Aug 6, 2008 at 7:49 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Right, the idea is that you just have your whole web app as an opportunistic
caching namespace and make sure it loads everything it ever needs offline
the first time it loads. I don't think this is a great feature but I
On Mon, Aug 4, 2008 at 8:24 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
The overall concern is that I think the spec is unnecessarily
complicated. I'll comment in detail below on specific features. An
overall requirement for mozilla is that we are very selective about
which features are exposed
On Tue, Aug 5, 2008 at 1:12 AM, Ian Hickson [EMAIL PROTECTED] wrote:
Right now, if you navigate an iframe to a document, and take a
reference to a method defined in that document, and then navigate that
iframe to another document, and then call the method, browsers differ in
what they do.
By
I'm still digesting the Web Worker proposal, but here is some
feedback. Sorry it is a bit long.
Structural API stuff:
- I still haven't really internalized the need to either have workers
speak directly to anyone other than the person who created them, or
the other use cases that
Thanks for the quick reply...
On Tue, Aug 5, 2008 at 2:52 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
I know this is weird wrt GC when combined with MessagePorts, and I
don't have a proposed solution.
I don't think we should say much regarding GC at all. All we should say is
that GC should
It seems like you need a way to abort an in-progress transaction. An
easy way to do this would be to add an abort() method to
SQLTransaction.
Thoughts?
- a
I think this has been covered in passing before, but I wanted to bring
it up explicitly.
Currently, the database API has an error code for the situation where
you open a transaction for read, then try to write but the database is
locked.
I think that the spec should at least suggest, but perhaps
Wh!
How about:
- synchronous network access
- storage access in general
- synchronous db access
- access to a subset of the capabilities from the window.location
object, for example the href property and the reload method. We
have found that some workers want to reload themselves when they
On Fri, Jun 27, 2008 at 2:04 PM, Brady Eidson [EMAIL PROTECTED] wrote:
Second: void makeStandalone();
I think one disadvantage of this approach is that it can only be
called in response to a user action if you want to avoid it being used
to annoy or spam. It's unfortunate to have an API that
I noticed one unfortunate thing about the new Database API. Because
the executeSql() callback holds open the transaction, it is easy to
accidentally do intensive work inside there and hold open the
transaction too long. A common mistake might be to do a big select and
then hold open the
On Fri, May 9, 2008 at 12:37 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Fri, 09 May 2008 03:34:21 +0100, Aaron Boodman [EMAIL PROTECTED] wrote:
I agree that mismatches will occur in the real world. I think it can
be left to the UA as to what to do in that case, as it is a developer
On Thu, May 8, 2008 at 7:29 PM, Ernest Cline [EMAIL PROTECTED] wrote:
No matter what the spec says, I think we can all agree that once this enters
the real world there will be times when the icon size given is wrong. So
what to do? At a minimum, I think the behavior called for when dealing
On Wed, May 7, 2008 at 7:17 PM, Ian Hickson [EMAIL PROTECTED] wrote:
I've added a sizes attribute to link for the icon keyword. It takes
a space separated list of keywords consisting of two integers separated by
an x or the keyword any.
Cool. Thanks for being so responsive on this.
- a
On Mon, May 5, 2008 at 1:57 PM, Kornel Lesinski [EMAIL PROTECTED] wrote:
There isn't much bandwidth to be saved. These icons are going to be
downloaded only once. 128x128 PNG icons take only 20-30kb.
Without hints as to which file contains which size, the user agent
must download up to four
On Sat, May 3, 2008 at 5:38 PM, Ernest Cline [EMAIL PROTECTED] wrote:
Perhaps, but it means adding attributes to link elements that will only be
needed for a single link type. If the use case for these attributes is
strong enough to add special purpose attributes for use with only link
On Sat, May 3, 2008 at 8:13 AM, fantasai [EMAIL PROTECTED] wrote:
Maciej Stachowiak wrote:
By contrast, I do not know of any actual need to determine the aspect
ratio of an SVG icon or the duration of a sound icon. I do not know of cases
where HI guidelines for particular platforms would
On Wed, Apr 30, 2008 at 11:32 AM, Brady Eidson [EMAIL PROTECTED] wrote:
Since this is obviously a topic that has sparked a tad of passionate
interest and there's not necessarily a clear solution that doesn't make
link ugly, what are people's thoughts on adding a new element for icon
badging,
On Tue, Apr 29, 2008 at 6:52 PM, Ian Hickson [EMAIL PROTECTED] wrote:
This is a proposal to add height and width attributes to link
specifically for the case of rel=icon, so that authors can provide
multiple icons and let the UA decide which to use based on their size
(without having to
On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Maciej Stachowiak wrote:
- Processing a reply synchronously is awkward in any case, since you need
a callback.
I'm not sure I follow this argument, I actually come to the opposite
conclusion.
Say that a page is
On Thu, Apr 17, 2008 at 7:22 PM, Ojan Vafai [EMAIL PROTECTED] wrote:
IMO, the tradeoff is still worth it, though. And in the future, with
something like Hixie's messaging proposal, this problem will go away
(because you'll have stateful objects that represent a conversation).
I don't
On Thu, Apr 10, 2008 at 9:53 AM, Dimitri Glazkov
[EMAIL PROTECTED] wrote:
Doh! I apologize. This has not been one of my shiniest moments.
In addition to what Aaron says, I actually meant the reverse: only
name and version being required (potentially with version optional, as
he suggests),
1 - 100 of 153 matches
Mail list logo
