+ JavaScript の質問用スレッド vol.126 +

**デフォルトの名無しさん** · 2018/06/02(土) 14:31:23.04

JavaScript を自ら学ぶ人のための質問スレッドです。

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

前スレ
+ JavaScript の質問用スレッド vol.125 +
https://mevius.5ch.net/test/read.cgi/tech/1518940081/

（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）

**デフォルトの名無しさん** · 2018/10/31(水) 01:09:10.31

ググレカス

**デフォルトの名無しさん** · 2018/10/31(水) 02:59:19.61

このページには、やり方が書いてないだろ。
要素の挿入かな？

$("#parent").append("<p>あいう：<b>abc</b></p>");

jQuery などの質問は、この板よりも、web制作管理板へ書き込んで！

**デフォルトの名無しさん** · 2018/10/31(水) 15:10:14.27

>>237
よく分からん
申し訳ないけどそのままコピーして使えるように記述して

**237** · 2018/11/01(木) 00:45:15.87

jQuery も知らんの？
$( ) は、jQuery関数

#parent の# は、id を表す。
<div id="parent"></div>

HTML, CSS, JavaScript, jQueryの、初心者用の本でも読んで、勉強して

**デフォルトの名無しさん** · 2018/11/01(木) 03:20:19.15

jQuery は読まなくていいよ

**デフォルトの名無しさん** · 2018/11/01(木) 08:31:05.31

Electornってブラウザで動くのにnode.jsなんですか？
初心者すぎてその辺よくわからん

**デフォルトの名無しさん** · 2018/11/01(木) 08:52:13.83

いいえV8です

**デフォルトの名無しさん** · 2018/11/01(木) 09:04:59.81

node.js は、普通のプログラム言語と同じで、ローカルPC のファイルにアクセスできる。
だから、node.js を使っているElectron は、VSCode を作った

VSCodeは、普通のIDE と同じ。
ただ、JavaScript で作られただけ

**デフォルトの名無しさん** · 2018/11/01(木) 13:23:12.38

じゃあnodeはローカルにもブラウザにもアクセスできるってこと？

**デフォルトの名無しさん** · 2018/11/01(木) 20:22:01.79

VSCode は、Electron で作られている普通のIDE。
ローカルPC のファイルにアクセスできる

Electron は、node.js + ブラウザのChromium。
画面は、HTML, CSS, JavaScript で作って、ブラウザで表示している

ほとんどの言語の開発で、VSCode を使う

漏れは、Ruby から、Selenium WebDriver を使って、ブラウザを自動操作している

Rubyで、ローカルPCの画像ファイルにアクセスして、
HTML, CSS, JavaScript で画面を作って、画像をブラウザで表示している

言語が異なっても、基本的な仕組みは同じ

**デフォルトの名無しさん** · 2018/11/02(金) 12:33:09.51

ブラウザの拡張機能やアプリと同じだよ
普通のUIはChromiumで普通のWebページ側のメインプロセス、
それとNodeのバックグラウンドプロセスが通信でやり取りする形
ただその通信が幾らか隠蔽されてるのでメインプロセスからでも特権的なAPIが自然と使える

**デフォルトの名無しさん** · 2018/11/04(日) 21:51:54.73

7..toString(2)の..って何ですか？

**デフォルトの名無しさん** · 2018/11/04(日) 22:10:06.82

>>247
小数点とプロパティアクセサ

**デフォルトの名無しさん** · 2018/11/04(日) 22:22:36.06

>>248
なるほど
7.toString()だと
SyntaxError: identifier starts immediately after numeric literal
7が数字から始まる不正な変数名だと認識されるという理解でよろしいか？

**デフォルトの名無しさん** · 2018/11/04(日) 22:32:31.49

中学英語も出来ないのかよ…
識別子が数値リテラルの直後から始まってます

**デフォルトの名無しさん** · 2018/11/04(日) 22:34:19.63

7は数値リテラルと認識されてるんで変数名と認識されてるわけではない

**デフォルトの名無しさん** · 2018/11/04(日) 22:35:32.03

>>247
そんなのは無視でいい。

初心者はそういうところばかりに目が行くようだが、上達を妨げるだけ。
そんな書き方する馬鹿なんていない。

**デフォルトの名無しさん** · 2018/11/04(日) 22:44:48.73

>>250
identifierは中学で習う英単語には出てこないが？
http://www.eigo-duke.com/tango/tangoindex.html
高2でようやくidentifyがでてくる

immediatelyは高1。numericもliteralも高校でも出てこない

**デフォルトの名無しさん** · 2018/11/04(日) 22:47:52.87

7..toString(2)
(7.).toString(2)
(7.0).toString(2)

どれでも文字列の、'111' と表示される

(7.0)
(7.)
7.

どれでも数値型の、7 と表示される

**デフォルトの名無しさん** · 2018/11/04(日) 23:00:03.48

な、なな、なんと！？

**デフォルトの名無しさん** · 2018/11/05(月) 06:30:57.02

7.0toString()
とできないように
7.toString()
とできないということ

**デフォルトの名無しさん** · 2018/11/05(月) 11:56:57.88

name="form1" の form を参照するのに document.form1 って書き方があるけど、これがうまくいかないケースがあったので理由が知りたい。
自分のページは mydomain にあり、外のドメイン extdomain のJSライブラリを使ってる。
そのJSライブラリはAJAXを使って extdomain の中で処理を行ない、完了後にコールバックしてくれる。
mydomain のページ中 form1 が submit されるイベントでこんな感じでライブラリを呼び出し、コールバックまで処理が来てる。

function smtForm1()
{
:
外部ライブラリ(smtForm1Callback);
return false;
}

