Message-ID: <3b31caf90909011608q3795529fg185ec701d37094a7@mail.gmail.com> >From #attr-time-pubdate: > If specified, [pubdate=""] indicates that the date and time given by > the element is the publication date and time of the nearest ancestor > article element. If the element has no ancestor article element, the > pubdate attribute must not be specified. I think this overlooks the case where serves as an implicit

?a simple document with no non-article content. If there's no ancestor

, a with pubdate="" should apply to the implicit article represented by . Something like the following might do the trick: > If specified, it indicates that the date and time given by the element > is the publication date and time of the nearest ancestor article or > body element. Thanks, Ted From ian at hixie.ch Tue Sep 1 16:12:18 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Sep 2009 23:12:18 +0000 (UTC) Subject: [whatwg] Adding alpha channel to In-Reply-To: <1251293172.4757.86.camel@desudesudesu> References: <4A94774D.4010805@gmail.com> <4A94E5BD.2060102@romantschuk.fi> <1251293172.4757.86.camel@desudesudesu> Message-ID: On Wed, 26 Aug 2009, Victor Vasiliev wrote: > > Section 4.10.4.1.15 says that color must be in sRGB. However, it may be > handful for some applications to have alpha channel specified, since > many GUI libraries (GTK has it; I'm also told Mac OS supports it as > well) support color picker with opacity control. > > I suggest to add a boolean attribute "alpha" to > (disabled by default). If this attribute is present, the color well > allows to set opacity value, and instead of sRGB, sends RGBA. This seems like a reasonable thing to add in a future version. I haven't added it to HTML5, since we're so close to last call, but if our experience with type=color when the UAs widely support it suggests this is important, we can prioritise this as a new feature in the next version. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 1 16:12:57 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Sep 2009 23:12:57 +0000 (UTC) Subject: [whatwg] SharedWorkers and the name parameter In-Reply-To: References: <5862638.83261250475050752.JavaMail.coremail@bj163app20.163.com> Message-ID: On Tue, 25 Aug 2009, Jim Jewett wrote: > On Tue, Aug 25, 2009 at 7:24 PM, Ian Hickson wrote: > > Drew Wilson wrote: > >> Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared > >> worker with a url and name, it is illegal for any other page under > >> the same origin to load a worker with the same name > > > > The idea here is that if you have an app that does database > > manipulation, you might want to ensure there is only ever one shared > > worker doing the manipulation, so you might decide on a shared worker > > name that is in charge of that, and then you can be sure that you > > don't accidentally start two workers with that name using different > > copies of a script > > So the name is really intended as a (lightweight) URN, but it can > default to the URL? The name is an opaque string. It can be whatever you want. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From snej at google.com Tue Sep 1 16:20:37 2009 From: snej at google.com (Jens Alfke) Date: Tue, 1 Sep 2009 16:20:37 -0700 Subject: [whatwg] HTML extension for system idle detection. In-Reply-To: <028301ca2ad0$f1527e80$0a01a8c0@mikedeskxp> References: <028301ca2ad0$f1527e80$0a01a8c0@mikedeskxp> Message-ID: On Aug 31, 2009, at 11:53 PM, Mike Wilson wrote: > This requirement could be solved in several other ways, f ex making > sure that the "standard" timeout period is short enough to not be > longer than what any app wants. Then (as was previously suggested) > an app that wants a longer timeout can do setTimeout and trigger its > own idle stuff if status has not come back to "active" during that > time. This seems reasonable. Different apps really do want different idle- time thresholds (if only for compatibility with other manifestations of the app, i.e. an IM platform), but I think the event-plus-custom- timeout mechanism would let them achieve that. > Another alternative is to have no event, and just a property: > window.lastUserActionTime > which is kept updated with the "msec since epoch" for the latest > user input on the desktop. Then an app can implement its own idle > functionality with totally own rules. This API has the drawback of > maybe exposing too much information (the rate of input events to > other apps), but may spawn some ideas. This would have to be deliberately fuzzed, as it is apparently possible to guess user typing by looking at the timing between keystrokes. Rounding it to the nearest second would probably suffice. The problem with this API is that, once the app determines the user is idle, it has to keep polling lastUserActionTime until it sees it change. I'm not fond of APIs that require the client to poll. The best solution, I think, would be both of the above. The lastUserActionTime property lets a page test whether the user's already idle at the time it loads, and the event lets it detect transitions without having to poll. ?Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at chromium.org Tue Sep 1 16:26:04 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Wed, 2 Sep 2009 08:26:04 +0900 Subject: [whatwg] HTML extension for system idle detection. In-Reply-To: <028301ca2ad0$f1527e80$0a01a8c0@mikedeskxp> References: <028301ca2ad0$f1527e80$0a01a8c0@mikedeskxp> Message-ID: <5dd9e5c50909011626j1ec7add4v2b3995d8fcce62fb@mail.gmail.com> On Tue, Sep 1, 2009 at 3:53 PM, Mike Wilson wrote: > David Bennett wrote: > > On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson wrote: > >> This would be my inclination as well. I'm not entirely convinced that >> "every web app should define their own idle timeout" is such desirable >> behavior that we should build our API around it by forcing every caller to >> specify their idle timeout - having a standard event that's fired with an >> exposed state for apps that need it seems like a cleaner approach. >> > > The trouble with this is it doesn't allow any experimentation on the part > of the app/entity to figure out what is the best idle time for it's > purposes. In terms of chat it might be that a 3 minute or 5 minute idle > time works best in terms of people's attention. For something like watching > a video perhaps a 15 minute idle would be a better length of time, or for an > online game a longer idle time is probably useful before being signed out. > Different purposes have different requirements for the idle time so it > makes sense to allow them to specify the different timeouts. > > This requirement could be solved in several other ways, f ex making sure > that the "standard" timeout period is short enough to not be longer than > what any app wants. Then (as was previously suggested) an app that wants a > longer timeout can do setTimeout and trigger its own idle stuff if status > has not come back to "active" during that time. > If we went the route of using events, I definitely think this is the way to go. Since the originally proposed API was based off of the timer API, you're really only adding one step if you want that behavior. Having a globally configured value seems sloppy and you'll have to manually use timeouts if, for example, you were using 2 libraries that used it for different purposes and thus wanted different idle timeouts. > Another alternative is to have no event, and just a property: > window.lastUserActionTime > which is kept updated with the "msec since epoch" for the latest user input > on the desktop. Then an app can implement its own idle functionality with > totally own rules. This API has the drawback of maybe exposing too much > information (the rate of input events to other apps), but may spawn some > ideas. > Then you're poling, which seems pretty ugly. I'd much prefer events to this. 2009/8/31 Max Romantschuk > > One issue: > > Is the user idle when the tab is in the background, when the browser is in > the background, or when the user is away from the machine? These are all > distinct cases of different levels of "idleness", and it's largely depended > on the use case which kind of "idleness" makes sense for a particular > application. > I would argue that "when the browser is in the background" should be no different from "when the tab is in the background". Given that the information the system uses to determine idleness (mouse movements and such) are all available to a web app while it's in the foreground tab, it seems as though knowing the idle time just from the perspective of your tab is not terribly useful. So, to me, I think it's pretty clear this should be system wide idleness. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorlow at chromium.org Tue Sep 1 16:31:22 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Wed, 2 Sep 2009 08:31:22 +0900 Subject: [whatwg] Storage mutex and cookies can lead to browser deadlock In-Reply-To: <5dd9e5c50908261524r7d95c480n912bce970e9bc258@mail.gmail.com> References: <49136932-8457-4C3A-9190-AEA878C4087D@google.com>

<5dd9e5c50908261454t17269d3bp2f5da554fe964b40@mail.gmail.com> <11e306600908261505m4b8ff8fcl74b132ea8de64e55@mail.gmail.com> <5dd9e5c50908261524r7d95c480n912bce970e9bc258@mail.gmail.com> Message-ID: <5dd9e5c50909011631k729fdb80if8e43c22aa916579@mail.gmail.com> On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow wrote: > On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan wrote: > >> On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow wrote: >> >>> Is there any data (or any way to collect the data) on how much of the web >>> IE and Chrome's current behavior has broken? Given that there hasn't been >>> panic in the streets, I'm assuming approximately 0%? >>> >> >> We previously had a lengthy discussion about this. >> >> If a site has a cookie race that causes a problem in IE/Chrome one in >> every 10,000 page loads, are you comfortable with that? >> > > I'm much more comfortable with that than the cost of a global mutex that > all cookies and LocalStorage share. There are other ways to come about this > problem (like developer tools). > > I'm pretty sure Chromium has no intention of implementing a global storage > mutex and putting all cookie access under it. Has anyone heard anything > (either way) from Microsoft? Are there any browsers moving to a > multi-event-loop (be it multi-threaded or multi-process) based model that > intend to implement this? If not, then it would seem like the spec is not > grounded in reality. > Does the silence mean that no one has any intention of implementing this? If so, maybe we should resign ourselves to a break in the single threaded illusion for cookies. This doesn't seem too outlandish considering that web servers working with cookies will never have such a guarantee and given that we have no evidence of widespread breakage with IE 8 and Chrome. If we were to get rid of the storage mutex for cookie manipulation (as I believe we should) maybe we should re-examine it for local storage. At a minimum, it could be implemented as a per-origin mutex. But I feel strongly we should go further. Why not have an asynchronous mechanism for atomic updates? For example, if I wanted to write an ATM application, I would have to do the following: var accountDelta = /* something */; window.localStorage.executeAtomic(function() { localStorage.accountBalance = localStorage.accountBalance + accountDelta; } Alternatively, we could make it so that each statement is atomic, but that you have to use such a mechanism for anything more complicated. For example: localStorage.accountBalance = localStorage.accountBalance + accountDelta; // It's atomic, so no worries! var balance = localStorage.accountBalance; /* Oh no!!!! This isn't safe since it's implemented via multiple statements... */ localStorage.accountBalance = balance + accountDelta; /* ....we should have used localStorage.executeAtomic! */ Such ideas would definitely lighten lock contention and possibly eliminate the need for yieldForStorageUpdates (formerly getStorageUpdates). Another major bonus is that it'd allow us to expose localStorage to workers again, which is one of the top complaints I've gotten when talking to web developers about localStorage. I know this is radical stuff, but the way things are speced currently just are not practical. J -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddt at google.com Tue Sep 1 16:33:36 2009 From: ddt at google.com (David Bennett) Date: Tue, 1 Sep 2009 16:33:36 -0700 Subject: [whatwg] HTML extension for system idle detection. In-Reply-To: <5dd9e5c50909011626j1ec7add4v2b3995d8fcce62fb@mail.gmail.com> References: <028301ca2ad0$f1527e80$0a01a8c0@mikedeskxp> <5dd9e5c50909011626j1ec7add4v2b3995d8fcce62fb@mail.gmail.com> Message-ID: On Tue, Sep 1, 2009 at 4:26 PM, Jeremy Orlow wrote: > On Tue, Sep 1, 2009 at 3:53 PM, Mike Wilson wrote: > >> David Bennett wrote: >> >> On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson wrote: >> >>> This would be my inclination as well. I'm not entirely convinced that >>> "every web app should define their own idle timeout" is such desirable >>> behavior that we should build our API around it by forcing every caller to >>> specify their idle timeout - having a standard event that's fired with an >>> exposed state for apps that need it seems like a cleaner approach. >>> >> >> The trouble with this is it doesn't allow any experimentation on the part >> of the app/entity to figure out what is the best idle time for it's >> purposes. In terms of chat it might be that a 3 minute or 5 minute idle >> time works best in terms of people's attention. For something like watching >> a video perhaps a 15 minute idle would be a better length of time, or for an >> online game a longer idle time is probably useful before being signed out. >> Different purposes have different requirements for the idle time so it >> makes sense to allow them to specify the different timeouts. >> >> This requirement could be solved in several other ways, f ex making sure >> that the "standard" timeout period is short enough to not be longer than >> what any app wants. Then (as was previously suggested) an app that wants a >> longer timeout can do setTimeout and trigger its own idle stuff if status >> has not come back to "active" during that time. >> > > If we went the route of using events, I definitely think this is the way to > go. Since the originally proposed API was based off of the timer API, > you're really only adding one step if you want that behavior. Having a > globally configured value seems sloppy and you'll have to manually use > timeouts if, for example, you were using 2 libraries that used it for > different purposes and thus wanted different idle timeouts. > I have been thinking about this. I think this sounds reasonable too, perhaps we should specify a minimum idle event timeout? For example make the event fire after 2 minutes idle? Be easy to hook up to the property without a timeout to see if the user is still idle after this time. > > >> Another alternative is to have no event, and just a property: >> window.lastUserActionTime >> which is kept updated with the "msec since epoch" for the latest user >> input on the desktop. Then an app can implement its own idle functionality >> with totally own rules. This API has the drawback of maybe exposing too much >> information (the rate of input events to other apps), but may spawn some >> ideas. >> > > Then you're poling, which seems pretty ugly. I'd much prefer events to > this. > > 2009/8/31 Max Romantschuk >> >> One issue: >> > >> Is the user idle when the tab is in the background, when the browser is in >> the background, or when the user is away from the machine? These are all >> distinct cases of different levels of "idleness", and it's largely depended >> on the use case which kind of "idleness" makes sense for a particular >> application. >> > > I would argue that "when the browser is in the background" should be no > different from "when the tab is in the background". Given that the > information the system uses to determine idleness (mouse movements and such) > are all available to a web app while it's in the foreground tab, it seems as > though knowing the idle time just from the perspective of your tab is not > terribly useful. So, to me, I think it's pretty clear this should be system > wide idleness. > Yes, I agree idlessness form being in the background should be a different event/information if it is supported. I will update my document with these ideas and then repost. Thanks, David. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Tue Sep 1 16:47:40 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Sep 2009 23:47:40 +0000 (UTC) Subject: [whatwg] SharedWorkers and the name parameter In-Reply-To: References: <5862638.83261250475050752.JavaMail.coremail@bj163app20.163.com> Message-ID: On Tue, 25 Aug 2009, Drew Wilson wrote: > On Tue, Aug 25, 2009 at 4:24 PM, Ian Hickson wrote: > > On Tue, 18 Aug 2009, Drew Wilson wrote: > > > > > > An alternative would be to make the "name" parameter optional, where > > > omitting the name would create an unnamed worker that is > > > identified/shared only by its url. > > > > > > So pages would only specify the name in cases where they actually > > > want to have multiple instances of a shared worker. > > > > Done. > > Thanks for adding this, Ian. However, the resulting spec language is > subtly different from what I was proposing. Section 4.8.3 of the spec > now reads: > > "4. Let name be the value of the second argument, or the value of > scriptURL, if the second argument was omitted." > > My reading of this is if I do the following: > > var worker1 = new SharedWorker("http://www.example.com/worker", " > http://www.example.com/worker2"); > > Then try to do this: > > var worker2 = new SharedWorker("http://www.example.com/worker2"); > > The second invocation of the constructor would throw a URL_MISMATCH_ERR, > since the name "http://www.example.com/worker2" is already associated > with the script at "http://www.example.com/worker". Yeah, good point. Ok, fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 1 16:51:37 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Sep 2009 23:51:37 +0000 (UTC) Subject: [whatwg] brief question on 2.4.5 Dates and times In-Reply-To: <2c0e02830908262028q6126715en9b36374bd8d1001a@mail.gmail.com> References: <2c0e02830908251901k5a5836aaqe1dd23e2de9bfa2b@mail.gmail.com> <2c0e02830908262028q6126715en9b36374bd8d1001a@mail.gmail.com> Message-ID: On Wed, 26 Aug 2009, Silvia Pfeiffer wrote: > > I am trying to use the specification of Dates and times given in section > 2.4.5. How? That section is just introducing concepts for the rest of the spec. > I was surprised to find that there is a specification of a valid month > string, but not of a valid year string or a valid day string. Is that an > oversight? No, nothing in the spec uses the term "valid year string" or "valid day string", so I didn't need to define them. On Thu, 27 Aug 2009, Silvia Pfeiffer wrote: > > I was trying to find out what restrictions we are putting on the year > part of the string. E.g. are we allowing years before the year 0 and > how. In what context? ? ? ? Something else? (The answer is the same for all of them, but the answer is much easier to find if you start from a concrete question, and then follow the definitions back.) > It's all there, and it's all fully defined by recursive definition of > the parts that are being re-used (e.g. date reuses month (which is > month-year, but not just month). However, if you are trying to look for > something, it's rather confusing not to have e.g. year and day exposed > in the contents, while month is. If you're looking for something, start at the start. Don't try to short-circuit the spec and jump half-way through your answer; if you do that you might miss restrictions that apply to particular cases. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 1 16:59:22 2009 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Sep 2009 23:59:22 +0000 (UTC) Subject: [whatwg] formNoValidate/novalidate/willValidate In-Reply-To: References: <4A94A47A.2030005@gmail.com> Message-ID: On Wed, 26 Aug 2009, Dean Edwards wrote: > > It's been a while. :) > > Looking through the spec I see the following DOM properties: > > * formNoValidate > * novalidate > * willValidate > > "novalidate" sticks out like a sore thumb. Can we change it to > "noValidate". It's only mentioned in the IDL so maybe it's a typo. Fixed, thanks. On Tue, 25 Aug 2009, Peter Kasting wrote: > > IIRC when we (my GSoC student and I; he's been working on form > validation in WebKit) encountered this recently, we assumed it was a > typo, and I used the snazzy little "file a bug from directly on this > page" UI on the spec to note it. Thanks. I'll get to that when I get to the bugs (I'm dealing with e-mails first because I have more of them.) On Wed, 26 Aug 2009, Simon Pieters wrote: > > There's also formnoValidate actually, and formaction vs formAction on > HTMLButtonElement vs HTMLInputElement. Also see > http://www.w3.org/Bugs/Public/show_bug.cgi?id=7389 Thanks, fixed those too and marked the bug fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 1 17:48:27 2009 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Sep 2009 00:48:27 +0000 (UTC) Subject: [whatwg] Note on the DETAILS element In-Reply-To: References: Message-ID: On Wed, 26 Aug 2009, Jeremy Keith wrote: > > The text for

begins with a definition: I assume you mean the text for . > "The hgroup element represents the heading of a section. The element is > used to group a set of h1?h6 elements when the heading has multiple > levels, such as subheadings, alternative titles, or taglines." > > But then has this note immediately afterwards: > > "The point of hgroup is to mask an h2 element (that acts as a secondary > title) from the outline algorithm." > > As far as I can tell, this is incorrect. The point of an hgroup is > actually to mask *all but one* heading element from the outline > algorithm. You win some, you lose some, I guess: http://www.brucelawson.co.uk/2009/html-5-is-a-mess/#comment-618892 I've moved the note to an example, so it's less misleading. Thanks, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Sep 1 18:35:46 2009 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Sep 2009 01:35:46 +0000 (UTC) Subject: [whatwg] Proposal for local-storage file management In-Reply-To: <71781F55-D905-4E10-99A2-BF11CFB4C996@google.com> References: <71781F55-D905-4E10-99A2-BF11CFB4C996@google.com> Message-ID: On Thu, 27 Aug 2009, Jens Alfke wrote: > > Here's what a typical scenario might look like: > Ellen tells me about a great online animation program. I go to its site, and > it puts up a Canvas and a bunch of snazzy drawing tools, so I start sketching > frames of an animation. (Behind the scenes, the app is storing my drawings in > session storage. This is considered temporary, so the browser gives it a > reasonable quota without any user interaction.) > After a while I decide I want to keep using the app, and the stuff I've drawn > has potential, so I decide to save it to disk. I click the Save button, and > the site (actually the browser) puts up a standard Save dialog box. Right now this can be done by the site directly. Also, we'd have to keep providing persistent storage without user input, so that the site can store preferences or the like without prompting the user (just like cookies today). > Next year I've switched allegiance to UltraAnimate.com, so while > cleaning house I go through my Web Documents folder, see the old > "SooperAnimator.com Data" file, and trash it to save disk space. You can do that today with cookies, which local storage is supposed to be exposed as in the UI. Do users ever look through their old cookies? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From robert at ocallahan.org Tue Sep 1 18:48:11 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 2 Sep 2009 13:48:11 +1200 Subject: [whatwg] Storage mutex and cookies can lead to browser deadlock In-Reply-To: <5dd9e5c50909011631k729fdb80if8e43c22aa916579@mail.gmail.com> References: <49136932-8457-4C3A-9190-AEA878C4087D@google.com>

begins with a definition: > > I assume you mean the text for . Doh! Yes, I did. > You win some, you lose some, I guess: > > http://www.brucelawson.co.uk/2009/html-5-is-a-mess/#comment-618892 > > I've moved the note to an example, so it's less misleading. Thanks, much appreciated. I figured that the genesis of that note was the comment thread on Bruce's post but it only makes sense in the context of H1+H2. Ah well. -- Jeremy Keith a d a c t i o http://adactio.com/ From darin at chromium.org Wed Sep 2 09:55:05 2009 From: darin at chromium.org (Darin Fisher) Date: Wed, 2 Sep 2009 09:55:05 -0700 Subject: [whatwg] Storage mutex and cookies can lead to browser deadlock In-Reply-To: <5dd9e5c50909011631k729fdb80if8e43c22aa916579@mail.gmail.com> References: <49136932-8457-4C3A-9190-AEA878C4087D@google.com>

<5dd9e5c50908261454t17269d3bp2f5da554fe964b40@mail.gmail.com> <11e306600908261505m4b8ff8fcl74b132ea8de64e55@mail.gmail.com> <5dd9e5c50908261524r7d95c480n912bce970e9bc258@mail.gmail.com> <5dd9e5c50909011631k729fdb80if8e43c22aa916579@mail.gmail.com> Message-ID: When we had this discussion last, there was significant pushback on this - the argument was basically "we have no evidence that cookie-based race conditions *aren't* causing sporadic breakages", which is true. It's inherently difficult to measure. As an aside, I'll note that the majority of pushback came from developers of platforms that were inherently single-threaded, and so enforcing synchronicity had no impact on the performance of their platforms. It's easy to be a purist when there's no cost. Now that more browsers are moving to multi-process architectures and will soon be faced with having to reduce the performance of their platforms to enforce cookie coherence, I wonder if people's attitudes have changed. I, too, would be interested in hearing if the folks working on multi-process firefox are planning to implement this piece of the spec. -atw On Wed, Sep 2, 2009 at 9:55 AM, Darin Fisher wrote: > > > On Tue, Sep 1, 2009 at 4:31 PM, Jeremy Orlow wrote: > >> On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow wrote: >> >>> On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan >> > wrote: >>> >>>> On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow wrote: >>>> >>>>> Is there any data (or any way to collect the data) on how much of the >>>>> web IE and Chrome's current behavior has broken? Given that there hasn't >>>>> been panic in the streets, I'm assuming approximately 0%? >>>>> >>>> >>>> We previously had a lengthy discussion about this. >>>> >>>> If a site has a cookie race that causes a problem in IE/Chrome one in >>>> every 10,000 page loads, are you comfortable with that? >>>> >>> >>> I'm much more comfortable with that than the cost of a global mutex that >>> all cookies and LocalStorage share. There are other ways to come about this >>> problem (like developer tools). >>> >>> I'm pretty sure Chromium has no intention of implementing a global >>> storage mutex and putting all cookie access under it. Has anyone heard >>> anything (either way) from Microsoft? Are there any browsers moving to a >>> multi-event-loop (be it multi-threaded or multi-process) based model that >>> intend to implement this? If not, then it would seem like the spec is not >>> grounded in reality. >>> >> >> Does the silence mean that no one has any intention of implementing this? >> If so, maybe we should resign ourselves to a break in the single threaded >> illusion for cookies. This doesn't seem too outlandish considering that web >> servers working with cookies will never have such a guarantee and given that >> we have no evidence of widespread breakage with IE 8 and Chrome. >> > > IE 6 <-- it is also multi process. you can poke at wininet from any > application and change the cookies for IE. > > -darin > > > >> If we were to get rid of the storage mutex for cookie manipulation (as I >> believe we should) maybe we should re-examine it for local storage. At a >> minimum, it could be implemented as a per-origin mutex. But I feel strongly >> we should go further. Why not have an asynchronous mechanism for atomic >> updates? For example, if I wanted to write an ATM application, I would have >> to do the following: >> >> var accountDelta = /* something */; >> window.localStorage.executeAtomic(function() { >> localStorage.accountBalance = localStorage.accountBalance + >> accountDelta; >> } >> >> Alternatively, we could make it so that each statement is atomic, but that >> you have to use such a mechanism for anything more complicated. For example: >> >> localStorage.accountBalance = localStorage.accountBalance + accountDelta; >> // It's atomic, so no worries! >> var balance = localStorage.accountBalance; /* Oh no!!!! This isn't safe >> since it's implemented via multiple statements... */ >> localStorage.accountBalance = balance + accountDelta; /* ....we should >> have used localStorage.executeAtomic! */ >> >> Such ideas would definitely lighten lock contention and possibly eliminate >> the need for yieldForStorageUpdates (formerly getStorageUpdates). Another >> major bonus is that it'd allow us to expose localStorage to workers again, >> which is one of the top complaints I've gotten when talking to web >> developers about localStorage. >> >> I know this is radical stuff, but the way things are speced currently just >> are not practical. >> >> J >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From snej at google.com Wed Sep 2 10:46:25 2009 From: snej at google.com (Jens Alfke) Date: Wed, 2 Sep 2009 10:46:25 -0700 Subject: [whatwg] Proposal for local-storage file management In-Reply-To: References: <71781F55-D905-4E10-99A2-BF11CFB4C996@google.com> Message-ID: <783AF4F5-A117-46A6-AFF6-FF340D2A16C3@google.com> On Sep 1, 2009, at 6:35 PM, Ian Hickson wrote: > Right now this can be done by the site directly. You mean a download link I can click? Sure, but then the site has no ability to access that data later unless I explicitly locate the file and upload it. That's not the same thing as a storage area it can access. In case it wasn't clear: In my example, the thing you're saving isn't a document file (like an SVG or PDF or whatever) but the actual local storage database for the site. Once that's been created, the site can continue to use it. > Also, we'd have to keep providing persistent storage without user > input, > so that the site can store preferences or the like without prompting > the > user (just like cookies today). Yes, I think it's unavoidable that there be two tiers of local storage, a small one that doesn't require permission and is equivalent to a cookie, and a larger one that does need permission. That's what a lot of the discussion here has been about. >> I go through my Web Documents folder, see the old >> "SooperAnimator.com Data" file, and trash it to save disk space. > You can do that today with cookies, which local storage is supposed > to be > exposed as in the UI. Do users ever look through their old cookies? You can't store 50MB of data in a cookie. I'm talking about the entire local storage of a site here, not a 40-byte session ID or something. ?Jens From snej at google.com Wed Sep 2 11:08:43 2009 From: snej at google.com (Jens Alfke) Date: Wed, 2 Sep 2009 11:08:43 -0700 Subject: [whatwg] Web Storage: apparent contradiction in spec In-Reply-To: References: <4A96A2EC.1040206@graffitiweb.org> <3726d1bf0908271753j73f4c4a0mb677e8557a2051a8@mail.gmail.com> <797AEAB3-8F87-46EB-B3E9-3B60FA1F2626@google.com> <5dd9e5c50908311112r385bed54l8bdb732d908012df@mail.gmail.com> <015AFBD2-5451-48FE-B8C3-30BEC2F15423@google.com> <5FDBCCB2-469C-499E-B88D-11B384CA26B5@google.com> Message-ID: On Aug 31, 2009, at 12:04 PM, Peter Kasting wrote: > If you combine that statement with section 6.1's "User agents should > present the persistent storage feature to the user in a way that > does not distinguish them from HTTP session cookies", then the > result is that, when the user requests to delete cookies from a > site, the UA will also delete that site's local storage. That is > exactly the behavior I am concerned about. > > That's not true. You're misinterpreting a statement about the > granularity of control users should have as one about what > terminology a UA should use. The [lack of] granularity of control actually is a serious concern, whatever the terminology. > The spec already recommends a bunch of things about what users > should be shown w.r.t. Local Storage, such as how much space a site > is using, so it's clear that a UA that wants to comply with this > "should" is going to need to construct UI that doesn't just use the > word "cookies" everywhere but actually presents the data as "here's > your locally stored data for this site" with local storage content > enumerated. Users won't be given a prompt that says "clear cookies" > that, confusingly, clears more than cookies; they'll be given a > prompt like "clear all locally stored data". The command will have to say something about cookies or it'll confuse anyone but an HTML5 expert. It'd have to be more like "Clear cookies and other locally stored data". The fundamental problem here is that some uses of local storage are nothing at all like cookies, for the same reason that ~/Documents is not the same as ~/Library/Caches. In the example I gave, the user needs to delete cookies for a site, but absolutely should not delete local storage. For the spec to tell browser developers to present the two as being the same thing makes no sense here. ?Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkasting at google.com Wed Sep 2 11:36:43 2009 From: pkasting at google.com (Peter Kasting) Date: Wed, 2 Sep 2009 11:36:43 -0700 Subject: [whatwg] Web Storage: apparent contradiction in spec In-Reply-To: References: <4A96A2EC.1040206@graffitiweb.org> <797AEAB3-8F87-46EB-B3E9-3B60FA1F2626@google.com> <5dd9e5c50908311112r385bed54l8bdb732d908012df@mail.gmail.com> <015AFBD2-5451-48FE-B8C3-30BEC2F15423@google.com> <5FDBCCB2-469C-499E-B88D-11B384CA26B5@google.com>

Message-ID: On Wed, Sep 2, 2009 at 11:08 AM, Jens Alfke wrote: > On Aug 31, 2009, at 12:04 PM, Peter Kasting wrote: > > If you combine that statement with section 6.1's "User agents should >> present the persistent storage feature to the user in a way that does not >> distinguish them from HTTP session cookies", then the result is that, when >> the user requests to delete cookies from a site, the UA will also delete >> that site's local storage. That is *exactly* the behavior I am concerned >> about. >> > > That's not true. You're misinterpreting a statement about the granularity > of control users should have as one about what terminology a UA should use. > > > > The [lack of] granularity of control actually is a serious concern, > whatever the terminology. > It still seems like you are interpreting this statement as saying that the UA must not allow users to keep/clear cookies separately from Local Storage data. While on the face of it that seems like a possible interpretation, I think it's clear that this would be a lousy user experience and detrimental to developers as well. Therefore I am convinced that the intent of the statement is to say that UAs must give users the same _abilities_ to see and clear Local Storage data as they already have with cookies, not that the two things should always be lumped together and made indistinguishable. Of course, Hixie could step in here and clarify what he means. But if he really means what you think he means (that users must not be able to tell a difference or control the two separately) then that seems like obvious grounds for a revolt. > The spec already recommends a bunch of things about what users should be > shown w.r.t. Local Storage, such as how much space a site is using, so it's > clear that a UA that wants to comply with this "should" is going to need to > construct UI that doesn't just use the word "cookies" everywhere but > actually presents the data as "here's your locally stored data for this > site" with local storage content enumerated. Users won't be given a prompt > that says "clear cookies" that, confusingly, clears more than cookies; > they'll be given a prompt like "clear all locally stored data". > > > The command will have to say something about cookies or it'll confuse > anyone but an HTML5 expert. It'd have to be more like "Clear cookies and > other locally stored data". > In general UAs should have separate checkboxes for these on their "clear private data" UIs. The fundamental problem here is that *some uses of local storage are nothing > at all like cookies*, for the same reason that ~/Documents is not the same > as ~/Library/Caches. > Yes, this is precisely why UAs should present them separately. In the example I gave, the user needs to delete cookies for a site, but > absolutely should not delete local storage. For the spec to tell browser > developers to present the two as being the same thing makes no sense here. > See comment above. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: From snej at google.com Wed Sep 2 12:50:15 2009 From: snej at google.com (Jens Alfke) Date: Wed, 2 Sep 2009 12:50:15 -0700 Subject: [whatwg] Web Storage: apparent contradiction in spec In-Reply-To: References: <4A96A2EC.1040206@graffitiweb.org> <797AEAB3-8F87-46EB-B3E9-3B60FA1F2626@google.com> <5dd9e5c50908311112r385bed54l8bdb732d908012df@mail.gmail.com> <015AFBD2-5451-48FE-B8C3-30BEC2F15423@google.com> <5FDBCCB2-469C-499E-B88D-11B384CA26B5@google.com>

Message-ID: <55C62939-3EFC-473E-B260-A8F2F5E924B9@google.com> On Sep 2, 2009, at 11:36 AM, Peter Kasting wrote: > It still seems like you are interpreting this statement as saying > that the UA must not allow users to keep/clear cookies separately > from Local Storage data. Yes; that seemed the most direct interpretation of its language. > While on the face of it that seems like a possible interpretation, I > think it's clear that this would be a lousy user experience and > detrimental to developers as well. Therefore I am convinced that > the intent of the statement is to say that UAs must give users the > same _abilities_ to see and clear Local Storage data as they already > have with cookies, not that the two things should always be lumped > together and made indistinguishable. Then we are in violent agreement :) Good. As a newbie here I was less inclined to give the spec the benefit of the doubt than you were. So do the rest of us agree about what the statement should mean? And if so, how could it be rephrased to say that more unambiguously? I think Peter's quote above is a good start. ?Jens From dpranke at chromium.org Wed Sep 2 13:26:53 2009 From: dpranke at chromium.org (Dirk Pranke) Date: Wed, 2 Sep 2009 13:26:53 -0700 Subject: [whatwg] textarea semantics for wrap, readonly, and disabled Message-ID: <3726d1bf0909021326s726855c9r76b9ef826ec7dcdf@mail.gmail.com> Hi all, In testing various combinations of attributes on textareas, I've found a couple of inconsistencies and some vagueness in the spec. 1) The wrap="hard" attribute appears to be defined such that you get hard line breaks at the specified character width of the element, but the semantics of the wrap="soft" attribute are not defined. And, in admittedly limited testing, WebKit, Gecko, and Trident all treated soft as if it was hard. Opera 10 seems to treat hard as if it was soft, meaning that it does not force linebreaks at the specified character width, and content overflowed (without a scroll bar being displayed). What are the semantics of wrap="soft" supposed to be? 2) wrap="off" does not appear to be a legitimate value, despite being implemented in all the major browsers. Is this an oversight, or an intentional omission? 2) If the textarea is specified as "disabled", but the text overflows the alloted size, should the scrollbars be enabled so you can scroll to see the content, or should the scrollbars be disabled (preventing the user from seeing the content)? Thanks! -- Dirk From jackalmage at gmail.com Wed Sep 2 13:33:20 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 2 Sep 2009 15:33:20 -0500 Subject: [whatwg] textarea semantics for wrap, readonly, and disabled In-Reply-To: <3726d1bf0909021326s726855c9r76b9ef826ec7dcdf@mail.gmail.com> References: <3726d1bf0909021326s726855c9r76b9ef826ec7dcdf@mail.gmail.com> Message-ID: On Wed, Sep 2, 2009 at 3:26 PM, Dirk Pranke wrote: > 2) wrap="off" does not appear to be a legitimate value, despite being > implemented in all the major browsers. Is this an oversight, or an > intentional omission? This value is specified down in the rendering section, as it doesn't have any effect on the semantics (it's equivalent to 'soft', just with a different display). ~TJ From dpranke at chromium.org Wed Sep 2 14:16:24 2009 From: dpranke at chromium.org (Dirk Pranke) Date: Wed, 2 Sep 2009 14:16:24 -0700 Subject: [whatwg] textarea semantics for wrap, readonly, and disabled In-Reply-To: References: <3726d1bf0909021326s726855c9r76b9ef826ec7dcdf@mail.gmail.com> Message-ID: <3726d1bf0909021416w56681b8cq863e949b9befc0db@mail.gmail.com> On Wed, Sep 2, 2009 at 1:33 PM, Tab Atkins Jr. wrote: > On Wed, Sep 2, 2009 at 3:26 PM, Dirk Pranke wrote: >> 2) wrap="off" does not appear to be a legitimate value, despite being >> implemented in all the major browsers. Is this an oversight, or an >> intentional omission? > > This value is specified down in the rendering section, as it doesn't > have any effect on the semantics (it's equivalent to 'soft', just with > a different display). > Ah, in 11.4.15. It seems like it would be useful to note that as a historical value in 4.10.10, or perhaps somewhere else like the obsolete section? I guess that actually half-answers my other question, which is that the soft wrapping will change the rendered output, but not the value of the element, whereas hard wrapping also changes the value of the element. On the flip side, should 11.4.15 specify anything about wrapping algorithms of soft vs. hard, or is that completely implementation defined (including handling of overflow with scrollbars, etc.)? From daveburke at google.com Wed Sep 2 14:26:15 2009 From: daveburke at google.com (Dave Burke) Date: Wed, 2 Sep 2009 22:26:15 +0100 Subject: [whatwg] Orientation event in Firefox In-Reply-To: <7D8FF9B9-0E90-41E2-AC0C-39EB9E9A2A02@gmail.com> References: <73B30FF3-0C50-48F9-BADC-63C609B92221@gmail.com> <6e608abf0908311454p78b0017ag45814796752e3d2a@mail.gmail.com> <7D8FF9B9-0E90-41E2-AC0C-39EB9E9A2A02@gmail.com> Message-ID: <6e608abf0909021426jeb1ac79s3603c4d6575a6f61@mail.gmail.com> On Mon, Aug 31, 2009 at 11:06 PM, Doug Turner wrote: > Thanks Dave for your comments. > I was thinking about update frequency. right now, it is up to the UA (we > are using 50ms). > To give an explicit example, if you want to run a high pass (say to detect only sudden movements), you might code a simple k-order FIR filter of the form: y[n] = b0.x[n] + b1.x[n-1] + ... + bk.x[n-k] The coefficient values b0 ... bk are a function of the sampling rate ("update frequency") and hence needs to be settable or at least known to allow code portability. > units -- yes. in g. This is best. > > magnetometer -- but in a different API, right? I do not see directly how > you would combined the two. > It's a different API, but (can be) closely related. You can present magnetometer information either as x, y, z of the magnetic field vector or as the special case of compass orientation. For example, Android has the same SensorEventfor both Sensor.TYPE_ACCELEROMETER and Sensor.TYPE_MAGNETIC_FIELD. Lots of interesting use-cases for compass ranging from map tile orientation, navigation, augmented reality, etc. > Also see: http://dougt.org/wordpress/2009/08/orientation-update/ for some > demos. > > Doug > > On Aug 31, 2009, at 2:54 PM, Dave Burke wrote: > > +1, I like this approach for its simplicity and familiarity. > > As part of fleshing out, there are probably a few small but key additions > that would greatly increase effectiveness: > - update frequency (knowing the sample rate is crucial for even the most > trivial DSP operations such as filtering) > - units (convention is in units of 'g', i.e 9.81 m/s^2) > - magnetometer in addition to accelerometer (for heading) > > Dave > > On Mon, Aug 24, 2009 at 4:39 AM, Doug Turner wrote: > >> I posted some thoughts and a strawman for orientation in Firefox: >> >> http://dougt.org/wordpress/2009/08/orientation/ >> >> Regards, >> Doug Turner >> >> >> >> >> > > > -- > > Sent from Wandsworth, Greater London, United Kingdom > > > -- Sent from Zurich, Switzerland -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Wed Sep 2 14:39:00 2009 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Sep 2009 21:39:00 +0000 (UTC) Subject: [whatwg]