JavaScript の質問用スレッド vol.123 [無断転載禁止]©2ch.net

2017/04/03(月) 00:31:25.68

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-6のテンプレを読んだ上で質問してください。次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) ライブラリ関連の質問は禁止です。関連スレにあるライブラリ質問スレで質問して下さい。
(10) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
※前スレ
JavaScript の質問用スレッド vol.122
http://echo.2ch.net/test/read.cgi/tech/1472426483/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2017/04/17(月) 11:16:39.84

>>27
>>28
>>29
>>30
の4つのコードの結果が何故こうなったのか理由を教えてください

2017/04/17(月) 12:35:49.92

インスタンス化したときじゃなくアロー使った時点でthisが束縛されてるから

2017/04/18(火) 16:19:41.63

generator-chrome-extension-kickstart を使ってchrome-extension作っているんです。
これ自体はすごく便利なんですが修正するたびにコンパイルが入ってリロードするため、
chromeが「この拡張機能は、自身により頻繁に再読み込みされています。」と、
開発中のプラグインを無効化してしまいます。
これが面倒なので警告を無効化する方法を教えていただけないでしょうか？

2017/04/19(水) 09:59:50.06

手動で更新すればいい

2017/04/19(水) 19:05:12.62

>>32
理解しました
function()を無理にアロー演算子に書き換える必要はなさそうですね
先輩ありがとうございます

2017/04/19(水) 19:18:09.01

>>35
アローは関数型プログラミングの流れを汲んでるから今回みたくオブジェクト指向で使おうとすると相性悪い

2017/04/21(金) 21:06:23.20

関数型の流れを組んでるからとか、どうしたらそんな頭の悪いこと思いつくんだ？
そもそもオブジェクト指向と相性悪いと言うこともないし。
ただ単に既存のthisを利用したクラスベースもどきクラスシステムと相性悪いというだけで、
オブジェクト指向はプロトタイプベースでも、別のクラスベースもどきでもいくらでもできる。

2017/04/21(金) 21:53:18.77

関数型っていうのは、ロジックを記述するもの。
オブジェクト指向っていうのは、そのロジックを持った構造を作るもの

住み分けがしっかりしてるから、オブジェクト指向＋関数型で
プログラミングするのが今のトレンド

2017/04/21(金) 21:58:57.35

>>37
> ただ単に既存のthisを利用したクラスベースもどきクラスシステムと相性悪いというだけで、

それは違う。逆にクラスベースのJavaScriptと相性がいい。

例えばこんな感じな

class Foo {
　　func() {
　　　　lib.sort(function() { thisはなんになる？ })
　　　　lib.sort(() => { thisは当然Fooのインスタンス })
　　}
}

今まではthisが何になるかは、lib.sort() の仕様によって決まるから、
他の言語のように
「クラスの中のコードでthisといったらインスタンス自身に決まってるだろJK」
と言うことができなかった。

アロー関数を使って（言い換えるとfunctionキーワードなしで）JavaScriptをかけば
クラスの中でthisを使えば、どこで使ってもそのクラスのインスタンスとなり、
他の言語と同じように考えることができる。

2017/04/21(金) 22:51:06.77

ラムダ式に引数を与えないなんてとんでもない！

2017/04/21(金) 23:22:22.43

>>40
そこは本質的なところじゃない自分でかってに補完しろ

2017/04/24(月) 05:00:01.27

>>39
屁理屈だな
メソッドにできないということが表の相性とすればそれは裏の相性だよ

2017/04/24(月) 23:04:59.41

>>42
それは↓に言うべきことだね

>>37
> ただ単に既存のthisを利用したクラスベースもどきクラスシステムと相性悪いというだけで、

相性悪いが裏の相性（？）ということなら、>>39が書いたとおり相性が良いってことだろう。

それにそういうどうでもいいことしか言えないってことは、
>>39の内容には何も意見できないってみなすしかないねｗ

2017/04/24(月) 23:16:12.81

JS使いには性格悪い人しかいないんですかね？

2017/04/24(月) 23:17:09.83

>>44
お前性格悪いなｗ

2017/04/25(火) 06:10:59.30

ブラウザさえあれば入門出来るから、いろんな人はいるだろね。

2017/04/25(火) 08:59:18.77

>>43
だからさあ、本当に言わないと分かんない？
コンテキストが違うでしょ？
そこまでずっとアロー関数を通常の関数のようにメソッドとして使えないという話をしてて、
その流れでの相性の話題なのよ

そしてそこでは君の言ったことは、（もっと広い視野で見て）「オブジェクト指向とは相性悪くない」
に含まれるのよ
君は数レスどころか１レスもまともに読めてない
あまりに視野が狭すぎだよ

2017/04/25(火) 09:57:49.62

>>47
頭悪いぞお前、コンテキストは>>36のアウアウな発言

