From giecrilj at stegny.2a.pl Wed Apr 1 04:40:01 2009 From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=) Date: Wed, 1 Apr 2009 13:40:01 +0200 Subject: [whatwg] Notifications UI for Persistent Workers In-Reply-To: <5ce7a0db0903311848j36f8d6beu8f5387c893b76101@mail.gmail.com> References: <5ce7a0db0903311848j36f8d6beu8f5387c893b76101@mail.gmail.com> Message-ID: <1A3012ED56104D658A29CCC04C050735@POCZTOWIEC> I think text input controls should be disabled for HTML notifications so that notification windows cannot benefit from posing as something else. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsivonen at iki.fi Wed Apr 1 04:53:01 2009 From: hsivonen at iki.fi (Henri Sivonen) Date: Wed, 1 Apr 2009 14:53:01 +0300 Subject: [whatwg] Input type for phone numbers In-Reply-To: <49D25146.9060507@mit.edu> References: <49D234E0.9010503@mit.edu> <49D24543.9040708@gmx.ch> <49D24CA0.3010704@opera.com> <49D25146.9060507@mit.edu> Message-ID: <60321AFF-00BC-45A3-B5E2-CC8D0FEE4095@iki.fi> On Mar 31, 2009, at 20:22, Boris Zbarsky wrote: > I agree that entering a week is pretty rare, though. ;) Is this observation based on observing U.S. sites? type=week is meant for European business use. (It doesn't even support U.S. week numbers.) Being in Europe, I'm not convinced that week needs to be supported as an input, though. When I see week numbers used, it tends to involve output instead input, but I don't use European business scheduling apps. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From timeless at gmail.com Wed Apr 1 05:31:40 2009 From: timeless at gmail.com (timeless) Date: Wed, 1 Apr 2009 15:31:40 +0300 Subject: [whatwg] Input type for phone numbers In-Reply-To: <60321AFF-00BC-45A3-B5E2-CC8D0FEE4095@iki.fi> References: <49D234E0.9010503@mit.edu> <49D24543.9040708@gmx.ch> <49D24CA0.3010704@opera.com> <49D25146.9060507@mit.edu> <60321AFF-00BC-45A3-B5E2-CC8D0FEE4095@iki.fi> Message-ID: <26b395e60904010531t716b105am3c08189e18b52e30@mail.gmail.com> Boris Zbarsky wrote: > I agree that entering a week is pretty rare, though. ?;) Henri Sivonen wrote: > Is this observation based on observing U.S. sites? At work, we only enter weeks into our Bugzilla. Even our time tracking system didn't ask us to enter weeks (you have to fill in a spreadsheet of html cells, but you view them a week at a time, and generally navigate 'next week', 'previous week', 'bang mouse repeatedly until you get close to the right week'. I'd rather delete weeks from our process but the process process manager managers manage to add weekly process management things weekly. In no other portion of my web app experience at my current European employer must i suffer from week entry. And in the case of Bugzilla, it's utterly useless because you spend so much time processing that you don't actually make the weekly deadline and therefore have to process change request to change the week to 5 later. > type=week is meant for European business use. (It doesn't even support U.S. > week numbers.) > Being in Europe, I'm not convinced that week needs to be supported as an > input, though. When I see week numbers used, it tends to involve output > instead input, but I don't use European business scheduling apps. Being in Europe, I'm uncertain... If someone actually were to make it so that an American could actually use the web app because they could figure out what the heck it was talking about (the numbers are utterly meaningless), then I suppose that my browser could explain the app to me by showing me a calendar with real dates would be valuable. Given that there are 3 or more week numbering rules, I'd expect this feature to fail often. The apps I'm working w/ today can't get DST transitions right, and that problem is older.... From michaeln at google.com Wed Apr 1 11:18:50 2009 From: michaeln at google.com (Michael Nordman) Date: Wed, 1 Apr 2009 11:18:50 -0700 Subject: [whatwg] Worker feedback In-Reply-To: References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> Message-ID: I'd like to propose a way forward. Please have an open mind. The objections your hearing from the chrome world are around the locking semantics being proposed. In various discussions the terms "evil", "troubling", and "onerous" have been used to describe what we think about aspects of those semantics. There are obvious difficulties in providing the semantics being discussed in a multi-threaded multi-process browser. There are obvious performance implications. There are limitations imposed on workers that would otherwise not be an issue. And with the introduction of these locks today, there would be challenges going forward when trying to add new features such that deadlocks would not be incurred... our hands would be getting tied up. So we don't like it... evil, troubling, onerous. The objections I'm hearing from the firefox world are around providing an API that is less error prone. I suggest that we can come up with a design that makes both of these camps happy and that should be our goal here. To that end... what if... interface Store { void putItem(string name, string value); string getItem(string name); // calling getItem multiple times prior to script completion with the same name is gauranteed to return the same value // (unless the current script had called putItem, if a different script had called putItem concurrently, the current script wont see that) void transact(func transactCallback); // is not guaranteed to execute if the page is unloaded prior to the lock being acquired // is guaranteed to NOT execute if called from within onunload // but... really... if you need transactional semantics, maybe you should be using a Database? attribute int length; // may only be accessed within a transactCallback, othewise throws an exception string getItemByIndex(int i); // // may only be accessed within a transactCallback, othewise throws an exception }; document.cookie; // has the same safe to read multiple times semantics as store.getItem() So there are no locking semantics (outside of the transact method)... and multiple reads are not error prone. WDYT? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kev at brantaero.com Wed Apr 1 12:00:23 2009 From: kev at brantaero.com (Kevin Field) Date: Wed, 01 Apr 2009 15:00:23 -0400 EDT Subject: [whatwg] DOM-related and API-related feedback Message-ID: <25199700630-BeMail@Kev> On Sun Dec 28 03:38:07 PST 2008, Ian Hickson wrote: > > On Sun, 8 Jun 2008, Ojan Vafai wrote: > > > > I can speak to the first (getNextFocusableElement). One case I have > > hit > > where this would be useful is a designMode iframe (in this case a > > rich-text editor). I wanted tab to go to the next focusable > > element, > > which was a different element depending on the context the editor > > is > > embedded in. There's currently no way to do that. > > It seems like this is something that should be left up to the user > agent. > After all, how is the Web page to know which key binding moves the > focus > normally anyway? > > If we were to provide this it seems what we'd have to do is provide > an API > that actually moves the focus (e.g. provide a focusNextElement() > method > and a focusPreviousElemnt() method), since the next focusable item > might > not even have a DOM node (e.g. the location bar) or it might be in > another > origin. But then what if the user agent doesn't do things using a > cycle > but instead uses directional focus management, like many phones? I'm currently working on a UI that I intend to be fully usable via keyboard or mouse. When an element is given focus, a mouse-usable UI is generated, but the focused element also accepts keystrokes. It appears to be currently very difficult to have the element give its focus over to the next available focusable element when the user clicks something in the mouse-usable UI. So I'm not replacing tab or whatever the keybinding might be, but I do want a click in one area to be followed by a simulated tab (or equivalent) keypress. This is an important use case for me. I propose extending the blur() function to act like history.go(): element.blur(-1) would act like element.focus() plus a shift + tab (or equivalent) keypress, and element.blur(1) would act like element.focus() plus a tab (or equivalent) keypress. Your final question made me stop and think, but in the end, "6.5.1 Sequential focus navigation" and the tabindex attribute already exist. This should still work. Developers targeting phone platforms would simply not make use of this function, and in any case, phone users would still have their directional focus management available unless the developer was malicious, in which case she or he could just abuse element.focus() or other existant technologies as-is. ( A less professional rant on this is available here for context: http://kevinjamesfield.blogspot.com/2009/04/manual-focus-management-woes.html woes.html ) From jonas at sicking.cc Wed Apr 1 14:41:28 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Wed, 1 Apr 2009 14:41:28 -0700 Subject: [whatwg] Notifications UI for Persistent Workers In-Reply-To: <5ce7a0db0903311848j36f8d6beu8f5387c893b76101@mail.gmail.com> References: <5ce7a0db0903311848j36f8d6beu8f5387c893b76101@mail.gmail.com> Message-ID: <63df84f0904011441m6acafba4ueeb39c5ad2352011@mail.gmail.com> On Tue, Mar 31, 2009 at 6:48 PM, John Gregg wrote: > interface Notifications { > ?NotificationObject createHTMLNotification(URL url); > ?NotificationObject createNotification(StructuredNotification n); > > ?/* see "Permissions" below */ > ?readonly attribute boolean trusted; > ?void requestTrust(); > }; > > In the Notifications interface, user agents may leave undefined > createHTMLNotification() if they do not support HTML notifications. > > [nointerface] interface StructuredNotification { > ?DOMString title; > ?DOMString /* URL */ icon; > ?DOMString body; > ?/* ... perhaps other fields can be optional ... */ > }; I would avoid creating a new object for displaying stuff. We have HTML which hopefully should be powerful enough ;) Instead maybe add an API for creating a notification based on a html string, or a node. Also, I assume that these are different toasters from whatever UI is used to ask for permission to install a persistent worker? You definitely don't want to allow rich content in those. / Jonas From robert at ocallahan.org Wed Apr 1 15:02:14 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 2 Apr 2009 11:02:14 +1300 Subject: [whatwg] Worker feedback In-Reply-To: References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> Message-ID: <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> On Thu, Apr 2, 2009 at 7:18 AM, Michael Nordman wrote: > I suggest that we can come up with a design that makes both of these camps > happy and that should be our goal here. > To that end... what if... > > interface Store { > void putItem(string name, string value); > > string getItem(string name); > // calling getItem multiple times prior to script completion with the > same name is gauranteed to return the same value > // (unless the current script had called putItem, if a different script > had called putItem concurrently, the current script wont see that) > > void transact(func transactCallback); > // is not guaranteed to execute if the page is unloaded prior to the lock > being acquired > // is guaranteed to NOT execute if called from within onunload > // but... really... if you need transactional semantics, maybe you should > be using a Database? > > attribute int length; > // may only be accessed within a transactCallback, othewise throws an > exception > > string getItemByIndex(int i); > // // may only be accessed within a transactCallback, othewise throws an > exception > }; > > > document.cookie; > // has the same safe to read multiple times semantics as store.getItem() > > > So there are no locking semantics (outside of the transact method)... and > multiple reads are not error prone. > > WDYT? > getItem stability is helpful for read-only scripts but no help for read-write scripts. For example, outside a transaction, two scripts doing putItem('x', getItem('x') + 1) can race and lose an increment. Even for read-only scripts, you have the problem that reading multiple values isn't guaranteed to give you a consistent state. So this isn't much better than doing nothing for the default case. (Note that you can provide hen read-only scripts are easy to optimize for full parallelism using ) Forcing iteration to be inside a transaction isn't compatible with existing localStorage either. Addressing the larger context ... More than anything else, I'm channeling my experiences at IBM Research writing race detection tools for Java programs ( http://portal.acm.org/citation.cfm?id=781528 and others), and what I learned there about programmers with a range of skill levels grappling with shared memory (or in our case, shared storage) concurrency. I passionately, violently believe that Web programmers cannot and should not have to deal with it. It's simply a matter of implementing what programmers expect: that by default, a chunk of sequential code will do what it says without (occasional, random) interference from outside. I realize that this creates major implementation difficulties for parallel browsers, which I believe will be all browsers. "Evil', "troubling" and "onerous" are perhaps understatements... But it will be far better in the long run to put those burdens on browser developers than to kick them upstairs to Web developers. If it turns out that there is a compelling performance boost that can *only* be achieved by relaxing serializability, then I could be convinced ... but we are very far from proving that. 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Wed Apr 1 15:17:27 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 2 Apr 2009 11:17:27 +1300 Subject: [whatwg] Worker feedback In-Reply-To: <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> Message-ID: <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> On Thu, Apr 2, 2009 at 11:02 AM, Robert O'Callahan wrote: > (Note that you can provide hen read-only scripts are easy to optimize for > full parallelism using ) Oops! I was going to point out that you can use a reader/writer lock to implement serializability while allowing read-only scripts to run in parallel, so if the argument is that most scripts are read-only then that means it shouldn't be hard to get pretty good parallelism. 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at google.com Thu Apr 2 13:00:29 2009 From: jorlow at google.com (Jeremy Orlow) Date: Thu, 2 Apr 2009 13:00:29 -0700 Subject: [whatwg] Worker feedback In-Reply-To: <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> Message-ID: <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> On Wed, Apr 1, 2009 at 3:17 PM, Robert O'Callahan wrote: > On Thu, Apr 2, 2009 at 11:02 AM, Robert O'Callahan wrote: > >> (Note that you can provide hen read-only scripts are easy to optimize for >> full parallelism using ) > > > Oops! > > I was going to point out that you can use a reader/writer lock to implement > serializability while allowing read-only scripts to run in parallel, so if > the argument is that most scripts are read-only then that means it shouldn't > be hard to get pretty good parallelism. The problem is escalating the lock. If your script does a read and then a write, and you do this in 2 workers/windows/etc you can get a deadlock unless you have the ability to roll back one of the two scripts to before the read which took a shared lock. If both scripts have an 'alert("hi!");' then you're totally screwed, though. There's been a LOT of CS research done on automatically handling the details of concurrency. The problem has to become pretty constrained (especially in terms of stuff you can't roll back, like user input) before you can create something halfway efficient. On Wed, Apr 1, 2009 at 3:02 PM, Robert O'Callahan wrote: > On Thu, Apr 2, 2009 at 7:18 AM, Michael Nordman > wrote: > >> I suggest that we can come up with a design that makes both of these camps >> happy and that should be our goal here. >> To that end... what if... >> >> interface Store { >> void putItem(string name, string value); >> >> string getItem(string name); >> // calling getItem multiple times prior to script completion with the >> same name is gauranteed to return the same value >> // (unless the current script had called putItem, if a different script >> had called putItem concurrently, the current script wont see that) >> >> void transact(func transactCallback); >> // is not guaranteed to execute if the page is unloaded prior to the >> lock being acquired >> // is guaranteed to NOT execute if called from within onunload >> // but... really... if you need transactional semantics, maybe you >> should be using a Database? >> >> attribute int length; >> // may only be accessed within a transactCallback, othewise throws an >> exception >> >> string getItemByIndex(int i); >> // // may only be accessed within a transactCallback, othewise throws an >> exception >> }; >> > >> >> document.cookie; >> // has the same safe to read multiple times semantics as store.getItem() >> >> >> So there are no locking semantics (outside of the transact method)... and >> multiple reads are not error prone. >> >> WDYT? >> > > getItem stability is helpful for read-only scripts but no help for > read-write scripts. For example, outside a transaction, two scripts doing > putItem('x', getItem('x') + 1) can race and lose an increment. > Totally agree that it doesn't quite work yet. But what if setItem were to watch for unserializable behavior and throw a transactCallback when it happens? This solves the silent data corruption problem, though reproducing the circumstances that'd cause this are obviously racy. Of course, reproducing the deadlocks or very slow script execution behavior is also racy. > Addressing the larger context ... More than anything else, I'm channeling > my experiences at IBM Research writing race detection tools for Java > programs ( http://portal.acm.org/citation.cfm?id=781528 and others), and > what I learned there about programmers with a range of skill levels > grappling with shared memory (or in our case, shared storage) concurrency. I > passionately, violently believe that Web programmers cannot and should not > have to deal with it. It's simply a matter of implementing what programmers > expect: that by default, a chunk of sequential code will do what it says > without (occasional, random) interference from outside. > I definitely see pro's and cons to providing a single threaded version of the world to all developers (both advanced and beginner), but this really isn't what we should be debating right now. What we should be debating is whether advanced, cross-event-loop APIs should be kept simple enough that any beginner web developer can use it (at the expense of performance and simplicity within the browser) or if we should be finding a compromise that can be kept fast, simple (causing less bugs!), and somewhat harder to program for. If someone wants to cross the event loop (except in the document.cookie case, which is a pretty special one), they should have to deal with more complexity in some form. Personally, I'd like to see a solution that does not involve locks of any sort (software transactional memory?). > I realize that this creates major implementation difficulties for parallel > browsers, which I believe will be all browsers. "Evil', "troubling" and > "onerous" are perhaps understatements... But it will be far better in the > long run to put those burdens on browser developers than to kick them > upstairs to Web developers. If it turns out that there is a compelling > performance boost that can *only* be achieved by relaxing serializability, > then I could be convinced ... but we are very far from proving that. > Like I said, a LOT of research has been done on concurrency. Basically, if you're not really careful about how you construct your language and the abstractions you have for concurrency, you can really easily back yourself into a corner that you semantically can't get out of (no matter how good of a programmer you are). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at google.com Thu Apr 2 13:02:59 2009 From: jorlow at google.com (Jeremy Orlow) Date: Thu, 2 Apr 2009 13:02:59 -0700 Subject: [whatwg] Worker feedback In-Reply-To: References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> Message-ID: <5dd9e5c50904021302j1b9b3cbw29207da66904a2a3@mail.gmail.com> On Tue, Mar 31, 2009 at 9:57 PM, Drew Wilson wrote: > > On Tue, Mar 31, 2009 at 6:25 PM, Robert O'Callahan wrote: >> >> We don't know how much (if any) performance must be sacrificed, because >> no-one's tried to implement parallel cookie access with serializability >> guarantees. So I don't think we can say what the correct tradeoff is. >> > > The spec as proposed states that script that accesses cookies cannot > operate in parallel with network access on those same domains. The > performance impact of something like this is pretty clear, IMO - we don't > need to implement it and measure it to know it exists and in some situations > could be significant. > I agree with everything Drew said, but I think think this one point really needs to be singled out. Cookies go across the wire. Serializable semantics are not possible in todays (latent) world. Period. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Thu Apr 2 16:01:42 2009 From: ian at hixie.ch (Ian Hickson) Date: Thu, 2 Apr 2009 23:01:42 +0000 (UTC) Subject: [whatwg] Help us review HTML5! Message-ID: 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%20bugs&priority=P3&product=HTML%20WG&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. `._.-(,_..'--(,_..'`-.;.' From alexbishop at gmail.com Thu Apr 2 17:30:08 2009 From: alexbishop at gmail.com (Alex Bishop) Date: Fri, 03 Apr 2009 01:30:08 +0100 Subject: [whatwg] Language codes: RFC 3066 versus RFC 4646 Message-ID: <49D55890.2080104@gmail.com> In several places in HTML5 (specifically, sections 3.3.3.3, 4.2.5.3 and 5.11.1), the specification states that certain attribute values must be valid RFC 3066 language codes. However, RFC 3066 was replaced by RFC 4646 (and RFC 4647) in September 2006. Is there a reason that HTML5 refers to the older standard or is this just an oversight? Alex -- Alex Bishop alexbishop at gmail.com From myakura.web at gmail.com Thu Apr 2 18:03:04 2009 From: myakura.web at gmail.com (Masataka Yakura) Date: Fri, 3 Apr 2009 10:03:04 +0900 Subject: [whatwg] Language codes: RFC 3066 versus RFC 4646 In-Reply-To: <49D55890.2080104@gmail.com> References: <49D55890.2080104@gmail.com> Message-ID: <827d89250904021803r58db0e7n55c550f02c9b789e@mail.gmail.com> I think the current plan is to point to BCP 47, since RFC 4646 is "soon" to be replaced by its successor [1]. [1] http://lists.w3.org/Archives/Public/public-html/2008Jan/0298.html On Fri, Apr 3, 2009 at 9:30 AM, Alex Bishop wrote: > In several places in HTML5 (specifically, sections 3.3.3.3, 4.2.5.3 and > 5.11.1), the specification states that certain attribute values must be > valid RFC 3066 language codes. > > However, RFC 3066 was replaced by RFC 4646 (and RFC 4647) in September 2006. > > Is there a reason that HTML5 refers to the older standard or is this just an > oversight? -- Masataka Yakura From mike at w3.org Thu Apr 2 18:13:14 2009 From: mike at w3.org (Michael(tm) Smith) Date: Fri, 3 Apr 2009 10:13:14 +0900 Subject: [whatwg] Language codes: RFC 3066 versus RFC 4646 In-Reply-To: <827d89250904021803r58db0e7n55c550f02c9b789e@mail.gmail.com> References: <49D55890.2080104@gmail.com> <827d89250904021803r58db0e7n55c550f02c9b789e@mail.gmail.com> Message-ID: <20090403011313.GC19889@sideshowbarker> Masataka Yakura , 2009-04-03 10:03 +0900: > I think the current plan is to point to BCP 47, since RFC 4646 is > "soon" to be replaced by its successor [1]. > > [1] http://lists.w3.org/Archives/Public/public-html/2008Jan/0298.html And the general plan is to at some point(s) (e.g., before taking the W3C version to Last call) do a thorough review and update of all the references/citations to whatever the current versions are that they should point to at that time. It's maybe not all that useful to try to keep them up to date piecemeal along the way. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ From robert at ocallahan.org Thu Apr 2 18:37:49 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 3 Apr 2009 14:37:49 +1300 Subject: [whatwg] Worker feedback In-Reply-To: <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> Message-ID: <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> On Fri, Apr 3, 2009 at 9:00 AM, Jeremy Orlow wrote: > The problem is escalating the lock. If your script does a read and then a > write, and you do this in 2 workers/windows/etc you can get a deadlock > unless you have the ability to roll back one of the two scripts to before > the read which took a shared lock. If both scripts have an 'alert("hi!");' > then you're totally screwed, though. > Double oops! Yes. On Wed, Apr 1, 2009 at 3:02 PM, Robert O'Callahan > wrote: > >> getItem stability is helpful for read-only scripts but no help for >> read-write scripts. For example, outside a transaction, two scripts doing >> putItem('x', getItem('x') + 1) can race and lose an increment. >> > > Totally agree that it doesn't quite work yet. > > But what if setItem were to watch for unserializable behavior and throw a > transactCallback when it happens? This solves the silent data corruption > problem, though reproducing the circumstances that'd cause this are > obviously racy. Of course, reproducing the deadlocks or very slow script > execution behavior is also racy. > You mean throw an exception when it happens? Yeah, that doesn't really help, you just replace one kind of random failure with another. A half-completed read-write script is very likely to have corrupted data. > >> Addressing the larger context ... More than anything else, I'm channeling >> my experiences at IBM Research writing race detection tools for Java >> programs ( http://portal.acm.org/citation.cfm?id=781528 and others), and >> what I learned there about programmers with a range of skill levels >> grappling with shared memory (or in our case, shared storage) concurrency. I >> passionately, violently believe that Web programmers cannot and should not >> have to deal with it. It's simply a matter of implementing what programmers >> expect: that by default, a chunk of sequential code will do what it says >> without (occasional, random) interference from outside. >> > > I definitely see pro's and cons to providing a single threaded version of > the world to all developers (both advanced and beginner), but this really > isn't what we should be debating right now. > Why not? I know of no better forum for debating the semantics of the Web platform, and it's clearly a matter of some urgency. What we should be debating is whether advanced, cross-event-loop APIs should > be kept simple enough that any beginner web developer can use it (at the > expense of performance and simplicity within the browser) or if we should be > finding a compromise that can be kept fast, simple (causing less bugs!), and > somewhat harder to program for. > > If someone wants to cross the event loop (except in the document.cookie > case, which is a pretty special one), they should have to deal with more > complexity in some form. Personally, I'd like to see a solution that does > not involve locks of any sort (software transactional memory?). > 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. That is entirely consistent with what I said above; I'm not saying all concurrency abstractions are intractable. But the "abstraction" which takes sequential code and adds races on shared storage everywhere certainly is. Unfortunately we have to deal with cookies and localStorage, where the API is already set. > >> I realize that this creates major implementation difficulties for parallel >> browsers, which I believe will be all browsers. "Evil', "troubling" and >> "onerous" are perhaps understatements... But it will be far better in the >> long run to put those burdens on browser developers than to kick them >> upstairs to Web developers. If it turns out that there is a compelling >> performance boost that can *only* be achieved by relaxing serializability, >> then I could be convinced ... but we are very far from proving that. >> > > Like I said, a LOT of research has been done on concurrency. Basically, if > you're not really careful about how you construct your language and the > abstractions you have for concurrency, you can really easily back yourself > into a corner that you semantically can't get out of (no matter how good of > a programmer you are). > I know this, but I'm not sure exactly what point you're trying to make. 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Thu Apr 2 18:45:52 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 3 Apr 2009 14:45:52 +1300 Subject: [whatwg] Worker feedback In-Reply-To: <5dd9e5c50904021302j1b9b3cbw29207da66904a2a3@mail.gmail.com> References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <5dd9e5c50904021302j1b9b3cbw29207da66904a2a3@mail.gmail.com> Message-ID: <11e306600904021845o5847beecm4b389fe9a6258360@mail.gmail.com> On Fri, Apr 3, 2009 at 9:02 AM, Jeremy Orlow wrote: > I agree with everything Drew said, but I think think this one point really > needs to be singled out. Cookies go across the wire. Serializable > semantics are not possible in todays (latent) world. Period. > The unit of serializability is a single script (typically an event handler) running to completion. There's no problem interleaving network cookie reads and writes with those. 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Thu Apr 2 18:45:56 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 3 Apr 2009 14:45:56 +1300 Subject: [whatwg] Worker feedback In-Reply-To: <5dd9e5c50904021302j1b9b3cbw29207da66904a2a3@mail.gmail.com> References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <5dd9e5c50904021302j1b9b3cbw29207da66904a2a3@mail.gmail.com> Message-ID: <11e306600904021845h79c3ad6ax36ed3700634e1237@mail.gmail.com> On Fri, Apr 3, 2009 at 9:02 AM, Jeremy Orlow wrote: > I agree with everything Drew said, but I think think this one point really > needs to be singled out. Cookies go across the wire. Serializable > semantics are not possible in todays (latent) world. Period. > The unit of serializability is a single script (typically an event handler) running to completion. There's no problem interleaving network cookie reads and writes with those. 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at google.com Thu Apr 2 21:11:59 2009 From: jorlow at google.com (Jeremy Orlow) Date: Thu, 2 Apr 2009 21:11:59 -0700 Subject: [whatwg] Worker feedback In-Reply-To: <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> Message-ID: <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> On Thu, Apr 2, 2009 at 6:37 PM, Robert O'Callahan wrote: > > Unfortunately we have to deal with cookies and localStorage, where the API > is already set. > Is it "set"? I understand that localStorage has been around for a while, but as far as I can tell virtually no one uses it. I thought the reason for calling this spec a draft was so that such fairly major issues could be corrected? I agree that changing something this late in the game is less than ideal, but I think we're both agreeing that any synchronous APIs that cross the event-loop are going to be long term problems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at corry.biz Thu Apr 2 21:15:14 2009 From: bil at corry.biz (Bil Corry) Date: Thu, 02 Apr 2009 23:15:14 -0500 Subject: [whatwg] XXX-Origin header Message-ID: <49D58D52.3060705@corry.biz> Since the public-webapps list was never able to reconcile[1] HTML5's Origin header (now renamed XXX-Origin[2]) with CORS's Origin header[3], we're left with two headers with similar implementations and similar names. Due to this, it may prudent to rename XXX-Origin to something without "Origin" in the name to better distinguish between the two. I don't know what the header should be renamed to ("Source"?), but no matter which name is chosen for the header, it should be listed as a prohibited header for XHR.setRequestHeader()[4]. - Bil [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0057.html [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step [3] http://www.w3.org/TR/cors/#origin-header [4] http://www.w3.org/TR/XMLHttpRequest2/#author-request-headers From bil at corry.biz Thu Apr 2 21:21:54 2009 From: bil at corry.biz (Bil Corry) Date: Thu, 02 Apr 2009 23:21:54 -0500 Subject: [whatwg] XXX-Origin header In-Reply-To: <49D58D52.3060705@corry.biz> References: <49D58D52.3060705@corry.biz> Message-ID: <49D58EE2.2010608@corry.biz> Related, HTML5 currently prohibits sending the XXX-Origin header for GET requests. This is to prevent intranet applications leaking their internal hostnames to external sites (are there other reasons?). However, there is value in a site being able to determine that a request originated from itself, so to that end, I'd like to request that HTML5 specify that the XXX-Origin header should be sent for any same-origin GET requests. This would still avoid leaking intranet hostnames while allowing a site to verify that a request came from itself. - Bil From robert at ocallahan.org Thu Apr 2 21:26:43 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 3 Apr 2009 17:26:43 +1300 Subject: [whatwg] Worker feedback In-Reply-To: <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> References: <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> Message-ID: <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> On Fri, Apr 3, 2009 at 5:11 PM, Jeremy Orlow wrote: > On Thu, Apr 2, 2009 at 6:37 PM, Robert O'Callahan wrote: > >> >> Unfortunately we have to deal with cookies and localStorage, where the API >> is already set. >> > > Is it "set"? > > I understand that localStorage has been around for a while, but as far as I > can tell virtually no one uses it. I thought the reason for calling this > spec a draft was so that such fairly major issues could be corrected? I > agree that changing something this late in the game is less than ideal, but > I think we're both agreeing that any synchronous APIs that cross the > event-loop are going to be long term problems. > AFAIK every major browser has an implementation of localStorage close to shipping. The only way I can imagine having a chance to put the brakes on the feature now is for everyone who hasn't actually shipped it --- which I think is currently everyone but IE, since we shipped the old "globalStorage" which we're planning to rip out anyway --- to unite and disable it immediately until we have a better API. Maybe we could even get IE to disable it in an update. Mozilla could probably get behind that, but I don't know who else is willing to bite the bullet. I suppose "sessionStorage" can stay? 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Thu Apr 2 21:33:23 2009 From: ian at hixie.ch (Ian Hickson) Date: Fri, 3 Apr 2009 04:33:23 +0000 (UTC) Subject: [whatwg] XXX-Origin header In-Reply-To: <49D58D52.3060705@corry.biz> References: <49D58D52.3060705@corry.biz> Message-ID: On Thu, 2 Apr 2009, Bil Corry wrote: > > Since the public-webapps list was never able to reconcile[1] HTML5's > Origin header (now renamed XXX-Origin[2]) with CORS's Origin header[3], > we're left with two headers with similar implementations and similar > names. The name "XXX-Origin" is a temporary name (I use "XXX" to mark known issues); I'm waiting for the discussion in the HTTP working group to settle so that I can fix it. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bil at corry.biz Thu Apr 2 21:44:29 2009 From: bil at corry.biz (Bil Corry) Date: Thu, 02 Apr 2009 23:44:29 -0500 Subject: [whatwg] XXX-Origin header In-Reply-To: References: <49D58D52.3060705@corry.biz> Message-ID: <49D5942D.800@corry.biz> Ian Hickson wrote on 4/2/2009 11:33 PM: > On Thu, 2 Apr 2009, Bil Corry wrote: >> Since the public-webapps list was never able to reconcile[1] HTML5's >> Origin header (now renamed XXX-Origin[2]) with CORS's Origin header[3], >> we're left with two headers with similar implementations and similar >> names. > > The name "XXX-Origin" is a temporary name (I use "XXX" to mark known > issues); I'm waiting for the discussion in the HTTP working group to > settle so that I can fix it. Ok, I'll pick it up over there then, thanks. - Bil From julian.reschke at gmx.de Thu Apr 2 22:52:41 2009 From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 03 Apr 2009 07:52:41 +0200 Subject: [whatwg] Language codes: RFC 3066 versus RFC 4646 In-Reply-To: <20090403011313.GC19889@sideshowbarker> References: <49D55890.2080104@gmail.com> <827d89250904021803r58db0e7n55c550f02c9b789e@mail.gmail.com> <20090403011313.GC19889@sideshowbarker> Message-ID: <49D5A429.3050006@gmx.de> Michael(tm) Smith wrote: > Masataka Yakura , 2009-04-03 10:03 +0900: > >> I think the current plan is to point to BCP 47, since RFC 4646 is >> "soon" to be replaced by its successor [1]. >> >> [1] http://lists.w3.org/Archives/Public/public-html/2008Jan/0298.html > > And the general plan is to at some point(s) (e.g., before taking > the W3C version to Last call) do a thorough review and update of > all the references/citations to whatever the current versions are > that they should point to at that time. It's maybe not all that > useful to try to keep them up to date piecemeal along the way. But maybe it is. Checking references earlier catches problems earlier. BR, Julian From ian at hixie.ch Fri Apr 3 00:54:11 2009 From: ian at hixie.ch (Ian Hickson) Date: Fri, 3 Apr 2009 07:54:11 +0000 (UTC) Subject: [whatwg] Language codes: RFC 3066 versus RFC 4646 In-Reply-To: <49D5A429.3050006@gmx.de> References: <49D55890.2080104@gmail.com> <827d89250904021803r58db0e7n55c550f02c9b789e@mail.gmail.com> <20090403011313.GC19889@sideshowbarker> <49D5A429.3050006@gmx.de> Message-ID: 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. `._.-(,_..'--(,_..'`-.;.' From sunberg at gmail.com Fri Apr 3 01:18:46 2009 From: sunberg at gmail.com (Lars) Date: Fri, 3 Apr 2009 10:18:46 +0200 Subject: [whatwg] Help us review HTML5! In-Reply-To: References: Message-ID: <8f2fc6f50904030118p5f4756een1f11aceab8a00fc1@mail.gmail.com> Hi Havent read it all yet, but I did a search, and found nothing about the 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 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%20bugs&priority=P3&product=HTML%20WG&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. ? `._.-(,_..'--(,_..'`-.;.' > From annevk at opera.com Fri Apr 3 02:18:43 2009 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 03 Apr 2009 11:18:43 +0200 Subject: [whatwg] Worker feedback In-Reply-To: <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> References: <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> Message-ID: On Fri, 03 Apr 2009 06:26:43 +0200, Robert O'Callahan 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/ From adeveria at gmail.com Fri Apr 3 05:47:59 2009 From: adeveria at gmail.com (Alexis Deveria) Date: Fri, 3 Apr 2009 08:47:59 -0400 Subject: [whatwg] HTML5 review: typo found Message-ID: <5e5974a0904030547r18d1e26fh7db8b97a30921383@mail.gmail.com> 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 From jorlow at google.com Fri Apr 3 10:35:26 2009 From: jorlow at google.com (Jeremy Orlow) Date: Fri, 3 Apr 2009 10:35:26 -0700 Subject: [whatwg] Worker feedback In-Reply-To: References: <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> Message-ID: <5dd9e5c50904031035x4b95b0ds456944e9451936c8@mail.gmail.com> On Fri, Apr 3, 2009 at 2:18 AM, Anne van Kesteren wrote: > On Fri, 03 Apr 2009 06:26:43 +0200, Robert O'Callahan < > robert at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jackalmage at gmail.com Fri Apr 3 11:44:55 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Fri, 3 Apr 2009 13:44:55 -0500 Subject: [whatwg] Worker feedback In-Reply-To: <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> References: <11e306600903301845g12c14687j4ec8359ca66c4f74@mail.gmail.com> <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> Message-ID: On Thu, Apr 2, 2009 at 8:37 PM, Robert O'Callahan 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 From ojan at chromium.org Fri Apr 3 13:20:20 2009 From: ojan at chromium.org (Ojan Vafai) Date: Fri, 3 Apr 2009 13:20:20 -0700 Subject: [whatwg] cross-domain scrollIntoView on frames and iframes Message-ID: <78dc8440904031320nc185002m8f90a2146af925e4@mail.gmail.com> 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 #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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From atwilson at google.com Fri Apr 3 14:25:54 2009 From: atwilson at google.com (Drew Wilson) Date: Fri, 3 Apr 2009 14:25:54 -0700 Subject: [whatwg] Worker feedback In-Reply-To: References: <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> Message-ID: 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. wrote: > On Thu, Apr 2, 2009 at 8:37 PM, Robert O'Callahan > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at google.com Fri Apr 3 14:33:12 2009 From: jorlow at google.com (Jeremy Orlow) Date: Fri, 3 Apr 2009 14:33:12 -0700 Subject: [whatwg] Worker feedback In-Reply-To: References: <11e306600903311825n2444afd2pe2770a93f0273fc@mail.gmail.com> <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> Message-ID: <5dd9e5c50904031433o75ebd61an1e5975a50158d2a0@mail.gmail.com> On Fri, Apr 3, 2009 at 2:25 PM, Drew Wilson 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. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Fri Apr 3 14:49:47 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 4 Apr 2009 10:49:47 +1300 Subject: [whatwg] Worker feedback In-Reply-To: <5dd9e5c50904031035x4b95b0ds456944e9451936c8@mail.gmail.com> References: <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> <5dd9e5c50904031035x4b95b0ds456944e9451936c8@mail.gmail.com> Message-ID: <11e306600904031449xb7a425apd0d9c1a7909d4ea4@mail.gmail.com> On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at google.com Fri Apr 3 14:53:27 2009 From: jorlow at google.com (Jeremy Orlow) Date: Fri, 3 Apr 2009 14:53:27 -0700 Subject: [whatwg] How long should sessionStorage data persist? Message-ID: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Fri Apr 3 15:16:24 2009 From: ian at hixie.ch (Ian Hickson) Date: Fri, 3 Apr 2009 22:16:24 +0000 (UTC) Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> Message-ID: 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. `._.-(,_..'--(,_..'`-.;.' From jorlow at google.com Fri Apr 3 15:17:32 2009 From: jorlow at google.com (Jeremy Orlow) Date: Fri, 3 Apr 2009 15:17:32 -0700 Subject: [whatwg] Worker feedback In-Reply-To: <11e306600904031449xb7a425apd0d9c1a7909d4ea4@mail.gmail.com> References: <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> <5dd9e5c50904031035x4b95b0ds456944e9451936c8@mail.gmail.com> <11e306600904031449xb7a425apd0d9c1a7909d4ea4@mail.gmail.com> Message-ID: <5dd9e5c50904031517x30a462c5g78035091afe6a4e0@mail.gmail.com> On Fri, Apr 3, 2009 at 2:49 PM, Robert O'Callahan wrote: > On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow 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. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at google.com Fri Apr 3 15:25:48 2009 From: jorlow at google.com (Jeremy Orlow) Date: Fri, 3 Apr 2009 15:25:48 -0700 Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> Message-ID: <5dd9e5c50904031525s57ee92dbw979793eedab3a06e@mail.gmail.com> On Fri, Apr 3, 2009 at 3:16 PM, Ian Hickson 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! -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin at chromium.org Fri Apr 3 17:03:17 2009 From: darin at chromium.org (Darin Fisher) Date: Fri, 3 Apr 2009 17:03:17 -0700 Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> Message-ID: On Fri, Apr 3, 2009 at 3:16 PM, Ian Hickson 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at google.com Fri Apr 3 17:07:45 2009 From: jorlow at google.com (Jeremy Orlow) Date: Fri, 3 Apr 2009 17:07:45 -0700 Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> Message-ID: <5dd9e5c50904031707i6168e725s7110b8f4aa201117@mail.gmail.com> On Fri, Apr 3, 2009 at 5:03 PM, Darin Fisher 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Fri Apr 3 17:29:39 2009 From: ian at hixie.ch (Ian Hickson) Date: Sat, 4 Apr 2009 00:29:39 +0000 (UTC) Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> Message-ID: 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. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Fri Apr 3 18:23:02 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Fri, 03 Apr 2009 21:23:02 -0400 Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> Message-ID: <49D6B676.2020800@mit.edu> 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 From ian at hixie.ch Fri Apr 3 18:46:59 2009 From: ian at hixie.ch (Ian Hickson) Date: Sat, 4 Apr 2009 01:46:59 +0000 (UTC) Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: <49D6B676.2020800@mit.edu> References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> <49D6B676.2020800@mit.edu> Message-ID: 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. `._.-(,_..'--(,_..'`-.;.' From jorlow at google.com Fri Apr 3 19:52:44 2009 From: jorlow at google.com (Jeremy Orlow) Date: Fri, 3 Apr 2009 19:52:44 -0700 Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> <49D6B676.2020800@mit.edu> Message-ID: <5dd9e5c50904031952u70d049cbge55261d3c434e3ea@mail.gmail.com> 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 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. `._.-(,_..'--(,_..'`-.;.' > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzbarsky at MIT.EDU Fri Apr 3 19:57:38 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Fri, 03 Apr 2009 22:57:38 -0400 Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> <49D6B676.2020800@mit.edu> Message-ID: <49D6CCA2.4010804@mit.edu> 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 From cam at mcc.id.au Fri Apr 3 22:46:01 2009 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 4 Apr 2009 16:46:01 +1100 Subject: [whatwg] cross-domain scrollIntoView on frames and iframes In-Reply-To: <78dc8440904031320nc185002m8f90a2146af925e4@mail.gmail.com> References: <78dc8440904031320nc185002m8f90a2146af925e4@mail.gmail.com> Message-ID: <20090404054600.GA19924@arc.mcc.id.au> 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/ From innovimax+whatwg at gmail.com Fri Apr 3 23:17:55 2009 From: innovimax+whatwg at gmail.com (Innovimax SARL) Date: Sat, 4 Apr 2009 08:17:55 +0200 Subject: [whatwg] Fwd: HTML 5 remarks on typo In-Reply-To: <546c6c1c0904030037q25dbef72r9a606ba8e2142852@mail.gmail.com> References: <546c6c1c0904030037q25dbef72r9a606ba8e2142852@mail.gmail.com> Message-ID: <546c6c1c0904032317x786cb6bau181091dbdc7202d8@mail.gmail.com> ---------- Forwarded message ---------- From: Innovimax SARL Date: Fri, Apr 3, 2009 at 9:37 AM Subject: Re: HTML 5 remarks on typo To: whatwg at whatwg.org Dear Here are some updated comments : good job most of the typo are now out == Some css properties are emphasized and other not == In 3.3.3.5. The dir attribute [[ CSS 'direction' and 'unicode-bidi' properties ]] are not emphasized as in 4.6.21 The bdo element [[ requirements by implementing the CSS unicode-bidi property. [CSS21] ]] == Choose between == initialize and initialise (DONE) absence and absense (DONE) authorize and authorise (DONE) behaviour and behavior (still one ) code point and codepoint (a lot of this one) invokation and invocation (DONE) > You used en version for > Localisation (with an S) (DONE) == Typo == s/appplies/applies/ (DONE) s/attribte/attribute/ (DONE) s/attributs/attributes/ (DONE) s/backgound/background/ (DONE) s/betwen/between/ (DONE) s/chacacters/characters/ (DONE) s/chosing/choosing/ (DONE) s/clipbroad/clipboard/ (DONE) s/befor /before / (DONE) s/conjuction/conjunction/ (REMOVED) s/corstructors/constructors/ (DONE) s/declaraing/declaring/ (DONE) s/decsendant/descendant/ (DONE) s/descendent/descendant/ (DONE) s/detais/details/ (DONE) s/ eding/ ending/ (DONE) s/errorneous/erroneous/ (DONE) s/explictly/explicitly/ (DONE) s/inteface/interface/ (DONE) s/musn't/mustn't/ (DONE) s/negotation/negotiation/ (DONE) s/numberic/numeric/ (DONE) s/occured/occurred/ (DONE) s/occurances/occurrences/ (STILL THERE) s/ofsets/offsets/ (DONE) s/ ommited/ omitted/ (DONE) s/particlar/particular/ (DONE) s/perferm/perform/ (DONE) s/preceeded/preceded/ (DONE) s/preceeding/preceding/ (DONE) s/pronounciations/pronunciations/ (DONE) s/asychronously/asynchronously/ (STILL THERE) Mohamed ZERGAOUI -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 ? -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From innovimax+whatwg at gmail.com Fri Apr 3 23:18:44 2009 From: innovimax+whatwg at gmail.com (Innovimax SARL) Date: Sat, 4 Apr 2009 08:18:44 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com> References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com> Message-ID: <546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> ---------- Forwarded message ---------- From: Innovimax SARL Date: Fri, Apr 3, 2009 at 10:27 AM Subject: Remarks on HTML5 (ASCII / Unicode) To: whatwg at whatwg.org In 2.3 Case-sensitivity and string comparison Please replace "Converting a string to uppercase" and "Converting a string to lowercase" by respectively "Converting a string to uppercase ASCII" and "Converting a string to lowercase ASCII" Mohamed ZERGAOUI -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 ? -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From giecrilj at stegny.2a.pl Sat Apr 4 01:06:55 2009 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Sat, 4 Apr 2009 10:06:55 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: <546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com> <546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> Message-ID: I suppose that converting a string to uppercase is an action relevant only to cases where only ASCII character set is allowed in the argument, such as HTML element names. Within this restricted application domain, converting to uppercase has the same effect as converting to uppercase ASCII. IMHO, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From innovimax+whatwg at gmail.com Sat Apr 4 01:29:17 2009 From: innovimax+whatwg at gmail.com (Innovimax SARL) Date: Sat, 4 Apr 2009 10:29:17 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com> <546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> Message-ID: <546c6c1c0904040129l2a32f1cetd07087fa2865338c@mail.gmail.com> Well that could be a good answer indeed Now let's try to dig into the subtilties on Unicode For example what does the spec says about an attribute whose name is data-K (where we have this unicode sequence U+0064 U+0061 U+0074 U+0061 U+002D U+212A ) ? Is it allowed ? If not why ? That's why I think everywhere in the spec, where ASCII is meant, it should be explicit. If not it would clash with a Unicode understanding IMHO Mohamed On Sat, Apr 4, 2009 at 10:06 AM, Kristof Zelechovski wrote: > I suppose that converting a string to uppercase is an action relevant > only to cases where only ASCII character set is allowed in the argument, > such as HTML element names. Within this restricted application domain, > converting to uppercase has the same effect as converting to uppercase > ASCII. > > IMHO, > > Chris > -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From giecrilj at stegny.2a.pl Sat Apr 4 01:54:23 2009 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Sat, 4 Apr 2009 10:54:23 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: <546c6c1c0904040129l2a32f1cetd07087fa2865338c@mail.gmail.com> References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com><546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> <546c6c1c0904040129l2a32f1cetd07087fa2865338c@mail.gmail.com> Message-ID: data-* attributes allow XML name characters and they are converted to lower case in HTML (ASCII, AIUI). BTW, editorial correction for 3.3.3.8 : should be "its name contains no characters in the range" (because an attribute contains its value). Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Sat Apr 4 01:57:07 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 4 Apr 2009 21:57:07 +1300 Subject: [whatwg] Worker feedback In-Reply-To: <5dd9e5c50904031517x30a462c5g78035091afe6a4e0@mail.gmail.com> References: <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> <5dd9e5c50904031035x4b95b0ds456944e9451936c8@mail.gmail.com> <11e306600904031449xb7a425apd0d9c1a7909d4ea4@mail.gmail.com> <5dd9e5c50904031517x30a462c5g78035091afe6a4e0@mail.gmail.com> Message-ID: <11e306600904040157y199cbaa4ue71aee7eb89ed12d@mail.gmail.com> On Sat, Apr 4, 2009 at 11:17 AM, Jeremy Orlow wrote: > 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". > OK, I don't think anyone expects, wants, or has ever had that :-). 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. > It's what the spec says (the spec doesn't say anything about reading cookies when constructing an HTTP request, but that's probably just an oversight) and it's what I expected, so not really a 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. > I hope browser implementors can solve this internally. I think the main thing we have to watch out for in the spec is situations where a script can *synchronously* "entangle" browsing contexts that previously could not interfere with each other (i.e., that a browser could have assigned independent locks). (Setting document.domain might be a problem, for example, although I don't know enough about cookies to be sure.) > >> 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.) > In Gecko we're working on making HTML parsing happen in parallel with other activities (including script execution), and video decoding already does. I can imagine doing all graphics rendering in parallel with other tasks and being parallel internally too. Some aspects of layout can be parallelized internally and overlapped with script execution. Expensive Javascript compiler optimizations can be run in parallel with actual application work. Canvas3D can run GPU programs which are another form of parallelism (OK that's not exactly "multicore parallelism" unless you believe Intel). 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: From innovimax+whatwg at gmail.com Sat Apr 4 02:00:30 2009 From: innovimax+whatwg at gmail.com (Innovimax SARL) Date: Sat, 4 Apr 2009 11:00:30 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com> <546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> <546c6c1c0904040129l2a32f1cetd07087fa2865338c@mail.gmail.com> Message-ID: <546c6c1c0904040200v38d8c58m3da898e31a3a501c@mail.gmail.com> Sorry, I don't see the answer to my question here ! On Sat, Apr 4, 2009 at 10:54 AM, Kristof Zelechovski wrote: > data-* attributes allow XML name characters and they are converted to > lower case in HTML (ASCII, AIUI). > > BTW, editorial correction for 3.3.3.8: > should be ?*its name* contains no characters in the range? (because an > attribute contains its value). > > Chris > -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From giecrilj at stegny.2a.pl Sat Apr 4 02:05:31 2009 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Sat, 4 Apr 2009 11:05:31 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: <546c6c1c0904040200v38d8c58m3da898e31a3a501c@mail.gmail.com> References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com><546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com><546c6c1c0904040129l2a32f1cetd07087fa2865338c@mail.gmail.com> <546c6c1c0904040200v38d8c58m3da898e31a3a501c@mail.gmail.com> Message-ID: An attribute named data-K is allowed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From innovimax+whatwg at gmail.com Sat Apr 4 02:11:41 2009 From: innovimax+whatwg at gmail.com (Innovimax SARL) Date: Sat, 4 Apr 2009 11:11:41 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com> <546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> <546c6c1c0904040129l2a32f1cetd07087fa2865338c@mail.gmail.com> <546c6c1c0904040200v38d8c58m3da898e31a3a501c@mail.gmail.com> Message-ID: <546c6c1c0904040211j44f360flb22ae65af1b05009@mail.gmail.com> Well again it depends if you read the spec with an ASCII point of view or a Unicode point of view If I read carefully the spec, it is explicitly said that [[ 3.3.3.8 Embedding custom non-visible data A custom data attribute is an attribute whose name starts with the string "data-", has at least one character after the hyphen, is XML-compatible, has no namespace, and contains no characters in the range U+0041 .. U+005A (LATIN CAPITAL LETTER A .. LATIN CAPITAL LETTER Z). ]] So This sequence is allowed data-K (where we have this unicode sequence U+0064 U+0061 U+0074 U+0061 U+002D U+212A ) but the following one is NOT data-K (where we have this unicode sequence U+0064 U+0061 U+0074 U+0061 U+002D U+004B ) ? That's why I was asking this question in particular Mohamed On Sat, Apr 4, 2009 at 11:05 AM, Kristof Zelechovski wrote: > An attribute named data-K is allowed. > -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From annevk at opera.com Sat Apr 4 02:43:00 2009 From: annevk at opera.com (Anne van Kesteren) Date: Sat, 04 Apr 2009 11:43:00 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com> <546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> Message-ID: On Sat, 04 Apr 2009 10:06:55 +0200, Kristof Zelechovski wrote: > I suppose that converting a string to uppercase is an action relevant > only to cases where only ASCII character set is allowed in the argument, > such as HTML element names. Within this restricted application domain, > converting to uppercase has the same effect as converting to uppercase > ASCII. That's not true. You can get Unicode characters in HTML element names. (You still want to lowercase only the ASCII characters though.) -- Anne van Kesteren http://annevankesteren.nl/ From giecrilj at stegny.2a.pl Sat Apr 4 03:05:57 2009 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Sat, 4 Apr 2009 12:05:57 +0200 Subject: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode) In-Reply-To: References: <546c6c1c0904030127t79541426sf42b83a458fd5459@mail.gmail.com><546c6c1c0904032318l27f1bde2p9ab21a7458cf8c42@mail.gmail.com> Message-ID: It seems that getting the element name is not covered at all, it is a core interface, so definitions in the HTML specification do not apply. Chris From joaoe at opera.com Sat Apr 4 05:10:54 2009 From: joaoe at opera.com (=?utf-8?Q?Jo=C3=A3o_Eiras?=) Date: Sat, 04 Apr 2009 14:10:54 +0200 Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: <5dd9e5c50904031952u70d049cbge55261d3c434e3ea@mail.gmail.com> References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> <49D6B676.2020800@mit.edu> <5dd9e5c50904031952u70d049cbge55261d3c434e3ea@mail.gmail.com> Message-ID: On , Jeremy Orlow wrote: > 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." Should that restore sessionStorage data ? Aren't you making sessionStorage much more complicated while the same use cases are covered by localStorage ? sessionStorage could be optimized to be just a volatile amount of data in memory, but these requirements require sessionStorage to implement the same disk IO heuristics, and a complex heuristic to decide when to erase sessionStorage completly. I vote for the data to be present just while a page is open or is restored from history or by going back. Thank you. -- Jo?o Eiras Core Technology developer From timeless at gmail.com Sat Apr 4 12:56:48 2009 From: timeless at gmail.com (timeless) Date: Sat, 4 Apr 2009 22:56:48 +0300 Subject: [whatwg] cross-domain scrollIntoView on frames and iframes In-Reply-To: <78dc8440904031320nc185002m8f90a2146af925e4@mail.gmail.com> References: <78dc8440904031320nc185002m8f90a2146af925e4@mail.gmail.com> Message-ID: <26b395e60904041256v6a232d8ds9660b9351cf6f3b6@mail.gmail.com> sounds like a security nightmare. we already have people complaining about reframing and spoofing and things. From pkasting at google.com Sat Apr 4 15:54:10 2009 From: pkasting at google.com (Peter Kasting) Date: Sat, 4 Apr 2009 15:54:10 -0700 Subject: [whatwg] cross-domain scrollIntoView on frames and iframes In-Reply-To: <26b395e60904041256v6a232d8ds9660b9351cf6f3b6@mail.gmail.com> References: <78dc8440904031320nc185002m8f90a2146af925e4@mail.gmail.com> <26b395e60904041256v6a232d8ds9660b9351cf6f3b6@mail.gmail.com> Message-ID: On Sat, Apr 4, 2009 at 12:56 PM, timeless wrote: > sounds like a security nightmare. Can you be less vague? We've had a number of security people vet this already, so specific complaints would be very helpful. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin at google.com Sat Apr 4 18:10:22 2009 From: darin at google.com (Darin Fisher) Date: Sat, 4 Apr 2009 18:10:22 -0700 Subject: [whatwg] How long should sessionStorage data persist? In-Reply-To: References: <5dd9e5c50904031453v3210796bn5e0c7a948b447b26@mail.gmail.com> Message-ID: On Fri, Apr 3, 2009 at 5:29 PM, Ian Hickson wrote: > 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 user can, and we then perform that navigation in the previous rendering process or if that process has since been closed, we create a new one for the navigation. We hold all of the state in the main process to facilitate this. > > > 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. OK, that makes sense. -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.maone at informaction.com Sat Apr 4 23:09:54 2009 From: g.maone at informaction.com (Giorgio Maone) Date: Sun, 05 Apr 2009 08:09:54 +0200 Subject: [whatwg] cross-domain scrollIntoView on frames and iframes In-Reply-To: References: <78dc8440904031320nc185002m8f90a2146af925e4@mail.gmail.com> <26b395e60904041256v6a232d8ds9660b9351cf6f3b6@mail.gmail.com> Message-ID: <49D84B32.7030301@informaction.com> Peter Kasting wrote, On 05/04/2009 0.54: > On Sat, Apr 4, 2009 at 12:56 PM, timeless wrote: > > >> sounds like a security nightmare. >> > > > Can you be less vague? We've had a number of security people vet this > already, so specific complaints would be very helpful. > > PK It would make clickjacking attacks more precise, by exactly positioning the frame content where the attacker wants it to be. Not that you cannot already be pixel-precise by using absolute positioning inside an overflow: hidden div... Let's say it would make them even more script-kiddies friendly. -- Giorgio Maone -------------- next part -------------- An HTML attachment was scrubbed... URL: From scampa.giovanni at gmail.com Sun Apr 5 09:04:49 2009 From: scampa.giovanni at gmail.com (Giovanni Campagna) Date: Sun, 5 Apr 2009 18:04:49 +0200 Subject: [whatwg] [html5] Pre-Last Call Comments Message-ID: <65307430904050904v7c68825qfaeec0d1a7b20a43@mail.gmail.com> A few comments, as requested by Ian Hickson. - End of 2.2.1, a typo: JavsScript instead of Javascript - From section 2.4.2 I don't understand if boolean attributes with invalid values represent "true" or "false". In addition, I don't understand if an empty value is false (as in XHTML1.0) or true (as in HTML4, because of the minimized syntax). >From my experience, I expect that the empty string (which is equivalent to not specify the attribute at all) is false, and any other value is true. - In 2.4.3 I don't see the point of all the digression about contentEditable, since it is noted that it doesn't work like that. I would leave the note to just "Note: The empty string can be one of the keywords" or "Note: The empty string can a valid keyword" - In 2.4.4.3 (and maybe in other places) I would prefer [A|E]BNF instead of the prose description of a floating point number. I'm also not sure that the normative algorithm is needed. I've also searched IEEE, IETF, ECMA, ISO and ANSI for another normative version of the syntax and processing, but I've found none. If you think that it is important to have it specified completely, you may submit an ID, so future technologies won't need to rewrite it again. - The second paragraph in 2.4.5.6 is hard to understand because the verb is at the end. I would rewrite as "A week-year with a number *yr* has 53 weeks if corresponds to a year *yr* in the proleptic Gregorian calendar that has a Thursday as its first day (January 1st), or if *yr* where *yr* is a number divisible by 400, or a number divisible by 4 but not by 100. In all other cases it has 52 weeks" Also, don't rely on styles alone, use different words for identifiers and prose. This includes also the Note following, where no styles are applied and it is difficult to understand that "year year" is not a typo but rather is the year numbered "year". - Can't be simply referenced CSS3 Color in 2.4.6? This way, implementors could have body[bgcolor] { background-color: attr(bgcolor,color,white); } in the default CSS instead of using HTML5 specific rules. - In 2.4.9 a valid hash reference must be equal to an ID, name is supported only for backward compatibility. - No comments for the URL part (except that Web Addresses is different in processing, and the proposed IRI-bis draft makes it unnecessary) - Section 2.6 is superfluous: handling of application cache is specified in the appropriate section, handling of HTTP requests and caches is defined in RFC2616, handling of cookie is defined in the appropriate RFC (I don't remember the number), handling of about:blank is in the proposed about-uri-scheme ID. In addition, serialized queue-based handling of resources should not be mandated by the HTML5 specification (can't UAs be multi-threaded?) - Rewriting 2.6.1 without the HTTP word is definitely better. Browsers are not required to support HTTP, AFAIK. You can write "a GET method" (because GET is anyway an English word), "a response code" (most protocols have response codes) and "metadata" (instead of headers, that SMTP, POP, FTP don't support) - 2.6.2 should be implied by the HTTP-over-TLS RFC - In section 2.7.1, in sentence "Extensions must not be used for determining resource types for resources fetched over HTTP.", do you mean "File extensions", like .txt or .png, or "User agent extensions" (additions to the algorithm)? - Still in section 2.7.1, why the algorithm is a violation of RFC2616? Because it is case insensitive? Because it allows spaces? Because it does not imply ISO-8859-1 if no charset is explicit? Because it does not imply ASCII for text/* mime types? - Why don't you add " - In section 4.2.5.3, a document may have a default language even if it doesn't have a content-language http-equiv, if it has a Content-Language HTTP header. - Section 4.2.7 should be completely delegated to CSSOM - Noscript should be allowed in XML, just without the complexity (and simply treated as display:none if scripting is enabled) - And is a grammar mistake in "These juicy, green apples and make a great filling for apple pies" (the example in 4.4.2) - I completely cannot understand 4.4.10.2 - I would like to disagree with the man who disagreed with the other man who disagreed with Ian Hickson (who said that things that are impossible just take longer) (section about ) - I don't think it is of any use to link a BBC article in 4.6.20 - Section 4.8.3 still refers to the Window Object specification, which I think has been superseded by HTML5 - classid is not a conforming attribute for object, and yet it is used in the algorithm to find a plugin. AFAIK, classid is only used by IE (along with COM) so I don't think it is a problem to drop it completely. (skipping video and canvas) - in HTMLFormElement, the function item should accept an integer, not a DOMString (because it is an IndexGetter) Same in HTMLSelectElement - In section 4.10.4, the table about which attributes applies to the various input types overflows in Opera 9.64 (1280x768 being the resolution, 12pt the font size) and it is very hard to read - In 4.10.4.1.5 I expect that neither the user is able to see the password - In 4.10.4.2.8 an "A" is missing in the part number example I read all up to and including section 4. I think I will take a break for now. The spec is incredibly long, but having an author only mode definitely helps (anyway the review is for the whole spec, not just the green parts). I hope that this will help someone Giovanni From giecrilj at stegny.2a.pl Sun Apr 5 09:47:01 2009 From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=) Date: Sun, 5 Apr 2009 18:47:01 +0200 Subject: [whatwg] [html5] Pre-Last Call Comments In-Reply-To: <65307430904050904v7c68825qfaeec0d1a7b20a43@mail.gmail.com> References: <65307430904050904v7c68825qfaeec0d1a7b20a43@mail.gmail.com> Message-ID: Character set x-x-big5 cannot be registered because it is private. Now that classid is gone, what will be the workaround for ActiveX objects where they are needed? 1. Ask Windows browsers to support Type="application/x-oleobject;classid=..."? 2. Use a custom DTD with classid for validation? 3. Use a custom type "application/vnd.acme-fancy-control+oleobject" for every control? 4. Rewrite everything Silverlight? 5. Ask the developers to keep their pages HTML4? Of course, such things are inherently nonportable but they are widely used. It would be nice to have a way to validate them. Chris From joao.eiras at gmail.com Sun Apr 5 09:55:37 2009 From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=) Date: Sun, 05 Apr 2009 18:55:37 +0200 Subject: [whatwg] [html5] Pre-Last Call Comments In-Reply-To: References: <65307430904050904v7c68825qfaeec0d1a7b20a43@mail.gmail.com> Message-ID: On , Kristof Zelechovski wrote: > Character set x-x-big5 cannot be registered because it is private. > > Now that classid is gone, what will be the workaround for ActiveX objects > where they are needed? > classid is nevertheless proprietary, and no other user agent but IE will require it (unless others implement ActiveX as well). The spec does not forbid to use non supported attributes and elements. It only specifies the handling for the known ones. From giecrilj at stegny.2a.pl Sun Apr 5 10:01:25 2009 From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=) Date: Sun, 5 Apr 2009 19:01:25 +0200 Subject: [whatwg] [html5] Pre-Last Call Comments In-Reply-To: References: <65307430904050904v7c68825qfaeec0d1a7b20a43@mail.gmail.com> Message-ID: <4168448396F74F1ABFD0E24F98C42F23@POCZTOWIEC> The specification forbids the authors using undefined elements and attributes; a document containing classid will not be valid. Still, the site hosting the controls will need a way to test validity of pages for QA. Chris From lists.whatwg at stakface.com Sun Apr 5 12:44:46 2009 From: lists.whatwg at stakface.com (Kartikaya Gupta) Date: Sun, 05 Apr 2009 19:44:46 +0000 Subject: [whatwg] HTML5 typos Message-ID: <20090405194447.57DA488D8@looneymail-mx3.g.dreamhost.com> I ran the spec through a typo-finder program I cooked up and it found these among lots of false positives. altogther (4.8.2.1.13) approprate (5.8.4) argments (4.8.11.1.10) asychronously (5.8.4) attribue's (2 in 4.6.12) attrbutes (4.10.4) constaints (4.10.14.2, 2 in 4.10.14.3) elemnt (4.10.14.3) elment (6.5, 4.3.1) follwed (4.10.2) fouth (4.10.9) implementaion (5.7.2) indicies (4.10.1, 4.10.6) knowns (4.2.2) oherwise (3.3.3.5) snipet (4.6.10) sebsteps (5.8.4) Also, the following words appear with different spelling variations; I suggest one of the variants be picked and used consistently: behaviour vs. behavior favorite vs. favourite honour vs. honor occurance[s] vs. occurrence[s] categoris* vs. categoriz* recognis* vs. recogniz* serialis* vs. serializ* tokenis* vs. tokeniz* Cheers, kats From christoph.paeper at crissov.de Sun Apr 5 13:10:28 2009 From: christoph.paeper at crissov.de (=?ISO-8859-1?Q?Christoph_P=E4per?=) Date: Sun, 5 Apr 2009 22:10:28 +0200 Subject: [whatwg] [html5] Pre-Last Call Comments In-Reply-To: <65307430904050904v7c68825qfaeec0d1a7b20a43@mail.gmail.com> References: <65307430904050904v7c68825qfaeec0d1a7b20a43@mail.gmail.com> Message-ID: <4586618F-8C62-4F45-9CDC-F0B0C4C88E45@crissov.de> Giovanni Campagna: > - The second paragraph in 2.4.5.6 is hard to understand because the > verb is at the end. I would rewrite as > "A week-year with a number *yr* has 53 weeks if corresponds to a > year *yr* in the proleptic Gregorian calendar that has a Thursday > as its first day (January 1st), or if *yr* where *yr* is a number > divisible by 400, or a number divisible by 4 but not by 100. In all > other cases it has 52 weeks" | A week-year with a number $year that corresponds to a year $year in the | proleptic Gregorian calendar that has a Thursday as its first day | (January 1st), and a week-year $year where $year is a number divisible | by 400, or a number divisible by 4 but not by 100, has 53 weeks. All | other week-years have 52 weeks. The description is wrong anyhow: Not every leap year has 53 weeks! (For instance, 2008 and 2012 have 52 weeks only.) The difference to common years is that leap years with 53 weeks can have Jan01 on either Thu or Wed, because Dec31 then is Fri or Thu respectively. (Compare your 2020 to your 2004 calendar.) : A week-year has 52 weeks, except it has 53 weeks when 1 January in the : Gregorian year of the corresponding number $year falls on a Thursday, : or it falls on a Wednesday and $year is a leap year. "1 January" = "the first day of the first month" (-01-01, -001) "a Thursday" = "the fourth day of the week" (-4) "a Wednesday" = "the third day of the week" (-3) "leap year" = "number divisible by 4 but not by 100 or a number divisible by 400" Or just reference and rely on ISO 8601. That is what references (especially to standards) are for after all. By the way, because there is an even number of weeks in a Gregorian 400-year cycle, the 53-week years (after the epoch) are: 400 * n + a; n e |N?, a c L L := {004, 009, 015, 020, 026, 032, 037, 043, 048, 054, 060, 065, 071, 076, 082, 088, 093, 099, 105, 111, 116, 122, 128, 133, 139, 144, 150, 156, 161, 167, 172, 184, 189, 195, 201, 207, 212, 218, 224, 229, 235, 240, 246, 252, 257, 263, 268, 274, 280, 285, 291, 296, 303, 304, 308, 314, 320, 325, 331, 336, 342, 348, 353, 359, 364, 370, 376, 381, 387, 392, 398} That is 71 leap-week years opposed to 97 leap-day years. PS: All complications are the fault of the month calendar, not of the week calendar. From Simetrical+w3c at gmail.com Sun Apr 5 13:20:52 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Sun, 5 Apr 2009 16:20:52 -0400 Subject: [whatwg] HTML5 typos In-Reply-To: <20090405194447.57DA488D8@looneymail-mx3.g.dreamhost.com> References: <20090405194447.57DA488D8@looneymail-mx3.g.dreamhost.com> Message-ID: <7c2a12e20904051320q73109957gac5fd6fe06d716d3@mail.gmail.com> On Sun, Apr 5, 2009 at 3:44 PM, Kartikaya Gupta wrote: > Also, the following words appear with different spelling variations; I suggest one of the variants be picked and used consistently: > > behaviour vs. behavior > favorite vs. favourite > honour vs. honor > occurance[s] vs. occurrence[s] This isn't a variation. As far as I'm aware, "occurance", "occurance", and "occurence" are not considered valid spellings by anyone: the correct spelling is "occurrence". From chris.double at double.co.nz Sun Apr 5 15:52:07 2009 From: chris.double at double.co.nz (Chris Double) Date: Mon, 6 Apr 2009 10:52:07 +1200 Subject: [whatwg] Start position of media resources Message-ID: Ogg based media resources can start from a time position that is not zero. Examples of files that do this are those generated by the program oggz-chop. For example: http://ia331342.us.archive.org/2/items/night_of_the_living_dead/night_of_the_living_dead.ogv?t=0:20:00/0:20:50 If this is played in VLC the start time of the video is 0:20:00. When seeking the time requested for the seek must be between 0:20:00 and 0:20:50. Does the HTML5 spec allow media resources that don't start from 0? I see in the spec mention: "Media elements have a current playback position, which must initially be zero. The current position is a time." In the case of the Ogg file above, the current playback position would initially be zero, but when the first frame is loaded it will be 0:20:00. Is this valid per the spec? If so, would we need an attribute on the media object so the web page author can retrieve the start time of the video (in the same way they can get the duration). They would need this to be able to display progress bars/scrubbers to position the thumb correctly based on the currentTime. Detecting the first frame or metadata loaded events and getting the position of the that won't work as some of the video may have been played by the time that event is handled by user code. Chris. -- http://www.bluishcoder.co.nz From whatwg at adambarth.com Sun Apr 5 22:32:10 2009 From: whatwg at adambarth.com (Adam Barth) Date: Mon, 6 Apr 2009 00:32:10 -0500 Subject: [whatwg] cross-domain scrollIntoView on frames and iframes In-Reply-To: <49D84B32.7030301@informaction.com> References: <78dc8440904031320nc185002m8f90a2146af925e4@mail.gmail.com> <26b395e60904041256v6a232d8ds9660b9351cf6f3b6@mail.gmail.com> <49D84B32.7030301@informaction.com> Message-ID: <7789133a0904052232s645f8562t88c7e26bfefd5ba1@mail.gmail.com> On Sun, Apr 5, 2009 at 1:09 AM, Giorgio Maone wrote: > It would make clickjacking attacks more precise, by exactly positioning the > frame content where the attacker wants it to be. > Not that you cannot already be pixel-precise by using absolute positioning > inside an overflow: hidden div... > Let's say it would make them even more script-kiddies friendly. Hum... That doesn't sound that bad. If you're relying on the obscurity of pixel offsets for a clickjacking defense, then you've got bigger problems than scrollIntoView. Adam From darin at chromium.org Mon Apr 6 00:03:23 2009 From: darin at chromium.org (Darin Fisher) Date: Mon, 6 Apr 2009 00:03:23 -0700 Subject: [whatwg] Worker feedback In-Reply-To: <11e306600904031449xb7a425apd0d9c1a7909d4ea4@mail.gmail.com> References: <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> <5dd9e5c50904031035x4b95b0ds456944e9451936c8@mail.gmail.com> <11e306600904031449xb7a425apd0d9c1a7909d4ea4@mail.gmail.com> Message-ID: On Fri, Apr 3, 2009 at 2:49 PM, Robert O'Callahan wrote: > On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow 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? > In addition to alert(), don't forget about all the great state changing things that can happen to the cookie database (and other data stores) during a synchronous XMLHttpRequest (or synchronous document.load) in Firefox. Maybe those are just bugs? What if a Firefox extension wants to muck around with the cookie database while a web page is blocked on a synchronous XMLHttpRequest? Maybe that should fail to avoid dead-locking? Sounds like a recipe for flaky extensions since it is unlikely that the extension author would have been prepared for being called at this time when access to the cookie database would have to be denied. (In Firefox, a new event loop is run to continue processing events while that synchronous XMLHttpRequest is active. That event loop helps keep the application alive and responsive to user action.) When deciding how to handle cookies in Chrome, we did not worry about the problem being debated here. Our concerns were allayed by recognizing that IE does not try to solve it (and IE6 is multi-process just like Chrome with a shared network stack), so clearly web developers must already have to cope. We flirted with the idea of letting each renderer maintain a local copy of its cookies, but that turned out to more complicated than was necessary. In the end, we ended up synchronizing with the main process on each call to document.cookie to fetch a snapshot. I think it would be best to specify that document.cookie returns a snapshot. I think that is consistent with existing implementations including IE, Firefox, and Chrome. I don't know about Safari and Opera, but it seems plausible that they could have similar behavior thanks to nested event queues which are typically used to support synchronous XHR and window.alert(). You would be surprised by the number of times it comes up that web developers at Google think Firefox has multi-threaded JS thanks to this behavior of synchronous XHR ;-) -Darin > > > 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] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Mon Apr 6 01:38:43 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 6 Apr 2009 08:38:43 +0000 (UTC) Subject: [whatwg] Worker feedback In-Reply-To: References: <11e306600904011502y3c4e54e4q2eca693d10d352a7@mail.gmail.com> <11e306600904011517n4c81dadbj56c17146526fe7b7@mail.gmail.com> <5dd9e5c50904021300x13058d08ia75715da9972e004@mail.gmail.com> <11e306600904021837k3513371et98fb2538efd40c50@mail.gmail.com> <5dd9e5c50904022111hc433deekd0b36950197b5f22@mail.gmail.com> <11e306600904022126x5bf9b752uda8428dc9d9dae1e@mail.gmail.com> <5dd9e5c50904031035x4b95b0ds456944e9451936c8@mail.gmail.com> <11e306600904031449xb7a425apd0d9c1a7909d4ea4@mail.gmail.com> Message-ID: On Mon, 6 Apr 2009, Darin Fisher wrote: > > In addition to alert(), don't forget about all the great state changing > things that can happen to the cookie database (and other data stores) > during a synchronous XMLHttpRequest (or synchronous document.load) in > Firefox. Maybe those are just bugs? The HTML5 spec says the storage mutex is released when alert() is called. I've asked Anne (editor of the XHR spec) to say that it is released when a sync XHR is started, too. Per the HTML5 spec, setting the cookies from the network grabs the storage mutex briefly. (Reading them is implicitly atomic, but might happen while someone else holds the mutex, so per spec there is still a chance of the cookies sent to the server being in an inconsistent state if they are read while a script is in the middle of a multi-stage cookie update.) I don't really mind if the spec says whether cookies should be protected by the storage mutex or not (the spec says they should be because that seems to be the majority opinion). I'm pretty sure localStorage should be so protected, though. I don't really see how to get away from that. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From silviapfeiffer1 at gmail.com Mon Apr 6 01:40:28 2009 From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer) Date: Mon, 6 Apr 2009 18:40:28 +1000 Subject: [whatwg] Start position of media resources In-Reply-To: References: Message-ID: <2c0e02830904060140l6aa1d474k6d667275a6613768@mail.gmail.com> Hi Chris, At the end of last year (I cannot find the thread any more) there was a discussion about removing a start offset attribute from the video element. The reason it was removed is that the W3C media fragments working group is working on a specification that is similar to the temporal URI specification that Ogg and archive.org are using. The idea is that in future all media files will have the ability to do temporal URIs (but also other types of fragment URIs like spatial or tracks). The W3C media fragments working group is right now in the process of finalizing the first WD on this specification. You will be able to comment on it soon - if you want to check out it's current incomplete specification, it's here: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/ . Thus, the idea is that the