On Thu, Oct 27, 2011 at 11:28 AM, Ojan Vafai wrote:
> On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote:
>>
>> On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote:
>>
>> > The same is true for having apply and reapply. Jonas wanted to get rid
>> > of
>> > reapply altogether and just have
>> >
On Wed, Oct 26, 2011 at 9:06 PM, Ryosuke Niwa wrote:
> On Wed, Oct 26, 2011 at 8:21 PM, Jonas Sicking wrote:
>>
>> Why is it problematic to move an element with an undoManager from one
>> document to another. If all the data that the undomanager needs lives
>> in
On Wed, Oct 26, 2011 at 10:57 AM, Aryeh Gregor wrote:
>>> 15) Is the isReapply parameter to apply() needed? The only place I
>>> see where it's used is if the author specifies a manual transaction
>>> but leaves off a reapply() method. In that case, why not just call
>>> apply() with no extra pa
On Wed, Oct 26, 2011 at 11:39 AM, Ryosuke Niwa wrote:
> On Wed, Oct 26, 2011 at 10:57 AM, Aryeh Gregor wrote:
>>
>> >> 2) What happens if you have an Element with the undoscope attribute
>> >> that doesn't descend from a Document? Does undo management make any
>> >> sense in that case, or should
On Wed, Oct 26, 2011 at 10:13 AM, Ryosuke Niwa wrote:
>> 2) What happens if you have an Element with the undoscope attribute
>> that doesn't descend from a Document? Does undo management make any
>> sense in that case, or should the undoscope attribute have no effect
>> for detached elements?
>
>
>
>
> Regards,
> Erc
>
>
> On Tue, Oct 25, 2011 at 1:43 AM, Jonas Sicking wrote:
>>
>> On Mon, Oct 24, 2011 at 12:22 PM, Jonas Sicking wrote:
>> > On Mon, Oct 24, 2011 at 10:14 AM, Eric Sh. wrote:
>> >> On 23/10/2011 08:35, Jonas Sicking wrot
On Mon, Oct 24, 2011 at 12:22 PM, Jonas Sicking wrote:
> On Mon, Oct 24, 2011 at 10:14 AM, Eric Sh. wrote:
>> On 23/10/2011 08:35, Jonas Sicking wrote:
>>> We added support for this in firefox, so you can get the behavior you
>>> want there in the meantime (I forget w
On Mon, Oct 24, 2011 at 10:14 AM, Eric Sh. wrote:
> On 23/10/2011 08:35, Jonas Sicking wrote:
>> We added support for this in firefox, so you can get the behavior you
>> want there in the meantime (I forget what we called the attribute
>> though).
>
> I don't
On Sun, Oct 23, 2011 at 8:50 PM, Mark Callow wrote:
> On 23/10/2011 08:35, Jonas Sicking wrote:
>
> We added support for this in firefox, so you can get the behavior you
> want there in the meantime (I forget what we called the attribute
> though).
>
> Is there a way for t
On Sat, Oct 22, 2011 at 3:48 PM, Eric Sh. wrote:
> I was trying out the HTML5 context menu in firefox and I saw that there is
> no way(in the specs) to create an empty menu with only selected context menu
> items in it.
>
> So for example if I have an image element and I want to create a context
>
On Thu, Oct 6, 2011 at 9:11 AM, Adam Barth wrote:
> On Thu, Oct 6, 2011 at 8:45 AM, Odin Hørthe Omdal wrote:
>> On Thu, 06 Oct 2011 17:05:29 +0200, Adam Barth wrote:
>>
>>> The reason it's implemented like that is because I didn't add any new
>>> security checks. I just expanded the canvas tain
On Thu, Sep 29, 2011 at 12:32 AM, Matias wrote:
>
> On 29 sep 2011, at 02:25, Jonas Sicking wrote:
>
>>> OK, I understand... so is there a reason not to have a method for
>>> triggering the display of validation errors in addition to triggering a
>>> click o
On Wed, Sep 28, 2011 at 6:56 AM, Matias wrote:
> Hi Mounir and sorry for the late reply,
>
>>> 1) Is there a reason why native form validation seems to be tied to the
>>> click of the submit button? Submitting the form using JavaScript does not
>>> seem to trigger HTML5 form validation in either
On Mon, Sep 26, 2011 at 11:48 AM, Boris Zbarsky wrote:
> On 9/26/11 2:09 PM, Tyler Close wrote:
>> I suggest fixing this problem by adding a new
>> readonly DOMString that contains the correct origin for the
>> postMessage invocation; perhaps document.origin.
>
> I would be somewhat in favor of th
On Mon, Sep 12, 2011 at 6:06 PM, Ryosuke Niwa wrote:
> On Mon, Sep 12, 2011 at 5:19 PM, Jonas Sicking wrote:
>>
>> Could you please supply an example where the apply/reapply split leads
>> to cleaner or otherwise better code than using a boolean argument?
>
> apply:
On Sat, Sep 10, 2011 at 7:01 PM, Ryosuke Niwa wrote:
> On Tue, Aug 30, 2011 at 7:22 PM, Jonas Sicking wrote:
>>
>> I'm really failing to think of a case when you'd really want to have
>> apply and reapply as separate callbacks. Even in the most trivial
>>
On Mon, Sep 12, 2011 at 1:31 PM, Ehsan Akhgari wrote:
> On 11-09-11 10:00 PM, Ryosuke Niwa wrote:
>>
>> On Tue, Aug 30, 2011 at 12:15 PM, Ryosuke Niwa wrote:
>>>
>>> 4. Jonas requested that we have manualTransact and managedTransact
>>> instead
>>> of single transact on undoManager for clarity.
On Fri, Sep 2, 2011 at 10:00 AM, Ryosuke Niwa wrote:
>
> On Fri, Sep 2, 2011 at 8:31 AM, Jonas Sicking wrote:
>>
>> On Thursday, September 1, 2011, Ryosuke Niwa wrote:
>> > On Thu, Sep 1, 2011 at 6:56 PM, James Robinson
>> > wrote:
>> >>
>>
On Thursday, September 1, 2011, Ryosuke Niwa wrote:
> On Thu, Sep 1, 2011 at 6:56 PM, James Robinson wrote:
>>
>> What is the expected behavior for nodes in iframes? IOW, with this sort
of
>> DOM:
>>
>>
>>
>>
>>
>>
>
> Let me first assume that you meant #a is in body, #b is somewher
On Thu, Sep 1, 2011 at 6:56 PM, James Robinson wrote:
> On Thu, Sep 1, 2011 at 1:39 AM, Anne van Kesteren wrote:
>
>> On Thu, 01 Sep 2011 00:18:26 +0200, Erik Arvidsson
>> wrote:
>>
>>> After thinking more about this we believe that moving contains to Node
>>> is a better alternative. The proble
On Thu, Sep 1, 2011 at 6:26 AM, Alex Vincent wrote:
> 3. I just spotted a flaw in our API's. Imagine the following:
> -
>
> myEditor.undoManager.transact({apply: function () {
> insert(document.createTextNode('o')) }, label: 'First transaction'});
> myEditor.undoManager.transact(
On Tue, Aug 30, 2011 at 10:49 PM, Anne van Kesteren wrote:
> On Tue, 30 Aug 2011 21:04:09 +0200, Ryosuke Niwa wrote:
>>
>> I've updated my document: https://rniwa.com/editing/undomanager.html
>>
>> I clarified which object it should return and also moved undoManager idl
>> attribute from Element/
On Tue, Aug 30, 2011 at 12:30 PM, Ryosuke Niwa wrote:
> On Tue, Aug 30, 2011 at 12:21 PM, Ehsan Akhgari wrote:
>
>> On 11-08-30 3:15 PM, Ryosuke Niwa wrote:
>>
>>> 1. Should Transaction have reapply property or not? It appears that
>>> some
>>>
>>> of us (e.g. me, Annie, Alex) want it for
On Tue, Aug 30, 2011 at 11:55 AM, Ehsan Akhgari wrote:
> On 11-08-30 12:23 PM, Aryeh Gregor wrote:
>>
>> On Tue, Aug 30, 2011 at 12:12 PM, Ryosuke Niwa wrote:
>>>
>>> Mn... I've never had that problem. e.g. .net framework uses the term
>>> "managed code" to mean the code that's garbage-collected
On Mon, Aug 29, 2011 at 11:32 PM, Anne van Kesteren wrote:
> On Tue, 30 Aug 2011 03:49:48 +0200, Erik Arvidsson wrote:
>>
>> Node inDocument seems cleaner but I'd be happy with contains moved to
>> Node so that Document could optimize this.
>
> The DOM is discussed on www-...@w3.org. This particu
On Friday, August 12, 2011, Ryosuke Niwa wrote:
> On Fri, Aug 12, 2011 at 3:11 PM, Ehsan Akhgari wrote:
>>
>> On 11-08-12 6:10 PM, Ryosuke Niwa wrote:
>>>
>>> But having authors add flag in almost all cases isn't that nice either.
>>
>> Why do you think that authors need to specify the flag in al
On Thu, Aug 11, 2011 at 2:56 PM, Ryosuke Niwa wrote:
> On Thu, Aug 11, 2011 at 2:53 PM, Ehsan Akhgari wrote:
>>
>> I think the confusion is arising because you chose to attach undoManager
>> to elements, not nodes. Note that document _is_ a node in the DOM, but it's
>> not an element. I think w
On Tue, Aug 9, 2011 at 3:29 PM, Annie Sullivan wrote:
> On Tue, Aug 9, 2011 at 6:25 PM, Jonas Sicking wrote:
>> On Tue, Aug 9, 2011 at 2:59 PM, Annie Sullivan
>> wrote:
>> > On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking wrote:
>> >>
>> >> On T
On Tue, Aug 9, 2011 at 3:11 PM, Ryosuke Niwa wrote:
> On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sicking wrote:
>> I don't think it's a matter of which use cases can or can't be solved with
>> either solution. It's pretty clear to me that all scenarios can be s
On Tue, Aug 9, 2011 at 2:59 PM, Annie Sullivan wrote:
>
>
> On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking wrote:
>>
>> On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa wrote:
>>
>> > On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking wrote:
>> >
>&g
On Tue, Aug 9, 2011 at 2:44 PM, Ryosuke Niwa wrote:
> On Tue, Aug 9, 2011 at 1:59 PM, Jonas Sicking wrote:
>
>> On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa wrote:
>>
>>> On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking wrote:
>>>
>>>> On T
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa wrote:
> On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking wrote:
>
>> On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa wrote:
>> > On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking
>> wrote:
>> >> Likewise I still
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa wrote:
> On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking wrote:
>>
>> I still see UndoManager.replace in there. I still haven't heard any use
>> cases that won't be solved better with a beforeEditingAction event (and
>
On Mon, Aug 8, 2011 at 11:22 PM, Ryosuke Niwa wrote:
> Hi everyone,
> I have updated my document on http://rniwa.com/editing/undomanager.html to
> address all responses I've got so far.
Hmm.. what changes did you make to the document? I still see
UndoManager.replace in there. I still haven't hear
On Fri, Aug 5, 2011 at 5:17 PM, Ryosuke Niwa wrote:
> On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking wrote:
>> For example in the collaborative editing case I would think that the
>> page generally wants to get a semantic understanding of the editing
>> operations so that it
On Fri, Aug 5, 2011 at 8:43 AM, Aryeh Gregor wrote:
> On Fri, Aug 5, 2011 at 1:57 AM, Jonas Sicking wrote:
>> It would make sense to me to match ES here. The main concern is of
>> course website compat. Could someone detail what the differences would
>> be compared to wha
On Fri, Aug 5, 2011 at 2:40 PM, Ryosuke Niwa wrote:
> On Fri, Aug 5, 2011 at 1:59 PM, Jonas Sicking wrote:
>>
>> > In the case of collaborative editing apps, reapply is different from
>> > apply because the backend server may have a tree of transaction history and
2011/8/3 Kornel Lesiński :
> On Wed, 03 Aug 2011 16:26:41 +0100, Tab Atkins Jr.
> wrote:
>
What do you think?
>>>
>>> Implementing this seems rather complicated for such a niche use. It also
>>> seems better to let sites handle this by themselves so these physical
>>> codes can evolve more ea
>> Why is there a need for a 'reapply' action? How is it different from
>> the 'apply' action?
>
>
> In the case of collaborative editing apps, reapply is different from apply
> because the backend server may have a tree of transaction history and may
> need to consult on demand in order to deter
On Fri, Aug 5, 2011 at 10:01 AM, Ryosuke Niwa wrote:
> On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking wrote:
>>
>> Why treat documentElement specially here? Just make the documentElement
>> *not* have a undoManager by default and have it just use it's ancestor's,
On Aug 4, 2011 5:31 PM, "Ryosuke Niwa" wrote:
>
> On Wed, Aug 3, 2011 at 2:46 PM, Anne van Kesteren
wrote:
>>
>> On Wed, 03 Aug 2011 23:40:27 +0200, Ryosuke Niwa
wrote:
>>>
>>> On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren
wrote:
If they are identical I think it is even more clear
On Wed, Aug 3, 2011 at 11:21 AM, Aryeh Gregor wrote:
> Hixie just WONTFIXed two bugs that I thought might be of interest:
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12220
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296
>
> Basically, HTML defines some algorithms for parsing integers,
On Tue, Aug 2, 2011 at 1:30 AM, Henri Sivonen wrote:
> On Fri, 2011-07-29 at 15:20 -0700, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor
>> wrote:
>> > On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking wrote:
>> >> On Fri, Jul 29,
On Sun, Jul 31, 2011 at 11:45 AM, Jeremy Keith wrote:
> The way that datalist is currently designed (and implemented) is exemplary.
> The fact that (by design) it allows authors to nest a select element within
> it that shares the same option elements means that authors can safely begin
> to us
On Fri, Jul 29, 2011 at 8:32 PM, Ian Hickson wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>>
>> I have no idea how the UA would be smart enough to figure out if
>> filtering makes sense or not based on the set of suggestions.
>
> You could do something like:
>
On Fri, Jul 29, 2011 at 4:24 PM, Ian Hickson wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson wrote:
>> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson wrote:
>
On Fri, Jul 29, 2011 at 5:17 PM, Anne van Kesteren wrote:
> On Fri, 29 Jul 2011 15:20:59 -0700, Jonas Sicking wrote:
>>
>> Ah, well, then it definitely seems like we should get rid of this
>> feature. The harm is definitely there in that it's adding a feature
>
On Tue, Jul 26, 2011 at 11:34 PM, Ryosuke Niwa wrote:
> Hi all,
> In the last couple of weeks, I've been working with developers of CKEditor,
> TinyMCE, and Google Docs to come up with new API for undo and redo.
> Why? Because undo and redo are broken on the Web today. Whenever Web apps
> try to a
On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson wrote:
>> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >>
>> >> The problem is the other way around. Wh
On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>>
>> The problem is the other way around. When wanting to show a short list
>> that should be filtered based on user input.
>
> Why would it matter if the list is filt
On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor wrote:
> On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson wrote:
>>> Looking specifically at 's ability to fall back to , I
>>> agree that it's not necessari
On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson wrote:
>> > On Mon, 2 May 2011, Jonas Sicking wrote:
>> >> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson wrote:
>&g
On Fri, Jul 29, 2011 at 9:29 AM, Ian Hickson wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> > On Mon, 9 May 2011, Mounir Lamouri wrote:
>> >>
>> >> Basically, when you want to use the datalist to suggest a few things
>> >> you might not wa
On Wed, Jul 27, 2011 at 8:37 PM, Jukka K. Korpela wrote:
> 28.07.2011 03:21, Ian Hickson wrote:
>
>> A text input field could have a number of error conditions:
>
> Indeed. Therefore it would be essential to be able to set the error message
> for _each_ check that a browser is supposed to do on th
On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson wrote:
> On Mon, 2 May 2011, Jonas Sicking wrote:
>> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson wrote:
>> >
>> > in a is completely ignored for form submission. In
>> > fact, any form element at all in is ignor
On Thu, Jul 28, 2011 at 5:54 PM, Ian Hickson wrote:
> On Tue, 3 May 2011, Jonas Sicking wrote:
>> >>
>> >> It seems to me that a simple boolean attribute and a few lines of
>> >> script solves 80% of the use cases.
>> >
>> > What boolean at
On Wed, Jul 27, 2011 at 5:21 PM, Ian Hickson wrote:
> On Fri, 29 Apr 2011, Jonas Sicking wrote:
>> On Fri, Apr 29, 2011 at 3:42 PM, Ian Hickson wrote:
>> > On Wed, 29 Dec 2010, Mounir Lamouri wrote:
>> >> On 12/29/2010 07:41 AM, Ian Hickson wrote:
>> >
On Thu, Jul 21, 2011 at 11:58 PM, Ian Hickson wrote:
> Is there any reason to use CORS here at all? It seems like the simpler
> solution would be the following:
>
> - If download="" is set, then by default trigger a download rather than a
> navigation action. (User can override via context menu
On Tue, Jul 19, 2011 at 8:07 PM, Boris Zbarsky wrote:
> On 7/19/11 9:12 PM, Ian Hickson wrote:
>>
>> Would other browser vendors be willing to change to only look at> href> in?
>
> Gecko used to implement that back when the spec said it.
>
> This caused site compat issues. See
> https://bugzilla
> I think this requirement doesn't really help us enforce endpoints
> initiate/accept WebSocket with the same configuration. Because
>
> - non-browser UAs are free to be implemented without deflate-stream
> - server developers would see/care only the wire protocol spec
Given the number of browser
On Mon, Jul 18, 2011 at 8:58 AM, Alexey Proskuryakov wrote:
>
> 17.07.2011, в 21:05, Adam Barth написал(а):
>
>> In summary, using CORS for this purpose is costly (both to
>> implementors and to authors), and I don't think it solves a real
>> security problem.
>
>
> Agreed. This feature basically
On Sun, Jul 17, 2011 at 1:05 PM, Adam Barth wrote:
> 2011/7/15 Jonas Sicking :
>> We've discussed a different solution to the same problem at mozilla.
>> The solution we discussed was allowing FileSaver to in addition to
>> taking a blob argument, allow it to take
On Sun, Jul 17, 2011 at 12:41 PM, Bjartur Thorlacius
wrote:
> Þann fös 15.júl 2011 18:39, skrifaði Jonas Sicking:
>>
>> 2011/7/14 Ian Fette (イアンフェッティ):
>> One concern which was brought up was the ability to cause the user to
>> download a file from a third party
2011/7/15 Darin Fisher :
> On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking wrote:
>>
>> 2011/7/15 Ian Fette (イアンフェッティ) :
>> > 2011/7/15 Jonas Sicking
>> >
>> >> 2011/7/14 Ian Fette (イアンフェッティ) :
>> >> > Many websites wish to offer a fi
2011/7/15 Ian Fette (イアンフェッティ) :
> 2011/7/15 Jonas Sicking
>
>> 2011/7/14 Ian Fette (イアンフェッティ) :
>> > Many websites wish to offer a file for download, even though it could
>> > potentially be viewed inline (take images, PDFs, or word documents as an
>> >
2011/7/14 Ian Fette (イアンフェッティ) :
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it
On Thu, Jul 14, 2011 at 1:16 AM, Julian Reschke wrote:
> On 2011-07-14 08:22, Jonas Sicking wrote:
>>
>> On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren
>> wrote:
>>>
>>> On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke
>>> wrote:
>>
On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren wrote:
>
> On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke
> wrote:
>>
>> Yes, but we can *define* the flag in HTML and write down what it means with
>> respect to plugin APIs.
>
> It seems much better to wait until it can actually be implem
On Mon, Jul 11, 2011 at 7:01 PM, Anant Narayanan wrote:
> Hi,
>
> Mozilla and Cisco have been working on an API for real time communication,
> which we sent out today to the W3C WebRTC working group
> (http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0010.html). It
> builds on both the WH
On Fri, Jul 8, 2011 at 9:44 AM, Ojan Vafai wrote:
> On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking wrote:
>>
>> I definitely have privacy concerns regarding a isRegistered function.
>> Such a function might be ok in some contexts, but I'd like to avoid it
>> as
I definitely have privacy concerns regarding a isRegistered function.
Such a function might be ok in some contexts, but I'd like to avoid it
as far as possible.
For example I don't think we need to think in terms of the, arguably
crappy, UI that browsers currently use. One simple improvement that
On Thu, Jun 23, 2011 at 5:09 PM, ilya goberman wrote:
> Jonas,
> It is personalized on something that we send in the URL ("cleint id" I
> mentioned below) which identifies which user's data is requested. We do not
> use cookies.
>
> Ian was kind enough to explain to me how EventSource will functio
On Sat, Jun 18, 2011 at 7:06 AM, ilya goberman wrote:
> We are a financial market data vendor streaming real-time market data.
> We currently have a cluster of servers servicing market data. These servers
> are hosted by our company and therefore have different domain from the
> client web pages d
On Mon, Jun 20, 2011 at 6:39 AM, Anne van Kesteren wrote:
> On Sat, 21 May 2011 04:48:15 +0200, Jonas Sicking wrote:
>>
>> When we designed CORS we very intentionally did not want to allow
>> "allow *" rules for resources that are loaded with user credentials
>&
On Mon, Jun 20, 2011 at 7:13 AM, Per-Erik Brodin
wrote:
> On 2011-06-20 12:53, Jonas Sicking wrote:
>>
>> Headers that the implementation adds doesn't need to be added to this
>> list. For example the "Host" header is set by the browser in almost
>>
On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen wrote:
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039
>
> It says "complete" in Firefox, "loading" in Chrome and Opera and
> "uninitialized" in IE. The spec requires "complete". readyState is
> originally an IE API. Why doesn't the
On Mon, Jun 20, 2011 at 4:06 AM, Anne van Kesteren wrote:
> On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking wrote:
>>
>> One thing to keep in mind though is that in the case of XHR, the
>> Content-Type header is often in direct control of the page, even
>&g
On Mon, Jun 20, 2011 at 3:57 AM, Anne van Kesteren wrote:
> On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking wrote:
>>
>> On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren
>> wrote:
>>>
>>> Agreed. I can add that to CORS. I already added Last-Event-ID
On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren wrote:
> On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin
> wrote:
>>
>> The Cache-Control request header used with EventSource is not in the list
>> of simple request headers and a preflight request is not really an option
>> here in my opini
On Fri, Jun 17, 2011 at 5:31 PM, ilya goberman wrote:
> I do not really understand what "specify the request to happen with
> credentials" really mean. Can someone explain or point to an example?
> My opinion is that it should be the same for the XHR and EventSource and
> should also be backward c
? See
>> http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests.
>
> Done.
>
>
> On Wed, 1 Jun 2011, Jonas Sicking wrote:
>>
>> We should probably consider adding the ability to specify if you want
>> the request to happen with or without credentials (and default
2011/6/17 Ian Hickson :
> On Fri, 17 Jun 2011, Mihai Parparita wrote:
>> On Wed, Jun 15, 2011 at 8:42 PM, Ian Hickson wrote:
>> >> Google Chrome 10 seems to fire popstate even if I open totally new
>> >> page. Firefox 4 seems to fire event only on going back/forward
>> >
>> > How are you determini
On Tue, Jun 14, 2011 at 2:00 PM, Ian Hickson wrote:
> On Fri, 11 Mar 2011, Jonas Sicking wrote:
>> On Tue, Dec 28, 2010 at 11:46 PM, Ian Hickson wrote:
>> > On Mon, 20 Sep 2010, Mounir Lamouri wrote:
>> >>
>> >> With the current specification, these
On Tue, Jun 14, 2011 at 12:11 AM, Ian Hickson wrote:
>> Furthermore, as I understand the above definitions, the spec does allow
>> to specify label and value in one step in a select element:
>>
>>
>> This is value and label
>>
>>
>> But not in a datalist, as the label is taken from the textCon
On Wed, Jun 1, 2011 at 11:23 AM, ilya goberman wrote:
>
> Can EventSource be enhanced to support cross-domain requests via
> "Access-Control-Allow-Origin" header, just like it is already done for XHR?
> See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests.
>
> I filed a request
On Tue, May 31, 2011 at 2:02 AM, Henri Sivonen wrote:
> Recently, there was discussion about changing media element state in the
> same task that fires the event about the state change so that scripts
> that probe the state can make non-racy conclusions about whether a
> certain event has fired al
On Mon, May 23, 2011 at 8:14 PM, =JeffH wrote:
> David Dahl replied..
>>
>> "Simon Heckmann" asked..
>>
>>> Why does it only handle asymmetric encryption? Something to
>>> encrypt/decrypt data with e.g. AES would be nice as well!
>>
>> I do need to add a symmetric encryption API as well, my curre
On Fri, May 20, 2011 at 10:46 AM, Gregg Tavares (wrk) wrote:
> How about updating the CORS spec so that a server can send a
> Access-Control-Allow-Origin: *
> header even when not specifically requested and the browser can then
> allow those resource to be used cross-origin where otherwise they
On Tue, May 17, 2011 at 2:25 PM, Kenneth Russell wrote:
> Last week, a proof of concept of a previously theoretical timing
> attack against WebGL was published which allows theft of cross-domain
> images' content.
>
> To address this vulnerability it appears to be necessary to ban the
> use of cro
On Thu, May 12, 2011 at 9:32 PM, Robert O'Callahan wrote:
> On Fri, May 13, 2011 at 3:19 PM, Ian Hickson wrote:
>
>> On Wed, 4 May 2011, Robert O'Callahan wrote:
>> > 4) remove the no-shadow special case, but add a special case to not draw
>> > shadows for operators other than source-over
>> >
>>
On Wed, May 11, 2011 at 3:27 PM, Jer Noble wrote:
>
> On May 11, 2011, at 3:03 PM, Jonas Sicking wrote:
>
>> On Wed, May 11, 2011 at 11:27 AM, Jer Noble wrote:
>>> 3. "fullscreenchange" events and their targets.
>>>
>>> The current pro
On Wed, May 11, 2011 at 11:27 AM, Jer Noble wrote:
> 3. "fullscreenchange" events and their targets.
>
> The current proposal states that a "fullscreenchange" event must be
> dispatched when a document enters or leaves full-screen. Additionally, "when
> the event is dispatched, if the document's
On Thursday, May 5, 2011, Hallvord R M Steen wrote:
> (Thanks to those clarifying the sync/async event question :-))
>
> 2011/5/3 Jonas Sicking :
>> Isn't the purpose of this flag mostly backwards compatibility, but
>> otherwise a fairly awkward feature. If so, it see
ike a *really* interesting idea to me. I'd love to add experimental
support for setting a property on the element directly, which
takes a JS object of some sort and builds a list out of that.
> On Mon, May 2, 2011 at 8:22 PM, Jonas Sicking wrote:
>> I'd also be worried about making
On Mon, May 2, 2011 at 5:48 PM, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 4:37 PM, Ian Hickson wrote:
>> On Wed, 5 Jan 2011, Mounir Lamouri wrote:
>>> On 01/05/2011 02:29 AM, Ian Hickson wrote:
>>> > On Thu, 14 Oct 2010, Olli Pettay wrote:
>>> >>
On Mon, May 2, 2011 at 4:37 PM, Ian Hickson wrote:
> On Wed, 5 Jan 2011, Mounir Lamouri wrote:
>> On 01/05/2011 02:29 AM, Ian Hickson wrote:
>> > On Thu, 14 Oct 2010, Olli Pettay wrote:
>> >>
>> >> may I wonder why on earth any new API, like
>> >> link.sizes uses PutForwards?
>> >> IMHO, PutForwar
On Mon, May 2, 2011 at 3:36 PM, Ian Hickson wrote:
> On Fri, 31 Dec 2010, Mounir Lamouri wrote:
>> On 12/31/2010 03:20 AM, Ian Hickson wrote:
>> > On Fri, 24 Sep 2010, Mounir Lamouri wrote:
>> >>
>> >> I agree that a child of a datalist element should not block the form
>> >> submission. However,
On Mon, May 2, 2011 at 3:32 PM, Ian Hickson wrote:
> On Fri, 31 Dec 2010, Jonas Sicking wrote:
>> >
>> > The thing that makes this different than "Google suggest"-style UI is
>> > that in the latter case you need a script that continually polls for
>&
On Sun, May 1, 2011 at 6:14 PM, Hallvord R M Steen wrote:
> Some questions related to possibly clarifying this section:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit
>
> 1) What methods exactly cause the "scripted submit" f
nsider markup
like . It's very frustrating for a user
to enter the value 1 and be told "The minimum allowed value is 3" and
then once the user adjust it to 10 get the message "10 is too high". A
much nicer experience is "A number between 3 and 7 is required".
In other words, of
301 - 400 of 1065 matches
Mail list logo
