Re: [whatwg] Language codes: RFC 3066 versus RFC 4646
On Fri, 3 Apr 2009, Julian Reschke wrote: But maybe it is. Checking references earlier catches problems earlier. It's WHATWG policy to not fill in the references section until a spec is basically complete. For HTML5 this is scheduled for August. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Help us review HTML5!
Hi Havent read it all yet, but I did a search, and found nothing about the keygen element. Isnt that suposed to be in there, or do you miss documentation on it? If you are missing documentation, I will be happy to try to write something in the same format as the other tags.. Thanks Regards Lars On Fri, Apr 3, 2009 at 1:01 AM, Ian Hickson i...@hixie.ch wrote: Have you been lurking here but wanting to do more? Now that HTML5 is starting to get more stable, it's time to ramp up the review process, so if you have been waiting for a reason to jump in, here it is. Open one of the versions of the spec: One page version http://www.whatwg.org/specs/web-apps/current-work/ Multipage version http://whatwg.org/html5 A4 PDF http://www.whatwg.org/specs/web-apps/current-work/html5-a4.pdf Letter PDF http://www.whatwg.org/specs/web-apps/current-work/html5-letter.pdf ...and start reading! See below for ideas of what to look for. If you find a problem, either send an e-mail to this mailing list, or file a bug (registration required) here: http://www.w3.org/Bugs/Public/enter_bug.cgi?component=Spec%20bugsamp;priority=P3amp;product=HTML%20WGamp;rep_platform=All The plan is to see whether we can shake down the spec and get rid of all the minor problems that have so far been overlooked. Typos, confusion, cross-reference errors, as well as mistakes in examples, errors in the definitions, and major errors like security bugs or contradictions. Anyone who helps find problems in the spec -- however minor --- will get their name in the acknowledgements section. You don't really need any experience to find the simplest class of problems: things that are confusing! If you don't understand something, then that's a problem. Not all the introduction sections and examples are yet written, but if there is a section with an introduction section that isn't clear, then you've found an issue: let us know! Something else that would now be good to search for is typos, spelling errors, grammar errors, and the like. Don't hesitate to send e-mails even for minor typos, all feedback even on such small issues is very welcome. If you have a specific need as a Web designer, then try to see if the need is met. If it isn't, and you haven't discussed this need before, then send an e-mail to the list. (So for example, if you want HTML to support date picker widgets, you'd look in the spec to see if it was covered. As it turns out, that one is!) If you have some specific expertise that lets you review a particular part of the spec for correctness, then that's another thing to look for. For example if you know about graphics, then reviewing the 2D Canvas API section would be a good use of your resources. If you know about scripting, then looking at the Web browsers section would be a good use of your time. If everything goes according to plan, I will respon to all issues by October. You can track how many issues remain to be responded to here: http://www.whatwg.org/issues/data.html You are encouraged to join our IRC channel #whatwg on Freenode to stay in touch with what other people are doing, but this is by no means required. You are also encouraged to post in the Discussion section on the wiki page: http://wiki.whatwg.org/wiki/Reviewing_HTML5#Discussion ...or in the blog comments for the corresponding blog post: http://blog.whatwg.org/help-us-review-html5 ...to let people know what you are reviewing. You can get news updates by following @WHATWG on Twitter. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Worker feedback
On Fri, 03 Apr 2009 06:26:43 +0200, Robert O'Callahan rob...@ocallahan.org wrote: Mozilla could probably get behind that, but I don't know who else is willing to bite the bullet. The problem already exists for document.cookie, no? And the current API is by far the most convenient the use. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] HTML5 review: typo found
The word string is misspelled as stirng here: http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv-refresh It's the last word at point #18. Woohoo, I'm gonna be famous! I'll try to do more at a time from now on, just wanted to secure my place in history. :) Alexis Deveria http://a.deveria.com
Re: [whatwg] Worker feedback
On Fri, Apr 3, 2009 at 2:18 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 03 Apr 2009 06:26:43 +0200, Robert O'Callahan rob...@ocallahan.org wrote: Mozilla could probably get behind that, but I don't know who else is willing to bite the bullet. The problem already exists for document.cookie, no? And the current API is by far the most convenient the use. If I understood the discussion correctly, the spec for document.cookie never stated anything about it being immutable while a script is running. People are now talking about specifying this, but there's been push back. Also, there's no way to guarantee serializability for the network traffic portion so I'm guessing (hoping!) that this wouldn't be required in the JavaScript side, even if it went through. localStorage, on the other hand, does have language in the draft spec stating that changes to localStorage must be serialized as if only one event loop is running at a time. That's the problem. In other words, the strictness of the concurrency control for localStorage is what makes this different from document.cookie. As for convenience: The spec is written in such a way that you can't have more that one event loop per browser window/worker, and everything is essentially tied to this one event loop. In other words, each window/worker can't run on more than one CPU core at a time. Thus, the only way for a web application to scale in todays world is going to be through additional windows and/or workers. I agree that the current API is quite convenient, but it worries me a great deal that it's synchronous. Now that navigator.unlockStorage() has been added to the spec and you can't access localStorage from workers, I'm less worried. But I still feel like we're going to regret this in the next couple years and/or people will simply avoid localStorage. J
Re: [whatwg] Worker feedback
On Thu, Apr 2, 2009 at 8:37 PM, Robert O'Callahan rob...@ocallahan.org wrote: I agree it would make sense for new APIs to impose much greater constraints on consumers, such as requiring them to factor code into transactions, declare up-front the entire scope of resources that will be accessed, and enforce those restrictions, preferably syntactically --- Jonas' asynchronous multi-resource-acquisition callback, for example. Speaking as a novice javascript developer, this feels like the cleanest, simplest, most easily comprehensible way to solve this problem. We define what needs to be locked all at once, provide a callback, and within the dynamic context of the callback no further locks are acquirable. You have to completely exit the callback and start a new lock block if you need more resources. This prevents deadlocks, while still giving us developers a simple way to express what we need. As well, callbacks are at this point a relatively novice concept, as every major javascript library makes heavy use of them. ~TJ
[whatwg] cross-domain scrollIntoView on frames and iframes
I'm suggesting an addition to cross-domain (i)frames that allows scrolling specific content into view. The use case is sites that aggregate data from many sites (e.g. search engines) and want to display that data in an iframe. They can load the page in an iframe, but they have no way to make the content visible as they don't have access to the iframe's contents. A few possible APIs come to mind. I personally prefer the javascripty option below, but I'll include another one for good measure. 1) Add a scrollPathIntoView (with a better name) on iframes that takes either an xpath or a css selector and scrolls the specified item into view. If no such item exists, it does nothing. If one or more such items exist, it calls scrollIntoView on the first matching item. 2) Add a css or xpath expression to fragment identifiers. Tthe iframe src can be set to http://foo.com#css(.foo http://foo.com/#css(.foo #bar). Same as above applies. If there's no match, it's a noop. If there is a match, it scrolls the first one into view. In both cases, no explicit success or failure is returned to the caller as that would leak the iframes DOM across domains. This API can obviously be supported on same-domain iframes as well, but it's not really necessary since you can just dig into the DOM of the iframe. Ojan
Re: [whatwg] Worker feedback
I know I said I would stay out of this conversation, but I feel obliged to share a data point that's pertinent to our API design. The structured storage spec has an asynchronous API currently. There are no shortage of experienced javascript programmers at Google, and yet the single biggest piece of feedback I've gotten from the internal app community has been (essentially): The asynchronous APIs are too cumbersome. We are going to delay porting over to use the HTML5 APIs until we have synchronous APIs, like the ones in Gears. So, we should all take the whining of pampered Google engineers with a grain of salt :), but the point remains that even though callbacks are conceptually familiar and easy to use, it's not always convenient (or possible!) for an application to stop an operation in the middle and resume it via an asynchronous callback. Imagine if you're a library author that exposes a synchronous API for your clients - now you'd like to use localStorage within your library, but there's no way to do it while maintaining your existing synchronous APIs. If we try to force everyone to use asynchronous APIs to access local storage, the first thing everyone is going to do is build their own write-through caching wrapper objects around local storage to give them synchronous read access and lazy writes, which generates precisely the type of racy behavior we're trying to avoid. If we can capture the correct behavior using synchronous APIs, we should. -atw On Fri, Apr 3, 2009 at 11:44 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Thu, Apr 2, 2009 at 8:37 PM, Robert O'Callahan rob...@ocallahan.org wrote: I agree it would make sense for new APIs to impose much greater constraints on consumers, such as requiring them to factor code into transactions, declare up-front the entire scope of resources that will be accessed, and enforce those restrictions, preferably syntactically --- Jonas' asynchronous multi-resource-acquisition callback, for example. Speaking as a novice javascript developer, this feels like the cleanest, simplest, most easily comprehensible way to solve this problem. We define what needs to be locked all at once, provide a callback, and within the dynamic context of the callback no further locks are acquirable. You have to completely exit the callback and start a new lock block if you need more resources. This prevents deadlocks, while still giving us developers a simple way to express what we need. As well, callbacks are at this point a relatively novice concept, as every major javascript library makes heavy use of them. ~TJ
Re: [whatwg] Worker feedback
On Fri, Apr 3, 2009 at 2:25 PM, Drew Wilson atwil...@google.com wrote: If we can capture the correct behavior using synchronous APIs, we should. I think we already have a good, correct, synchronous API. My concern is the implications to the internals of the implemenation. Anyway, given that no one is chiming in to my defense, either no one really cares enough to have read this far or no one agrees with me. Either way, I guess I'll quite down. :-)
Re: [whatwg] Worker feedback
On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow jor...@google.com wrote: If I understood the discussion correctly, the spec for document.cookie never stated anything about it being immutable while a script is running. Well, there never was a decent spec for document.cookie for most of its life, and even if there had been, no implementations allowed asynchronous changes to cookies while a script was running (except for maybe during alert()) and no-one really thought about it. Was this even identified as a possible issue during Chrome development? People are now talking about specifying this, but there's been push back. Also, there's no way to guarantee serializability for the network traffic portion so I'm guessing (hoping!) that this wouldn't be required in the JavaScript side, even if it went through. What exactly do you mean by that? It's easy to guarantee that reading the cookies to send with an HTTP request is an atomic operation, and writing them as a result of an HTTP response is an atomic operation. The spec is written in such a way that you can't have more that one event loop per browser window/worker, and everything is essentially tied to this one event loop. In other words, each window/worker can't run on more than one CPU core at a time. Thus, the only way for a web application to scale in todays world is going to be through additional windows and/or workers. Depending on exactly what you mean by a Web application, that's not really true. There are a variety of ways to exploit multicore parallelism within a window with the current set of specs, at least in principle. 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]
[whatwg] How long should sessionStorage data persist?
I created a page that sets a variable in sessionStorage, then I navigated to a different domain, then I went back to the page and checked if the variable was still set. In Safari 4 (beta) it is. In IE8 it isn't. The spec is not terribly clear: When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user) the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever be subsequently retrieved. Can anyone explain what's intended here? If not, can the spec make it more clear? Jeremy
Re: [whatwg] How long should sessionStorage data persist?
On Fri, 3 Apr 2009, Jeremy Orlow wrote: I created a page that sets a variable in sessionStorage, then I navigated to a different domain, then I went back to the page and checked if the variable was still set. In Safari 4 (beta) it is. In IE8 it isn't. The spec is not terribly clear: When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user) the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever be subsequently retrieved. Can anyone explain what's intended here? If not, can the spec make it more clear? IE8 is buggy according to the text you quoted. I don't understand why the text is unclear. Does the definition of browsing context not leave this unambiguous? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Worker feedback
On Fri, Apr 3, 2009 at 2:49 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow jor...@google.com wrote: People are now talking about specifying this, but there's been push back. Also, there's no way to guarantee serializability for the network traffic portion so I'm guessing (hoping!) that this wouldn't be required in the JavaScript side, even if it went through. What exactly do you mean by that? It's easy to guarantee that reading the cookies to send with an HTTP request is an atomic operation, and writing them as a result of an HTTP response is an atomic operation. True serializability would imply that the HTTP request read and write are atomic. In other words, you'd have to keep a lock for the entirety of each HTTP request and couldn't do multiple in parallel. When I said there's no way to guarantee serializability, I guess I meant to qualify it with in practice. After thinking about it for a bit, your suggestion of reading the cookies to send with an HTTP request is an atomic operation, and writing them as a result of an HTTP response is an atomic operation does seems like a pretty sensible compromise. The one thing I'd still be concerned about: localStorage separates storage space by origins. In other words, www.google.com cannot access localStorage values from google.com and visa versa. Cookies, on the other hand, have a much more complex scheme of access control. Coming up with an efficient and dead-lock-proof locking scheme might take some careful thought. The spec is written in such a way that you can't have more that one event loop per browser window/worker, and everything is essentially tied to this one event loop. In other words, each window/worker can't run on more than one CPU core at a time. Thus, the only way for a web application to scale in todays world is going to be through additional windows and/or workers. Depending on exactly what you mean by a Web application, that's not really true. There are a variety of ways to exploit multicore parallelism within a window with the current set of specs, at least in principle. What else is there? (I believe you, I'm just interested in knowing what's out there.) Jeremy P.S. Please don't mistake me for an expert on document.cookie or even window.localStorage. I try to fact check myself as I go, but if I say something that seems stupid, please do let me know. :-)
Re: [whatwg] How long should sessionStorage data persist?
On Fri, Apr 3, 2009 at 3:16 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 3 Apr 2009, Jeremy Orlow wrote: I created a page that sets a variable in sessionStorage, then I navigated to a different domain, then I went back to the page and checked if the variable was still set. In Safari 4 (beta) it is. In IE8 it isn't. The spec is not terribly clear: When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user) the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever be subsequently retrieved. Can anyone explain what's intended here? If not, can the spec make it more clear? IE8 is buggy according to the text you quoted. I don't understand why the text is unclear. Does the definition of browsing context not leave this unambiguous? My mistake. Browsing context does make this clear. Sorry!
Re: [whatwg] How long should sessionStorage data persist?
On Fri, Apr 3, 2009 at 3:16 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 3 Apr 2009, Jeremy Orlow wrote: I created a page that sets a variable in sessionStorage, then I navigated to a different domain, then I went back to the page and checked if the variable was still set. In Safari 4 (beta) it is. In IE8 it isn't. The spec is not terribly clear: When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user) the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever be subsequently retrieved. Can anyone explain what's intended here? If not, can the spec make it more clear? IE8 is buggy according to the text you quoted. I don't understand why the text is unclear. Does the definition of browsing context not leave this unambiguous? Hmm... In Chrome we also create a new browsing context when the user types a new URL into the location bar of an existing tab. This can be thought of as a shortcut for create a new tab with the given URL and close the old tab. (We only do this when the new URL is of a different domain.) Perhaps, IE8 is doing something similar. Jeremy didn't say how he navigated. A link click or any content driven navigation cannot be treated like this of course. However, I believe that we should still restore the old sessionStorage when the user navigates back to the old URL just as we do for form state, scroll position, and other attributes normally associated with session history. -Darin
Re: [whatwg] How long should sessionStorage data persist?
On Fri, Apr 3, 2009 at 5:03 PM, Darin Fisher da...@chromium.org wrote: Hmm... In Chrome we also create a new browsing context when the user types a new URL into the location bar of an existing tab. This can be thought of as a shortcut for create a new tab with the given URL and close the old tab. (We only do this when the new URL is of a different domain.) Perhaps, IE8 is doing something similar. Jeremy didn't say how he navigated. A link click or any content driven navigation cannot be treated like this of course. However, I believe that we should still restore the old sessionStorage when the user navigates back to the old URL just as we do for form state, scroll position, and other attributes normally associated with session history. I typed a new URL into the address bar. I suppose I should try a links based experiment as well. And yes, we'll have to copy this code out of the render process if we want such a scenario to work in Chrome.
Re: [whatwg] How long should sessionStorage data persist?
On Fri, 3 Apr 2009, Darin Fisher wrote: In Chrome we also create a new browsing context when the user types a new URL into the location bar of an existing tab. So a user can't hit the back button after typing in a URL? The term browsing context in the spec basically corresponds to the session history exposed by window.history, and the outer Window object that the history is on. However, I believe that we should still restore the old sessionStorage when the user navigates back to the old URL just as we do for form state, scroll position, and other attributes normally associated with session history. That's basically what the spec says. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How long should sessionStorage data persist?
Ian Hickson wrote: The term browsing context in the spec basically corresponds to the session history exposed by window.history, and the outer Window object that the history is on. How should this behave in a situation like Firefox's undo close tab, where the resulting tab has a brand-new window object but the window.history has been deserialized from a string representation. So it's a new object, but has the same information in it as the old one used to. Presumably in such a case this should be treated as the same browsing context in spite of the Window object being totally different? -Boris
Re: [whatwg] How long should sessionStorage data persist?
On Fri, 3 Apr 2009, Boris Zbarsky wrote: Ian Hickson wrote: The term browsing context in the spec basically corresponds to the session history exposed by window.history, and the outer Window object that the history is on. How should this behave in a situation like Firefox's undo close tab, where the resulting tab has a brand-new window object but the window.history has been deserialized from a string representation. So it's a new object, but has the same information in it as the old one used to. Presumably in such a case this should be treated as the same browsing context in spite of the Window object being totally different? From the HTML5 spec's point of view, that's a new browsing context. There's a 1:1 mapping from browsing context to outer Window (called WindowProxy in the spec). However, the Web Storage spec allows for this case: | When a new top-level browsing context is created by cloning an existing | browsing context, the new browsing context must start with the same | session storage areas as the original, but the two sets must from that | point on be considered separate, not affecting each other in any way. This was originally intended to cover IE's open new window functionality, which options a new window with a cloned session history, but Undo close tab should be considered a case of cloning a browsing context too. It just happens that the underlying browsing context is no longer accessible from script. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How long should sessionStorage data persist?
I think this also applies: NOTE: The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart. On Fri, Apr 3, 2009 at 6:46 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 3 Apr 2009, Boris Zbarsky wrote: Ian Hickson wrote: The term browsing context in the spec basically corresponds to the session history exposed by window.history, and the outer Window object that the history is on. How should this behave in a situation like Firefox's undo close tab, where the resulting tab has a brand-new window object but the window.history has been deserialized from a string representation. So it's a new object, but has the same information in it as the old one used to. Presumably in such a case this should be treated as the same browsing context in spite of the Window object being totally different? From the HTML5 spec's point of view, that's a new browsing context. There's a 1:1 mapping from browsing context to outer Window (called WindowProxy in the spec). However, the Web Storage spec allows for this case: | When a new top-level browsing context is created by cloning an existing | browsing context, the new browsing context must start with the same | session storage areas as the original, but the two sets must from that | point on be considered separate, not affecting each other in any way. This was originally intended to cover IE's open new window functionality, which options a new window with a cloned session history, but Undo close tab should be considered a case of cloning a browsing context too. It just happens that the underlying browsing context is no longer accessible from script. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How long should sessionStorage data persist?
Ian Hickson wrote: However, the Web Storage spec allows for this case: | When a new top-level browsing context is created by cloning an existing | browsing context, the new browsing context must start with the same | session storage areas as the original, but the two sets must from that | point on be considered separate, not affecting each other in any way. Aha. Indeed! -Boris
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
Ojan Vafai: 2) Add a css or xpath expression to fragment identifiers. Tthe iframe src can be set to http://foo.com#css(.foo #bar). Same as above applies. If there's no match, it's a noop. If there is a match, it scrolls the first one into view. Sounds like XPointer: http://www.w3.org/TR/xptr-framework/ -- Cameron McCormack ≝ http://mcc.id.au/
