From 4a34e72372f443351183a952b7ff1320f1e86fcc Mon Sep 17 00:00:00 2001 From: Takayoshi Kochi Date: Fri, 12 Feb 2016 19:46:32 +0900 Subject: [PATCH 01/82] Proposed change for Focus Navigation As discussed in https://github.com/w3c/webcomponents/issues/375 This adds a clarification about focus navigation order for nodes distributed under a slot element. Also added handling tabindex="-1" case. --- spec/shadow/index.html | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/spec/shadow/index.html b/spec/shadow/index.html index 687e7130..c3f4c27c 100644 --- a/spec/shadow/index.html +++ b/spec/shadow/index.html @@ -1130,6 +1130,8 @@

Focus Navigation

The sequential focus navigation order for a given shadow tree A must be inserted into the sequential focus navigation order for the parent tree B as follows:

  1. Let HOST be the shadow host which hosts A
  2. +
  3. The sequential focus navigation order for A must be + skipped if HOST is given the tabindex value -1.
  4. The sequential focus navigation order for A must be inserted into the sequential focus navigation order for B:
      @@ -1139,6 +1141,27 @@

      Focus Navigation

    +

    Likewise, the sequential focus navigation order for distributed nodes + under a given slot A must be inserted into + the sequential focus navigation order of the containing shadow tree's + sequential focus navigation order as follows:

    +
      +
    1. The sequential focus navigation order for its distributed nodes + must be skipped if A is assigned tabindex value -1. +
    2. If A is not given tabindex, + The sequential focus navigation order for its distributed nodes + must be inserted in place of A as if A + were assigned the tabindex value 0 for determining its position.
    3. +
    4. Otherwise the sequential focus navigation order for its + distributed nodes must be inserted in place of + A according to its tabindex value.
    5. +
    +

    When a slot A is assigned to another + slot B, + the sequential focus navigation order of A's distributed nodes + is inserted into B's sequential focus navigation order following + the steps shown above.

    +

    For directional focus navigation [[!CSS3-UI]], it is up to the user agent to integrate the shadow trees into the document's directional focus navigation. From 346a477c5db518ac0300a401a90e73dceb3c1720 Mon Sep 17 00:00:00 2001 From: Hayato Ito Date: Thu, 18 Feb 2016 13:05:45 +0900 Subject: [PATCH 02/82] [Fix #277] Add loadedmetadata to the list --- spec/shadow/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/shadow/index.html b/spec/shadow/index.html index 687e7130..d31b95f1 100644 --- a/spec/shadow/index.html +++ b/spec/shadow/index.html @@ -666,7 +666,7 @@

    scoped flag

    A trusted event's scoped flag must be initialized to true - if the event is one of the following events: abort, error, select, change, load, reset, + if the event is one of the following events: abort, error, select, change, load, loadedmetadata, reset, resize, scroll and selectstart.

    From d7bf7389bd4e286b06d00183b6370b4b53e920f6 Mon Sep 17 00:00:00 2001 From: Hayato Ito Date: Thu, 18 Feb 2016 14:32:14 +0900 Subject: [PATCH 03/82] [Fix #373] Make event.deepPath() return an empty array if the event is no longer dispatched --- spec/shadow/index.html | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/spec/shadow/index.html b/spec/shadow/index.html index d31b95f1..683d0e96 100644 --- a/spec/shadow/index.html +++ b/spec/shadow/index.html @@ -1598,24 +1598,12 @@

    Extensions to Event Interface

      -
    1. If EVENT hasn't been dispatched, return a new empty array.
    2. +
    3. If EVENT hasn't been dispatched or EVENT is no longer dispatched, return a new empty array.
    4. Otherwise:
      1. Let PATH be the event path of EVENT.
      2. -
      3. - If EVENT is being dispatched: -
          -
        1. Let CURRENT-TARGET be the current target of EVENT.
        2. -
        -
      4. -
      5. - Otherwise: -
          -
        1. Let CURRENT-TARGET be the last node of PATH.
        2. -
        -
      6. -
      7. Let PATH contain only a node which is an unclosed node of CURRENT-TARGET.
      8. +
      9. Let PATH contain only a node which is an unclosed node of the current target of EVENT.
    From c9fe8bf0b48f7e896d32b739041e407551798ccb Mon Sep 17 00:00:00 2001 From: Hayato Ito Date: Thu, 18 Feb 2016 14:59:30 +0900 Subject: [PATCH 04/82] [Fix #386] Fix an editorial issue --- spec/shadow/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/shadow/index.html b/spec/shadow/index.html index 683d0e96..a8faacd9 100644 --- a/spec/shadow/index.html +++ b/spec/shadow/index.html @@ -343,7 +343,7 @@

    Slotting Algorithm

  5. Otherwise:
      -
    1. Let SLOT be the most preceding slot in TREE whose slot name is NAME if it exists. Otherwise null.
    2. +
    3. Let SLOT be the first slot element, in tree order, in TREE, whose slot name is NAME, and null if there is no such slot element otherwise.
From 315e58ab1369ed9c8c2779327df1a73796085569 Mon Sep 17 00:00:00 2001 From: Hayato Ito Date: Thu, 18 Feb 2016 15:03:11 +0900 Subject: [PATCH 05/82] Fix an editorial issue --- spec/shadow/index.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/spec/shadow/index.html b/spec/shadow/index.html index a8faacd9..274120fe 100644 --- a/spec/shadow/index.html +++ b/spec/shadow/index.html @@ -307,8 +307,7 @@

Slots

- A default slot is a slot whose slot name is the empty string or missing. - If there are more than one slots which don't have a slot name in the same component tree, the most preceding one is the default slot. The others are not. + A default slot is the first slot element, in tree order, in a component tree, whose slot name is the empty string or missing.

From ed43c0abce263c8142cf0e534d672e1e99d456c7 Mon Sep 17 00:00:00 2001 From: Takayoshi Kochi Date: Thu, 18 Feb 2016 20:02:04 +0900 Subject: [PATCH 06/82] Updated the draft. Addresses comments from hayato. --- spec/shadow/autolink-config.js | 4 +++ spec/shadow/index.html | 66 ++++++++++++++++++++++++---------- 2 files changed, 51 insertions(+), 19 deletions(-) diff --git a/spec/shadow/autolink-config.js b/spec/shadow/autolink-config.js index 5abc4b9e..62c0747c 100644 --- a/spec/shadow/autolink-config.js +++ b/spec/shadow/autolink-config.js @@ -62,11 +62,14 @@ var autolinkConfig = { 'canvas element': '#the-canvas-element', 'comma separated tokens': '#comma-separated-tokens', 'contenteditable': '#attr-contenteditable', + 'control group owner': '#control-group-owner', + 'control group': '#control-group', 'details element': '#the-details-element', 'embed element': '#the-embed-element', 'fallback content': '#fallback-content', 'fieldset element': '#the-fieldset-element', 'flow content': '#flow-content', + 'focusable area': '#focusable-area', 'focusable': '#focusable-area', 'form element': '#the-form-element', 'form submission': '#form-submission', @@ -86,6 +89,7 @@ var autolinkConfig = { 'reflect': '#reflect', 'sequential focus navigation': '#sequential-focus-navigation', 'sequential focus navigation order': '#sequential-focus-navigation-order', + 'sequential navigation search algorithm': '#sequential-navigation-search-algorithm', 'style': '#the-style-attribute', 'tabindex': '#attr-tabindex', 'textarea element': '#the-textarea-element', diff --git a/spec/shadow/index.html b/spec/shadow/index.html index c3f4c27c..22480bf3 100644 --- a/spec/shadow/index.html +++ b/spec/shadow/index.html @@ -1123,11 +1123,42 @@

Ranges and Selections

-

Focus Navigation

+

Sequential Focus Navigation

If a node doesn’t participate in the document flat tree, the node must be skipped from the sequential focus navigation.

-

The sequential focus navigation order for a given shadow tree A must be inserted into the sequential focus navigation order for the parent tree B as follows:

+

Each shadow root and slot element is a control group owner and + forms its control group. +

+ +

For a given shadow root, its sequential focus navigation order consists of + focusable areas in its shadow tree + except descendants of a shadow host. + The order is tree order. +

+ +

For a given slot element, + its sequential focus navigation order consists of + focusable areas of its assigned nodes + and descendants of the assigned nodes. + If a given slot's assigned nodes is empty, its + sequential focus navigation order consists of + focusable areas of its fallback contents. + They are ordered by tree order of assigned nodes, + whose order is defined by get assigned nodes algorithm, + or if they are fallback contents, they are ordered by tree order of fallback contents. +

+ +

+ Any focusable area that is a descendant of a shadow host is excluded + from the sequential focus navigation order of its component tree. + Thus, if a child of a shadow host is not assigned to any slot, the child and + its descendants are considered inert and do not participate in any + sequential focus navigation order. +

+ +

+ The sequential focus navigation order for a given shadow tree A must be inserted into the sequential focus navigation order for the parent tree B as follows:

  1. Let HOST be the shadow host which hosts A
  2. The sequential focus navigation order for A must be @@ -1141,26 +1172,23 @@

    Focus Navigation

-

Likewise, the sequential focus navigation order for distributed nodes - under a given slot A must be inserted into - the sequential focus navigation order of the containing shadow tree's - sequential focus navigation order as follows:

+

Likewise, the sequential focus navigation order for a given slot + C must be inserted into + the sequential focus navigation order of the containing shadow tree + D's sequential focus navigation order as follows:

    -
  1. The sequential focus navigation order for its distributed nodes - must be skipped if A is assigned tabindex value -1. -
  2. If A is not given tabindex, - The sequential focus navigation order for its distributed nodes - must be inserted in place of A as if A +
  3. Let ORDER be the sequential focus navigation order of + the assigned nodes and their descendant nodes, or fallback contents of + slot C.
  4. +
  5. If C is assigned tabindex value -1, ORDER + must be skipped in D's + sequential focus navigation order +
  6. If C is not given tabindex, ORDER + must be inserted in place of C as if C were assigned the tabindex value 0 for determining its position.
  7. -
  8. Otherwise the sequential focus navigation order for its - distributed nodes must be inserted in place of - A according to its tabindex value.
  9. +
  10. Otherwise ORDER must be inserted in place of + C according to its tabindex value.
-

When a slot A is assigned to another - slot B, - the sequential focus navigation order of A's distributed nodes - is inserted into B's sequential focus navigation order following - the steps shown above.

For directional focus navigation [[!CSS3-UI]], it is up to the user agent to integrate the shadow trees into the document's directional focus navigation.

From 4dff0366c1cde367e9bcf2e799b9b688431f8734 Mon Sep 17 00:00:00 2001 From: siusin Date: Wed, 24 Feb 2016 17:24:02 +0800 Subject: [PATCH 07/82] Used ReSpec --- .../WD-html-imports-20160225/index.html | 568 ++++++++++++++++++ spec/imports/index.html | 342 +++++------ 2 files changed, 740 insertions(+), 170 deletions(-) create mode 100644 publish/imports/WD-html-imports-20160225/index.html diff --git a/publish/imports/WD-html-imports-20160225/index.html b/publish/imports/WD-html-imports-20160225/index.html new file mode 100644 index 00000000..6accb4ea --- /dev/null +++ b/publish/imports/WD-html-imports-20160225/index.html @@ -0,0 +1,568 @@ + + + + + HTML Imports + + + + + + +
+

HTML Imports are a way to include and reuse HTML documents in other HTML documents.

+
+ +
+
+ +
+

About this Document

+ +

All diagrams, examples, notes, are non-normative, as well as sections explicitly marked as non-normative. Everything else in this specification is normative.

+ +

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification.

+ +

Any point, at which a conforming UA must make decisions about the state or reaction to the state of the conceptual model, is captured as algorithm. The algorithms are defined in terms of processing equivalence. The processing equivalence is a constraint imposed on the algorithm implementers, requiring the output of the both UA-implemented and the specified algorithm to be exactly the same for all inputs.

+
+ +
+

Dependencies

+ +

This document relies on the following specifications:

+ + +
+ +
+

Terminology

+ +

HTML Imports, or just imports from here on, are HTML documents that are linked as external resources from another HTML document. The document that links to an import is called an import referrer. For any given import, an import referrer ancestor is its import referrer or any import referrer ancestor of its import referrer. There are one or more import referrers and import referrer ancestors for each import because same import can be referred from multiple import referrers.

+ +

An import referrer that is not an import, thus is not associated with any import referrer, is called a master document. Each import is associated with one master document: if the referrer of the import is a master document, it is the master document of the import. Otherwise, the master document of the import referrer is the master document of the import.

+ +

The URL of an import is called the import location.

+ +

In each import referrer, an import is represented as a Document, called the imported document.

+ +

+

The imported documents don't have browsing context. (See bug 26682.)

+ +

The set of all imports associated with the master document forms an import map of the master document. The maps stores imports as its items with their import locations as keys. The import map is empty at beginning. New items are added to the map as import fetching algorithm specifies.

+ +
+

Import Dependent

+ +

To track requested imports, each document has an import link list. Each of its item consists of link, a link element and location, a URL. +Also, the item is optionally marked as branch. +The list is initially empty, and items are added to it as specified by the import request algorithm.

+ +

Each imported document has an import parent: If the import link list of document A contains a branch item whose location points document B, A is an import parent of B. + +

Each imported document also has one or more import ancestors: Document A is an import ancestor of another document B if A is import parent of B. Being an import ancestor is transitive: If A is an import parent of B and B is an import parent of C, A is an import parent of C as well. + +

An imported document also has one or more import predecessors. An import predecessor is a document. If the URL of document A is located before the URL of document B in the import link list of B's import parent, and the located link is marked as a branch, then A is import predecessor of B.

+ +

The import ancestor predecessors of document A is defined as follows: If document B is an import predecessor of document C, and C is an import ancestor of A, B is an import ancestor predecessors of A.

+ +

The Document that is in either import ancestor predecessors or import predecessors of document A, or is linked from branch item of A's import link list, is the import dependent of A.

+ +
+

The import link list and the import dependent constrains the order of script execution in imports. It is intend to give a deterministic order of script execution which is defined by the order of link element in each import. The edges of each node is ordered in terms of import link list. The import predecessors selection is aware of the order.

+ +

The linking structure of import link lists forms a directed graph. Each node of the graph is a document and its edge is a link. Branches are intended to form a spanning tree of the graph. This tree gives the deterministic order of the script execution.

+ +
+ +
+ An example of import link lists. +
+
+ +

+In the figure, +

+ + +

The difference between the import referrer and the import parent is that import referrer reflects the state of the node tree and that the import parent is built by the algorithm described in this document.

+ +
+
+
+ + + +
+

Extensions to HTMLLinkElement Interface

+ +

+partial interface HTMLLinkElement {
+    readonly attribute Document? import;
+};
+
+ +

On getting, the import attribute must return null, if:

+ +

Otherwise, the attribute must return the imported document for the import, represented by the link element.

+ +

The same object must be returned each time.

+ +
+

Here's how one could access the imported document, mentioned in the previous example:

+

+var link = document.querySelector('link[rel=import]');
+var heart = link.import;
+// Access DOM of the document in /imports/heart.html
+var pulse = heart.querySelector('div.pulse');
+
+
+ +

An import in the context of the Document of an HTML parser or XML Parser is said to be an import that is blocking scripts if the element was created by that Document's parser, or and the element is a link of type import when the element was created by the parser, and the link is not marked as async, and the the import is yet to be completely loaded, and, the last time the event loop has reached step 1, the element was in that Document, and the user agent hasn't given up on that import yet. A user agent may give up on an import at any time.

+ + +
+

+Giving up an import before it loads, even if the import eventually does still load, means that the script might end up operating with incorrect information. For example, if an import registers a custom element and a script relies on the availability of this element, the script will find that this element is unavailable if the user agent gives up early. Implementers have to balance the likelihood of a script using incorrect information with the performance impact of doing nothing while waiting for a slow network request to finish. +

+
+ +

A Document has an import that is blocking scripts if there is an import that is blocking scripts in the Document's import dependent. +A Document has no import that is blocking scripts if it does not have an import that is blocking scripts as defined in the previous paragraph.

+ +
+

The state of "has an import that is blocking scripts" can change each time an existing import is completely loaded or new import loading is started. HTML parser has changes to unblock it for each of such timings.

+
+
+ +
+

Extensions to Document Interface

+ +

Additions to document.open() method

+ +

Add following step as the first step of the definition:

+ +
+
    +
  1. Throws an InvalidStateError exception if the Document is an import.
  2. +
+
+ +

Additions to document.write() method

+ +

Add following step as the first step of the definition:

+ +
+
    +
  1. Throws an InvalidStateError exception if the Document is an import.
  2. +
+
+ +

Additions to document.close() method

+ +

Add following step as the first step of the definition:

+ +
+
    +
  1. Throws an InvalidStateError exception if the Document is an import.
  2. +
+
+ +
+ +
+

Loading Imports

+ +
+

Updating Branch

+ +

After a link is added to the import link list, the update marking algorithm must be run with the master document. which is equivalent to running these steps:

+ +
+
Input
+
DOCUMENT, the Document
+
+ +
    +
  1. If the DOCUMENT is the master document, unmark branch of all the links in the import link list of DOCUMENT and every import that is associated to DOCUMENT.
  2. +
  3. Let LIST be an import link list of DOCUMENT.
  4. +
  5. For each ITEM in the LIST:
  6. +
    1. +
    2. Let LOCATION be a location of ITEM.
    3. +
    4. Let IMPORT be an import whose URL is same as LOCATION.
    5. +
    6. If there is no other link whose location is same as LOCATION and which is marked as a branch, mark ITEM as a branch.
    7. +
    8. If ITEM is marked as a branch and IMPORT is not null, invoke update marking algorithm with IMPORT.
    9. +
  7. +
+ +
+ +
+

Requesting Import

+ +

When user agents attempt to obtain a linked import, they must also run the import request algorithm, which is equivalent to running these steps:

+ +
+
+
Input
+
LINK, the link element that creates an external resource link to the import.
+
LOCATION, the URL of the linked resource.
+
+
    +
  1. If the async attribute of LINK is true, mark LINK as async. +
  2. Let DOCUMENT be a document of LINK. +
  3. Let LIST be an import link list of DOCUMENT. +
  4. Let ITEM be LINK and LOCATION:
  5. +
    1. +
    2. Add ITEM at the end of LIST. +
    3. Invoke update marking algorithm with the master document. +
  6. +
+
+ +
+ +
+

Fetching Import

+ +

All imports linked from documents that is the master document or the one in the import map must be fetched using the import fetching algorithm described below, instead of the one that HTML specifies to obtain a linked resouce.

+ +

The import fetching algorithm must be equivalent to running these steps:

+
+
+
Input
+
LINK, a link element which makes the external resource link to the import.
+
LOCATION, the import location
+
Output
+
IMPORT, the imported document.
+
+
    +
  1. If LOCATION is already in the import map:
  2. +
    1. +
    2. Let IMPORT be the imported document for LOCATION and stop.
    3. +
  3. +
  4. Fetch a resource from LOCATION with request's origin set to the origin of the master document, the mode to CORS and the credentials mode to same-origin.
  5. +
      +
    1. If fetched response type is error or the response has a header whose name is Content-Disposition:
    2. +
      • +
      • Add LOCATION and null to the import map and stop. +
    3. +
    4. Let IMPORT be a new Document, the document's address of which is LOCATION
    5. +
    6. Let PARSER be a new HTML parser, associated with IMPORT
    7. +
    8. Add LOCATION and IMPORT to the import map.
    9. +
    10. For each task that the networking task source places on the task queue while fetching: +
        +
      1. Fill PARSER's input byte stream with the fetched bytes
      2. +
      3. Let PARSER process the input byte stream with utf-8 as a known definite encoding
      4. +
    11. +
    12. When no more bytes are available: +
        +
      1. Queue a task from the networking task source for PARSER to process implied EOF character
      2. +
      +
    +
+
+ +
+All of loaded imports and imports under loading are in the import link list, thus every import which is linked from imports in the list will also be loaded using the import fetching algorithm, with LOCATION be the import location of the import. +
+ +

+The loading attempt must be considered successful if IMPORT is not null on the algorithm completion, and failed otherwise. +

+ +

Every import that is not marked as async delays the load event in the Document. + +

+

The link element fires a simple event called load +for successful loading attempt. For failed attempt, it fires a simple event named error.

+

As an import delays the load event, the Document isn't completely loaded until loading attempts of all of its linked imports are finished.

+
+ +
+ +
+

Imports and Content Security Policy

+ +

+Content Security Policy must restrict import loading through the script-src directive. +

+ +

+Each import must be restricted by the Content Security Policy of the master document. +For example, if Content Security Header Field is sent to an import, the user agent must enforce the policy of the master document to the imported document. +

+ +
+
+ +
+

Parsing Imports

+ +

Parsing behaviour of imports is defined as a set of changes to the HTML Parsing.

+ +
+

Additions to Prepare A Script Algorithm

+ +

In step 15 of prepare a script algorithm, modify the last part of condition which begins with If element does not have a src attribute to read:

+
+

... and the Document of the HTML parser or XML parser that created the script element has a style sheet that is blocking scripts or has an import that is blocking scripts

+
+ +
+ +
+

Additions to Tree Construction Algorithm

+ +

At the DOCTYPE part of section 12.2.5.4.1 The "initial" insertion mode, modify text if the document is not an iframe srcdoc document... as follows + +

+

if the document is not an iframe src document nor an import...

+
+ +

In sub-condition named Otherwise of condition An end tag whose name is "script" in "text" insertion mode, modify step 3 to read:

+
+
    +
  1. If the parser's Document has a style sheet that is blocking scripts or has an import that is blocking scripts or the script's "ready to be parser-executed" flag is not set: spin the event loop until the parser's Document has no style sheet that is blocking scripts and has no import that is blocking scripts and the script's "ready to be parser-executed" flag is set.
  2. +
+
+ +
+ +
+

Additions to Parsing XHTML Documents

+ +

Modify step 3 of steps that run following preparing the script element to read:

+
+
    +
  1. Spin the event loop until the parser's Document has no style sheet that is blocking scripts and has no import that is blocking scripts and the pending parsing-blocking script's "ready to be parser-executed" flag is set.

  2. +
+
+ +
+
+ +
+

Scripting in Imports

+ +
+

Additions to Script Enabling Criteria

+ +

Add following condition to the list of Enabling and disabling scripting criteria:

+ +
+ +
+ +
+ +
+

Additions to document.currentScript

+ +

+Modify the definition of document.currentScript +as follows: +

+
+The currentScript attribute, on getting, +must return the value to which it was most recently initialized in the document or the import map of the document. +When the Document is created, the currentScript must be initialized to null. +If the Document is an imported document, its currentScript is always null. +
+ +
+
+ +
+

Style processing with Imports

+ +

The contents of the style elements and +the external resources of the link elements in imports must be considered as input sources of the style processing model of the master document.

+ + + +
+

Order of Appearances and Imports

+ +

The order of appearances of declarations which come from different documents are determined by the import link tree. If node documents of two declarations differ, compare the tree order of these documents in the import link tree. The last one wins.

+ +
+
+ +
+

Events in Imports

+ +

Events in imports is defined as a set of changes to the HTML Events.

+ +
+

Additions to Event Handlers

+ +

+Modify the event handler content attribute's +script creation criteria by expanding the first paragraph: + +

+

When an event handler content attribute is set, if the element is owned by a Document that is in a browsing context or +in an import map, ...

+
+ +
+
+ +
+

Acknowledgements

+ +

David Hyatt developed XBL 1.0, and Ian Hickson co-wrote XBL 2.0. These documents provided tremendous insight into the problem of behavior attachment and greatly influenced this specification.

+ +

Alex Russell and his considerable forethought triggered a new wave of enthusiasm around the subject of behavior attachment and how it can be applied practically on the Web.

+ +

Dominic Cooney and Roland Steiner worked tirelessly to scope the problem within the confines of the Web platform and provided a solid foundation for this document.

+ +

The editor would also like to thank Alex Komoroske, Angelina Fabbro, Anne van Kesteren, Boris Zbarsky, Brian Kardell, Daniel Buchner, Edward O'Connor, Eric Bidelman, Erik Arvidsson, Elliott Sprehn, Gabor Krizsanits, Hayato Ito, James Simonsen, Jonas Sicking, Ken Shirriff, Neel Goyal, Olli Pettay, Rafael Weinstein, Scott Miles, Steve Orvell, Tab Atkins, William Chan, and William Chen for their comments and contributions to this specification.

+ +

This list is too short. There's a lot of work left to do. Please contribute by reviewing and filing bugs—and don't forget to ask the editor to add your name into this section.

+ +
+ + diff --git a/spec/imports/index.html b/spec/imports/index.html index 211107b2..1e2b32ef 100644 --- a/spec/imports/index.html +++ b/spec/imports/index.html @@ -1,106 +1,47 @@ - + -HTML Imports - - - - - - + + HTML Imports + + + +
+

HTML Imports are a way to include and reuse HTML documents in other HTML documents.

+
-
- - - -

HTML Imports

-

W3C Editor's Draft

-
-
This version
-
http://w3c.github.io/webcomponents/spec/imports/
-
Latest version
-
http://www.w3.org/TR/html-imports/
-
Latest editor's draft
-
http://w3c.github.io/webcomponents/spec/imports/
-
Previous version
-
none
-
Revision history
-
https://github.com/w3c/webcomponents/commits/gh-pages/spec/imports/
-
Participate
-
Discuss on public-webapps@w3.org (Web Platform Working Group)
-
Bugs filed
-
https://github.com/w3c/webcomponents/labels/html-imports
-
Editor
-
Dimitri Glazkov, Google, <>
-
Hajime Morrita, Google, <>
-
- - - -
- -

Abstract

- -

HTML Imports are a way to include and reuse HTML documents in other HTML documents.

- -

Status of This Document

- -

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

- -

This document was published by the Web Platform Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives). All feedback is welcome.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

- -

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

- -

This document is governed by the 1 September 2015 W3C Process Document.

- -
- -
-

Table of Contents

-
    -
  1. About this Document -
  2. Dependencies -
  3. Terminology -
      -
    1. Import Dependent -
    -
  4. Link Type "import" -
  5. Extensions to HTMLLinkElement interface -
  6. Extensions to Document interface -
  7. Loading Imports -
      -
    1. Updating Branch -
    2. Requesting Import -
    3. Fetching Import -
    4. Imports and Content Security Policy -
    -
  8. Parsing Imports -
      -
    1. Additions to Prepare A Script Algorithm -
    2. Additions to Tree Construction Algorithm -
    3. Additions to Parsing XHTML Documents -
    -
  9. Scripting in Imports -
      -
    1. Additions to Script Enabling Criteria -
    2. Additions to document.currentScript -
    -
  10. Style processing with Imports -
      -
    1. Import Link Tree
    2. -
    3. Order of appearances and Imports
    4. -
    -
  11. Events in Imports -
      -
    1. Additions to Event Handlers -
    -
  12. Acknowledgements -
+
@@ -111,8 +52,10 @@

About this Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification.

Any point, at which a conforming UA must make decisions about the state or reaction to the state of the conceptual model, is captured as algorithm. The algorithms are defined in terms of processing equivalence. The processing equivalence is a constraint imposed on the algorithm implementers, requiring the output of the both UA-implemented and the specified algorithm to be exactly the same for all inputs.

+
-

Dependencies

+
+

Dependencies

This document relies on the following specifications:

@@ -130,8 +73,10 @@

Dependencies

  • Shadow DOM
  • Web IDL
  • --> +
    -

    Terminology

    +
    +

    Terminology

    HTML Imports, or just imports from here on, are HTML documents that are linked as external resources from another HTML document. The document that links to an import is called an import referrer. For any given import, an import referrer ancestor is its import referrer or any import referrer ancestor of its import referrer. There are one or more import referrers and import referrer ancestors for each import because same import can be referred from multiple import referrers.

    @@ -141,20 +86,21 @@

    Terminology

    In each import referrer, an import is represented as a Document, called the imported document.

    -

    +
    +

    The imported documents don't have browsing context. (See bug 26682.)

    The set of all imports associated with the master document forms an import map of the master document. The maps stores imports as its items with their import locations as keys. The import map is empty at beginning. New items are added to the map as import fetching algorithm specifies.

    -

    Import Dependent

    +
    +

    Import Dependent

    To track requested imports, each document has an import link list. Each of its item consists of link, a link element and location, a URL. Also, the item is optionally marked as branch. The list is initially empty, and items are added to it as specified by the import request algorithm.

    -

    Each imported document has an import parent: If the import link list of document A contains a branch item whose location points document B, A is an import parent of B. +

    Each imported document has an import parent: If the import link list of document A contains a branch item whose location points document B, A is an import parent of B. -

    Each imported document also has one or more import ancestors: Document A is an import ancestor of another document B if A is import parent of B. Being an import ancestor is transitive: If A is an import parent of B and B is an import parent of C, A is an import parent of C as well. +

    Each imported document also has one or more import ancestors: Document A is an import ancestor of another document B if A is import parent of B. Being an import ancestor is transitive: If A is an import parent of B and B is an import parent of C, A is an import parent of C as well.

    An imported document also has one or more import predecessors. An import predecessor is a document. If the URL of document A is located before the URL of document B in the import link list of B's import parent, and the located link is marked as a branch, then A is import predecessor of B.

    @@ -162,7 +108,7 @@

    Import Dependent

    The Document that is in either import ancestor predecessors or import predecessors of document A, or is linked from branch item of A's import link list, is the import dependent of A.

    -
    +

    The import link list and the import dependent constrains the order of script execution in imports. It is intend to give a deterministic order of script execution which is defined by the order of link element in each import. The edges of each node is ordered in terms of import link list. The import predecessors selection is aware of the order.

    The linking structure of import link lists forms a directed graph. Each node of the graph is a document and its edge is a link. Branches are intended to form a spanning tree of the graph. This tree gives the deterministic order of the script execution.

    @@ -203,13 +149,16 @@

    Import Dependent

    The difference between the import referrer and the import parent is that import referrer reflects the state of the node tree and that the import parent is built by the algorithm described in this document.

    -
    +
    +
    +
    - + -
    +

    The following document has one import, located at /imports/heart.html:

    
    @@ -237,9 +186,11 @@ 
         </body>
     </html>
     
    -
    + + -

    Extensions to HTMLLinkElement Interface

    +
    +

    Extensions to HTMLLinkElement Interface

    
     partial interface HTMLLinkElement {
    @@ -256,7 +207,7 @@ 

    Extensions to HTMLLinkElement InterfaceThe same object must be returned each time.

    -
    +

    Here's how one could access the imported document, mentioned in the previous example:

    
     var link = document.querySelector('link[rel=import]');
    @@ -264,59 +215,65 @@ 

    Extensions to HTMLLinkElement Interface

    -
    +

    An import in the context of the Document of an HTML parser or XML Parser is said to be an import that is blocking scripts if the element was created by that Document's parser, or and the element is a link of type import when the element was created by the parser, and the link is not marked as async, and the the import is yet to be completely loaded, and, the last time the event loop has reached step 1, the element was in that Document, and the user agent hasn't given up on that import yet. A user agent may give up on an import at any time.

    -
    +

    Giving up an import before it loads, even if the import eventually does still load, means that the script might end up operating with incorrect information. For example, if an import registers a custom element and a script relies on the availability of this element, the script will find that this element is unavailable if the user agent gives up early. Implementers have to balance the likelihood of a script using incorrect information with the performance impact of doing nothing while waiting for a slow network request to finish.

    -
    +

    A Document has an import that is blocking scripts if there is an import that is blocking scripts in the Document's import dependent. A Document has no import that is blocking scripts if it does not have an import that is blocking scripts as defined in the previous paragraph.

    -
    +

    The state of "has an import that is blocking scripts" can change each time an existing import is completely loaded or new import loading is started. HTML parser has changes to unblock it for each of such timings.

    -
    + + -

    Extensions to Document Interface

    +
    +

    Extensions to Document Interface

    Additions to document.open() method

    Add following step as the first step of the definition:

    -
    +
    1. Throws an InvalidStateError exception if the Document is an import.
    -
    +

    Additions to document.write() method

    Add following step as the first step of the definition:

    -
    +
    1. Throws an InvalidStateError exception if the Document is an import.
    -
    +

    Additions to document.close() method

    Add following step as the first step of the definition:

    -
    +
    1. Throws an InvalidStateError exception if the Document is an import.
    -
    + -

    Loading Imports

    + -

    Updating Branch

    +
    +

    Loading Imports

    + +
    +

    Updating Branch

    After a link is added to the import link list, the update marking algorithm must be run with the master document. which is equivalent to running these steps:

    @@ -337,18 +294,21 @@

    Updating Branch

    -

    Requesting Import

    +
    + +
    +

    Requesting Import

    When user agents attempt to obtain a linked import, they must also run the import request algorithm, which is equivalent to running these steps:

    -
    +
    Input
    LINK, the link element that creates an external resource link to the import.
    LOCATION, the URL of the linked resource.
      -
    1. If the async attribute of LINK is true, mark LINK as async. +
    2. If the async attribute of LINK is true, mark LINK as async.
    3. Let DOCUMENT be a document of LINK.
    4. Let LIST be an import link list of DOCUMENT.
    5. Let ITEM be LINK and LOCATION:
    6. @@ -357,14 +317,17 @@

      Requesting Import

    7. Invoke update marking algorithm with the master document.
    -
    +
    + +
    -

    Fetching Import

    +
    +

    Fetching Import

    All imports linked from documents that is the master document or the one in the import map must be fetched using the import fetching algorithm described below, instead of the one that HTML specifies to obtain a linked resouce.

    The import fetching algorithm must be equivalent to running these steps:

    -
    +
    Input
    LINK, a link element which makes the external resource link to the import.
    @@ -397,11 +360,11 @@

    Fetching Import

    -
    +
    -
    +
    All of loaded imports and imports under loading are in the import link list, thus every import which is linked from imports in the list will also be loaded using the import fetching algorithm, with LOCATION be the import location of the import. -
    +

    The loading attempt must be considered successful if IMPORT is not null on the algorithm completion, and failed otherwise. @@ -409,13 +372,16 @@

    Fetching Import

    Every import that is not marked as async delays the load event in the Document. -

    +

    The link element fires a simple event called load for successful loading attempt. For failed attempt, it fires a simple event named error.

    As an import delays the load event, the Document isn't completely loaded until loading attempts of all of its linked imports are finished.

    -
    + + + -

    Imports and Content Security Policy

    +
    +

    Imports and Content Security Policy

    Content Security Policy must restrict import loading through the script-src directive. @@ -426,76 +392,100 @@

    Imports and Content Security Policy

    For example, if Content Security Header Field is sent to an import, the user agent must enforce the policy of the master document to the imported document.

    -

    Parsing Imports

    +
    + + +
    +

    Parsing Imports

    Parsing behaviour of imports is defined as a set of changes to the HTML Parsing.

    -

    Additions to Prepare A Script Algorithm

    +
    +

    Additions to Prepare A Script Algorithm

    In step 15 of prepare a script algorithm, modify the last part of condition which begins with If element does not have a src attribute to read:

    - +
    -

    Additions to Tree Construction Algorithm

    +
    + +
    +

    Additions to Tree Construction Algorithm

    At the DOCTYPE part of section 12.2.5.4.1 The "initial" insertion mode, modify text if the document is not an iframe srcdoc document... as follows -

    +

    if the document is not an iframe src document nor an import...

    -
    +

    In sub-condition named Otherwise of condition An end tag whose name is "script" in "text" insertion mode, modify step 3 to read:

    - + + + -

    Additions to Parsing XHTML Documents

    +
    +

    Additions to Parsing XHTML Documents

    Modify step 3 of steps that run following preparing the script element to read:

    - +
    -

    Scripting in Imports

    + + + +
    +

    Scripting in Imports

    -

    Additions to Script Enabling Criteria

    +
    +

    Additions to Script Enabling Criteria

    Add following condition to the list of Enabling and disabling scripting criteria:

    -
    +
    -
    +
    + +
    -

    Additions to document.currentScript

    +
    +

    Additions to document.currentScript

    Modify the definition of document.currentScript as follows:

    -
    +
    The currentScript attribute, on getting, must return the value to which it was most recently initialized in the document or the import map of the document. When the Document is created, the currentScript must be initialized to null. If the Document is an imported document, its currentScript is always null. -
    +
    -

    Style processing with Imports

    + + + +
    +

    Style processing with Imports

    The contents of the style elements and the external resources of the link elements in imports must be considered as input sources of the style processing model of the master document.

    - + -
    +
    The import link tree algorithm defines a order of imports using a depth first traversal. This import link tree is different from the one formed by import link list. The former is based on the document tree of each import. The later is built through import loading process and isn'taffected by document tree mutation. -
    +
    + + -

    Order of Appearances and Imports

    +
    +

    Order of Appearances and Imports

    The order of appearances of declarations which come from different documents are determined by the import link tree. If node documents of two declarations differ, compare the tree order of these documents in the import link tree. The last one wins.

    -

    Events in Imports

    +
    + + +
    +

    Events in Imports

    Events in imports is defined as a set of changes to the HTML Events.

    -

    Additions to Event Handlers

    +
    +

    Additions to Event Handlers

    Modify the event handler content attribute's script creation criteria by expanding the first paragraph: -

    +

    When an event handler content attribute is set, if the element is owned by a Document that is in a browsing context or in an import map, ...

    -
    +
    + +
    + -

    Acknowledgements

    +
    +

    Acknowledgements

    David Hyatt developed XBL 1.0, and Ian Hickson co-wrote XBL 2.0. These documents provided tremendous insight into the problem of behavior attachment and greatly influenced this specification.

    From 4a5a2c751481bbb57924da36f35719cfe536bfea Mon Sep 17 00:00:00 2001 From: siusin Date: Wed, 24 Feb 2016 17:41:27 +0800 Subject: [PATCH 08/82] used ReSpec and added a new WD --- .../WD-html-imports-20160225/index.html | 689 +++++++++++++----- spec/imports/index.html | 6 +- 2 files changed, 523 insertions(+), 172 deletions(-) diff --git a/publish/imports/WD-html-imports-20160225/index.html b/publish/imports/WD-html-imports-20160225/index.html index 6accb4ea..8070fc63 100644 --- a/publish/imports/WD-html-imports-20160225/index.html +++ b/publish/imports/WD-html-imports-20160225/index.html @@ -1,65 +1,411 @@ - - - + + + HTML Imports - - - - - - -
    + + + + + + +

    Abstract

    HTML Imports are a way to include and reuse HTML documents in other HTML documents.

    -
    - -
    -
    - -
    -

    About this Document

    +

    Status of This Document

    + + + +

    + This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. +

    + + + + + + +

    + This document was published by the Web Platform Working Group as a Working Draft. + + This document is intended to become a W3C Recommendation. + + + If you wish to make comments regarding this document, please send them to + public-webapps@w3.org + (subscribe, + archives). + + + + + + + All comments are welcome. + + +

    + + + + +

    + Publication as a Working Draft does not imply endorsement by the W3C + Membership. This is a draft document and may be updated, replaced or obsoleted by other + documents at any time. It is inappropriate to cite this document as other than work in + progress. +

    + + + +

    + + This document was produced by + + a group + operating under the + 5 February 2004 W3C Patent + Policy. + + + + + W3C maintains a public list of any patent + disclosures + + made in connection with the deliverables of + + the group; that page also includes + + instructions for disclosing a patent. An individual who has actual knowledge of a patent + which the individual believes contains + Essential + Claim(s) must disclose the information in accordance with + section + 6 of the W3C Patent Policy. + + +

    + +

    This document is governed by the 1 September 2015 W3C Process Document. +

    + + + + + + +

    Table of Contents

    + + + +
    +

    1. About this Document

    All diagrams, examples, notes, are non-normative, as well as sections explicitly marked as non-normative. Everything else in this specification is normative.

    -

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification.

    +

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification.

    -

    Any point, at which a conforming UA must make decisions about the state or reaction to the state of the conceptual model, is captured as algorithm. The algorithms are defined in terms of processing equivalence. The processing equivalence is a constraint imposed on the algorithm implementers, requiring the output of the both UA-implemented and the specified algorithm to be exactly the same for all inputs.

    +

    Any point, at which a conforming UA must make decisions about the state or reaction to the state of the conceptual model, is captured as algorithm. The algorithms are defined in terms of processing equivalence. The processing equivalence is a constraint imposed on the algorithm implementers, requiring the output of the both UA-implemented and the specified algorithm to be exactly the same for all inputs.

    -
    -

    Dependencies

    +
    +

    2. Dependencies

    This document relies on the following specifications:

    @@ -79,49 +425,49 @@

    Dependencies

    -
    -

    Terminology

    +
    +

    3. Terminology

    -

    HTML Imports, or just imports from here on, are HTML documents that are linked as external resources from another HTML document. The document that links to an import is called an import referrer. For any given import, an import referrer ancestor is its import referrer or any import referrer ancestor of its import referrer. There are one or more import referrers and import referrer ancestors for each import because same import can be referred from multiple import referrers.

    +

    HTML Imports, or just imports from here on, are HTML documents that are linked as external resources from another HTML document. The document that links to an import is called an import referrer. For any given import, an import referrer ancestor is its import referrer or any import referrer ancestor of its import referrer. There are one or more import referrers and import referrer ancestors for each import because same import can be referred from multiple import referrers.

    -

    An import referrer that is not an import, thus is not associated with any import referrer, is called a master document. Each import is associated with one master document: if the referrer of the import is a master document, it is the master document of the import. Otherwise, the master document of the import referrer is the master document of the import.

    +

    An import referrer that is not an import, thus is not associated with any import referrer, is called a master document. Each import is associated with one master document: if the referrer of the import is a master document, it is the master document of the import. Otherwise, the master document of the import referrer is the master document of the import.

    -

    The URL of an import is called the import location.

    +

    The URL of an import is called the import location.

    -

    In each import referrer, an import is represented as a Document, called the imported document.

    +

    In each import referrer, an import is represented as a Document, called the imported document.

    -

    +

    The imported documents don't have browsing context. (See bug 26682.)

    -

    The set of all imports associated with the master document forms an import map of the master document. The maps stores imports as its items with their import locations as keys. The import map is empty at beginning. New items are added to the map as import fetching algorithm specifies.

    +

    The set of all imports associated with the master document forms an import map of the master document. The maps stores imports as its items with their import locations as keys. The import map is empty at beginning. New items are added to the map as import fetching algorithm specifies.

    -
    -

    Import Dependent

    +
    +

    3.1 Import Dependent

    -

    To track requested imports, each document has an import link list. Each of its item consists of link, a link element and location, a URL. -Also, the item is optionally marked as branch. +

    To track requested imports, each document has an import link list. Each of its item consists of link, a link element and location, a URL. +Also, the item is optionally marked as branch. The list is initially empty, and items are added to it as specified by the import request algorithm.

    -

    Each imported document has an import parent: If the import link list of document A contains a branch item whose location points document B, A is an import parent of B. +

    Each imported document has an import parent: If the import link list of document A contains a branch item whose location points document B, A is an import parent of B. -

    Each imported document also has one or more import ancestors: Document A is an import ancestor of another document B if A is import parent of B. Being an import ancestor is transitive: If A is an import parent of B and B is an import parent of C, A is an import parent of C as well. +

    Each imported document also has one or more import ancestors: Document A is an import ancestor of another document B if A is import parent of B. Being an import ancestor is transitive: If A is an import parent of B and B is an import parent of C, A is an import parent of C as well. -

    An imported document also has one or more import predecessors. An import predecessor is a document. If the URL of document A is located before the URL of document B in the import link list of B's import parent, and the located link is marked as a branch, then A is import predecessor of B.

    +

    An imported document also has one or more import predecessors. An import predecessor is a document. If the URL of document A is located before the URL of document B in the import link list of B's import parent, and the located link is marked as a branch, then A is import predecessor of B.

    -

    The import ancestor predecessors of document A is defined as follows: If document B is an import predecessor of document C, and C is an import ancestor of A, B is an import ancestor predecessors of A.

    +

    The import ancestor predecessors of document A is defined as follows: If document B is an import predecessor of document C, and C is an import ancestor of A, B is an import ancestor predecessors of A.

    -

    The Document that is in either import ancestor predecessors or import predecessors of document A, or is linked from branch item of A's import link list, is the import dependent of A.

    +

    The Document that is in either import ancestor predecessors or import predecessors of document A, or is linked from branch item of A's import link list, is the import dependent of A.

    -
    +

    The import link list and the import dependent constrains the order of script execution in imports. It is intend to give a deterministic order of script execution which is defined by the order of link element in each import. The edges of each node is ordered in terms of import link list. The import predecessors selection is aware of the order.

    The linking structure of import link lists forms a directed graph. Each node of the graph is a document and its edge is a link. Branches are intended to form a spanning tree of the graph. This tree gives the deterministic order of the script execution.

    -
    +
    Fig. 1 An example of import link lists. -
    +

    @@ -129,15 +475,15 @@

    Import Dependent

    -