[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
[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.1、HTML 5.2、DOM4、DOM 4.1 のような粗大ごみをがんばって開発し続けたりしているわけなんで、
W3C 上層部とかの圧力が何もないなら、 W3C は上から下までとんだ無能集団ってことになりますよね。。。
[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
[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
[74] Mike West on Twitter: "WebCrypto published as CR: http://t.co/wjRRsOBRnm. @sleevi_: Congrats?"
( ( 版))
https://twitter.com/mikewest/status/543139903933280256
[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
[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
[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
[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
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.
[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.
[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.
[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.
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
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.
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.
[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.
[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
[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
[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
[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
[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
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
[217] そういえば WHATWGLiving Standard は内容が変わっていくから引用できないだとかなんだとか大騒ぎしているのに、
この初期文脈みたいなのが許されるのはどういう理論なのでしょうか。
置いてある場所が W3C のWebサーバーだからセーフとか?
[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
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/
[187] そして URL の開発から撤退したにも関わらず、それより後に出版された
W3C勧告にもまだ謎の注意書きが残ります。ここでも「Continually Updated Specification」
が出てきます。その直上に
「Anne van Kesteren. WHATWG. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/」
というのがあって、こちらでは普通に「Living Standard」と書いてあるのですがね。
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 というのは W3C
が WHATWG の Living Standard を参照する時に使う独自の用語のようです。
[245] Streams API () https://www.w3.org/TR/2016/NOTE-streams-api-20161129/
[246]
こちらでは「the Streams Living Standard」というラベルで Streams Standard
を参照しています。ということは W3C 的には Living Standard
が NGワードになっているわけではないはずで、謎は深まるばかりです。
[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
[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]
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 の規定の一部です。
DOM4 が W3C勧告になった時点で Web IDL は W3C勧告では無かったので移動前の古い内容をそのまま残したのでしょうが...
「Refer to [Web IDL] for latest definition」に従って Web IDL
を参照するなら DOM4 のこの章に存在価値はありませんし、
W3C勧告の「格」を重視して DOM4 に従うのは馬鹿げています。
W3C は読者に何を期待しているのでしょうか。
[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
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
[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.
[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 Standard の AppCache の代替ですし)、 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
[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
[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
そして第三者的に MS の Michael Champion が寛大な心で WHATWG 勢との仲裁に入ったように見えて、
実は (その時点ではまだ発表されていないが) MS が WHATWG
に参加することになって 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 の求める「実装経験」はガバガバすぎだな。
仕様書内に含まれる DTD と XSLT で文字実体が実装可能だと“複数の実装”
によって示したことになる
>>273 なら、 XML応用は実態が何もなくても仕様書だけ用意すれば実装したことになる。
(現に旧 HTML WG はその手口で利用者が誰もいなかった XHTML m12n を REC
にした実績があるしなw)
[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
になっている。その WD は Normative References に掲載されている。
過去の他の REC のように「まだ REC に到達していないけど Director
が問題ないと認めた」のような注意書きがない。あの意味のない制度はなくなったのだろうか。
ところが実際に使われている IDL素片内のリンク先は
HTML Standard になっている。そして HTML Standard
は Informative 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
[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
PR と REC では 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 を引用してるんだよなー
[301] BinaryType enum is already defined in HTML · Issue #456 · w3c/presentation-api
()
https://github.com/w3c/presentation-api/issues/456
[302] Revert "Remove BinaryType enum (already in HTML) (#457)" by mfoltzgoogle · Pull Request #459 · w3c/presentation-api
()
https://github.com/w3c/presentation-api/pull/459