IE11/Edgeで最低限閲覧可能な見た目にする

[usagi]

提案

• IE11 を含む IE を判定しすべて中途半端なレガシーウェブブラウザーとして、 "さいあく" でも CSS と JS を無効化しても難なく閲覧可能なよう対策する。

背景

1. IE11 での表示崩れが可読性に影響のあるレベルで発生している。（参考1）
2. IE11はまだ現役で cpprefjp も個人ユーザーの他、あまりモダンではない、あるいはウェブブラウザーについて保守的な環境を強いられたユーザーも残念ながら少なくない。
3. 滅びゆく IE11 に CSS/JS を特殊可するコストは勿体無い。
4. 実は w3m などテキストブラウザーだとわりとまともに読める。（参考2）
5. IE の場合はさしあたり CSS と JS を無効化してしまって少なくともテキストブラウザーと同様には読めるようにしてはどうか。

参考1 IE11

参考2 w3m

CC: @saki7

[saki7]

画像付きの詳細な報告ありがとうございます。これにはHTMLとCSSとJSそれぞれの問題がありますので、僕が把握している範囲のことを順を追って書きたいと思います。

HTML

cpprefjpのhtmlは、以前より編集者各位のご尽力のおかげで、文書構造としてはかなり適切な形になっています。このため、GoogleのクローラなどJSが無効化されているrobotsが来ても正しくパースできています。

僕の方でhtmlに行った変更は、（cssを.cssファイルに移動するなど）古いコードを削除するものです。この時に、html5shiv.js （IE8以下でHTML5/CSS3を使えるようにするパッチ）など事実上廃止されていた物の読み込み処理は削除しました。これがIE11に影響を与えている可能性はあります。

w3mなどのテキストブラウザでそこそこ見れるのは、この文書構造の正しさのおかげです。以前のサイドバーで静的に生成されていたサイドバー用のhtmlも、構造が正しいです。ただ、このサイドバーはサイズが肥大化するなど様々な問題を抱えており (参考) 、フロントエンドのデザイン修正を抜きにしても対応する必要はありました。

htmlについては大幅な変更が必要無いので、僕としてもこれから大規模な変更をする予定はありません。

CSS

cpprefjpのCSSは、元々はbootstrapベースに様々な要素を追加したものでした。bootstrapのレイアウトは全て float: left; などを使って実装されているため、基本的にどんなブラウザでもうまく表示できます。

kunaiのCSS実装では、floatの代わりにCSS3のflexboxを（全面的に）使っています。flexbox自体は2014年くらいから広く使われ始めた技術なので、これ自体は極端に先鋭的なものというほどでもないかなと思っています。

https://caniuse.com/#feat=flexbox

flexboxは、IEでは最終版の IE 11 でも実装にバグがありすぎて実質使えません。以前のデザインに戻すことは可能ですが、サイドバーのことを考えると float を使ってゼロから書き直す必要があります。僕の技術力の問題で僕は float でサイトを構築することができないので、誰かが対応してくれた場合は IE 11 を検出して切り替えるコードは3行くらいで書けます。

ブラウザの印刷機能で印刷をする時に正しく表示されるようにするのは新規の機能になるので、余裕ができたらやりたいなと思っています。

JS

cpprefjp の中で特別なJavaScriptコードは2箇所あります。クイックジャンプの検索窓とサイドバーです。DOM生成にはjQueryを使っているのでモバイルでもレガシーでも基本的に動くと思います。言語自体はES2017ですが、最終的にES2015にトランスパイルされてデプロイされているので、ブラウザで解釈できます。

---

float で全てを実装し直した css をどなたかが書いて頂けるのであれば、僕はIE11向けのフォールバック処理をすぐに実装する用意はできています。

※「IE11のシェアが何％だから〜」という数字の話を抜きにしても、僕はIE11への対応自体の必要性は感じています。

※いまのサイドバーのJavaScriptの実行が重すぎる問題は、数日以内に対応してデプロイします。

