Re: [whatwg] Typo: 'possibly' as adjective
On Thu, 10 Sep 2009, Øistein E. Andersen wrote: [P]ossibly algorithms in the adoption agency algorithm note should be possible algorithms. Fixed, thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Initial carriage return in pre and textarea
On Thu, 10 Sep 2009, Øistein E. Andersen wrote: § 9.1.2.5 Restrictions on content models mentions that an initial line feed (\n) character inside pre and textarea will be removed. Should it not cover carriage return (\r) and \r\n as well? Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r3801 - [e] (0) hx examples.
On Fri, 11 Sep 2009, Simon Pieters wrote: + div class=example + pThese two snippets are equivalent:/p + + prelt;h1Let's call it a draw(ing surface)lt;/h1 +lt;h2Diving inlt;/h2 +lt;h2Simple shapeslt;/h2 +lt;h2Canvas coordinateslt;/h2 +lt;h3Canvas coordinates diagramlt;/h3 +lt;h2Pathslt;/h2/pre + + prelt;section + lt;h1Let's call it a draw(ing surface)lt;/h1 + lt;section + lt;h1Diving inlt;/h1 + lt;/section + lt;section + lt;h1Simple shapeslt;/h1 + lt;/section + lt;section + lt;h1Canvas coordinateslt;/h1 + lt;section + lt;h1Canvas coordinates diagramlt;/h1 + lt;/section + lt;/section + lt;section + lt;h1Pathslt;/h1 + lt;/section +lt;/section/pre + + /div They are not equivalent; in the first example, the h1 will apply to the body, while in the second example the first h1 will apply to the explicit section. Either add a section to the first example or remove the wrapping section from the other. Maybe add body to both examples. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 drag and drop feedback
Yes, that is a neat solution. However, it is still the case that at this time we should not add new features, otherwise we might get too far ahead of the implementations, and the quality of implementations will go down. I support the suggestions that Francisco made and I accept that some of them might be too much to add right now. However, while I see the argument for not racing ahead too quickly, I do think the last suggestion brings excellent value in terms of 'additional effort to implement' vs. 'additional benefit given'. Considering how useful this feature would be for web-apps (which I thought HTML5 was meant to be geared towards) I think that this is too tempting to pass up. Furthermore I'm not sure I agree with Ian's argument for holding out until the browsers support the current API more reliably. My experience has shown that there are numerous cross-browser incompatibilities in the existing implementations of more trivial features, yet we are not waiting for all of those to get resolved before adding support for, say, native video. So why should this be any different? Anyway, I'm new to this group and don't know much about how decisions are usually made here, but in case there was any doubt about this idea's popularity I'd like to lend it my own +1.
Re: [whatwg] HTML 5 drag and drop feedback
On Tue, 15 Sep 2009 11:37:57 +0200, Nabil Elisa nabil.el...@gmail.com wrote: Furthermore I'm not sure I agree with Ian's argument for holding out until the browsers support the current API more reliably. My experience has shown that there are numerous cross-browser incompatibilities in the existing implementations of more trivial features, yet we are not waiting for all of those to get resolved before adding support for, say, native video. So why should this be any different? The argument Ian made was not support for feature A is brittle so we should not do feature B. It was support for feature A is brittle so we should do not do feature A-2 just yet. Anyway, I'm new to this group and don't know much about how decisions are usually made here, but in case there was any doubt about this idea's popularity I'd like to lend it my own +1. Decisions are usually made based on merit, not popularity. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] cloneNode and HTML elements
On Mon, Sep 14, 2009 at 9:11 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 10 Sep 2009, Olli Pettay wrote: On 9/10/09 11:13 AM, Jonas Sicking wrote: On Thu, Sep 10, 2009 at 12:41 AM, Maciej Stachowiakm...@apple.com wrote: My assumption based on the spec is that no element-specific internal state should be copied, the cloning should only be DOM-wise. My assumption was always the opposite. For example forinput elements we clone the 'value' API attribute, as well as the internal has-changed-value bit (used for form field restore when going back to a page). Forscript we copy over the has-executed bit. I'm fairly sure that the list is longer. I've always interpret DOM3 Core strictly; cloning an element clones the object and copies all attributes and their values So no state copying. (I noticed the input element state cloning when writing other cloning related stuff.) I didn't even know about the input control state cloning. I've updated the spec to require that the value, checkedness, dirty value, and dirty checkedness flags get cloned too. For what it's worth, we also clone: The script-is-malformed bit (set to true if a script lacks an end tag, used when serializing to avoid a round-trip executing a partial script element which in theory could be a security concern) Script line-number (used for error messages). Though this doesn't seem particularly important given that it's only used in very weird edge cases. There's also something in svg:use elements, but I suspect that's for some internal magic. / Jonas
Re: [whatwg] Fakepath revisited
On Mon, 14 Sep 2009, Eduard Pascual wrote: Now, maybe stepping on a side topic, I'd like to bring back a separate request: I think, if fakepath is to be included on the spec, that content authors shouldn't be left at their own risks. Considering that pre-HTML5 browsers (like IE 6 and 7 or FF2) are going to stay there for a while, approaches like substr(12) or any other means of just trimming C:\fakepath\ just won't work. Last indexof(\\) would break on any browser that doesn't include path at all (that's what fakepath is addressing, after all), as well as any browser that runs on Unix-like systems and provides full path (not sure if there is any current browser on this category). Is there any way we content authors can reliably retrieve a filename from scripts, other than special-casing several versions of each browser in existence? More specifically, would .files[0] work on those pre-HTML5 browsers? If it does, this is a non-issue. However, if it doesn't, I'd like to suggest adding an algorythm on the spec to deal with this task. Just like the spec offers algorythms for browsers to deal with non-compliant existing content, on cases like this it would be equally valuable to have algorythms for content to deal with non-compliant existing browsers. files[0] won't work in most legacy browsers. I've added an example of how to grab the filename. On Mon, 14 Sep 2009, Alex Henrie wrote: Then for however long we use HTML, we will always remember that we have to work around fakepath because someone decided that compatibility with a handful of badly designed pages in 2009 was more important than having good design in 2090. If only this was the only thing for which we could say that. :-( -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r3859 - [acgiowt] (2) Parser changes: dc, ds, dialog are now treated differently. [...]
wha...@whatwg.org writes: + pThe span class=implfirst/span codea href=#the-dt-elementdt/a/code element child + of the element, if any, represents the caption of the + codea href=#the-figure-elementfigure/a/code element's contents. If there is no child + codea href=#the-dt-elementdt/a/code element, then there is no caption./p + pThe span class=implfirst/span codea href=#the-dd-elementdd/a/code element child + of the elementspan class=impl, if any,/span represents the + element's contents. span class=implIf there is no child + codea href=#the-dd-elementdd/a/code element, then there is no caption./span/p I think that last caption is supposed to be content. Also, the If there is no for dd is class=impl but the equivalent one for dt isn't. While proofreading this change I also spotted an inconsistency in the related example undet the dd element: http://www.whatwg.org/html5#the-dd-element I think the first class=part-of-speech should be on the i rather than the dd (matching the other instances). Smylers
Re: [whatwg] object behavior
Ian Hickson wrote: Since the whole point of text/plain sniffing is a workaround around a known issue where content is reliably mis-marked as text/plain, and since in this case there is a source of MIME information that's more reliable than that, it's not clear to me why we want to continue sniffing. Of course if there is no @type there is no problem; I'm specifically concerned about the @type=text/plain case here. What exactly are you proposing here? - Always honour type= if it's a UA-supported type, ignoring server- provided content-type? - Always honour type= without sniffing if it matches the server- provided content-type, even if normally that type would be sniffed? - Just honour type=text/plain regardless of the server type, but for other UA-supported type=s, use the server type? My suggestion is to only perform text/plain is this text or binary sniffing where it belongs: on the HTTP level; since it's a workaround for a particular HTTP server bug. It shouldn't affect other type metadata. Perform the sniffing such that it detects as either text/plain or application/octet-stream. Then if it's application/octet-stream we'll end up using the @type. Though see below on other sniffing issues. This does fail to sniff text/plain as the various non-scriptable types, but I question how desirable that is anyway, honestly. If we want to preserve this property without clobbering @type=text/plain then I need to think a bit more about how to specify the behavior here. Maybe your option 2 is what would give that behavior... I can work through it if you'd like. Your option 1 would be ok if that's what we want (but a change from HTML4 and what UAs at least _try_ to implement now; I'm not sure whether it's desirable on its own). Your option 3 is a bit too magic for text/plain in @type; unnecessarily so unless we want to go the full option 1 route. All in my opinion, of course. My concern about text/plain data being sniffed as text/html by your current algorithm (even with the changes you've made) seems to remain unaddressed. I thought I had. Can you walk me through how anything labeled text/plain could get sniffed as text/html with the new text? Hmm. Assume the type attribute is not set and HTML data is sent as text/plain and contains a binary byte in the first 512 bytes (can just stick it in the title or something). Also assume no plug-in claims to support the URI's file extension. At step 3, the resource type is set to text/plain. At step 4, the resource type is sniffed as application/octet-stream, since text/html is marked as scriptable in [MIMESNIFFF]. At step 5, there is no @type, and the resource type is application/octet-stream, so the resource type is changed to unknown. At step 6, nothing changes since there is no plug-in supporting the URI's file extension. At step 7, the resource type is unknown, so it is changed to the sniffed type of the resource. Maybe I simply misunderstood this last reference, by way of contrasting it with what step 4 says and you mean to apply the full sniffing algorithm, including the special-cases for text/plain, and not just section 5 of [MIMESNIFF]. In that case there wouldn't be a problem (the data would get sniffed as application/octet-stream). That wasn't quite clear, but I can see now that this is probably what you meant. -Boris
Re: [whatwg] article/section/details naming/definition problems
Henri wrote: http://adactio.com/journal/1607/ Ah, you beat me to it. I was just about to write an email to the list, honestly. ;-) So anyway, the upshot of my somewhat unscientific survey[1] conducted at a workshop a couple of weeks ago is that there is great confusion between the section and article elements. In that blog post, I point out that section and article were once more divergent but have converged over time (since the @cite and @pubdate attributes were dropped from article). I've also seen a lot of confusion from authors wondering when to use section and when to use article. Bruce wrote an article on HTML5 doctor recently to address this: http://html5doctor.com/the-section-element/ Probably the best tutorial I've seen on this issue is from Ted: http://edward.oconnor.cx/2009/09/using-the-html5-sectioning-elements ...but even so, the confusion remains. The very fact that tutorials are required for what should be intuitive structural elements is worrying — I don't see the same issues around nav, header or footer (now that the content model has been changed) ...although there is continuing confusion around aside. Anyway... Is there a strong enough case for having two separate new elements or they close enough in functionality that one of them could be dropped? Personally, I don't have a strong opinion about which element name should be dropped, but I do think that dropping one of them would make life easier for authors. Thoughts? [1] Details of the exercise: http://adactio.com/journal/1605/ -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] the cite element
Dear Ian, Here are a few more thoughts regarding the definition of cite in HTML5. On Thu, Aug 27, 2009 at 7:08 PM, Ian Hickson i...@hixie.ch wrote: Earlier, when justifying why you changed the definition of cite from HTML 4.01, you said: I don't think it makes sense to use the cite element to refer to people, because typographically people aren't generally marked up anyway. I don't really see how you'd use it to refer to untitled works. This usage is an example of when people are typographically marked up. It's a minor case. The semantic here wouldn't be name of person, it would be name of person when immediately following a quote in a pullquote, which is far too specific to deserve a whole element. I don't think anyone is arguing that there should be a new element exclusively for the above use or that cite should be limited only to that definition (name of person when immediately following a quote in a pullquote or the more forgiving person to whom the quote is attributed). Still, it would be nice to be able to use cite to mark up people being cited (along with other citations that don't explicitly involve a work's title). ... more importantly, the element's style is made non-italics, thus completely defeating the entire point of marking up the element in the first place. I'm not sure this is a reasonable argument against the use of cite. Following this line of reasoning, it is not worthwhile to mark up titles of works if they are *not* to be italicized; moreover, it is even pointless to mark up headings using h1-h6 if you intend to remove the bold styling. The counter to this approach is that h1-h6 provide semantic value even when styled differently from the default. But the same can be said for cite, whether it is defined as title of work or as a more general citation. When examining pages, you have to first pick a random sample, then study those, because otherwise you get sampling bias. With a trillion pages on the Web, it's easy to find thousands of examples of any particular use of HTML elements; the question is what is the most useful definition, not what is used at all. Because you believe title of work to be the most useful definition, does that mean that you would reject even a majority use of cite for marking up citations that aren't only or exclusively titles? There are plenty of examples of authors using cite to mark up the following (among other things): - titles of works - full citations - names and other sources of quote attribution (leaving aside placement relative to the quote) - names of blog post commenters and authors (in the context of their comments, posts, etc.) Even if titles are by for the most common use case, it doesn't make sense to exclude other semantically justifiable uses of what appear to be valid uses of the cite element, at least according to the English language usages associated with the word cite. Put another way, if you had no prior knowledge of the current HTML5 definition of cite (and perhaps any other specification's definition of the element), what would seem to be logical and appropriate uses of the element? By changing the definition of cite in HTML5, you are saying that numerous users of the HTML4 definition of cite are no longer conforming, and not really giving any alternative that does the same job. span does the job fine, in the rare cases where someone really wants to mark up someone's name. Unless there is some semantic value to the name being more than just a name, yes. In the absence of that, having cite mean simply a source being cited, and allowing the author to determine whether they want to use it for titles of works, authors, or entire citations, seems to be both reasonable and compatible with existing content. I think having it mean title of work only is more useful. Having it mean all three will mislead authors into using it for all three, and then cause them undue pain as they work around the default styling. I'm not sure I buy the undue pain argument, especially since there are plenty of times authors may wish to deviate from the default italic style of cite (using either title of work or citation as the definition): - A normally italicized title that is in a block of text that is also italicized (in which case the general use would be to remove italics from cite) - A title of a work that according to a style guide should not be italicized (in which case a class value would probably be added to the cite element, such as cite class=essayThe Freedom to Offend/cite). Moreover, what kinds of difficulties do you suppose? Nested cite elements? I don't think this would be any more a challenge than nested lists, strong in bolded text, or em in italicized text, in terms of dealing with default styles. People are actively overriding the styles cite because they think it's the right element, but it has the wrong effect. I don't know what more harm we could be causing here. The
Re: [whatwg] HTML extension for system idle detection.
On Tue, Sep 15, 2009 at 7:04 AM, timeless timel...@gmail.com wrote: On Mon, Sep 14, 2009 at 10:41 AM, David Bennettd...@google.com wrote: I also don't see why, in your particular case, you couldn't make it so that all background tasks are 'idle'. We could, but the reason we stop scripts is so that the pages don't kill our battery life. If we sent an idle signal and the page decided to do something expensive, how would that help? Suppose we send an idle message to a page as it goes to the background and give it a 30s window before we terminate it. Your window needs 35s to complete its expensive task. You come back to me and say that my idle notification behavior is broken, because i didn't let you finish your task (draining my battery). We're currently getting complaints from our cellular stack people about each network connection which causes the radio to have to power up and down (in fact, they complain that there are two hits or maybe three: initial request, initial response, and remote closed connection). If we tell pages each time they go to the background using your proposed idle notification, the scripts will spend power waking up the radio and then the cellular people will complain even more. Since the reason we stop scripts is to save battery, adding another chance for scripts to drain the battery (by waking up the radio) is counter productive at best. I don't really see why we're still talking about this. If you're stopping scripts, then all of the use cases for this proposal really don't apply to your particular platform. If people want to debate the merits of stopping scripts, this doesn't seem like the right list.
Re: [whatwg] Inter-window communication beyond window.postMessage()
On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson i...@hixie.ch wrote: 4. Open a SharedWorker and send a MessagePort to the other window. I'm not too familiar with shared workers, but I read through the spec and it looks like they suffer from the SOP (as Drew mentioned). (LocalStorage also suffers from this, I shouldn't have included it in the original post.) How do you know there's a Window to get a hold of if you don't have a hold of it already? You don't. What's common among the use cases for this kind of inter-window communication is that you are trying to talk to windows which may have been around longer than you or were created after you. If the call fails or you get no response, handle it (tell the user, open the window, or do nothing.). The main reason for Window.postMessage() is communication with iframes (gadgets), not with other top-level browsing contexts. What's the use case for the latter? On Mon, Sep 14, 2009 at 8:57 PM, Jeremy Orlow jor...@chromium.org wrote: I assume the use case for this is similar with the use case for storage events which essentially is a broadcast mechanism that's specific to just DOM storage. So if, for example, you wanted to tell your other windows hey! I changed the cookie then you could do it with a message. This seems much better than, for example polling. This could also be useful if you wanted to say hey, I just navigated to gmail.com. Do any of you already have the inbox and chat contacts loaded up?. I suppose there's not much advantage to doing it like this over shared workers since either way you're passing messages, but I also don't see any major downsides to allowing broadcasts. The original case that made me start exploring these APIs was a stuff browser that I'm working on (think address book). The browser stays open (as a popup) and can be used alone, but other pages should be able to ask it to navigate to a specific record. A shared worker would actually work quite nicely in this situation, but wouldn't work at all across-domains. For instance, websites are big these days on asking for login information for webmail clients to pull down contacts. What if an informal protocol were developed for exchanging contact information? Then, let's say I'm on Google Voice and want to call a number from my address book (which may be run by an unrelated company). Google Voice checks to see if I have a window open that identifies itself as an address book, sends it a MessagePort, and displays an add from address book button next to the phone number field. When I click the button, the address book's UI changes to indicate that it's ready for me to pick a phone number to send back to Google Voice. The same concept could apply to a password manager. An informal protocol would let login pages broadcast their existence to other windows and and if the user happens to have a web-based password manager open, it could answer the request and send back credentials. I'm not great at coming up with use cases, but messaging between separate top-level browsing contexts with different origins isn't covered by the current APIs, and it's a broad enough category that more-creative developers will want it once they realize that message passing exists at all.
Re: [whatwg] the cite element
Erik Vorhes writes:
On Thu, Aug 27, 2009 at 7:08 PM, Ian Hickson i...@hixie.ch wrote:
Earlier, when justifying why you changed the definition of cite
from HTML 4.01, you said:
I don't think it makes sense to use the cite element to refer
to people, because typographically people aren't generally
marked up anyway. I don't really see how you'd use it to refer
to untitled works.
This usage is an example of when people are typographically marked
up.
It's a minor case. The semantic here wouldn't be name of person,
it would be name of person when immediately following a quote in a
pullquote, which is far too specific to deserve a whole element.
I don't think anyone is arguing that there should be a new element
exclusively for the above use or that cite should be limited only to
that definition (name of person when immediately following a quote in
a pullquote or the more forgiving person to whom the quote is
attributed). Still, it would be nice to be able to use cite to mark
up people being cited (along with other citations that don't
explicitly involve a work's title).
But what do those situations have in common? Titles of works are
rendered in some way which makes them stand out (typically italics), so
they aren't mistaken for words the authors is using with their normal
meaning.
That doesn't apply to blockquote attributions as a whole, where the
attribution is distinguished by dint of being the line just after the
quote. And an attribution may include the author's name, the title of
the work, and a page number -- of which the title of the work needs
marking up in some way, ideally the same way as titles of works are
elsewhere in the document.
A publisher's house style may require that titles of works are
underlined instead of italicized, or in purple, or in roman text but
with single quotes around them ... but it's exceedingly unlikely they
would use exactly the same style for blockquote attributions.
Similarly a speaking browser would likely read titles of works
differently from the surrounding text, but doesn't need to give
blockquote attributions the same treatment. The two are different.
They are conveyed differently to users.
I can appreciate that having to use:
blockquote + div { text-align: right; }
(or whatever) isn't as nice as having a blockquoteattribution element.
But if you agree a blockquoteattribution is too niche to have its own
element, cramming it into an element which already has a specific
meaning and conveys something different to users.
Where a specific element for your needs doesn't exist the right course
of action is to use a generic one.
... more importantly, the element's style is made non-italics, thus
completely defeating the entire point of marking up the element in
the first place.
I'm not sure this is a reasonable argument against the use of cite .
Following this line of reasoning, it is not worthwhile to mark up
titles of works if they are *not* to be italicized;
It's only worthwhile marking up _anything_ if there's to be some benefit
to readers. If you do not wish your users to get clues as to which
words are titles of works then indeed you should not mark them up at
all.
Indeed going further, if you do not wish text to be conveyed to users as
being the title of a work then you must not mark it up with cite.
Even if you use CSS to remove the italics, only users of graphical
browsers with CSS enabled and good vision will be aware of that; many
other users will still have the words in question italicized or
otherwise conveyed in the manner appropriate for titles of works. It is
unfair on such minority users to rely on CSS for removing meaning from
elements.
(Note this isn't about whether it's italics or some other styling you've
chosen to convey which are titles of works to readers. If you wish to
remove the italics and use something else instead, cite is still the
right element.)
moreover, it is even pointless to mark up headings using h1 -h6 if
you intend to remove the bold styling.
Not so long as you leave the larger font sizes, or replace it with some
other styling which conveys they are headings -- then all users will
have conveyed to them that the headings are in fact headings, regardless
of their browsing environment.
The counter to this approach is that h1 -h6 provide semantic value
even when styled differently from the default.
Quite.
But the same can be said for cite , whether it is defined as title
of work or as a more general citation.
Nope, because those two need conveying differently to users, and the
semantics browsers convey by default are those appropriate for titles of
works.
Even if titles are by for the most common use case, it doesn't make
sense to exclude other semantically justifiable uses of what appear to
be valid uses of the cite element, at least according to the English
language usages associated with the word cite.
At this point in HTML's life
Re: [whatwg] Editorial: Colloquial contractions
On 15 Sep 2009, at 02:37, Ian Hickson wrote: On Tue, 8 Sep 2009, Øistein E. Andersen wrote: The spec currently contains a few occurrences of colloquial contractions like can't, won't and there's, which should be changed to cannot, will not, there is etc. for consistency. I haven't changed this, because it doesn't seem especially important, frankly. If there are specific cases where you think the current text reads poorly due to the use of contractions, please let me know. 'Tis not that specific instances are particularly horrific; the problem is that unmotivated alternation 'tween the two, just like any other typographical error or inconsistency, gives the impression of carelessness, which is always discomforting in a technical specification, whate'er the cause might be. I still think 'twould be worth fixing this, though I must admit 'tis more pervasive than I first thought. To make it less open-ended, please find below a list of changes that would correct most instances (capitalised forms not listed separately): s/doesn't/does not/ s/isn't/is not/ except: isn't his s/don't/do not/ except: don't know,, don't. s/it's/it is/ except: it's hot (twice), it's so pedantic, it's unarguably, it's about s/can't/cannot/ s/I'm looking/I am looking/ s/there's/there is/ except: there's a microphone (twice) s/won't/will not/ except: won't be that s/that's/that is/ except: that's right s/wasn't/was not/ s/aren't/are not/ s/wouldn't/would not/ s/we're/we are/ except: team we're, gt;we're (twice) s/they're/they are/ except: they're really s/here's/here is/ (except: there's a microphone) s/didn't/did not/ except: didn't have, didn't know, didn't lt; s/we'll/we shall/ s/we'd/we would/ s/I've/I have/ except: I've liked, I've got, I've only s/hasn't/has not/ except: hasn't changed s/you're doing/you are doing/ s/couldn't/could not/ except: couldn't admit s/we've/we have/ s/shouldn't/should not/ except: shouldn't say s/let's simulate/let us simulate/ s/it'll/it will/ s/haven't/have not/ s/you'd/you would/ s/it'd/it would/ s/I'd probably/I would probably/ s/I'd realised/I had realised/ s/hadn't/had not/ s/they've/they have/ s/they'll/they will/ s/there'd/there would/ s/he's covered/he is covered/ -- Øistein E. Andersen
Re: [whatwg] HTML extension for system idle detection.
Morning,
Updated the document for the proposal which now uses an event callback for
the system idle along with a method to get the current system idle time.
Comments on the update proposal?
Thanks,
David.
SUMMARY
There currently is no way to detect the system idle state in the browser.
This makes it difficult to deal with any sort of chat room or instant
messaging client inside the browser since the idle will always be incorrect.
USE CASE
Any instant messaging client, or any client that requires user presence,
will use this to keep track of the users idle state. Currently the idle
state of a user inside a browser tell tend to be incorrect, and this leads
to problems with people being unable to rely on the available status of a
user. Without this information it is difficult to do a full featured and
reliable instant messaging client inside the browser since this makes the
users' status somewhat unreliable.
Lots of social networking sites and other sites centered around user
interactions on the net keep track of the users idle state for enabling
interactions with people that are currently online, this would be especially
useful for interactive online gaming.
A process that would like to do some heavy duty processing, like s...@home,
could use the system idle detection to enable the processing only when the
user is idle and enable it to not interfere with or degrade their normal
browsing experience.
WORK AROUNDS
The idle state of the user is currently detected by looking at the brower
window and detecting the last activity time for the window. This is
inaccurate since if the user is not looking at the page the state will be
incorrect and means that the idle time is set to longer than would be
desirable so there is also a window in which the user is actually idle but
it has not yet been detected.
PROPOSAL
I propose an api which enables an event for the minimum idle timeout and has
a query to determine the current system idle. The event is fired when the
state changes. Active-idle, Active-away, idle-away, idle-active,
away-active.
The idle times are all specified in seconds, the event will be fired when
the idle state changes.
Not explicitly specified, and thus intentionally left to the UA, include:
* The event will be fired after the minimum system idle time for the
property; 2 minutes. [1]
* Any jitter intentionally added to the idle times reported [1]
* The granularity of the times reported (e.g. a UA may round them to
multiples of 15 seconds)
[NoInterfaceObject,
ImplementedOn=Windowhttp://www.w3.org/TR/html5/browsers.html#window]
interface WindowTimers {
// timers
// Returns the current system idle state.
int systemIdleState();
// The event fired when the idle state of the system changes.
interface IdleStateChangeEvent : Event
{
const unsigned short AWAY;
const unsigned short ACTIVE;
const unsigned short IDLE;
readonly attribute unsigned short idleState;
};
Where idleState is one of:
idleState : active = 1, idle = 2, away = 3
Away is defined as locked/screen saver enabled or any other system mechanism
that is defined as away.
REFERENCES
1] There is research showing that it is possible to detemine a users key
strokes and which keys they are actually typeing by using millisecond
accuracy idle time information. This is the reason this spec emphasises the
jitter and granularity aspects of the idle detection.
http://portal.acm.org/citation.cfm?id=1267637
On Tue, Sep 1, 2009 at 4:33 PM, David Bennett d...@google.com wrote:
On Tue, Sep 1, 2009 at 4:26 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Sep 1, 2009 at 3:53 PM, Mike Wilson mike...@hotmail.com wrote:
David Bennett wrote:
On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson atwil...@google.comwrote:
This would be my inclination as well. I'm not entirely convinced that
every web app should define their own idle timeout is such desirable
behavior that we should build our API around it by forcing every caller to
specify their idle timeout - having a standard event that's fired with an
exposed state for apps that need it seems like a cleaner approach.
The trouble with this is it doesn't allow any experimentation on the part
of the app/entity to figure out what is the best idle time for it's
purposes. In terms of chat it might be that a 3 minute or 5 minute idle
time works best in terms of people's attention. For something like watching
a video perhaps a 15 minute idle would be a better length of time, or for an
online game a longer idle time is probably useful before being signed out.
Different purposes have different requirements for the idle time so it
makes sense to allow them to specify the different timeouts.
This requirement could be solved in several other ways, f ex making sure
that the standard timeout period is short enough to not be longer than
what any app wants. Then (as was previously suggested) an app that wants a
longer timeout can do setTimeout and trigger its own idle stuff if
Re: [whatwg] HTML extension for system idle detection.
Actually, one small change. I think I need the idle time in seconds in the
event, in case different UAs implement different idles as their minimum
time.
// The event fired when the idle state of the system changes.
interface IdleStateChangeEvent : Event
{
const unsigned short AWAY;
const unsigned short ACTIVE;
const unsigned short IDLE
;
readonly attribute unsigned short idleState;
readonly attribute unsigned long idleTimeInSec;
};
This way the js can find the actual time and do a timer event to get the
idle time it is looking for.
Thanks,
David.
On Tue, Sep 15, 2009 at 5:13 PM, David Bennett d...@google.com wrote:
Morning,
Updated the document for the proposal which now uses an event callback for
the system idle along with a method to get the current system idle time.
Comments on the update proposal?
Thanks,
David.
SUMMARY
There currently is no way to detect the system idle state in the browser.
This makes it difficult to deal with any sort of chat room or instant
messaging client inside the browser since the idle will always be incorrect.
USE CASE
Any instant messaging client, or any client that requires user presence,
will use this to keep track of the users idle state. Currently the idle
state of a user inside a browser tell tend to be incorrect, and this leads
to problems with people being unable to rely on the available status of a
user. Without this information it is difficult to do a full featured and
reliable instant messaging client inside the browser since this makes the
users' status somewhat unreliable.
Lots of social networking sites and other sites centered around user
interactions on the net keep track of the users idle state for enabling
interactions with people that are currently online, this would be especially
useful for interactive online gaming.
A process that would like to do some heavy duty processing, like s...@home,
could use the system idle detection to enable the processing only when the
user is idle and enable it to not interfere with or degrade their normal
browsing experience.
WORK AROUNDS
The idle state of the user is currently detected by looking at the brower
window and detecting the last activity time for the window. This is
inaccurate since if the user is not looking at the page the state will be
incorrect and means that the idle time is set to longer than would be
desirable so there is also a window in which the user is actually idle but
it has not yet been detected.
PROPOSAL
I propose an api which enables an event for the minimum idle timeout and
has a query to determine the current system idle. The event is fired when
the state changes. Active-idle, Active-away, idle-away, idle-active,
away-active.
The idle times are all specified in seconds, the event will be fired when
the idle state changes.
Not explicitly specified, and thus intentionally left to the UA, include:
* The event will be fired after the minimum system idle time for the
property; 2 minutes. [1]
* Any jitter intentionally added to the idle times reported [1]
* The granularity of the times reported (e.g. a UA may round them to
multiples of 15 seconds)
[NoInterfaceObject,
ImplementedOn=Windowhttp://www.w3.org/TR/html5/browsers.html#window]
interface WindowTimers {
// timers
// Returns the current system idle state.
int systemIdleState();
// The event fired when the idle state of the system changes.
interface IdleStateChangeEvent : Event
{
const unsigned short AWAY;
const unsigned short ACTIVE;
const unsigned short IDLE;
readonly attribute unsigned short idleState;
};
Where idleState is one of:
idleState : active = 1, idle = 2, away = 3
Away is defined as locked/screen saver enabled or any other system
mechanism that is defined as away.
REFERENCES
1] There is research showing that it is possible to detemine a users key
strokes and which keys they are actually typeing by using millisecond
accuracy idle time information. This is the reason this spec emphasises the
jitter and granularity aspects of the idle detection.
http://portal.acm.org/citation.cfm?id=1267637
On Tue, Sep 1, 2009 at 4:33 PM, David Bennett d...@google.com wrote:
On Tue, Sep 1, 2009 at 4:26 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Sep 1, 2009 at 3:53 PM, Mike Wilson mike...@hotmail.com wrote:
David Bennett wrote:
On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson atwil...@google.comwrote:
This would be my inclination as well. I'm not entirely convinced that
every web app should define their own idle timeout is such desirable
behavior that we should build our API around it by forcing every caller to
specify their idle timeout - having a standard event that's fired with an
exposed state for apps that need it seems like a cleaner approach.
The trouble with this is it doesn't allow any experimentation on the
part of the app/entity to figure out what is the best idle time for it's
purposes. In terms of
Re: [whatwg] Inter-window communication beyond window.postMessage()
On Mon, 14 Sep 2009, Jeremy Orlow wrote: On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Sep 2009, Sidney San Mart�n wrote: The cross-document messaging API solves a lot of problems and is overall an Awesome Thing, but requiring a reference to the target window is hugely limiting. When a a window wants to talk to another window and didn't create it, there are basically three options: 1. window.open with a window name argument, which is a hack because the target window has to reload. 2. Comet, which is a horrible hack because a trip to the server is required. 3. LocalStorage and storage events, which wasn't designed for anything remotely like this. 4. Open a SharedWorker and send a MessagePort to the other window. Unless there's a reason to prevent free communication between windows, there must be a better solution. I can think of a couple of possibilities. The most obvious one would be an API similar to postMessage that allows broadcasting of messages to all windows, windows by name, and windows by domain. Another one (which I haven't developed very far) would be to stick with window.postMessage but provide an API to ask for windows. So, I could say, Can I please have a reference to the window named 'x', or, ...to windows at 'example.com', or, ...to any window who'll give me one. Each window would obviously have to opt into this. What do you all think? How do you know there's a Window to get a hold of if you don't have a hold of it already? The main reason for Window.postMessage() is communication with iframes (gadgets), not with other top-level browsing contexts. What's the use case for the latter? I assume the use case for this is similar with the use case for storage events which essentially is a broadcast mechanism that's specific to just DOM storage. So if, for example, you wanted to tell your other windows hey! I changed the cookie then you could do it with a message. This seems much better than, for example polling. This could also be useful if you wanted to say hey, I just navigated to gmail.com. Do any of you already have the inbox and chat contacts loaded up?. I suppose there's not much advantage to doing it like this over shared workers since either way you're passing messages, but I also don't see any major downsides to allowing broadcasts. Yeah, a broadcast mechanism could make sense. Shared workers are probably a reasonable interim measure though, to help us gauge how much this is really needed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Global Script proposal.
On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Sep 2009, Dimitri Glazkov wrote: On Sat, Aug 29, 2009 at 2:40 PM, Ian Hicksoni...@hixie.ch wrote: Another case is an application that uses navigation from page to page using menu or some site navigation mechanism. Global Script Context could keep the application state so it doesn't have to be round-tripped via server in a cookie or URL. You can keep the state using sessionStorage or localStorage, or you can use pushState() instead of actual navigation. First off, sessionStorage and localStorage are not anywhere close to being useful if you're dealing with the actual DOM objects. The JS code that would freeze-dry them and bring back to life will make the whole exercise cost-prohibitive. Indeed. I don't see why you would want to be keeping nodes alive while navigating to entirely new documents though. But more to the point, I think globalScript is a good replacement for the pushState additions to the History spec. I've been reading up on the spec an the comments made about pushState and I am becoming somewhat convinced that pushState is confusing, hard to get right, and full of fail. You should simply look at the motivation behind building JS-based history state managers -- it all becomes fairly clear. The best analogy I can muster is this: pushHistory is like creating Rhoad's-like kinetic machines for moving furniture around the house in an effort to keep the tenant standing still. Whereas globalScript proposes to just let the poor slob to walk to the chest to get the damn socks. My big issue with pushHistory is that it messes with the nature of the Web: a URL is a resource you request from the server. Not something you arrive to via clever sleight of hand in a user agent. So, you've managed to pushState your way to a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks it. What are you going to do know? Intuitively, it feels like we should be improving the user agent to eliminate the need for mucking with history, not providing more tools to encourage it. The only criticism of substance in the above -- that pushState() lets you change the URL of the current page when you change the page dynamically -- is pretty much the entire point of the feature, and I don't understand why it's bad. I certainly don't want to require that every pan on Google Maps require a new page load. On Tue, 8 Sep 2009, Anne van Kesteren wrote: If JavaScript can be somehow kept-alive while navigating to a new page within a single domain, be in control of what is displayed and without security issues and all that'd be rather cool and also solve the issue. This seems substantially less preferable, performance-wise, than having a single Document and script, using pushState(). It depends, right? That single Document+script would have to have all the resources and code to be able to morph itself into all the possible app states, preventing benefits of lazy-loading. Or, to be more efficient, it should load additional resources on demand, which looks very close to navigation to subsequent pages. Today, those natural navigations from page to page are prohibitively expensive, even with caches - they are equivalent to serialization of everything into some storage, terminating the app, then launching the app again, loading state from storage and/or cloud, setting up the UI etc. So AJAX is the only real alternative today, although it comes with complex pages that have to construct UI dynamically. History management API is great, but it is also an overkill to say that every app should necessarily be a single complex AJAX page morphing itself. That in itself may be a serious limitation.
Re: [whatwg] article/section/details naming/definition problems
On Tue, 15 Sep 2009, Jeremy Keith wrote: Henri wrote: http://adactio.com/journal/1607/ Ah, you beat me to it. I was just about to write an email to the list, honestly. ;-) So anyway, the upshot of my somewhat unscientific survey[1] conducted at a workshop a couple of weeks ago is that there is great confusion between the section and article elements. I've tweaked their definitions (as well as a few others) to take this data into account. Thanks for this research, by the way, it's very useful. In that blog post, I point out that section and article were once more divergent but have converged over time (since the @cite and @pubdate attributes were dropped from article). I've also seen a lot of confusion from authors wondering when to use section and when to use article. Bruce wrote an article on HTML5 doctor recently to address this: http://html5doctor.com/the-section-element/ Probably the best tutorial I've seen on this issue is from Ted: http://edward.oconnor.cx/2009/09/using-the-html5-sectioning-elements ...but even so, the confusion remains. The very fact that tutorials are required for what should be intuitive structural elements is worrying — I don't see the same issues around nav, header or footer (now that the content model has been changed) ...although there is continuing confusion around aside. I'd like to rename article, if someone can come up with a better word that means blog post, blog comment, forum post, or widget. I do think there is an important difference between a subpart of a page that is a potential candidate for syndication, and a subsection of a page that only makes sense with the rest of the page. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] article/section/details naming/definition problems
On Tue, Sep 15, 2009 at 6:08 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 15 Sep 2009, Jeremy Keith wrote: Henri wrote: http://adactio.com/journal/1607/ Ah, you beat me to it. I was just about to write an email to the list, honestly. ;-) So anyway, the upshot of my somewhat unscientific survey[1] conducted at a workshop a couple of weeks ago is that there is great confusion between the section and article elements. I've tweaked their definitions (as well as a few others) to take this data into account. Thanks for this research, by the way, it's very useful. In that blog post, I point out that section and article were once more divergent but have converged over time (since the @cite and @pubdate attributes were dropped from article). I've also seen a lot of confusion from authors wondering when to use section and when to use article. Bruce wrote an article on HTML5 doctor recently to address this: http://html5doctor.com/the-section-element/ Probably the best tutorial I've seen on this issue is from Ted: http://edward.oconnor.cx/2009/09/using-the-html5-sectioning-elements ...but even so, the confusion remains. The very fact that tutorials are required for what should be intuitive structural elements is worrying — I don't see the same issues around nav, header or footer (now that the content model has been changed) ...although there is continuing confusion around aside. I'd like to rename article, if someone can come up with a better word that means blog post, blog comment, forum post, or widget. I do think there is an important difference between a subpart of a page that is a potential candidate for syndication, and a subsection of a page that only makes sense with the rest of the page. How about section type=article or section article=? Or can we leave it to a predefined microformat (as much as I'm not a fan of those) / Jonas
[whatwg] Setting .value on input type=file
Hi All, Currently the spec says to throw an INVALID_ACCESS_ERR exception anytime the 'value' IDL attribute is set. However allowing it to be set to the empty string would be good. The simplest use case is allowing the page to implement a 'cancel' button. Many UAs (in fact all that I know of) don't have explicit UI for clearing the field. In fact a quick test shows that at least Firefox and Safari has no way to clear the field at all. While the page can always delete the old input element and create a new one, that is much more complicated. Especially if the element has event listeners or user data associated with it. Setting it to the empty string works in Firefox, Safari, and Chrome. It does not appear to work in IE or Opera. / Jonas
[whatwg] LocalStorage in workers
I've talked to a lot of web developers about workers and the one thing that
they keep expressing to me is how disappointing it is to not have access to
LocalStorage. I tell them about the work around which is to pass a
message back to the page (or, in the case of shared workers, any page) and
ask it to look up the value, but this approach is uninteresting to most of
them. Enough so that most of them have said they'd probably just wait until
workers were more mature (and/or WebDatabase was more widely available)
before bothering with them.
The problem is that LocalStorage is a synchronous interface. When you
access it from a normal web page, all other event loops that try to access
it will block until either you exit your script context or call
yieldForStorageUpdates manually. Of course, during this time, the UI of the
browser will be locked up and many UAs would present the user with a slow
script dialog. This is (hopefully) enough to keep web apps reasonably in
check.
Unfortunately, it's perfectly reasonable for a worker to run forever. For
example, it might calculate pi. If, for example, that worker periodically
saved the value of pi to localStorage (and didn't call
yieldForStorageUpdates) then you could block your other event loops forever.
Even if a worker held the lock for a couple hundred milliseconds, it could
still affect the responsiveness of a web browser in a perceivable for no
apparent reason (from the users perspective). For this reason, it was taken
out of the spec.
One possible solution is to add an asynchronous callback interface for
LocalStorage into workers. For example:
function myCallback(localStorage) {
localStorage.accountBalance = localStorage.accountBalance + 100;
}
executeLocalStorageCallback(myCallback); // TODO: Make this name better
:-)
The interface is simple. You can only access localStorage via a callback.
Any use outside of the callback is illegal and would raise an exception.
The callback would acquire the storage mutex during execution, but the
worker's execution would not block during this time. Of course, it's still
possible for a poorly behaving worker to do large amounts of computation in
the callback, but hopefully the fact they're executing in a callback makes
the developer more aware of the problem.
I admit that this is not a great solution and would definitely like to hear
alternate proposals. But, no matter what, I think we need to think
seriously about giving workers access to LocalStorage again.
J
Re: [whatwg] Global Script proposal.
to say that every app should necessarily be a single complex AJAX page morphing itself. That in itself may be a serious limitation. Agree very much so. On Tue, Sep 15, 2009 at 5:54 PM, Dmitry Titov dim...@chromium.org wrote: On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Sep 2009, Dimitri Glazkov wrote: On Sat, Aug 29, 2009 at 2:40 PM, Ian Hicksoni...@hixie.ch wrote: Another case is an application that uses navigation from page to page using menu or some site navigation mechanism. Global Script Context could keep the application state so it doesn't have to be round-tripped via server in a cookie or URL. You can keep the state using sessionStorage or localStorage, or you can use pushState() instead of actual navigation. First off, sessionStorage and localStorage are not anywhere close to being useful if you're dealing with the actual DOM objects. The JS code that would freeze-dry them and bring back to life will make the whole exercise cost-prohibitive. Indeed. I don't see why you would want to be keeping nodes alive while navigating to entirely new documents though. But more to the point, I think globalScript is a good replacement for the pushState additions to the History spec. I've been reading up on the spec an the comments made about pushState and I am becoming somewhat convinced that pushState is confusing, hard to get right, and full of fail. You should simply look at the motivation behind building JS-based history state managers -- it all becomes fairly clear. The best analogy I can muster is this: pushHistory is like creating Rhoad's-like kinetic machines for moving furniture around the house in an effort to keep the tenant standing still. Whereas globalScript proposes to just let the poor slob to walk to the chest to get the damn socks. My big issue with pushHistory is that it messes with the nature of the Web: a URL is a resource you request from the server. Not something you arrive to via clever sleight of hand in a user agent. So, you've managed to pushState your way to a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks it. What are you going to do know? Intuitively, it feels like we should be improving the user agent to eliminate the need for mucking with history, not providing more tools to encourage it. The only criticism of substance in the above -- that pushState() lets you change the URL of the current page when you change the page dynamically -- is pretty much the entire point of the feature, and I don't understand why it's bad. I certainly don't want to require that every pan on Google Maps require a new page load. On Tue, 8 Sep 2009, Anne van Kesteren wrote: If JavaScript can be somehow kept-alive while navigating to a new page within a single domain, be in control of what is displayed and without security issues and all that'd be rather cool and also solve the issue. This seems substantially less preferable, performance-wise, than having a single Document and script, using pushState(). It depends, right? That single Document+script would have to have all the resources and code to be able to morph itself into all the possible app states, preventing benefits of lazy-loading. Or, to be more efficient, it should load additional resources on demand, which looks very close to navigation to subsequent pages. Today, those natural navigations from page to page are prohibitively expensive, even with caches - they are equivalent to serialization of everything into some storage, terminating the app, then launching the app again, loading state from storage and/or cloud, setting up the UI etc. So AJAX is the only real alternative today, although it comes with complex pages that have to construct UI dynamically. History management API is great, but it is also an overkill to say that every app should necessarily be a single complex AJAX page morphing itself. That in itself may be a serious limitation.
Re: [whatwg] article/section/details naming/definition problems
On Tue, Sep 15, 2009 at 9:08 PM, Ian Hickson i...@hixie.ch wrote: I'd like to rename article, if someone can come up with a better word that means blog post, blog comment, forum post, or widget. I do think there is an important difference between a subpart of a page that is a potential candidate for syndication, Perhaps something with a meaning, along the lines of EXCERPT, maybe? and a subsection of a page that only makes sense with the rest of the page. -- -- -- -- ô¿ô¬ K e V i N /¯\
Re: [whatwg] LocalStorage in workers
On Tue, Sep 15, 2009 at 6:56 PM, Jeremy Orlow jor...@chromium.org wrote:
One possible solution is to add an asynchronous callback interface for
LocalStorage into workers. For example:
function myCallback(localStorage) {
localStorage.accountBalance = localStorage.accountBalance + 100;
}
executeLocalStorageCallback(myCallback); // TODO: Make this name better
:-)
The interface is simple. You can only access localStorage via a callback.
Any use outside of the callback is illegal and would raise an exception.
The callback would acquire the storage mutex during execution, but the
worker's execution would not block during this time. Of course, it's still
possible for a poorly behaving worker to do large amounts of computation in
the callback, but hopefully the fact they're executing in a callback makes
the developer more aware of the problem.
First off, I agree that not having localStorage in workers is a big
problem that we need to address.
If I were designing the localStorage interface today I would use the
above interface that you suggest. Grabbing localStorage can only be
done asynchronously, and while you're using it, no one else can get a
reference to it. This way there are no race conditions, but also no
way for anyone to have to lock.
So one solution is to do that in parallel to the current localStorage
interface. Let's say we introduce a 'clientStorage' object. You can
only get a reference to it using a 'getClientStorage' function. This
function is available both to workers and windows. The storage is
separate from localStorage so no need to worry about the 'storage
mutex'.
There is of course a risk that a worker grabs on to the clientStorage
and holds it indefinitely. This would result in the main window (or
another worker) never getting a reference to it. However it doesn't
affect responsiveness of that window, it's just that the callback will
never happen. While that's not ideal, it seems like a smaller problem
than any other solution that I can think of. And the WebDatabase
interfaces are suffering from the same problem if I understand things
correctly.
There's a couple of other interesting things we could expose on top of this:
First, a synchronous API for workers. We could allow workers to
synchronously get a reference to clientStorage. If someone is
currently using clientStorage then the worker blocks until the storage
becomes available. We could either use a callback as the above, which
blocks until the clientStorage is acquired and only holds the storage
until the callback exists. Or we could expose clientStorage as a
property which holds the storage until control is returned to the
worker eventloop, or until some explicit release API is called. The
latter would be how localStorage is now defined, with the important
difference that localStorage exposes the synchronous API to windows.
Second, allow several named storage areas. We could add an API like
getNamedClientStorage(name, callback). This would allow two different
workers to simultaneously store things in a storage areas, as long as
they don't need to use the *same* storage area. It would also allow a
worker and the main window to simultaneously use separate storage
areas.
However we need to be careful if we add both above features. We can't
allow a worker to grab multiple storage areas at the same time since
that could cause deadlocks. However with proper APIs I believe we can
avoid that.
/ Jonas
Re: [whatwg] HTML 5 drag and drop feedback
On Tue, 15 Sep 2009, Nabil Elisa wrote: Furthermore I'm not sure I agree with Ian's argument for holding out until the browsers support the current API more reliably. My experience has shown that there are numerous cross-browser incompatibilities in the existing implementations of more trivial features, yet we are not waiting for all of those to get resolved before adding support for, say, native video. So why should this be any different? The browser vendors were implementing video whether we specced it or not. Anyway, I'm new to this group and don't know much about how decisions are usually made here, but in case there was any doubt about this idea's popularity I'd like to lend it my own +1. Decisions are made based on their technical merits, it doesn't matter how many people support it. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
