Re: [whatwg] DOM Storage feedback

[Ian Hickson]

On Wed, 14 Jan 2009, Cameron McCormack wrote:
> 
> I began testing all attributes and operations with DOMString arguments 
> from a selection of specs for their behaviour wrt null and undefined:
> 
>   http://mcc.id.au/2009/01/string-handling/string-handling
> 
> Each pair of characters in the column for a browser is the behaviour for 
> null and undefined, respectively.  It’s nowhere near complete, though 
> you can see that there are some operations arguments and attributes that 
> stringify null to "null" (“S” in the column).

In particular it seems that IE does this reliably. After spot checking a 
few more using IE8, I have left the HTML5 spec and the other specs I work 
on at using the WebIDL defaults. If there are specific cases that people 
believe should be treated specially, please raise those explicitly.

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

Re: [whatwg] DOM Storage feedback

[Jonas Sicking]

On Tue, Jan 13, 2009 at 4:53 PM, Cameron McCormack  wrote:
> Jonas Sicking:
>> So it behaves different from passing in an empty string? For some
>> functions this surprises me, such as for the namespace parameter for
>> getAttributeNS, I would think that we there treat "" the same as null.
>
> Not necessarily, but I agree that would be a better thing to report.
> I'll rejig the tests to get that information.
>
> Cameron McCormack:
>> > OK.  So what is more important for choosing the default: fewer
>> > exceptions (and thus fewer [Null=…] things polluting the IDL),
>> > consistency with the default stringification behaviour of ECMAScript,
>> > or avoiding the somewhat counterintuitive default behaviour of
>> > converting a valid value of the type to a different value of that type?
>
>> "converting a valid value of the type to a different value of that
>> type", which values exactly?
>
> null.  It feels slightly strange to me to treat null as a "second class
> value" by default.  But I'll get over it. :-)

The point would be to not do it by default. I.e. default behavior is
to treat null as a valid value that is left untouched by default. And
only convert it to n-u-l-l when specified in IDL.

To answer your original question. I think the most important thing is
to have few exceptions that authors have to learn.

> It may actually be indicative of a need for two distinct types: strings
> (i.e., possibly empty sequences of characters) and strings-or-null.  But
> I don't know if it's worth rewriting everything in this way.

Yeah

/ Jonas

Re: [whatwg] DOM Storage feedback

[Cameron McCormack]

Jonas Sicking:
> So it behaves different from passing in an empty string? For some
> functions this surprises me, such as for the namespace parameter for
> getAttributeNS, I would think that we there treat "" the same as null.

Not necessarily, but I agree that would be a better thing to report.
I’ll rejig the tests to get that information.

Cameron McCormack:
> > OK.  So what is more important for choosing the default: fewer
> > exceptions (and thus fewer [Null=…] things polluting the IDL),
> > consistency with the default stringification behaviour of ECMAScript,
> > or avoiding the somewhat counterintuitive default behaviour of
> > converting a valid value of the type to a different value of that type?

> "converting a valid value of the type to a different value of that
> type", which values exactly?

null.  It feels slightly strange to me to treat null as a “second class
value” by default.  But I’ll get over it. :-)

It may actually be indicative of a need for two distinct types: strings
(i.e., possibly empty sequences of characters) and strings-or-null.  But
I don’t know if it’s worth rewriting everything in this way.

> I think another factor, that you haven't mentioned, that is very
> important is web compatibility. But beyond that I think I would rate
> fewer exceptions highest.

Well, I assume that writers of specs that document already-implemented
interfaces will choose the appropriate [Null] annotation (or lack of it)
for web compatibility.  Which to choose as the default is orthogonal, I
think.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [whatwg] DOM Storage feedback

[Jonas Sicking]

On Tue, Jan 13, 2009 at 4:26 PM, Cameron McCormack  wrote:
> Jonas Sicking:
>> So in the null column an "S" means that it's treated as "null", an "E"
>> as "", but what does "N" mean?
>
> "N" means that I was able to determine that null was treated as the
> actual null value, rather than converted to a string.

So it behaves different from passing in an empty string? For some
functions this surprises me, such as for the namespace parameter for
getAttributeNS, I would think that we there treat "" the same as null.

