Re: respec question: not losing place during reload
Sandro Hawke <sandro <at> w3.org>
2012-05-20 11:05:30 GMT
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.