function smtForm1Callback()
{
var f = document.form1;
:
}

このコールバックの中で form1 を参照したいんだけど、上記のコードだと f は undefined になる。
form1 に id="form1" も加えて document.getEementById("form1") とやると参照できたものの、document.form1 じゃダメな理由が分からない。
実は同じコードが同じ外部ライブラリ使って同じブラウザで動く環境もあるから、サーバのセキュリティがらみの設定の問題のような気がしながらもよく分からずにいる。
原因とかチェックポイントとかアドバイスください。

**デフォルトの名無しさん** · 2018/11/05(月) 12:10:08.11

呼び出し元はどう本体呼び出してんの？
スタックトレース見てみたら？

**デフォルトの名無しさん** · 2018/11/05(月) 13:12:30.96

もしかして
document.forms.form1

**デフォルトの名無しさん** · 2018/11/05(月) 22:57:46.85

「js document」で検索！

Document
https://developer.mozilla.org/ja/docs/Web/API/document

document は、DOM ツリーのエントリーポイント。
document.write などが有名

自作のフォーム名などが、document のメソッド名になる事はない。
document のメソッド名は、あらかじめ決まっているから

**257** · 2018/11/05(月) 23:16:36.71

>>258
どうやら外部ライブラリは body の中に scriptタグを作り出し、そこでロードされるスクリプトにコールバックを呼び出すだけのコードが書かれてるらしい。
だからグローバルスコープからのコールバック呼び出しかな。
この scriptタグの生成によって document の再構築でも起こって、まだ form1 が取り込まれてない状態になってるとかかな？

>>259
いや、普通は document.form1 で参照できてる。

>>260
メソッドじゃなくプロパティじゃないかな。
document 直下にフォームの name のプロパティが出来上がる。
という動作はブラウザでJavaScriptが盛り込まれた頃からの仕様だと思ってたけど、非推薦かなんかになってたりする？

**デフォルトの名無しさん** · 2018/11/06(火) 01:27:51.27

>>261
仕様ならMDNなり仕様書なりに載ってるはずだから、とりあえず探してみれば？

それ以前にまともな奴ならそんな物使わないが。
nameは重複許可だから、それは仕様バグであり、使い物にならない。
仮に仕様であったとしても、削除/変更されるのは時間の問題だ。地雷臭が酷すぎる。
お前も含めてJavaScripterは全員馬鹿だからここら辺を理解出来ないようだけど。

**デフォルトの名無しさん** · 2018/11/06(火) 07:04:44.97

nameが何にためにあるのかを知っていれば
重複可なのが当たり前でそのformを１つだけ参照するものがあっても
常識の範囲で有意義に使えることが分かる
まあ馬鹿にはわからないだろうが

**デフォルトの名無しさん** · 2018/11/06(火) 09:04:41.69

同じ名前の人が二人いるとかおかしいじゃないですか

**デフォルトの名無しさん** · 2018/11/06(火) 09:46:57.23

>>263
唯一性をユーザー側で保証出来るのならid使え、ってことになってるだろ。

旧API（のつもり？)を使用し続けるのなら、それが今どういう状況になっているのか、自分で把握しておく必要がある。
そんな質問している時点でアウトでしょ。
とりあえず仕様書やMDNを漁って、「今でも使えるものか」確認しないと駄目だと思うよ。
ただそれ以前に、それが仕様であったとしても、動かないんなら意味無いけど。
（お前が「仕様だ！俺は悪くない！」とごねたところでコードが動くようにはならない）

大体、document.forms.xxx ならさておき、ドキュメント直下 document.xxx は不味いとすぐ分かるだろ。
それが仕様であったなら、早々に非推奨になって削除されるべきだし、実際多分そうなんだろ。
仕様がどんどん改訂されるプラットフォームなのだから、良くも悪くもトレンドに沿ってないと駄目なんだよ。
それだって、idで参照するようにしていれば、最初からそんな疑問すらわかないわけでさ。
仕様だから使える！と思ってる時点で馬鹿確定なんだよ。

お前も含めて、JavaSripterはコードを書き捨てばかりしているから、大局観が全く育ってない。
動かないから書き直す、ではなく、
何故書き直す羽目になったのか、どう書いていれば書き直さずに済んだのか、それを考える癖を付けた方がいい。
繰り返すが、それ、id/classで参照する今風のコードなら、問題すら発生しなかったわけでしょ。
お前ら、マッチポンプをしていることにすら気づいてないだろ。

**デフォルトの名無しさん** · 2018/11/06(火) 09:47:16.32

>>257
これかな
https://stackoverflow.com/questions/7436277/document-formname-is-undefined/14804179#14804179

**257** · 2018/11/06(火) 10:49:05.82

>>266
英語読みきれてなかったらスマンだけど、それはアプリケーションサーバの設定の問題でローカル開発環境では form の name が出力されてなかったってことかな？
であればちょっと違うかも。

>>265
言わんとしてることはよく分かるよ。
でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
どうやってもその書き方じゃ動かないという話なら、機能として削除されたんだろうとも思うわけ。
>>257 の例だと、コールバックじゃないところでの例えば smtForm1内での document.form1 は問題無いし、それどころか同じものを別サーバへ設置するとコールバックの中でも動いたりする。
同じブラウザで。サーバはどっちも同じ apache で。ブラウザに渡ってる HTML も全く同一で。
しかしブラウザ依存でもないようで、動かない時はどのブラウザでも同じように動かない。
だからクロスドメイン周りの設定に差があるのかとサーバからの HTTPヘッダを比較してもこれと言った差も無いようで、よくわからんって話さ。
ただこのページに仕込んである他のJSの挙動が置くサーバによって違ってるのかもしれない。ページが安定した後の document に影響があるようなことは無いだろうと思って言わなくて悪かったけど。
ちなみに他のJSってアクセス解析の類い。
んじゃそれ外して試せばいいじゃんとなるだろうけど、いつか確かめるけど事情により今すぐは難しい。

