W3C home > Mailing lists > Public > spec-prod@w3.org > April to June 2012

Re: respec question: not losing place during reload

From: Sandro Hawke <sandro@w3.org>
Date: Sun, 20 May 2012 07:05:30 -0400
To: Robin Berjon <robin@berjon.com>
Cc: spec-prod@w3.org
Message-ID: <1337511930.2272.28.camel@waldron>
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.  

Meanwhile, Robin, someone else in a different thread asked about ReSpec2
which reminds me I'm quite confused about the status of ReSpec.  I have
no idea which version is the latest, best, recommended, or what.   Can
we update http://dev.w3.org/2009/dap/ReSpec.js/documentation.html and
https://dvcs.w3.org/hg/respec2 and
http://respec.specifiction.com/guide/basic-layout.html to all tell the
same story?

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?   

> > 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 structure being very limited (for your purposes you'll need to get the generated HTML from inside evaluate() and return it to write it to disk).
> 
> Anyway, you have been warned. I'm attaching said script, but if you use/adapt it you agree to forfeit all rights to complain about it and are solely responsible if it happens to eat your homework, or your dog, or reopen httpRange-14, as well as for sundry near-apocalyptic and extinction-level events that may follow.

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

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.

    -- Sandro
Received on Sunday, 20 May 2012 11:05:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 20 May 2012 11:05:43 GMT