>アローは関数型プログラミングの流れを汲んでるから今回みたくオブジェクト指向で使おうとすると相性悪い

functionはOOスタイルプログラミングでクソって書いてあるのに
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions

Until arrow functions, every new function defined its own this value (a new object in the case of a constructor,
undefined in strict mode function calls, the context object if the function is called as an "object method", etc.).
This proved to be annoying with an object-oriented style of programming.

2017/04/25(火) 14:18:09.68

>>48
だからそれに君と同じように批判してるのが>>37だっていう話をしてるんだが
オブジェクト指向とは相性悪くないってはっきり言ってるでしょ
頭大丈夫か？

2017/04/25(火) 16:19:31.03

オブジェクトを理解できていないのがドヤ顔でなんか言ってるわｗ

**デフォルトの名無しさん** (JP 0Hcf-41eg) · 2017/04/25(火) 18:42:15.58

constとfreezeがデフォルトになる時代を待ってます
2020くらいまでにおねしゃす

2017/04/25(火) 23:00:57.97

>>47
お前が言ってるのは、オブジェクト指向との相性じゃなくて、
古いやり方、prototypeを使ってメソッドを追加する時限定の話じゃん。

オブジェクト指向の話でいうならば、お前が狭いんだよ。

2017/04/26(水) 10:54:04.97

>>52
だから最初からその狭い範囲限定で話をしてるでしょ
で、広い範囲では違うよと書いてるでしょ
レスをちゃんと読めって言ってるのよ……
まだ分かんない？

2017/04/26(水) 12:16:56.72

>>53

>アローは関数型プログラミングの流れを汲んでるから今回みたくオブジェクト指向で使おうとすると相性悪い

これは狭い範囲に限定した発言じゃ無いと思うが
そんな必死になってこのアウアウを擁護する理由は?

2017/04/26(水) 21:05:53.95

>>53
だからこうですよね？

限定した狭い意味
「アローはprotptypeを使ってメソッドを作成するときには使えない」

大幅に範囲拡大した場合
「アローはオブジェクト指向で使おうとすると相性が悪い」
※注意オブジェクト指向でアロー関数が相性がいい理由は上で説明済みです

2017/05/04(木) 14:53:39.23

メソッドを作成するときに直接使えないよりも
メソッド中で別の関数を定義するときに便利な時があるという方が
よっぽど視野が狭いんだよなぁ
オブジェクト指向と相性が良い！とか笑える

2017/05/04(木) 18:20:15.83

視野が狭い笑い
>>56
> This proved to be annoying with an object-oriented style of programming.
こう言ってアロー関数の動作を変更した奴に言え

2017/05/04(木) 18:56:55.88

javascriptの勉強する時ってフロントエンドやるよりnodeから始めた方が良いの？

2017/05/04(木) 19:05:34.12

今時はフロントエンドでもnpm使うから明確な区切りはないかと。
いきなりtypescriptオススメ。
補完効くからめっちゃ捗る。

2017/05/04(木) 21:01:14.87

>>59
そうですか:-)

2017/05/05(金) 12:57:26.72

typescriptの補完はjavascriptの補完として使うことも出来ますか？
ternjsでライブラリなどの補完がしたいんですが対応してないみたいで

2017/05/05(金) 21:24:46.13

javascriptでaddEventListenerによりイベント登録したときって実際どこに登録されてるの？

例えばpにclickを登録してconsole.dirしてみてもどこにも何か登録されたような状況が見当たりません・・・

2017/05/05(金) 22:27:05.74

参照する手段がないだけでP要素自身に紐付けられてる
EventEmitterだと登録済みのリスナー関数を取得できたりする

62 (ｱｳｱｳｳｰ Sab3-W+y+) · 2017/05/05(金) 23:23:40.21

イベントリスナ関数に適当な引数セットして関数内で引数をdirしてみたら
なんとなくイベントオブジェクト？的なものを見られましたわ

>>63
ありがうございました

2017/05/05(金) 23:26:56.16

Firefox
https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Examine_event_listeners

Chrome
https://developers.google.com/web/tools/chrome-devtools/console/command-line-reference#geteventlistenersobject

62 (ｱｳｱｳｳｰ Sab3-W+y+) · 2017/05/05(金) 23:39:07.79

>>65
なにこれすごい便利
ありがとうございます！

2017/05/05(金) 23:50:55.73

<form name="form_gp">
<input type="text" name="form_name">
</form>

document.forms["form_gp"].elements["form_name"]という書き方で
フォームが存在しているかどうかを調べることはできますか？
IDをつけてgetelementbyIDとかいうのを使わないとダメですか？
できたらそうやればいいんですか？

2017/05/06(土) 02:31:13.69

プログラム板のこのスレよりも、
web制作管理板の、JavaScriptのスレに書き込んだ方がいい

あっちの方が、人が多い

2017/05/06(土) 04:02:27.19