といった感じで実用面では他のより良い手段でやればいいことなので問題があるわけじゃないんだけど、理由は知っておきたいという話。
どこでハマるか分からんし。

**デフォルトの名無しさん** · 2018/11/06(火) 11:11:11.71

> どこでハマるか分からんし。

だからみんなjQuery使うんだよ

**デフォルトの名無しさん** · 2018/11/06(火) 11:21:39.49

もう誰もjQueryなんて使ってない

**デフォルトの名無しさん** · 2018/11/06(火) 11:53:23.90

>>267
> 同じコードが動いたり動かなかったりするからなんでって聞いてるの
それはそうだから、でしかないだろ。

まず、今現在「仕様」かどうか確認しろよ。
それで「仕様」でないのなら、それは偶々動いていただけであって、それだけでしかない。
ブラウザは大幅に更新されてる。
元々それを動かすコードをブラウザが持っていたとして、
仕様から外れた時点でそれをどこで落とすかはブラウザ開発者の自由だし、
結果的に一部残っていて動いたり動かなかったりするのも問題なしだ。
そしてそうなってるだけだろ。

「仕様」でなければ何の不思議もないし、「仕様」であればバグ報告すればいいだけだろ。

そしてその範囲を知る意味もない。
ありがちなパターンとしては、「古いコードもある程度までは動くようにする」為に、
初期構築（最初の構築)だけはそのコードを通し（つまり旧来方法でのアクセスも可能）、
追加で動的構築したDOMについては追跡してない(つまり旧来方法でのアクセスは不可能)といったところか。
ただこれを知ったところで、いつ変更されるかも分からんし、意味無いだろ。

> どこでハマるか分からんし。
「仕様」かどうかはさておき、「みんな」が「今」使ってない方法を使ったら駄目、ってことでしかないだろ。
そういったコードは、必要に応じて書き換えて「今」のトレンドに乗るようにするか、
jQueryみたいに「バージョン○○では…」と自前で管理しきるしかない。
どっちもする気がないのなら、それはお前の問題だ。

初心者にありがちな、全て「仕様」で確定している、という勘違いなら、頭を切り換えた方がいい。
厳密に仕様準拠なら、「必ずundefinedが返る」のが正しいが、
JavaScript界隈はそういう厳密さより、上記のように旧来コードも動くような曖昧さを残した方が好まれる。
結果、今の君のように、「ある日突然コードが動かなくなって？？？、環境依存？？？」な事も発生し、
それが長期的に生産性を下げる要因になっているのも事実だが。

**デフォルトの名無しさん** · 2018/11/06(火) 12:09:12.29

>>267
> でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
グローバル変数に関する規定はあるが、documentは分からん
納得できるまで、自分で調べてくれ
https://momdo.github.io/html/window-object.html#named-access-on-the-window-object
https://momdo.github.io/html/dom.html#the-document-object

あと、それを使うと決めたあなたの判断基準が分からん

**デフォルトの名無しさん** · 2018/11/06(火) 13:49:56.96

>>269
> もう誰もjQueryなんて使ってない
いちいち嘘つくなよ。どうせ俺がバラすんだから逆効果にしかならんぞｗ

https://w3techs.com/technologies/overview/javascript_library/all

w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月～2018年10月の約半年間で変化が見られず、ようやく73.3%～73.4%で
増加が停止したようである。

しかしながら、減少の傾向は見られず、マーケットシェア（JavaScriptを使用しているサイトでの使用率）
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる

jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。

またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。

この状況が大きく変化するときは来るのだろうか？この先の動向が注目される

**デフォルトの名無しさん** · 2018/11/06(火) 14:36:25.99

前線の開発者が新規にwebアプリ作る時はもう使わんというだけで
全体から見たらそんなのごくごく希少さね

**デフォルトの名無しさん** · 2018/11/06(火) 14:42:55.62

Angularが減ったのはまだ誤差の範囲内だと思うけど
Reactがこんなに減ったのはなんでだろうな

**デフォルトの名無しさん** · 2018/11/06(火) 14:44:59.13

保守ではjQueryあるけど新規は全くない
俺なところはほぼAngular
最近はJAVA有料化の流れのおかげでnodejsも上げてきてる

**デフォルトの名無しさん** · 2018/11/06(火) 14:56:30.64

そもそも新規の仕事ってのがないってだけなので、
jQueryがまったくないという言い方はおかしい

同様にAngularやReactを使うこともないんだから
新規の仕事が無いのでね

たいていは過去やったことの続きか、
別の客に同じようなものを提供するので
そこで使われてるjQueryがそのまま使われる

**デフォルトの名無しさん** · 2018/11/06(火) 20:15:00.55

>>264
全国の鈴木一郎に謝れ！

**デフォルトの名無しさん** · 2018/11/06(火) 20:34:37.04

ここまで探せば１分で見つかる仕様提示　無し
https://html.spec.whatwg.org/multipage/dom.html#dom-document-nameditem

**デフォルトの名無しさん** · 2018/11/06(火) 22:25:14.22

>>278
「3.1.3 DOM tree accessors」の中だったか
参考までに、どうやって検索した？

**デフォルトの名無しさん** · 2018/11/06(火) 22:53:30.78

とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った

なぜか逆ギレされたけど

**デフォルトの名無しさん** · 2018/11/06(火) 23:01:46.77