[saki7]

※大掛かりな修正を入れずとも、IE11向けの特殊なHTMLコメントを埋め込むことでcssを全て以前のものに切り替える処理を実装することは出来ます。ただし、その場合にそれがどういう風に見えているかを僕が継続的に検証することが出来ないので、フロントエンド方面でフルタイムで協力して頂ける方がどうしても必要です。

追記：条件付きコメントはIE10で削除されたらしいので、上記の内容は現在では正しくないです。対応するためには、IE11を検出する専用のJavaScriptコードを新しく書く必要があります

[saki7]

@usagi cpprefjp/kunai#31 で見た目が多少マシになったと思うのですが、ローカルのIE11で確認して頂けますか？

[yumetodo]

うーむ

[saki7]

@yumetodo あ、これです。この画像の2枚目の情報が知りたかった。

注意 Internet Explorer 11 は、flexbox プロパティの Microsoft ベンダー プレフィックス ("-ms-") バージョンをサポートしなくなりました。 標準の準拠や今後の互換性のため、代わりにプレフィックスなしの名前を使う必要があります。変更とベスト プラクティスの要約については、「可変ボックス ("Flexbox") レイアウトの更新」をご覧ください。

https://msdn.microsoft.com/ja-jp/library/hh673531(v=vs.85).aspx

display: flex もしくは display: -ms-flexbox が正しく見れていれば最低限の配置は守られるはずなんですが、うまくいかないですね。これが余計なベンタープレフィクスを見に行っていることで発生している問題だとするなら cpprefjp/kunai#31 で iOS のWebkitに対応する目的でプレフィクックスの対応範囲を上げたことによるregressionですが、そうでないとしたら元々このIssueで僕が書いたようなIE11のflexへの対応不足が原因なので、根本的な問題に戻りますね。

[saki7]

ref:

cpprefjp/kunai@bd89f41#r149858589

https://github.com/cpprefjp/kunai/pull/31/commits/bd89f41830bdfe9eb3419cc94d9e829ed65f50f4#r149858589

↑GitHubの内部参照のURLの自動変換先が間違ってるのでリンクにしてないです（これはGitHubのサポートに報告しておきました）

[yumetodo]

そりゃそうとこのkunai-vender.js:24,336959から飛んできてるエラーはなんだろう・・・

M.OPTS_DEFAULT={klass:{search_button:["fa","fa-fw","fa-binoculars"]},google_url:new URL("https://www.google.co.jp/search"),force_new_window:!1}

該当箇所はおそらくこれなんですが・・・

[saki7]

@yumetodo 該当箇所がそれかどうかは僕にも確信が無いですが、（IE11で）JavaScriptが全部死んでいるのはかなりスコープが広い問題なので、一概にどうとは言えないですね。

[yumetodo]

わかった

var u = new URL("https://www.google.co.jp/search");

が

このオブジェクトではサポートされていない操作です。

て言ってくる。

[yumetodo]

おかしいなぁ、mdn見る限りサポートしてるはずなんだが・・・

と思ったら日本語版のmdnが嘘ついていやがる・・・

英語版には

[4] As of IE11, instantiating new URL objects is not supported - ie. new URL() does not work.

って書いてあった

[saki7]

@yumetodo ですから、僕が上のコメントで書いたように、IE11でJavaScriptが動かないのはもっとスコープが広い問題で、１つ１つの動作を修正していっても完全対応には果てしない道のりがあります。

僕は、現行のcpprefjpがIE11でも最低限まともに見れるようになることを期待していて（つまりusagiさんの要望と全く同じ）、そのため cpprefjp/kunai#31 を実装しました。これは純粋にCSSの問題で、JavaScriptはここには関係ありません。

IE11でJavaScriptが全部死んでいるのは、CSSではなく https://babeljs.io/ の問題です。つまりkunaiが使っているbabelのオプションをいじってtransform-runtimeの出力結果を直すことで問題は解決します。しかし、表示に使っているCSSが全面的にFlexboxを使っているため、JavaScriptが動くようになったとしても正しく表示できる可能性はゼロです。