>>67
<form name="form_gp"> が増えないのなら、そのコードは期待通りに動作するが、増えることも考慮すると、for文で繰り返し処理する方が安全
idなら <form id="form_gp"> が増やせない(一応、増えても期待通りに動作する)
というわけで役割が違うので、比較対象にならない

とはいえ、id, class があれば、nameを積極的に使う理由がないのも確か
古いAPIなので、今では(初心者を除いて)ほとんど見ない書き方だな
古いAPIだからいけないわけでもないし、「新しいAPIだから」とか「トレンドだから」等の非合理的な理由で決めるべきものでもないが

2017/05/06(土) 10:24:39.94

すまん、>>69は忘れてくれ。
仕様では form[name] は「formsコレクションのform要素の中で一意でなければならない」とあるので、getElementByIdと同じ感覚で扱えるようだ。
https://momdo.github.io/html/forms.html#attr-form-name
idが良く推奨されるのはフラグメント識別子としても扱える利便性にあると思われる。

2017/05/06(土) 10:37:34.28

HTML4.01ではname属性は後方互換性のために規定とあり、id属性を推奨されているな。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/interact/forms.html#adef-name-FORM
XHTML1.0ではname属性が廃止されている。
http://www.y-adagio.com/public/standards/tr_xhtml_mod/abstract_modules.html#s_forms
HTML5では逆行しているが、この辺りがid属性が推奨される理由なのだろう。

2017/05/06(土) 11:30:21.16

>>70
不使用を推奨されているのはその辺が分かりにくい（一貫性がない）からでしょ。
例えばそのURL内（すぐ下のNote内）
> 一度要素が特定の名前を使用して参照されると、
> たとえ要素の実際のIDまたはnameを変更しても、要素がツリーに残る限り、
> その名前は、この方法でその要素を参照する方法として利用され続ける。
オイオイ！
JavaScriptから始めた人間としては、なんだこの糞仕様死ね、としか思えない。