>>280
自演か？
それを257が言うのはともかく、お前が言うのはおかしいだろ。

**デフォルトの名無しさん** · 2018/11/06(火) 23:08:25.32

自演ではないね。
そういう事がありましたってことだよ
起こったことはちゃんと書かないとｗ

**デフォルトの名無しさん** · 2018/11/06(火) 23:13:35.68

>>282
まず立場をはっきりさせろよ。
まあお前のレスを見る限り、正直、257のケース以外のところで怒らせてると思うけどね。

**デフォルトの名無しさん** · 2018/11/06(火) 23:29:44.69

>>283
俺の立場は「誰が書いたか？」ではなくて「書いてある内容」しかみない
だから俺にも立場を求めるな。

**デフォルトの名無しさん** · 2018/11/06(火) 23:44:03.25

>>284
やはり通じてねえw
そこがお前の駄目なところで、客もそれに怒ったんだと思うぜ。
まあ、完全に空回りだからもういいが。

**デフォルトの名無しさん** · 2018/11/07(水) 00:45:22.01

>>285
流行り通じてねぇｗ

「
　とりあえずバグなんで、ブラウザの対応待ちですわ
　客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
　
　なぜか逆ギレされたけど
」

ということが、起こったんですよ。彼の現場ではね！
って話だろうがｗ

**デフォルトの名無しさん** · 2018/11/07(水) 00:45:39.54

× 流行り通じてねぇｗ
○ はやり通じてねぇｗ

**デフォルトの名無しさん** · 2018/11/07(水) 05:11:53.04

+new Date()の+って何ですか？

**デフォルトの名無しさん** · 2018/11/07(水) 06:48:51.19

>>280
ブラウザはOSやグラフィックドライバなどのバグにきちんと対処してるぞ

**デフォルトの名無しさん** · 2018/11/07(水) 06:50:32.64

>>288
+-のプラス　単項演算子

**デフォルトの名無しさん** · 2018/11/07(水) 07:32:08.33

>>267
>別サーバへ設置するとコールバックの中でも動いたりする
実行環境が異なると、使っているライブラリも変わる

それと一般的には、動いたり動かなかったりするのは、非同期処理を勘違いしているとか。
promise とかで、ちゃんと解決してない

処理A, B の順番では動くけど、B, A の順番では動かないとか

1回目は、ファイルの読み込みに時間が掛かるから、エラーになっても、
2回目は、キャッシュから読み込むから、エラーにならないとか

ちゃんと非同期処理をやっていないのに、タイミング次第で動いているアプリは多い。
その特徴はエラーになったり、動いたりすること

ログを見れば、わかる

**デフォルトの名無しさん** · 2018/11/07(水) 07:44:13.90

>>286
> 客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
「言った」の主語が>>280に読める、と>>281は言ってる

>>287
> ○ はやり通じてねぇｗ
日本語頑張れ

**デフォルトの名無しさん** · 2018/11/07(水) 09:25:05.22

>>291
概ね同意だ。

善し悪しはさておき、WHATWGにあるのなら、今現在も仕様としてブラウザ開発者側に認識されているだろう。
なら、既に実装されて十分動いていたコードが意図的に落とされることはない。となると、

1. そもそも257のコードに問題があって、それが何らかの理由で顕在化しただけ
2. 元々ブラウザにバグがあって、それが検出されずにずっと残っていただけ
3. ブラウザのコードの更新時に、レグレッションテストに引っかからずバグを挿入してしまっただけ

のどれかだが、可能性が一番高いのは 1. だね。
俺自身はブラウザなんてバグだらけで全く信用ならないプラットフォームだと認識しているから、
こなれてない書き方は出来るだけしないようにしている。
そこではまっても本当に時間の無駄でしかないから。
だからそんなコードはさっさと書き直せ、という立場だ。

ただ、ブラウザのバグだという立場なら、バグ報告をするにしてもコードを切り分けていかないといけないし、
仮に 1. なら、idで書き直しても動かないケースが発生するはずだから、
どのみちそのコードに関しては詳細検討が必要になってしまったね。まあ頑張れ。
ある意味、「仕様外」だったほうが楽だったのではないかな？
もっとも、バグ報告したとしても、直すのも開発者側の自由だから、このまま放置される可能性もあるが。

JavaScripterは全般的にそうだが、最近の初心者は、仕様の隅を使いたがる傾向がある。
仕様を隅々まで知って、それを『使い切る』事がいいことだ/上級テクニックだと勘違いしている。
そういうところでしか差別化出来ないから、そういう小手先テクニックに異常にこだわるわけだ。
ただ、それが仕様内でも、それを動かすのは人間が作ったソフトウェアであって、
そこにバグがある可能性があり、実際、ブラウザなんてバグだらけだ。
こなれてない書き方をするのなら、それなりの覚悟と能力が必要だって事だ。
勿論それをやるのも自由だけど。
(もっとも、257がこなれてないか、と言われれば、こなれているが古い書き方、かな？)

**デフォルトの名無しさん** · 2018/11/07(水) 11:04:13.33

最近の初心者が仕様の隅まで知りたがる？ｗ嘘つけｗｗｗ
仕様の隅まで知りたがるのはCおじさんとか古い人たちだろ。あの年代はCの仕様を勘違いしてたことがバレようものなら翌日から同僚に蔑まれてえんがちょされるような世代。
最近の特にWeb系のやつらなんか、必要になったらググって出てきたコードコピペする世代じゃんｗｗｗｗｗ

**257** · 2018/11/07(水) 11:27:49.74