>> Yes, there are definitely a lot of "S"s in the null column for
>> non-firefox browsers. The question to me is if this is really needed
>> for webcompat though. Looking though our bug database I see no
>> indication of that, but that's not necessarily a proof.
>>
>> If we were able to use "" as the default behavior for null then we
>> would be able to get away with much fewer exceptions (so far alert()
>> and and possibly write() has been found).
>
> OK.  So what is more important for choosing the default: fewer
> exceptions (and thus fewer [Null=…] things polluting the IDL),
> consistency with the default stringification behaviour of ECMAScript,
> or avoiding the somewhat counterintuitive default behaviour of
> converting a valid value of the type to a different value of that type?

"converting a valid value of the type to a different value of that
type", which values exactly?

I think another factor, that you haven't mentioned, that is very
important is web compatibility. But beyond that I think I would rate
fewer exceptions highest.

/ Jonas

Re: [whatwg] DOM Storage feedback

[Cameron McCormack]

Jonas Sicking:
> So in the null column an "S" means that it's treated as "null", an "E"
> as "", but what does "N" mean?

"N" means that I was able to determine that null was treated as the
actual null value, rather than converted to a string.

> Yes, there are definitely a lot of "S"s in the null column for
> non-firefox browsers. The question to me is if this is really needed
> for webcompat though. Looking though our bug database I see no
> indication of that, but that's not necessarily a proof.
> 
> If we were able to use "" as the default behavior for null then we
> would be able to get away with much fewer exceptions (so far alert()
> and and possibly write() has been found).

OK.  So what is more important for choosing the default: fewer
exceptions (and thus fewer [Null=…] things polluting the IDL),
consistency with the default stringification behaviour of ECMAScript,
or avoiding the somewhat counterintuitive default behaviour of
converting a valid value of the type to a different value of that type?

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [whatwg] DOM Storage feedback

[Jonas Sicking]

On Tue, Jan 13, 2009 at 3:37 PM, Cameron McCormack  wrote:
> Jonas Sicking:
>> I talked with Cameron a while ago about what the default behavior
>> should be for null. We couldn't find any functions that required that
>> null be treated as "null", but there are several examples of functions
>> that require that null be treated as the empty string.
>
> I began testing all attributes and operations with DOMString arguments
> from a selection of specs for their behaviour wrt null and undefined:
>
>  http://mcc.id.au/2009/01/string-handling/string-handling
>
> Each pair of characters in the column for a browser is the behaviour for
> null and undefined, respectively.  It's nowhere near complete, though
> you can see that there are some operations arguments and attributes that
> stringify null to "null" ("S" in the column).

So in the null column an "S" means that it's treated as "null", an "E"
as "", but what does "N" mean?

Yes, there are definitely a lot of "S"s in the null column for
non-firefox browsers. The question to me is if this is really needed
for webcompat though. Looking though our bug database I see no
indication of that, but that's not necessarily a proof.

If we were able to use "" as the default behavior for null then we
would be able to get away with much fewer exceptions (so far alert()
and and possibly write() has been found).

/ Jonas

Re: [whatwg] DOM Storage feedback

[Cameron McCormack]

Jonas Sicking:
> I talked with Cameron a while ago about what the default behavior
> should be for null. We couldn't find any functions that required that
> null be treated as "null", but there are several examples of functions
> that require that null be treated as the empty string.

I began testing all attributes and operations with DOMString arguments
from a selection of specs for their behaviour wrt null and undefined:

  http://mcc.id.au/2009/01/string-handling/string-handling

Each pair of characters in the column for a browser is the behaviour for
null and undefined, respectively.  It’s nowhere near complete, though
you can see that there are some operations arguments and attributes that
stringify null to "null" (“S” in the column).

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [whatwg] DOM Storage feedback

[Maciej Stachowiak]

On Jan 13, 2009, at 11:28 AM, Anne van Kesteren wrote:

On Tue, 13 Jan 2009 19:32:16 +0100, Jonas Sicking   
wrote:
On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren  
 wrote:

alert() requires it.


How so? I couldn't imagine how a site could depend on that.


