Re: [whatwg] Storage mutex

[Jeremy Orlow]

On Tue, Aug 25, 2009 at 10:28 PM, Robert O'Callahan wrote:

> On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow wrote:
>
>> To me, getStorageUpdates seems to imply that updates have already happened
>> and we're working with an old version of the data.  I think many developers
>> will be quite shocked that getStorageUpdates _enables_ others to update
>> storage.  In other words, 'get' seems to imply that you're consuming state
>> that's happening anyway, not affecting behavior.
>>
>
> fetchStorageUpdates?


fetch has the same problem.  If we want to keep the "StorageUpdates" suffix,
I'd go with something like allowStorageUpdates.  But, no matter what, it
just doesn't seem very clear that you're actively allowing another thread to
use the storage mutex.

What about yieldStorageMutex?  Yield is enough different from unlock that I
don't think it'll leave developers looking for the lock function.  Yield
fits pretty well since this is essentially cooperative multi-tasking.
 StorageMutex is good because that's what its actually affecting.

Re: [whatwg] Storage mutex

[Robert O'Callahan]

On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow  wrote:

> To me, getStorageUpdates seems to imply that updates have already happened
> and we're working with an old version of the data.  I think many developers
> will be quite shocked that getStorageUpdates _enables_ others to update
> storage.  In other words, 'get' seems to imply that you're consuming state
> that's happening anyway, not affecting behavior.
>

fetchStorageUpdates?

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] formNoValidate/novalidate/willValidate

[Peter Kasting]

On Tue, Aug 25, 2009 at 7:56 PM, Dean Edwards wrote:

> Looking through the spec I see the following DOM properties:
>
> * formNoValidate
> * novalidate
> * willValidate
>
> "novalidate" sticks out like a sore thumb. Can we change it to
> "noValidate". It's only mentioned in the IDL so maybe it's a typo.


IIRC when we (my GSoC student and I; he's been working on form validation in
WebKit) encountered this recently, we assumed it was a typo, and I used the
snazzy little "file a bug from directly on this page" UI on the spec to note
it.

PK

Re: [whatwg] HTML5 History Management

[Ian Hickson]

On Sun, 16 Aug 2009, Mike Wilson wrote:
> Ian Hickson wrote:
> > On Wed, 5 Aug 2009, Nathan Hammond wrote:
> > > I should have stated this one with a goal: the ability to ensure 
> > > that the popstate event always fires with a full understanding of 
> > > the (app/page) state when navigating through history. This would be 
> > > lost when a user manually changes the hash. With that as my goal, 
> > > history.replace does not achieve what I am trying to accomplish. 
> > > Neither does pushState without a URL as that still registers a new 
> > > history point.
> > 
> > All the information about the state really should be in the URL, such 
> > that the state of the app after the user manually changes the hash, 
> > and the state of the app after the user returns to a point in the 
> > history where he had manually changed the hash, really should be the 
> > same.
> 
> This has never been true for server-side web applications so why should 
> it be this way for client-side apps?

It's always supposed to be true for server-side Web apps too, no?


> My understanding of the purpose of pushState has been that it is there 
> to aid client-side apps in behaving like server- side apps wrt history 
> traversal. Not to make them more different and break user expectations.

Your understanding is correct.


> > I don't think we should encourage cases where the same URL can 
> > correspond to multiple states, which this would encourage.
> 
> This statement confuses me as the whole point of pushState seems to be 
> to store unique state in addition to the URL. If the URL can be used to 
> infer the state anyway, then what's the point of storing it in the 
> history entry?

It's mostly about being able to track extra state that isn't important to 
the user. For example, if you have an application with many boxes, and two 
states, one with one box open, and another with another box open, and the 
boxes are randomly dotted around but move when a box is opened or closed, 
and you then hit back-forward-back-forward, you would want the same two 
boxes to move in the same way each time. However, if you just jump 
straight to the URI representing those two states, the exact position of 
the boxes doesn't matter, and might differ each time. The state object is 
for keeping track of that kind of thing (the position of the boxes).


> Though, when taking a more thorough look at what is spec:ed, it seems 
> these use cases are indeed not supported, due to state update 
> limitations and how events are ordered.

I've tried to fix this by making popstate more synchronous.


> > > [suggesting .hashvalue on hashchange event]
> > 
> > I really don't follow.
> > 
> > Imagine you're updating what's visible based on the hash, and the user 
> > changes the hash twice in a row quickly such that by the time you get 
> > the first event, the location's already changed again. Why wouldn't 
> > you be happy to ignore the first location?
> 
> F ex, because your client-side app may update some state based on what 
> (or how many times) individual fragments have been visited. Maybe 
> something in the spirit of "read count" or so.

Fair enough. I've made hashchange synchronous also.


> Two other notes about the history state mechanism:
> 
> 1) The "popstate" event is sort of a misnomer as it doesn't "pop" the 
> state. Popping would imply removing it from its stack, but this is not 
> the case as it remains in place in the history to be retrieved any 
> number of times. A better name could be something like "restorestate".

That's possible. onrestorestate="" is not as clear as onpopstate="", 
though, so I've not chnged it.


> 2) This text at the end of 6.10.1:
> | When state object entries are added, a URL can be 
> | provided. This URL is used to replace the state object 
> | entry if the Document is evicted.
> I'm not sure how to interpret this. Does it (implicitly) 
> say that all state objects are evicted when the owning 
> Document is evicted?

That text is meaningless. I've removed it.


> One super-minor nit: 
> 
> In 6.10.3 we have:
> | (which happens during [[session history traversal]], as 
> | described above)
> The link points to 6.11.9 which is below, not above.

Thanks, fixed.

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

[whatwg] formNoValidate/novalidate/willValidate

[Dean Edwards]

Hi all,

It's been a while. :)

Looking through the spec I see the following DOM properties:

* formNoValidate
* novalidate
* willValidate

"novalidate" sticks out like a sore thumb. Can we change it to 
"noValidate". It's only mentioned in the IDL so maybe it's a typo.


-dean

[whatwg] brief question on 2.4.5 Dates and times

[Silvia Pfeiffer]

Hi,

I am trying to use the specification of Dates and times given in section
2.4.5.

I was surprised to find that there is a specification of a valid month
string, but not of a valid year string or a valid day string. Is that an
oversight?

Regards,
Silvia.

Re: [whatwg] SharedWorkers and the name parameter

[Jim Jewett]

On Tue, Aug 25, 2009 at 7:24 PM, Ian Hickson wrote:

> Drew Wilson wrote:
>> Per section 4.8.3 of the SharedWorkers spec,
>> if a page loads a shared worker with a url and
>> name, it is illegal for any other page under the
>> same origin to load a worker with the same name

> The idea here is that if you have an app that
> does database manipulation, you might want to
> ensure there is only ever one shared worker
> doing the manipulation, so you might decide
> on a shared worker name that is in charge of
> that, and then you can be sure that you don't
> accidentally start two workers with that name
> using different copies of a script

So the name is really intended as a (lightweight) URN, but it can
default to the URL?

-jJ

Re: [whatwg] Web Storage: apparent contradiction in spec

[Aryeh Gregor]