つまり、現実問題としてIE11をサポートしていない以上、JavaScriptのエラーの詳細を追求する必要はないです。エラーが出ても最低限表示できるようになればそれで良いです。

[saki7]

refs #476

[yumetodo]

なんでEdgeまで・・・？

[saki7]

EdgeだとFlexboxの実装がまともなので、たぶん技術的に対応できます。

そのため、もし、IE11で最低限の見た目にする過程でIE11/EdgeにおけるJSのエラーが一掃できれば、Edgeへの対応が速攻で完了する可能性が高いです。IE11のレガシーのための対処にかかった作業が、そのままEdgeへの対応に活かせます。

※厳密には別々の問題なのですが、Issueをこれ以上分割しなくてもいいんじゃないかなと思いました

[yumetodo]

了解です

---

とりあえずURLに関してはpolyfill入れるなりするべきかなと思っているんですがどうでしょう？

・・・と思ったら修正入りだしてた・・・

[saki7]

URL は全部Polyfill化したのでURL周りのエラーは全部殺しました！

[yumetodo]

URL周りがどうにかなった影響でIEでもすこしましになりました

次は
https://github.com/cpprefjp/crsearch/blob/933a30636885356c6f57e435f6523d2ecd1bd61e/js/crsearch/database.js#L36
json.ids.entries()に対して

オブジェクトは 'entries' プロパティまたはメソッドをサポートしていません。

が出ています

[yumetodo]

@saki7
IE11での動作を目指して片っ端からpolyfillを追加しています
yumetodo/kunai@69b1d9d

現在string.prototype.normalizeが無い、というエラーが出ているのですが、
https://github.com/cpprefjp/crsearch/blob/933a30636885356c6f57e435f6523d2ecd1bd61e/js/crsearch/index-id.js#L69
https://github.com/cpprefjp/crsearch/blob/933a30636885356c6f57e435f6523d2ecd1bd61e/js/crsearch/query.js#L12
こいつのpolyfillは
https://github.com/walling/unorm
でかいので入れたくないです。ロジック的にstring.prototype.normalizeを必要とする理由を教えてください

[yumetodo]

@saki7 そう思ってこっちでもbabelとWebpackの設定読み返してるんですがががが

[yumetodo]

https://qiita.com/inuscript/items/1993b6b18a76fcb70dc4
静的変換なので、インスタンスメソッドのArray.prototype.includesとかは変換出来ない

まあ確かになぁ、という思い。やっぱpolyfillからは逃げられなかったよ

• core-jsなどで別途自己管理でpolyfillするのは割りとアリ
  - core-js自体は独立したpolyfillライブラリなので、スタンドアローンに十分使える
• ただし、polyfillは冪等というわけではないので、そのあたりの管理はやったほうが良い
  - core-jsでpolyfillするにしても、複数回呼び出しは避けるのが賢明と言えそう
• babel-polyfillが差し戻してるcore-jsから落とされた機能を利用する場合には、何らか処理が必要
  - とはいえ、おそらくどこかで消えるので、なるべく早めに根本解決したほうが良い。
• ライブラリ提供を目的としてるならbabel-runtime一択。global汚染するpolyfillに出番は無い

うーん、やっぱり少量とは言えglobal汚染するのは精神的に病みそうなのでpolyfillをglobal汚染しない形で読み込んで手動で置換します・・・

[yumetodo]

string.prototype.normalize は右上の検索窓で入力を正規化する時に使っています。

完全に外しても動きますが、意図していない部分で不都合が起きる可能性はあります。

string.prototype.normalizeがない場合は正規化しないという泥臭いハックをしてもいいですか・・・？
polyfillを動的loadとかも考えたけど、なんかアホらしいので。IEとFirefox for AndroidとiOS9 safariくらいしか該当がないので

