On Wednesday, October 3, 2012 6:50 PM, Jonas Sicking wrote: >On Wed, Oct 3, 2012 at 9:48 AM, Joshua Bell <jsb...@chromium.org> wrote: >> On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal <odi...@opera.com> wrote: >>> >>> So, at work and with the spec in front of me :-) >>> >>> >>> Odin claimed: >>> >>>> There is a note near the algorithm saying something to that point, >>>> but the definite text is up in the prose "let's explain IDB" section IIRC. >>> >>> >>> Nope, this was wrong, it's actually right there in the algorithm: >>> >>> >>> <http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps >>> -for-iterating-a-cursor> >>> >>> # If direction is "prevunique", let temp record be the last record in >>> # records which satisfy all of the following requirements: >>> # >>> # If key is defined, the record's key is less than or equal to key. >>> # If position is defined, the record's key is less than position. >>> # If range is defined, the record's key is in range. >>> # >>> # If temp record is defined, let found record be the first record in >>> # records whose key is equal to temp record's key >>> >>> So it'll find the last "foo", and then, as the last step, it'll find >>> the top result for "foo", giving id 1, not 3. The prevunique is the >>> only algo that uses that temporary record to do its search. >>> >>> I remember this text was somewhat different before, I think someone >>> clarified it at some point. At least it seems much clearer to me now >>> than it did the first time. >> >> >> Since I have it the link handy - discussed/resolved at: >> >> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.htm >> l >> >>> >>> Israel Hilerio said: >>>> >>>> Since we're seeing this behavior in both browsers (FF and Canary) we >>>> wanted to validate that this is not by design. >>> >>> >>> It would bet several pennies its by design, because the spec needs >>> more framework to explain this than it would've needed otherwise. >>> What that exact design was (rationale et al) I don't know, it was >>> before my time I guess. :-) >> >> >> Yes, the behavior in Chrome is by design to match list consensus. >> >> (FWIW, it's extra code to handle this case, and we've had bug reports >> where we had to point at the spec to explain that we're actually >> following it, but presumably this is one of those cases where someone >> will be confused by the results regardless of which approach was >> taken.) > >Yes, this was very intentional. The goal was that reverse iteration would >always return the same set of rows as forward iteration, just in reverse >order. This seemed like the most easily understandable and >explainable >behavior. > >Consider for example a UI which renders an address book grouped by first >letter and showing the first name in that letter. It would seem strange if the >user changing z-a or a-z shows different names. > >/ Jonas
Thanks everyone for the explanations. Jonas, your last example clarified things for me. We'll file a bug on our side. Israel
