edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Kevin Carhart <kevin@carhart.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [edbrowse-dev] timers and async (fwd)
Date: Fri, 6 Sep 2019 21:56:06 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.1909062136480.77350@phoenix> (raw)


I think it's a good idea.

> So it would be nice to *know* if async scripts can run after the page is
> loaded, and after the onload code, but I don't even know how to ask the
> question.

Me too.  And extraneous is a subjective matter, right?  I don't think it 
would be discernible from static analysis.  Although, what if you 
differentiated based on whether it addresses the domain that you are 
loading, or an outside domain?  It wouldn't be 100% correct though, 
because sites can load libraries by just giving an href to the library 
website.  So doubleclick.com would be discernible as external, but 
jquery.com would look external too.

I also have a wacky idea.  Since we don't know which scripts must run 
early, group them based on a random draw.  Not by default, but as an enableable 
so it won't bother anyone unless they set it. 
So the user puts this setting on and the scripts are marked "must run 
early" or "can run later".  Then the page loads based on that.  From the user's 
perspective, they either got faster access to page contents, or they 
didn't.  If they didn't, they are no worse off.  If they did, they can 
find out what the draw happened to be, like 1,3,6, mandatory and 2,4,5 
discretionary.  And that grouping could become an ebrc setting for next 
time so that they can continue having early access to page contents.   It 
would be a form of learning through working backwards.  The thing that 
might make this work is that there tend to be a fairly small number of 
scripts most of the time.   Thus ends my wacky ideas for now..



                 reply	other threads:[~2019-09-07  4:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1909062136480.77350@phoenix \
    --to=kevin@carhart.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).