On Thu, Aug 25, 2011 at 11:55 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney domin...@google.com wrote:
On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
All,
Adam raises an interesting question: should we allow
On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Aug 24, 2011 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote:
I agree with this, but it might be too late to make this change.
The problem is that if we returned an Array object, it would not have
a .item function,
On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchard ch...@jumis.com wrote:
Prpoposed:
FormData output with the x-www-form-urlencoded mime type:
formData.toUrlEncodedBlob(xhr.send)
If going down the blob path, these two would have the same end-result:
formData.toMultipartBlob(xhr.send)
On 25 août 2011, at 08:33, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Aug 24, 2011 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote:
I agree with this, but it might be too late to make this change.
The problem is that
On Thu, Aug 25, 2011 at 11:57 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote:
On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson
On Thu, Aug 25, 2011 at 11:58 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
Also -- we can always try to start with just one subtree, and then
enable multiple. Since the plumbing and the order specification are
trivial, it's something we can easily add.
:DG
Yes. This sounds like a good
On 8/24/11 11:36 PM, Jonas Sicking wrote:
On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchardch...@jumis.com wrote:
Prpoposed:
FormData output with the x-www-form-urlencoded mime type:
formData.toUrlEncodedBlob(xhr.send)
If going down the blob path, these two would have the same
On Thu, Aug 25, 2011 at 2:03 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
I'm still trying to digest this, but it seem pretty clear the 'confinement'
is the clear scope thing I was asking about on es-discuss. According to
that discussion, this means needs to fit with the 'modules'
On Wed, Aug 24, 2011 at 11:47 PM, Julien Richard-Foy
jul...@richard-foy.fr wrote:
On 25 août 2011, at 08:33, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Aug 24, 2011 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote:
I
Hello,
I noticed that Mozilla has started to prototype support for Joystick
events. There's some documentation on this effort
https://wiki.mozilla.org/JoystickAPI as well as a prototype
https://bugzilla.mozilla.org/show_bug.cgi?id=604039
I'm also interested in adding support for joysticks to
Here is a quick first cut:
How about use cases like these:
- Extension that wants to inspect input type=password and warn you
when you are entering you password in an insecure form (from abarth
earlier in the thread.)
- Password manager that wants to find anything that looks like a login
panel
On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
All,
Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:
* Created a general overview document for behavior attachment problem
on the Web
Hi Scott,
We should definitely open it up for a broader discussion. I think the
right place for the discussion might be the new device apis WG, which I've
cc'ed.
Thanks,
Paul
Am 24.08.11 21:23 schrieb Scott Graham unter scot...@chromium.org:
Hello,
I noticed that Mozilla has started to
Hi all,
On Aug 25, 2011, at 10:49 , Paul Bakaus wrote:
We should definitely open it up for a broader discussion. I think the
right place for the discussion might be the new device apis WG, which I've
cc'ed.
It certainly feels like such an API would find a logical home in Device APIs.
It's a
On 08/25/2011 12:54 PM, Robin Berjon wrote:
Hi all,
On Aug 25, 2011, at 10:49 , Paul Bakaus wrote:
We should definitely open it up for a broader discussion. I think
the right place for the discussion might be the new device apis WG,
which I've cc'ed.
It certainly feels like such an API would
On Aug 22, 2011, at 11:47 , James Graham wrote:
I don't really understand your point here. If you used the smaller document
presumably you could just have easily have read the relevant chapter from the
larger document.
[...snip...]
Small specs encourage people - including the spec editors -
On Thu, Aug 25, 2011 at 5:41 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
All,
Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:
* Created a
Hi,
This seems like it could fit more into the Web Events WG. In the Web Events, we
deal with touch events, which are user inputs, this seems to be in the same
category.
Thanks
Tran
-Original Message-
From: public-device-apis-requ...@w3.org
[mailto:public-device-apis-requ...@w3.org]
Also, there are some interests from our TV group to support such devices
similar to Wii Remote.
Thanks
Tran
-Original Message-
From: public-device-apis-requ...@w3.org
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Tran, Dzung D
Sent: Thursday, August 25, 2011 7:23 AM
To: Robin
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's content.
I think this omission is a big plus. XBL1 content is mysterious. If a
dev tool wants to add support for building
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's content.
It would be rather strange if one needs to explicitly construct
shadow tree after the element is created.
I know we
On Thu, Aug 25, 2011 at 8:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's content.
It would be rather strange if one needs
Thanks all,
On Thu, Aug 25, 2011 at 2:54 AM, Robin Berjon ro...@berjon.com wrote:
... That being said, if there's support for doing this work (in the form of
people willing to put in the work of writing the spec and implementers
willing to prototype and provide feedback) I'd be very happy
On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow art.bars...@nokia.com
wrote:
Hi All,
Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and I
would characterize them both as editorial [Bugs]. As such, the
redirect issue Thomas originally reported in this thread (see
On Thu, Aug 25, 2011 at 2:33 AM, Jonas Sicking jo...@sicking.cc wrote:
That works, but what is the advantage?
The same advantage as having those methods work for Array. :)
They're useful for lots of stuff.
And .push/.pop or other mutating functions wouldn't work.
Right. I'm only talking
I made these changes.
E
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-
requ...@w3.org] On Behalf Of Jonas Sicking
Sent: Monday, August 22, 2011 7:20 PM
To: Israel Hilerio
Cc: public-webapps@w3.org; Tom Bolds
Subject: Re: [indexeddb] Updates to the
Le 22 août 2011 à 05:47, James Graham a écrit :
Small specs encourage people - including the spec editors - to perceive that
features are more self-contained than they really are
Note that in some circumstances it might have some benefits in forcing
orthogonality. Our tools and cultural
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13908
Summary: WordStar semantics aren't supported
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13909
Summary: Selections have three possible directions, not two
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13910
Summary: There can never be no active range
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13911
Summary: Active range's definition relies on the context
object but there might not be one
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13913
Summary: Attributes don't have an order
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Continuing the discussion of some of the open issues I'm aware of:
-- If MouseEvent types are returned under mouse lock, what should .clientX/Y
and screenX/Y be? --
Spec as drafted states they should be the center of the target element.
That's likely a poor idea, as discussed, and a better
On Wed, Aug 24, 2011 at 5:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote:
On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org
Paddy Byers:
WAC does refer to interfaces defined in one module from another
module; however, we have not been using scoped names for these
references - we use the unqualified interface name. More or less
every WAC module does this.
Cameron McCormack:
If WAC is already considering these names
On Thu, 25 Aug 2011 16:23:19 +0200, Tran, Dzung D dzung.d.t...@intel.com
wrote:
This seems like it could fit more into the Web Events WG. In the Web
Events, we deal with touch events, which are user inputs, this seems to
be in the same category.
Yes, I also think this belongs in Web
On Mon, Aug 22, 2011 at 2:47 AM, James Graham jgra...@opera.com wrote:
On 08/22/2011 11:22 AM, Jonas Sicking wrote:
http://www.whatwg.org/specs/web-apps/current-work/complete/
I *always* used the much smaller document that used to be available here:
37 matches
Mail list logo