Re: [IndexedDB] Two Real World Use-Cases

On 01 Mar 2011, at 7:27 PM, Jeremy Orlow wrote: > 1. Be able to put an object and pass an array of index names which must > reference the object. This may remove the need for a complicated indexing > spec (perhaps the reason why this issue has been pushed into the future) and > give developers

Re: [whatwg] set input.value when input element has composition string

On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato wrote: > > On Safari 5, even if textbox has IME composition string, text into textbox > can be replaced by DOM/script. But other browser's behaviors are different, > and this is no specification when textbox has composition string. Although > IE, Chrom

Re: publish a new Working Draft of DOM Core; comment deadline March 2

On 3/1/11, Anne van Kesteren wrote: > On Mon, 28 Feb 2011 18:49:48 +0100, Garrett Smith > wrote: >> | DOM Core defines the event and document model the Web platform uses. >> >> That says that DOM Core defines two different things: events and DOM. >> Some things might implement DOM Events Core (or

Re: Cross-Origin Resource Embedding Restrictions

On 3/1/11 12:26 AM, Adam Barth wrote: > From-Origin is closely related to one of the proposed CSP > features, namely frame-ancestors, which also controls how the > given resource can be embedded in other documents: Also similar to X-Frame-Options; I'd hate to end up with all three mechanisms. I'd

Re: publish a new Working Draft of DOM Core; comment deadline March 2

On Tue, 1 Mar 2011, Anne van Kesteren wrote: > On Sat, 26 Feb 2011 16:15:25 +0100, Doug Schepers wrote: > > > > I would still like to help edit that specification, to bring a > > slightly different perspective and approach, and to coordinate between > > DOM3 Events and DOM Core, and I believe w

Re: [DOMCore] fire and dispatch

On Tue, 1 Mar 2011, Aryeh Gregor wrote: > On Tue, Mar 1, 2011 at 8:51 AM, Boris Zbarsky wrote: > > The big worry here is that you have to be _very_ careful to define > > behavior properly.  It's not an issue for extension APIs, where you > > can assume that the caller will do sane (and probably

Re: [DOMCore] fire and dispatch

On Tue, Mar 1, 2011 at 8:51 AM, Boris Zbarsky wrote: > The big worry here is that you have to be _very_ careful to define behavior > properly.  It's not an issue for extension APIs, where you can assume that > the caller will do sane (and probably non-malicious) things.  But for a web > API like t

Re: Cross-Origin Resource Embedding Restrictions

Glenn Maynard wrote: On Tue, Mar 1, 2011 at 3:33 PM, Nathan wrote: (rather than controlled only "by user agents which choose to follow the specs" offering an artificial screen). If user agents deliberately ignore the specs to allow embedding where authors don't want it to, they can do it wit

Re: Cross-Origin Resource Embedding Restrictions

On Tue, Mar 1, 2011 at 3:33 PM, Nathan wrote: > (rather than controlled only "by user agents which choose to follow the > specs" offering > an artificial screen). If user agents deliberately ignore the specs to allow embedding where authors don't want it to, they can do it with any model--Refere

Re: Cross-Origin Resource Embedding Restrictions

Anne van Kesteren wrote: http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html And although it might end up being part of the Content Security Policy work I think it would be useful if publish a Working Draft of this work to gather more input, committing us nothing. What do you think?

Re: [whatwg] Intent of the FileSystem API

On Tue, Mar 1, 2011 at 3:17 PM, Eric Uhrhane wrote: >> Maybe disallow nulls; I'm not sure if this is special enough to >> actually need to be in this set. > > I like it, though, as allowing nulls in strings is likely to lead to user > error. In my experience, most of the errors surrounding nulls

Re: [whatwg] Intent of the FileSystem API

On Tue, Mar 1, 2011 at 11:37 AM, Glenn Maynard wrote: > On Tue, Mar 1, 2011 at 1:13 PM, Eric Uhrhane wrote: >> What would you suggest for limitations?  If we're requiring >> virtualization, it seems to me that we could be quite liberal. > > I'd suggest only the restrictions that are required for

[eventsource] Event names

> 3. Otherwise, create an event that uses the MessageEvent interface, with the event name message [...] > 4. If the event name buffer has a value other than the empty string, change the type of the newly created event to equal the value of the event name buffer. I'd suggest consistently saying the

Re: [whatwg] Intent of the FileSystem API

On Tue, Mar 1, 2011 at 1:13 PM, Eric Uhrhane wrote: > What would you suggest for limitations?  If we're requiring > virtualization, it seems to me that we could be quite liberal. I'd suggest only the restrictions that are required for the API: no "", ".", "..", and no filenames containing forward

Re: Cross-Origin Resource Embedding Restrictions

Adam wrote: > > There's been a bunch of discussion on the public-web-security mailing > list about the scope of CSP. Some folks think that CSP should be a > narrow feature targeted at mitigating cross-site scripting. Other > folks (e.g., as articulated in >

Re: [whatwg] Intent of the FileSystem API

On Mon, Feb 28, 2011 at 6:21 PM, Glenn Maynard wrote: > On Mon, Feb 28, 2011 at 7:41 PM, Eric Uhrhane wrote: >> >> Sorry--I meant to push this over to public-webapps, as Ian suggested. >> [+cc public-webapps, whatwg->BCC] > > Currently (reviewing for context), the spec tries to reach "filename >

Re: [whatwg] Intent of the FileSystem API

On Mon, Feb 28, 2011 at 4:59 PM, Charles Pritchard wrote: > On 2/28/2011 4:10 PM, Eric Uhrhane wrote: >> >> On Mon, Feb 28, 2011 at 2:54 PM, Charles Pritchard >>  wrote: >>> >>> I'd like some clarification on the intent of the FileSystem API: >>> requestFileSystem permanent, getDirectory and getFi

Re: Cross-Origin Resource Embedding Restrictions

I do think Content Security Policy offers a good opportunity to address the use cases Anne brought up. CSP already has a directive, frame-ancestors, that restricts the context in which a resource can be embedded as a , or to a list of origins. Perhaps we should expand the scope of the directive

Re: [IndexedDB] Two Real World Use-Cases

On Tue, Mar 1, 2011 at 7:34 AM, Joran Greef wrote: > I have been following the development behind IndexedDB with interest. Thank > you all for your efforts. > > I understand that the initial version of IndexedDB will not support > indexing array values. > > May I suggest an alternative derived fr

[IndexedDB] Two Real World Use-Cases

I have been following the development behind IndexedDB with interest. Thank you all for your efforts. I understand that the initial version of IndexedDB will not support indexing array values. May I suggest an alternative derived from my home-brew server database evolved from experience using

Re: publish a new Working Draft of DOM Core; comment deadline March 2

On Mon, 28 Feb 2011 18:49:48 +0100, Garrett Smith wrote: | DOM Core defines the event and document model the Web platform uses. That says that DOM Core defines two different things: events and DOM. Some things might implement DOM Events Core (or a subinterface thereof) but are unrelated to the

Re: [DOMCore] fire and dispatch

On 3/1/11 3:48 AM, Ojan Vafai wrote: Mouse.click(document.body, {clientX : 10}); ... The Chromium extension APIs use this pattern and I think it's gone over well in that space. For example, see chrome.contextMenus.create at http://code.google.com/chrome/extensions/contextMenus.html. I

Re: [DOMCore] fire and dispatch

On Tue, 01 Mar 2011 09:59:59 +0100, Jonas Sicking wrote: We're also using it in IndexedDB, though I don't think this has gotten into the spec drafts yet. But it is in the firefox implementation and I *think* in the chrome implementation. The issue raised with it last time (by Boris Zbarsky) wa

Re: [DOMCore] fire and dispatch

On Tue, Mar 1, 2011 at 12:48 AM, Ojan Vafai wrote: > On Tue, Mar 1, 2011 at 7:23 PM, Anne van Kesteren wrote: >> >> On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith >> wrote: >>> >>> Mouse.click(document.body, {clientX : 10}); >> >> Yeah, that would be simpler. However, we do not really have th

Re: publish a new Working Draft of DOM Core; comment deadline March 2

On Tue, 01 Mar 2011 08:51:24 +0100, Maciej Stachowiak wrote: What conflicts or contradictions exist currently? Does anyone have a list? Some time ago I put a list in the draft: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-events Glenn Maynard and I are still researching the

Re: [DOMCore] fire and dispatch

On Tue, Mar 1, 2011 at 7:23 PM, Anne van Kesteren wrote: > On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith > wrote: > >> Mouse.click(document.body, {clientX : 10}); >> > > Yeah, that would be simpler. However, we do not really have this pattern > anywhere in browser APIs and I believe last tim

Re: publish a new Working Draft of DOM Core; comment deadline March 2

On Mon, 28 Feb 2011 17:59:45 +0100, Adrian Bateman wrote: Something boxed out at the start of the Events section would be great for now. Added: https://bitbucket.org/ms2ger/dom-core/changeset/a997dac35d91 Hopefully we can make sure that the drafts are aligned and if the new DOM Core spe

Re: Cross-Origin Resource Embedding Restrictions

+dveditz and +bsterne because they have strong opinions about CSP. Adam On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth wrote: > On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak wrote: >> For what it's worth, I think this is a useful draft and a useful technology. >> Hotlinking prevention is o

Re: Cross-Origin Resource Embedding Restrictions

On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak wrote: > For what it's worth, I think this is a useful draft and a useful technology. > Hotlinking prevention is of considerable interest to Web developers, and > doing it via server-side Referer checks is inconvenient and error-prone. I > hop

Re: [DOMCore] fire and dispatch

On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith wrote: Mouse.click(document.body, {clientX : 10}); Yeah, that would be simpler. However, we do not really have this pattern anywhere in browser APIs and I believe last time we played with objects (for namespace support querySelector or som

Re: set input.value when input element has composition string

Hi, Kang-Hao. On 2011/02/28 21:31, Kang-Hao (Kenny) Lu wrote: Hello Makoto, (Cc+ public-webapps) (11/02/25 15:16), Makoto Kato wrote: Hi, This is simple sample. This behavior is different on all web browsers when input element has composition/preedit string for IME. A relevant question here

Re: publish a new Working Draft of DOM Core; comment deadline March 2

On Sat, 26 Feb 2011 16:15:25 +0100, Doug Schepers wrote: I will remove my objection to publish DOM Core if: 1) conflicts (rather than extensions) are removed from the draft, or reconciled with changes in DOM3 Events; and 2) for those changes that have broad consensus, we can integrate them

Re: [DOMCore] fire and dispatch

On 2/28/11, Anne van Kesteren wrote: > On Fri, 25 Feb 2011 18:47:54 +0100, Garrett Smith > wrote: >> Your example is simple. But some common cases of synth events are >> complicated. UI Events aren't so bad but MouseEvents and especially >> TouchEvents are a lot of work to synthesize. >> >> Most