Re: respec question: not losing place during reload

On May 20, 2012, at 13:05 , Sandro Hawke wrote:
> Since posting the my email, I did discover this workaround, but that's
> actually not the problem I was reporting.  Before discovering this
> workaround, I wasn't using fragment URLs.   My spec was fairly small, so
> I was scrolling to the point I cared about, not using the TOC.   That
> scrolling point is lost during reload in respect, but not lost during
> reload of a normal html document.

Ah, gotcha. I don't know how much can be done about that, but I'll see what I can do. Note that it's not a problem that I'm seeing right now when reloading in Firefox 12 or Opera 11, but do see in Chrome 20 and Safari 5. I reckon you file a bug against those :)

> I imagine the workaround there might be to have respec do the reload
> instead of the browser doing it, or something like that.  

I'm pretty sure that that won't work. I might be able to squirrel you last scroll position into a cookie and use that to return you to the same position but I'm not sure about that.

> Meanwhile, Robin, someone else in a different thread asked about ReSpec2
> which reminds me I'm quite confused about the status of ReSpec.

Hopefully things are clearer now :)

> How open for serious patches are you?   I'm starting to use it a lot and
> starting to be a decent js coder.  How should I approach the growing
> design to make non-trivial changes?   

I've always been open to serious patches, in fact large parts of ReSpec I had no part in creating. The best way to do that is to fork the GH project and make pull requests. For run-of-the-mill bug fixes just go ahead and hack. For major features, it's probably better if we talk about it first (here) so that we can avoid duplicated work and after-the-fact disagreement.

One of the cool things with the new design is that if there is no consensus on a given feature it doesn't matter :) You can create a separate module and include it from a separate profile and everyone's happy.

> Hmm.  Doesn't sound so promising.  Maybe I'll try to approach it using
> node.js.   

I've thought about trying to use https://github.com/aredridel/html5 (or perhaps just https://github.com/tmpvar/jsdom) but haven't experimented with it yet. If you have the spare cycles it's worth a shot.

Note that there's a useful new feature in the latest release: there's a pubsub mechanism that gets notified with an "end-all" event when all processing has terminated (including all async operations), and also dispatches all those events to the parent page if the spec is included in an iframe (the reverse will also become possible so that specs can be controlled from the outside). This means that any batch tool can now know at what point it is safe to generate the HTML snapshot.

> Another way to approach the whole thing is to have a "publish" command
> which saves the pre- *and* post- transform HTML to a site which makes
> drafts available for review.

It would be very simple to post the generated HTML to a service. If there's something like that, I'd be happy to use it.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 24 May 2012 14:31:03 UTC