[Bug 24658] [imports]: The fetch readiness shouldn't block fetching.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24658

--- Comment #2 from Morrita Hajime <morrita@google.com> ---
Thanks for sharing your thought Gabor!

Before stepping into the detail, let me clarify the motivation behind
this "block only on <script>" idea.

Think all imports are composed in this way:

---
<html>
<head>
  <link rel=import ....>

  ... bunch of more imports ...

  <script>
  ... // main logic of the imports
  </script>
</head>
</html>
---

Assuming all imports are written in this style and we don't block on imports
(only block on <script>), we can fetch subimports as soon as we receive imports
bytestream and started parsing them. We could possibly request all requested
imports and stylesheets without blocking any. This maximizes the concurrency
and minimizes the delay.

If we block on fetching, we'll introduce delay. Even if we pre-fetch them,
waiting before parsing means we cannot see <link>s in imports to be parsed.

Although it can go as fast as non-blocking scenario with prescanning+prefetch,
it would be nice if we can make parallelism built into the spec,
instead of expecting many speculative work.

I agree that current fetch readiness criteria doesn't work well with this.
The first version of the spec was written this in mind, but then dedup made
things complicated and I once gave up the parallelism to introduce fetching
readiness.

But there are strong demand to make this fast. After all, speed is one of the
justification why we want HTML Imports.

So let's make it work somehow.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 14 February 2014 01:38:27 UTC