Re: [whatwg] WebIDL vs HTML5 storage changes
delete means from memory, not from container in C++. In particular, delete member of object leaves the object in an inconsistent state, unless the member is already NULL, and therefore such a construct should never be used. The analogy is very inappropriate. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson Sent: Tuesday, May 20, 2008 1:53 AM To: Geoffrey Garen Cc: Maciej Stachowiak; WHATWG Mailing List Subject: Re: [whatwg] WebIDL vs HTML5 storage changes To give you an analogy, even in C++, where you're allowed to overload operator delete, if you overloaded operator delete to mean do not free this object's memory, but do delete the file it references from the file system, well, let's just say that your patch would not pass code review with any of your four reviewers :). But if you overloaded the delete operator to free the object's memory *and* delete its referenced files from the file system, you'd be using the operator overloading in its intended capacity.
Re: [whatwg] WebIDL vs HTML5 storage changes
Opacity of style is not quite the same thing because you compare a predefined property to an expando property. Predefined properties should not be deleted, deleting expando properties should be supported. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Tuesday, May 20, 2008 5:50 AM To: [EMAIL PROTECTED] Cc: Brady Eidson; WHATWG Mailing List Subject: Re: [whatwg] WebIDL vs HTML5 storage changes On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote: If storage.keyName = 'value'; can create a new storage item (persistently), won't authors expect delete storage.keyName; to remove it (persistently), as a matter of consistency? If overloading delete is too quirky or too hard to implement, then it seems none of the other shorthands should be allowed either. Many objects in the DOM implement custom name getters (for instance NodeList) and a few even implement custom name setters (CSSStyleDeclaration, at least the way it is done in WebKit) but no one has clamored for a custom deleter or expected delete to work as a matter of consistency or been confused that style.opacity = 0 is allowed but delete style.opacity is not. So I would say the available evidence argues against your conclusions. Regards, Maciej
[whatwg] StorageEvent deficiency
The StorageEvent has almost all the information in it that a script
would need, except one.
Imagine a multi-frame page where each document is from the same
security origin. In this case, if one document on the page changes
either a SessionStorage item or a LocalStorage item, the other
documents on the page have no way of knowing if the StorageEvent
generated is from changing SessionStorage or LocalStorage.
One might argue they could compare the changed key/value in the event
to their SessionStorage and LocalStorage and infer which one generated
the event, but this is not fool proof. There are a number of
situations that could arise where a script couldn't infer which
Storage object had changed.
I propose adding an additional property to the StorageEvent interface:
interface StorageEvent : Event {
...
readonly attribute Storage storageArea;
...
}
The name of the attribute is up in the air, but the point is that the
object would be either the SessionStorage object or the LocalStorage
object.
Thanks,
~Brady
Re: [whatwg] WebIDL vs HTML5 storage changes
On Mon, 19 May 2008, Maciej Stachowiak wrote:
On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote:
If storage.keyName = 'value'; can create a new storage item
(persistently), won't authors expect delete storage.keyName; to
remove it (persistently), as a matter of consistency?
If overloading delete is too quirky or too hard to implement, then
it seems none of the other shorthands should be allowed either.
Many objects in the DOM implement custom name getters (for instance
NodeList) and a few even implement custom name setters
(CSSStyleDeclaration, at least the way it is done in WebKit) but no one
has clamored for a custom deleter or expected delete to work as a
matter of consistency or been confused that style.opacity = 0 is
allowed but delete style.opacity is not. So I would say the available
evidence argues against your conclusions.
The difference is that style.opacity = 0 doesn't remove opacity from
the style object but storage.removeItem('opacity') _does_ remove
opacity from the storage object.
Originally, I wanted Storage objects to be indistinguishable from Object
objects in JS, and native hash or collection objects in other bindings.
Conceptually, that's what these objects are -- native name/value pair
collections that happen to be mapped to non-volatile storage (or somewhat-
volatile storage, in the case of sessionStorage).
I'd also like the delete operator to work on DOMStringMap (for the
dataset object -- calling 'delete' on that has the side-effect of removing
the underlying attribute) and UndoManager (where the side-effect is to
remove the entry and renumber the following entries, so maybe that's not
such a good idea after all), for what it's worth. If we want to decide
that we're not supporting this, we should decide that before
implementations of those come about.
For DOMStringMap, my intention was to not provide methods at all, and only
provide the JS-native mechanisms.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebIDL vs HTML5 storage changes
On May 20, 2008, at 2:00 PM, Ian Hickson wrote:
On Mon, 19 May 2008, Maciej Stachowiak wrote:
On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote:
If storage.keyName = 'value'; can create a new storage item
(persistently), won't authors expect delete storage.keyName; to
remove it (persistently), as a matter of consistency?
If overloading delete is too quirky or too hard to implement, then
it seems none of the other shorthands should be allowed either.
Many objects in the DOM implement custom name getters (for instance
NodeList) and a few even implement custom name setters
(CSSStyleDeclaration, at least the way it is done in WebKit) but no
one
has clamored for a custom deleter or expected delete to work as a
matter of consistency or been confused that style.opacity = 0 is
allowed but delete style.opacity is not. So I would say the
available
evidence argues against your conclusions.
The difference is that style.opacity = 0 doesn't remove opacity
from
the style object but storage.removeItem('opacity') _does_ remove
opacity from the storage object.
Yes, the analogy to storage.removeItem() would be
style.removeProperty(). You can't do delete style.opacity instead of
style.removeProperty('opacity') and as far as I can tell, no one has
ever asked to be able to use delete on style, or been especially
confused that they couldn't.
Originally, I wanted Storage objects to be indistinguishable from
Object
objects in JS, and native hash or collection objects in other
bindings.
Conceptually, that's what these objects are -- native name/value pair
collections that happen to be mapped to non-volatile storage (or
somewhat-
volatile storage, in the case of sessionStorage).
Normal objects don't fire DOM events when you change their properties
(I imagine the same may be true of native hash objects in at least
some languages), so the indistinguishability only goes so far.
I'd also like the delete operator to work on DOMStringMap (for the
dataset object -- calling 'delete' on that has the side-effect of
removing
the underlying attribute) and UndoManager (where the side-effect is to
remove the entry and renumber the following entries, so maybe that's
not
such a good idea after all), for what it's worth. If we want to decide
that we're not supporting this, we should decide that before
implementations of those come about.
Those both sound suboptimal to me. UndoManager because it remove more
than the one item, and DOMStringMap because (a) you can't delete from
NamedNodeMap to remove an attribute so it would be inconsistent and
(b) removing an attribute causes a mutation event to fire and thus
runs arbitrary code (creating the same problem of 'delete' running
arbitrary code as Storage).
For DOMStringMap, my intention was to not provide methods at all,
and only
provide the JS-native mechanisms.
A bold choice, but I would not recommend it as the sole available
mechanism.
Regards,
Maciej
Re: [whatwg] WebIDL vs HTML5 storage changes
On Tue, May 20, 2008 at 3:50 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote: If storage.keyName = 'value'; can create a new storage item (persistently), won't authors expect delete storage.keyName; to remove it (persistently), as a matter of consistency? If overloading delete is too quirky or too hard to implement, then it seems none of the other shorthands should be allowed either. Many objects in the DOM implement custom name getters (for instance NodeList) and a few even implement custom name setters (CSSStyleDeclaration, at least the way it is done in WebKit) but no one has clamored for a custom deleter or expected delete to work as a matter of consistency or been confused that style.opacity = 0 is allowed but delete style.opacity is not. So I would say the available evidence argues against your conclusions. I think 'style' does not bear on my conclusions, since 'style' has custom property getters and setters, but not *adders* --- style.foobar = ...; does not trigger any DOM API. Storage is different, it is something new. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] WebIDL vs HTML5 storage changes
On May 20, 2008, at 2:56 PM, Robert O'Callahan wrote: On Tue, May 20, 2008 at 3:50 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote: If storage.keyName = 'value'; can create a new storage item (persistently), won't authors expect delete storage.keyName; to remove it (persistently), as a matter of consistency? If overloading delete is too quirky or too hard to implement, then it seems none of the other shorthands should be allowed either. Many objects in the DOM implement custom name getters (for instance NodeList) and a few even implement custom name setters (CSSStyleDeclaration, at least the way it is done in WebKit) but no one has clamored for a custom deleter or expected delete to work as a matter of consistency or been confused that style.opacity = 0 is allowed but delete style.opacity is not. So I would say the available evidence argues against your conclusions. I think 'style' does not bear on my conclusions, since 'style' has custom property getters and setters, but not *adders* --- style.foobar = ...; does not trigger any DOM API. Storage is different, it is something new. style.opacity = ... certainly triggers DOM API even if opacity was not previously set on that style. And there is even a plausible mapping for delete (style.removeProperty). It's not completely open-ended but you can certainly have properties added to and removed from a style declaration. Ultimately the conclusion I question is that having obj.foo and obj.foo = ... work, but not delete obj.foo, will create confusion or is somehow illogical. I don't believe it will create confusion, and I think style is a relevant example of a case where it has not. Regards, Maciej
Re: [whatwg] WebIDL vs HTML5 storage changes
On Wed, May 21, 2008 at 10:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: style.opacity = ... certainly triggers DOM API even if opacity was not previously set on that style. The property was always there, though, from the JS point of view. And there is even a plausible mapping for delete (style.removeProperty). It's not completely open-ended but you can certainly have properties added to and removed from a style declaration. style.removeProperty does not remove the JS property, so from the JS point of view it's a misnomer. Ultimately the conclusion I question is that having obj.foo and obj.foo = ... work, but not delete obj.foo, will create confusion or is somehow illogical. I don't believe it will create confusion, and I think style is a relevant example of a case where it has not. FWIW, I see style.opacity = ''; far more often than removeProperty. I don't think authors don't think of 'style' as a container to which they can add and remove arbitrary properties, so I continue to maintain it's not relevant to their expectations for storage. I don't care all that much. But since it's convenience with some use, and we've already implemented it and so has IE, I think we'd want a pretty strong argument to remove it. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] Cross browser automated tests
Hi, I'm working on an experimental project to build a set of cross browser automated tests. The idea would be to have a repository of browser independent automated tests. Existing test suites could be imported into it. These tests could be run automatically on today's available browsers with the results published. Spec writers or web developers could check what feature is implemented on what browser and browser vendor could use that for their internal regression tests. Would WHATWG be interested in such a project? As a starting point, the testing environment and API would need to be defined. I'm thinking of the following requirements: * Possible for browser vendors to integrate these tests in their testing frameworks * Minimal modifications necessary for migrating existing non automated test cases like the ones on http://www.hixie.ch/tests or http://tc.labs.opera.com/. They should still report PASS/FAIL messages when run in a browser like they do now, which is convenient for testing test cases individually. To meet these goals, such an API should be as unobtrusive as possible: * One .js file to include * A set of functions that can be called for performing the checks and life cycle functions (end of tests, ...) Once this is defined, existing non automated test cases could be modified and imported in the repository. That could be lot of work if I'm looking at all the tests linked from http://wiki.whatwg.org/wiki/Test_cases, but I think there would be lots of benefit. The other big part of the work is to develop the framework for running these tests automatically and reporting the results. I've already done some experiments by running automated tests from Mozilla and WebKit. The results are visible on http://www.browsertests.org/. I started a thread on Mozilla [1] and WebKit lists [2]. There were some interesting discussions with Jeff Walden on the Mozilla list already. Sylvain [1] http://groups.google.com/group/mozilla.dev.quality/browse_thread/thread/b2a959c7547b9877 [2] https://lists.webkit.org/pipermail/webkit-dev/2008-May/003943.html
Re: [whatwg] Cross browser automated tests
Sylvain Pasche wrote: As a starting point, the testing environment and API would need to be defined. I'm thinking of the following requirements: * Possible for browser vendors to integrate these tests in their testing frameworks Hrm, I neglected to mention this on the other thread, but this requirement can't fly. It discourages creating libraries for common testing functions (or even just for non-testing functions, e.g. how Mochitests all have access to the entire MochiKit framework) and using them declaratively (hardcoded script versus dynamic addition with callback schemes), which just makes life harder if you're writing tests. Jeff -- Life would be so much easier if humans had a natural affinity for remembering 128-bit integers.
Re: [whatwg] Cross browser automated tests
On Wed, 21 May 2008, Sylvain Pasche wrote: I'm working on an experimental project to build a set of cross browser automated tests. The idea would be to have a repository of browser independent automated tests. Existing test suites could be imported into it. Would WHATWG be interested in such a project? I think that would be great; if you do go ahead with this, you are welcome to use the WHATWG wiki and other resources. I encourage you to use the implementors mailing list for this: http://www.whatwg.org/mailing-list#imps To meet these goals, such an API should be as unobtrusive as possible: * One .js file to include I recommend not embedding any JS, but instead requiring that the following two lines be used to report results (or something like them): if (parent.reportResults) parent.reportResults(...); ...and using iframes to embed the tests one after another. I use something similar for my performance tests: http://www.hixie.ch/tests/adhoc/perf/ This makes the test even easier to maintain, and also makes it a lot easier to reimplement the harness or to share tests between hardnesses. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Cross browser automated tests
Collin, James, and I have been working on cross-browser security testing as well. We've implemented a subset of the WebKit LayoutTestController for Firefox and ran the WebKit security LayoutTests on both Firefox 2 and Firefox 3 RC1. http://crypto.stanford.edu/websec/cross-testing/ There are a number of interesting failures, which we are investigating. On Tue, May 20, 2008 at 7:51 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 21 May 2008, Sylvain Pasche wrote: To meet these goals, such an API should be as unobtrusive as possible: * One .js file to include I recommend not embedding any JS, but instead requiring that the following two lines be used to report results (or something like them): if (parent.reportResults) parent.reportResults(...); The WebKit LayoutTestController might be a reasonable starting point for a testing API. Just calling parent.reportResults might be limiting for security testing because a frame might not be able to access its parent. For example, the LayoutTestController has a globally readable and writable boolean flag that helps cross-domain frames signal that the test is complete. ...and using iframes to embed the tests one after another. This is also limiting for security tests because some behavior must be tested in a top-level frame. This makes the test even easier to maintain, and also makes it a lot easier to reimplement the harness or to share tests between hardnesses. One of our goals for the project is to integrate with Firefox's testing harness. Ideally, the Firefox source tree could check out the WebKit LayoutTests unmodified and run them as part of their per-checkin regression testing. Adam
