W3Cブログに、HTML5.1について早速どんな作業があるか、どういう目標で取り組むかについてのブログ記事が出てきた（英文）ので、これを日本語で速報します。訳文は翻訳速度優先ですので、間違いなどありましたら指摘いただけると嬉しいです。

原文：https://www.w3.org/blog/2016/04/working-on-html5-1/

速報訳：

HTML5.1に向けた作業

HTML5は2014年にリリースされたけど、W3C HTML Working Groupなどの努力の結果だったよね。
その意図は、すぐ後に、後押しした出版活動のためだった。定期的なHTML標準の更新ね。
しかし、いくつか意味が違った。予定通りいかなかった。
今ではWeb Platform Working Group (WP WG)が向う方向はHTML 5.1のリリースだ。6ヶ月以内に。そして全体の仕事進行は、我々が意図するところにおいて、HTMLの安定板を出版できるようにすること。W3C勧告として年に1度が目標。

目標

目標の中心は、未来のHTML仕様を現実に沿うようにすること。その結果、仕様を明確に、可能な限りメンテして、もちろん全員の利害関係者に良い提案をできるようにする。そうできるように「HTMLの成功とは何なのか」を考える。

タイムライン

予定では、HTML 5.1勧告を2016年9月に出す。これの意味は、その前の勧告候補(CR)を6月中旬に、最新WCを軸としたCall For Consensus (CFC)に続いて出さないといけない。
簡単に人々がレビューできるようにするには、更新版のWorking Draft (WD)の出版がだいたい月に1回にしないといけない。利便性のために、変更は仕様自体に書こう。

長期的に好ましいのは「整頓の繰り返し」で、定期的な更新をHTMLに行い、その実装を相対的には真っ直ぐなものにすること。そうしているうちに、進行を追い掛けるのにGitHub Pulseを使ったり、@HTML_commitsをフォローしたり、@HTMLWGをツイッターでフォローしたりするだろう。

仕様に向き合う

仕様はGitHubにあるので、みんなPull Requestさえできれば、提案して変更できる。簡単な変更は、例えば文法修正など、とても学習の敷居が低い。ほかの簡単な変更も一般的に受け入れられるものだ。編集者は喧嘩しない。

もし何かを仕様に見つけて、それが一般的に世のブラウザで動かないようなものなら、ぜひとも
ここで起票
してほしい、もしよければ修正に加えてプルリクエストを送ってほしい。それを修正するような。我々はいつも除去する物があるか考えている。十分なサポートが少なくとも2つのブラウザで得られない仕様は、除去する対象になる。たとえ便利で、保持していてほしくても、期待して将来のサポートを待つと思っても、だ。詳しくは下の「incubation」を参照。

HTMLはとても大きな仕様だ。その開発は、複数のソースファイルの集合から成る。それはBikeshed Processorによって処理される。これは自動化によりリンクを多数のセクション間で処理するもので、要素定義などをつなげる。重要な変更は、それが編集上のものであっても、おおよそ必要とする基礎知識があり、Bikeshedの動きを知っていないといけない。我々は継続して向上させる。文書化して特に初心者が分かりやすいように。

実際の新しい機能について、我々が好むのは、別個のモジュールが開発されること。これを「incubated」という。これにより、実際のサポートが存在するようになる。いろんな実装者がブラウザをやったり、製作ツールをやったり、実用コンテンツを作ったり、ユーザーも参加したり、さらに標準化しようとしたときの準備として提案できる拡張的なHTMLの仕様になったりする。

Web Platform Incubator Community Group (WPICG)の設立目的は、上記のためだが、もちろん参加者が開発して提案するとき、どんな立場でもいい。もう一度言う。我々が参加者に要求するのは、提案への技術貢献を追跡して(WICGは補助する)、そうすることで我々が到達点に来たと知ることができる。人々が提案を持ってW3Cにコメントして、ロイヤルティーフリーの条項に貢献して、開発者が喜んで実装をして、他大な心配を抱えて特許訴訟について頭をかかえることがない、という到達点に。

テスト

W3Cの開発プロセスでは、勧告がWGへ要求するところによると、W3Cディレクターを説得しないといけない、としている。Tim Berners-Leeに対して仕様が

・十分に明瞭で、完全で、市場要求に適合して、独立的な相互操作性のある実装が各機能について行われ、仕様が実現されていること

これはHTML5.0でも行う必要があった。変更が提案されてHTMLを変えるとき、我々が求めるのは、十分なテストで説明づけることだ。その提案が相互操作性を改善していると。理想的にはこれらは自動テストに組み入れたシステムにして、Webapps test harnessのようにすることだ。しかし実際に我々の計画で受け入れているテストでは、必要な相互操作性を説明づけるものなら良しとしている：自動化できるものであっても、でなくても。

利益としてこれらのアプローチがもたらすもの、それはブラウザから機能が除去されるのを除いては（レアだが）、継続的な増大を相互操作性レベルに見出せること。変更を承認するたびに。これの意味は、いつでもEditor's Draft (ED)のスナップショットが安定した基盤となって改善したHTMLバージョンになれるということ。それを我々が出版してHTML勧告の更新版にできる。

結論

我々が求めるHTML仕様−それは著者も実装者も、手軽に、自信を持って使用できるものであること。目標は完全の追求ではない(それは良への敵だ)。むしろHTML 5.1を5.0より良くすることだ。5.2までのね。

そして我々が各自に求めることは、気軽に参加してHTMLを向上させる活動をしてほしい。各自の目的もあるだろうし、Web全体のためにもなる。