W3C Process

W3C Process

[3] W3C Process は、 W3C における標準化の過程、あるいはそれを記述した文書です。 W3C では単に Process と呼ぶことがよくあります。

仕様書

勧告過程

[116] WDLCWDCRPRREC と進みます。

[119] 一旦 REC になったものの改訂は PERREC と進みます。

WG Note

[117] 勧告過程で開発されたものの中断される時は、 WG Note として最後に出版します。

[118] 他に、元から WG Note として出版することを目標に開発されることもあります。

[182] WG Note 参照。

W3C Process がいかれている例

[54] Process にあわせるために仕様書の技術的内容が歪められることが W3C ではよくあります。本末転倒であるとして W3C 外からしばしば批判されており、 W3CProcess の改善を議論していますが、2014年に小改訂がようやく行われた程度で、 改革はなかなか進まないようです。

[55] W3C 内部ではそれほど問題意識が高くないのかもしれません。

[252] Process 自体よりも、その運用に政治的な闇を多く抱えています。

[123] SVG Tiny 1.2

[122] XHTML Basic 1.1 2e

[121] XHTML Vocabulary

[1] OWL 2 Web Ontology Language Document Overview ( 版) <http://www.w3.org/TR/2009/REC-owl2-overview-20091027/#sotd-xml-dep>

[2] rdf:PlainLiteral: A Datatype for RDF Plain Literals ( ( 版)) <http://www.w3.org/TR/2009/REC-rdf-plain-literal-20091027/#sotd-xml-dep>

[4] Cascading Style Sheets (CSS) Snapshot 2007 ( ( 版)) <http://www.w3.org/TR/2011/NOTE-css-beijing-20110512/#w3c-process>

[5] Cascading Style Sheets (CSS) Snapshot 2010 ( ( 版)) <http://www.w3.org/TR/2011/NOTE-css-2010-20110512/#w3c-process>

