Re: [whatwg] type=email validation is too loose for practical applications
On Tue, 25 Aug 2009 02:19:55 +0200, TAMURA, Kent tk...@chromium.org 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Microdata
On Tue, 25 Aug 2009 00:29:06 +0200, Ian Hickson i...@hixie.ch 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: p item=vevent itemprop=description Concert at span itemprop=dtstart19:00/span at span itemprop=locationthe beach/span. /p rather than p item=vevent span itemprop=description Concert at span itemprop=dtstart19:00/span at span itemprop=locationthe beach/span. /span /p 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: outer foo=inner//. That kind of thing could just as well be outerfooinner//foo/outer, outerinner type=foo//outer or even outerinner//outer 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 p itemprop=subtype item These would be replaced with p item=subtype 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: p item=vcard itemprop=n item My name is span itemprop=given-namePhilip/span span itemprop=family-nameJägenstedt/span. /p I don't understand what this maps to at all. The same as p item=vcard span itemprop=n item My name is span itemprop=given-namePhilip/span span itemprop=family-nameJägenstedt/span. /span /p 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
[whatwg] HTML 5 clarifications on ValidityState?
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: form action=javascript:void() input disabled=true name=foo id=foo/ /form 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] object behavior
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
Re: [whatwg] Drag and Drop Security Model and current implementations
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] type=email validation is too loose for practical applications
On Tue, Aug 25, 2009 at 2:59 AM, Anne van Kesterenann...@opera.com wrote: On Tue, 25 Aug 2009 02:19:55 +0200, TAMURA, Kent tk...@chromium.org 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 input type=email (but I'm not totally sure on this, my IDN might just be wrong somehow).
Re: [whatwg] type=email validation is too loose for practical applications
On Tue, 25 Aug 2009 15:19:42 +0200, Aryeh Gregor simetrical+...@gmail.com 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 input type=email (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] Text areas with pattern attributes?
On Tue, Aug 25, 2009 at 3:05 AM, Anne van Kesterenann...@opera.com 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] Text areas with pattern attributes?
On Tue, Aug 25, 2009 at 3:05 AM, Anne van Kesterenann...@opera.com
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?
On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren ann...@opera.comwrote: 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?
On Tue, 25 Aug 2009 18:57:59 +0200, Peter Kasting pkast...@google.com wrote: On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren ann...@opera.comwrote: 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] HTML 5 clarifications on ValidityState?
On Tue, Aug 25, 2009 at 12:50 AM, Alex Vincent ajvinc...@gmail.com 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] Microdata
, 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 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:
section id=bt200x item=com.example.product
link itemprop=about href=http://example.com/products/bt200x;
h1 itemprop=nameGPS Receiver BT 200X/h1
pRating: #x22C6;#x22C6;#x22C6;#x2729;#x2729; meta
itemprop=rating content=2/p
pRelease Date: time itemprop=reldate
datetime=2009-01-22January 22/time/p
p itemprop=review itema itemprop=reviewer
href=http://ln.hixie.ch/;Ian/a:
span itemprop=textLots of memory, not much battery, very little
accuracy./span/p
/section
figure item=work
img itemprop=about src=image.jpeg
legend
pcite itemprop=titleMy Pond/cite/p
psmallLicensed under the a itemprop=license
href=http://www.opensource.org/licenses/mit-license.php;MIT
license/a./small
/legend
/figure
pimg subject=bt200x itemprop=image src=bt200x.jpeg
alt=.../p
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:
p item=reviewa itemprop=reviewer href=http://ln.hixie.ch/;Ian/a:
(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 span
item=bookspan itemprop=author item=vcard.../span/span
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
Re: [whatwg] Storage mutex
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.orgwrote:
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] Storage mutex
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.org wrote: On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote: On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.orgwrote: 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 :)
[whatwg] Web Storage: apparent contradiction in spec
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] Web Storage: apparent contradiction in spec
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 s...@google.com 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
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com 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
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 s...@google.com wrote: I've just noticed an apparent self-contradiction in the Web Storage spechttp://dev.w3.org/html5/webstorage (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] Remove addCueRange/removeCueRanges
At 0:49 +1200 23/08/09, Robert O'Callahan wrote: On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk mailto:m...@romantschuk.fim...@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
On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote: On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com 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] Web Storage: apparent contradiction in spec
On Tue, Aug 25, 2009 at 2:16 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com 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
On Tue, Aug 25, 2009 at 2:40 PM, Brady Eidson beid...@apple.com wrote: On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote: On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com 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
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
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
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 a...@google.com wrote: On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org 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
On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote: On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org 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 s...@google.com 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
On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlowjor...@chromium.org 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
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 a...@google.com wrote: On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org 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
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org 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
On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote: On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote: On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org 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 s...@google.com 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
Re: [whatwg] SharedWorkers and the name parameter
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 the #name part will break this line and throw a URL_MISMATCH_ERR with the duplicated #name2 one. Shall we ignore minor difference
Re: [whatwg] Web Storage: apparent contradiction in spec
On Tue, Aug 25, 2009 at 4:18 PM, Brady Eidson beid...@apple.com wrote: On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote: On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote: On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org 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 s...@google.com 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
Re: [whatwg] Web Storage: apparent contradiction in spec
On Tue, Aug 25, 2009 at 5:44 PM, Jeremy Orlowjor...@chromium.org 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.
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 25, 2009 at 7:24 PM, Ian Hicksoni...@hixie.ch 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
[whatwg] brief question on 2.4.5 Dates and times
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.
[whatwg] formNoValidate/novalidate/willValidate
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
Re: [whatwg] HTML5 History Management
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] formNoValidate/novalidate/willValidate
On Tue, Aug 25, 2009 at 7:56 PM, Dean Edwards dean.edwa...@gmail.comwrote: 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] Storage mutex
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.org 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] Storage mutex
On Tue, Aug 25, 2009 at 10:28 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.orgwrote: 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.
