On Tue, 14 Sep 2010 20:19:27 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 14, 2010 at 11:04 AM, Anne van Kesteren ann...@opera.com
wrote:
So in terms of HTML5 the above would invoke Constructing the form data
set (defined in HTML5) for the HTMLFormElement passed as parameter and
Just to follow up on this one more time with regards to the current state
of the specification.
On Sat, 13 Feb 2010 02:32:18 +0100, Jonas Sicking jo...@sicking.cc wrote:
First of all, I assume that it is intended that a FromData object can
be submitted several times. I.e. that the following
On Mon, Feb 7, 2011 at 8:09 PM, Jeremy Orlow jor...@chromium.org wrote:
We're currently implementing the onblocked/setVersion semantics and ran into
an interesting problem: if you don't call .close() on a database and simply
expect it to be collected, then you ever being able to run a
On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote:
We do that as well.
What's the best way to do it API wise? Do we need to
The only solution I can think of is to require (or recommend) that
implementations run the garbage collector in a context after firing
the versionchange event if the database still isn't closed. This
should be a rare occurrence simply because setVersion should be rare.
That would be a hack
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote:
The only solution I can think of is to require (or recommend) that
implementations run the garbage collector in a context after firing
the versionchange event if the database still isn't closed. This
should be a rare
On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote:
The only solution I can think of is to require (or recommend) that
implementations run the garbage collector in a context after firing
the versionchange
On Tue, Feb 8, 2011 at 3:20 AM, João Eiras joao.ei...@gmail.com wrote:
On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote:
The only solution I can think of is to require (or recommend) that
On Tue, Feb 8, 2011 at 3:26 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 3:20 AM, João Eiras joao.ei...@gmail.com wrote:
On Tue, Feb 8, 2011 at 10:52 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 2:45 AM, João Eiras joao.ei...@gmail.com wrote:
The only
Unless by certain GC behavior mean
I referred to
# The only solution I can think of is to require (or recommend) that
implementations run the garbage collector
The GC is transparent and a spec cannot expect that it runs at
specific times or demand it.
Why not just expand our list of error codes to have multiple ABORT_
variants for each situation, and then always fire the abort event
with a slightly different errorCode?
That seems far simpler IMO.
-Ben
On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 7, 2011
On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jan 28, 2011 at 4:33 PM, Jeremy Orlow jor...@chromium.org
wrote:
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote:
Unless by certain GC behavior mean
I referred to
# The only solution I can think of is to require (or recommend) that
implementations run the garbage collector
The GC is transparent and a spec cannot expect that it
Hi, folks-
(BCC public-webapps, public-html. Apologies for the cross-post)
Various people in various groups (as well as the community at large)
have been emphasizing the need for fullscreen functionality. In the SVG
WG, we had discussed the ability to make the root element fullscreen
(this
On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote:
Unless by certain GC behavior mean
I referred to
# The only solution I can think of is to require (or recommend) that
implementations run the
Nathan wrote:
Marcos Caceres wrote:
On 9/16/10 6:10 PM, Nathan wrote:
Marcos Caceres wrote:
As above. I thought that was what we (Web Apps WG - Widgets) have been
doing for the last 5 years?
Maybe I've missed part of the specifications - are you telling me that I
can package up an
On Tue, Feb 8, 2011 at 9:16 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 7, 2011 at 8:05 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 7, 2011 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote:
On
On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote:
Unless by certain GC behavior mean
I referred to
# The only
Hi Tim,
In [1], it sounds to me like you are after W3C Widgets [2]; we have
almost finished standardizing them so no need to wait.
You can play with them today in Opera [3] and a bunch of other great
runtimes [4].
Kind regards,
Marcos
[1]
On Tue, Feb 8, 2011 at 6:14 PM, Doug Schepers schep...@w3.org wrote:
Hi, folks-
(BCC public-webapps, public-html. Apologies for the cross-post)
Various people in various groups (as well as the community at large) have
been emphasizing the need for fullscreen functionality. In the SVG WG,
The main idea is here in bugzilla:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c4
I'll post it here though since Doug said this might get more people to see it.
The idea would be to allow the browser to capture, as in lock the mouse to a
certain DOM region such as a canvas tag. Thinking
I think that's what Ben was suggesting.
Yes. We already have ABORT_ERR, no reason we can't subdivide that
since it's being overloaded. In fact I think it makes perfect sense.
Add the following to IDBTransaction:
I'm really not a fan of making IDBTransaction more complicated. We
already have a
I'm actually fine with keeping the setVersion from proceeding until
the old database is collected. First, this is probably a bug in the
web page, and the page should be fixed. Second, the new database that
is waiting for setVersion to proceed will get an onblocked event, so
the page should know
Hi Andrey,
I'll try to look into this this week. We've also updated the test suite
to address the issues you outlined in your previous email. I've also
updated the spec so the that vendors can define their own transform
(instead of forcing 1.1).
On 2/2/11 7:34 AM, Andrey Nazarov wrote:
On Tue, Feb 8, 2011 at 11:37 AM, ben turner bent.mozi...@gmail.com wrote:
I think that's what Ben was suggesting.
Yes. We already have ABORT_ERR, no reason we can't subdivide that
since it's being overloaded. In fact I think it makes perfect sense.
That part of the spec seems completely
2011/2/8 Jeremy Orlow jor...@chromium.org:
On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 8, 2011 at 3:36 AM, João Eiras joao.ei...@gmail.com wrote:
Unless by certain GC behavior
On 2/8/2011 11:51 AM, ben turner wrote:
I'm actually fine with keeping the setVersion from proceeding until
the old database is collected. First, this is probably a bug in the
web page, and the page should be fixed. Second, the new database that
is waiting for setVersion to proceed will get an
IE has a setCapture DOM API. We've implemented it in Gecko:
https://developer.mozilla.org/en/DOM/element.setCapture
Rob
--
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what
On Tue, Feb 8, 2011 at 7:49 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Feb 9, 2011 at 7:53 AM, João Eiras joao.ei...@gmail.com wrote:
Detecting fullscreen is something that belong 100% to media queries.
Opera for instance, applies the projection media when the web page
is
On 8 Feb 2011, at 18:48, Marcos Caceres wrote:
Hi Tim,
In [1], it sounds to me like you are after W3C Widgets [2]; we have almost
finished standardizing them so no need to wait.
You might also find this post useful:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12016
Summary: After page unload, all IDBDatabases attached to the
document should have .close() called on them
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
On Wed, Feb 9, 2011 at 9:12 AM, João Eiras joao.ei...@gmail.com wrote:
On Tue, Feb 8, 2011 at 7:49 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
The :full-screen-document pseudo-class could be replaced with a media
query,
and that's probably a good idea. Thanks! The :full-screen
On Tue, Feb 8, 2011 at 3:12 PM, João Eiras joao.ei...@gmail.com wrote:
Regarding the web page requesting full screen access, I regard it as
dangerous, disruptive and unnecessary.
It's only dangerous or disruptive if implemented carelessly. It's simply
false to claim it's unnecessary.
-
This API doesn't handle all of the desired use cases. In particular,
to implement Quake-style mouse look (needed for e.g.
http://code.google.com/p/quake2-gwt-port/) it needs to work when the
mouse button is up, not just down.
-Ken
On Tue, Feb 8, 2011 at 12:11 PM, Robert O'Callahan
On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow jor...@chromium.org wrote:
I talked it over with Darin (Fisher), and he largely agreed with you guys.
I'll file a bug saying that after unload, all IDBDatabases attached to that
On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow jor...@chromium.org wrote:
I talked it over with Darin (Fisher), and he largely agreed with you guys.
I'll file a bug saying that after unload, all IDBDatabases attached to that
On Tue, Feb 8, 2011 at 5:49 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
This API doesn't handle all of the desired use cases. In particular,
to implement Quake-style mouse look (needed for e.g.
(Not sure how to reply to a mailing list with yahoo mail so this might not work
or it might)
On Tue, Feb 8, 2011 at 5:49 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Feb 9, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
This API doesn't handle all of the desired use
On Tue, Feb 8, 2011 at 8:54 PM, Kenneth Russell k...@google.com wrote:
How would you satisfy that use-case without enabling abusive behavior by
Web
sites?
Per the proposal posted earlier and at
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 :
1. Only enable mouse capture in response
On Tue, Feb 8, 2011 at 10:27 PM, Charles Pritchard ch...@jumis.com wrote:
- It's a major break from the normal event model. Merely defining an
event shouldn't cause side-effects.
This proposal seems to say that mouse capture is enabled by adding an event
handler to an element. I don't
On 2/8/2011 8:03 PM, Glenn Maynard wrote:
On Tue, Feb 8, 2011 at 10:27 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
- It's a major break from the normal event model. Merely
defining an event shouldn't cause side-effects.
This proposal seems to say that
41 matches
Mail list logo
