言うほど枯れてるだろうか？
そんなに使われまくってる？

原則CSSのanimation/keyframesと一緒でしょ
枯れてると言って良いと思う

> 原則CSSのanimation/keyframesと一緒でしょ
> 枯れてると言って良いと思う

だめだろ。できることが一緒でも、
それを実現している技術は最近だろ？
これはCSSではない新しい技術なのだから枯れてない

長い期間実際に使われてないなら枯れてるとは言えない

>>303
> それを実現している技術は最近だろ？
2016/09/13
http://www.w3.org/TR/web-animations-1/

実際に多くの人に使われてるかどうかは関係ない
同時期の技術で言うとWebRTCのように使うべき人が使ってきて
議論が出尽くして仕様が固まって可能性も粗方掴めた段階で枯れてると言える
もう先人が試しきってるんだからね

次世代とかウン十年前のゲーム機の宣伝文句じゃないんだから

ps5まだかな

>>304
まだドラフトかよｗ
枯れてるとか嘘じゃん

ドラフトだったら枯れてない
初めて聞いたな

>>309
あなたは、ドラフト（草案）がもうこれから
変わらない仕様だと断定したいんですかね？ｗ

http://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にしたけど動く
それよりも古いバージョンはしらないけど
http://jsfiddle.net/6q4whbty/

あ、逆か。
外側をjQueryにして、中をDOM APIにするわけね。
そりゃDOM APIじゃむりだ。中もjQueryにしなきゃ

ってか、外側でjQuery使っていてjQueryでやれることを
DOM APIを使ってやる必要ないでしょｗ

必要かどうかは私が決めることです
分からないのなら解答しなくていいので黙っててください

>jQueryのloadはPromise的な処理になっていて
>あとからつけても発動する

どういう経緯でこうなってるんですか
pure-js側はそんなことないですよね
デバッグの妨げになるようにも思えるんですけど

どういう経緯って言われても、何度も発生するイベントと
resolve（またはreject）状態になってから変わらないものは
そもそも性質が異なるからですよ。

Promiseもいまやpure-jsですが、昔はそんなものがなかったからイベントで代用していましたが、
他のイベントと違い発生したタイミングが重要なのではなくロードは発生したタイミングが知りたいというより、
「現在ロードされているか？されていなければされるまで待つ」という処理を行うのが普通なので
現在の状態を判断するという処理が必要になります。


結構複雑ですよ？まずjQueryのloadはブラウザのloadイベントではなく
それよりも早い段階で発生する、DOM構築が完了した直後の
DOMContentLoadedを捉えるものだというのは知っていますか？

DOMContentLoadedはHTML5で標準化されましたが、それまでは非標準で
http://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の読み込みが完了してしまうことがある

参考http://iwb.jp/domcontentloaded-javascript-async-forbidden/

>>345
IEは9の時代からDOMContentLoadedに対応してる。
対応してないブラウザのためというのなら、別にIEだけじゃなくて
その他のブラウザも非標準のDOMContentLoadedには対応していなかった
DOMContentLoadedが標準化されたのはHTML5になってからだ。

非常に興味深い話だが話が長い

それはわざと。レスする気なくするでしょ？それが狙い
不正にjQueryを貶めようとする奴らに反論する気をなさせる

asyncは「DOM構築完了後に実行」される、ではなく
「DOM構築完了後に終了する場合がある」というべきでは

つかasyncしてもwindow.onload使えばいい話じゃないのか