scroll-to can happen BEFORE respec is really done

[halindrome]

Currently one of the last things ReSpec does is look at the request URI for a fragment identified. If there is one, then it attempts to position the view of the user agent at that location.

The problem arises of a spec subscribes to the end-all event. Since the scroll handing happens BEFORE end-all, any modifications to the document during end-all processing will be missed!

In a separate branch I have added an event that happens even AFTER end-all. This is just to handle aria-busy. My proposal is that we change the scroll handling to be an event handler that subscribes to the new event and it does the scrolling when that happens. Should solve the problem.

[halindrome]

ALSO, the scrolling can happen before data-include loads are complete if data-include-sync is not specified. We should track async data-includes and only attempt the scrolling once all of those have actually finished.

[patrickhlauke]

The most aggravating part seems to be that for some reason, using Chrome, if the scrolling happened before everything was finished (meaning that the final scroll position does not match the fragment identifier), hitting ENTER in the url bar again does not then jump to the right place, but seems to actually reload the page (which then does the wrong scrolling again). tl;dr: in Chrome, any url with a fragment identifier is borked completely.

[simevidas]

I have actually proposed an intervention in Chrome (see here) to fix this issue, unaware that it’s an issue with ReSpec.

Being able to link to specific sections in W3C specs is an essential functionality — reading specs is “hard enough” even without them loading at a random position completely unrelated to the URL’s fragment; think of how many developers we’re “losing” because they were either confused or too annoyed to find the correct section — so it’s worth prioritizing (and hotfixing) this issue, I think.

[marcoscaceres]

I agree. I'm sick of the FOUC and this issue. I'm going to bump them up the priority list. Also, we need help people stop publishing ReSpec source docs and set up auto publish.

Sent from my iPhone

On 26 Apr 2016, at 11:37 AM, Šime Vidas notifications@github.com wrote:

I have actually proposed an intervention in Chrome (see here) to fix this issue, unaware that it’s an issue with ReSpec.

Being able to link to specific sections in W3C specs is an essential functionality — reading specs is “hard enough” without having them load at a random position completely unrelated to the URLs fragment — so it’s worth prioritizing (and hotfixing) this issue, I think.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[halindrome]

Yes - auto-publish. ReSpec source should not be viewed by real people.
It's for development.

On Mon, Apr 25, 2016 at 9:04 PM, Marcos Cáceres notifications@github.com
wrote:

I agree. I'm sick of the FOUC and this issue. I'm going to bump them up
the priority list. Also, we need help people stop publishing ReSpec source
docs and set up auto publish.

Sent from my iPhone

On 26 Apr 2016, at 11:37 AM, Šime Vidas notifications@github.com
wrote:

I have actually proposed an intervention in Chrome (see here) to fix
this issue, unaware that it’s an issue with ReSpec.

Being able to link to specific sections in W3C specs is an essential
functionality — reading specs is “hard enough” without having them load at
a random position completely unrelated to the URLs fragment — so it’s worth
prioritizing (and hotfixing) this issue, I think.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly or view it on GitHub

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#452 (comment)

Shane McCarron
halindrome@gmail.com

[marcoscaceres]

Yes - auto-publish. ReSpec source should not be viewed by real people. It's for development.

So, computers are not going to help here. We will need to go out to individual specs and help them move off github pages.

[halindrome]

By providing an out-of-the-box solution that helps generate static versions
to the gh-pages branch whenever the master is updated or something, using
travis? 'cause that would be super handy.

On Mon, Apr 25, 2016 at 9:53 PM, Marcos Cáceres notifications@github.com
wrote:

Yes - auto-publish. ReSpec source should not be viewed by real people.
It's for development.

So, computers are not going to help here. We will need to go out to
individual specs and help them move off github pages.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#452 (comment)

Shane McCarron
halindrome@gmail.com

[marcoscaceres]

By providing an out-of-the-box solution that helps generate static versions to the gh-pages branch whenever the master is updated or something, using travis? 'cause that would be super handy.

Better would be Echidna integration. There is no need to have a gh-pages branch at all for anything apart from "unofficial" drafts.

[halindrome]

That's only true for w3c specs. Others use this tool.
On Apr 25, 2016 10:56 PM, "Marcos Cáceres" notifications@github.com wrote:

By providing an out-of-the-box solution that helps generate static
versions to the gh-pages branch whenever the master is updated or
something, using travis? 'cause that would be super handy.

Better would be Echidna integration. There is no need to have a gh-pages
branch at all for anything apart from "unofficial" drafts.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#452 (comment)

[halindrome]

Actually - I have derailed this issue. Sorry! Now that we have a promise wrapper available in ReSpec, can't we actually just fix this by doing the final positioning after ReSpec (and anything ReSpec ends up calling) is done?