[saki7]

僕の説明が甘かったです。途中からJavaScript周りのIE11の話をEdgeの話だと誤解していたので、説明不足に気づくのが遅れました。

IE11への対応方針

まず僕の方針として、IE11はサポートしません。これはこのIssueの一番最初のコメントで書きました。

ポリシーとしての理由は、IE11は既にベンダーの開発自体が終了しているからです。

技術的な理由は、kunaiとcrsearchの内部のCSSが完全にFlexboxで書かれているため、仮にJavaScriptのコードのエラーを全て解消しても、見た目が正しく表示される可能性がゼロだからです。

そういう大前提があって、僕は「誰かがIE11向けにfloatレイアウトでCSSを全部書きなおしてくれるならそれにフォールバックする処理は追加する」と書きました。これは今でもそう思っています。僕が使っていた“対応”という言葉は、誰かが書いてくれるなら僕は切り替える処理だけは書くということです。つまり、僕の書くコード（css, js両方）でIE11がサポートされる可能性はゼロです。

ここで一旦このIssueの本題に戻りますが、本題はあくまで「最低限閲覧可能な見た目にする」ということです。要するに、今のcpprefjpの本番環境をChromeで開いてそのままJavaScriptをオフにした時の表示が僕が最低限閲覧可能と考えている見た目です。usagiさんの報告時点では、IE11での見た目がChromeのJSオフ時の見た目とあまりにも乖離していたため、最低限の対応はするというつもりで色々な修正を今まで入れてきました。

Edgeへの対応方針

僕はEdgeには対応する気はあります。現行のブラウザだからです。ただ、僕はWindowsの検証環境を持っていないため現実的にはEdge向けのコードは一切書けません。ただ、誰かがEdge向けの対応処理を実装してくれる場合は、それを全面的にサポートするつもりですし、それは100%取り込むことを約束します。

kunaiにおけるpolyfillの導入方針

前提として、polyfillは使いません。kunaiの実装方針としてkunaiが無効化されてもページが動くということがベースになっており（READMEを参照）、グローバル汚染のpolyfillをした時点で責任が持てないからです。

現実にはMathJaxやGoogleアナリティクスなどのコードが現時点でも完全に独立して読み込まれているため、polyfillの結果そこで何が起こるかは本当に不定なので、仮に問題が何も起こらなかったとしてもpolyfillはしません。

それならローカルオブジェクトにcore-jsのpolyfillを保持して使えば良いと思うかもしれません。それをやった場合、僕が今まで書いた問題が全て一発で解決するのは事実です。しかし、あらゆるコードを全てそのローカルオブジェクト経由で呼び出す必要が出てくるので、これはkunaiの開発者として生理的に無理です。

URLはpolyfillしたのでは？という疑問

厳密にはあれはpolyfillではないです。普通のCommonJSのライブラリなので、グローバルオブジェクトは触りません。もともと、URLはECMAScriptというよりWeb APIの一部で、仕様レベルで何も固まっていないこと（をあとから知った）から外部ライブラリを使うように切り替えました。

yumetodo さんの調査内容について

yumetodo さんの調査内容は掲題の 「IE11で最低限の見た目にする」という点に加えて「Edgeに対応する」という2点でかなり重要度が高いので無駄になることは絶対にありません。

ここの前者（IE11）は、いま説明したような状況なのでそこそこ見れるようになればその時点で調査とワークアラウンドは打ち切ってください。

後者（Edge）は、babelで変換不可能なレベルで実験的な提案段階の機能をどうやって置き換えればpolyfillせずに気持ちよく書き直せるかという点を僕は今考えています。それを考える上で、不具合が起きている部分は開発方針としてワークアラウンドしても良いと思っています。

ここですが、実はkunaiでここに該当するものはもう無いんじゃないかと思っています。たぶんURLがこれに該当してたんですが、URL以外で純粋にEdgeで動かないものが無ければもうたぶん無いです（あったらすいません）。