On Tue, Aug 25, 2009 at 5:44 PM, Jeremy Orlow wrote:
> Ok, well I guess we should go ahead and have this discussion now.  :-)  Does
> anyone outside of Apple and Google have an opinion on the matter (since I
> think it's pretty clear where we both stand).

FWIW, I initially thought localStorage deserved to be treated more
like cookies, because I felt that localStorage wouldn't be reliable
from a user perspective anyway -- using different browsers, etc.  But
I was convinced by the analogy to bookmarks and settings, and
use-cases like prolonged offline use, or use that's offline from the
beginning (e.g., HTML/CSS/JS-based apps that you download and install
like desktop apps).  It seems valuable to guarantee the data will be
as persistent as bookmarks and so forth.

[whatwg] Adding alpha channel to

[Victor Vasiliev]

Section 4.10.4.1.15 says that color must be in sRGB. However, it may be
handful for some applications to have alpha channel specified, since
many GUI libraries (GTK has it; I'm also told Mac OS supports it as
well) support color picker with opacity control.

I suggest to add a boolean attribute "alpha" to 
(disabled by default). If this attribute is present, the color well
allows to set opacity value, and instead of sRGB, sends RGBA.

Another question is which format should be used to submit RGBA color. We
have rgba(number, number, number, float) used in canvas, but I feel like
it's not the best format to be used in submited data. Maybe #rrggbbaa or
#aarrggbb?

--vvv

Re: [whatwg] Web Storage: apparent contradiction in spec

[Jeremy Orlow]

On Tue, Aug 25, 2009 at 4:18 PM, Brady Eidson  wrote:

>
> On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote:
>
> On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman  wrote:
>
>> On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow wrote:
>>
>> Extensions are an example of an application that is less cloud-based.
>> It would be unfortunate and weird for extension developers to have to
>> worry about their storage getting tossed because the UA is running out
>> of disk space.
>
>
> Extensions are pretty far out of scope of the spec (at least for now),
> right?  (Within Chrome, we can of course special case this.)
>
>
> The current spec is about "Web Applications" of all forms, including those
> that are offline, and others that hope to break from from the *required*
> chain to the cloud.
>
> Extensions based on web technology are just one form of this.
>  Widgets/gadgets are another.  Stand alone web applications are yet another.
>  Native applications that integrate HTML for their UI are another still.
>
> On Tue, Aug 25, 2009 at 3:09 PM, Jens Alfke  wrote:
>
>> Interesting comments. Linus and Jeremy appear to be coming at this from a
>> pure "cloud" perspective, where any important or persistent data is kept on
>> a remote server and the browser, so local storage can be treated as merely a
>> cache. That's definitely a valid position, but from my perspective, much of
>> the impetus for having local storage is to be able to support *other* 
>> application
>> models, where important data is stored locally. If browsers are free to
>> dispose HTML5 local storage without the user's informed consent, such
>> applications become dangerously unreliable.
>> For example, Linus wrote:
>>
>> User agents need to be free to garbage collect any local state. If they
>> can't then attackers (or the merely lazy) will be able to fill up the user's
>> disk. We can't expect web sites or users to do the chore of taking out the
>> garbage.
>>
>>
>> Replace "user agent" -> "operating system" and "local state" -> "user
>> files", and you have an argument that, when the hard disk in my MacBook gets
>> too full, the OS should be free to start randomly deleting my local files to
>> make room. This would be a really bad idea.
>>
>
> Well, it's certainly different from what we're used to.  I'm not convinced
> it's wrong though.  The web has gotten by pretty well with such a model so
> far.
>
>
> But behind the scenes, developers have shoehorned their own data storage
> solutions in to place because there hasn't been a good solution in place.
>
> Why should an app that is largely about client side experience have to
> store user preferences in cookies and hope they won't be purged, or load a
> plug-in that has reliable local storage, or sync preferences over the cloud
> to a server?
>
>
>  Similar analogies —
>> • If the SD card in my Wii fills up, should the system automatically start
>> deleting saved games?
>> • If my iPhone's Flash disk gets full, should it start deleting photos?
>> What if I haven't synced those photos to my iTunes yet?
>>
>> In each of those cases, what the device actually does is warns you about
>> the lack of free space, and lets you choose what to get rid of.
>>
>
> It's worth noting that today, OSs do a pretty poor job of helping you with
> this task.  (I don't see any reason why the spec will prohibit UAs from
> creating a good UI for this, though.)
>
>
> I completely agree OSs do a pretty poor job of helping with the task.
>  Browsers might be an innovating space here.  I challenge you to come up
> with a great UI for this that shows up in a UA.  I challenge the WHATWG to
> not decide that deleting user data is okay because it's the easiest way
> out.
>
>
>
>> Local storage is different from cloud storage. The HTML5 storage API can
>> be used for both, so it shouldn't be limited to what's convenient for just
>> one of them.
>>
>
> I still don't understand what use local storage has outside of 'cloud
> storage'.  Even in the extensions use case (which I think is out of scope
> for this spec), there's no reason you can't sync user preferences and such
> to the cloud.
>
>
> Once thing I think that HTML5 has made clear is that "web technologies" are
> no longer exclusively about "web sites" that exist solely "in the cloud."
>  Widgets/gadgets, html-based extensions, offline web applications, and
> native applications that use HTML/JS/CSS to embed parts of their UI are
> *all* covered by HTML5, and I don't think requiring the cloud for any of
> them is necessary.
>
> Also - and I don't mean this to be flippant, I raise it as a serious point
> - not all web application developers are Google or Apple with access to a
> server infrastructure.  To many web developers, just "throwing data up on a
> server somewhere" is outside the constraints of their resources or their
> design.
>
> The cloud is within the scope of web technologies, but web technologies
> should not rely on the cloud.
>
> By the way, in case it's not clear, my po

Re: [whatwg] SharedWorkers and the name parameter

[Ian Hickson]

Drew Wilson wrote:
>
> Currently, SharedWorkers accept both a "url" parameter and a "name" 
> parameter - the purpose is to let pages run multiple SharedWorkers using 
> the same script resource without having to load separate resources from 
> the server.
>
> Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared 
> worker with a url and name, it is illegal for any other page under the 
> same origin to load a worker with the same name but a different URL -- 
> the SharedWorker name becomes essentially a shared global namespace 
> across all pages in a single origin. This causes problems when you have 
> multiple pages under the same domain (ala geocities.com) - the pages all 
> need to coordinate in their use of "name". Additionally, a typo in one 
> page (i.e. invoking SharedWorker("mypagescript?", "name") instead of 
> SharedWorker("mypagescript", "name") will keep all subsequent pages in 
> that domain from loading a worker under that name so long as the 
> original page resides in the page cache. I'd* like to propose changing 
> the spec so that the name is not associated with the origin, but instead 
> with the URL itself.
>
> So if a page wanted to have multiple instances of a SharedWorker using
> the same URL, it could do this:
> new SharedWorker("url.js", "name");
> new SharedWorker("url.js", "name2");
> 
> Nothing would prevent a page from also doing this, however:
> new SharedWorker("other_url.js", "name");

The idea here is that if you have an app that does database manipulation, 
you might want to ensure there is only ever one shared worker doing the 
manipulation, so you might decide on a shared worker name that is in 
charge of that, and then you can be sure that you don't accidentally start 
two workers with that name using different copies of a script (e.g. 
because you have two installations of WordPress and they both use relative 
URLs to the same script in their respective locations).


On Sat, 15 Aug 2009, Jim Jewett wrote:
> >
> > Currently, SharedWorkers accept both a "url" parameter and a "name" 
> > parameter - the purpose is to let pages run multiple SharedWorkers 
> > using the same script resource without having to load separate 
> > resources from the server.
> > 
> > [ request that name be scoped to the URL, rather than the entire 
> > origin, because not all parts of example.com can easily co-ordinate.]
> 
> Would there be a problem with using URL fragments to distinguish the 
> workers?
> 
> Instead of:
> new SharedWorker("url.js", "name");
> 
> Use
> new SharedWorker("url.js#name");
> and if you want a duplicate, call it
> new SharedWorker("url.js#name2");
> 
> The normal semantics of fragments should prevent the repeated server fetch.

That seems like abuse of the fragment identifier syntax.


On Mon, 17 Aug 2009, Michael Nordman wrote:
>
> What purpose the the 'name' serve?

It's intended to prevent two scripts from being opened for the same 
purpose by mistake.


> Can the 'name' be used independently of the 'url' in any way?

No.


> * Is 'name' visible to the web developer any place besides those two?

No.


On Tue, 18 Aug 2009, Drew Wilson wrote:
>
> An alternative would be to make the "name" parameter optional, where 
> omitting the name would create an unnamed worker that is 
> identified/shared only by its url.
>
> So pages would only specify the name in cases where they actually want 
> to have multiple instances of a shared worker.

Done.


On Sun, 16 Aug 2009, Mike Wilson wrote:
> Drew Wilson wrote:
> > Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared 
> > worker with a url and name, it is illegal for any other page under the 
> > same origin to load a worker with the same name but a different URL -- 
> > the SharedWorker name becomes essentially a shared global namespace 
> > across all pages in a single origin. This causes problems when you 
> > have multiple pages under the same domain (ala geocities.com) - the 
> > pages all need to coordinate in their use of "name".
> 
> I agree with you that this is a problem, and the same problem exists in 
> WebStorage (storage areas are set up per origin). F ex, the sites 
> http://www.google.com/calendar and http://www.google.com/reader, and 
> every other site based off www.google.com will compete for the same keys 
> in one big shared storage area.
> 
> It seems lately everything is being based on having unique host names, 
> and path is not being considered anymore, which I think it should.

The reason it's not is that it would mislead people into thinking that you 
could do things safely based just on the path, which you can't. A script 
could trivially poke into another path's databases or cookies, e.g.


On Mon, 17 Aug 2009, Laurence Ph. wrote:
>
> | If worker global scope's location attribute represents an absolute 
> | URL that is not *exactly equal* to the resulting absolute URL, then 
> | throw a URL_MISMATCH_ERR exception and abort all these steps.
>
> Seems 

Re: [whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote:


On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman  wrote:
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow  
wrote:


Extensions are an example of an application that is less cloud-based.
It would be unfortunate and weird for extension developers to have to
worry about their storage getting tossed because the UA is running out
of disk space.

Extensions are pretty far out of scope of the spec (at least for  
now), right?  (Within Chrome, we can of course special case this.)


The current spec is about "Web Applications" of all forms, including  
those that are offline, and others that hope to break from from the  
*required* chain to the cloud.


Extensions based on web technology are just one form of this.  Widgets/ 
gadgets are another.  Stand alone web applications are yet another.   
Native applications that integrate HTML for their UI are another still.



On Tue, Aug 25, 2009 at 3:09 PM, Jens Alfke  wrote:
Interesting comments. Linus and Jeremy appear to be coming at this  
from a pure "cloud" perspective, where any important or persistent  
data is kept on a remote server and the browser, so local storage  
can be treated as merely a cache. That's definitely a valid  
position, but from my perspective, much of the impetus for having  
local storage is to be able to support other application models,  
where important data is stored locally. If browsers are free to  
dispose HTML5 local storage without the user's informed consent,  
such applications become dangerously unreliable.


For example, Linus wrote:
User agents need to be free to garbage collect any local state. If  
they can't then attackers (or the merely lazy) will be able to fill  
up the user's disk. We can't expect web sites or users to do the  
chore of taking out the garbage.


Replace "user agent" -> "operating system" and "local state" ->  
"user files", and you have an argument that, when the hard disk in  
my MacBook gets too full, the OS should be free to start randomly  
deleting my local files to make room. This would be a really bad idea.


Well, it's certainly different from what we're used to.  I'm not  
convinced it's wrong though.  The web has gotten by pretty well with  
such a model so far.


But behind the scenes, developers have shoehorned their own data  
storage solutions in to place because there hasn't been a good  
solution in place.


Why should an app that is largely about client side experience have to  
store user preferences in cookies and hope they won't be purged, or  
load a plug-in that has reliable local storage, or sync preferences  
over the cloud to a server?




Similar analogies —
• If the SD card in my Wii fills up, should the system automatically  
start deleting saved games?
• If my iPhone's Flash disk gets full, should it start deleting  
photos? What if I haven't synced those photos to my iTunes yet?


In each of those cases, what the device actually does is warns you  
about the lack of free space, and lets you choose what to get rid of.


It's worth noting that today, OSs do a pretty poor job of helping  
you with this task.  (I don't see any reason why the spec will  
prohibit UAs from creating a good UI for this, though.)


I completely agree OSs do a pretty poor job of helping with the task.   
Browsers might be an innovating space here.  I challenge you to come  
up with a great UI for this that shows up in a UA.  I challenge the  
WHATWG to not decide that deleting user data is okay because it's the  
easiest way out.




Local storage is different from cloud storage. The HTML5 storage API  
can be used for both, so it shouldn't be limited to what's  
convenient for just one of them.


I still don't understand what use local storage has outside of  
'cloud storage'.  Even in the extensions use case (which I think is  
out of scope for this spec), there's no reason you can't sync user  
preferences and such to the cloud.


Once thing I think that HTML5 has made clear is that "web  
technologies" are no longer exclusively about "web sites" that exist  
solely "in the cloud."  Widgets/gadgets, html-based extensions,  
offline web applications, and native applications that use HTML/JS/CSS  
to embed parts of their UI are *all* covered by HTML5, and I don't  
think requiring the cloud for any of them is necessary.


Also - and I don't mean this to be flippant, I raise it as a serious  
point - not all web application developers are Google or Apple with  
access to a server infrastructure.  To many web developers, just  
"throwing data up on a server somewhere" is outside the constraints of  
their resources or their design.


The cloud is within the scope of web technologies, but web  
technologies should not rely on the cloud.


By the way, in case it's not clear, my position is not that UAs  
should take deleting user information lightly, my position is 1)  
this behavior should be left up to the UA and 2) when possible,  
developers should kee

