Merge/upstream (#5)

* Editorial: remove redundant "the"

* Meta: default branch rename

Also correct a broken link. Not even w3.org URLs are that cool.

Helps with whatwg/meta#174.

* Editorial: clean up calls to "parse a URL"

It actually takes a string, so calls should be clear about that.

* Review Draft Publication: January 2021

* Simplify <link>s

In particular, remove their activation behavior, stop them from matching
:link and :visited, and stop suggesting that they be focusable areas.

This also includes a slight expansion and rearrangement of the link
element's section to make it clearer what hyperlinks created by <link>
are meant for, contrasting them to <a> and <area> hyperlinks.

Closes whatwg#4831. Closes whatwg#2617. Helps with whatwg#5490.

* Meta: remove demos/offline/* (whatwg#6307)

These are no longer needed as of e4330d5.

* Meta: minor references cleanup

Use more HTTPS and drop obsolete HTML Differences reference.

* Editorial: anticlockwise → counterclockwise

We use en-US these days. Spotted in https://twitter.com/iso2022jp/status/1352601086519955456.

* Use :focus-visible in the UA stylesheet

See w3c/csswg-drafts#4278.

* Editorial: align with WebIDL and Infra

* Fix "update a style block" early return

The new version matches implementation reality and CSSWG resolution.

The algorithm was also inconsistent, as it looked at whether
the element was in a shadow tree or in the document tree, but it was
only specified to be re-run if the element becomes connected or
disconnected.

The CSSWG discussed this in
w3c/csswg-drafts#3096 (comment)
and http://wpt.live/shadow-dom/ShadowRoot-interface.html tests this.

This also matches closer the definition of <link rel="stylesheet">,
which does use connectedness (though it uses "browsing-context
connected", which is a bit different):
https://html.spec.whatwg.org/#link-type-stylesheet

* Modernize and refactor simple dialogs

This contains a small bug fix, in that confirm() and prompt() said
"return" in some cases instead of "return false" or "return null" as
appropriate.

Other notable changes, all editorial, are:

* Factoring out repeated "cannot show simple dialogs" steps, which will
  likely expand over time (see e.g. whatwg#6297).
* Separating out and explaining the no-argument overload of alert().
* Passing the document through to the "printing steps", instead of just
  having them talk about "this Window object".

* Meta: add definition markup for MessageEvent

* Remove <marquee> events

They are only supported by one engine (Gecko).

Closes whatwg#2957.

* Clarify when microtasks happen

* Ignore COEP on non-secure contexts

Fixes whatwg#6328.

* Editorial: update URL Standard integration

* Editorial: only invoke response's location URL once

Complements whatwg/fetch#1149.

* Track the incumbent settings and active script in Promise callbacks

Closes whatwg#5213.

* createImageBitmap(): stop clipping sourceRect to source's dimensions

It has been found in whatwg#6306 that this was an oversight at the time of its introduction. Current behavior goes against author expectations and no implementer has opposed the change to "no-clip".

Tests: web-platform-tests/wpt#27040.

Closes whatwg#6306.

* Remove CSP plugin-types blocking

With Flash not being supported anymore, the CSP directive plugin-types has lost its main reason for being and is being removed from the Content Security Policy specification: w3c/webappsec-csp#456.

This change removes references to the relevant algorithm from the Content Security Policy spec.

* Meta: set more dfn types

A follow-up to:

* whatwg#5694
* whatwg#5916

* Editorial: occuring → occurring

* Make all plugin-related APIs no-ops

Part of whatwg#6003.

* Disallow simple dialogs from different-origin domain iframes

Closes whatwg#5407.

* Revive @@iterator for PluginArray/MimeTypeArray/Plugin

@@iterator is implicitly installed by defining an indexed property getter. Since there is no other way to define it exclusively, this restores some methods back to being indexed getters.

This fixes an inadvertent observable behavior change in d4f07b8.

* Adjust web+ scheme security considerations to account for FTP removal

Also, network scheme is now reduced to HTTP(S) scheme.

Helps with whatwg#5375, but form submission issue remains.

See whatwg/fetch#1166 for context.

* Meta: export pause

Nobody but XMLHttpRequest take a dependency on this please. You have been warned.

Context: whatwg/xhr#311.

* Fix typo: ancestor → accessor

Fixes whatwg#6374.

Co-authored-by: Dominic Farolino <[email protected]>
Co-authored-by: Anne van Kesteren <[email protected]>
Co-authored-by: Domenic Denicola <[email protected]>
Co-authored-by: Emilio Cobos Álvarez <[email protected]>
Co-authored-by: Momdo Nakamura <[email protected]>
Co-authored-by: Jake Archibald <[email protected]>
Co-authored-by: Yutaka Hirano <[email protected]>
Co-authored-by: Shu-yu Guo <[email protected]>
Co-authored-by: Kaiido <[email protected]>
Co-authored-by: Antonio Sartori <[email protected]>
Co-authored-by: Michael[tm] Smith <[email protected]>
Co-authored-by: Ikko Ashimine <[email protected]>
Co-authored-by: Carlos IL <[email protected]>
Co-authored-by: Kagami Sascha Rosylight <[email protected]>
Co-authored-by: Simon Pieters <[email protected]>

.github/workflows/build.yml

@@ -2,10 +2,10 @@ name: Build
 on:
   pull_request:
     branches:
-    - master
+    - main
   push:
     branches:
-    - master
+    - main
 jobs:
   build:
     name: Build
@@ -30,7 +30,7 @@ jobs:
                    --env "HTML_OUTPUT=/imhele/output" \
                    imhele/html-build
     - name: Deploy
-      if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/master' }}
+      if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
       env:
         AccessKeyId: ${{ secrets.ALIYUN_ACCESS_KEY_ID }}
         AccessKeySecret: ${{ secrets.ALIYUN_ACCESS_KEY_SECRET }}

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # HTML Standard contributor guidelines
 
-These are the guidelines for contributing to the HTML Standard. First see the [WHATWG contributor guidelines](https://github.com/whatwg/meta/blob/master/CONTRIBUTING.md).
+These are the guidelines for contributing to the HTML Standard. First see the [WHATWG contributor guidelines](https://github.com/whatwg/meta/blob/main/CONTRIBUTING.md).
 
 The HTML Standard is quite complex and people notice minor and larger issues with it all the time. We'd love your help fixing these. Pull requests for typographical and grammar errors are also most welcome.
 
@@ -12,7 +12,7 @@ We'd be happy to mentor you through this process. If you're interested and need
 
 In short, change `source` and submit your patch, with a [good commit message](https://github.com/erlang/otp/wiki/Writing-good-commit-messages). Try to follow the source formatting rules below.
 
-Note that `source` is written in a dialect of HTML, which is eventually compiled into the deployed standard by a tool called [Wattsi](https://github.com/whatwg/wattsi). Documentation for this dialect can be found [in the Wattsi repository](https://github.com/whatwg/wattsi/blob/master/Syntax.md).
+Note that `source` is written in a dialect of HTML, which is eventually compiled into the deployed standard by a tool called [Wattsi](https://github.com/whatwg/wattsi). Documentation for this dialect can be found [in the Wattsi repository](https://github.com/whatwg/wattsi/blob/main/Syntax.md).
 
 Please add your name to the Acknowledgments section (search for `<!-- ACKS`) in your first pull request, even for trivial fixes. The names are sorted lexicographically.
 

FAQ.md

@@ -45,9 +45,8 @@ Validity (more often referred to as document conformance in the WHATWG) is a qua
 There are a number of ways to track changes to the standard:
 
 * The Twitter feed: [@htmlstandard](https://twitter.com/htmlstandard)
-* The [GitHub commits log](https://github.com/whatwg/html/commits/master)
+* The [GitHub commits log](https://github.com/whatwg/html/commits)
 * The standard is available in the [Git repository](https://github.com/whatwg/html/). You may use any Git client to check out the latest version and use your client's diff tools to compare revisions and see what has been changed.
-* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/
 
 ### What are the various versions of the HTML Standard?
 
@@ -377,8 +376,8 @@ The plan to get the specs to converge again, such as it is, is to just do a bett
 
 Here are some documents that detail the history of HTML:
 
-* [A feature history of the modern web platform](https://platform.html5.org/history/) (2003 onward) ([on GitHub](https://github.com/whatwg/platform.html5.org/blob/master/history/index.html))
-* [HTML's timeline on the ESW wiki](http://esw.w3.org/topic/HTML/history) (1997 to 2008)
+* [A feature history of the modern web platform](https://platform.html5.org/history/) (2003 onward) ([on GitHub](https://github.com/whatwg/platform.html5.org/blob/main/history/index.html))
+* [HTML's timeline on the W3C HTML WG wiki](https://www.w3.org/html/wg/wiki/History) (1997 to 2008)
 * [The history section in the HTML standard itself](https://html.spec.whatwg.org/multipage/introduction.html#history-2)
 
 ## Using HTML
@@ -395,7 +394,7 @@ Some people argue that in such cases, the `<span>` element should be used with a
 
 In essence, the `<i>` and `<b>` elements convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don't convey specific semantics by themselves, but instead they indicate that the content is somehow semantically distinct from its surroundings — leaving the interpretation of the semantics up to the reader.
 
-This is further explained in the article [The `<b>` and `<i>` Elements](http://lachy.id.au/log/2007/05/b-and-i).
+This is further explained in the article [The `<b>` and `<i>` Elements](https://lachy.id.au/log/2007/05/b-and-i).
 
 Similarly, the `<small>` element is defined for content that is commonly typographically rendered in small print, and which is often referred to as "fine print"; that could include copyright statements, disclaimers and other legal text commonly found at the end of a document.
 
@@ -411,7 +410,7 @@ So, we can't really decide what the element should be based on past practice, li
 
 This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for `<cite>` is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.
 
-There are already many ways of marking up names already (e.g. the [hCard microformat](http://microformats.org/wiki/hcard), the microdata vCard vocabulary, `<span>` and class names, etc), if you really need it.
+There are already many ways of marking up names already (e.g. the [hCard microformat](https://microformats.org/wiki/hcard), the microdata vCard vocabulary, `<span>` and class names, etc), if you really need it.
 
 ### Do you have any hints on how to use `<section>` and `<article>` and so on?
 

PULL_REQUEST_TEMPLATE.md

@@ -7,7 +7,7 @@ Thank you for contributing to the HTML Standard! Please describe the change you
    * …
 - [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
    * …
-- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/master/MAINTAINERS.md#handling-pull-requests) are filed:
+- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
    * Chrome: …
    * Firefox: …
    * Safari: …

review-draft.sh

@@ -3,9 +3,9 @@ set -o errexit
 set -o nounset
 
 # This is based on a script named review.sh over at
-# https://github.com/whatwg/whatwg.org/tree/master/resources.whatwg.org/build
+# https://github.com/whatwg/whatwg.org/tree/main/resources.whatwg.org/build
 #
-# Please see https://github.com/whatwg/meta/blob/master/MAINTAINERS.md for information on creating
+# Please see https://github.com/whatwg/meta/blob/main/MAINTAINERS.md for information on creating
 # and announcing Review Drafts.
 
 header() {
@@ -16,7 +16,7 @@ header() {
 
 header "Creating a git branch with a Review Draft:"
 
-git checkout master
+git checkout main
 git pull
 git checkout -b "review-draft-$(date +'%F')"
 echo ""