[yumetodo]

Edgeについては
#476 (comment)
の回答待ちです。相変わらずランダムに表示されない。

---

polyfillについては

グローバル汚染のpolyfillをした時点で責任が持てないからです。

yumetodo/crsearch@e73ae43
にて汚染しない形でcore-jsを読み込んでいます。これなら問題ないかと。まあIE11無視ならpolyfill不要ですが、現状は(今後Edgeが対応していない)。

---

IE11について

祝！JSが最低限動くようになった

yumetodo/kunai@7139dbd

ただしスクロールするとエラーがドッサリでる(が動く)

また時々

がでて、その直後すべてのログを吹き飛ばしてリロードする(webpack-dev-server側？)

[saki7]

@yumetodo ですから、IE11はサポートしません！！サポートしちゃダメです。動いたから良いという話ではありません！！（泣）

(@saki7)
IE11への対応方針
まず僕の方針として、IE11はサポートしません。

IE11をサポートしない理由は散々書きました！！長文で申し訳ないですがもう一度読んでください。

polyfillに関してもグローバルを汚染しないpolyfillなら使って良いという話ではありません。

(@yumetodo)
yumetodo/crsearch@e73ae43
にて汚染しない形でcore-jsを読み込んでいます。これなら問題ないかと。まあIE11無視ならpolyfill不要ですが、現状は(今後Edgeが対応していない)。

僕は既に以下のように書いています：

(@saki7)
それならローカルオブジェクトにcore-jsのpolyfillを保持して使えば良いと思うかもしれません。（中略）あらゆるコードを全てそのローカルオブジェクト経由で呼び出す必要が出てくるので、これはkunaiの開発者として生理的に無理です。

yumetodoさんのIE11向けの現状のcore-jsワークアラウンドは、今はこのレベル（1ファイルあたり2〜3箇所）で済んでいますが、 例えば Array.prototype.includes() のようなごくごく基本的な機能を使う箇所が今後kunaiの内部で順調に増えていった場合に全部の箇所でワークアラウンドする必要があります。これは、できるからやるとか、誰かがやってくれるならその人に任せるという話では済まないのです。

1. kunaiがグローバル汚染したpolyfillを入れた場合→外部のjsファイルをそのままhtml（kunaiの管轄外）に追加した場合の挙動が不定（デザインチーム以外がメンテ出来なくなるのと同義）
2. ローカルオブジェクト経由でpolyfillを使う場合（IE11のためだけの場合）→全ての箇所でワークアラウンドを保証する必要がある（誰もメンテ出来なくなる）
3. ローカルオブジェクト経由でpolyfillを使う場合（babelが未対応なせいでEdge対応のために必要な場合）→どうしても必要なら入れる。入れなくて済む書き方があるならなるべくそっちを使う

cpprefjpは基本的にボランティアです。なので、フロントエンドでは、フロントエンド周りのコードは最悪メンテ出来る人が全員死亡してもどうにかできるようにしています。そのために神経質なほど方針を設定しています。

---

今まで話したこと以外にも、僕はkunaiの技術選択はすごく慎重にやっています。以下はこのIssueの本筋とは全く関係が無いのでポエム程度に捉えていただきたいのですが、デザインチームとして書いておきます。

例えば、TypeScriptを使っていないのはTypeScriptはそもそもJavaScriptではなくて別の言語だからで、ESNextで書いているのはECMAScriptの次期規格だからです。これだったらフロントエンドに特化していない人でも「better JavaScript」として書けるはずです。つまり、メンテの障壁が天と地ほどの差があります。TypeScriptが3年後生き残ってるかどうか僕は個人的にかなり怪しいと思っていますが、ECMAScriptなら絶対にその心配が無いです。

例えば、ReactやMithrilを使わずにDOM構築をjQueryで完結させているのは、いくつか理由があります。