Re: [whatwg] Web Storage: apparent contradiction in spec

[Aaron Boodman]

On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlow wrote:
> I still don't understand what use local storage has outside of 'cloud
> storage'.  Even in the extensions use case (which I think is out of scope
> for this spec), there's no reason you can't sync user preferences and such
> to the cloud.

The use case, though, is local storage, not cloud storage. Requiring
cloud storage here kind of defeats the purpose and makes the API a lot
harder to use.

- a

Re: [whatwg] Web Storage: apparent contradiction in spec

[Jeremy Orlow]

On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman  wrote:

> On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow wrote:
> > Ok, well I guess we should go ahead and have this discussion now.  :-)
>  Does
> > anyone outside of Apple and Google have an opinion on the matter (since I
> > think it's pretty clear where we both stand).
>
> FWIW, I tend to agree more with the Apple argument :). I agree that
> the multiple malicious subdomains thing is unfortunate. Maybe the
> quotas should be per eTLD instead of -- or in addition to --
> per-origin? Malicious developers could then use multiple eTLDs, but at
> that point there is a real cost.


This could be helpful.  I suppose UAs could do this today, even.


> Extensions are an example of an application that is less cloud-based.
> It would be unfortunate and weird for extension developers to have to
> worry about their storage getting tossed because the UA is running out
> of disk space.


Extensions are pretty far out of scope of the spec (at least for now),
right?  (Within Chrome, we can of course special case this.)


> It seems more like if that happens the UA should direct the user to UI
> to free up some storage. If quotas were enforced at the eTLD level,
> wouldn't this be really rare?


It would be on the desktop, but it probably won't be rare on mobile phones
(and maybe even netbooks).


On Tue, Aug 25, 2009 at 3:09 PM, Jens Alfke  wrote:

> Interesting comments. Linus and Jeremy appear to be coming at this from a
> pure "cloud" perspective, where any important or persistent data is kept on
> a remote server and the browser, so local storage can be treated as merely a
> cache. That's definitely a valid position, but from my perspective, much of
> the impetus for having local storage is to be able to support *other* 
> application
> models, where important data is stored locally. If browsers are free to
> dispose HTML5 local storage without the user's informed consent, such
> applications become dangerously unreliable.
> For example, Linus wrote:
>
> User agents need to be free to garbage collect any local state. If they
> can't then attackers (or the merely lazy) will be able to fill up the user's
> disk. We can't expect web sites or users to do the chore of taking out the
> garbage.
>
>
> Replace "user agent" -> "operating system" and "local state" -> "user
> files", and you have an argument that, when the hard disk in my MacBook gets
> too full, the OS should be free to start randomly deleting my local files to
> make room. This would be a really bad idea.
>

Well, it's certainly different from what we're used to.  I'm not convinced
it's wrong though.  The web has gotten by pretty well with such a model so
far.


> Similar analogies —
> • If the SD card in my Wii fills up, should the system automatically start
> deleting saved games?
> • If my iPhone's Flash disk gets full, should it start deleting photos?
> What if I haven't synced those photos to my iTunes yet?
>
> In each of those cases, what the device actually does is warns you about
> the lack of free space, and lets you choose what to get rid of.
>

It's worth noting that today, OSs do a pretty poor job of helping you with
this task.  (I don't see any reason why the spec will prohibit UAs from
creating a good UI for this, though.)


> Local storage is different from cloud storage. The HTML5 storage API can be
> used for both, so it shouldn't be limited to what's convenient for just one
> of them.
>

I still don't understand what use local storage has outside of 'cloud
storage'.  Even in the extensions use case (which I think is out of scope
for this spec), there's no reason you can't sync user preferences and such
to the cloud.

The only tricky thing I see here is enabling offline use of websites.  And I
don't think "keep local storage forever" is a very good solution, though I
agree it is _a_ solution for this use case.

By the way, in case it's not clear, my position is not that UAs should take
deleting user information lightly, my position is 1) this behavior should be
left up to the UA and 2) when possible, developers should keep information
in the cloud not local storage.

J

Re: [whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

On Aug 25, 2009, at 3:31 PM, Michael Nordman wrote:

The statement in section 4.3 doesn't appear to specify any  
behavior... its just an informational statement.


The statement in section 6.1 suggests to prohibit the development of  
a UI that mentions local storage as a distinct repository seperate  
from cookies. This doesn't belong in the spec imho.


I think both of these statements should be dropped from the spec.


If all browsers go through great lengths to ensure that this data is  
as persistent as a local user file, but one browser decides it's only  
a cache and can prune it at will, then developers cannot rely on it.


I don't think 4.3 should be dropped - I think it should be  
strengthened to actually protect the data from any action not  
authorized by the user.


Browsers who wish to treat it as a local cache that they can prune at  
any time could give the user a checkbox labeled "Let me delete your  
stored data whenever I want" and this would qualify.  ;)


Yes, that's an unrealistic, hyperbolic example, but I stand by the  
point it illustrates!


~Brady

PS: I am ambivalent about section 6.1, other than to reiterate I don't  
think the current language actually reflects the intended message.




Ultimately I think UAs will have to prop up out-of-band  
permissioning schemes to make stronger guarantees about how long  
lived 'local data' that accumulates really is.


On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman  wrote:
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow  
wrote:
> Ok, well I guess we should go ahead and have this discussion  
now.  :-)  Does
> anyone outside of Apple and Google have an opinion on the matter  
(since I

> think it's pretty clear where we both stand).

FWIW, I tend to agree more with the Apple argument :). I agree that
the multiple malicious subdomains thing is unfortunate. Maybe the
quotas should be per eTLD instead of -- or in addition to --
per-origin? Malicious developers could then use multiple eTLDs, but at
that point there is a real cost.

Extensions are an example of an application that is less cloud-based.
It would be unfortunate and weird for extension developers to have to
worry about their storage getting tossed because the UA is running out
of disk space.

It seems more like if that happens the UA should direct the user to UI
to free up some storage. If quotas were enforced at the eTLD level,
wouldn't this be really rare?

- a

Re: [whatwg] Web Storage: apparent contradiction in spec

[Michael Nordman]

The statement in section 4.3 doesn't appear to specify any behavior... its
just an informational statement.

The statement in section 6.1 suggests to prohibit the development of a UI
that mentions local storage as a distinct repository seperate from cookies.
This doesn't belong in the spec imho.

