On 2011-06-29 18:34, Alfonso Martínez de Lizarrondo wrote:
...
No.
All I want is a way for the web page to state that when a Blob is used
in a FormData object it should be send to the server with a proposed
filename. No sniffing. No guessing. It's up to the script to suggest a
correct filename
I thought that the browser could retrieve that info from the os based on the
proposed extension.
I just requested the part that I needed, if there's something else missing
then I guess that it should be possible to add it at the same time.
El 30/06/2011 09:28, Julian Reschke julian.resc...@gmx.de
On 2011-06-30 09:54, Alfonso Martínez de Lizarrondo wrote:
I thought that the browser could retrieve that info from the os based on
the proposed extension.
1) the OS may not know
2) it also needs to be sent over the wire some way...
I just requested the part that I needed, if there's
On Wed, 29 Jun 2011 20:17:52 +0200, Jonas Sicking jo...@sicking.cc wrote:
Just a small nit: We would also use blob for File objects with an
empty .name property, right?
I guess we can do that. getFile() should also specify a media type by the
way.
--
Anne van Kesteren
On Wed, 29 Jun 2011 23:54:47 +0200, Rafael Weinstein rafa...@google.com
wrote:
On Wed, Jun 29, 2011 at 7:13 AM, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sicking jo...@sicking.cc wrote:
This new proposal solves both these by making all the
On 29 Jun 2011, at 12:34, Marcos Caceres wrote:
On Wed, Jun 29, 2011 at 12:08 PM, Charles McCathieNevile
cha...@opera.com wrote:
On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
I think Bruce Lawson was dropping a big hint the other day to look again
On Thu, Jun 30, 2011 at 2:11 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wednesday, June 29, 2011, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sicking jo...@sicking.cc wrote:
This new proposal solves both these by making all the modifications
As Cameron indicated in [1], all non-enhancements bugs for Web IDL are
now resolved and as such, this is a Call for Consensus to publish a Last
Call Working Draft of Web IDL:
http://dev.w3.org/2006/webapi/WebIDL/
This CfC satisfies the group's requirement to record the group's
decision to
On 06/30/2011 12:54 AM, Rafael Weinstein wrote:
On Wed, Jun 29, 2011 at 7:13 AM, Aryeh Gregorsimetrical+...@gmail.com wrote:
On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sickingjo...@sicking.cc wrote:
This new proposal solves both these by making all the modifications
first, then firing all the
On Jun 29, 2011, at 16:33 , Arthur Barstow wrote:
Robin - what is the status and plan for the Widget URI spec?
http://dev.w3.org/2006/waf/widgets-uri/
The status is that it's hanging on URI scheme registration. I'm afraid that I
simply don't have the bandwidth to handle that at this point.
On Jun 4, 2009, at 12:07 , Jonas Sicking wrote:
Here's an API that might work:
The following methods are added to the Document, Element and
DocumentFragment interfaces:
addAttributeChangedListener(NodeDataCallback);
addSubtreeAttributeChangedListener(NodeDataCallback);
Arthur Barstow wrote:
Richard, Marcos - what is the plan to get Widget Updates spec LC ready
(see [1] for LC requirements)?
http://dev.w3.org/2006/waf/widgets-updates/
I think Marcos wanted to have a pass over the spec. We didn't receive
much feedback on the previous Working Draft and we've
Given the lack of support for stopping work on Web Storage [1], I'd let
to get consensus on the plan to move it to Last Call Working Draft.
Currently there are two open bugs:
1. Bug 12111: spec for Storage object getItem(key) method does not
match implementation behavior. PLH created a
Hi hi,
Is there anyone who has objections against publishing
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD.
The idea is mainly to gather more feedback to see if there is any interest
in taking this forward.
(Added public-web-security because of the potential for
On Thu, Jun 30, 2011 at 3:42 PM, Rich Tibbett ri...@opera.com wrote:
Arthur Barstow wrote:
Richard, Marcos - what is the plan to get Widget Updates spec LC ready
(see [1] for LC requirements)?
http://dev.w3.org/2006/waf/widgets-updates/
I think Marcos wanted to have a pass over the spec.
On Tue, Jun 28, 2011 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
1. DOMNodeRemoved is fired *before* a mutation takes place. This one's
tricky since you have to figure out all the removals you're going to
do, then fire events for them, and then hope that the mutations
actually still
On Jun 30, 2011, at 7:22 AM, Anne van Kesteren wrote:
Hi hi,
Is there anyone who has objections against publishing
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD. The
idea is mainly to gather more feedback to see if there is any interest in
taking this forward.
The comment period for the 7-June-2011 LCWD of the Widget Packaging and
XML Configuration spec ended with no comments and as documented in the
spec's Implementation Report [ImplRept], there are 4 implementations
that pass 100% of the test suite. As such, this is Call for Consensus to
publish a
The comment period for the 7-June-2011 LCWD of the Widget Digital
Signature spec ended with no comments and as documented in the spec's
Implementation Report [ImplRept], there are 2 implementations that pass
100% of the test suite's Mandatory feature tests. As such, this is Call
for Consensus
client to send server ping as per websocket spec
2) onpong(); //allow client to receive response of ping
Posted from: 65.5.190.254
User agent: Mozilla/5.0 (X11; Linux i686; rv:7.0a1) Gecko/20110630
Firefox/7.0a1
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
Hi Maciej!
First off, I really appreciate your willingness to get into the mix of
things. It's a hard problem and I welcome any help we can get to solve
it.
I also very much liked your outline of encapsulation and I would like
to start using the terminology you introduced.
I am even flattered
On Jun 29, 2011, at 9:08 AM, Dimitri Glazkov wrote:
Hi Folks!
With use cases (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases)
So I looked at this list of use cases. It seems to me almost none of these are
met by the proposal at http://dglazkov.github.com/component-model/dom.html.
On Jun 30, 2011, at 10:57 AM, Dimitri Glazkov wrote:
Hi Maciej!
First off, I really appreciate your willingness to get into the mix of
things. It's a hard problem and I welcome any help we can get to solve
it.
I also very much liked your outline of encapsulation and I would like
to
[Callback, NoInterfaceObject]
interface MutationCallback
{
// aNode is the node to which the listener was added.
// aChangeTarget is the node in which the mutation was made.
void handleMutation(in Node aNode, in Node aChangeTarget);
};
Won't the callback be invoked as if it were a
Aryeh Gregor wrote:
Maybe this is a stupid question, since I'm not familiar at all with
the use-cases involved, but why can't we delay firing the
notifications until the event loop spins? If we're already delaying
them such that there are no guarantees about what the DOM will look
like by the
On 06/30/2011 09:36 PM, David Flanagan wrote:
[Callback, NoInterfaceObject]
interface MutationCallback
{
// aNode is the node to which the listener was added.
// aChangeTarget is the node in which the mutation was made.
void handleMutation(in Node aNode, in Node aChangeTarget);
};
Won't the
On 30 Jun 2011, at 14:55, Arthur Barstow wrote:
Given the lack of support for stopping work on Web Storage [1], I'd let to
get consensus on the plan to move it to Last Call Working Draft.
Currently there are two open bugs:
1. Bug 12111: spec for Storage object getItem(key) method does
On 6/30/11 2:56 PM, David Flanagan wrote:
I'll add my own possibly stupid question... Can we go in the opposite
direction and fire mutation events immediately without queuing, but
forbid any DOM modifications from the event callbacks?
Forbid DOM modifications to all DOMs? Or just one DOM? Is
Maciej, as promised on #whatwg, here's a more thorough review of your
proposal. I am in agreement in the first parts of your email, so I am
going to skip those.
== Are there other limitations created by the lack of encapsulation? ==
My understanding is yes, there are some serious limitations:
On 6/30/11 12:26 PM, Boris Zbarsky wrote:
On 6/30/11 2:56 PM, David Flanagan wrote:
I'll add my own possibly stupid question... Can we go in the opposite
direction and fire mutation events immediately without queuing, but
forbid any DOM modifications from the event callbacks?
Forbid DOM
On Tuesday, June 28, 2011 7:31 PM, Jonas Sicking wrote:
On Tue, Jun 28, 2011 at 4:59 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Tuesday, June 28, 2011 12:49 PM, Jonas Sicking wrote:
On Tue, Jun 28, 2011 at 10:53 AM, Israel Hilerio
isra...@microsoft.com
wrote:
On Monday, June
On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote:
Maciej, as promised on #whatwg, here's a more thorough review of your
proposal. I am in agreement in the first parts of your email, so I am
going to skip those.
== Are there other limitations created by the lack of encapsulation? ==
My
On 6/30/11 4:15 PM, David Flanagan wrote:
Forbid DOM modifications to all DOMs? Or just one DOM?
Is it clearer is I say forbid any modifications to the document tree?
There are multiple document trees around is the point.
It would be nice to only lock the document tree in which the mutation
On Thu, Jun 30, 2011 at 1:15 PM, David Flanagan dflana...@mozilla.comwrote:
This is actually a pretty hard problem to solve, and still wouldn't really
solve the performance issues for DOM events
Still better than current DOM Mutation event, though right? Are you saying
that synchronous
On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote:
Maciej, as promised on #whatwg, here's a more thorough review of your
proposal. I am in agreement in the first parts of your email, so I am
going to skip those.
On Jun 30, 2011, at 2:07 PM, Dimitri Glazkov wrote:
On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote:
In the case of extending elements with native shadow DOM, you have to
use composition or have something like
On Thu, Jun 30, 2011 at 1:19 PM, Israel Hilerio isra...@microsoft.com wrote:
On Tuesday, June 28, 2011 7:31 PM, Jonas Sicking wrote:
On Tue, Jun 28, 2011 at 4:59 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Tuesday, June 28, 2011 12:49 PM, Jonas Sicking wrote:
On Tue, Jun 28, 2011 at
On Thu, Jun 30, 2011 at 1:15 PM, David Flanagan dflana...@mozilla.comwrote:
avoid the need to maintain a list of pending callbacks.
Yeah, this is one reason I like Rafael's proposal of having a list of
mutations. In many editing apps, you want to get a list of mutation events
for each editing
On Thu, Jun 30, 2011 at 2:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 30, 2011, at 2:07 PM, Dimitri Glazkov wrote:
On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote:
In the case of extending elements with
On 6/30/11 5:45 PM, Dimitri Glazkov wrote:
There's a very interesting distinction here. You don't attach
components to DOM elements. DOM elements _are_ components. The only
way to make a component is by sub-classing it from an existing
element. In this case, there is no distinction between
On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/11 5:45 PM, Dimitri Glazkov wrote:
There's a very interesting distinction here. You don't attach
components to DOM elements. DOM elements _are_ components. The only
way to make a component is by sub-classing it
On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/11 5:45 PM, Dimitri Glazkov wrote:
There's a very interesting distinction here. You don't attach
components to DOM elements. DOM elements _are_ components. The only
way to make a component is by sub-classing it
On 6/29/11, Dimitri Glazkov dglaz...@chromium.org wrote:
Hi Folks!
With use cases (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases)
firmed up, and isolation
(http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0900.html),
inheritance
Perhaps the right solution is to require inherited and disallow
access to shadow DOM tree if the sub-class is not overriding the
subtree?
:DG
On 6/30/11 6:04 PM, Dimitri Glazkov wrote:
Perhaps the right solution is to requireinherited and disallow
access to shadow DOM tree if the sub-class is not overriding the
subtree?
I don't know. First, I'm not sure what problem we're solving. Second,
I'm not sure what inherited does
On 6/30/11 1:45 PM, James Robinson wrote:
On Thu, Jun 30, 2011 at 1:15 PM, David Flanagan dflana...@mozilla.com
mailto:dflana...@mozilla.com wrote:
This is actually a pretty hard problem to solve, and still
wouldn't really solve the performance issues for DOM events
On Thu, Jun 30, 2011 at 1:35 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The point of my proposal was to guarantee that mutation events are
delivered when the tree is in its freshly-mutated state and avoid the
need to maintain a list of pending callbacks.
That would be nice; the problem is
On 6/30/11 6:33 PM, Ryosuke Niwa wrote:
I think most developers are concerned with paint to avoid flickering and
not so much about layout.
I meant from the implementation's point of view. E.g. if a node is
partially inserted into the DOM, is it OK to trigger layout? The answer
may depend
On Thu, Jun 30, 2011 at 3:55 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/11 6:33 PM, Ryosuke Niwa wrote:
I think most developers are concerned with paint to avoid flickering and
not so much about layout.
I meant from the implementation's point of view. E.g. if a node is
partially
On Wed, Jun 29, 2011 at 6:11 PM, Jonas Sicking jo...@sicking.cc wrote:
Maybe this is a stupid question, since I'm not familiar at all with
the use-cases involved, but why can't we delay firing the
notifications until the event loop spins? If we're already delaying
them such that there
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 06/30/2011 12:54 AM, Rafael Weinstein wrote:
On Wed, Jun 29, 2011 at 7:13 AM, Aryeh Gregorsimetrical+...@gmail.com
wrote:
On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sickingjo...@sicking.cc wrote:
This new proposal
On Thu, Jun 30, 2011 at 5:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/11 7:01 PM, Ryosuke Niwa wrote:
What do you mean by it being partially inserted? Like document
relationship, etc... aren't consistent?
That would be one example, yes. Firing mutation events as you go involves
On Tue, Jun 21, 2011 at 10:17 AM, Arun Ranganathan a...@mozilla.com wrote:
**
Sorry if these have all been discussed before. I just read the File API for
the first time and 2 random questions popped in my head.
1) If I'm using readAsText with a particular encoding and the data in the
file
On Fri, Jul 1, 2011 at 7:01 AM, Dimitri Glazkov dglaz...@google.com wrote:
On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/11 5:45 PM, Dimitri Glazkov wrote:
There's a very interesting distinction here. You don't attach
components to DOM elements. DOM
On 6/30/11 9:31 AM, Maciej Stachowiak wrote:
On Jun 30, 2011, at 7:22 AM, Anne van Kesteren wrote:
(Added public-web-security because of the potential for doing
this in CSP instead. Though that would require a slight change
of scope for CSP, which I'm not sure is actually desirable.)
I
55 matches
Mail list logo