1. cpprefjpは本来は全て静的で、ナビゲーションの定義ファイル（つまり crsearch.json ）も静的なフェッチ1回で済む
2. そのためReactほどの複雑なUIの構築が必要無い
3. そのためVirtual DOMによる差分適用の最適化が必要無い（更新時イコール100%の差分なので）

こういう繋がりで考えると、IE11のためにローカルpolyfillを入れていくのはあまりにもデメリットが多すぎます。Edge対応のためにどうしてもpolyfillを入れるならそれはまだ分かります。そこの部分は明確に違います。

[saki7]

上記の理由により、今出ているPRのなかでEdgeの対応に必要不可欠な物が無いのであればマージはしません。

[saki7]

Edgeについては
#476 (comment)
の回答待ちです。相変わらずランダムに表示されない。

僕はEdgeでここのコードが動かない理由は1つしか思いつきません。global symbol registryのバグです。これが原因でない場合は、1行1行console.logしてデバッグするしかないです。

これがIE11のことを指しているのであれば、IE11ではそもそもsymbol自体のサポートが無いので諦めてください。

もう1つ考えられる原因としては、 git submodule update --init を走らせていない可能性です。 kunai と crsearch のリポジトリで submodule になっている cpprefjp/kunai_config が無いと、そもそも設定ファイルが読み込めないのでここは動きません。

[yumetodo]

babel-runtimeの仕様上、メソッドの追加にはどういう形であれpolyfillの追加が避けられません(promiseのようなクラス追加のみならbabel-runtimeで完結する)
たまたま今のところIE以外でその必要が出ていないだけで、今後でてくることは十分想定されます。

polyfillに関しては諦めて受け入れる必要があります。メンテ可能性を考えればローカルオブジェクトなんてナンセンスで(CIの掛けようすらない)kunaiより大きな枠で(site_generator?全部のJSライブラリを管理しているところ)global汚染を受け入れてpolyfillするべきというのが私の意見です。kunai内でglobal汚染するのはまずいと思いますが、外側でどのみちmathjaxなりkunaiなり(本当はjQueryもkunaiの外にあるべき)JSライブラリの管理をせねばならんのですから、そこでpolyfillも管理するのは不自然ではないし、デザインチーム以外がメンテできないというのは当たらないのではないでしょうか？

IEサポートのpull requestについては一旦取り下げますが、IE11は開発は終了してもご存知の通りサポートは継続しており、またシェアも無視できない規模を保っています。サイドバーの中身がすっからからんというのは明らかに見た目上差し支えあるのではないでしょうか？

---

Mithrilの件ですが、あれはjQuery職人芸もmithril使うのもメンテ可能性は大して変わらないだろうから書きやすい方でいいのではという意図での提案でした。

[yumetodo]

もう1つ考えられる原因としては、 git submodule update --init を走らせていない可能性

その場合はWebpackのビルドが通らないですね、最初それで小一時間くらい悩んでました。ついでにいうとシンボリックリンクが含まれているrepoの扱いはWindowsだと事前準備が必須でした(グループポリシー、export MSYS=winsymlinks:nativestrict、git config core.symlinks true)

僕はEdgeでここのコードが動かない理由は1つしか思いつきません。global symbol registryのバグです。これが原因でない場合は、1行1行console.logしてデバッグするしかないです。

私の技量ではこれ以上追うのは難しいです。私に協力できそうなのは、global symbol registry周りのテストケースを @saki7 さんに書いていただいて私が実行するくらいです、お役に立てなさそうで申し訳ない。

[saki7]

babel-runtimeの仕様上、メソッドの追加にはどういう形であれpolyfillの追加が避けられません(promiseのようなクラス追加のみならbabel-runtimeで完結する)
たまたま今のところIE以外でその必要が出ていないだけで、今後でてくることは十分想定されます。

はい。正しいです。しかし、kunaiのコードでそのような先進的すぎるインスタンスメソッドを使っている箇所は無いというのが僕の認識です。人間らしいコードを書くために最低限必要な新し目のESのインスタンスメソッドは、現実としてChrome/Firefox/Edgeにはだいたい実装済みなので、問題になっていません。