Debugging, for one. You can't mean that you'd consider making  
alert(null) give a dialog that contains the empty string rather than  
"null".


Yeah, we definitely shouldn't change this for alert or document.write






Besides that I believe we (Opera) specifically did it
for methods here and there to be more compatible with Internet  
Explorer and make sites work better.


Do you know of any sites worked better because of the change? Or
indeed that were affected at all by the change?


No, sorry. I believe WebKit is doing it as well though for a number  
of methods/attributes, but it's been a while since I looked into this.


We have marked up some of the attributes and method parameters where  
the null value must be treated as "" instead of "null" with  
ConvertNullToNullString in our IDL. There are a number of method  
parameters that are not marked that way, but I'm not sure how many of  
these require the normal ECMAScript behavior and how many just haven't  
been changed.


Regards,
Maciej

Re: [whatwg] DOM Storage feedback

[Anne van Kesteren]

On Tue, 13 Jan 2009 19:32:16 +0100, Jonas Sicking  wrote:
On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren   
wrote:

alert() requires it.


How so? I couldn't imagine how a site could depend on that.


Debugging, for one. You can't mean that you'd consider making alert(null)  
give a dialog that contains the empty string rather than "null".




Besides that I believe we (Opera) specifically did it
for methods here and there to be more compatible with Internet Explorer  
and make sites work better.


Do you know of any sites worked better because of the change? Or
indeed that were affected at all by the change?


No, sorry. I believe WebKit is doing it as well though for a number of  
methods/attributes, but it's been a while since I looked into this.



--
Anne van Kesteren

Re: [whatwg] DOM Storage feedback

[Jonas Sicking]

On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren  wrote:
> On Tue, 13 Jan 2009 13:44:22 +0100, Jonas Sicking  wrote:
>>
>> I talked with Cameron a while ago about what the default behavior
>> should be for null. We couldn't find any functions that required that
>> null be treated as "null", but there are several examples of functions
>> that require that null be treated as the empty string.
>
> alert() requires it.

How so? I couldn't imagine how a site could depend on that.

That said, this did make me think about document.write, where we do
seem to display 'null' rather than empty string. So this might be an
exception.

> Besides that I believe we (Opera) specifically did it
> for methods here and there to be more compatible with Internet Explorer and
> make sites work better.

Do you know of any sites worked better because of the change? Or
indeed that were affected at all by the change?

/ Jonas

Re: [whatwg] DOM Storage feedback

[Anne van Kesteren]

On Tue, 13 Jan 2009 13:44:22 +0100, Jonas Sicking  wrote:

I talked with Cameron a while ago about what the default behavior
should be for null. We couldn't find any functions that required that
null be treated as "null", but there are several examples of functions
that require that null be treated as the empty string.


alert() requires it. Besides that I believe we (Opera) specifically did it  
for methods here and there to be more compatible with Internet Explorer  
and make sites work better.




So from a code purity point of view it would be nicer if we could make
the default behavior be that null is treated as "null" as that would
require fewer exceptions.

The downside is that it would be a bigger change for more UAs than
going the other way around. So there's more risk of compat problems.


Indeed, I would rather not change Opera's behavior where we stringify just  
like Internet Explorer without some kind of data that shows it will not  
give problems.



--
Anne van Kesteren

Re: [whatwg] DOM Storage feedback

[Jonas Sicking]

On Tue, Jan 13, 2009 at 1:41 AM, Ian Hickson  wrote:
> On Mon, 28 Apr 2008, Brady Eidson wrote:
>>
>> Anne was asserting that since the interface for setItem() specifies a
>> DOMString as the input, anything you pass it will be stringified.
>> Therefore passing it the null value would be stringified to "null".
>> This is what you currently see in all the major browsers with
>> window.alert(null), for example, which is also specified as a DOMString
>> input parameter.
>>
>> Therefore a call to setItem("foo", null); becomes, in effect,
>> setItem("foo", "null");
>>
>> Is this correct?
>>
>> If so, the spec is fine as-is, and removeItem() is the only way to
>> remove an individual item.
>
> That is correct, at least currently. I am tempted to change this to
> [Null=Empty], though (i.e. make 'null' act like the empty string).
> However, I'm somewhat stuck on this as it depends on what happens with
> [Null] in WebIDL.

