Re: [DOMCore] fire and dispatch

2011-03-01 Thread Garrett Smith
On 2/28/11, Anne van Kesteren ann...@opera.com wrote:
 On Fri, 25 Feb 2011 18:47:54 +0100, Garrett Smith dhtmlkitc...@gmail.com
 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 cases for synth events are for testing -- feature test or unit test.

 EventTarget.fireEvent(type[, options]);

 So how is this simpler? Maybe you could illustrate by example instead?


It is simpler than the W3C existing model because it doesn't require
any memorization. This is because each property of `options` is
optional. The entire `options` object is optional. If options is not
an object, then a default options object is created internally.

Some examples where that approach is used are in YUI, which they use
for YUI Test. Another is in TestRunner (I made). Both of these are
unit testing frameworks that can be used to test javascript code
running in a web browser.

YUI is pretty easy to find. The interface of what I made is quite
similar. The idea is that instead of the heavywork of
createEvent(MouseEvent) and then initMouseEvent with 16 args, you
can just:

Mouse.click(document.body, {clientX : 10});
https://github.com/GarrettS/ape-javascript-library/blob/master/src/eventsynth/Mouse.js

No long parameter lists to memorize. And it is extensible in that
future versionso of mouse events can have more options which can be
easily featre tested.

Compare that to:
var mouseEvent = doc.createEvent(MouseEvent);
mouseEvent.initMouseEvent(click, true, true,
doc.defaultView, 1, 0, 0,
10, 0, false, false,
false, false, 1,
null);
document.body.dispatchEvent(mouseEvent);

For me, the first one is memorable but the second way (the standard
way) requires me to memorize too much and is easy to make a mistake
with order of arguments.

The adapter also does some workarounds for browser bugs and for IE's
different model. But regardless, even without the differing model, or
bug workarounds, the default API is unnecessarily complicated. At
least for web scripting. For java, too, I suppose.

Nothing ingenious on my part. Makes perfect sense, really.
-- 
Garrett



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

2011-03-01 Thread Anne van Kesteren

On Sat, 26 Feb 2011 16:15:25 +0100, Doug Schepers schep...@w3.org 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 into DOM3 Events, which means that the changes should  
be sent as comments on DOM3 Events, to be discussed by the group and  
their current status determined.


I am fine with raising issues to be discussed (and I am planning on doing  
so), but do we really need to resolve them before proceeding with  
publication? Is having a clear warning at the start of the Events  
section not sufficient, as Adrian suggested?



I had previously started a DOM Core 4 draft specification, but when Anne  
and others volunteered to do Web DOM Core, I moved aside to let them  
work, and volunteered to help with that draft;


Actually, before you worked on that Simon Pieters wrote fair bit of Web  
DOM Core (now DOM Core). Then Geoffrey Sneddon. Then Ms2ger. And only then  
I started helping out.



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 we can edit the spec together  
amicably and productively.


Do you have a bitbucket.org account? Ms2ger and I use  
https://bitbucket.org/ms2ger/dom-core as our primary repository. We  
typically coordinate editorial ideas in #whatwg and for them we also do  
commit first, then review every so often. Changes to existing features are  
brought up for discussion on public-webapps@w3.org, usually after we  
sanity checked them with each other. So far we have avoided adding new  
features as we would like to first reach some kind of stability with the  
current DOM implementations. If this all works for you I think it can work  
out.


I have not run this by Ms2ger though I suspect he will agree.

To be frank I am a little skeptical given our strained relationship to  
date, but I am willing to give it a try.


Kind regards,


--
Anne van Kesteren
http://annevankesteren.nl/



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

2011-03-01 Thread Makoto Kato

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, I think, is where the cursor should go when
the value of the text box is set by script. For Safari5, it always goes
to the end when the value is set. For FF4.0b11, the cursor stays in
previous position when the value to be set is the same and goes to the
end when the value is different. Is this a known incompatibility? I find
the behavior of FF quite strange.


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, Chrome and Opera keep composition string after 
value is replaced by DOM, each behavior is different.


This is the result for this test on each browsers.  When textbox has IME 
composition string such as ABCDEFG, then script (textbox.value = 123;) 
is called, textbox becomes...


1. 123ABCDEFG (ABCDEFG keeps composition state and caret is after G).
2. 123 (composition string is removed).
3. ABCDEFG (ABCDEFG keeps composition state and caret is after G).

Which behavior is right?  1 is Opera 11, 2 is Safari 5, and 3 is Chrome 
10 and IE9.


Also, on Firefox/Gecko, since there is some bugs, key input cannot work 
until IME is turned off.  So to fix this, I am talking with Ehsan about 
right specification.  But there is no discussion about this 
specification/behavior at WHATWG.



If input element has composition string by IME, should it cancel
composition string and set value by script?  Or should it cancel
setting value since it has composition string?

What makes sense to me is:
1. the cursor always goes to the end
2. the composition string goes with the cursor, which should not change.

But I am not sure whether this is the right way to go.

Cheers,
Kenny


script
function setvalue() {
   document.getElementById('test').value = replaced;
}
/script
body onload=setTimeout('setvalue()',5000)
input type=text id=test/
/body


-- Makoto Kato


-- Makoto Kato



Re: [DOMCore] fire and dispatch

2011-03-01 Thread Anne van Kesteren
On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith dhtmlkitc...@gmail.com  
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 some such) it was deemed  
problematic.


An alternative would be I guess what Simon Pieters proposed some time ago.  
That we make event IDL attributes mutable before the event is dispatched.  
And that they would get readonly semantics on setting during dispatch  
(i.e. based on the dispatch flag).