I think both of these statements should be dropped from the spec.

Ultimately I think UAs will have to prop up out-of-band permissioning
schemes to make stronger guarantees about how long lived 'local data' that
accumulates really is.

On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman  wrote:

> On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow wrote:
> > Ok, well I guess we should go ahead and have this discussion now.  :-)
>  Does
> > anyone outside of Apple and Google have an opinion on the matter (since I
> > think it's pretty clear where we both stand).
>
> FWIW, I tend to agree more with the Apple argument :). I agree that
> the multiple malicious subdomains thing is unfortunate. Maybe the
> quotas should be per eTLD instead of -- or in addition to --
> per-origin? Malicious developers could then use multiple eTLDs, but at
> that point there is a real cost.
>
> Extensions are an example of an application that is less cloud-based.
> It would be unfortunate and weird for extension developers to have to
> worry about their storage getting tossed because the UA is running out
> of disk space.
>
> It seems more like if that happens the UA should direct the user to UI
> to free up some storage. If quotas were enforced at the eTLD level,
> wouldn't this be really rare?
>
> - a
>

Re: [whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

On Aug 25, 2009, at 3:09 PM, Jens Alfke wrote:

Interesting comments. Linus and Jeremy appear to be coming at this  
from a pure "cloud" perspective, where any important or persistent  
data is kept on a remote server and the browser, so local storage  
can be treated as merely a cache. That's definitely a valid  
position, but from my perspective, much of the impetus for having  
local storage is to be able to support other application models,  
where important data is stored locally. If browsers are free to  
dispose HTML5 local storage without the user's informed consent,  
such applications become dangerously unreliable.


For example, Linus wrote:
User agents need to be free to garbage collect any local state. If  
they can't then attackers (or the merely lazy) will be able to fill  
up the user's disk. We can't expect web sites or users to do the  
chore of taking out the garbage.


Replace "user agent" -> "operating system" and "local state" ->  
"user files", and you have an argument that, when the hard disk in  
my MacBook gets too full, the OS should be free to start randomly  
deleting my local files to make room. This would be a really bad idea.


Similar analogies —
• If the SD card in my Wii fills up, should the system automatically  
start deleting saved games?
• If my iPhone's Flash disk gets full, should it start deleting  
photos? What if I haven't synced those photos to my iTunes yet?


In each of those cases, what the device actually does is warns you  
about the lack of free space, and lets you choose what to get rid of.


Local storage is different from cloud storage. The HTML5 storage API  
can be used for both, so it shouldn't be limited to what's  
convenient for just one of them.




Thank you Jens.  This is a well thought out synopsis of the point I've  
been wanting to make whenever this comes up, but have failed to do.


~Brady


—Jens

Re: [whatwg] Web Storage: apparent contradiction in spec

[Aaron Boodman]

On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow wrote:
> Ok, well I guess we should go ahead and have this discussion now.  :-)  Does
> anyone outside of Apple and Google have an opinion on the matter (since I
> think it's pretty clear where we both stand).

FWIW, I tend to agree more with the Apple argument :). I agree that
the multiple malicious subdomains thing is unfortunate. Maybe the
quotas should be per eTLD instead of -- or in addition to --
per-origin? Malicious developers could then use multiple eTLDs, but at
that point there is a real cost.

Extensions are an example of an application that is less cloud-based.
It would be unfortunate and weird for extension developers to have to
worry about their storage getting tossed because the UA is running out
of disk space.

It seems more like if that happens the UA should direct the user to UI
to free up some storage. If quotas were enforced at the eTLD level,
wouldn't this be really rare?

- a

Re: [whatwg] Web Storage: apparent contradiction in spec

[Jens Alfke]

Interesting comments. Linus and Jeremy appear to be coming at this  
from a pure "cloud" perspective, where any important or persistent  
data is kept on a remote server and the browser, so local storage can  
be treated as merely a cache. That's definitely a valid position, but  
from my perspective, much of the impetus for having local storage is  
to be able to support other application models, where important data  
is stored locally. If browsers are free to dispose HTML5 local storage  
without the user's informed consent, such applications become  
dangerously unreliable.


For example, Linus wrote:
User agents need to be free to garbage collect any local state. If  
they can't then attackers (or the merely lazy) will be able to fill  
up the user's disk. We can't expect web sites or users to do the  
chore of taking out the garbage.


Replace "user agent" -> "operating system" and "local state" -> "user  
files", and you have an argument that, when the hard disk in my  
MacBook gets too full, the OS should be free to start randomly  
deleting my local files to make room. This would be a really bad idea.


Similar analogies —
• If the SD card in my Wii fills up, should the system automatically  
start deleting saved games?
• If my iPhone's Flash disk gets full, should it start deleting  
photos? What if I haven't synced those photos to my iTunes yet?


In each of those cases, what the device actually does is warns you  
about the lack of free space, and lets you choose what to get rid of.


Local storage is different from cloud storage. The HTML5 storage API  
can be used for both, so it shouldn't be limited to what's convenient  
for just one of them.


—Jens

Re: [whatwg] Web Storage: apparent contradiction in spec

[Jeremy Orlow]

On Tue, Aug 25, 2009 at 2:40 PM, Brady Eidson  wrote:

>
> On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:
>
> On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson  wrote:
>
>> On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
>>
>> It is important that all local state be treated as a cache. User agents
>> need to be free to garbage collect any local state. If they can't then
>> attackers (or the merely lazy) will be able to fill up the user's disk. We
>> can't expect web sites or users to do the chore of taking out the garbage.
>> Better user agents will have better garbage collection algorithms.
>> It would be better to remove section 4.3.
>>
>>
>> I disagree.
>> One key advantage of LocalStorage and Databases over cookies is that they
>> *do* have a predictable, persistent lifetime, and the browser is *not*
>> allowed to prune them at will.
>>
>> User agents are perfectly allowed to not allow new items to go into
>> LocalStorage or Database Storage once some quota is met, or if the user has
>> disabled it for that domain, or disabled it altogether, or if the disk is
>> filling up, or any other number of circumstances.
>>
>> But once the data is stored, it should be considered user data - as
>> "sacred" as a user's file on the file system.
>>
>
> What happens when your computer blows up?
>
>
> You lose the data the same way you lose your local file data.
>
> When you switch browsers?
>
>
> Unfortunately the same thing that happens with your bookmarks, preferences,
> history, etc - unless the new browser knows how to import the old data.
>
> No one would ever claim a browser should be able to arbitrarily prune a
> user's bookmarks "just because you might lose them when switching browsers."
>  If someone would claim that, I would raise this same objection.
>
> What about when you re-install your OS?
>
>
> Same thing as with local files - if you didn't backup your hard disk, you
> lose them.  If you do backup your hard disk and restore files after you
> re-install your OS, you get your localstorage, databases, and hell - even
> your Flash cookies back, just like your files.
>
> What about mobile devices where 5mb is actually a lot of space?
>
>
> These mobile devices are perfectly allowed to restrict the amount of data
> they agree to store with respect to their limited capacity.
>
> What happens when a malicious site fills up all of your localStorage space?
>
>
>
> This is why per-security-origin quotas exist.  For the counter argument of
> "what about a site that switches subdomains to subvert the per-origin
> quota?", fortunately HTML5 doesn't disallow browsers from limiting per
> top-level domain or via some other extra limitation.
>
> You're saying the UAs should not be free to have heuristics about what to
> delete?
>
>
> Yes.
>
> What do they do then?
>
>
> They should be free to have whatever heuristics they'd like when choosing
> what to store.  But once it's stored, it should be persistent.
>
> When a user's hard drive on a desktop machine fills up, should the
> operating system be able to decide "Oh crap, I'm running out of space, and I
> have no other caches or temporary data to delete.  So I'll just go ahead and
> start deleting the user's files without asking?"
>
> LocalStorage is quite clearly modeled after Flash's LocalStorage - what
> does Flash do?  It has all sorts of controls in place to limit what data is
> stored.  But once the data *is* stored, does it ever arbitrarily decide to
> delete it?
>
> Note this exact point has been discussed on this list before, and IIRC the
> outcome was that localStorage should be treated like cookies: we'll try to
> keep them around, but the app should be resilient to them going away.
>
>
> This exact point has been discussed on this list more than once, and I've
> only ever seen it die out with no consensus.  If the discussion took place
> and it *was* decided that "User Agents should arbitrarily be able to decide
> to delete LocalStorage or database data without the user pre-clearing that
> action," then I'm afraid I missed it and I am raising my objection now.
>

