Re: [docbook-apps] [WebHelp] Incorrect initial scroll to anchor in Chrome

[David Cramer <david@thingbag.net>]

On 10/27/14, 1:04 PM, Jan Tosovsky wrote:
...
> While target offset is -195 in FF, it is 2200 in Chrome. The required anchor
> is not scrolled precisely to its location, but ca 300 px towards the bottom.
> However, on page reload it is sometimes correct, sometimes more or less than
> the initial value. This inconsistency is really weird.
> 
> I've found several threads mentioning incorrect Chrome behaviour when
> determining offset top value on StackOverflow, but it is not very clear to
> me if this is our case.
> 
> Has anybody any experience with this or fix?

As you've noticed, that code is trying to compensate for the fact that
there's a fixed header and links to anchors in a page would otherwise
appear under the fixed header (i.e. at the top of the window). I've
recently come across a better solution to that problem that uses only
css. It goes something like this (assuming you're linking to <a/> tags
and assuming a header-height of 195px):

  a:before {
      display: block;
      content: " ";
      margin-top: -195px;
      height: 195px;
      visibility: hidden;
      z-index: -1;
    }

Adjust the selector as needed if the links are to div tags or whatever.
In the case of the DocBook xslts, I think a and div tags that have id
attributes would be the right things to add this rule to.

This strategy is much easier to maintain if you're using sass/scss
because you can use variables, defining $header-height in one place and
then reusing it to define the height of the header and the offests in
rules like this.

My suggestion would be to rip out the javascript and move to a solution
like this.

Regards,
David