いろいろありがとう。
>>267 で言ったアクセス解析のJS（これまた別のドメイン extdomain2 にある）を外したら動くようになった。
このJSはページロード初期に動いて終わりだと思ったら、タイマーで定期的に動き続けてるようだ。
ビーコン的に外と通信してるわけでもなさそうだから何やってるのかは分からないし、>>257 の smtFrom1 と smtForm1Callback の間でその JS の処理は割り込んでないようだけど、
少なくとも初期に DOM をいじってるようだからその影響なんだと思う。
それでも smtForm1 では document.form1 を参照できてるから、関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど、現状の詳細を伏せたままここで話を深められるほど単純なことでもなさそうだから、ちょっと引きこもります。
ありがとう。

**デフォルトの名無しさん** · 2018/11/07(水) 12:50:29.23

>>295
> 具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど
そのスタンスなら君は君なりに整合性が取れていると思うよ。まあ頑張れ。
言うなれば俺はそういうのから逃げてる。
俺は思うように動かしたいだけであって、
JavaScript自身や環境のデバッグをしたいわけではない、というスタンスだからだ。

> 関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
知っているような気がするが、仕様上は document は複数存在しえる。
ただし、通常はそのようにコードが作られておらず、結果、まともに動かないから妥協されてる。
以下から辿れる。
> Node.ownerDocument 問題の詳細については W3C DOM FAQ を参照してください。
>
> Firefox では現在このルールを強制していません。
> Firefox 3 の開発中には強制していた時期もありましたが、
> このルールを強制すると多くのサイトが機能しなくなってしまうため取りやめになりました。
> 将来的な互換性を高めるため、Web 開発者にはこのルールに従ってコードを修正することを推奨します。
https://developer.mozilla.org/ja/docs/Web/API/Document/importNode

なにか、2-3年前にJavaScriptのスレ（ここだったかWeb板だったかは不明）で
同じようなことを言っていた奴が居たような気もしたが…。(あまり自信ない)

一応複数 document については、実装はされてるっぽい。
例えば、ChromeのDevTools(F12の奴）のTimelineでJSHeapの使用量グラフを出せるが、
そこに document が何個かのグラフも出る。
ただし俺にはあの document の数が何に一致するのかいまいち分からないが。
（具体的に外部documentを取り込むときに増えるのは分かるが、よく分からん時に増えるときもある）

**デフォルトの名無しさん** · 2018/11/07(水) 12:52:09.02

仕様の隅とかカッコつけなくて良いから
ただ「俺はそんな仕様知らないし勉強する気もない」だけでしょ
自分の意見を表明するだけで良いところを
ひたすら他人を絡めようとする奴は程度が知れてる

**デフォルトの名無しさん** · 2018/11/07(水) 12:55:39.20

防衛機制の一種だろうな。
誰でも自分が無能と認めるわけにはいかないのさ。

**デフォルトの名無しさん** · 2018/11/07(水) 13:32:20.41

>>297-298
それが俺の自説を補強することにしかなってないことに気づけないのが、
お前らが馬鹿たる所以だよ。
マジでJavaScripterは馬鹿しかいない。これは断言出来る。
他言語と比べても相当酷い。

**デフォルトの名無しさん** · 2018/11/07(水) 15:22:39.79

＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
　　　　　　　　　　　Ｖ
　　　　　　　　　＿＿＿　　　　　　　　　　　　　　　　＿
　　　　　　　／　＿＿＿＿ヽ　　　　　　　　　／￣　　￣＼
　　　　　　　|　 | /, －､, -､ｌ　　　　　　　　 /､　　　　　　　　ヽ　きみ頭だいじょうぶ？
　　　　　　　| _|　-|○　|　○||　　　　　　　 |･ |―-､　　　　　　 |
　　 , ―-､　(6　＿ｰつ-´､}　　　　　　　ｑ -´　二ヽ　　　　　 |
　　 |　-⊂)　＼ヽ_ ￣￣ﾉﾉ　　　　　　　　ﾉ＿　ー　 |　　　　　|
　　 |￣￣|／（_ ∪￣ / ､　＼　　　　　　　＼.￣｀　 |　　　　/
　　ヽ　　｀　,.|　　　￣　　|　　|　　　　　　　　O＝＝＝＝＝ |
　　　｀－ ´ |　　　　　　　| ＿|　　　　　　　　/　　　　　　　　 |

**デフォルトの名無しさん** · 2018/11/07(水) 18:00:52.56

>>295
あと、実は、2.もあるかもね。
まともな奴（＝バグ報告出来るレベルの奴)はそんな設計しないから、
バグ報告すら上がってきてない可能性もある。

1a. id
1b. document.forms[name]
1c. document[name]

でどれも動くとしても、まともな奴ならaかbだ。
「非推奨」なんて言われなくとも、推奨はaに決まっている。
そして、

2a. ノードそのものを渡す
2b. 名前を渡して、document[name]でアクセスしてもらう