Ok, well I guess we should go ahead and have this discussion now.  :-)  Does
anyone outside of Apple and Google have an opinion on the matter (since I
think it's pretty clear where we both stand).

Re: [whatwg] Web Storage: apparent contradiction in spec

[Jeremy Orlow]

On Tue, Aug 25, 2009 at 2:16 PM, Jeremy Orlow  wrote:

> On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson  wrote:
>
>> On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
>>
>> It is important that all local state be treated as a cache. User agents
>> need to be free to garbage collect any local state. If they can't then
>> attackers (or the merely lazy) will be able to fill up the user's disk. We
>> can't expect web sites or users to do the chore of taking out the garbage.
>> Better user agents will have better garbage collection algorithms.
>> It would be better to remove section 4.3.
>>
>>
>> I disagree.
>> One key advantage of LocalStorage and Databases over cookies is that they
>> *do* have a predictable, persistent lifetime, and the browser is *not*
>> allowed to prune them at will.
>>
>> User agents are perfectly allowed to not allow new items to go into
>> LocalStorage or Database Storage once some quota is met, or if the user has
>> disabled it for that domain, or disabled it altogether, or if the disk is
>> filling up, or any other number of circumstances.
>>
>> But once the data is stored, it should be considered user data - as
>> "sacred" as a user's file on the file system.
>>
>
> What happens when your computer blows up?  When you switch browsers?  What
> about when you re-install your OS?  etc
>
> What about mobile devices where 5mb is actually a lot of space?  What
> happens when a malicious site fills up all of your localStorage space?
>  You're saying the UAs should not be free to have heuristics about what to
> delete?  What do they do then?
>

I just re-read your message and noticed that you suggested local storage
should stop working when it's filled up.  First of all, this seems
completely unacceptable to me, especially since we don't have a good answer
yet (besides quotas which are probably enough for your average desktop, but
probably not your average mobile or netbook) to the problem of malicious
sites filling up local storage with multiple sub domains.

Also, consider this scenario: you fill up your hard drive only 50% of the
way with localStorage data.  (Possibly by a malicious site, and thus the
user is unaware.)  Now you try to install a bunch of apps (maybe even over
time) that consume the rest of the hard drive.  So now the user is either
SOL unless they can realize this space has gone to their browser and can
figure out how to delete it?


> Note this exact point has been discussed on this list before, and IIRC the
> outcome was that localStorage should be treated like cookies: we'll try to
> keep them around, but the app should be resilient to them going away.
>

One previous reference:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019276.html
I thought there was more discussion, but I couldn't find anything
other
than this thread after a quick search.

J

Re: [whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:

On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson   
wrote:

On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:

It is important that all local state be treated as a cache. User  
agents need to be free to garbage collect any local state. If they  
can't then attackers (or the merely lazy) will be able to fill up  
the user's disk. We can't expect web sites or users to do the chore  
of taking out the garbage. Better user agents will have better  
garbage collection algorithms.


It would be better to remove section 4.3.


I disagree.

One key advantage of LocalStorage and Databases over cookies is that  
they *do* have a predictable, persistent lifetime, and the browser  
is *not* allowed to prune them at will.


User agents are perfectly allowed to not allow new items to go into  
LocalStorage or Database Storage once some quota is met, or if the  
user has disabled it for that domain, or disabled it altogether, or  
if the disk is filling up, or any other number of circumstances.


But once the data is stored, it should be considered user data - as  
"sacred" as a user's file on the file system.


What happens when your computer blows up?


You lose the data the same way you lose your local file data.


When you switch browsers?


Unfortunately the same thing that happens with your bookmarks,  
preferences, history, etc - unless the new browser knows how to import  
the old data.


No one would ever claim a browser should be able to arbitrarily prune  
a user's bookmarks "just because you might lose them when switching  
browsers."  If someone would claim that, I would raise this same  
objection.



What about when you re-install your OS?


Same thing as with local files - if you didn't backup your hard disk,  
you lose them.  If you do backup your hard disk and restore files  
after you re-install your OS, you get your localstorage, databases,  
and hell - even your Flash cookies back, just like your files.



What about mobile devices where 5mb is actually a lot of space?


These mobile devices are perfectly allowed to restrict the amount of  
data they agree to store with respect to their limited capacity.


What happens when a malicious site fills up all of your localStorage  
space?


This is why per-security-origin quotas exist.  For the counter  
argument of "what about a site that switches subdomains to subvert the  
per-origin quota?", fortunately HTML5 doesn't disallow browsers from  
limiting per top-level domain or via some other extra limitation.


You're saying the UAs should not be free to have heuristics about  
what to delete?


Yes.


What do they do then?


They should be free to have whatever heuristics they'd like when  
choosing what to store.  But once it's stored, it should be persistent.


When a user's hard drive on a desktop machine fills up, should the  
operating system be able to decide "Oh crap, I'm running out of space,  
and I have no other caches or temporary data to delete.  So I'll just  
go ahead and start deleting the user's files without asking?"


LocalStorage is quite clearly modeled after Flash's LocalStorage -  
what does Flash do?  It has all sorts of controls in place to limit  
what data is stored.  But once the data *is* stored, does it ever  
arbitrarily decide to delete it?


Note this exact point has been discussed on this list before, and  
IIRC the outcome was that localStorage should be treated like  
cookies: we'll try to keep them around, but the app should be  
resilient to them going away.


This exact point has been discussed on this list more than once, and  
I've only ever seen it die out with no consensus.  If the discussion  
took place and it *was* decided that "User Agents should arbitrarily  
be able to decide to delete LocalStorage or database data without the  
user pre-clearing that action," then I'm afraid I missed it and I am  
raising my objection now.


~Brady



J

Re: [whatwg] Remove addCueRange/removeCueRanges

[David Singer]

At 0:49  +1200 23/08/09, Robert O'Callahan wrote:
On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk 
<m...@romantschuk.fi> wrote:


Silvia Pfeiffer wrote:

Precision is influenced more strongly by the temporal
resolution of the decoding pipeline rather than the polling resolution
for currentTime. I doubt the previous implementations of "start" and
"end" gave you a 3 sample accurate resolution even for wav files.


I'll chime in here, having done extensive work with audio and video 
codecs. With current codec implementations getting sample- or 
frame-accurate resolution is largely a pipe dream. (Outside of the 
realm of platforms dedicated to content production and playback.) 
Especially for video there can be several seconds between keyframes, 
frame-accurate jumps requiring complex buffering tricks.



Those tricks aren't that hard, at least for Theora; we do them in Firefox.


It's very easy in QuickTime or MP4.  Timestamps of the frames can be 
sample accurate, so you decode the right frame, and trim the result.




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]



--
David Singer
Multimedia Standards, Apple Inc.

Re: [whatwg] Web Storage: apparent contradiction in spec

[Jeremy Orlow]

On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson  wrote:

> On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
>
> It is important that all local state be treated as a cache. User agents
> need to be free to garbage collect any local state. If they can't then
> attackers (or the merely lazy) will be able to fill up the user's disk. We
> can't expect web sites or users to do the chore of taking out the garbage.
> Better user agents will have better garbage collection algorithms.
> It would be better to remove section 4.3.
>
>
> I disagree.
> One key advantage of LocalStorage and Databases over cookies is that they
> *do* have a predictable, persistent lifetime, and the browser is *not*
> allowed to prune them at will.
>
> User agents are perfectly allowed to not allow new items to go into
> LocalStorage or Database Storage once some quota is met, or if the user has
> disabled it for that domain, or disabled it altogether, or if the disk is
> filling up, or any other number of circumstances.
>
> But once the data is stored, it should be considered user data - as
> "sacred" as a user's file on the file system.
>

What happens when your computer blows up?  When you switch browsers?  What
about when you re-install your OS?  etc

What about mobile devices where 5mb is actually a lot of space?  What
happens when a malicious site fills up all of your localStorage space?
 You're saying the UAs should not be free to have heuristics about what to
delete?  What do they do then?

Note this exact point has been discussed on this list before, and IIRC the
outcome was that localStorage should be treated like cookies: we'll try to
keep them around, but the app should be resilient to them going away.

J

Re: [whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:

It is important that all local state be treated as a cache. User  
agents need to be free to garbage collect any local state. If they  
can't then attackers (or the merely lazy) will be able to fill up  
the user's disk. We can't expect web sites or users to do the chore  
of taking out the garbage. Better user agents will have better  
garbage collection algorithms.


It would be better to remove section 4.3.


I disagree.

One key advantage of LocalStorage and Databases over cookies is that  
they *do* have a predictable, persistent lifetime, and the browser is  
*not* allowed to prune them at will.


User agents are perfectly allowed to not allow new items to go into  
LocalStorage or Database Storage once some quota is met, or if the  
user has disabled it for that domain, or disabled it altogether, or if  
the disk is filling up, or any other number of circumstances.


But once the data is stored, it should be considered user data - as  
"sacred" as a user's file on the file system.



Linus


On Tue, Aug 25, 2009 at 1:18 PM, Jens Alfke  wrote:
I've just noticed an apparent self-contradiction in the Web Storage  
spec (24 August draft).


Section 4.3 states:
Data stored in local storage areas should be considered potentially  
user-critical. It is expected that Web applications will use the  
local storage areas for storing user-written documents.



Section 6.1 states:
User agents should present the persistent storage feature to the  
user in a way that does not distinguish them from HTTP session  
cookies.


These statements are contradictory, because cookies don't store user- 
critical data such as documents. The user model of cookies is that  
they're conveniences (at best) for keeping you logged into a site or  
remembering preferences like font-size, so deleting them is no more  
than an inconvenience. If local storage is presented to the user as  
being cookies, then a user may delete it without understanding the  
consequences.


Potential result: "I was having trouble logging into FooDocs.com, so  
my friend suggested I delete the cookies for that site. After that I  
could log in, but now the document I was working on this morning has  
lost all the changes I made! How do I get them back?"


I suggest that the sub-section "Treating persistent storage as  
cookies" of section 6.1 be removed.


I agree that the wording of the section needs great improvement and it  
is factually wrong in its current form.  That said, I don't think it  
should be removed.


I *think* Ian's intention was that in the same vein that user agents  
are "obligated" to present all of the cookies stored on the disk at  
any given time and allow manual management of them, they should be  
"obligated" to do the same for LocalStorage (and databases, too).


If I'm wrong, hopefully he can correct me.


~Brady

Re: [whatwg] Web Storage: apparent contradiction in spec

[Linus Upson]

It is important that all local state be treated as a cache. User agents need
to be free to garbage collect any local state. If they can't then attackers
(or the merely lazy) will be able to fill up the user's disk. We can't
expect web sites or users to do the chore of taking out the garbage. Better
user agents will have better garbage collection algorithms.
It would be better to remove section 4.3.

Linus


On Tue, Aug 25, 2009 at 1:18 PM, Jens Alfke  wrote:

> I've just noticed an apparent self-contradiction in the Web Storage 
> spec (24
> August draft).
> Section 4.3 states:
>
> Data stored in local storage areas should be considered potentially
> user-critical. It is expected that Web applications will use the local
> storage areas for storing user-written documents.
>
>
> Section 6.1 states:
>
> User agents should present the persistent storage feature to the user in a
> way that does not distinguish them from HTTP session cookies.
>
>
> These statements are contradictory, because cookies don't store
> user-critical data such as documents. The user model of cookies is that
> they're conveniences (at best) for keeping you logged into a site or
> remembering preferences like font-size, so deleting them is no more than an
> inconvenience. If local storage is presented to the user as being cookies,
> then a user may delete it without understanding the consequences.
>
> Potential result: "I was having trouble logging into FooDocs.com, so my
> friend suggested I delete the cookies for that site. After that I could log
> in, but now the document I was working on this morning has lost all the
> changes I made! How do I get them back?"
>
> I suggest that the sub-section "Treating persistent storage as cookies" of
> section 6.1 be removed.
>
> —Jens
>

[whatwg] Web Storage: apparent contradiction in spec

[Jens Alfke]

I've just noticed an apparent self-contradiction in the Web Storage  
spec (24 August draft).


Section 4.3 states:
Data stored in local storage areas should be considered potentially  
user-critical. It is expected that Web applications will use the  
local storage areas for storing user-written documents.



Section 6.1 states:
User agents should present the persistent storage feature to the  
user in a way that does not distinguish them from HTTP session  
cookies.


These statements are contradictory, because cookies don't store user- 
critical data such as documents. The user model of cookies is that  
they're conveniences (at best) for keeping you logged into a site or  
remembering preferences like font-size, so deleting them is no more  
than an inconvenience. If local storage is presented to the user as  
being cookies, then a user may delete it without understanding the  
consequences.


Potential result: "I was having trouble logging into FooDocs.com, so  
my friend suggested I delete the cookies for that site. After that I  
could log in, but now the document I was working on this morning has  
lost all the changes I made! How do I get them back?"


I suggest that the sub-section "Treating persistent storage as  
cookies" of section 6.1 be removed.


—Jens

Re: [whatwg] Storage mutex

[Drew Wilson]

On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow  wrote:

> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan 
> wrote:
>
>> On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow wrote:
>>
>>> On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan >> > wrote:
>>>
 On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow wrote:

> First of all, I was wondering why all user prompts are specified as
> "must release the storage mutex" (
> http://dev.w3.org/html5/spec/Overview.html#user-prompts).  Should this
> really say "must" instead of "may"?  IIRC (I couldn't find the original
> thread, unfortunately) this was added because of deadlock concerns.  It
> seems like there might be some UA implementation specific ways this could
> deadlock and there is the question of whether we'd want an alert() while
> holding the lock to block other execution requiring the lock, but I don't
> see why the language should be "must".  For Chromium, I don't think we'll
> need to release the lock for any of these, unless there's some
> deadlock scenario I'm missing here.


 So if one page grabs the lock and then does an alert(), and another page
 in the same domain tries to get the lock, you're going to let the latter
 page hang until the user dismisses the alert in the first page?

>>>
>>> Yes.  And I agree this is sub-optimal, but shouldn't it be left up to the
>>> UAs what to do?  I feel like this is somewhat of an odd case to begin with
>>> since alerts lock up most (all?) browsers to a varying degrees even without
>>> using localStorage.
>>>
>>
>> That behaviour sounds worse than what Firefox currently does, where an
>> alert disables input to all tabs in the window (which is already pretty
>> bad), because it willl make applications in visually unrelated tabs and
>> windows hang.
>>
>
> OK...I guess it makes sense to leave this as is.
>
> One thing I just realized that kind of sucks though:  This makes alert
> based debugging much more difficult.  I guess that's acceptable, though.
>

I'm not sure why, unless you are saying that "alert based debugging while
another document is updating the same database simultaneously", then yeah.
But that seems like an obscure case for alert debugging.

The problem with leaving this up to the UA is it becomes a point of
incompatibility - on one browser, it's safe to put up an alert, on another
it isn't. So if applications have to fall back to the LCD behavior, then we
might as well codify it in the spec, which we have :)

Re: [whatwg] Storage mutex

[Jeremy Orlow]

On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan wrote:

> On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow wrote:
>
>> On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan 
>> wrote:
>>
>>> On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow wrote:
>>>
 First of all, I was wondering why all user prompts are specified as
 "must release the storage mutex" (
 http://dev.w3.org/html5/spec/Overview.html#user-prompts).  Should this
 really say "must" instead of "may"?  IIRC (I couldn't find the original
 thread, unfortunately) this was added because of deadlock concerns.  It
 seems like there might be some UA implementation specific ways this could
 deadlock and there is the question of whether we'd want an alert() while
 holding the lock to block other execution requiring the lock, but I don't
 see why the language should be "must".  For Chromium, I don't think we'll
 need to release the lock for any of these, unless there's some
 deadlock scenario I'm missing here.
>>>
>>>
>>> So if one page grabs the lock and then does an alert(), and another page
>>> in the same domain tries to get the lock, you're going to let the latter
>>> page hang until the user dismisses the alert in the first page?
>>>
>>
>> Yes.  And I agree this is sub-optimal, but shouldn't it be left up to the
>> UAs what to do?  I feel like this is somewhat of an odd case to begin with
>> since alerts lock up most (all?) browsers to a varying degrees even without
>> using localStorage.
>>
>
> That behaviour sounds worse than what Firefox currently does, where an
> alert disables input to all tabs in the window (which is already pretty
> bad), because it willl make applications in visually unrelated tabs and
> windows hang.
>

OK...I guess it makes sense to leave this as is.

One thing I just realized that kind of sucks though:  This makes alert based
debugging much more difficult.  I guess that's acceptable, though.


>  Given that different UAs are probably going to have other scenarios where
 they have to drop the lock (some of them may even be purely 
 implementational
 issues), should we add some way for us to notify scripts the lock was
 dropped?  A normal event isn't going to be of much use, since it'll fire
 after the scripts execution ends (so the lock would have been dropped by
 then anyway).  A boolean doesn't seem super useful, but it's better than
 nothing and could help debugging.  Maybe fire an exception?  Are there 
 other
 options?

>>>
>>> A generation counter might be useful.
>>>
>>
>> Ooo, I like that idea.  When would the counter increment?  It'd be nice if
>> it didn't increment if the page did something synchronous but no one else
>> took the lock in the mean time.
>>
>
> Defining "no-one else" may be difficult. I haven't thought this through, to
> be honest, but I think you could update the counter every time the storage
> mutex is released and the shared state was modified since the storage mutex
> was acquired. Reading the counter would acquire the storage mutex. You'd
> basically write
>
> var counter = window.storageMutexGenerationCounter;
> ... do lots of stuff ...
> if (window.storageMutexGenerationCounter != counter) {
>   // abort, or refresh local state, or something
> }
>
> I'm not sure what you'd do if you discovered an undesired lock-drop,
> though. If you can't write something sensible instead of "abort, or
> something", it's not worth doing.
>

I guess it would depend on the use.  Let's say a library/framework dependeds
on the lock being held but does a callback (that might do something that
causes the lock to be dropped).  It could check the counter and raise an
exception.  It could also re-start "processing" if that were an acceptable
answer (but by having the counter, it would only do so when necessary).  I
think it'll be very application specific _what_ you do when you catch such
an error, but I do think it'll be valuable to developers.


>  But getStorageUpdates is still not the right name for it.  The only way
>> that there'd be any updates to get is if, when you call the function,
>> someone else takes the lock and makes some updates.  Maybe it should be
>> yieldStorage (or yieldStorageMutex)?  In other words, maybe the name should
>> imply that you're allowing concurrent updates to happen?
>>
>
> I thought that's what getStorageUpdates implied :-).


To me, getStorageUpdates seems to imply that updates have already happened
and we're working with an old version of the data.  I think many developers
will be quite shocked that getStorageUpdates _enables_ others to update
storage.  In other words, 'get' seems to imply that you're consuming state
that's happening anyway, not affecting behavior.

For what it's worth, I sanity checked my point with a web developer here at
Google working with LocalStorage and he too thought the name was
misleading/not clear.  Are we the only ones??

Re: [whatwg] Microdata

[Philip Jägenstedt]

atwg/20090824#l-375


We can't disallow nesting items as values of properties, there are a  
whole

bunch of use cases that depend on it.


3 is not a suggestion to disallow nesting, but to change the syntax for  
it.



Could you show how your syntax proposals would look when marking up the
following data?

// JSON DESCRIPTION OF MARKED UP DATA
// document URL: http://www.example.org/sample/test.html
{
  "items": [
{
  "type": "com.example.product",
  "properties": {
"about": [ "http://example.com/products/bt200x"; ],
"image": [ "http://www.example.org/sample/bt200x.jpeg"; ] //  
please keep this one outside the item in the DOM

"name": [ "GPS Receiver BT 200X" ],
"reldate": [ "2009-01-22" ],
"review": [
  {
"type": "",
"properties": {
  "reviewer": [ "http://ln.hixie.ch/"; ],
  "text": [ "Lots of memory, not much battery, very little  
accuracy." ]

}
  }
],
  }
},
{
  "type": "work",
  "properties": {
"about": [ "http://www.example.org/sample/image.jpeg"; ],
"license": [  
"http://www.opensource.org/licenses/mit-license.php"; ]

"title": [ "My Pond" ],
  }
}
  ]
}


Here's how it would be marked up today:


 http://example.com/products/bt200x";>
 GPS Receiver BT 200X
 Rating: ⋆⋆⋆✩✩ itemprop=rating content="2">
 Release Date: datetime="2009-01-22">January 22
 href="http://ln.hixie.ch/";>Ian:
 "Lots of memory, not much battery, very little  
accuracy."



 
 
  My Pond
  Licensed under the http://www.opensource.org/licenses/mit-license.php";>MIT
  license.
 

alt="...">


To be clear, I'm now suggesting that item+itemprop never be allowed on  
the same item (option 3). Nesting items is accomplished simply by  
nesting them.


In your example, the only change would be this line:

  http://ln.hixie.ch/";>Ian:

(Of course some tokens may need to change to be renamed to make sense as  
item names rather than itemprops.)


As an aside, subject should also be allowed to associate items with its  
parent item, just like for itemprop.


IMHO, this syntax is more copy-paste robust, favors the common cases  
over the complex cases and makes the model more intuitive to those who  
understand XML and/or DOM.


http://krijnhoetmer.nl/irc-logs/whatwg/20090825#l-469

After this discussion it is (even more) clear that at least option 3 is  
not just a syntax change but rather a change to the underlying model from  
nested name-value groups to a tree of unnamed (but not untyped) nodes  
which each have name-value groups, somewhat like DOM.


Pros:

* No itemprop+item syntax.

But simpler syntax might be compensated for by more nesting... If  
itemprop+item sticks, then some examples in the spec that use both  
itemprop name and item type would help. Something like item="book">...


It will be very interesting to see the results from usability testing if  
itemprop+item actually will confuse authors.


* Items don't need to "know" that they are part of a bigger item.

But if the two items don't know of each other then they probably don't  
belong together. The real issue is that item elements that happen to be  
children of another item element (like in Jame's blog planet example)  
aren't going to be top-level items and are simply ignored. Workarounds are  
possible, but ensuring that items are in different subtrees is impossible  
if you only control a document fragment that is included in a larger  
document. I'd suggest simply letting any item element that doesn't have an  
itemprop attribute be a top-level item. Other solutions possible.


Cons:

* It would make converting microdata into a JavaScript object awkward  
because there's no such thing as unnamed properties. On the other hand, no  
matter the syntax you'll probably end up with vocabulary-specific mappings  
to JS(ON).


* It assumes that the type of the subitem to be enough to determine how it  
relates to the item, not property name + subitem type as now. This might  
be an even worse source of confusion than itemprop+item.


Looking at the pros/cons I can only conclude that I dislike all options  
equally. Several of these issues leak over to the DOM API, but I've  
already sent feedback on that separately. I hope there will be more  
suggestions to consider.


--
Philip Jägenstedt
Opera Software

Re: [whatwg] HTML 5 clarifications on ValidityState?

[Peter Kasting]

On Tue, Aug 25, 2009 at 12:50 AM, Alex Vincent  wrote:

> "The validationMessage  attribute must return the empty string if the
> element is not a candidate for constraint validation or if it is one
> but it satisfies its constraints; otherwise, it must return a suitably
> localized message that the user agent would show the user if this were
> the only form with a validity constraint problem. If the element is
> suffering from a custom error, then the custom validity error message
> should be present in the return value."
>
> Specifically, the last sentence contradicts the rest of the paragraph.
>  If there is a custom error, but the element is not a candidate for
> constraint validation, should the validationMessage attribute be
> empty, or should the custom validity error message be present in the
> return value?  You can't have both.


I believe the intent is that an element which is not a candidate for
constraint validation cannot be suffering from a custom error (just as it
cannot be suffering from any other validation error).  However, I'm not sure
why elements which are barred from constraint validation (fieldset, output)
have a setCustomValidity() method; perhaps so that authors could blindly
iterate over all form-associated elements and call this method?

PK

Re: [whatwg] Text areas with pattern attributes?

[Anne van Kesteren]

On Tue, 25 Aug 2009 18:57:59 +0200, Peter Kasting   
wrote:
On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren  
wrote:

Also, maxlength cannot be enforced as client-side validation requirement
due to compatibility issues.


I don't grasp what you're saying here.  Are you saying that maxlength or
ValidityState.tooLong() cannot be implemented as specced?


I was trying to say something else (Web Forms 2.0 was at one point  
modified to only enforce maxlength if the value was actually changed by  
the user and I misremembered how that was solved), but it turns out what  
is specified clashes with a jQuery extension to the textarea element as  
well :/ Not sure how to address that.



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

Re: [whatwg] Text areas with pattern attributes?

[Peter Kasting]

On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren wrote:

> Also, maxlength cannot be enforced as client-side validation requirement
> due to compatibility issues.
>

I don't grasp what you're saying here.  Are you saying that maxlength or
ValidityState.tooLong() cannot be implemented as specced?

PK

Re: [whatwg] Text areas with pattern attributes?

[Kornel]

On Tue, Aug 25, 2009 at 3:05 AM, Anne van Kesteren  
wrote:
Also, maxlength cannot be enforced as client-side validation  
requirement due to compatibility issues.


Hmm, I hadn't thought of that.  You're right, that would provide
somewhat inconsistent behavior.  On the other hand, just not letting
you type any more is if anything probably better than an error
message.  I don't see why you'd ever *want* the behavior of
pattern=".{0,n}" for maxlength=n.


With maxlength (as implemented in current browsers) it's not possible  
to paste string that is too long and then trim it to desired length,  
e.g. if I have "Your order reference is AB-456" in my clipboard, I  
can't use it in input field that has maxlength=6.


So I wish maxlength behaved more like pattern in all cases :)

--
regards, Kornel

Re: [whatwg] Text areas with pattern attributes?

[Aryeh Gregor]

On Tue, Aug 25, 2009 at 3:05 AM, Anne van Kesteren wrote:
> Also, maxlength cannot be enforced as client-side validation requirement due 
> to compatibility issues.

Hmm, I hadn't thought of that.  You're right, that would provide
somewhat inconsistent behavior.  On the other hand, just not letting
you type any more is if anything probably better than an error
message.  I don't see why you'd ever *want* the behavior of
pattern=".{0,n}" for maxlength=n.

For that matter, it might be nice if some patterns just refused to let
you enter anything that doesn't meet the pattern -- but not all,
clearly.  E.g., "[ -~]*" to restrict to ASCII would really like to
just not let you type other characters, but that's not workable for
".{10,}" to set a minimum length.  Possibly this is too much
complication for the time being, however.

Re: [whatwg] type=email validation is too loose for practical applications

[Anne van Kesteren]

On Tue, 25 Aug 2009 15:19:42 +0200, Aryeh Gregor  
 wrote:

Nor does the current spec, but it only restricts what the UA actually
submits, not what it accepts from the user.


Ah, that makes sense.



The spec suggests that
UAs convert IDNs to punycode for submission, which seems reasonable.


Though somewhat inconsistent with type=url, but then IDN email addresses  
are not quite there yet.




Opera 9.64 seems to reject IDNs in  (but I'm not
totally sure on this, my IDN might just be wrong somehow).


We might not support them yet, I haven't checked.


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

Re: [whatwg] type=email validation is too loose for practical applications

[Aryeh Gregor]

On Tue, Aug 25, 2009 at 2:59 AM, Anne van Kesteren wrote:
> On Tue, 25 Aug 2009 02:19:55 +0200, TAMURA, Kent  wrote:
>> I'd like stricter rule for it. e.g.
>> dot-atom-text "@" 1*(ALPHA / DIGIT) 1*("." 1*(ALPHA / DIGIT))
>
> That does not work with IDNs.

Nor does the current spec, but it only restricts what the UA actually
submits, not what it accepts from the user.  The spec suggests that
UAs convert IDNs to punycode for submission, which seems reasonable.
Opera 9.64 seems to reject IDNs in  (but I'm not
totally sure on this, my IDN might just be wrong somehow).

Re: [whatwg] Drag and Drop Security Model and current implementations

[Aron Spohr]

Hi Oliver,

> I agree as I'm unsure what else *could* be safely exposed
> before the drop event -- realistically anything beyond the
> types seems risky: ignoring the obvious risks of exposing
> actual content, exposing any form of URI may lead to
> unintended information leaking (you have to assume that
> people are dragging random private files, urls, etc across
> windows and do not intend to drop them)

I generally agree. However in this particular case (which is currently 
implemented in the latest versions of Firefox and Google) full access is only 
granted if the original and the target page are the same. For instance: If you 
drag something from http://www.mywebapp.com/ to another window serving 
http://www.mywebapp.com/. Only in this particular case the target application 
or page has access to all the data during a dragover event (and other events). 
I believe that makes sense as it is literally the same application which 
created and stored the data to the dataTransfer object in the first place. It's 
just using multiple browser-windows. As you can see this wouldn't work if 
people drag private files, urls from other sources across..

Aron

Re: [whatwg] behavior

[Andrew Oakley]

Ian Hickson wrote:
> I'm not sure exactly what change you mean. The spec already has some of 
> Gecko's behaviour (in particular the special-casing of certain MIME types 
> to enable sniffing), are there other changes you think we should include? 

Boris Zbarsky wrote (near the top of this thread):
> If the type attribute was set to something that parsed as a MIME
> type, and if that type would be handled by a plug-in (that is, we
> have a plug-in to handle it, and have no other method for handling 
> it), then use the type attribute's type instead of the header type.

So if we had a type attribute of application/x-shockwave-flash, and a
Content-Type header of image/png we would use the flash plugin.
Following the HTML5 spec we would use the image renderer.


>> I'm also confused about the criteria for creating a nested browsing context.
>>
>>> - If the resource type is an XML MIME type
>>> - If the resource type is HTML
>>> - If the resource type does not start with "image/"
>> Does that mean:
>> - xml_mime_type OR html OR not_image
>>   this is the same as xml_mime_type OR not_image
>> - xml_mime_type AND html AND not_image
>>   this would be application/xhtml+xml, application/ce-html+xml etc. but
>>   *not* text/html
>> - (xml_mime_type OR html) AND not_image
>>   makes sense but would certainly need clarification in the spec
> 
> The former. I've added an "or" and removed the (redundant) HTML line to 
> make this clearer.

Thanks.


-- 
Andrew Oakley

[whatwg] HTML 5 clarifications on ValidityState?

[Alex Vincent]

I read this paragraph (from section 4.10.15.3) as self-contradicting:

"The validationMessage  attribute must return the empty string if the
element is not a candidate for constraint validation or if it is one
but it satisfies its constraints; otherwise, it must return a suitably
localized message that the user agent would show the user if this were
the only form with a validity constraint problem. If the element is
suffering from a custom error, then the custom validity error message
should be present in the return value."

Specifically, the last sentence contradicts the rest of the paragraph.
 If there is a custom error, but the element is not a candidate for
constraint validation, should the validationMessage attribute be
empty, or should the custom validity error message be present in the
return value?  You can't have both.

This inconsistency is somewhat worsened when you consider the user may
call input.setCustomValidity("foo") on an element that isn't a
candidate for constraint validation:





var foo = document.getElementById("foo");
foo.setCustomValidity("foo");
foo.willValidate // returns false, because of the disabled attribute

"The willValidate  attribute must return true if an element is a
candidate for constraint validation, and false otherwise (i.e. false
if any conditions are barring it from constraint validation)."

foo.validity.customError // returns true
foo.validity.valid // returns false
foo.validationMessage // ???

Also, I noticed the readonly attribute for input elements overrides
constraint validation, per section 4.10.4.2.3 - but the readonly
attribute has no meaning for several input types (section 4.10.4, the
big table after the IDL).  For checkboxes, radio buttons, file
uploads, image inputs, submit, reset and ordinary button types for the
input element, readonly has no other effect.

Please advise - I'm currently working on a patch for Gecko code which
implements this.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

Re: [whatwg] Microdata

[Philip Jägenstedt]

On Tue, 25 Aug 2009 00:29:06 +0200, Ian Hickson  wrote:


On Mon, 24 Aug 2009, Philip Jägenstedt wrote:


I've found two related things that are a bit problematic. First, because
itemprops are only associated with ancestor item elements or via the
subject attribute, it's always necessary to find or create a separate
element for the item. This leads to more convoluted markup for small
items, so it would be nice if the first item and itemprop could be on
the same element when it makes sense:


  Concert at 19:00 at the beach.


rather than


  
Concert at 19:00 at the beach.
  



As specced now, having itemprop="" and item="" on the same element  
implies

that the value of the property is an item rooted at this element.

Not supporting the above was intentional, to keep the mental model of the
markup very simple, rather than having shortcuts. (RDFa has lots of
shortcuts and it ended up being very difficult to keep the mental model
straight.)


There's something like an inverse relationship between simplicity of the  
syntax and complexity of the resulting markup, the best balance point  
isn't clear (to me at least). Perhaps option 3 is better, never allowing  
item+itemprop on the same element.



Second, because composite items can only be made by adding item and
itemprop to the same element, the embedded item has to know that it has
a parent and what itemprop it should use to describe itself. James gave
the example of "something like planet where each article could be a
com.example.blog item and within each article there could be any
arbitrary author-supplied microdata" [1]. I also feel that the
item+itemprop syntax for composite items is one of the least intuitive
parts of the current spec. It's easy to get confused about what the type
of the item vs the itemprop should be and which item the itemprop
actually belongs to.


Fair points.



Given that flat items like vcard/vevent are likely to be the most common
use case I think we should optimize for that. Child items can be created
by using a predefined item property: itemprop="com.example.childtype
item".


Ok...



The value of that property would then be the first item in tree-order
(or all items in the subtree, not sure). This way, items would have
better copy-paste resilience as the whole item element could be made
into a top-level item simply by moving it, without meddling with the
itemprop.


That sounds kinda confusing...


More confusing than item+itemprop on the same element? In many cases the  
property value is the contained text, having it be the contained item  
node(s) doesn't seem much stranger.



If the parent-item (com.example.blog) doesn't know what the child-items
are, it would simply use itemprop="item".


I don't understand this at all.


This was an attempt to have anonymous sub-items. Re-thinking this, perhaps  
a better solution would be to have each item behave in much the same way  
that the document itself does. That is, simply add items in the subtree  
without using itemprop and access them with .getItems(itemType) on the  
outer item.


Comparing the current model with a DOM tree, it seems odd in the a  
property could be an item. It would be like an element attribute being  
another element: . That kind of thing could just as  
well be , type="foo"/> or even  if the relationship  
between the elements is clear just from the fact that they have a  
parent-child relationship (usually the case).


All examples of nested items in the spec are on the form



These would be replaced with



It's only in the case where both itemprop and item have a type that an  
extra level of nesting will be needed and I expect that to be the  
exception. Changing the model to something more DOM-tree-like is probably  
going to be easier to understand for many web developers. It would also  
fix the problem in my other mail where it's a bit tricky to determine via  
the DOM API whether a property is a string or an item. When on the topic  
of the DOM API, document.getItems("outer")[0].getItems("inner")[0] would  
be so much clearer than what we currently have.



Example:


  My name is Philip
  Jägenstedt.



I don't understand what this maps to at all.


The same as


  
My name is Philip
Jägenstedt.
  


Unless I've misunderstood the "n" in vcard (there's no example in the  
spec). But let's move on.



I'll admit that my examples are a bit simple, but the main point in my
opinion is to make item+itemprop less confusing. There are basically
only 3 options:

1. for compositing items (like now)
2. as shorthand on the top-level item (my suggestion)
3. disallow

I'd primarily like for 1 and 2 to be tested, but 3 is a real option too.

[1] http://krijnhoetmer.nl/irc-logs/whatwg/20090824#l-375


We can't disallow nesting items as values of properties, there are a  
whole

bunch of use cases that depend on it.


3 is not a suggestion to disallow nesting, but to change the syntax for it.


Could you show how your syntax proposals wou

Re: [whatwg] Text areas with pattern attributes?

[Anne van Kesteren]

On Mon, 24 Aug 2009 22:14:51 +0200, Aryeh Gregor  
wrote:
> On Mon, Aug 24, 2009 at 1:49 PM, Peter Kasting  
> wrote:
>> On Mon, Aug 24, 2009 at 9:08 AM, Chris Taylor  
>> 
>> wrote:
>>> It's been mentioned before about limiting the length of text  
>>> permissible
>>> in a  element, specifically for forums.
>>
>>  is defined to support maxlength already
>> (  
>> http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element  
>> ).
>
> There's no minlength, though.

Also, maxlength cannot be enforced as client-side validation requirement due to 
compatibility issues.


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