うーん厳しい。これでWeb組版の進化が止まることになんなきゃいいんだけど。むしろWeb組版の進化に電子書籍がまったくついていけないことのが多いか？
2026年にもなってXMLの呪いとか勘弁してくれ。互換性のために進化を止める典型例
まともにDOM化できるHTMLならツールにかけて整形すれば秒でXML化できるし実質的に何の妨げにもならんだろ
書籍のシステムから見たらWebのルーズさは受け入れづらいって話か。まぁそれはそうだな。
エラーをエラーにしない変な文化が定着してしまうと特定の実装が仕様になってしまう
最終データ形式をミスに寛容なものにしてどうするんだよ。当たり前の結論だろう。
“HTMLは「多少の構文ミスもブラウザが良しなに補完する、耐障害性の高い（寛容な）言語」” ものも言いよう。
エコシステムの破壊リスクの内容からすると、XMLが壁なんじゃなくて、ドキュメント表示システムにアプリケーション要素を含めてしまったのが壁になったんじゃないかと。
ここでの議論はserializationの話だけで、単に構文としてHTML形式も追加しようかと思ってたけどみんな構文以上を期待するから止めた、とのこと。別途Webと出版の融合の議論もありWeb Publication Manifestが2種類になり（文字数
っスよね～～～～～以上の感想がないw
「HTMLは「多少の構文ミスもブラウザが良しなに補完する、耐障害性の高い（寛容な）言語」だ」/XHTMLがなくなるとは思わなかったなあ。タグ閉じろよ。
XHTMLではなくHTML5が勝った時点で仕方なかったんでしょうね。その時点から分かってた欠点ですから
「HTMLは使えないことになりました」って、タイトルが悪意に満ちている。video要素すらOKなら、むしろ既にかなり使えてるでしょ。
電子書籍になぜvueやらreactを使いたいって要望が出てくるんだ…？
"しかし、この事実が開発現場で正しく認識されておらず、「HTML5の機能を使うためにXMLを廃止しなければならない」という誤解が生じていたこと" この記事タイトルも誤解を助長しとるがな
AozoraEpub3を電子出版目的に使う場合に、審査が通るように修正している。 改造版AozoraEpub3 電書連 EPUB 3 制作ガイドのEPUB対応 https://github.com/kyukyunyorituryo/AozoraEpub3
全部画像にするしかないな！！
"しかし、EPUBの内部仕様は今もなお、厳格なXMLの構文規則（XHTML）に依存している" XHTMLあんたこんなところでひっそりと生きてたのか…
“出版実務に携わる層からは、Web開発とは異なる「本」というメディア特有の懸念が示された。業界が長年築き上げたXML/XSLTベースの自動組版システムを刷新するコストは、多くの事業者にとって許容しがたい”
“アプリを入手 圧倒的に便利です” わざと不便にしといてこの言い草
クライアントサイドで解釈に揺らぎが出るフォーマットはよろしくない
棲み分けを維持したことを歓迎したい
本件と関係ないが、電子書籍とタグ言語だと初の電子書籍小説体験が伊藤計劃のハーモニーだったで初見時「タグ見えちゃってる！？」と焦った思い出がある
そもそもWebと電子書籍を統合する必要がどこにあるんだ……
HTMLとアプリ記述言語は分けるべき派閥なので、HTMLはもっとシンプルにハイパーテキスト記述の初心に戻って縮小するべき、と思う。
Web屋はなんでも自分の処が普通だと思いすぎ
Webを寛容に解釈してXMLに変換するツールを普及させれば良いのでは？
htmlタグもheadもbodyも書かずにいきなりheadの中に書くべきタグ書いて続けてbodyの中に書くべきタグを書いてもブラウザが補完してくれてちゃんと表示されるもんな そもそもhtmlの仕様として補完することになってるらしいが
電子書籍（EPUB）ではHTMLは使えないことになりました — W3Cが苦渋の決断、Webと電子書籍の統合を阻んだ「XMLの壁」
うーん厳しい。これでWeb組版の進化が止まることになんなきゃいいんだけど。むしろWeb組版の進化に電子書籍がまったくついていけないことのが多いか？
2026年にもなってXMLの呪いとか勘弁してくれ。互換性のために進化を止める典型例
まともにDOM化できるHTMLならツールにかけて整形すれば秒でXML化できるし実質的に何の妨げにもならんだろ
書籍のシステムから見たらWebのルーズさは受け入れづらいって話か。まぁそれはそうだな。
エラーをエラーにしない変な文化が定着してしまうと特定の実装が仕様になってしまう
最終データ形式をミスに寛容なものにしてどうするんだよ。当たり前の結論だろう。
“HTMLは「多少の構文ミスもブラウザが良しなに補完する、耐障害性の高い（寛容な）言語」” ものも言いよう。
エコシステムの破壊リスクの内容からすると、XMLが壁なんじゃなくて、ドキュメント表示システムにアプリケーション要素を含めてしまったのが壁になったんじゃないかと。
ここでの議論はserializationの話だけで、単に構文としてHTML形式も追加しようかと思ってたけどみんな構文以上を期待するから止めた、とのこと。別途Webと出版の融合の議論もありWeb Publication Manifestが2種類になり（文字数
っスよね～～～～～以上の感想がないw
「HTMLは「多少の構文ミスもブラウザが良しなに補完する、耐障害性の高い（寛容な）言語」だ」/XHTMLがなくなるとは思わなかったなあ。タグ閉じろよ。
XHTMLではなくHTML5が勝った時点で仕方なかったんでしょうね。その時点から分かってた欠点ですから
「HTMLは使えないことになりました」って、タイトルが悪意に満ちている。video要素すらOKなら、むしろ既にかなり使えてるでしょ。
電子書籍になぜvueやらreactを使いたいって要望が出てくるんだ…？
"しかし、この事実が開発現場で正しく認識されておらず、「HTML5の機能を使うためにXMLを廃止しなければならない」という誤解が生じていたこと" この記事タイトルも誤解を助長しとるがな
AozoraEpub3を電子出版目的に使う場合に、審査が通るように修正している。 改造版AozoraEpub3 電書連 EPUB 3 制作ガイドのEPUB対応 https://github.com/kyukyunyorituryo/AozoraEpub3
全部画像にするしかないな！！
"しかし、EPUBの内部仕様は今もなお、厳格なXMLの構文規則（XHTML）に依存している" XHTMLあんたこんなところでひっそりと生きてたのか…
“出版実務に携わる層からは、Web開発とは異なる「本」というメディア特有の懸念が示された。業界が長年築き上げたXML/XSLTベースの自動組版システムを刷新するコストは、多くの事業者にとって許容しがたい”
“アプリを入手 圧倒的に便利です” わざと不便にしといてこの言い草
クライアントサイドで解釈に揺らぎが出るフォーマットはよろしくない
棲み分けを維持したことを歓迎したい
本件と関係ないが、電子書籍とタグ言語だと初の電子書籍小説体験が伊藤計劃のハーモニーだったで初見時「タグ見えちゃってる！？」と焦った思い出がある
そもそもWebと電子書籍を統合する必要がどこにあるんだ……
HTMLとアプリ記述言語は分けるべき派閥なので、HTMLはもっとシンプルにハイパーテキスト記述の初心に戻って縮小するべき、と思う。
Web屋はなんでも自分の処が普通だと思いすぎ
Webを寛容に解釈してXMLに変換するツールを普及させれば良いのでは？
htmlタグもheadもbodyも書かずにいきなりheadの中に書くべきタグ書いて続けてbodyの中に書くべきタグを書いてもブラウザが補完してくれてちゃんと表示されるもんな そもそもhtmlの仕様として補完することになってるらしいが