I'd like to thank and congratulate everyone who contributed to the Pointer Events specification. As you probably know now, Pointer Events has now been published as a W3C Recommendation [1][2].

These blog posts address a serious issue: the lack of universal interoperability, and competition with the Touch Events technology (also published by W3C). We hope that with work and developer interest, this will change over time.

[14:02] <annevk> W3C AC still partying like it's 2004: https://twitter.com/fabien_gandon/status/596229047476170753

heycam: these algorithms like "focusing steps", can't we just reference HTML?

ed: I think they were in HTML 5.1, not HTML 5, and we couldn't reference 5.1 at the point these were added

Please note that advancement to Recommendation is blocked until Web IDL and Web Storage are both Proposed Recommendations.

By publishing this Recommendation, W3C expects that the functionality specified in this Widget Interface API will not be affected by changes to HTML5 or WebIDL as that specification proceeds to Recommendation.

Note that since the old syntax was never supported by any UA in any

meaningful way I'm aware of, those are basically problems in those specs

that should technically have prevented them from going to REC (due to

lack of two interoperable implementations).

A specification for Notifications is also being developed at https://notifications.spec.whatwg.org/. Recent work there has focused on integrating notifications with Service Workers and other new features. That specification also deprecates the onshow and onclose events that are present in this specification, under the rationale that those events lack sufficient use cases.

It is published as a Working Group Note because the HTML Working Group is reaching the end of its charter; it is hoped and expected that a successor to that Working Group, perhaps the Timed Media Working Group, will continue the work of taking this document to become a W3C Recommendation.

A specification for Notifications is also being developed at https://notifications.spec.whatwg.org/. Recent work there has focused on integrating notifications with Service Workers and other new features. That specification also deprecates the onshow and onclose events that are present in this specification, under the rationale that those events lack sufficient use cases.

Warning

Implementers should take heed of the old bugs list in general, but more particularly of these two bugs that adversely affect interoperability (most particularly of the Document interface):

Bug 19431: Namespace of elements made via .createElement() in XML documents must be null

Bug 22960: Document, XMLDocument, HTMLDocument, oh my

[CSSOMVIEW]

(Non-normative)

Document Object Model (DOM) Level 2 Style, C. Wilson, P. Le Hégaret, V. Apparao. W3C.

CSSOM View Module, S. Pieters, G. Adams. W3C.

[URL]

(Non-normative)

Note: URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider [RFC3986] [RFC3987]. The W3C URL specification defines the term URL, various algorithms for dealing with URLs, and an API for constructing, parsing, and resolving URLs. Developers of Web browsers are advised to keep abreast of the latest URL developments by tracking the progress of https://url.spec.whatwg.org/. We expect that the W3C URL draft will evolve along the Recommendation track as the community converges on a definition of URL processing.

URL, Anne van Kesteren. WHATWG.

RFC3986, T. Berners-Lee; R. Fielding; L. Masinter. IETF.

RFC3987, M. Duerst, M. Suignard. IETF.

B. CSS Concepts

Note: This section contains concepts introduced by the Selectors Level 4 and will be removed in the future once the Selectors Level 4 is updated. Please refer to [SELECTORS] for up-to-date definitions.

By publishing this Recommendation, W3C expects the functionality specified in this Recommendation will not be affected by changes to Web IDL, CSS Object Model, CSS Images Values, or CSS Fonts as those specifications proceed to Recommendation.

The practices proposed in this document are intended to address some specific problems:

W3C wastes resources, and at worst tarnishes its credibility, when it invests in standardization efforts that end up going nowhere

The W3C staff will continue to accept errata for the XML Core

Recommendations and may request assistance with the processing of

submitted errata. We may publish Proposed Edited Recommendations for

editorial changes that require no technical review [6].

With HTML5.1 in PR, we don't want to make any substantive changes... of course, we do hope to continue editing and publishing HTML, so the updates in the 5.2 editor's draft will eventually replace 5.1, so it's not the end of the world if we miss this...

2.1 is a Rec, so it's easier to publish a

new version than to update the Rec.

    <dt id="biblio-whatwg-url">[WHATWG-URL]
-   <dd>Anne van Kesteren. <a href="https://url.spec.whatwg.org/">URL Standard</a>. Living Standard. URL: <a href="https://url.spec.whatwg.org/">https://url.spec.whatwg.org/</a>
+   <dd>
+     Anne van Kesteren. <a href="https://url.spec.whatwg.org/">URL Standard</a>. Living Standard. URL: <a href="https://url.spec.whatwg.org/">https://url.spec.whatwg.org/</a>
+     <p class="note" role="note">Note: URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider <a data-link-type="biblio" href="#biblio-rfc3986">[RFC3986]</a> and <a data-link-type="biblio" href="#biblio-rfc3987">[RFC3987]</a>.</p>
+   </dd>

XForms 1.0 is a W3C recommendation; it was the most implementated W3C specification at time of going to recommendation ever!

A couple Edge perf folks said they would look into changing Edge for this (but aren't able to comment on this issue since it's in the WHATWG)

This is the "Level 1" Version of WebIDL, it contains parts of the main Editor's copy [WEBIDL] that are considered stable, implemented and tested. Implementors who do not need to reference a stable version of WebIDL should defer to the Editor's copy [WEBIDL] only, as it may contain updated algorithm and definitions; this specification is suitable for reference by other specification authors in so far as it wholly contains the syntax definitions used in the citing document. New syntax definitions will be added in the next Level of WebIDL.

I recently took the action to check with

the W3C Management (W3M) and I want to share with you all what I learned.