I talked with Cameron a while ago about what the default behavior
should be for null. We couldn't find any functions that required that
null be treated as "null", but there are several examples of functions
that require that null be treated as the empty string.

So from a code purity point of view it would be nicer if we could make
the default behavior be that null is treated as "null" as that would
require fewer exceptions.

The downside is that it would be a bigger change for more UAs than
going the other way around. So there's more risk of compat problems.

/ Jonas

Re: [whatwg] DOM Storage feedback

[Ian Hickson]

On Mon, 28 Apr 2008, Brady Eidson wrote:
> 
> Anne was asserting that since the interface for setItem() specifies a 
> DOMString as the input, anything you pass it will be stringified.  
> Therefore passing it the null value would be stringified to "null".  
> This is what you currently see in all the major browsers with 
> window.alert(null), for example, which is also specified as a DOMString 
> input parameter.
> 
> Therefore a call to setItem("foo", null); becomes, in effect, 
> setItem("foo", "null");
> 
> Is this correct?
> 
> If so, the spec is fine as-is, and removeItem() is the only way to 
> remove an individual item.

That is correct, at least currently. I am tempted to change this to 
[Null=Empty], though (i.e. make 'null' act like the empty string). 
However, I'm somewhat stuck on this as it depends on what happens with 
[Null] in WebIDL.

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

Re: [whatwg] DOM Storage feedback

[Anne van Kesteren]

On Mon, 28 Apr 2008 23:14:03 +0200, Brady Eidson <[EMAIL PROTECTED]> wrote:
I would like to make sure that my understanding is correct here, since  
you expressed doubt.


Anne was asserting that since the interface for setItem() specifies a  
DOMString as the input, anything you pass it will be stringified.   
Therefore passing it the null value would be stringified to "null".   
This is what you currently see in all the major browsers with  
window.alert(null), for example, which is also specified as a DOMString  
input parameter.


Therefore a call to setItem("foo", null); becomes, in effect,  
setItem("foo", "null");


Is this correct?

If so, the spec is fine as-is, and removeItem() is the only way to  
remove an individual item.


This was what I was suggesting, yes.


--
Anne van Kesteren

Re: [whatwg] DOM Storage feedback

[Brady Eidson]

On Apr 27, 2008, at 5:32 PM, Ian Hickson wrote:


On Thu, 10 Apr 2008, Brady Eidson wrote:


In 4.10.5, the description of the properties on the StorageEvent  
object
mentions "...its newValue attribute set to the new value of the key  
in

question, or null if the key was removed..."

So a web author can assume that when handling a StorageEvent whose
newValue property is null that the event was the result of a
removeItem(), and the key is no longer in the list.

However in 4.10.2 in the discussion of setItem(), there is no mention
that null is not an allowed value.  Something like
sessionStorage.setItem("key", null) is not forbidden, therefore it is
allowed, and it would result in a StorageEvent with a null newValue.

To resolve this case, I propose that we specify that the value in a  
key/value

pair cannot be set to null.
I see two clean ways to specify this:

1 - Throw an exception when setItem() is called with a null value.
2 - Specify setItem(key, null) to have the exact same effects as
removeItem(key).

I prefer #2.  Thoughts?


On Fri, 11 Apr 2008, Anne van Kesteren wrote:


Euhm, setItem() takes two strings. Therefore I'd expect null,  
undefined,

etc. to be stringified.


On Thu, 10 Apr 2008, Brady Eidson wrote:


Ugh... yup.  You're right.

Nevermind!


I'm not sure I understand why this is not an isue, but ok.


I would like to make sure that my understanding is correct here, since  
you expressed doubt.


Anne was asserting that since the interface for setItem() specifies a  
DOMString as the input, anything you pass it will be stringified.   
Therefore passing it the null value would be stringified to "null".   
This is what you currently see in all the major browsers with  
window.alert(null), for example, which is also specified as a  
DOMString input parameter.


Therefore a call to setItem("foo", null); becomes, in effect,  
setItem("foo", "null");


Is this correct?

If so, the spec is fine as-is, and removeItem() is the only way to  
remove an individual item.


