stop FOUC

[stevefaulkner]

when respec loads doc often there is a flash of unstyled content, would be nice if it did not occur

[marcoscaceres]

So, there are a number of challenges:

1. The script tag that loads ReSpec is generally set to run async - this can only be fixed by Editors.
2. the style module runs at the turn of the event loop and hence after first paint.
3. Even when the async attr is removed from the script tag, 2 still occurs (this might be the fault of require.js, but I'm not sure).

My solution would be to only use the style module if document is running async. Otherwise, add the following to profile-w3c-common.js - using a MutationObserver, it watches for when the respecConfig is added to the document - then figures out which style to use based on the respecConfig, and immediately adds it to the head of the document. It, of course, requires that the script be running sync:

var sync = (document.currentScript && !document.currentScript.async) || false;
if(sync){ 
    //if we have mutation observer support
    if (window.MutationObserver && !window.respecConfig) {
        var observer = new MutationObserver(function(mutation) {
            if (window.respecConfig) {
                observer.disconnect();
                addStyle(window.respecConfig);
            }
        });
        observer.observe(document.head, {
            childList: true
        });
    } else if (window.respecConfig) {
        addStyle(window.respecConfig);
    }
}
//add the style - basically the same as w3c/style module
function addStyle(conf) {
   ...
}

The other option is for Editors to just include a link element to TR/base css or to the style sheet for their spec.

[halindrome]

Since for some documents the initial load can take a very long time, I
would almost rather have the option of a 'loading' throbber that would
appear so that as all the churn happens people are not attempting to
navigate the document. It is very frustrating to have the document shift
around while scrolling.

On Sat, Jul 26, 2014 at 11:59 PM, Marcos Caceres notifications@github.com
wrote:

So, there are a number of challenges:

1. The script tag that loads ReSpec is generally set to run async -
   this can only be fixed by Editors.
2. the style module runs at the turn of the event loop and hence after
   first paint.
3. Even when the async attr is removed from the script tag, 2 still
   occurs (this might be the fault of require.js, but I'm not sure).

My solution would be to only use the style module if document is running
async. Otherwise, add the following to profile-w3c-common.js - using a
MutationObserver, it watches for when the respecConfig is added to the
document - then figures out which style to use based on the respecConfig,
and immediately adds it to the head of the document. It, of course,
requires that the script be running sync:

var sync = (document.currentScript && !document.currentScript.async) || false;if(sync){
//if we have mutation observer support
if (window.MutationObserver && !window.respecConfig) {
var observer = new MutationObserver(function(mutation) {
if (window.respecConfig) {
observer.disconnect();
addStyle(window.respecConfig);
}
});
observer.observe(document.head, {
childList: true
});
} else if (window.respecConfig) {
addStyle(window.respecConfig);
}}//add the style - basically the same as w3c/style modulefunction addStyle(conf) {
...}

The other option is for Editors to just include a link element to TR/base
css or to the style sheet for their spec.

—
Reply to this email directly or view it on GitHub
https://github.com/darobin/respec/issues/326#issuecomment-50256002.

Shane McCarron
halindrome@gmail.com

[marcoscaceres]

I think that's a related but different problem. Ideally, we just want to
fix that FOUCking problem (hehe, sorry not sorry) :) even with a loading
indicator, you would still have the flash as Respec is coded today. Need to
look a bit more at what the DOMReady script is doing.

On Sunday, July 27, 2014, Shane McCarron notifications@github.com wrote:

Since for some documents the initial load can take a very long time, I
would almost rather have the option of a 'loading' throbber that would
appear so that as all the churn happens people are not attempting to
navigate the document. It is very frustrating to have the document shift
around while scrolling.

On Sat, Jul 26, 2014 at 11:59 PM, Marcos Caceres <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

So, there are a number of challenges:

1. The script tag that loads ReSpec is generally set to run async -
   this can only be fixed by Editors.
2. the style module runs at the turn of the event loop and hence after
   first paint.
3. Even when the async attr is removed from the script tag, 2 still
   occurs (this might be the fault of require.js, but I'm not sure).

My solution would be to only use the style module if document is running
async. Otherwise, add the following to profile-w3c-common.js - using a
MutationObserver, it watches for when the respecConfig is added to the
document - then figures out which style to use based on the
respecConfig,
and immediately adds it to the head of the document. It, of course,
requires that the script be running sync:

var sync = (document.currentScript && !document.currentScript.async) ||
false;if(sync){
//if we have mutation observer support
if (window.MutationObserver && !window.respecConfig) {
var observer = new MutationObserver(function(mutation) {
if (window.respecConfig) {
observer.disconnect();
addStyle(window.respecConfig);
}
});
observer.observe(document.head, {
childList: true
});
} else if (window.respecConfig) {
addStyle(window.respecConfig);
}}//add the style - basically the same as w3c/style modulefunction
addStyle(conf) {
...}

The other option is for Editors to just include a link element to
TR/base
css or to the style sheet for their spec.

—
Reply to this email directly or view it on GitHub
https://github.com/darobin/respec/issues/326#issuecomment-50256002.

Shane McCarron
halindrome@gmail.com
javascript:_e(%7B%7D,'cvml','halindrome@gmail.com');

—
Reply to this email directly or view it on GitHub
https://github.com/darobin/respec/issues/326#issuecomment-50277145.

[marcoscaceres]

Note to future @marcoscaceres: if you combine all the styles into a single element, and insert it into the document on end-all, that will reduce the number of style recalculations significantly. Also, you should not insert styles that are not needed (e.g., if there is not WebIDL in the spec, then don't include the WebIDL styles... dummy). If we can move more stuff to base.css, then that is also a huge win.

[halindrome]

FWIW if there are easy ways to just rely on what is ALREADY in base.css that would be a huge win too. In that we would have more consistency within and among specs. Right @fantasai ?

[marcoscaceres]

On 27 Jun 2016, at 10:10 PM, Shane McCarron notifications@github.com wrote:

FWIW if there are easy ways to just rely on what is ALREADY in base.css that would be a huge win too. In that we would have more consistency within and among specs. Right @fantasai ?

We need to actually dig into ReSpec's style sheet and see what duplication there is. Base.css is unlikely to ever give us good syntax highlighting tho because we (ReSpec and BS) depend on different tools... But who knows.

Maybe we can get consistent notes, warnings, tables, etc. Those are the low hanging fruits.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[fantasai]

base.css intentionally doesn't include syntax highlighting rules. Definitely should be relying on it for styling tables, etc. -- anything documented in http://fantasai.inkedblade.net/style/design/w3c-restyle/2016/sample really.

[marcoscaceres]

@fantasai, unrelated... but tables are still super broken :(