Hyperlink/anchor behaviour different in Safari/Chrome & FireFox

  • Resolved kintopp

    (@kintopp)


    9 years, 8 months ago

    Hi, I’m entering anchors and hyperlinks into cells of a column in my table as follows, for example:

    Row X, Column Y
    <a class="Kangxi" id="⼄"></a>

    Row X+n, Column Y
    <a href="#⼄">a variant of ⼄（おつ）</a>

    This works. However, the position to which the hyperlink takes me is differernt in FireFox 31 compared to Safari 7 / Chrome 36. When I click on the hyperlink in FireFox, the page scrolls to the row with the anchor (Row X) still visible at the very top of the page. This is the desired behavior. When I do the same in Safari/Chrome, the the page scrolls to Row X+n, specfically to the row containing the hyperlink itself and shows that at the top of the page.

    Here is a testpage demonstrating this (password=kanji). I assume I must be doing something very simple wrong. I am using the current version of TablePress (v1.4).

    https://wordpress.org/plugins/tablepress/

Viewing 15 replies - 1 through 15 (of 16 total)
1 2
  • Plugin Author TobiasBg

    (@tobiasbg)

    9 years, 8 months ago

    Hi,

    thanks for your post, and sorry for the trouble.

    I can see what you mean, but I have no idea what exactly is causing it, or how it can be fixed. It’s also not caused by TablePress directly, but seems to be an issue with Chrome.
    My assumption is that Chrome doesn’t like UTF-8 characters in the id attribute, and I found some references that state that the id attribute should only contain ASCII letters, e.g. http://www.sitepoint.com/web-foundations/id-html-attribute/

    Regards,
    Tobias

    Thread Starter kintopp

    (@kintopp)

    9 years, 8 months ago

    Hi Tobias, vielen Dank für die – wie immer – blitzschnelle Antwort (and now returning to my native language..). In an earlier version of this table it worked just fine. Here, I used name instead of id but even so, when I switch to id with this table (as in row 5, the first linked cell) it still works correctly.

    Temporary link to the old version, working correctly (also password=kanji):

    http://kanjialive.com/more-tests/

    Plugin Author TobiasBg

    (@tobiasbg)

    9 years, 8 months ago

    Hi,

    you are very welcome for the fast reply 🙂

    Indeed, it seems to work correctly with the name attribute. Then, all I can do is suggest to use that.
    TablePress is not influenced or changing this HTML code in any way, so this must be Chrome treating name and id differently in current versions.
    There’s nothing that I can do about this in TablePress, as the plugin already prints well-formed and valid HTML code.

    Regards,
    Tobias

    Thread Starter kintopp

    (@kintopp)

    9 years, 8 months ago

    No, sorry I wasn’t expressing myself clearly. I meant that it works on the old table http://kanjialive.com/more-tests/ regardless of whether I use name or id. Row 5 uses id, the others name and both work.

    Here’s one more test. The same data as in the original, problematic table (all using id) now re-created with all cells using name instead. Same problem. That’s what puzzles me..

    http://kanjialive.com/yet-more-tests/ (all using name)

    Plugin Author TobiasBg

    (@tobiasbg)

    9 years, 8 months ago

    Hi,

    ah, ok. Sorry for not understanding that correctly the first time.

    This is really weird then, but I still don’t see why this happens or how to fix it 🙁 Sorry.
    There could maybe be something else on that page that’s tripping up Chrome, or something is broken in the HTML code that you entered.
    You could maybe try shortening that table several rows at a time (using the “Hide rows” button) to see if it suddenly starts working again. This way you can maybe narrow things down until you find a row that maybe causes this.

    Regards,
    Tobias

    Thread Starter kintopp

    (@kintopp)

    9 years, 8 months ago

    Yes, good plan. I’ll try out several things and then report back when/if I find a solution.

    Plugin Author TobiasBg

    (@tobiasbg)

    9 years, 8 months ago

    Hi,

    sounds good. If there’s anything that I can help with, just let me know.

    Regards,
    Tobias

    Thread Starter kintopp

    (@kintopp)

    9 years, 8 months ago

    I believe I found the answer… In short, if there is a column to the right of the column with the anchors, then we get consistent behavior in Safari/Chrome and FireFox. If there is no column to the right of the anchor column, then the behavior diverges as explained above.

    I’ve modified the contents of the two test pages to reflect this.

    1. With a column to the right (i.e. “ok”)
    http://kanjialive.com/new-radical-table-test/

    2. Without a column to the right (i.e. “broken”)
    http://kanjialive.com/more-tests/

    Both tables use id to designate the anchor. Here is the JSON export for both tables in case you want to try and reproduce it:

    https://dl.dropboxusercontent.com/u/1667511/tablepress-export-2014-08-15-00-19-06-json.zip

    Thread Starter kintopp

    (@kintopp)

    9 years, 8 months ago

    Don’t forget to use cache_table_output=false / in the shortcode to work around this bug: https://core.trac.wordpress.org/ticket/23495

    Plugin Author TobiasBg

    (@tobiasbg)

    9 years, 8 months ago

    Hi,

    wow, that sounds really weird. That would be really strange if an extra column would change Chrome’s behavior here…

    I’ll test with your file on my test site, but besides probably being able to reproduce this, I don’t know what we could do to fix this 🙁

    Regards,
    Tobias

    Thread Starter kintopp

    (@kintopp)

    9 years, 8 months ago

    I’m going to mark this as resolved since I managed to work around (though without actually solving) the underlying problem. Also, the links to the above test pages and sample data are now defunct.

    Plugin Author TobiasBg

    (@tobiasbg)

    9 years, 8 months ago

    Hi,

    ok. I’ll experiment some more with your table (I had downloaded the JSON file already). If I happen to find something, I’ll let you know ASAP!
    Otherwise, we’ll have to add this to our list of “browser quirks”, I guess…

    Best wishes,
    Tobias

    Thread Starter kintopp

    (@kintopp)

    9 years, 8 months ago

    Seriously, please don’t worry about it. It works. That’s the main thing.

    Plugin Author TobiasBg

    (@tobiasbg)

    9 years, 8 months ago

    Hi,

    but it’s also kind of fun to dive into such issues 🙂

    Best wishes,
    Tobias

    Thread Starter kintopp

    (@kintopp)

    9 years, 8 months ago

    Ha, yes – that’s true. I do know what you mean. I’ve been grumbling over obscure CJK encoding issues for weeks and it’s a good feeling to finally straighten it all out.

    In the latest version of this table the problem is not reproducible. Previously, hiding the last column after the column with hyperlinks could trigger it. Here’s a link to the JSON export of the current version. Perhaps comparing it to the previous version which you already have will reveal something. The previous version also had some awful custom CSS but I guess it’s unlikely this would have made a difference.

    https://dl.dropboxusercontent.com/u/1667511/tablepress-export-2014-08-20-14-43-56-json.zip

    And the public version of this table can be viewed here:

    http://kanjialive.com/214-traditional-kanji-radicals/

Viewing 15 replies - 1 through 15 (of 16 total)
1 2
  • The topic ‘Hyperlink/anchor behaviour different in Safari/Chrome & FireFox’ is closed to new replies.