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).