>>67
ただ、その手の「○○はどっちを選ぶべきですか？」という質問については、
とりあえずどこか君から見てカッコイイサイトを探して、(2-3箇所ね）
その人達がどうしているかF12で見て、真似するのが一番いいと思うよ。
明らかにこっちの方がいいという場合はみんなそっちを使ってる。
どっちでもいい場合はばらけるけど、その場合はどっちでもいいので問題ない。

ここで聞いても「俺はこう思う」しか出てこない。デタラメを主張する奴もいるし。
67なんてきちんと訂正もして正しい回答を目指しているのでかなりまとも。
でも今の君には正直、「誰が正しいのか」を判断する目もないでしょ。
君のレベルなら多分、回答者がID制のところの方がいいと思うよ。

まあそもそも、フォームを探すこと自体が奇妙ではあるんだがね。
フォームがあったり無かったりってことがまず無い。
そういう場合は通常はdisplay:noneを使った方が効率がいいから、まともなサイトならそうしてる。
(今君が書いているコードが丸々不要になるだろ)
といっても俺はWeb屋ではないからここら辺の話は他の奴を信頼した方がいいとは思うが。

2017/05/06(土) 11:53:54.14

>>72
> JavaScriptから始めた人間としては、なんだこの糞仕様死ね、としか思えない。
>>67が使用しているコードでは RadioNodeList は使っていないように読めるので、それは別の話。

「他人のコードに倣っておけばOK」は参考にしたサイトがダメだと意味がないし、本当の意味で理解したとは言えないので個人的にはお勧めはしない。
客観的な評価としては、仕様書と回答内容を比較して正誤を判断するのが確実かね…。
少なくとも、模範となる信頼性の高いサイトが一つ二つないと初心者は間違いなく、はまる。

2017/05/06(土) 12:42:20.62

経験上、「どっちがいいですか」系の質問は「判断する目がない」もそうだが、「自分から学ぶ意志がない」がほとんどだな
自分から学ぶ意志がない質問は次のどちらかになる

- 質問文に自分の考えが皆無で回答者に判断を完全に委ねている質問
- 自分の考えがあっても、まともな基礎勉強してないことが丸分かりで、質問内容が広範、基礎から全部教えないと理解できないと思われる質問

後者は学ぶ意志はあるが、独学が苦手で熟練者に手取り足取り教えて貰う方が早いと思っているタイプ
まともな回答は豚に真珠なので、痛い目を見るまで間違い続けるのを見守るのも優しさかと思う

2017/05/06(土) 13:16:30.69

>>73
いや多分あの書き方だと、「一度捕まれたら名前は消えない」という仕様は、
RadioNodeList以外にも適用されてるぞ。
もっとも、同じ名前のフォームを使う場合がradioButton以外にはほぼないので、
自動脳内補完したのだとも思えるが。そもそも名前も変えないしね。

> 模範となる信頼性の高いサイトが一つ二つないと
まあ俺らはこれを提示すべきかもな。
つってもgoogleやYahooとか、いわゆる大手どころ
（Webサイトにも金を掛けて居るであろう所）
を見ればそんなに大外れはないとは思うが。

> 本当の意味で理解したとは言えないので個人的にはお勧めはしない
ちなみに俺は習うより慣れろ派。
初心者の時点ではどっちがいいなんて分からないよ。
そこで踏みとどまってしまってコードを書かないから上達しない。
だからどっちでもいいからとにかく書け、迷うなら適当に他人を参考にしろ、だね。
理想的には理解して書いた方がいいけど、それが出来る奴はあんな質問しないよ。
「どっちがいいですか」ではなく、「どこがどう違うんですか」になる。

>>74
初心者に要領を得た質問をしろというのはそもそも無理だ。

ただ一般論としては、同じようなAPIがあるのなら、とりあえず新しい方使っとけ、かな。
大体は古いのに問題があったから更新されてるもわけでね。
偶に「新しいことこそが正義」みたいな馬鹿も沸くけど、
それはここではある程度どうしようもない。

2017/05/06(土) 17:36:04.74

>>75
> 初心者に要領を得た質問をしろというのはそもそも無理だ。
「質問の初心者」と「JavaScriptの初心者」は等価ではないと俺は思う
そもそも、俺は要領を得た質問を求めているわけではない
(勿論、最終的にはそうなるのが理想だが)

俺が指摘しているのは「学ぶ姿勢」で受動的な学習しかしない人は伸びないのだよ
分からないなりに調べて、分からないなりに調べた結果を書いて、それで要領を得ない質問になったとしても、調べた経験は無駄にならない
回答者は質問者の知識レベルを踏まえた回答が出来るというメリットもある
それは回答を貰って「自分には難しすぎる」と匙を投げるか、出来る限り理解しようと努力するか、の違いでもある

自分から何も調べず、回答者に完璧な回答を求めて、回答を貰って満足するタイプは自分で調べる事をしないから、いつまでたっても他人に質問して問題解決を図ろうとする
そういう人は独り立ち出来ず、いつまでも「初心者」のままだ
実際、某Q&Aサイトでも名前を何度も変えては同じような質問を繰り返して、詳しい回答を貰うと「初心者なので分からないです」と返信する人がいるよ

2017/05/06(土) 17:42:11.82

>>75
> ただ一般論としては、同じようなAPIがあるのなら、とりあえず新しい方使っとけ、かな。
対象ブラウザによっては新旧APIを併用するか、旧APIを使用する事もある
PromiseとかFetchとか、IE11で実装されてないことを踏まえれば、「とりあえず、新しいAPIを使っとけ」という判断にはならない事もあるだろう

2017/05/06(土) 19:31:13.08

>>76
質問をするスキルか。確かに今の時代だとそれが必要なのかもしれないね。
初心者にも分かるように言うと、とにかく全部ダンプしろって事だな。
何をやろうとしていて、どこで引っかかっていて、何を迷っているか。
長文が～っていう奴はゴミだから無視でいい。
というかやってりゃ分かるはずだけど、
MDNでも仕様書でもここの「長文」どころじゃない。
三行越えたら長文だ～みたいな奴はプログラマに向いてない。

>>77
そういやJavaScriptはこれがあるんだった。
初心者にも分かる結論としては、
「新しめのAPIの方がいいが、新しすぎるのは駄目」ってところか。

2017/05/06(土) 22:35:31.96

いくら新しいAPIの知識はあっても
現状の実装をいかに把握するかだけ
これだけ

2017/05/06(土) 23:59:40.05

>>75
> いや多分あの書き方だと、「一度捕まれたら名前は消えない」という仕様は、
> RadioNodeList以外にも適用されてるぞ。
どうして「同じ」と解釈したのか、理解できなかったので、仕様のどの文章をどう解釈したのか、説明が欲しい。

document.forms は HTMLCollection を返すので live
https://momdo.github.io/html/dom.html#dom-document-forms
form[name] は RadioNodeList (NodeList を継承している) を返すので not live
form.elements は HTMLFormControlsCollection を返すが、HTMLCollection を継承するのでこちらも live
https://momdo.github.io/html/forms.html#the-form-element:dom-form-elements-2

Google Chrome 58.0.3029.96 で再現出来なかったので、現象を再現可能なコードも欲しい。
https://jsfiddle.net/3duzojn3/1/

2017/05/07(日) 00:55:55.42

>>80
こちらも動作を確認したがそちらと同じ。
英語の仕様書も確認したが確かにそう書いてある。
しかし動作はそうなってないね。

> 一度要素が特定の名前を使用して参照されると、
> たとえ要素の実際のIDまたはnameを変更しても、要素がツリーに残る限り、
> その名前は、この方法でその要素を参照する方法として利用され続ける。
これはつまり、ブラウザ内部に名前引き用のキャッシュを持っていて、
ヒットした場合はそれを使い、ミスなら新規登録、
ノードが取り除かれる時にエントリから消し、
DOMノードの属性変更ではエントリを確認してないと言っている。
（更新はしないので一旦登録されたら名前が残ったままになる）
高速化では定番の方法だし、実際に名前を変える必要があることは無いので、
内々で使う場合の仕様としてはこれもありだろう。
ただし外面仕様として出す場合はこれは無理だ。知識的に粗結合化出来てない。
（このAPIを使う場合に例外ケースを把握してないと使えない）

だからこの仕様を外面仕様としている場合は間違いなく糞だ。
ただし、実際の動作はそうなってない。
どっちが正しいのかは俺には分からん。

仕様として美しいのは間違いなく今のブラウザの動作だ。
だから推測するなら、
元々マクロ用だった為の奇妙な（ただし知っていると便利な）DOM周りの旧仕様を
一般的なプログラミング向けの仕様（直感的、統一的、一貫性重視）に
変更している最中といったところか。
俺が仕様について裁定する権限があるのなら、
上記引用部分を削除して終わりだね。（ブラウザの動作に合わせる）

2017/05/07(日) 05:32:07.74

そういうのはDOM Lv0といって昔のデファクトを文章にしただけのものだから
ベンダー間でこうしていきましょうねと合意が取れてるものとは違うぞ
Webは生き物だから正しいも正しくないもない
神様も居ない

2017/05/07(日) 09:10:15.71

まあしかし、仕様書と実装の同期は取っておくべきだろ。
それが>>80の意図だろ多分。

こちらで試した限りではFireFoxでも同じだった。
80が仕様について何かやっている人なら頑張れとしか。

2017/05/07(日) 09:41:57.10

>>81
伝わってないようだが、「その3行の意味が理解できないから説明してくれ」や「その仕様が糞である理由を説明してくれ」ではない。
RadioNodeList 以外にも「たとえ要素の実際のIDまたはnameを変更しても、要素がツリーに残る限り、その名前は、この方法でその要素を参照する方法として利用され続ける」が適用されると判断した「仕様の文章」を引用して「あなたの解釈」を説明してくれ。

2017/05/07(日) 09:51:22.86

>>84
いやそれは文章そのものだろ。
和文も英文も、あの書き方ならRadioNodeList以外も含むとしか取れないが。
てかお前、日本語も英文も読めない人？

2017/05/07(日) 09:57:53.45

HTML Standard や DOM Standard には「後方互換性の為に標準化した旧来の仕様」が多数存在する。
(>>82のいう DOM Level 0がそれだが、子の表記はMDNでしか見たことがないな)
XHTML2.0での失敗、IE6がいつまでも現役時代だった失敗を経て、HTML5 では既存のブラウザで動く事を重視して標準化しているからだ。
それが彼(>81)の言う「糞な仕様」だが、そうする事で旧来の古いブラウザの独自拡張で書いたコードも全てのブラウザで動くことが保証される。
「美しい仕様」よりも「動く仕様」を重視しているので、>>81とは目指すべき方向が違う。

2017/05/07(日) 10:05:18.25

>>85
そこまで否定される筋合いはないんだが、なぜそう挑発的なんだ？

> 指定したIDまたはname（歴史的な理由でイメージボタンを除く）をもつフォームでフォームコントロール（または複数存在する場合、フォームコントロールのRadioNodeList）を返す。または、いずれも存在しない場合、与えられたIDとともにimg要素を返す。
> 一度要素が特定の名前を使用して参照されると、たとえ要素の実際のIDまたはnameを変更しても、要素がツリーに残る限り、その名前は、この方法でその要素を参照する方法として利用され続ける。
> 複数のマッチするアイテムが存在する場合、それらの要素すべてを含むRadioNodeListオブジェクトが返される。

この文章は form[name] に書かれたもの。
文章内で「form.elements や document.forms にも適用される」とはない。
返り値の Interface も RadioNodeList と HTMLCollection で全く違う。
どう解釈したら「form.elements や document.forms にも適用される」となるのか日本語を読めない俺に説明してくれ。

2017/05/07(日) 10:48:18.68

>>87
> 日本語を読めない俺に説明してくれ。
それは無理。

ここで国語の授業をするのは原理的に無理なんだよ。
俺が日本語でいくら説明しても、君はそれを俺が意図した通りに読めないことを意味する。
君がいくら反論してきても、それは俺には君が意図したとおりには伝わらないことを意味する。
だから片方の言語が不自由な時点で、「文章での」議論は空転する。
だからこそ韓国人はここではものすごく嫌われているわけでね。

俺には和文も英文もそうとしか取れないし、
仮にそれが俺の間違いなら、俺がそれを君に俺の文章で説明することは不可能なんだよ。
だから原理的に無理。

2017/05/07(日) 10:57:46.04

>>88
そうか。日本語を日本語で説明できないとは謎理論だが、あなたの中ではそうなんだな。
>>87では「日本語が読めない」と書いたが、それは言葉の綾で俺は日本語を読めると思っている。
「>>88の中では RadioNodeList 以外にも適用されると解釈したんだな」ぐらいに思っておくことにする。
俺はあなたの根拠なき主張を信じないがね。

2017/05/07(日) 11:16:41.63

なぜいつもこうなるのか

2017/05/07(日) 12:08:47.12

韓国人が紛れ込んでいるからだろ。
2chにおける典型的なスレ崩壊パターンだよ。
だから彼等は嫌われる。

実を言うと80の時点で意味不明だった。
そもそも俺が噛み付かれる理由がないし、
文章自体も直接的に俺に向けた物とも思えなかった。（話が噛み合っていない）
ただ俺はこういう馬鹿も見飽きてるし、コードが上がっているので試しに見てみたら、
ああなるほど彼はこれが言いたかったのか？と思って81を書いた。
それが伝わっていないというのなら、俺にはどうしようもない。あれで精一杯だ。

ちなみに俺はゆとりに対しても同様に怒っているが、
ゆとりに関しては日本人だから俺らにも教育責任はあるとも思う。
ただ韓国人については死ねとしか思わないね。

2017/05/07(日) 12:18:54.29

ID:nVVEnA7X0 が感情的になって無駄に煽るから、こうなる
どちらかが間違っている事ご分かっていて、「日本語も英文も読めない人？」といわれたら、カチンとくるのは当然
>>80はそれでも我慢した方だと思う

2017/05/07(日) 12:23:58.61

支離滅裂すぎる
全然関係ないこのスレに人種差別持ち込むなよ

2017/05/07(日) 12:39:51.32

>>92
逆ギレ止めーや。
つか最近そういう奴も増えたけどね。
基本的価値観として、まともな日本人なら、「間違っている奴が悪い」なんだよ。

既に書いたが、和文も英文も俺にはそうとしか読めないし、
それで間違っているというのなら、俺がそれを説明する能力なんて原理的にないのさ。
だからその説明を俺に求めるのも論理的に矛盾してる。
お前らは馬鹿すぎてこのことが理解出来ないようだが。

2017/05/07(日) 13:22:06.98

>>93
そうやって正統な批判を全部人種差別にすり替えるのが韓国人の汚い手口だよ。
だから今後とも嫌韓は収まらない。

そもそもここで韓国人呼ばわりされることがおかしいだろ。
顔も見えない、性別も分からない、見えるのは書き込みだけなのに。
それでも嫌われるのはそういうことをやり続けてるからだよ。
今回の例で言えば、

仕様書「RadioNodeListを含みます」
俺「『含みます』って書いてあると思うけど」
韓国人「いやそうは書いてない。書いているという証拠を示せ」
俺(どうしろと)

俺が間違っているというのなら、お前らが代わりに説明してやればいいだけ。
それも出来ないのなら、お前らは批判の為の批判をしているだけ。
それは韓国人やヤクザの手口だよ。だから彼等は嫌われる。
そういうゴミを嫌う権利は誰にでもある。ここら辺をパヨクは間違っている。
もちろん、俺を嫌う権利はお前らにもある。
だから俺はWeb板のスレには行かない。俺が嫌いならあっちで頑張れ。
あっちはあっちで機能しているし。

こうやって複数のスレで競争しないと、
今のJavaScriptのスレの面子では状態を改善出来ないんだ。
だから俺が強硬に並立を主張したわけでね。

2017/05/07(日) 13:30:47.09

ああすまん、ミスってた。
無駄に喧嘩になっても仕方ないので一応投稿し直す。

仕様書「RadioNodeList以外も含みます」
俺「『含みます』って書いてあると思うけど」
韓国人「いやそうは書いてない。書いているという証拠を示せ」
俺(どうしろと)

とにかく、俺には含みますと書いてあるとしか見えない。
それが俺の間違いだというのなら、君らがそれを指摘してくれればいい。
俺にはこれ以上どうすることも出来ないのさ。

2017/05/07(日) 13:37:00.76

┐(´∀｀)┌

2017/05/07(日) 13:42:44.84

典型的なネット右翼やな

2017/05/07(日) 14:22:41.48

空気を読まずに蒸し返してみる

ある事の証明は存在をひとつ示せばいい
ない事の証明は全てを網羅しなければならない
この２つの証明はは等価ではなく後者の方が圧倒的に困難である
よって、ないことを証明しろ、それが出来ないならあるのだという論法は典型的な詭弁の手法として用いられる

ある事が分かっているならば当該箇所を示せばその時点で論破()できるのに、それをせずに相手に悪魔の証明を求めるのは、あるという証拠の１つすら示せないからに他ならない

2017/05/07(日) 14:55:04.57

つか、何度も言っているが、
俺が間違っているというのなら、お前らが説明してやれよ。
マジでお前らヤクザのやり方を地で行ってるぞ。

仕様書の該当部分は既に明示されているし、
そこにはそう書いてある（と俺には読める）
これ以上俺が出来ることはないんだよ。

お前らって、内容を読まずに批判する為の批判を繰り返すよね。
そして相手が悪いという事に無理矢理持っていこうとする。
これはゆとりに多いパターンだけど。

あ (ｱｳｱｳｲｰ Sa37-gZQE) · 2017/05/07(日) 15:04:07.44

イデオロギーと主張と日本語が読めないと言うのは互いに疎だろうから、ちょっとこうなると話が終わらなくなるな。

>>95
正当か正当でないかは主観だから言い換えるとして「正当かもしれない批判を全部人種差別にすり替える」を技を
>>95という批難のレスが自己言及を起こしてるから、根拠を足すか別の表現で説明して。
批判のための批判ではなくて、論理的に正しい批判が読みたいな、俺は。

2017/05/07(日) 15:38:18.75

>>101
日本語でおk

2017/05/07(日) 16:22:44.83

ヤクザ、ゆとり、韓国人、これらはすべて論理的な議論において無用なレッテル貼りでありこれまた詭弁の典型例である
発言者が馬鹿だと論旨の正否に関わらず批判を受けるという好例だわ

2017/05/07(日) 16:58:46.44

>>80は真っ当なものだし、正しいと俺は思う
根拠(URL)も十分に出てるし、補足することは何もない

対して彼の返答は「そうとしか読めない」しかなく、具体的なところは何もない
信じてもらえなくて当然だと思う

2017/05/07(日) 17:24:34.96

>>96
少なくとも彼は>>80や>>87で自分の正当性を説明出来ているけどね
君はなぜか完全スルーの構えでそこに触れてないが
仕様は変わらないのだから、仕様の解釈を説明するしかないのに、それが出来ないのは君に説明能力がないとしか思えない

あと、君の発言は段々、暴論になってきているから気を付けた方がいい
人格否定や差別的発言は明らかに君が間違ってる(君の論にてらせば、君が悪い)
いっちゃ悪いが、自分の発言が認められなくてだだをこねている子供のようだ

2017/05/07(日) 19:09:24.78

というかこの手の「ゆとりスクラム」、最近割と良く遭遇するようになったが、何がしたいんだ？

俺に説明能力がないというのなら、俺に説明を求めること自体がおかしいし、
説明能力があるゆとり君が代わって説明すればいいだけ。
俺が文章を読めてないというのなら、俺にそれを文章で説明しろというのは無理な話。
俺を信じれないというのなら、ああそうですかでしかない。そもそもそういう話ではないし。

ゆとりって基本的に他人に文句は言うけど、自分で改善しようとは全くしないよね。
今の現実世界はそれまでの大人達が少しずつ改善を重ねてきた結果だというのに。

俺は2chしかほぼ見てないから
> 実際、某Q&Aサイトでも名前を何度も変えては同じような質問を繰り返して、
> 詳しい回答を貰うと「初心者なので分からないです」と返信する人がいるよ (>>76)
には遭遇したことがないけど、(というより遭遇しても気づくほど見てない)
この手の「無理矢理○○って事にしたい」ってのは最近すごく遭遇するんだが。

2017/05/07(日) 20:11:06.03

わかったから他所でやってや
ゆとりでもそうでなくてもどうでもいいが、スレタイぐらいは読めるやろ

あ (ｱｳｱｳｲｰ Sa37-gZQE) · 2017/05/07(日) 20:31:31.21

>>102
日本語読めないんだ。

あ (ｱｳｱｳｲｰ Sa37-gZQE) · 2017/05/07(日) 20:36:30.42

>>106
破綻しとる。
自説を説明する能力がある人間でも、代わって「おまえの理論」の説明はできまい。
説明能力が無いなら説明を求めるのがおかしいって無茶苦茶じゃん。
説明能力がある奴に、説明を求めるのは無意味だろ。
だって説明能力があるならば、求めるより前に説明してるはずじゃん。
説明能力か無いからこそ、説明しろと要求されていると思えよ。
論理的にやろう。ゆとりも、非ゆとりもな。

2017/05/07(日) 21:20:48.44

> 俺に説明能力がないというのなら、俺に説明を求めること自体がおかしいし、

書いてあんだろ？

「俺に説明能力がない」だ
説明が足りないじゃない。
説明する能力がないのだ。

感情を表現する能力がないやつに
感情を表現しろと言っても無理だろ？
計算する能力がないやつに計算しろと言っても無理だろ？
説明する能力がないやつに説明しろって言っても無理だろ？

2017/05/07(日) 21:34:41.49

つまり結局こうだろ

>>109
日本語でおk

2017/05/07(日) 21:46:16.89

要するに「無能」が正しいと認めているわけだから、
「無能」に聞いても、能力がないやつには答えられないということ

あ (ｽﾌｯ Sd52-gZQE) · 2017/05/08(月) 06:06:52.81

>>112
違う違う。
無能だからこそ、説明を求められるんだ、と。
能力が無いならば、最初から説明しようとすらするはずが無いんだよ。
全くできない事をしようとする事はあり得ないんだし。
空が飛べないのに空を飛んで見せるのが、全くできない事をするって言うことだよ。

相手の言葉をうまく摘んで「無い」の定義を適当に用意してはいかん。ただの逃避だよ。
それこそ自分が揶揄してるやつ。
吐いた唾は飲もう。

2017/05/08(月) 09:35:49.25

無能なほど意味不明な説明をしたがる

2017/05/08(月) 11:29:12.00

自らの正当性を主張する人が自己完結していないわけがなので、ID:nVVEnA7X0も俺も自己完結している点では同じ
見解の相違で衝突した場合、お互いに根拠を出しながら意見を出すのが普通
相手の論理を崩すには「相手が出した根拠が間違っている証拠」をだしたり、「根拠の解釈が間違っている論理的矛盾」をだしたり、と論理的に話をする

ところが、ID:nVVEnA7X0 は「いや多分あの書き方だと(>>75)」「そうとしか取れない(>>88)」と恣意的な感想を述べるばかりで根拠も論理展開も何もなければ、相手の論理的矛盾に言及するわけでもない
根拠や意見を掲示するのは>>80だけ
説明出来ないというが、「そうとしか取れない」理由を具体化すれば説明可能なはず
具体的な何をすれば良いかは>>84で補足要求してくれているのに無反応
この状況で説明能力がないといわれるのは仕方がないし、何も反論出来ないのなら説明能力がないと認めているも同義だと思うがね

2017/05/08(月) 11:29:40.46

人間なんてみんな無能だよ
協力し合わないとなにも為せないんだよ
そのことを忘れちゃだめ

2017/05/08(月) 13:25:26.02

とりあえずスレ違いだからツイッターあたりでバトってもらっていいかな？

2017/05/08(月) 14:07:05.92

一体何と闘ってるの？w

2017/05/08(月) 21:44:07.20

そりゃレスした相手とじゃね？

2017/05/11(木) 22:25:00.55

window.fetchでshift-jisのデータをダウンロードしてresponse.text()で文字列にすると文字化けしてしまうのですがどのようにすれば文字化けしないようにできますか？

2017/05/12(金) 08:25:26.77

>>120
サーバ側で正しい文字コード(Shift_JIS)を指定する
https://www.google.co.jp/search?q=htaccess+charset

2017/05/12(金) 08:36:44.00

>>121
外部サーバーなので出来ないです(´；ω；`)

2017/05/12(金) 09:15:45.68

メッセージングの手段とかないの？
まあ例えばC#アプリとやり取りするときとか、最も汎用的な方法はローカルWebSocketだよ

2017/05/12(金) 09:40:01.01

2chも、shift-jisだから、JSで扱えない

でも、YQL(Yahoo Query Language)を通して取得したら、UTF-8になってる。
文字コードを推測して、変換しているのかね？

この板よりも、web制作管理板で質問した方がよいかも。
そっちの方が、人が多いから

2017/05/12(金) 09:46:56.13

> 2chも、shift-jisだから、JSで扱えない

そんなわけねーだろｗ
文字コードを変換すればいいだけ

2017/05/12(金) 09:48:05.24

もしくは適切にパラメータ与えれば
ブラウザが勝手にやってくれる

**124** (ﾜｯﾁｮｲ cf75-yoyE) · 2017/05/12(金) 10:15:34.52

iframe に読み込ませれば、ブラウザが自動変換するから、文字化けしないけど、
自分で、JSで、2chのHTMLを取得しようとすると、shift-jis のままじゃないの？

つまり、ブラウザを通せば、変換されるけど

2017/05/12(金) 13:33:42.65

Fetch APIにはContent-Typeを上書きする機構はないのかな

>>122
外部サーバならクロスドメインを許可してる事になるという事？
それなら、そのサーバ管理者に相談してみては？

2017/05/12(金) 13:46:56.99

http://echo.2ch.net/test/read.cgi/hp/1456242505/392
「移動を勧められたので、移動しました」と言い訳しそうだが、質問をクローズせずに並行質問する行為はマルチポストという
人が多いとノイズも多くなるので、俺はWeb制作板をお勧めしないな

2017/05/12(金) 13:55:16.77

new Headers で XMLHttpRequest#overrideMimeType 相当の機能が実装できそうだが
https://sbfl.net/blog/2017/01/29/fetch-api/#i-3