Forum for discussion of W3C Specifications production issues

Sandro Hawke | 9 May 2012 17:21

respec question: not losing place during reload

It's a little annoying use respec that when I edit in emacs, save, and
reload in firefox, I then have to scroll all the way through the
document to where I was to see the change.  If I'm not using respec,
then reload in firefox keeps me where I am, and I can see the change
right away.  Does anyone know a way to avoid or workaround this problem?

Also, while I'm thinking about it, has anyone figured out how to run
respec in a batch/command-line mode?    (I could actually use that as a
workaround, since firefox wouldn't be dealing with respec in that mode.)

    -- Sandro

headers

Robin Berjon | 15 May 2012 21:45

Re: respec question: not losing place during reload

Hi Sandro,

On May 9, 2012, at 17:21 , Sandro Hawke wrote:
> It's a little annoying use respec that when I edit in emacs, save, and
> reload in firefox, I then have to scroll all the way through the
> document to where I was to see the change.  If I'm not using respec,
> then reload in firefox keeps me where I am, and I can see the change
> right away.  Does anyone know a way to avoid or workaround this problem?

Yes, it's a known problem, I will file a bug about it, and I think I can fix it. What's happening is that you're
using auto-generated IDs for sections (which some people consider bad practice, but RS lets you choose)
and the browser tries to find the anchor before the ID has been generated. The fix is to detect that at the end
of processing, and scroll the page to that ID. I'll file a bug for it after I'm off the plane and hope to add a
fix soon. I have a bunch of fixes to work on and ought to get around to several hopefully next week.

In the meantime, the dirty workaround that works for me is to hit reload, and once it's done hit Cmd-L (or
whatever focuses the address bar) and enter. At least in Firefox that does not cause the document to load
again but rather it looks for the anchor anew and finds it. Not ideal, but better than scrolling down.

> Also, while I'm thinking about it, has anyone figured out how to run
> respec in a batch/command-line mode?    (I could actually use that as a
> workaround, since firefox wouldn't be dealing with respec in that mode.)

I have an absolutely horrendous PhantomJS script that I use to do that in order to generate the static W3C
course that I wrote. It only works with RSv2 (though I suspect it could be adapted to v1) and it essentially
detects when a specific debugging console message is sent in order to get the generated content. It
randomly fails on what looks like a PhantomJS race condition and it features comments like "I have no idea
why, but this is required for things to work". I have to further warn you that code written for PhantomJS is
overall strange. The callback to page.evaluate() looks like it's in the same context as the rest of the JS
but it actually gets run in the page, variables being only shared in some ways, and the returned data

(Continue reading)

headers

Sandro Hawke | 20 May 2012 13:05

Re: respec question: not losing place during reload

On Tue, 2012-05-15 at 21:45 +0200, Robin Berjon wrote:
> Hi Sandro,
> 
> On May 9, 2012, at 17:21 , Sandro Hawke wrote:
> > It's a little annoying use respec that when I edit in emacs, save, and
> > reload in firefox, I then have to scroll all the way through the
> > document to where I was to see the change.  If I'm not using respec,
> > then reload in firefox keeps me where I am, and I can see the change
> > right away.  Does anyone know a way to avoid or workaround this problem?
> 
> Yes, it's a known problem, I will file a bug about it, and I think I can fix it. What's happening is that you're
using auto-generated IDs for sections (which some people consider bad practice, but RS lets you choose)
and the browser tries to find the anchor before the ID has been generated. The fix is to detect that at the end
of processing, and scroll the page to that ID. I'll file a bug for it after I'm off the plane and hope to add a
fix soon. I have a bunch of fixes to work on and ought to get around to several hopefully next week.
> 
> In the meantime, the dirty workaround that works for me is to hit reload, and once it's done hit Cmd-L (or
whatever focuses the address bar) and enter. At least in Firefox that does not cause the document to load
again but rather it looks for the anchor anew and finds it. Not ideal, but better than scrolling down.

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.

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

(Continue reading)

headers

Robin Berjon | 24 May 2012 16:30

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

(Continue reading)