~Brady




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

[whatwg] DOM Storage feedback

[Ian Hickson]

On Tue, 19 Feb 2008, Ralf Stoltze wrote:
>
> I found three more occurrences of "global storage area" in the current 
> version, in 4.10.6.2 and 4.10.7.1.

Fixed.


> And a minor typo in 4.10.5: "hte" --> "the"

Thanks. Fixed.


On Thu, 13 Mar 2008, Dave Camp wrote:
> 
> 4.10.6.1 still talks about quotas being per-domain-setting-the-value vs. 
> per-storage-area, this is no longer relevant.

Fixed.


On Fri, 21 Mar 2008, Sunava Dutta wrote:
> 
> Meanwhile, we have feedback for the draft that we feel and hope will 
> contribute to the existing repository of web developer's tools. Here are 
> a few enhancements that we've implemented. We think these features are 
> good for developers and want to add them to the spec. MSDN is being 
> updated so for more details please refer to the 
> API.
> 
> Storage.remainingSpace
>
> A straightforward and popular request, this API provides a script to 
> check the remaining persistent storage spec available to it, in bytes. 
> It's a very useful feature to allow pages to manage their store better.
> 
> *  We currently return bytes but perhaps returning the 
> number of characters is more useful? We'd love to hear thoughts here...

The problem with this feature is that there are a number of ways to store 
data, and thus no way to know exactly how much data can be stored.

For example, if the UA stores data in UTF-8 characters, the number of 
characters left to store will vary based on what characters are to be 
stored. Similarly, if the UA stores data in a compressed fashion, the 
number of bytes will vary based on how compressible the data is. 
Furthermore, we don't want to preclude user agents from dynamically 
increasing the amount of available storage based on user actions, for 
example the UA could automatically increase the storage every time the 
user interacts with the page, or could prompt the user to increase the 
storage when it gets to 80%.

Thus this API really can't easily work in an interoperable fashion.


> Clear All API
> Storage.clear()
>
> An obvious benefit for the persistent store, unlike 
> removeItem, 
> this API removes all key/value pairs accessible to that script without 
> requiring costly iteration over all data entries.

Added.


> Asynchronous model for DOM 
> Storage:
> The spec calls for atomic setItem() and removeItem() with respect to 
> changes to the data storage area. This is valuable since it ensures that 
> data is written to disk successfully. One of the major differences today 
> between what we've implemented is that we went down an "asynchronous" 
> path.  This is because there are significant performance advantages if 
> committing to the disk can be delayed while providing the data instantly 
> from memory.  Our model is exposed the same as a synchronous model to 
> the web developer so there should be no differences to the developer who 
> is interested in programming it using no new APIs other than that 
> specified in the HTML 5.0 spec. Here are some of the reasons why the 
> asynchronous model was chosen:
> 
> 1. It offers much better performance without sacrificing the persistence 
> to disk -- we will fire an event to confirm commit so web applications 
> can listen to the event when persistence is a concern.
> 
> 2.  Our customer outreach leads us to believe that the DOM Storage is 
> primarily used as local cache to improve responsiveness. The performance 
> cost of synchronous storage in our opinion outweighs the need for 
> guaranteed persistence.
> 
> 3.  It avoids a possible hang in the UI thread if the operation takes 
> long time and therefore makes the browsing experience more fluid.

The API is designed in such a way that UAs can implement a lazy commit on 
the back end, but this should not be exposed to the author -- there is no 
reason for the author to need to know whether the data is in RAM, flash 
storage, disk storage, remote tape storage, or whatever.

> Hence we created an async model. As far as the web developer is 
> concerned, the data will be available immediately from memory when the 
> onstorage event it fired so the behavior is the similar and no new APIs 
> are needed, hence its backwards compatible with other implementations. 
> In addition, an onstoragecommit event is fired for developers who want 
> to ensure the data is persisted to disk successfully.
>
> Begin/Commit
> 
> Storage.begin()
> 
> Storage.commit()
> 
> It's an application level concept that web authors who want a set of 
> values to be committed at once can use. Data is either committed in its 
> entirety (batch commit) or not. This is especially critical given that 
> DOM Storage is primarily used for name/value pair op