+ JavaScript の質問用スレッド vol.135 +
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
次スレは>>950が(本スレで改善案があれば考慮して)立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」だけでなく「意見」を出しても良い。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。
【条件】期待する回答の条件を書いてください。
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/
■回答者へ
・回答には多様性があります。他人の回答を尊重してください
・動作ブラウザや環境が限られる場合は、それを明記してください
・他人の回答を批判する代わりに、自分ならこう書くという例を示してください
・質問者がJavaScriptでなければ実現できないと勘違いしてるなら、その否定としてHTMLとCSSで実装しても良い
・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける=荒らしです javascriptもclassを実装したの?
煩雑なprototypeは改めて欲しい。 プロトタイプはクラスと比較してもしなくてもこれ以上無いくらい簡単な仕組みで
複雑なのはnew演算子だって何回言ったら分かるんだろうね >>278
実装が簡単なのと使い方が簡単なのをごっちゃにしてるぞ
例えば、gotoはコレ以上無いくらいに簡単な仕組みだ、
そのgoto一つで分岐処理、ループ処理、例外処理、
処理の流れを変えることはなんでもできる
だけど、使うのは難しい
原子的な機能であればあるほど、実装は簡単で
いろんな応用ができる。だけどそのせいで間違った
使いかたもできるから、使いこなすのは難しんだよ 小学生の時にBASICやってたなあ
そんでGOTOやGOSUBのなにがいかんのかイマイチわからん 問題が出るのはたとえばこういう場合
・後でコードを見たときに
・意図や目的のコメント文がぜんぜんなくて
・大きく飛んだり戻ったりで全容を掴むのが至難の業で
・書いた本人も気づいてないgoto由来のバグが潜んでる
よって、次のことが言える
自分がメンテするのでなければ何も問題がない お腹に刺さると死ぬから包丁は使うべきじゃない
的な gotoって確か行数かマーカー依存だったよな
行数の場合、ソース変更したら処理が変わるし、マーカーだと処理を追いにくいからあまり推奨されてない
大規模開発だと(他人にソースコードを読ませる関係上)問題になるが個人での開発ならそれほど問題にならない goto乱用よりも
仕様ひっくり返すユーザ、設計をひっくり返す上流SE、みたいな 要件を正しく伝えない蔵担当者
勝手に要件を追加する蔵担当者の上司
最終段階で「これ本当に必要なの〜?」とぶちかます蔵の社長、とか 質問です 自分は障害持ちで将来的に在宅で
仕事したいと思っとります 在宅でのweb系の仕事を考えるなら、javascriptとphpどちらを先に勉強すべきでしょうか?すぐに仕事に繋がりやすいのはどちらでしょうか?
大金稼ぎたいとかじゃなく、少し稼げれば良いです 宜しくお願いします
長文失礼しました まずwebのことなんて一旦忘れて
c書けるようになってサーバ操作に慣れろ >>291
考え方が逆
何ができれば良いか、ではなく何が出来なくても許されるか、だね
んで在宅≒フリーランスだとあまりないかもなあ、出来なくてもいいこと
デザインくらいかなあ 最近この手のクラワのステマじみた何かをよく見かけるな >>291
WebAssemblyもあるから何とも言えんな
C++とjavascript学んでおけばいいんじゃね ウェブサイトにアニメーションを実装するとなると
Canvas使うよりよりSVGやCSSアニメーションのほうが優勢ですか
例えばページ背景に複数の円が色を変えながら動き続けるとかです >>295
c +は難しそうですね phpがオススメとも聞きましたが、逆の意見も耳にします >>296
WEB+DB vol.106 に、次世代のアニメ規格、Web Animations API の記事が載っている
これのPolyfill として、web-animations-js が公開されている 言うほど枯れてるだろうか?
そんなに使われまくってる? 原則CSSのanimation/keyframesと一緒でしょ
枯れてると言って良いと思う > 原則CSSのanimation/keyframesと一緒でしょ
> 枯れてると言って良いと思う
だめだろ。できることが一緒でも、
それを実現している技術は最近だろ?
これはCSSではない新しい技術なのだから枯れてない
長い期間実際に使われてないなら枯れてるとは言えない 実際に多くの人に使われてるかどうかは関係ない
同時期の技術で言うとWebRTCのように使うべき人が使ってきて
議論が出尽くして仕様が固まって可能性も粗方掴めた段階で枯れてると言える
もう先人が試しきってるんだからね 次世代とかウン十年前のゲーム機の宣伝文句じゃないんだから >>304
まだドラフトかよw
枯れてるとか嘘じゃん >>309
あなたは、ドラフト(草案)がもうこれから
変わらない仕様だと断定したいんですかね?w
https://www.nttpc.co.jp/yougo/%E6%9E%AF%E3%82%8C%E3%81%9F.html
> しかし単に古いだけでなく「すでにトラブルが出尽くしていて、
>そのトラブルも解決され尽くしている」といった意味が強い。
ブラウザで実装してこの仕様でなにかトラブルがないですかー?って
調べてるのが今の段階で、トラブルはまだ出尽くしていない
枯れるわけがないだろ。常識で考えろや これらの書き込みで1600円の雑誌が何冊余計に売れるのかね 枯れてない=トラブルが多く仕様が不安定
とすると
枯れてない=使い物にならない可能性が高い、細かいトラブル対応はネット漁るしかない=本見る意味なし
枯れてる=トラブルが出尽くし解決され尽くすほど普及してる=mdnで十分、本見る意味なし >>310
意味分からん
ブラウザはまだAPIの一部しか全然実装してないし個々何年もする気もないだろ
ずっと見てきたわけもでないのにしったげに言うな
むしろ使う人が居なくて仕様の中核以外の部分は廃止されてもおかしくないような状態だから
もう枯れ切ってるんだよ
崩れる前に使い始めようっていうのに近い >>314
意味がわからんのは、お前が「"仕様"が枯れた」なんて
意味不明なことを言ってるからだよ
いいか? 俺らは使う側。APIを使う。使うにはブラウザに実装されていなきゃいけない。
いくら仕様がずーっと前から変わらなかったとしても、それがブラウザに実装されてない以上
使えないし、Polyfillがあろうがブラウザに実装されようが、それなりの期間使われてないと
バグがあるかもしれない。だからいくら仕様が安定してようが「"実装"は枯れてない」んだよ
それとも何か?「枯れてるけど使えません。」とか言うつもりか? 枯れたっつーのは、なんつうか、こう
世界中のいろんな現場で使い倒されてる感がないとね Web技術は枯れてからようやく使われるようになる
色んなメディアやブログが取り上げ始めたらその合図 >>315
俺らは使う側?は?何言ってんだお前。
Webって言うのは皆で作っていくもんだろ
その大原則を忘れるとかアホかお前
ほんとアホなこと言ってる暇あったらMLに参加するなり、実装にパッチ投げたりしろよドアホ
皆が苦労して決まりきってから腰を上げるお前みたいなのに仕様が云々語る権利は一切無い Webの世界(要するにウェブサイト)は皆で作るが
仕様は皆で作らない >>315
> だからいくら仕様が安定してようが「"実装"は枯れてない」んだよ
いつの間にか、「実装が枯れてない」にすり替わってる っていうか実装が枯れてないというのがどうも
枯れてるものを移植したら枯れてない新世代ぎじゅつに様変わりするのか?んなわけないだろ 不毛でも感覚をぶつけ合って少しでもすり合わせておくことは大事
皆がバラバラな方向いてたらWebは崩壊する 下のコードでaddEventListenerが実行されないのが良く分かりません。
window.onload = function () {
window.addEventListener('load', function () {
・・・ // 実行されなかった
});
};
なぜですか?
なお
window.onload = function () {
ではなく、
jQuery(function ($) {
でも実行されませんでした。そう言う仕様ですか? >>330
ロードイベントが起こった後にロードイベントを監視しても、もう起こった後だから起こらない。 >>330
そりゃ二重にロードイベントに紐付けしたら起動するわけが無い
どっちかだけにしろ Life is a series of choices.(人生とは選択の連続である)- William Shakespeare(ウィリアム・シェイクスピア) >>330
おかしいな? jQueryの場合は動くはずだけど?
jQueryのloadはPromise的な処理になっていて
あとからつけても発動するように考慮されてある
jQueryの古いバージョンは違ったかな?って思って1.9.1にしたけど動く
それよりも古いバージョンはしらないけど
https://jsfiddle.net/6q4whbty/ あ、逆か。
外側をjQueryにして、中をDOM APIにするわけね。
そりゃDOM APIじゃむりだ。中もjQueryにしなきゃ
ってか、外側でjQuery使っていてjQueryでやれることを
DOM APIを使ってやる必要ないでしょw 必要かどうかは私が決めることです
分からないのなら解答しなくていいので黙っててください >jQueryのloadはPromise的な処理になっていて
>あとからつけても発動する
どういう経緯でこうなってるんですか
pure-js側はそんなことないですよね
デバッグの妨げになるようにも思えるんですけど どういう経緯って言われても、何度も発生するイベントと
resolve(またはreject)状態になってから変わらないものは
そもそも性質が異なるからですよ。
Promiseもいまやpure-jsですが、昔はそんなものがなかったからイベントで代用していましたが、
他のイベントと違い発生したタイミングが重要なのではなくロードは発生したタイミングが知りたいというより、
「現在ロードされているか?されていなければされるまで待つ」という処理を行うのが普通なので
現在の状態を判断するという処理が必要になります。
結構複雑ですよ?まずjQueryのloadはブラウザのloadイベントではなく
それよりも早い段階で発生する、DOM構築が完了した直後の
DOMContentLoadedを捉えるものだというのは知っていますか?
DOMContentLoadedはHTML5で標準化されましたが、それまでは非標準で
https://qiita.com/mamosan/items/ff336b5cc0a1a95e03a7
Firefox 2 (2006年)、Safari 3.1(2008年)、Chrome 4(2010年)、IE 9(2011年)で
予約サポートされたものです。jQueryは2006年なので普及しておらず当時は
使えない人が大半だったってのがわかりますね?
jQueryのloadはこのDOMContentLoadedをシミュレートする形で実装されました。
詳細は省きますがドキュメントのとあるプロパティをsetTimeoutで監視して読み取れれば
イベント発生扱いとしています。この部分のコードだけでも面倒なのですが、今は
DOMContentLoadedが使えるし、シミュレートが完璧に動作すると信じて
DOMContentLoadedの話にすすみましょう。
DOMContentLoadedが発生するのはDOM構築が完了した直後です。ここで問題になるのは
パフォーマンスアップのために使われる非同期で実行されるJavaScriptの存在です。
同期的に実行されるJavaScriptはDOM構築完了前に実行されますが、非同期で実行される場合
DOM構築完了後に実行されます。つまりDOMContentLoadedが発生した後に
DOMContentLoadedを監視することになるわけです。つまりイベントはすでに発生しているので
捉えることはできません。>>330と似たような状況になりますね。 ではどうするのかというと、イベントを監視する前にすでにDOMContentLoadedが発生したかを
document.readyStateを使ってチェックするわけです。
ですが単純には行かず、document.readyStateを使ってチェックしてまだloading中であれば、
addEventListenerでDOMContentLoadedを監視すると書いてしまうと、チェックした段階では
loadingだったが、addEventListenerするまでに間にDOMContentLoadedが発生してしまって
イベントが捉えられない可能性があります。
なので逆に実装し、addEventListenerでDOMContentLoadedを捉えるようにしてから、
document.readyStateを監視して、すでにreadyStatusがinteractiveにだったら
ずっと前にDOMContentLoadedが発生していたと判断するわけですが、
実はaddEventListenerを設定した直後にDOMContentLoadedが発生した可能性があるため
この場合は2回イベントが発生する可能性があります。それを避けるために状態管理で
1回しか発動しないようにするわけです。
これらの動きはDOM読み込みとJavaScriptの実行タイミングによるものなので
毎回発生するものではなく、まちまちで見つけづらいバグとなってしまいます。
ローカルでは問題ないのにサーバーにアップした発生する。
でも2回目以降はキャッシュが効いて速いので発生しないとかですね。
このように完璧に対応するのは複雑なのです。DOMの非同期読み込みをやめれば
解決するのですがパフォーマンスアップのためにブラウザに搭載された機能を
使うなというのは、ライブラリとしてありえませんね。
他のイベントでは必要ないのにloadに関してこれらが必要になるのは
DOM構築が完了したあとに何度も発生するイベントと、そもそもDOM構築完了を監視する
DOMContentLoadでは性質が異なるからなのです。
そして実際のユースケースを考えたら「ロード済みかロード完了時にイベント発生」して
欲しいため、APIもそのようになっているのが望ましいわけです。
開発者が上で書いたようなな複雑な処理を書くことなく、単純なAPIで判断できるため
それが原因で起きるマイナーなバグから逃れることができます。 >パフォーマンスアップのために使われる非同期で実行されるJavaScriptの存在です。
>同期的に実行されるJavaScriptはDOM構築完了前に実行されますが、非同期で実行される場合
>DOM構築完了後に実行されます。つまりDOMContentLoadedが発生した後に
>DOMContentLoadedを監視することになるわけです。つまりイベントはすでに発生しているので
>捉えることはできません。
これどゆこと
ブラウザにおけるjavascriptの実行ってのは
今も昔も非同期な関数(呼び出し)があるだけで、原則は全部同期実行なんじゃないのけ
setTimeoutやXHRのcallbackの中でwindow.addEventListener('load', ... )なんてしないし 「なんでonloadではなくDOMContentLoadedなのか」は?
つか化石IE対応のための負の遺産的挙動じゃないん >>344
scriptタグのasync属性のことだよ。
HTMLの読み込みとJavaScriptの実行が非同期で行われる。
つまりaddEventListenerでDOMContentLoadedを監視する前に
HTMLの読み込みが完了してしまうことがある
参考 https://iwb.jp/domcontentloaded-javascript-async-forbidden/ >>345
IEは9の時代からDOMContentLoadedに対応してる。
対応してないブラウザのためというのなら、別にIEだけじゃなくて
その他のブラウザも非標準のDOMContentLoadedには対応していなかった
DOMContentLoadedが標準化されたのはHTML5になってからだ。 それはわざと。レスする気なくするでしょ?それが狙い
不正にjQueryを貶めようとする奴らに反論する気をなさせる asyncは「DOM構築完了後に実行」される、ではなく
「DOM構築完了後に終了する場合がある」というべきでは
つかasyncしてもwindow.onload使えばいい話じゃないのか この件は良く知らんのだけど
・>>337いわく1.9.1の時点からそういう挙動
・scriptのasyncはHTML5から
・jq 1.9.1リリース 2013年02月04日
・HTML5勧告 2014年10月28日
順番おかしくね >>351
jQのpromise的動作とjsタグのasync的動作はまったく別物 >>352
>>346
JQueryの良く分からん挙動がscriptのasyncと関係ないということになると
>>342-343の大長編レスの前提が崩れるんじゃないか? >>351
> ・>>337いわく1.9.1の時点からそういう挙動
どこにも1.9.1の時点からなんて書いてない。
少なくとも1.9.1ではそういう挙動だったってだけ。
おそらく最初からそうだろう >>352
何を持って別物と言ってるのかは知らないが、
PromiseオブジェクトにはPromise.resolve()とPromise.reject()という
メソッドがあって、それぞれ解決済み、リジェクト済みのオブジェクトを返す。
このオブジェクトにあとからthenメソッドでコールバック関数を
くっつけてもちゃんとコールバックが呼ばれるんだよ。 > jQのpromise的動作とjsタグのasync的動作はまったく別物
jsタグってなに?HTMLタグっていいたいの?
HTMLタグのasyncはJavaScriptの実行を遅らせることで
見た目上のパフォーマンスを上げる技術で
その弊害として、DOMContentLoadedが先に呼ばれてしまうから
JavaScriptの発動が起きないってものなんだけど
jQueryはそのことも考慮されてるから、普通に書くだけで
非同期でJavaScriptが読み込まれても大丈夫って話をしてるんだよ
Promise的動作っていうのは、コールバックを後から追加しても
発動するって話。あんた全く別物の話をしてるよ >asyncはJavaScriptの実行を遅らせることで
遅らせてるのか?
htmlの解析処理と当該jsファイルのダウンロード・実行処理とを
切り離して並行処理させることで、htmlのパース・文章や画像の配置等が妨げられないようにしているだけでは?
DOMContentLoadedより後に処理が開始されるのではなく
DOMContentLoadedの前に終わるとは限らないというだけの話では? > DOMContentLoadedより後に処理が開始されるのではなく
> DOMContentLoadedの前に終わるとは限らないというだけの話では?
今はそういう細かい話はどうでも良くて、
需要なのはscriptタグのasyncを使われてると、DOMContentLoadedが
先に発生してしまうことがあるってことですよ
他にもRequireJSのような非同期でJavaScriptモジュールを読み込む仕組みを
使ったときにも発生しましたね。 たとえ細かい話でも虚偽が含まれてる人の話は信用できないからなあ はは、信用出来ないっていうだけで、間違ってるとは言えない
あわれよのうw まあ間違ってるわけじゃないからね。信用出来ないってだけ ■ このスレッドは過去ログ倉庫に格納されています