Array.prototype.includes も、Edgeにはあります。Edgeで動かないとしたら、それはまだ把握できていない箇所なので、そこはEdge用に直す必要があります。例えば、僕の上記コメントのSymbol類は、まさにこの「人間らしいコードを書くために最低限必要」かつ「Chrome/Firefoxではサポート済だがEdgeでは微妙」な可能性が高い機能です。

polyfillに関しては諦めて受け入れる必要があります。メンテ可能性を考えればローカルオブジェクトなんてナンセンスで(CIの掛けようすらない)kunaiより大きな枠で(site_generator?全部のJSライブラリを管理しているところ)global汚染を受け入れてpolyfillするべきというのが私の意見です。kunai内でglobal汚染するのはまずいと思いますが、外側でどのみちmathjaxなりkunaiなり(本当はjQueryもkunaiの外にあるべき)JSライブラリの管理をせねばならんのですから、そこでpolyfillも管理するのは不自然ではないし、デザインチーム以外がメンテできないというのは当たらないのではないでしょうか？

グローバル汚染をする場所は関係ありません。kunaiでグローバル汚染しようが、site_generatorの範疇で１つ独立したpolyfill用のjsを作ってグローバル汚染しようが同じです。どこでグローバル汚染をしても、その影響先はページ内で読み込んでいる全てのjsファイルに及びます。「polyfillを管理する」ということ自体がナンセンスです。

cpprefjpはSPA（シングルページアプリケーション）では無いので、誰かが気軽に好きなjsファイルをプラグインとしてhtmlに1行追加してもそれを動くことを保証する必要があります。たとえば、今後、合意形成の結果、何かしらのjsのウィジェット（ツイートボタンとか？）をcpprefjpに追加することになったとします。その時にグローバルなpolyfillをやっていると、「同等な機能をkunai側で追加してください」としか言えなくなります。これは明らかに問題があり、許容できません。

「polyfilによる汚染で現実に問題が起こることは無いんだから、やればいい」と思うかもしれません（僕自身も最初はそう思っていました）が、現実に問題が起こった有名な例はあります。 https://blog.jxck.io/entries/2017-02-17/polyfill-implementation-guideline.html

「jQueryもkunaiの外にあるべき」というのは、単純に指摘としてあたりません。これは、C++でいうなら「Boostライブラリはアプリの外の標準のインクルードディレクトリの物を使うべき」という指摘と全く同じです。これは許容できません。

IE11は開発は終了してもご存知の通りサポートは継続しており、またシェアも無視できない規模を保っています。サイドバーの中身がすっからからんというのは明らかに見た目上差し支えあるのではないでしょうか？

「cpprefjpの執筆者の大多数がその環境を使っていて執筆に支障が出る」という話であれば無視できないと思いますが、そういうことでは無いと思っています。「IE11はまだサポートが続いている」という点を挙げるのであれば、サポート終了の2025年10月までkunaiでもサポートするということになると思いますが、これを含んだ要望ですか？

ちなみに、 cpprefjp/kunai#16 という要望は上がっています。これをバックエンドで実装した結果最低限のナビゲーションがhtml内に静的に埋め込まれれば、それをデフォルトでサイドバーの中のプレースホルダーとして扱うことも可能なので、そこに最低限の何かしらのリンクは出ると思います。なので、これが実装されれば「すっからかん」という状態からは脱却できます。

---

Windowsにおけるシンボリックリンクが含まれているgitリポジトリの扱いは個人設定の範疇なので、特に対応はしません。

global symbol registryの件は、どこが死んでいるのかエスパーをすることは出来ますが、あくまでエスパーです。Windows環境が無いので。そのため、テストケースを書くとかは出来ません。

私の技量ではこれ以上追うのは難しいです。私に協力できそうなのは、global symbol registry周りのテストケースを @saki7 さんに書いていただいて私が実行するくらいです、お役に立てなさそうで申し訳ない。