[6] Re: Obsolescence notices on old specifications, again ( (Ian Hickson 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2012Jan/0032.html>

[7] PROV-DM: The PROV Data Model ( ( 版)) <http://www.w3.org/TR/2013/REC-prov-dm-20130430/#conformance-to-rdf-datatypes>

[8] JSON-LD 1.0 Processing Algorithms and API ( ( 版)) <http://www.w3.org/TR/2013/WD-json-ld-api-20130516/#the-application-programming-interface>

[9] Page Visibility ( ( 版)) <http://www.w3.org/TR/2013/REC-page-visibility-20130514/#status-of-this-document>

[10] HTML Working Group Charter ( ( 版)) <http://www.w3.org/2013/09/html-charter.html>

[11] FAQ Regarding HTML Working Group Charter License Experiment ( ( 版)) <http://www.w3.org/2013/09/html-faq.html>

[12] Re: Next steps for Web Events WG ( (Arthur Barstow 著, 版)) <http://lists.w3.org/Archives/Public/public-webevents/2013JulSep/0005.html>

[13] Normative References ( ( 版)) <http://www.w3.org/2013/09/normative-references>

[14] [CSSWG] Minutes Telecon 2013-10-30 ( (Dael Jackson 著, 版)) <http://lists.w3.org/Archives/Public/www-style/2013Oct/0744.html>

[15] [CSSWG] Minutes Telecon 2013-10-30 ( (Dael Jackson 著, 版)) <http://lists.w3.org/Archives/Public/www-style/2013Oct/0744.html>

[16] Re: Current process encourages monkey patching ( (Anne van Kesteren 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2014Feb/0010.html>

[17] IRC logs: freenode / #whatwg / 20140415 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140415#l-724>

[18] RDF 1.1 XML Syntax ( ( 版)) <https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-xml/index.html#h4_parseTypeLiteralPropertyElt>

[19] Extensible Markup Language (XML) 1.1 (Second Edition) ( ( 版)) <http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-CharNorm>

[20] IRC logs: freenode / #whatwg / 20140505 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140505#l-231>

[21] Copy of Promises Spec Draft as of October 2013 ( ( 版)) <http://www.w3.org/2013/10/json-ld-api/snapshot-promises-draft/>

[22] IRC logs: freenode / #whatwg / 20140625 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140625>

[23] Normative References ( ( 版)) <http://www.w3.org/2013/09/normative-references>

[24] Re: WebIDL Spec Status ( (Boris Zbarsky 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/1015.html>

[25] Re: WebIDL Spec Status ( (Chris Wilson 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/1023.html>

[26] Re: XMLHttpRequest Level 1- specification history ( (Ian Hickson 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0789.html>

[27] Re: PubReq: new WD of Shadow DOM on June 12 ( (Jérémie Astori 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2014Jun/0006.html>

[28] ProcessTransition2014 - W3C Wiki ( ( 版)) <http://www.w3.org/wiki/ProcessTransition2014>

[29] World Wide Web Consortium Process Document ( ( 版)) <http://www.w3.org/2014/Process-20140801/>

[30] Intent to Implement: Standby API - Google グループ ( ( 版)) <https://groups.google.com/a/chromium.org/d/msg/blink-dev/SzVuAi2KRhA/ziJt4Wo98uwJ>

[31] Re: First Draft of W3C version of URL Spec ( (Marcos Caceres 著, 版)) <http://lists.w3.org/Archives/Public/public-w3process/2014Aug/0133.html>

[32] Publishing documents under the 2014 Process ( (Ian Jacobs 著, 版)) <http://lists.w3.org/Archives/Public/spec-prod/2014JulSep/0065.html>

[33] [Pubrules] Revised Proposed changes regarding references to editors' drafts ( (Ian Jacobs 著, 版)) <http://lists.w3.org/Archives/Public/spec-prod/2014JulSep/0068.html>

[34] ProcessTransition2014 - W3C Wiki ( ( 版)) <https://www.w3.org/wiki/ProcessTransition2014>

[35] Domenic Denicola on Twitter: "Wow. W3C explicitly blacklists referencing WHATWG specs http://t.co/np984MJL9Y Need more evidence the W3C is behind the times?" ( ( 版)) <https://twitter.com/domenic/status/508964136366391297>

[36] ISSUE-124: Normative Reference policy should explicitly black list WHATWG specs - Revising W3C Process Community Group Tracker ( ( 版)) <http://www.w3.org/community/w3process/track/issues/124>

[37] Re: w3process-ISSUE-124 (WHATWG-blacklist): Normative Reference policy should explicitly black list WHATWG specs [Normative Reference Policy] ( (Arthur Barstow 著, 版)) <http://lists.w3.org/Archives/Public/public-w3process/2014Sep/0053.html>

[38] Re: publishing new WD of URL spec ( (Robin Berjon 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0517.html>

[39] Re: publishing new WD of URL spec ( (Boris Zbarsky 著, 版)) <http://lists.w3.org/Archives/Public/www-tag/2014Sep/0016.html>

[40] Re: publishing new WD of URL spec ( (Philippe Le Hegaret 著, 版)) <http://lists.w3.org/Archives/Public/public-w3process/2014Sep/0083.html>

[41] Sam Ruby: The URL Mess ( 版) <http://intertwingly.net/blog/2014/09/16/The-URL-Mess>

[42] minor fixes · 5665b66 · w3c/html ( ( 版)) <https://github.com/w3c/html/commit/5665b66d3bc7720fcaaeff5817e6eacbf782d835>

[43] crazy hoop jumping about URLs · 5b04c84 · w3c/html ( ( 版)) <https://github.com/w3c/html/commit/5b04c84af9bb460fa0ffddb5af7fac41a17b1938>

[44] IRC logs: freenode / #whatwg / 20140917 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140917#l-76>

[45] HTML5 ( ( 版)) <http://www.w3.org/TR/2014/PR-html5-20140916/>

[46] proposal: have W3C HTML5 reference dated WHATWG URL standard rather than W3C copy ( (Tantek Çelik 著, 版)) <http://lists.w3.org/Archives/Public/public-html/2014Sep/0061.html>

[47] Re: w3process-ISSUE-124 (WHATWG-blacklist): Normative Reference policy should explicitly black list WHATWG specs [Normative Reference Policy] ( (Tim Berners-Lee 著, 版)) <http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0021.html>

[48] Re: w3process-ISSUE-124 (WHATWG-blacklist): Normative Reference policy should explicitly black list WHATWG specs [Normative Reference Policy] ( (Ian Hickson 著, 版)) <http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0036.html>

[214] 大手芸能事務所「(元所属タレントを出演させるなという) 圧力など存在しない」

W3C 「(WHATWG仕様書を引用するなという) 圧力など存在しない」

[215] この一連の騒動の後 Arthur Barstow が座長だった WebApps WG が取り潰されたのは W3C の圧力だ・・・とかいうのはただの陰謀論でしょうけど、 その後一身上の都合で引退しちゃったのはこの騒動と無関係ではないでしょうね...

[216] 結局 Arthur Barstow が勝手に空気読みすぎてただけみたいな感じで有耶無耶にされちゃいましたけど、 その後何年も (この記事で以降に示している通り) W3C仕様書から WHATWG仕様書をまともに引用できずに意味不明な破綻を繰り返していたり、 HTML 5.1HTML 5.2DOM4DOM 4.1 のような粗大ごみをがんばって開発し続けたりしているわけなんで、 W3C 上層部とかの圧力が何もないなら、 W3C は上から下までとんだ無能集団ってことになりますよね。。。

[49] IRC logs: freenode / #whatwg / 20141003 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20141003>

[50] Publication Workflow ( ( 版)) <http://www.w3.org/2014/08/pubworkflow.html>

[51] ( ( 版)) <http://dev.w3.org/html5/2014/10/url-ref.html>

[52] ( ( 版)) <http://dev.w3.org/html5/2014/10/url-ref.html>

[53] Re: [xhr] Questions on the future of the XHR spec, W3C snapshot ( (Arthur Barstow 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0166.html>

[56] IRC logs: freenode / #whatwg / 20141028 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20141028>

[57] HTML/wg/UrlStatus - W3C Wiki ( ( 版)) <https://www.w3.org/wiki/HTML/wg/UrlStatus#Formal_Objections>

[58] [url] follow-ups from the TPAC F2F Meeting ( (Sam Ruby 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0315.html>

[59] W3C - WHATWG Wiki ( ( 版)) <https://wiki.whatwg.org/wiki/W3C>

[60] URL spec and copying ( (Sam Ruby 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2014Nov/0023.html>

[61] Re: PSA: Sam Ruby is co-Editor of URL spec ( (Sam Ruby 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0437.html>

[62] Sam Ruby: WHATWG/W3C Collaboration ( 版) <http://intertwingly.net/blog/2014/11/20/WHATWG-W3C-Collaboration>

[63] Re: PSA: Sam Ruby is co-Editor of URL spec ( (Anne van Kesteren 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2014Nov/0029.html>

[64] URL Collaboration Work (was: Sam Ruby is co-Editor of URL spec) ( (Sam Ruby 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2014Nov/0039.html>

[65] Web Platform Specs ( ( 版)) <https://specs.webplatform.org/docs/>

[66] Re: PSA: Sam Ruby is co-Editor of URL spec ( (Sam Ruby 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2014Nov/0056.html>

[67] IRC logs: freenode / #whatwg / 20141126 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20141126#l-701>

[68] URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec) ( (Sam Ruby 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0520.html>

[69] url/workmode.md at develop · webspecs/url ( ( 版)) <https://github.com/webspecs/url/blob/develop/docs/workmode.md>

[70] RE: Help with WebIDL v1? ( (Travis Leithead 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0518.html>

[71] RE: WebIDL v1 vs. v2 ( (Domenic Denicola 著, 版)) <http://lists.w3.org/Archives/Public/www-tag/2014Dec/0008.html>

[72] Re: [url] Requests for Feedback (was Feedback from TPAC) ( (Arthur Barstow 著, 版)) <http://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0025.html>

[73] ( ( 版)) <http://www.ietf.org/proceedings/91/minutes/minutes-91-appsawg>

[74] Mike West on Twitter: "WebCrypto published as CR: http://t.co/wjRRsOBRnm. @sleevi_: Congrats?" ( ( 版)) <https://twitter.com/mikewest/status/543139903933280256>

[75] Bug 27727 – Remove DOMError from IDB ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27727#c1>

[76] Indexed Database API ( ( 版)) <http://www.w3.org/TR/2015/REC-IndexedDB-20150108/>

[77] Sam Ruby: URL Work Status ( 版) <http://intertwingly.net/blog/2015/01/11/URL-Work-Status>

[78] CSP2: Fork a draft of CSP2. · 68d5fec · w3c/webappsec ( ( 版)) <https://github.com/w3c/webappsec/commit/68d5fecbf626420d2d988a5d9e7170a00b508c7c>

[79] Pointer Events Published (was: Pointer Events Recommendation delayed by a Formal Objection) (Doug Schepers 著, 版) <https://lists.w3.org/Archives/Public/public-pointer-events/2015JanMar/0014.html>

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.

[80] David Baron's weblog: Open licensing at the W3C ( 版) <http://dbaron.org/log/20130522-w3c-licensing>

[81] Relicensing Unfinished W3C Specifications ( ( 版)) <http://www.w3.org/2014/12/relicense.html>

[82] meetings/04-21-minutes.md at gh-pages · w3ctag/meetings ( 版) <https://github.com/w3ctag/meetings/blob/gh-pages/2015/04-sfo/04-21-minutes.md>

[83] fabien_gandon on Twitter: ""implementing a standard is like walking on water: it's much easier when it is frozen." quote #ac-rep meeting @w3c" ( 版) <https://twitter.com/fabien_gandon/status/596229047476170753>

[84] IRC logs: freenode / #whatwg / 20150507 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20150507#l-447>

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

[85] Re: Web Notification Working Group Charter Extended (Michael[tm] Smith 著, 版) <https://lists.w3.org/Archives/Public/public-web-notification/2015May/0004.html>

[86] Implementing ATAG 2.0 ( ( 版)) <http://www.w3.org/TR/2015/WD-IMPLEMENTING-ATAG20-20150604/>

[87] Point to the Streams Standard as that's actively being worked on by annevk · Pull Request #195 · WebAssembly/design ( 版) <https://github.com/WebAssembly/design/pull/195>

[88] It is also necessary to join the CG before filing issues by lukewagner · Pull Request #199 · WebAssembly/design ( 版) <https://github.com/WebAssembly/design/pull/199>

[89] SVG Working Group Teleconference -- 09 Jun 2015 ( 版) <http://www.w3.org/2015/06/09-svg-minutes.html>

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

[90] Widget Interface ( 版) <http://w3c.github.io/packaged-webapps/api/Overview.html>

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

[91] Widget Interface ( 版) <http://www.w3.org/TR/widgets-apis/>

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.

[92] Re: [WebIDL] T[] migration (Boris Zbarsky 著, 版) <https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0170.html>

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

[93] World Wide Web Consortium Process Document ( ( 版)) <http://www.w3.org/2015/Process-20150901/>

[94] ProcessTransition2015 - W3C Wiki ( ( 版)) <https://www.w3.org/wiki/ProcessTransition2015>

[95] State Chart XML (SCXML): State Machine Notation for Control Abstraction ( 版) <http://www.w3.org/TR/2015/REC-scxml-20150901/>

[96] >>95 は、なぜか1年以上前に出版済みの RFC 7303 を無視して、 14年も前の RFC 3023 を参照しています。

[98] Web Notifications ( 版) <http://www.w3.org/TR/2015/PR-notifications-20150910/>

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.

[97] >>98 用途不詳として削除されたことは認識しつつ、なおも仕様書から削除せず実装を求める (= 相互運用性に害をなそうとする) W3C まじ意味不wwww

[99] Normative references to Workers. (Mike West 著, 版) <https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0361.html>

[100] Re: Normative references to Workers. (Arthur Barstow 著, 版) <https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0367.html>

[101] Fork tracking - WHATWG Wiki ( 版) <https://wiki.whatwg.org/wiki/Fork_tracking>

[102] IRC logs: freenode / #whatwg / 20150929 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20150929>

[103] Mozilla comments on Web Platform and Timed Media (L. David Baron 著, 版) <https://lists.w3.org/Archives/Public/www-archive/2015Sep/0016.html>

[104] A transcript extension for HTML ( ( 版)) <http://www.w3.org/TR/2015/NOTE-html-transcript-src-20151001/>

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.

[105] Normative References ( 版) <http://www.w3.org/2013/09/normative-references>

[106] Re: App-to-App interaction APIs - one more time, with feeling (Chaals McCathie Nevile 著, 版) <https://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0084.html>

[107] Web Notifications ( 版) <http://www.w3.org/TR/2015/REC-notifications-20151022/>

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.

[108] W3C DOM4 ( ( 版)) <http://www.w3.org/TR/2015/REC-dom-20151119/>

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

[113] >>108 のような深刻な課題 (原文では赤枠に赤字で表示されてます。) が残っていても W3C勧告にはなってしまうんだ...

[130] >>108 真下に

It is a stable document and may be used as reference material or cited from another document.

とか書いてあって、「stable」とは一体、と気になるところではあるのですが、 W3C 職員の発言 >>131 によると /TR/ 以下の日付が入った URL で出版されたら以後変更されないことを指しているようです (その「変更されない」 ポリシーも実はがばがばなんですけどねぇ...)。

[132] おそらく元々は不安定な技術を勧告とするのは好ましくない、 勧告となったのは安定した以後変更されない安心して利用できるものだ、 という趣旨だったと推測するのですが、形骸化しちゃったんでしょうねぇ。 この「安定」の基準だったら、 GitHub に置いてある ED も全部「安定」しているといっても良い (むしろ /TR/ より安定している) ことに...
[111] W3C DOM4 ( ( 版)) <http://www.w3.org/TR/2015/REC-dom-20151119/>

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

[112] W3C DOM4 ( ( 版)) <http://www.w3.org/TR/2015/REC-dom-20151119/>

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

[109] W3C DOM4 ( ( 版)) <http://www.w3.org/TR/2015/REC-dom-20151119/>

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.

[110] Selectors Level 4 がまだ WD なので >>109 のように一部の用語だけ無理矢理コピペしている一方、 Selectors Level 4 は normative reference になっている。不安定な仕様を引用しないみたいな指針は何のためにあるのか。

[114] HTML Canvas 2D Context ( ( 版)) <http://www.w3.org/TR/2015/REC-2dcontext-20151119/>

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.

[115] >>114 の注記が DOM4 にないのはなぜだろう。 Selectors Level 4 等の変更の影響を受ける可能性があると思ったのだろうか。 (だとしたらなんでそんなものをW3C勧告にしたのか。)

[120] FW: New W3C publication requirements as of March 1 (Léonie Watson 著, 版) <https://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0106.html>

[124] Here's the list of all the 2D Context API specs I could find at the W3C as of March 4th 2014 ( 版) <http://damowmow.com/temp/canvas-specs>

[125] Large custom element spec rewrite to implement some F2F decisions · w3c/webcomponents@d95392f ( 版) <https://github.com/w3c/webcomponents/commit/d95392f734895b2c72e1822f464dd70a22b322a4#commitcomment-16980405>

[126] Revert "Revert edits to custom elements made by me for process reasons" · w3c/webcomponents@9d349ee ( 版) <https://github.com/w3c/webcomponents/commit/9d349eed0182c4a2c04e9da1676af2b2c41fdb9c>

[127] Upstream Shadow DOM spec to DOM/HTML Standard · Issue #377 · w3c/webcomponents ( 版) <https://github.com/w3c/webcomponents/issues/377#issuecomment-206030809>

[128] [CSS21] Reverted some changes to remain exactly equal to the REC, typ… · w3c/csswg-drafts@93f2718 ( 版) <https://github.com/w3c/csswg-drafts/commit/93f2718a87d3875d659bc2965f59f0b3f20832b3>

[129] Re: webappsec-ACTION-216: Examine fetch refs for stability (Anne van Kesteren 著, 版) <https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0037.html>

[131] Re: webappsec-ACTION-216: Examine fetch refs for stability (Wendy Seltzer 著, 版) <https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0040.html>

[133] Where is the spec? · Issue #481 · w3c/webcomponents ( 版) <https://github.com/w3c/webcomponents/issues/481>

[134] New Web Components editor (Léonie Watson 著, 版) <https://lists.w3.org/Archives/Public/public-webapps/2016AprJun/0068.html>

[135] Integrate with HTML, part 1 of n by domenic · Pull Request #42 · w3c/webappsec-referrer-policy ( ()) <https://github.com/w3c/webappsec-referrer-policy/pull/42>

[136] Re: webappsec-ACTION-216: Examine fetch refs for stability ( (Wendy Seltzer著, )) <https://lists.w3.org/Archives/Public/public-webappsec/2016May/0002.html>

[137] Figure out how to manage normative dependencies to WHATWG HTML for features not in W3C HTML for CR/REC · Issue #9 · w3c/webappsec-secure-contexts ( ()) <https://github.com/w3c/webappsec-secure-contexts/issues/9>

[138] Integrate with HTML, part 1 of n by domenic · Pull Request #42 · w3c/webappsec-referrer-policy ( ()) <https://github.com/w3c/webappsec-referrer-policy/pull/42>

[139] Redirect on preflighted CORS requests generally impossible · Issue #204 · whatwg/fetch ( ()) <https://github.com/whatwg/fetch/issues/204#issuecomment-184257430>

[140] Web Application Security Working Group F2F -- 17 May 2016 ( ()) <https://www.w3.org/2016/05/17-webappsec-minutes.html>

[141] standards-track/bp.md at master · w3c/standards-track ( ()) <https://github.com/w3c/standards-track/blob/master/bp.md>

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

[142] [e] (0) Remove some examples that use HTML5 features from the W3C cop… ( (Hixie著, )) <https://github.com/whatwg/html/commit/15459330f52a7633d964ef23f4c35ff5f4330dba>

[143] RE: Quick update on WebIDL "Level 1" (Marcos Caceres著, ) <https://lists.w3.org/Archives/Public/public-webapps/2016JulSep/0007.html>

[144] Clarify usage of various terms from other documents. (mikewest著, ) <https://github.com/w3c/webappsec-secure-contexts/commit/64a540b24dddf3accd1dbc7c683d8c3ce8d88ddb>

[145] EventListenerOptions and passive event listeners - move to WICG? - APIs - WICG () <https://discourse.wicg.io/t/eventlisteneroptions-and-passive-event-listeners-move-to-wicg/1386/9>

[146] W3C Proposed Recommendation: longdesc () <https://lists.mozilla.org/pipermail/dev-platform/2015-January/008233.html>

[147] XML Core Working Group and XML Processing Model Working Group are now Closed (Xueyuan Jia著, ) <https://lists.w3.org/Archives/Public/public-xml-core-wg/2016Aug/0000.html>

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

[148] W3C Process 2016 (Jeff Jaffe著, ) <https://lists.w3.org/Archives/Public/public-w3process/2016Aug/0017.html>

[149] The fetch step in HTML5.1's resource fetch algorithm no longer exists · Issue #99 · w3c/media-source () <https://github.com/w3c/media-source/issues/99>

[150] CFC to migrate to the Web Platform WG · Issue #49 · WICG/EventListenerOptions () <https://github.com/WICG/EventListenerOptions/issues/49>

[151] This recommendation should be definitely corected relative to the current specification of WHATWG · Issue #3 · w3c/dom () <https://github.com/w3c/dom/issues/3>

[152] Unclear conformance of attributes on <table> element · Issue #582 · w3c/html () <https://github.com/w3c/html/issues/582#issuecomment-246063709>

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

[153] PR だから HTML 5.1 は変更したくないが HTML 5.2 があるから問題ない、と。 HTML 5.1バグ修正より手続き優先で、W3C勧告に進めることだけが目的の捨て仕様書なんですね...

[154] Re: [css22] History (Tab Atkins Jr.著, ) <https://lists.w3.org/Archives/Public/www-style/2016Sep/0033.html>

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

new version than to update the Rec.

[155] CR comments from @plehegar. (@plehegar著, ) <https://github.com/w3c/webappsec-secure-contexts/commit/480483f79b8cf85b5a64d63b77a80126f903f2af>

[156] CR comments from @plehegar. (@plehegar著, ) <https://github.com/w3c/webappsec-secure-contexts/commit/480483f79b8cf85b5a64d63b77a80126f903f2af>
    <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>

[157] W3C は未だに URL Standard を否定しているのか(驚愕)

[158] Steven Pemberton () <http://homepages.cwi.nl/~steven/>

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

[159] [css-transitions-2] Remove new transition events from level 2 now tha… (birtles著, ) <https://github.com/w3c/csswg-drafts/commit/f09d150dcc952bffdc3476ad2a4ace1b30613ef8>

[160] [Fwd: [wbs] response to 'Call for Review: HTML 5.1 is W3C Proposed Recommendation'] (L. David Baron著, ) <https://lists.w3.org/Archives/Public/www-archive/2016Oct/0003.html>

[161] Upstream Shadow DOM spec to DOM/HTML Standard · Issue #377 · w3c/webcomponents () <https://github.com/w3c/webcomponents/issues/377>

[162] Upstream the `integrity` attribute to HTML. · Issue #31 · w3c/webappsec-subresource-integrity () <https://github.com/w3c/webappsec-subresource-integrity/issues/31>

[163] High resolution timing for events · Issue #23 · whatwg/dom () <https://github.com/whatwg/dom/issues/23>

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)

[164] Attr and NamedNodeMap in DOM4 are inconsistent · Issue #4 · w3c/dom () <https://github.com/w3c/dom/issues/4>

[165] Incorrect URL to a DTD for the named entity declarations · Issue #731 · w3c/html () <https://github.com/w3c/html/issues/731>

[166] たしかに 404 だな。昔は W3C の出版時のチェック項目にリンク切れ検査があった気がするけど、今はやってないんだろうか。 WD ならともかく REC なのに規定の一部を構成するファイルが 404 とか大丈夫なのか?

[167] Google's incubation-first standards process (Rick Byers著, ) <https://lists.w3.org/Archives/Public/www-style/2016Dec/0011.html>

[168] [CSS2] Proposed process for maintaining CSS2 (fantasai著, ) <https://lists.w3.org/Archives/Public/www-style/2016Dec/0015.html>

[169] >>168 ものすごく複雑に見えるけど、新機能はもちろん含まれないし相互運用性にも何一つ貢献しそうになくて、 W3C Process を通すことだけしか目的になさそうなのがやばい。

[170] Send HTMLIFrameElement.allowPaymentRequest to HTML spec · Issue #311 · w3c/browser-payment-api () <https://github.com/w3c/browser-payment-api/issues/311>

[171] WebIDL Level 1 () <https://www.w3.org/TR/2016/REC-WebIDL-1-20161215/>

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.

[172] HTML 4 system identifiers are accidentally non-conforming in HTML 5.1 · Issue #754 · w3c/html () <https://github.com/w3c/html/issues/754>

[173] こんな重大なミスに誰も気づかないまま REC になるとか・・・

[174] Migrate HTML 5.0 references to HTML 5.1? · Issue #396 · w3c/presentation-api () <https://github.com/w3c/presentation-api/issues/396>

[175] Check references category and stability · Issue #295 · w3c/presentation-api () <https://github.com/w3c/presentation-api/issues/295>

[176] WG Outlook (Arnaud Le Hors著, ) <https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/0045.html>

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.

[177] [css-style-attr] s/draft/module/ per <https://lists.w3.org/Archives/P…]]> (fantasai著, ) <https://github.com/w3c/csswg-drafts/commit/f7dea62816460c4e84461e6ab880b8e51879eebf>

[178] Re: [css-style-attr] About word "draft" (fantasai著, ) <https://lists.w3.org/Archives/Public/www-style/2016Dec/0117.html>

[179] Add ShadowDOM support from WHATWG-DOM · Issue #13 · w3c/dom () <https://github.com/w3c/dom/issues/13>

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.

[180] Spec references both W3C DOM4 and WHATWG-DOM · Issue #160 · w3c/pointerevents () <https://github.com/w3c/pointerevents/issues/160>

[181] RDFa初期文脈の改訂は、 勧告過程を経ることなく行われるようです。 どの版の初期文脈を実装するかに依って、非互換性が生じることになりますが、 W3C勧告ほど大々的な告知は行われていません。

[217] そういえば WHATWG Living Standard は内容が変わっていくから引用できないだとかなんだとか大騒ぎしているのに、 この初期文脈みたいなのが許されるのはどういう理論なのでしょうか。 置いてある場所が W3CWebサーバーだからセーフとか?

[183] Issue #396: Migrate HTML 5.0 references to HTML 5.1 by tidoust · Pull Request #404 · w3c/presentation-api () <https://github.com/w3c/presentation-api/pull/404>

[185] URL () <https://www.w3.org/TR/2016/NOTE-url-1-20161206/>

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.

[186] 素直に間違いでしたと言わずに謎の釈明と現実に乖離した RFC 3986RFC 3987 への誘導を続けるのはどうかと思いますが、ようやく正式に W3CURL の開発を止めると明確に表明したのは良いニュースです。 しかし「the URL Continually Updated Specification」 (リンク先は URL Standard) なる意味不明な造語は誰のどういう意図を反映しているのでしょうか。

[184] Webmention () <https://www.w3.org/TR/2017/REC-webmention-20170112/>

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/

[187] そして URL の開発から撤退したにも関わらず、それより後に出版された W3C勧告にもまだ謎の注意書きが残ります。ここでも「Continually Updated Specification」 が出てきます。その直上に 「Anne van Kesteren. WHATWG. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/」 というのがあって、こちらでは普通に「Living Standard」と書いてあるのですがね。

[188] Resource Timing Level 2 () <https://www.w3.org/TR/2016/WD-resource-timing-2-20161103/>

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

[189] Resource Timing Level 1 () <https://www.w3.org/TR/2017/PR-resource-timing-1-20170110/>

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

[190] HTML 5.1: References () <https://www.w3.org/TR/2016/REC-html51-20161101/references.html#normative>

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/

[191] というような用例がこの時期に W3C で現れています。 結局、 Continually Updated Specification というのは W3CWHATWGLiving Standard を参照する時に使う独自の用語のようです。

[192] Google検索によると、普通の文章中で小文字で 「continually updated specification」という語句を使った例は以前から若干数あるものの、 大文字で「Continually Updated Specification」と書いているのはすべて W3C 内で、しかも WHATWG仕様書を参照するためにだけ使われています。

[193] >>185 のせいなのか、「"Continually Updated Specification"」 で検索すると第1位に現れるのは URL Standard です。 URL Standard の本文中には一言も「Continually Updated Specification」 なんて書いてありませんが。。。

[194] こんな独自用語を創造してまで W3C が守りたいものが何なのかは、さっぱりわかりません。

[236] >>235 は普通に 「URL Standard」と書いています。 それが /TR/ に出版したら変な名前に変わっているということは、 W3Cスタッフの意向によるものなのでしょうか。

[246] こちらでは「the Streams Living Standard」というラベルで Streams Standard を参照しています。ということは W3C 的には Living StandardNGワードになっているわけではないはずで、謎は深まるばかりです。


[203] Cannot tell what element owns an attribute · Issue #6 · w3c/dom () <https://github.com/w3c/dom/issues/6>

[204] DOM Standard では数ヶ月前に解決済みの問題について、その劣化コピーの DOM 4.1 には反映されておらず、困惑した人がバグ報告してきたのに対し、 9ヶ月後にやってきた回答が 「WD のスケジュール的に今はやらない」。 問題の指摘をのらりくらりとかわして結局何もやらなかった旧 HTML WG を思い出します。 答えが既に出ている問題で違う解を示したままにし続けているという意味では旧 HTML WG より悪質ともいえます。

[205] Re: [w3c-dom4] And more (Anne van Kesteren著, ) <https://lists.w3.org/Archives/Public/www-dom/2017JanMar/0013.html>

[206] Reference to WebIDL · Issue #408 · w3c/presentation-api () <https://github.com/w3c/presentation-api/issues/408>

[207] Web Cryptography API () <https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/#dependencies>

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]

... となっていて、その [DOM4] は <https://www.w3.org/TR/dom/> を指しています。 現時点で <https://www.w3.org/TR/dom/> にあるのは W3C DOM4 () <https://www.w3.org/TR/2015/REC-dom-20151119/> という1年以上古い版。そしてそこには、

[208] W3C DOM4 () <https://www.w3.org/TR/2015/REC-dom-20151119/#errors>

A. Exceptions and Errors

A.1 Exceptions

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

... という意味不明な一節があって、 DOMException は確かにそこで定義はされているのですが。 「was moved out」ということで既に DOM4 には属さないとも読めますが、 この章には特に non-normative とは書いてなくて、 「All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.」 と書いてある以上、この章も DOM4規定の一部です。 DOM4W3C勧告になった時点で Web IDLW3C勧告では無かったので移動前の古い内容をそのまま残したのでしょうが... 「Refer to [Web IDL] for latest definition」に従って Web IDL を参照するなら DOM4 のこの章に存在価値はありませんし、 W3C勧告の「格」を重視して DOM4 に従うのは馬鹿げています。 W3C は読者に何を期待しているのでしょうか。

[209] それよりも問題なのは、 WebCrypto が参照している PromisesDOM4 には出てこないことです。確かにかつて PromiseDOM Standard に含まれていましたが (Promises ではありません。)、 かなり前に ECMAScript に移動しています。 DOM4 には「promise」も「promises」も 1回も出てきません。

[210] W3C/TR/Promise が存在していたのは 2013年の FPWD: W3C DOM4 () <https://www.w3.org/TR/2013/WD-dom-20131107/#promises> にまで遡ります (章名は「Promises」だが機能は「Promise」)。 この時点で既に DOM4WHATWG DOM Standardコピペでしたが、 Promise は仕様の再検討に入っていて、 旧仕様が削除されて GitHub へのリンクに置き換わっていました。 つまり規定そのものは含まれていませんでした。 次の WD では章ごと削除されています。

[211] つまり WebCrypto は4年も前の古い仕様書を参照した記述があって、 最新の状態に改訂されないまま W3C勧告になったということになります。

[212] Web Cryptography API () <https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/#terminology>

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

... とあってその [HTML] とは <https://www.w3.org/TR/html51/> で、 現時点で HTML 5.1 () <https://www.w3.org/TR/2016/REC-html51-20161101/> と同じもののようですが、この3つの語のいずれも定義されていません。 一応他の仕様書や新しい名前との対応は説明されているので、 何を表しているかはわかるのですが、 WebCryptoW3C勧告になるよりずっと前に W3C 自身が W3C勧告として出版したはずの文書への参照が間違っているのは大丈夫なのでしょうか。

[213] Re: Update the Editor's Draft Specification Page (Ilya Grigorik著, ) <https://lists.w3.org/Archives/Public/public-web-perf/2017Feb/0007.html>

[218] add ref to normative references policy (wseltzer著, ) <https://github.com/w3c/webappsec/commit/bcbcc28d2a1b0aa7282ce42979cac6ca658d9b4d>

[219] World Wide Web Consortium Process Document () <https://www.w3.org/2017/Process-20170301/>

[220] What’s new in the W3C Process 2017? | W3C Blog () <https://www.w3.org/blog/2017/03/whats-new-in-the-w3c-process-2017/>

[221] Re: Transition Request: WebDriver to Candidate Recommendation (Ralph Swick著, ) <https://lists.w3.org/Archives/Public/www-archive/2017Mar/0001.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?

[222] Reference correct URL spec (closes #19) (mikewest著, ) <https://github.com/w3c/webappsec-clear-site-data/commit/693d24b96dc5c968d671857fc84cecc358a51e6d>

[223] [meta] Publish a revised Candidate Recommendation · Issue #406 · w3c/presentation-api () <https://github.com/w3c/presentation-api/issues/406>

[224] Unsubscribing from the list (Boris Zbarsky著, ) <https://lists.w3.org/Archives/Public/public-web-perf/2017Apr/0000.html>

[225] Please fix at least your broken links, if you want anyone to ever make any sense of your specs · Issue #65 · w3c/navigation-timing () <https://github.com/w3c/navigation-timing/issues/65>

[226] Re: CFC notice: Move Microdata to FPWD (Florian Rivoal著, ) <https://lists.w3.org/Archives/Public/public-webapps/2017AprJun/0018.html>

[227] HTML 4 system identifiers are accidentally non-conforming in HTML 5.1 · Issue #754 · w3c/html () <https://github.com/w3c/html/issues/754>

[228] CFC: Move Microdata to FPWD · Issue #7 · w3c/microdata () <https://github.com/w3c/microdata/issues/7>

[229] Obsoleting some specifications (chaals@yandex-team.ru著, ) <https://lists.w3.org/Archives/Public/www-tag/2017Apr/0010.html>

[230] Upgrading Jena to 3.0.1 · Issue #229 · w3c/ldp-testsuite () <https://github.com/w3c/ldp-testsuite/issues/229#issuecomment-250448306>

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

[231] Update structured cloning for recent changes to HTML by domenic · Pull Request #1108 · w3c/webrtc-pc () <https://github.com/w3c/webrtc-pc/pull/1108#issuecomment-300694559>

[232] revert PR#1108 by fluffy · Pull Request #1171 · w3c/webrtc-pc () <https://github.com/w3c/webrtc-pc/pull/1171>

[233] Steps to transition the spec in case of WG closure (Francois Daoust著, ) <https://lists.w3.org/Archives/Public/public-tvcontrol/2017May/0002.html>

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

[234] need CR? :( Re: Denotation of XMLLiterals: poll (Dan Brickley著, ) <https://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Aug/0086.html>

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.

[237] Update references to W3C if available · Issue #526 · w3c/manifest () <https://github.com/w3c/manifest/issues/526>

[238] This recommendation should be definitely corected relative to the current specification of WHATWG · Issue #3 · w3c/dom () <https://github.com/w3c/dom/issues/3>

[239] Socialwg/2017-05-23-minutes - W3C Wiki () <https://www.w3.org/wiki/Socialwg/2017-05-23-minutes>

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

[240] disable auto publish since the spec is now CR (deniak著, ) <https://github.com/w3c/webdriver/commit/0d62ec62c2c18502cd7ebd20452a0d0a7fc90508>

[241] Use DOM-20151119 for DOM reference (dontcallmedom著, ) <https://github.com/w3c/resource-timing/commit/1264d9247931b7a1e647ac8eeac2cd9f6a6c40d6>

[242] Use /TR/hr-time-2 for in-spec links (dontcallmedom著, ) <https://github.com/w3c/resource-timing/commit/bd71543d20925029467aade958a1efc6caf9cec1>

[243] Use canonical TR link for service workers (dontcallmedom著, ) <https://github.com/w3c/resource-timing/commit/717707e167e9aa71e24c6717150c36bd51b0df59>

[244] Use link to HTML spec consistent with the one in references (dontcallmedom著, ) <https://github.com/w3c/webdriver/commit/b7d7da7deecc0b27e1238063660f8c604a8c349d>

[247] citation to dated version of since-abandoned url spec fork is unusual · Issue #30 · w3c/webpayments-method-identifiers () <https://github.com/w3c/webpayments-method-identifiers/issues/30#issuecomment-293304663>
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.

[248] WHATWG仕様書を引用できないという W3C からの圧力はない、 というのはやっぱり嘘だったんだな・・・ (知ってた)。 きっと W3C仕様書と衝突するものは引用できないという規則だから WHATWG を禁じているわけではない、みたいな理屈で「圧力はない」 ことになっているのだろう・・・。

[249] CFC: Make previous versions of HTML and XHTML obsoleteCFC: Make previous versions of HTML and XHTML obsolete · Issue #86 · w3c/WebPlatformWG () <https://github.com/w3c/WebPlatformWG/issues/86>

[250] Service Workers Working Group Charter () <https://www.w3.org/2017/08/sw-charter.html>

[251] >>250 衆知の事実として Service Workers の開発には WHATWG (特に Fetch Standard) が深く関与しているわけですが (そもそも発端が HTML StandardAppCache の代替ですし)、 Charter には一言も触れられていないとかいう闇よ。

[253] CFC: Publish WebIDL Level 2 as a FPWD · Issue #88 · w3c/WebPlatformWG () <https://github.com/w3c/WebPlatformWG/issues/88>

[254] Upgrade our references to HTML5.2 (dontcallmedom著, ) <https://github.com/w3c/mediacapture-main/commit/a2d6c4d5b2616064e0290c8316b1da70b31e92eb>

[255] Use post-processing to remove unwanted links to HTMLLS (dontcallmedom著, ) <https://github.com/w3c/mediacapture-main/commit/dda86bb286ee82163715dcaf7654ae68480ec258>

[256] Use post-processing to remove unwanted links to HTMLLS by dontcallmedom · Pull Request #480 · w3c/mediacapture-main () <https://github.com/w3c/mediacapture-main/pull/480>

[257] Use defined terms list for autolinks in WebIDL when available · Issue #1372 · w3c/respec () <https://github.com/w3c/respec/issues/1372>

[258] Why is WebIDL-LS added as an "informative" reference? · Issue #1105 · w3c/respec () <https://github.com/w3c/respec/issues/1105>

[259] Merge pull request #1571 from w3c/remove-html-ref (aboba著, ) <https://github.com/w3c/webrtc-pc/commit/802660598d3dd257c4f9af2e512a9b4eee4efd02>

[260] Update CSS Overflow reference to version we need by sideshowbarker · Pull Request #3075 · whatwg/html () <https://github.com/whatwg/html/pull/3075>

[261] OWL Time Ontology adoption - Spatial Data on the Web Working Group () <https://www.w3.org/2015/spatial/wiki/OWL_Time_Ontology_adoption>

[262] >>261W3C勧告となった OWL-Time から Implementation Report としてリンクされているもの。 「OWL-Time は沢山の実装がある」 ということになっている。 Webブラウザーの機能とは「実装」の意味がまったく違う。

[263] Editorial: Remove normative references to APNG and Editing. (cynthia著, ) <https://github.com/w3c/html/commit/e6732fc4268af4c2661495fb3136b52ce76d3810>

[264] [css-ui-4][css-sizing] Moving box-sizing to the right spec · Issue #1906 · w3c/csswg-drafts () <https://github.com/w3c/csswg-drafts/issues/1906>

[265] Incorporate Custom Elements in HTML directly? · Issue #955 · w3c/html () <https://github.com/w3c/html/issues/955>

[266] Use locally defined references / definitions when available for auto links by dontcallmedom · Pull Request #1376 · w3c/respec () <https://github.com/w3c/respec/pull/1376>

[267] HTML5.1-2 "Latest version" points to HTML5.1 · Issue #991 · w3c/html () <https://github.com/w3c/html/issues/991>

[268] Call for Consensus - Publish First Public Working Draft · Issue #12 · w3c/staticrange () <https://github.com/w3c/staticrange/issues/12>

[270]HTML WG 勢が新兵器の Code of Conduct で殴るってのを覚えたかと思ったが、 華麗に失敗してるwww

そして第三者的に MSMichael Champion が寛大な心で WHATWG 勢との仲裁に入ったように見えて、 実は (その時点ではまだ発表されていないが) MSWHATWG に参加することになって Michael はその MS 側のボスなんだな。

というのをわかってから読み返すと、言うほど失礼でもない発言の言葉尻を掴んで Code of Conduct で封殺しようとしたら周りが全員敵でボコボコに殴られてる状況で、 むしろかわいそうになってくるww

[269] This recommendation should be definitely corected relative to the current specification of WHATWG · Issue #3 · w3c/dom () <https://github.com/w3c/dom/issues/3>

[271] WHATWG Working Mode Changes | W3C Blog () <https://www.w3.org/blog/2017/12/whatwg-working-mode-changes/>

[272] [css-overflow] body overflow propagation is less defined than it was in CSS 2.1 · Issue #1905 · w3c/csswg-drafts () <https://github.com/w3c/csswg-drafts/issues/1905>

[273] Re: Pushing the current CR for TPE for REComenndation in 2017 (Bert Bos著, ) <https://lists.w3.org/Archives/Public/public-tracking/2017Nov/0010.html>

[274] W3C の求める「実装経験」はガバガバすぎだな。 仕様書内に含まれる DTDXSLT文字実体が実装可能だと“複数の実装” によって示したことになる >>273 なら、 XML応用は実態が何もなくても仕様書だけ用意すれば実装したことになる。 (現に旧 HTML WG はその手口で利用者が誰もいなかった XHTML m12nREC にした実績があるしなw)

[275] 完全な実装がなくても部分部分の実装がいくつかあればいい、ということは、 全体としては実装不可能な自己矛盾したものが REC に進むこともあり得るわけだ。

[276] High Resolution Time Level 2 () <https://rawgit.com/w3c/tr-design/versioning/versions-proposal.html>

[277] No need to remove HTML biblio entry anymore (dontcallmedom著, ) <https://github.com/w3c/webrtc-pc/commit/2aabb8f09025a0ca5676c036635ccceff10f4ea0>

[278] Fix compatibility with ReSpec 19 by dontcallmedom · Pull Request #1763 · w3c/webrtc-pc () <https://github.com/w3c/webrtc-pc/pull/1763>

[279] Move dataset & other shared IDL attributes from SVGElement to HTMLOrSVGElement · Issue #60 · w3c/svgwg () <https://github.com/w3c/svgwg/issues/60>

[280] HTML Media Capture () <https://www.w3.org/TR/2018/REC-html-media-capture-20180201/>

CEReactionsリンク先が用語の節では Custom Elements WD になっている。その WDNormative References に掲載されている。 過去の他の REC のように「まだ REC に到達していないけど Director が問題ないと認めた」のような注意書きがない。あの意味のない制度はなくなったのだろうか。 ところが実際に使われている IDL素片内のリンク先HTML Standard になっている。そして HTML StandardInformative References に掲載されている。意味不明だ。

そして Normative References には Web IDL の昔の W3C勧告版が掲載されているが、 Informative References には最新の ED が掲載されている。 IDL素片内の DOMStringリンク先ED となっている。何がやりたいのかわからん。

[281] World Wide Web Consortium Process Document () <https://www.w3.org/2018/Process-20180201/>

[282] Should we move more HTMLElement members to HTMLorSVGElement mixin? · Issue #395 · w3c/svgwg () <https://github.com/w3c/svgwg/issues/395>

[283] Move dataset & other shared IDL attributes from SVGElement to HTMLOrSVGElement · Issue #60 · w3c/svgwg () <https://github.com/w3c/svgwg/issues/60>

[284] Update WHATWG-DOM to DOM4 (#240) (NavidZ著, ) <https://github.com/w3c/pointerevents/commit/b0cc670ff252b249f07eecea54ae44321ba27567>

[285] Update WHATWG-DOM to DOM4 by NavidZ · Pull Request #240 · w3c/pointerevents () <https://github.com/w3c/pointerevents/pull/240>

[286] Spec references both W3C DOM4 and WHATWG-DOM · Issue #160 · w3c/pointerevents () <https://github.com/w3c/pointerevents/issues/160>

[287] Replace stray WHATWG HTML reference to W3C HTML (patrickhlauke著, ) <https://github.com/w3c/pointerevents/commit/e9bad530669af40ddf3ae5241c43c766da9d6dca>

[288] Update SVG interfaces to use mixins where possible in all SVG specs. Issue #353 by dirkschulze · Pull Request #376 · w3c/svgwg () <https://github.com/w3c/svgwg/pull/376>

[289] Should we move more HTMLElement members to HTMLorSVGElement mixin? · Issue #395 · w3c/svgwg () <https://github.com/w3c/svgwg/issues/395>

[290] Move dataset & other shared IDL attributes from SVGElement to HTMLOrSVGElement · Issue #60 · w3c/svgwg () <https://github.com/w3c/svgwg/issues/60>

[291] Anchors changed in CSS 2 in-place edit in 2016 · Issue #2551 · w3c/csswg-drafts () <https://github.com/w3c/csswg-drafts/issues/2551>

[292] CfC: Move DOM 4.1 to Candidate Recommendation · Issue #175 · w3c/dom () <https://github.com/w3c/dom/issues/175>

[293] Update structured cloning for recent changes to HTML by stefhak · Pull Request #1810 · w3c/webrtc-pc () <https://github.com/w3c/webrtc-pc/pull/1810>

[294] revert PR#1108 by fluffy · Pull Request #1171 · w3c/webrtc-pc () <https://github.com/w3c/webrtc-pc/pull/1171>

[295] Update structured cloning for recent changes to HTML by domenic · Pull Request #1108 · w3c/webrtc-pc () <https://github.com/w3c/webrtc-pc/pull/1108>

[296] Drop "DOM 4" or any copy/paste efforts · Issue #145 · w3c/charter-html () <https://github.com/w3c/charter-html/issues/145>

[297] Work on HTML · Issue #130 · w3c/charter-html () <https://github.com/w3c/charter-html/issues/130>

[298] update shadow dom to DOM LS (svgeesus著, ) <https://github.com/w3c/svgwg/commit/78af001206073d1b7dd16baff041862da928ff7b>

[299] update shadowdom to DOM LS (svgeesus著, ) <https://github.com/w3c/svgwg/commit/5392c8d9da0b73be6de735ccd753b9fb879fc328>

[300] BinaryType enum is already defined in HTML · Issue #456 · w3c/presentation-api () <https://github.com/w3c/presentation-api/issues/456>

PRREC では WHATWG HTML Standard ではなく W3C HTML 5.x しか引用できないという Director の指示がある、という証言。 引用制限などないという W3C の主張 (>>248) はやっぱり嘘なのか。

ただ最近 REC になった WebDriver () <https://www.w3.org/TR/2018/REC-webdriver1-20180605/#bib-HTML>WHATWG HTML Standard引用してるんだよなー