Unfortunately my doubts about the possibility of getting our WG extended

were confirmed. The W3C Advisory Board (AB) and membership in general has

requested that W3M no longer just extend WGs on their own accord but

instead submit WG extensions to the Advisory Committee (AC) - full

membership - for review, just like when a WG is initially launched. This

is a heavy process which requires explaining how a few additional months

will make a difference and without a vibrant set of members supporting the

request this isn't going to happen. So, the bottom line is that we cannot

count on an extension.

If W3C DOM is updated to match implementations (and kept up-to-date) on things like this, then we could reference DOM4 instead of WHATWG-DOM.

Note:URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider [RFC3986] [RFC3987]. The W3C URL specification was aimed to define the term URL, various algorithms for dealing with URLs, and an API for constructing, parsing, and resolving URLs.

Work on this document has been discontinued and it should not be referenced or used as a basis for implementation. Please refer to the URL Continually Updated Specification for the latest available specification of this API.

Note: URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider [RFC3986] and [RFC3987]. The URL specification defines the term URL, various algorithms for dealing with URLs, and an API for constructing, parsing, and resolving URLs. Developers are advised to keep abreast of the latest URL developments by tracking the progress of https://url.spec.whatwg.org/.

As a word of caution, there are notable differences in the manner in which Web browsers and other software stacks outside the HTML context handle URLs. While no changes would be accepted to URL processing that would break existing Web content, some important parts of URL processing should therefore be considered as implementation-defined (e.g. parsing file: URLs or operating on URLs that would be syntax errors under the [RFC3986] [RFC3987] syntax).

Anne van Kesteren. WHATWG. URL Standard. Continually Updated Specification. URL: https://url.spec.whatwg.org/

Anne van Kesteren. XMLHttpRequest Standard. Continually Updated Specification. URL: https://xhr.spec.whatwg.org/

Anne van Kesteren. XMLHttpRequest Standard. Continually Updated Specification. URL: https://xhr.spec.whatwg.org/

Anne van Kesteren. Fetch Standard. Continually Updated Specification. URL: https://fetch.spec.whatwg.org/

As of today the Web community lacks a sufficiently complete, reliable, interoperable, and tested specification for the manner in which content sniffing takes place on the Web. We encourage implementers to exercise caution in this area as the Web community makes progress towards addressing this issue.

Gordon P. Hemsley. MIME Sniffing Standard. Continually Updated Specification. URL: https://mimesniff.spec.whatwg.org/

Note: URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider [RFC3986] [RFC3987]. The W3C URL specification defines the term URL, various algorithms for dealing with URLs, and an API for constructing, parsing, and resolving URLs. Developers of Web browsers are advised to keep abreast of the latest URL developments by tracking the progress of https://url.spec.whatwg.org/. We expect that the W3C URL draft will evolve along the Recommendation track as the community converges on a definition of URL processing.

Most of the URL-related terms used in the HTML specification (URL, absolute URL, relative URL, relative schemes, scheme component, scheme data, username, password, host, port, path, query, fragment, percent encode, get the base, and UTF-8 percent encode) can be straightforwardly mapped to the terminology of [RFC3986] [RFC3987]. The URLUtils (formerly known as URL) collection of attributes (e.g. href and protocol) and its required definitions (input, query encoding, url, update steps, set the input) are considered common practice nowadays. Some of the URL-related terms are still being refined (e.g. URL parser, parse errors, URL serializer, default encode set, and percent decode).

As a word of caution, there are notable differences in the manner in which Web browsers and other software stacks outside the HTML context handle URLs. While no changes would be accepted to URL processing that would break existing Web content, some important parts of URL processing should therefore be considered as implementation-defined (e.g. parsing file: URLs or operating on URLs that would be syntax errors under the [RFC3986] [RFC3987] syntax).

Anne van Kesteren. URL Standard. Continually Updated Specification. URL: https://url.spec.whatwg.org/

A conforming user agent MUST support at least the subset of the functionality defined in DOM4 that this specification relies upon; in particular, it MUST support Promises and DOMException. [DOM4]

A. Exceptions and Errors

A.1 Exceptions

This entire section was moved out into IDL. Refer to [Web IDL] for latest definition.

The terms and algorithms ArrayBuffer, ArrayBufferView, and structured clone, are defined by the HTML specification [HTML].

Is this specification dependent on material in the WhatWG DOM and HTML

normative references that is not present in the W3C specifications? If

so, what are those dependencies?

We kept the source base stable (unmaintained) because LDP 1.0 is closed, and the reports delivered.

Bad news is that this seems to have fallen through the cracks in practice and drafts of the TV Control API have actually been published under the more restrictive W3C Document License. I apologize for this. That's an oversight. Next update we publish (either a Working Draft or a WG Note) should use the right license, and I prepared a PR for that

I'm coming round to the view that we need a CR[1]. In 1999, RDF M+S was

promoted prematurely to REC with minimal implementation experience;

we're still cleaning up the resulting mess. I fear we're about to do the

same thing regarding RDF's relationship to XML.

RESOLUTION: Adopt the optional HTTP 410 Gone behavior in WebSub, if Director says we can do it without restarting CR clock

marcoscaceres

Oh, thank goodness (well, thank Annevk) they gave up on the URL spec. Will update the reference... now, can we get the same for DOM and HTML? :nerd_face:

ianbjacobs

I believe that we can refer to WhatWG specs that have material not present in W3C versions.

The WebPlat charter has just been extended until 31 December, whilst we

wait for the outcome of the W3C/WHATWG negotiations.