--
Anne van Kesteren
http://annevankesteren.nl/



Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread Adam Barth
On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak m...@apple.com 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 
 hope we can fit it into Web Apps WG, or if not, find another goo home for it 
 at the W3C.

 One thing I am not totally clear on is how this would fit into CSP. A big 
 focus for CSP is to enable site X to have a policy that prevents it from 
 accidentally including scripts from site Y, and things of that nature. In 
 other words, voluntarily limit the embedding capabilities of site X itself 
 But the desired feature is kind of the opposite of that. I think it would be 
 confusing to stretch CSP to this use case, much as it would have been 
 confusing to reuse CORS for this purpose.

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
http://w2spconf.com/2010/papers/p11.pdf) would like to see CSP be
more of a one-stop shop for configuring security-relevant policy for a
web site.

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:

https://wiki.mozilla.org/Security/CSP/Specification

Aside from the aesthetic questions, I'd imagine folks will want to
include a list of permissible origins in the From-Origin header (or
else they'd have to give up caching their resources).  CSP already has
syntax, semantics, and processing models for lists of origins,
including wildcards.  At a minimum, we wouldn't want to create a
gratuitously different syntax for the same thing.

Adam


 On Feb 28, 2011, at 11:35 PM, Anne van Kesteren wrote:
 The WebFonts WG is looking for a way to prevent cross-origin embedding of 
 fonts as certain font vendors want to license their fonts with such a 
 restriction. Some people think CORS is appropriate for this, some don't. 
 Here is some background material:

 http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
 http://annevankesteren.nl/2011/02/web-platform-consistency
 http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html


 More generally, having a way to prevent cross-origin embedding of resources 
 can be useful. In addition to license enforcement it can help with:

 * Bandwidth theft
 * Clickjacking
 * Privacy leakage

 To that effect I wrote up a draft that complements CORS. Rather than 
 enabling sharing of resources, it allows for denying the sharing of 
 resources:

 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?

 Kind regards,


 --
 Anne van Kesteren
 http://annevankesteren.nl/







Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread Adam Barth
+dveditz and +bsterne because they have strong opinions about CSP.

Adam


On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth w...@adambarth.com wrote:
 On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak m...@apple.com 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 
 hope we can fit it into Web Apps WG, or if not, find another goo home for it 
 at the W3C.

 One thing I am not totally clear on is how this would fit into CSP. A big 
 focus for CSP is to enable site X to have a policy that prevents it from 
 accidentally including scripts from site Y, and things of that nature. In 
 other words, voluntarily limit the embedding capabilities of site X itself 
 But the desired feature is kind of the opposite of that. I think it would be 
 confusing to stretch CSP to this use case, much as it would have been 
 confusing to reuse CORS for this purpose.

 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
 http://w2spconf.com/2010/papers/p11.pdf) would like to see CSP be
 more of a one-stop shop for configuring security-relevant policy for a
 web site.

 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:

 https://wiki.mozilla.org/Security/CSP/Specification

 Aside from the aesthetic questions, I'd imagine folks will want to
 include a list of permissible origins in the From-Origin header (or
 else they'd have to give up caching their resources).  CSP already has
 syntax, semantics, and processing models for lists of origins,
 including wildcards.  At a minimum, we wouldn't want to create a
 gratuitously different syntax for the same thing.

 Adam


 On Feb 28, 2011, at 11:35 PM, Anne van Kesteren wrote:
 The WebFonts WG is looking for a way to prevent cross-origin embedding of 
 fonts as certain font vendors want to license their fonts with such a 
 restriction. Some people think CORS is appropriate for this, some don't. 
 Here is some background material:

 http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
 http://annevankesteren.nl/2011/02/web-platform-consistency
 http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html


 More generally, having a way to prevent cross-origin embedding of resources 
 can be useful. In addition to license enforcement it can help with:

 * Bandwidth theft
 * Clickjacking
 * Privacy leakage

 To that effect I wrote up a draft that complements CORS. Rather than 
 enabling sharing of resources, it allows for denying the sharing of 
 resources:

 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?

 Kind regards,


 --
 Anne van Kesteren
 http://annevankesteren.nl/








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

2011-03-01 Thread Anne van Kesteren
On Mon, 28 Feb 2011 17:59:45 +0100, Adrian Bateman  
adria...@microsoft.com 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 spec picks up where DOM L3 Events leaves off then that might be  
an helpful outcome.


Since you keep bringing this up I thought I should clarify that the  
emphasis of DOM Core is not on new features. It is about a better  
definition of the DOM that better reflects reality and is more in line  
with specifications written from scratch in the last couple of years, such  
as HTML5, XMLHttpRequest, etc.


Regardless of that (potential) misunderstanding, it is much appreciated we  
could work this out.


Kind regards,


--
Anne van Kesteren
http://annevankesteren.nl/



Re: [DOMCore] fire and dispatch

2011-03-01 Thread Ojan Vafai
On Tue, Mar 1, 2011 at 7:23 PM, Anne van Kesteren ann...@opera.com wrote:

 On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith dhtmlkitc...@gmail.com
 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 some such) it was deemed problematic.


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 don't see a
problem with beginning to introduce this into web APIs, but it would be a
departure from existing APIs.


 An alternative would be I guess what Simon Pieters proposed some time ago.
 That we make event IDL attributes mutable before the event is dispatched.
 And that they would get readonly semantics on setting during dispatch (i.e.
 based on the dispatch flag).


This seems fine to me too.

Ojan


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

2011-03-01 Thread Anne van Kesteren
On Tue, 01 Mar 2011 08:51:24 +0100, Maciej Stachowiak m...@apple.com  
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 last bullet point. It seems  
there are a variety of options there each with their own implications (oh,  
and current browsers do not really agree). Hopefully I will get to that  
soon.



Doug, should I open a thread for each of these on www-...@w3.org? What  
about  
http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-eventPhase not  
being defined for this scenario: var e = document.createEvent(Event);  
alert(e.eventPhase);? There is quite a few of those undefined issues. Are  
they conflicts or extensions of DOM Core?



--
Anne van Kesteren
http://annevankesteren.nl/



Re: [DOMCore] fire and dispatch

2011-03-01 Thread Jonas Sicking
On Tue, Mar 1, 2011 at 12:48 AM, Ojan Vafai o...@chromium.org wrote:
 On Tue, Mar 1, 2011 at 7:23 PM, Anne van Kesteren ann...@opera.com wrote:

 On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith dhtmlkitc...@gmail.com
 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 some such) it was deemed problematic.

 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 don't see a problem with beginning to introduce this into web APIs, but it
 would be a departure from existing APIs.

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.