ここもおかしいだろ。普通はaだ。
(決め打ち出来る状況だからだろうが、普通はその手の場合は決め打ちは無理だし）

おかしなコードが何故動かないか調査するのに精を出すよりも、
おかしなコードを修正する方に精を出す方が有意義だと思うが、まあこれは個人の自由だ。
ただ、俺は「仕様内」でもブラウザで動くかは信用ならんと実感しているから、
俺ならさっさと修正して終わりにするが。
(ブラウザのバグだとか言いだしたら長くcloseしない案件になってしまう。
ブラウザのバグ取りが目的ではないし)

**デフォルトの名無しさん** · 2018/11/07(水) 19:49:33.17

正直、>>278以外に参考になるレスがない
>>279は気になってるんだが、本人から回答は貰えそうにないか…

**デフォルトの名無しさん** · 2018/11/07(水) 21:46:32.86

>>302
まずDocumentクラスの仕様を見るでしょ？
https://html.spec.whatwg.org/multipage/dom.html#the-document-object
// DOM tree accessors　の　getter object (DOMString name);　を見つけるでしょ
その説明を見て終わり

**デフォルトの名無しさん** · 2018/11/07(水) 22:16:45.82

VSCode の拡張機能、ESLint には、package manager のyarn の、インストールが必要。
yarnには、node.js のインストールが必要

yarnは、npm でインストールしなかった。
Windows10 に直接インストールした

yarnは、数MB のJavaScript で作られているのか。
Ruby のBundler, npm の影響を受けている

where node
C:\Program Files\nodejs\node.exe

where yarn
C:\Program Files (x86)\Yarn\bin\yarn
C:\Program Files (x86)\Yarn\bin\yarn.cmd
C:\Program Files (x86)\Yarn\bin\yarn.js

**デフォルトの名無しさん** · 2018/11/07(水) 22:29:07.63

「Ruby」でNG登録するのがお手軽・簡単です。

**デフォルトの名無しさん** · 2018/11/07(水) 23:00:35.11

>>294
コピペプログラマが無自覚で結果的に仕様の隅をつついたコードになっていることはあり得る。
彼等は書かないのだから、どういうコードが標準なのか当然知らないから。

ただ、本質的な問題はそこじゃない。
コピペプログラマがコピペしてきた元コードが糞だって事なんだよ。
コピペ自体が褒められるべき事ではないにしても、元コードがまともなら局所的にはまともなコードになる。
今回で言えば、誰かが最初に

document.name

の糞コードを書いた、ということなんだよ。
これがコピペであれば、どこかの馬鹿がドヤ顔で「こんな書き方も出来る(ｷﾘｯ」した結果、ということだ。

正直、JavaScript界隈はこれが多すぎる。
糞コードが糞コードを再生産してて、しかもみんなそれに気づいてない。

JavaScript界隈はバージョン管理を止めてしまった。
結果、猶予期間中にアップデートして新しい書き方に変更していかないといけない状況になってる。
旧来の、バージョン○○では動きます、みたいな管理方法が出来なくなっている。
だからそもそも257流の管理方法は不適だ。
古い書き方のままでどこまで動かせるか厳密に言える状況ではなく、適宜書き換えていくしかなくなってる。

だから、本来は古いwebサイトは閉鎖されるべきなんだよ。
今 document.name なんて書いているまともなサイトがあるとは思えないから、
おそらくはかなり古いサイトを参考にしたか、どこかの馬鹿がドヤ顔したかだが、
正直、前者もかなりある。

**デフォルトの名無しさん** · 2018/11/07(水) 23:16:45.49

ダラダラ長い。仕事できなさそう。

**デフォルトの名無しさん** · 2018/11/08(木) 06:09:34.45

質問です。
Parentを親に持つクラス Child には、自身のインスタンスを生成する関数があります。
（この書き方で良いのかは分かりませんが）

　//基本クラス
　class Parent{
　}

　//派生クラス
　class Child extends Parent{
　　//自身のインスタンスを生成する
　　static CreateInstance(){ return new Child(); }
　}

このとき、CreateInstance関数を
Parent側で用意するにはどう書くのが良いでしょうか。

**デフォルトの名無しさん** · 2018/11/08(木) 06:35:07.12

new this()

**デフォルトの名無しさん** · 2018/11/08(木) 07:23:26.56

グローバルスコープの変数は、id だけの方がよい

**デフォルトの名無しさん** · 2018/11/08(木) 08:28:22.04

>>309
ありがとうございます
こういう場合でもthisは使えるんですね

**デフォルトの名無しさん** · 2018/11/08(木) 12:26:51.19

まずWebの仕様とJSを一括にするのは違和感あるけど、まあそれはいいとして
今はWHATWGなどに立派な仕様があるんだからさ

それが元々どこかのブラウザの独自実装だろうが、デファクトだろうが、
ブラウザのお偉いさんが話し合って決めたことだろうが、
メーリングリストで決まったことだろうが、
なにがどうだって仕様は仕様なんだからさ、それを素直に参照すればいいじゃん

まあ色々言いたいことあるけど長くなるから取り敢えず１つだけにすると
Webって言うのは皆の合意、というより総意で決まって来たものだからさ
中央集権的な所が丸ごと決めきってから出す物と比べたら、
そりゃ良いところもあるし、同じだけ悪いところもある

でもその悪いとこだけを引き合いに出すのはおかしいと思うね
それはWebがWebの道を選んだ時点でどうしても付いてくる「特徴」だもの
それを改めようと思ったらWebがWebじゃ無くなっちゃう
WebはWebらしくて、他は他らしい、で良いじゃん

別にWebの特徴が嫌いなら他所へ行けばいいじゃん?
それをせずにそんな批判ばかりしたって、俺からすると、
「WebやWebの人間はこんな悪いとこがあるのに注目されて盛り上がっちゃって俺まで付き合わされておかしいだろ!」っていう妬みにしか聞こえないよ
でもたまたまラッキーでWebが発展できたわけじゃないからね
Webやコミュニティがこの形だったからこのよう発展できたわけ
それは事実として認めないとね

**デフォルトの名無しさん** · 2018/11/08(木) 14:39:53.97

> まあ色々言いたいことあるけど長くなるから取り敢えず１つだけにすると

うんとっても短いね棒

**デフォルトの名無しさん** · 2018/11/08(木) 17:24:06.77

>>312
コピペか？ポエムか？

意味不明すぎ。
流れ上俺への批判だろうが、該当する箇所がどこだかさっぱり分からない。
お前も「JavaScripterは馬鹿しかいない」という俺の自説を補強したいのか？
他言語スレでは馬鹿が噛みついて来るにしても、少なくともどこに噛みつかれたかは分かるぜ。
お前らではまともに会話が成立しないではないか。

**デフォルトの名無しさん** · 2018/11/08(木) 19:25:14.84

下記のjsonをJavaScriptの多元連想配列に格納する方法を教えてください。

{
　"name1": {
　　"key1": "value1",
　　"key2": "value2"
　}
}

$.getJSON(url) で取得はできますが、
どのようなアクセスでvalue1等に辿れますでしょうか？

json['name1']['key1'] == 'value1' を期待していますが違うようです。

**デフォルトの名無しさん** · 2018/11/08(木) 20:03:52.85

>>315
$.getJSON( url, function( json ) {
console.log( json['name1']['key1'] );
});

俺ならawait fetch使うがjQueryがいいってんだからしょうがないね

**デフォルトの名無しさん** · 2018/11/08(木) 20:07:48.28

ありがとうございました。死ね。

**デフォルトの名無しさん** · 2018/11/08(木) 20:14:54.95

お前が死ね

**デフォルトの名無しさん** · 2018/11/08(木) 20:21:16.21

人間のクズw

**デフォルトの名無しさん** · 2018/11/08(木) 20:34:29.34

ここはひどいインターネットですね

**デフォルトの名無しさん** · 2018/11/08(木) 21:03:58.59

>>314
それ以上知能指数が低いアピール続けてると誰からも取り合ってもらえなくなるぞ

あ、もう手遅れかｗ

**デフォルトの名無しさん** · 2018/11/08(木) 22:52:35.10

今どきjQueryでって頭が湧いてるとしか思えんな

**デフォルトの名無しさん** · 2018/11/08(木) 23:00:42.87

荒らしと会話するな。質問に答えるな。
荒らしと会話するものも、荒らしと同じ

このスレで質問しないように！
JavaScript, jQuery のスレは、web制作管理板にあるので、そこへ書き込め

この板には、荒らしが多いから、書き込まないように！

他の質問スレにも、よくいる。
質問に答えると、お前に聞いていないとか、馬鹿とか、荒らしてくる奴が多い

**デフォルトの名無しさん** · 2018/11/08(木) 23:09:47.02

しかしこれは一方的に>>315が悪いだろ。
>>316で死ねと言われる理由もないし、そりゃ死ねと返すだろ。

まあこのレベルの質問はWeb板で、というのは同意だが。

**デフォルトの名無しさん** · 2018/11/08(木) 23:36:30.84

ほんと、jQueryの話題がでると、頭フットーするやつがいるなぁｗ

>>322
> 今どきjQueryでって頭が湧いてるとしか思えんな

https://w3techs.com/technologies/overview/javascript_library/all

w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月～2018年10月の約半年間で変化が見られず、ようやく73.3%～73.4%で
増加が停止したようである。

しかしながら、減少の傾向は見られず、マーケットシェア（JavaScriptを使用しているサイトでの使用率）
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる

jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。

またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。

この状況が大きく変化するときは来るのだろうか？この先の動向が注目される

**デフォルトの名無しさん** · 2018/11/08(木) 23:51:10.14

近年jQueryは余計な機能減らしてきててDOM操作ライブラリへの回帰を目指している。
jQuery.slimには$.ajaxや$.getJSONは入っていない。

**デフォルトの名無しさん** · 2018/11/08(木) 23:54:50.59

>>325
> jQueryの話題がでると、頭フットーするやつがいるなぁｗ
お前もな。

好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
急速に衰退するかは微妙だが、引き金になるとしたらWebAssemblyが成功したら、かな？
そう簡単に行くとも思えんが、あれはゲームチェンジャーになり得る。

**デフォルトの名無しさん** · 2018/11/09(金) 01:16:54.01

>>327
> 好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
> それを自覚しているからこそ、お前もいちいち布教してるわけだろ。

逆逆ｗ先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どう考えても終わりません。不安を煽って間違ってる方向へ変えようと、
明らかにずれてる方向が正しいんだと、布教してるやつがいるから事実を伝えてるだけ

jQueryの代替なんてまだ登場してないんだよ。React？Angular？ WebAssembly？
それらはjQueryの代替ではなく大規模なウェブアプリを作るためのもの。
ウェブサイトに適してるのは昔も今もjQueryだ。

jQueryが終わるとしたらWeb componentsが完成して、
使えるコンポーネントが "出揃った時" だろう

つまりウェブサイトを作ってる連中が「JavaScriptなんて全く使わねぇ。
誰かが作ったコンポーネントを使ったHTMLを書くだけで終わり」と
言い出すまでってことだ

そうなれば本来あるべき完全分業の世界に行くことができる。
HTMLのパーツを作るのはプログラマ。それを使うのはウェブデザイナー。
今はウェブデザイナーが書いたHTMLにJavaScript（jQuery）で動きをつけるという形で分業している。
jQueryを使うのはJavaScriptよりも圧倒的に楽だから。セレクタを使うからウェブデザインとの相性も良い。

React、Angular、WebAssembly などはウェブデザイナーの仕事であるデザインの作成を
プログラマの領域に吸収するやり方なので、世界の大半を占めるウェブサイトには全く適していない

**デフォルトの名無しさん** · 2018/11/09(金) 01:18:44.17

世界の大半を占めるウェブサイトは
「まず最初にHTML+CSSを書く」ということを
しっかりと認識するようにな

まず最初にビルド環境を整えましょうじゃないんだよｗ

**デフォルトの名無しさん** · 2018/11/09(金) 01:31:54.32

IE11のことを考えないコードを指摘するのは人間のクズ
JQの時点でお察ししろクソ野郎
ちなみに、あたしはクソ女だからな！
女の言う事は従えよ？

**デフォルトの名無しさん** · 2018/11/09(金) 03:02:19.99

>>328
> 逆逆ｗ先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どっちが先とかはどうでもよくて、お前も必死過ぎなのは事実だよ。
どうしても、jQueryは不滅です、ってことにしたいんだろ。それもまた、不安だからだよ。

> 今はウェブデザイナーが書いたHTMLにJavaScript（jQuery）で動きをつけるという形で分業している。
> ウェブデザイナーの仕事であるデザインの作成を
> プログラマの領域に吸収するやり方なので
この、君の現状認識については同意出来る。

> 「まず最初にHTML+CSSを書く」ということを
これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。

CSSの恩恵を正しく受ける為にはクラス設計が必要となる。
そしてそれは工程が逆転する、つまりプログラマが上流、デザイナが下流になるから、
Webデザイナが牛耳っている職場ではかなり無理がある。変化するにしても時間はかかるだろう。
それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
どっちに賭けるかも含めて、個人の自由だ。

> jQueryの代替なんてまだ登場してないんだよ。
jQueryの売りはCSSセレクタで、それは標準に入ってしまった。
大体それ以前に、まともにクラス設計されてたら getElementsByClassName だけで済んでしまって、
querySelectorすら必要ない。（アプリならqueryすらしないし）
その他諸々jQueryが色々便利に出来ていることは認めるが、
最早、無ければ無いでいいや、程度でしか無いと思うが？
まあこれについては水掛け論だからもういいが、
少なくとも、俺と同じ「もう要らないんじゃね？」と思う奴が一定数居るからこそ「不要論」が出るわけで、
そこは君も認めないと駄目だと思うぜ。

**デフォルトの名無しさん** · 2018/11/09(金) 03:02:58.94

jQueryはHTMLベースになる点が本質的に筋が悪いんだよ。(逆に、それが取っつきやすい点でもあるが)
だから頻繁にリニューアルするサイトならCSSベースの方が効率がいい。
文書を流し込んで出来上がり、だからだ。
（そしてその場合は、CSSクラスをがっちり組んでしまう為、jQueryの恩恵がない）
その点、おそらくWordPress等もそこを目指しているはずだが、
いまいちjQueryが死にきってないところをみると、
WordPressではJavaScriptをある程度書かないと駄目なのかな？
まあそれはさておき、
> 世界の大半を占めるウェブサイト
はつまりほぼ静的なサイトであり、お約束的動きしか必要ないのだから、（ハンバーガーメニューとか）
最終的には静的ページ用のフレームワークで全て終了するようになるはずだが。
Hugoとか、どこまで出来るのか知らんが、出てきてるだろ。
他サイトでやってない動きが必要なら自前で書くしかないけど、ほぼ静的サイトでそれは不要だろ。
デザイナがJavaScriptを書かなければならないのは、環境が整備されてないからだよ。

そしてプログラマにとってはjQueryはもうどっちでもいい存在になってる。
或いはここは君も同意してくれるのかな？

> jQueryが終わるとしたらWeb componentsが完成して、
> 使えるコンポーネントが "出揃った時" だろう
確認してみたが、この意見にも同意出来る。
ただ、若干大がかりすぎるとは思うが。俺は静的HP用フレームワークでいいと思うぜ。
shadowDOMなんてここで持ち出す必要なんて無いと思うのだが。
あと、デザイナはどうしても独自の動きを付けたいのかね？
だとすると、永久に「出揃う」事はないが。

とまあ、つらつら書いてみたが、俺と君の認識は似ている、というかほぼ同じだろう。
WebAssemblyについては、俺は「プログラマがjQuery禁止にされる理由」になり得ると見ている。
今現在jQueryを使って悪い点は、第一に速度面だろ。だから。

**デフォルトの名無しさん** · 2018/11/09(金) 03:17:04.51

馬鹿って変なところにこだわって前へ進めないままなんだよなあ
そういうの捨てれば楽になるのに

**デフォルトの名無しさん** · 2018/11/09(金) 06:28:59.39

jQueryの遅さは機能性から来るそのDOMAPI利用の冗長さにあって
WebAssemblyでDOMAPIを叩ける用になっても同じことをすれば速度は変わらないだろ
こいつホント中身スッカスカの思考しかできない、文字通りのカス

**デフォルトの名無しさん** · 2018/11/09(金) 07:09:53.79

ブラウザもPCもどんどこ高性能になってるよ。
そんなに言うほど遅くない。
慣れている物で素早く開発し、ちゃんと制御することも大事じゃん。

**デフォルトの名無しさん** · 2018/11/09(金) 07:39:35.28

>>331
> > 「まず最初にHTML+CSSを書く」ということを
> これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
中途半端に引用するな

ほんとな。わざと１行で書いて、都合よく引用させないように
徹底しないといけないよな

> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」ということを
ってかいただろ

プログラマ的に間違ってるとか、大半を占めるウェブサイトになんの関係があるんですか？
上で、ゲームチェンジャーになりうるとか言ったが、なんのゲームを変えるのかを
明確に言ったらどうだ？それは「プログラマ的なゲーム」だろう
チェンジするのはウェブサイトの世界じゃない。デスクトップやスマホアプリ・ゲームの世界だ
デスクトップやスマホと言ったウェブでない世界を壊してウェブに来るだけの話
その場合になくなるのはjQueryじゃなくて.NET FrameworkやUnityだよ