Re: [whatwg] Web Addresses vs Legacy Extended IRI

On Sat, 21 Mar 2009, Giovanni Campagna wrote: > > Now I would like to ask: > are there any major differences that requires the W3C / WHATWG to > publish an other specification, just for HTML5, instead of just > referencing the IRI-bis draft or the LEIRI working group note? As far as I can tell th

Re: [whatwg] Signatures in HTML5

On Sun, 22 Mar 2009, Channy Yun wrote: > > If anyone knows good positions or opinion to discuss this issue, please > let me know. I would recommend contacting the public-weba...@w3.org mailing list. If that working group is interested in following this, the chairs can invite you relevant parti

Re: [whatwg] localStorage + worker processes

On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking wrote: > The problem with synchronously grabbing the lock is that we can only > ever have one feature that uses synchronous locks, otherwise we'll > risk dead-locks. > > Say that we make document.cookie behave the same way (to prevent > multi-process

Re: [whatwg] Worker and message port feedback

On Fri, Mar 20, 2009 at 3:29 PM, Ian Hickson wrote: > On Sat, 7 Mar 2009, Jonas Sicking wrote: >> >> document.cookies can't change in the middle of an execution. I.e. a >> script like: >> >> a = document.cookie; >> b = document.cookie; >> alert(a === b); >> >> will always show 'true'. > > On Mon,

Re: [whatwg] localStorage + worker processes

As a side note, if we do go with this async lock acquiring, we could add an API like: getLockedFeatures(callback, 'localStore', 'cookie'); This would be an asynchronously grab locks to multiple features and only call the callback once all of them have been acquired. This would allow computations

Re: [whatwg] localStorage + worker processes

On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson wrote: > That might work. Is it feasible for user agents to enforce limits on how > long a callback is allowed to run holding the lock? That way workers can't > starve normal pages from accessing their local storage. I don't think it will be a big prob

Re: [whatwg] localStorage + worker processes

On Sat, Mar 21, 2009 at 9:38 AM, Aaron Boodman wrote: > On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking wrote: >> What we could do, is to have an API like >> >> getLocalStorage(callback); >> >> This function returns immediately, but will then call the callback >> function as soon as the localStor

[whatwg] Web Addresses vs Legacy Extended IRI

HTML5 originally included a section about resource identifiers processing. A few days ago that section was extracted into the W3C editor draft of Web Addresses. I noticed it and remembered that I had read once something like that. Precisely, what I once read is , a note

Re: [whatwg] Signatures in HTML5

Ian, Anyway I thank you for your careful consideration and encouragement of another activities. Basically web signature must be implemented by browser venders because of an example of XKMS's fail that Anders indicated. So we have to consider how to do is cost effective and I think form processing

Re: [whatwg] localStorage + worker processes

On Sat, Mar 21, 2009 at 9:41 AM, Drew Wilson wrote: > That might work. Is it feasible for user agents to enforce limits on how > long a callback is allowed to run holding the lock? That way workers can't > starve normal pages from accessing their local storage. It seems like they could use the sa

Re: [whatwg] localStorage + worker processes

That might work. Is it feasible for user agents to enforce limits on how long a callback is allowed to run holding the lock? That way workers can't starve normal pages from accessing their local storage. -atw On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking wrote: > On Fri, Mar 20, 2009 at 3:10

Re: [whatwg] localStorage + worker processes

On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking wrote: > What we could do, is to have an API like > > getLocalStorage(callback); > > This function returns immediately, but will then call the callback > function as soon as the localStorage becomes available and the lock > been acquired. This would

Re: [whatwg] size attribute

For implementors: The size attribute gives the average number of glyphs that the reader of the page will be able to see when the control is rendered and completely filled with text. (This depends on the language of the control and the current style and accounts for ligature-driven scripts like Dev

Re: [whatwg] Persistent SharedWorkers

Hi Drew, I definitely think that a lot of what you are proposing here is very interesting. And, as you mention, much of it needs user approval. However, I don't think we can use UI as simple a what we use for enabling popups. The reason is that it's something that is IMHO too easy to social engin

Re: [whatwg] localStorage + worker processes

On Fri, Mar 20, 2009 at 3:10 PM, Aaron Boodman wrote: > I think the best option is to make access to localstorage asynchronous > for workers. This reduces the amount of time a worker can hold the > localstore lock so that it shouldn't be a problem for normal pages. It > sucks to make such a simple