/ Jonas



Re: [DOMCore] fire and dispatch

2011-03-01 Thread Anne van Kesteren

On Tue, 01 Mar 2011 09:59:59 +0100, Jonas Sicking jo...@sicking.cc 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) was the potential  
for the existence of getters. Maybe we can deal with that via JSON or some  
such? Though even then I think I would prefer


  var e = document.createEvent(MouseEvent)
  e.offsetX = 10

over using an object of some sorts.


--
Anne van Kesteren
http://annevankesteren.nl/



Re: [DOMCore] fire and dispatch

2011-03-01 Thread Boris Zbarsky

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 don't see
a problem with beginning to introduce this into web APIs, but it would
be a departure from existing APIs.


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 this you would need to define exactly when and 
how many times the UA is supposed to get the clientX property of the 
second argument, for example.  That's a minimal requirement; there are 
probably other ratholes here that would need worrying about.  :(


Alternately, we could require that all the properties be plain data 
properties or something, to avoid some of those pitfalls.


-Boris



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

2011-03-01 Thread Anne van Kesteren
On Mon, 28 Feb 2011 18:49:48 +0100, Garrett Smith dhtmlkitc...@gmail.com  
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 DOM. Like XHR.

Could Events Core exist on its own? (You could make DOM Core
conformance require Events Core conformance).


These are the reasons they are intertwined:

 * document.createEvent()
 * mutation events
 * we want Node to inherit from EventTarget
 * both events and documents depend on the same tree concept
 * INVALID_STATE_ERR is shared

Of course, given a mutual dependency they could be split, but I do not  
really see the point. Should the Exceptions section be split out too in  
your opinion? Given that Events and Exceptions are quite short and per  
the above summary quite integral to how everything fits together I think  
the current division makes sense.



--
Anne van Kesteren
http://annevankesteren.nl/



[IndexedDB] Two Real World Use-Cases

2011-03-01 Thread Joran Greef
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 MySql, WebSql, LocalStorage, CouchDb, Tokyo Cabinet and 
Redis?

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 all the flexibility they need.

2. Be able to intersect and union indexes. This covers a tremendous amount of 
ground in terms of authorization and filtering.

These two needs are critical.

Without them, I will either carry on using WebSql for as long as possible, or 
be forced to use IndexedDb as a simple key value store and layer my own 
indexing on top.

I am writing an email application and have to deal with secondary indexes of up 
to 4,000,000 keys. It would not be ideal to do intersects and unions on these 
indexes in the application layer.

Regards

Joran Greef


Re: [IndexedDB] Two Real World Use-Cases

2011-03-01 Thread Jeremy Orlow
On Tue, Mar 1, 2011 at 7:34 AM, Joran Greef jo...@ronomon.com 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 from my home-brew server database
 evolved from experience using MySql, WebSql, LocalStorage, CouchDb, Tokyo
 Cabinet and Redis?

 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 all the flexibility they need.


You're talking about having multiple entries in a single index that point
towards the same primary key?  If so, then I strongly agree, and I think
others agree as well.  It's mostly a question of syntax.  A while ago we
brainstormed a couple possibilities.  I'll try to send out a proposal this
week.  I think this + compound keys should probably be our last v1 features
though.  (Though they almost certainly won't make Chrome 11 or Firefox 4,
unfortunately, hopefully they'll be done in the next version of each, and
hopefully that release with be fairly soon after for both.)


 2. Be able to intersect and union indexes. This covers a tremendous amount
 of ground in terms of authorization and filtering.


Our plan was to punt some sort of join language to v2.  Could you give a
more concrete proposal for what we'd add?  It'd make it easier to see if
it's something realistic for v1 or not.

As you mention below, you can always do this in JS if necessary.  And
although I know it's not ideal, I think it's the right tradeoff in terms of
making it practical for browser vendors to get v1 out the door fairly fast.


 These two needs are critical.

 Without them, I will either carry on using WebSql for as long as possible,
 or be forced to use IndexedDb as a simple key value store and layer my own
 indexing on top.

 I am writing an email application and have to deal with secondary indexes
 of up to 4,000,000 keys. It would not be ideal to do intersects and unions
 on these indexes in the application layer.

 Regards

 Joran Greef



Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread Brandon Sterne
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 iframe, frame or object
to a list of origins.  Perhaps we should expand the scope of the
directive to include other elements (and change the directive name to
something less frame-centric).

I'd personally support such a change.

-Brandon


On 03/01/2011 12:32 AM, Adam Barth wrote:
 +dveditz and +bsterne because they have strong opinions about CSP.
 
 Adam
 
 
 On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth w...@adambarth.com wrote:
 On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak m...@apple.com 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 hope we can fit it into Web Apps WG, or if not, find another 
 goo home for it at the W3C.

 One thing I am not totally clear on is how this would fit into CSP. A big 
 focus for CSP is to enable site X to have a policy that prevents it from 
 accidentally including scripts from site Y, and things of that nature. In 
 other words, voluntarily limit the embedding capabilities of site X itself 
 But the desired feature is kind of the opposite of that. I think it would 
 be confusing to stretch CSP to this use case, much as it would have been 
 confusing to reuse CORS for this purpose.

 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
 http://w2spconf.com/2010/papers/p11.pdf) would like to see CSP be
 more of a one-stop shop for configuring security-relevant policy for a
 web site.

 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:

 https://wiki.mozilla.org/Security/CSP/Specification

 Aside from the aesthetic questions, I'd imagine folks will want to
 include a list of permissible origins in the From-Origin header (or
 else they'd have to give up caching their resources).  CSP already has
 syntax, semantics, and processing models for lists of origins,
 including wildcards.  At a minimum, we wouldn't want to create a
 gratuitously different syntax for the same thing.

 Adam


 On Feb 28, 2011, at 11:35 PM, Anne van Kesteren wrote:
 The WebFonts WG is looking for a way to prevent cross-origin embedding of 
 fonts as certain font vendors want to license their fonts with such a 
 restriction. Some people think CORS is appropriate for this, some don't. 
 Here is some background material:

 http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
 http://annevankesteren.nl/2011/02/web-platform-consistency
 http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html


 More generally, having a way to prevent cross-origin embedding of 
 resources can be useful. In addition to license enforcement it can help 
 with:

 * Bandwidth theft
 * Clickjacking
 * Privacy leakage

 To that effect I wrote up a draft that complements CORS. Rather than 
 enabling sharing of resources, it allows for denying the sharing of 
 resources:

 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?

 Kind regards,


 --
 Anne van Kesteren
 http://annevankesteren.nl/








Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Eric Uhrhane
On Mon, Feb 28, 2011 at 4:59 PM, Charles Pritchard ch...@jumis.com wrote:
 On 2/28/2011 4:10 PM, Eric Uhrhane wrote:

 On Mon, Feb 28, 2011 at 2:54 PM, Charles Pritchardch...@jumis.com
  wrote:

 I'd like some clarification on the intent of the FileSystem API:
 requestFileSystem permanent, getDirectory and getFile.

 ...

 They're not particularly easy to use, compared to the IndexedDB data
 store,

 I find files to be easier to use than databases, but I'm clearly
 biased ;'.  However, that's not really the point.  Files and
 databases serve different needs, and various use cases are better
 served by each than the other.  If you want transactions or indexing,
 you want IDB.  If you want fast, mutable binary blobs with persistent
 URLs, you want FileSystem.

 It's much easier to send a query via IndexedDB to list all files in a
 directory
 mask, than it is to build up the same thing using getDirectory.

 I'm quite happy with File, FileWriter, and so forth.

 It's much easier/quicker to post a binary blob at an arbitrary path using a
 data store, than it is going through full file system
 semantics; a bunch of create directory and file calls.

 For scalability, you've got Amazon S3 and Google Storage as data store
 models.

 I target the old WebSQL, localStorage, file system,
 IDB and remote services, to stash images and metadata.

 IDB has been the easiest to support, as the others generally require more
 work to stash metadata information,
 and have uncertain locking.


 but if they are OS level commands,
 then they do help with usability of a web app with the rest of the OS:
 with
 managing files directly from the OS file manager.

 Is the FileSystem API intended to expose a folder on the host operating
 system, or is it just an abstraction
 which can be bolted onto any data system (such as, using SQLite as a
 backend, as appCache and IndexedDB do)  ?

 While the current API could in theory be implemented either way, there
 have been many requests for expansions to the API that would allow for
 access to directories outside the sandbox, e.g. giving Flickr access
 to My Photos.  While that's not yet been specced, that would clearly
 require real pass-through access and real file names.  The rest of the
 API could of course be identical, and I hope that eventually it will
 serve both use cases.

 I'm supportive of a virtual FS for the temporary file system, but
 using a real sandbox for the permanent system.

I don't think it's likely that we'll want to have different APIs for
temporary vs. persistent storage, in the origin-specific sandbox.  But
if you mean a different API [different path limitations, anyway] for
the sandbox vs. other mount points such as My Photos, then yes, I
think that makes sense.

 I'm sure we'll get there eventually, serving both cases.

 Are there any plans of reviewing/visiting efficient File/Blob support in
 indexeddb?

 I can't speak for the indexedDB developers, but the last I heard
 on-list, they were at least hoping to support immutable Blobs, but not
 soon.

 What's the hold up? Working with base64 encoding is slow.
 createObjectURL is nice.

 More on those portability issues:

 We've been implementing the current FileSystem API spec in Chrome, and
 had planned that our implementation of the sandbox would be just a
 passthrough to a directory under the user's profile.  We've been
 testing that out, currently only allowing access to extensions and
 apps, but we've gotten feedback that long profile paths are causing a
 problem on Windows.

 Yes, I submitted that feedback :-)

 My understanding is that it's quite reasonable to get longer paths than the
 current 255 bytes.
 Keep in mind, that includes the whole path to the AppData profile directory.

 There are certainly issues in old copies of windows, but I think they've
 been addressed since.

 speed of access and ease of modification, but we'll be storing the
 paths in an internal database.

 I did the same on the file system as well, as I needed that flexibility
 to get around the various constraints.

 I kept original file names, which caused some problems with the 255 byte
 limit.

 stashed the file in
 sha1hash.substr(-2) + '/' + sha1Hash + '/' originalFilename
 with metadata in
 sha1hash.substr(-2) + '/' + sha1Hash + '/' metaDataHash + '/entry.txt'

 The metadata entry.txt files are in there as a precaution and for
 transparency
 if the user is accessing things outside of the app.

 ..

 Would your virtual FS be up to including a Dropbox style directory,
 where users could copy files into, and they'd be accessible to the FS api?

No.  That'd have to wait for the proposed expanded API that would
allow for other mount points.

 That's also how I modeled mine, including a Dropbox directory underneath
 it all, for users to easily copy files into.

 In some cases, it's much easier to drag/drop a hundred files into the
 directory,
 through the system file manager. Also allows for the OS to treat the dropbox
 as a queue: the 

Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Eric Uhrhane
On Mon, Feb 28, 2011 at 6:21 PM, Glenn Maynard gl...@zewt.org wrote:
 On Mon, Feb 28, 2011 at 7:41 PM, Eric Uhrhane er...@google.com 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
 consistency (only allowing filenames to be used which can be used
 consistently on all browsers) by restricting filenames to the lowest-common
 denominator.  With this path length issue, I don't think that approach is
 correct, since it seems like everyone's going to have to implement path
 virtualization anyway.

Indeed.

 Based on that, I'd like to suggest a model change:

 - Only place basic restrictions on filenames, giving the broadest set of
 filenames that are generally supported (eg. no slashes, nulls, and some
 reasonable length limits).

What would you suggest for limitations?  If we're requiring
virtualization, it seems to me that we could be quite liberal.

 - For sandboxed directories, it's guaranteed that all legal filenames are
 permitted, whether or not the local filesystem supports them.  If the native
 filesystem isn't capable of supporting all legal filenames, virtualization
 is required.
 - For mounted directories, no guarantee of filename consistency is made:
 you can create filenames on some systems that aren't allowed on others.
 Filenames invalid on a particular system raise an exception.

 This gives filename consistency for sandboxed directories without applying
 quirks of all operating systems to users of all other operating systems.

 This expressly gives no guarantee of filename consistency for mounted
 directories (which don't exist yet, of course).  As we talked about before,
 I think this is critical when dealing with directories shared with native
 applications.  If the user creates hello?.txt, then a web app version of
 gzip must be able to create hello?.txt.gz if the system can do so.
 Similarly, if the user creates family photos: Bill.jpg, a web app image
 resizer must be able to create family photos: Bill (thumbnail).jpg.

 (I'm not trying to get into the particulars of mounted directories now,
 but I needed to mention them to explain how this suggestion fits together,
 since directories interacting with native applications can't be
 virtualized.)

Yes, and I'm finding myself agreeing with you, although I've argued
the other side in the past.  Sometimes you just have to try
implementing it to figure out what's not going to work.

 On Mon, Feb 28, 2011 at 7:59 PM, Charles Pritchard ch...@jumis.com wrote:
 There are certainly issues in old copies of windows, but I think they've
 been addressed since.

 It still happens in Win7, even in Windows Explorer.  I'm pretty sure this is
 just PATH_MAX, which hasn't changed.

 --
 Glenn Maynard





Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread =JeffH

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
 http://w2spconf.com/2010/papers/p11.pdf) would like to see CSP be
 more of a one-stop shop for configuring security-relevant policy for a
 web site.

Well, to be clear, we (AndyS and I) aren't calling (in the above-cited paper) 
for CSP per se to address all use cases -- rather, we see it as a non-trivial 
piece of necessarily multi-faceted approach to crafting a more coherent 
approach to web application security.


That said, we do feel that attenuation of the growth of the number of distinct 
http header fields would probably be a good thing, which would auger for trying 
to figure out how, e.g., CSP might address this use case.


=JeffH





Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Glenn Maynard
On Tue, Mar 1, 2011 at 1:13 PM, Eric Uhrhane er...@google.com 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 slashes.

Maybe some fairly high filename component limit (NAME_MAX) for sanity;
maybe 4k (in UTF-16).

Maybe disallow nulls; I'm not sure if this is special enough to
actually need to be in this set.

I think the 5000 entries per directory limitation should also go
away.  Virtualization hides any local directory
limitations--presumably files on disk wouldn't mirror the virtualized
directory structure.

(By the way, I'm not sure from the spec which error code is used for
invalid filenames.  Also--though this section may be irrelevant if you
go with this approach--section 8 says This section is non-normative.
and then contains normative requirements.)

 Yes, and I'm finding myself agreeing with you, although I've argued
 the other side in the past.  Sometimes you just have to try
 implementing it to figure out what's not going to work.

Sure, I don't think anyone predicted OS-related problems that were
quite that difficult to mask with filename restrictions.  (It feels
like I should have thought of it, too, since I've hit the this issue
several times natively when extracting archives with long
filenames...)

-- 
Glenn Maynard



[eventsource] Event names

2011-03-01 Thread Glenn Maynard
 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 event type, rather than using both
event name and event type.  It sounds like it's referring to two
different things, so I had to read this a few times to figure out what it
meant.


This allows sending messages with names equal to those of the API's own
events.  Should it prohibit using open and error as event names, so
remote messages can't fire events that look like connection-state events?
These are very obvious choices for people to use as event names, so I could
see this leading to obscure bugs.

Alternatively, give remote event names a prefix; for example, if an event is
sent with the event name update, fire the event server:update.  That has
the advantage that, if additional events are added to MessageEvent in a
later spec, they won't conflict with server event names that people are
using--the namespaces are clearly separated.

-- 
Glenn Maynard


Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Eric Uhrhane
On Tue, Mar 1, 2011 at 11:37 AM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Mar 1, 2011 at 1:13 PM, Eric Uhrhane er...@google.com 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 slashes.

That makes sense.

 Maybe some fairly high filename component limit (NAME_MAX) for sanity;
 maybe 4k (in UTF-16).

 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.

 I think the 5000 entries per directory limitation should also go
 away.  Virtualization hides any local directory
 limitations--presumably files on disk wouldn't mirror the virtualized
 directory structure.

Right.

 (By the way, I'm not sure from the spec which error code is used for
 invalid filenames.  Also--though this section may be irrelevant if you
 go with this approach--section 8 says This section is non-normative.
 and then contains normative requirements.)

The non-normative flag is only supposed to be for the next paragraph,
not the whole section.  Thanks--I'll fix that when I rewrite that
section.

 Yes, and I'm finding myself agreeing with you, although I've argued
 the other side in the past.  Sometimes you just have to try
 implementing it to figure out what's not going to work.

 Sure, I don't think anyone predicted OS-related problems that were
 quite that difficult to mask with filename restrictions.  (It feels
 like I should have thought of it, too, since I've hit the this issue
 several times natively when extracting archives with long
 filenames...)

 --
 Glenn Maynard




Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Glenn Maynard
On Tue, Mar 1, 2011 at 3:17 PM, Eric Uhrhane er...@google.com 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 are related to
null-terminated strings, which doesn't apply in JS.

I'm not bothered much either way, though: no real systems support
nulls in filenames (since it would break just about all C APIs), so
disallowing it won't break anything.

-- 
Glenn Maynard



Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread Nathan

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?


Half way there, I don't follow why a line of js invokes an everything 
cross-origin blocked by default security model, and a line of html 
invokes an everything allowed by default security model. Nor do I 
follow why origin isn't just sent as standard with every request and 
access controlled by the server based on origin (rather than controlled 
only by user agents which choose to follow the specs offering an 
artificial screen).


However, on this specific draft, is there any chance you can move to a 
white-list/black-list model, where people can send either Allow-Origin 
or Deny-Origin, for instance in many scenarios I want to allow everyone 
except origins A and B who I know consistently steal bandwidth, or 
display my resources beside unsavoury ones.


Best,

Nathan



Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread Glenn Maynard
On Tue, Mar 1, 2011 at 3:33 PM, Nathan nat...@webr3.org 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--Referer,
Origin, From-Origin, etc.  They all depend on UA cooperation.

In practice, as long as most browsers support it and enable it by
default, that's enough to discourage people from embedding resources
from sites that don't want them to.

 However, on this specific draft, is there any chance you can move to a
 white-list/black-list model, where people can send either Allow-Origin or
 Deny-Origin, for instance in many scenarios I want to allow everyone except
 origins A and B who I know consistently steal bandwidth, or display my
 resources beside unsavoury ones.

Sending whitelists in a header makes sense to me, but sending
blacklists with every request doesn't scale--such a list could easily
end up having dozens of entries, bloating the headers for every
request.  You may not actually want to expose your entire blacklist to
the public, either.

Blacklisting does seem like a fair use case, though; it often makes
sense to want to block particularly abusive sites, without blocking
everyone.

-- 
Glenn Maynard



Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread Nathan

Glenn Maynard wrote:

On Tue, Mar 1, 2011 at 3:33 PM, Nathan nat...@webr3.org 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--Referer,
Origin, From-Origin, etc.  They all depend on UA cooperation.

In practice, as long as most browsers support it and enable it by
default, that's enough to discourage people from embedding resources
from sites that don't want them to.


However, on this specific draft, is there any chance you can move to a
white-list/black-list model, where people can send either Allow-Origin or
Deny-Origin, for instance in many scenarios I want to allow everyone except
origins A and B who I know consistently steal bandwidth, or display my
resources beside unsavoury ones.


Sending whitelists in a header makes sense to me, but sending
blacklists with every request doesn't scale--such a list could easily
end up having dozens of entries, bloating the headers for every
request.  You may not actually want to expose your entire blacklist to
the public, either.

Blacklisting does seem like a fair use case, though; it often makes
sense to want to block particularly abusive sites, without blocking
everyone.


yes, hence suggesting to offer both, let the resource owners manage how 
they want :)




Re: [DOMCore] fire and dispatch

2011-03-01 Thread Aryeh Gregor
On Tue, Mar 1, 2011 at 8:51 AM, Boris Zbarsky bzbar...@mit.edu 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 this you would need to define exactly when and how many times the
 UA is supposed to get the clientX property of the second argument, for
 example.  That's a minimal requirement; there are probably other ratholes
 here that would need worrying about.  :(

 Alternately, we could require that all the properties be plain data
 properties or something, to avoid some of those pitfalls.

I think the latter sounds like the right way to go.  I can't imagine
any use-case where you'd need to set anything other than regular old
properties on the object (and I say that as someone who uses this
pattern a lot in my own code).



Re: [DOMCore] fire and dispatch

2011-03-01 Thread Ian Hickson
On Tue, 1 Mar 2011, Aryeh Gregor wrote:
 On Tue, Mar 1, 2011 at 8:51 AM, Boris Zbarsky bzbar...@mit.edu 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 this you would need to define exactly 
  when and how many times the UA is supposed to get the clientX 
  property of the second argument, for example.  That's a minimal 
  requirement; there are probably other ratholes here that would need 
  worrying about.  :(
 
  Alternately, we could require that all the properties be plain data 
  properties or something, to avoid some of those pitfalls.
 
 I think the latter sounds like the right way to go.  I can't imagine any 
 use-case where you'd need to set anything other than regular old 
 properties on the object (and I say that as someone who uses this 
 pattern a lot in my own code).

This is an issue with any of the APIs that use the structured clone 
algorithm also. Currently it can cause an infinite loop (if there's a 
getter). If anyone has any advice on how we should fix this problem, 
please comment on this bug:

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=12101

My current thinking is to just skip over any properties that have getters.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

2011-03-01 Thread Ian Hickson
On Tue, 1 Mar 2011, Anne van Kesteren wrote:
 On Sat, 26 Feb 2011 16:15:25 +0100, Doug Schepers schep...@w3.org 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 we can edit the spec together 
  amicably and productively.
 
 Do you have a bitbucket.org account? Ms2ger and I use 
 https://bitbucket.org/ms2ger/dom-core as our primary repository. We 
 typically coordinate editorial ideas in #whatwg and for them we also do 
 commit first, then review every so often. Changes to existing features 
 are brought up for discussion on public-webapps@w3.org, usually after we 
 sanity checked them with each other. So far we have avoided adding new 
 features as we would like to first reach some kind of stability with the 
 current DOM implementations. If this all works for you I think it can 
 work out.
 
 I have not run this by Ms2ger though I suspect he will agree.
 
 To be frank I am a little skeptical given our strained relationship to 
 date, but I am willing to give it a try.

I don't know if this helps, but for what it's worth, one thing that still 
needs defining and that is partly defined in the DOM 3 Events work that 
Doug has worked on but is not, and probably should not be, defined in the 
DOM Core work, is interaction events.

That is, defining the exact order of operations when a user clicks their 
mouse: how the target is picked (especially given weird cases like table 
cells and border-collapse, or SVG with pointer-events), what the various 
MouseEvent interfaces should be, all the stuff with key events that we've 
avoided defining for years, what events should be fired for joysticks, 
etc. This is critical work that really needs a serious effort and would 
be of huge help to the platform as a whole.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'



Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread Daniel Veditz
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 be happy(ish) to jettison frame-ancestors from CSP
if there's another competent header that can take up that use-case.
Mainly we wanted to fix X-Frame-Options (without introducing the
incompatibilities of embrace and extend) but didn't want to invent
yet another header to do it.

Depending on how it's eventually spec'd the Origin header could
satisfy the same use-case with server-side enforcement. For that to
happen it'd have to be sent with every request; not sure it's
specified that way currently.

Personally I'm more optimistic about client-enforced mechanisms
because you only need five or so correct browser implementations,
not tens or hundreds of app framework implementations. Either way
the site authors have to correctly specify their policy, of course,
and that's a big concern.

-Dan Veditz



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

2011-03-01 Thread Garrett Smith
On 3/1/11, Anne van Kesteren ann...@opera.com wrote:
 On Mon, 28 Feb 2011 18:49:48 +0100, Garrett Smith dhtmlkitc...@gmail.com
 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 DOM. Like XHR.

 Could Events Core exist on its own? (You could make DOM Core
 conformance require Events Core conformance).

 These are the reasons they are intertwined:

   * document.createEvent()
That was previously DocumentEvent interface, IIRC.

   * mutation events
Why can't those be defined independently in Events. (not a fan of
mutation events, BTW).

   * we want Node to inherit from EventTarget
That can be stated in DOM Core. For example: The Node Interface
implements EventTarget [Events Core].

   * both events and documents depend on the same tree concept
How do XHR events or progress events depend on tree concept?

   * INVALID_STATE_ERR is shared

XHR and Event instances can have invalid states, but should those
exceptions to have the same name and numerical representation?

Defining Errors within the API that uses them makes it easier to
change the Error.

 Of course, given a mutual dependency they could be split, but I do not
 really see the point.
Something that depends on Events Core doesn't necessarily need to
depend on DOMImplementation. I believe ProgressEvents is an existing
case of that. I like to define  specification to be specific. This
makes them easier to read and change.

Things that aren't related to document navigation can theoretically
implement EventTarget. Node stuff, for example, nextSibling and
cloneNode, aren't relevant to ProgressEvents.

Should the Exceptions section be split out too in
 your opinion? Given that Events and Exceptions are quite short and per
 the above summary quite integral to how everything fits together I think
 the current division makes sense.

No. Exceptions should not be in a separate specification; there is
no core Exception module or interfaces. I like having the exception
grouped with the API that uses it. INVALID_STATE_ERR for EventTarget
is conceptually different than for XMLHttpRequest. I don't like having
the same name for two different things.

For example, a program that redispatches an Event would be putting
that Event instance in an invalid state. Conversely, an
`XMLHttpRequest` that calls `send()` before `open()` also creates an
invalid state. However, to me, those are different scenarios.

These two scenarios don't have enough in common to justify giving them
the same numerical error code. I would actually prefer these two cases
to have different error names because I think it would ease debugging.
For instance, when an error message is missing or unhelpful, a web
search on the error name should result in something more closely
relevant to what caused the error. I'd stink to have a program with an
XHR problem and get an error, search the web for that error, find the
the Events API, and then go back to the program's event code.

I noticed that the DOM Core spec uses throw instead of raise. I
don't mind the change but it might be something that matters for IDL
formalism.
-- 
Garrett



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

2011-03-01 Thread Ryosuke Niwa
On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato m_k...@ga2.so-net.ne.jp 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, Chrome and Opera keep composition string after value is replaced by DOM,
 each behavior is different.

 This is the result for this test on each browsers.  When textbox has IME
 composition string such as ABCDEFG, then script (textbox.value = 123;) is
 called, textbox becomes...

 1. 123ABCDEFG (ABCDEFG keeps composition state and caret is after G).
 2. 123 (composition string is removed).
 3. ABCDEFG (ABCDEFG keeps composition state and caret is after G).

 Which behavior is right?  1 is Opera 11, 2 is Safari 5, and 3 is Chrome 10
 and IE9.


You must have tested Chrome improperly.  We currently have a bug in Chrome.
 To see the bug, open the attached test and type nihao with Chinese IME on
Windows or Mac.  Then press down array key.  The text is replaced by henhao
but henha is still marked and looks as if I'm compositing henha but if I
continue to type ma still with IME, then I observe that henhaomao is
shown inside the input element.  Once this bug is fixed, Chrome's behavior
should match that of Safari 5.

- Ryosuke



This test ensures WebKit clears marked text inside an input element when the value is programmatically set. To manually test, type in "nihao" using Chinese IME and then press the down arrow key. The text must be replaced by "henhao" without composition marker.






Re: [IndexedDB] Two Real World Use-Cases

2011-03-01 Thread Joran Greef
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 all the flexibility they need.
 
 You're talking about having multiple entries in a single index that point 
 towards the same primary key?  If so, then I strongly agree, and I think 
 others agree as well.  It's mostly a question of syntax.  A while ago we 
 brainstormed a couple possibilities.  I'll try to send out a proposal this 
 week.  I think this + compound keys should probably be our last v1 features 
 though.  (Though they almost certainly won't make Chrome 11 or Firefox 4, 
 unfortunately, hopefully they'll be done in the next version of each, and 
 hopefully that release with be fairly soon after for both.)

Yes, for example this user object { name: Joran Greef, emails: 
[jo...@ronomon.com, jorangr...@gmail.com] } with indexes on the emails 
property, would be found in the jo...@ronomon.com index as well as in the 
jorangr...@gmail.com index.

What I've been thinking though is that the problem even with formally 
specifying indexes in advance of object put calls, is that this pushes too much 
application model logic into the database layer, making the database enforce a 
schema (at least in terms of indexes). Of course IDB facilitates migrations in 
the form of setVersion, but most schema migrations are also coupled with 
changes to the data itself, and this would still have to be done by the 
application in any event. So at the moment IDB takes too much responsibility on 
behalf of the application (computing indexes, pre-defined indexes, pseudo 
migrations) and not enough responsibility for pure database operations (index 
intersections and index unions).

I would argue that things like migrations and schema's are best handled by the 
application, even if this is more work for the application, as most people will 
write wrappers for IDB in any event and IDB is supposed to be a core-level API. 
The acid-test must be that the database is oblivious to schemas or anything 
pre-defined or application-specific (i.e. stateless). Otherwise IDB risks being 
a database for newbies who wouldn't use it, and a database that others would 
treat as a KV anyway (see MySQL at FriendFeed).

A suggested interface then for putting or deleting objects, would be: 
objectStore.put(object, [indexname1, indexname2, indexname3]) and then 
IDB would need to ensure that the object would be referenced by the given index 
names. When removing the object, the application would need to provide the 
indexes again (or IDB could keep track of the indexes associated with an 
object).

Using a function to compute indexes would not work as this would entrap 
application-specific schema knowledge within the function (which would need to 
be persisted) and these may subsequently change in the application, which would 
then need a way to modify the function again. The key is that these things must 
be stateless.

The objects must be opaque to IDB (no need for serialization/deserialization 
overhead at the DB layer). Things like key-paths etc. could be removed and the 
object id just passed in to put or delete calls.

 2. Be able to intersect and union indexes. This covers a tremendous amount of 
 ground in terms of authorization and filtering.
 
 Our plan was to punt some sort of join language to v2.  Could you give a more 
 concrete proposal for what we'd add?  It'd make it easier to see if it's 
 something realistic for v1 or not.

If you can perform intersect or union operations (and combinations of these) on 
indexes (which are essentially sets or sorted sets), then this would be the 
join language. It has the benefit that the interface would then be described in 
terms of operations on data structures (set operations on sets) rather than a 
custom language which would take longer to spec out.

I've written databases over append-only files, S3, WebSQL and even LocalStorage 
(!) and from what I've found with my own applications, you could handle 
everything from multi-tenant authorization to adequate filtering with the 
following operations:

1. intersect([ index1, index2 ])
2. union([ index1, index2 ])
3. intersect([ union([ index1, index2 ]), index3, index4, index5, index6, 
index7 ])

Hopefully, a join language described in terms of pure set operations would be 
much simpler to implement and easier to use and reason with.

In fact I think if IDB offered only a single object store and an indexing 
system described above, it would be completely perfect. That's all that's 
needed. No need for a V2. Just a focus on high-performance thereafter.