はい。URL周りをはじめとした調査ありがとうございます。アサインからは外しておきます。

[saki7]

実家の母親のWin 8 / IE11のマシンを借りてスクショしました。記事の本文を読む上で支障が無いので、このIssueの対応は終わりとします。

[saki7]

本筋からは外れますが、デザインチームとして1つ見過ごせない点があったので補足します。

Mithrilの件ですが、あれはjQuery職人芸もmithril使うのもメンテ可能性は大して変わらないだろうから書きやすい方でいいのではという意図での提案でした。

jQueryを使っているのはcpprefjpで高度なUIが必要無いからで、この詳細は #477 (comment) で書きました。

つまり、jQueryはほとんどDOM構築のためだけに使っています。僕自身は、DOM構築に特化したモダンなライブラリがあるならそっちを使いたいという気持ちがあります。そのため、 @yumetodo さんからMithrilの提案を頂いた時は、実際に全てのコードをMithrilで書き直して試しています （ cpprefjp/crsearch#2 (comment) ）

「jQuery職人芸」というのは @yumetodo さんは単に深い意図はなくこういう表現をされているのだと思いますが、この表現はあまりにも見る人に嫌な印象（cpprefjpがレガシーなjQueryの書き方をしているという印象）を与えるので、僕としてはこれは違うということはここで書いておきます。

例えば、 jQueryの中でも、 $.Deferred とか $.extend とかを使っているなら、これは疑いなく「jQuery職人芸」だと僕は思っています。しかしそういう闇が深い物は使っていないので、レガシーなjQueryにこだわりがあるわけではありません。

jQueryを使うのとMithrilを使うのでメンテ可能性は大して変わらないというのは、僕は絶対にそうは思いません。天と地くらいの差があると思っています。

[yumetodo]

「IE11はまだサポートが続いている」という点を挙げるのであれば、サポート終了の2025年10月までkunaiでもサポートするということになると思いますが、これを含んだ要望ですか？

私はcpprefjpのアクセス解析をできる立場にないのでIE11にどれくらいの需要があるかはわかりませんが、10~15%程度はアクセスがあるのではないかと推測しています(Qiitaの自分の記事のアクセス解析などから推測)。IEのシェアはサポートが終了しないとなかなか落ちなかったのがこれまでだと認識しています。そういう観点から開発上の大きな障害にならない限りにおいて、IE11はサポート終了までkunai含めたcpprefjp全体でサポートされるべきだと私は思っています(要望)。

余談でかつ話がそれますが、IEと同じく開発上の障害になりつつあるAndroid・iOSのブラウザをどうするべきなんでしょうね・・・。iOSはようやくiOS9のユーザーが減ってきてるのでまだいいとしてAndroid 4.xおよび5.xのユーザーも合わせて多分3%くらいいると推測しているんですが・・・。

[saki7]

私はcpprefjpのアクセス解析をできる立場にないのでIE11にどれくらいの需要があるかはわかりませんが、10~15%程度はアクセスがあるのではないかと推測しています(Qiitaの自分の記事のアクセス解析などから推測)。IEのシェアはサポートが終了しないとなかなか落ちなかったのがこれまでだと認識しています。そういう観点から開発上の大きな障害にならない限りにおいて、IE11はサポート終了までkunai含めたcpprefjp全体でサポートされるべきだと私は思っています(要望)。

cpprefjpにおけるIEのシェアの実際の割合は、広く公開されている日本の統計のIEの割合とほとんど同じです。

polyfillは「開発上の大きな障害」になるので、僕はサポートしません。

その他のレガシーブラウザやレガシーモバイル環境については、解決する必要性があると感じるのでしたら、別のIssueを cpprefjp/kunai に立ててください。

[yumetodo]

嫌な印象（cpprefjpがレガシーなjQueryの書き方をしているという印象）を与えるので

そういう意図はなかったのですがそれは失礼しました。