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

**Name_Not_Found** · 2015/01/24(土) 16:23:05.20

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。

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

+ JavaScript の質問用スレッド vol.122 +(c)2ch.net
http://peace.2ch.net/test/read.cgi/hp/1420095379/

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

**556** · 2015/04/06(月) 09:24:46.78

すいません。バタバタしててスレを覗きに来れませんでした。

>>569
ありがとうございます！
ただ、>>573でご指摘あるとおり、「元々の場所（並び順も同じ）に戻したい」が理想でした。
最初の質問に記入し忘れていて申し訳ありませんでした。

>>567
ありがとうございます。
戻す際にループを行ってソートする方法も考えてはいたのですが、
実環境で使用するコンボボックスが200件近く表示される可能性もあり、
もしかしたら少し時間がかかってしまうのではないか、と思った次第です。

**Name_Not_Found** · 2015/04/06(月) 11:19:05.97

>>587
嘘は良くないよ。
https://html.spec.whatwg.org/multipage/forms.html#the-multiple-attribute
>>The multiple attribute is a boolean attribute
だからmultiple="true"は正しい。
multiple="false"は間違い。

**556** · 2015/04/06(月) 12:01:02.45

皆様、ありがとうございました。
頂いた回答と、optgroup内のソート処理を組み合わせることで、
意図した動作をIE/Firefox/Chromeのそれぞれで確認することが出来ました。

http://jsfiddle.net/fw1e85vy/1/

HTML規約的に妙な部分ことになっているかもしれないですが、
data-sort -> id にしても問題なさそうですかね・・・

**Name_Not_Found** · 2015/04/06(月) 12:27:44.74

そこまでやるなら要素の外にごちゃごちゃくっつけるんじゃなくて
丸っとカスタムエレメントにすべきだよ。

**Name_Not_Found** · 2015/04/06(月) 13:08:08.95

>>594
煽った上に嘘を言うとはとことん使えない野郎だな
https://html.spec.whatwg.org/multipage/infrastructure.html#boolean-attribute
> The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

英語が読めないならせめてvalidatorでも使って調べてから書け

**Name_Not_Found** · 2015/04/06(月) 14:15:43.98

どこが嘘かね？
俺はHTML5がわざわざ正しいことにしてくれたから正しいと言っている。

**Name_Not_Found** · 2015/04/06(月) 14:19:57.83

HTML5 とは >>594 みたいなバカに合わせて、酷かった現状に溜息まじりでアリバイを作ってくれたクソな仕様だよ。

**Name_Not_Found** · 2015/04/06(月) 14:21:08.47

自分で自分をバカと言ったw
バカは >>597 だな。

**Name_Not_Found** · 2015/04/06(月) 14:28:41.05

短く言い直してやるよ。
multiple="true" は現行HTMLで正しいことにしてくれたから正しい。
しかし、過去においてその間違いを犯していた大量のアホがいたから、ふつうは格好悪くて書けない。

(だからHTML5仕様の例示にも属性名省略で書いてある。)
(そして、そもそも、仕様を読めなかった大多数の低脳は省略が名であることを知らないから、過去において大量に間違えていた。)

**597** · 2015/04/06(月) 14:33:55.93

>>599は別人だから責めんといてくれ

まず、multiple="true"は仕様に沿っておらず、validatorではエラーになる。
これは分かってるよな？
>>597にも書いたし、validatorでも確認できるから、先入観を持たずに確認してくれ。

次に、>>598は、仕様に沿ってなくても、自分の思い通りになれば「正しいことにしてくれる」って思ってるのか？
それなら、<select multiple="on">も<select multiple="yes">も>>598にとっては「正しい」のか？

**Name_Not_Found** · 2015/04/06(月) 14:52:43.62

HTML4では値がmultiple一択だった。
HTML5では何でもいい。

しかし、JSのDOMでは、最初から真偽値だった。
当時のその現状を参考にしてDOM仕様がまとめられた。

HTMLの属性値で文字列としてしか取得できないのだが、見た目にtrueと書いてあると、JSを書く者には親近感が湧くのかもしれない。とにかくこの過去の仕様に照らしての間違いを過去においていたるところで見た。
なんと、HTML5で、何でも良いことにしてくれたw
HTML5での、属性名省略そのものの崩壊とtfootの位置、この2つが代表例だと思っているが、さすがにたまげたわ、馬鹿に合わせてここまで敷居を下げないと実情に合わないんだなって。笑うしかない。

ところで、お前は馬鹿だから現行HTMLでは何でもいいってどういうことか分かってないんだろ、どうせ。
multiple=""
multiple="false"
multiple="true"
multiple="multiple"
multiple
これらがぜんぶ同じ。笑うしかないわなw
お前みたいな馬鹿のせいでこうなったんだよ。

**597** · 2015/04/06(月) 15:16:17.06

>>603はどなた？あと誰宛て？

**Name_Not_Found** · 2015/04/06(月) 15:24:36.47

なんとなく語りたくなったんだろう

**Name_Not_Found** · 2015/04/06(月) 15:30:48.54

603は何と戦っているのだろう？

**Name_Not_Found** · 2015/04/06(月) 20:15:17.25

>>593
やっときたかｗ

> ただ、>>573でご指摘あるとおり、「元々の場所（並び順も同じ）に戻したい」が理想でした。

まあそうだろうと思って、あれからすぐに作っていたのだが
レスがあるまで待ってた。

http://jsfiddle.net/L2p6zkux/3/

**607** · 2015/04/06(月) 20:28:48.07

>>595
補足するならば、ソート使ってないのでデータが増えても問題ないのと
HTML Validにしている。

>>596
> そこまでやるなら要素の外にごちゃごちゃくっつけるんじゃなくて
> 丸っとカスタムエレメントにすべきだよ。

>>595のコードの場合、data-sort=を減らすためだけに
カスタムエレメントにしろって話？それはやり過ぎだろう。

それ以前に俺のコードの場合は、data-sortという特殊な属性も必要なく
HTMLの標準のごく普通のselectだけを使ってるから
新たに要素を作るカスタムエレメントのする意味ないけどね。

で、一つ引っかかるんだけど、「そこまでやる」というけど、
たった14行だよ？（無理やり書けば4行ぐらいに収めることは可能）
たった14行で作れる小さな機能ためにカスタムエレメント導入するほうが、
そこまでやることじゃないって思うけど。

外部に分離する前に、まずんなの大したこと無い。簡単に短いコードで
実現できる。と思いつけるようにならないと。

**Name_Not_Found** · 2015/04/06(月) 20:45:33.92

>>601
> (だからHTML5仕様の例示にも属性名省略で書いてある。)
multipleは値じゃなくて属性だよ。

http://www.w3.org/TR/REC-html32#select
> multiple
> The presence of this attribute signifies that the
> users can make multiple selections. By default only one selection is allowed.

HTML3やHTML4の仕様を見てみれば、昔から属性だってのはわかると思うんだが。
XHTMLだけが異端で、気の迷いでHTMLをXMLの仕様に歪めたために
multiple="multiple"などという変な表記が生まれた。

XHMTLはXMLだから厳格なんだ。故に正しいんだって思っているのかもしれないけど、
HTMLは（XHTMLを除いて）XMLではなく、例えば一部の終了タグとかも省略できるのが
正しい仕様。multipleはHTMLの仕様では昔から値無しの属性。
XHTMLの方が例外なんでもうなかったことにした方がいい。

**Name_Not_Found** · 2015/04/06(月) 21:00:30.27

>>603
> ところで、お前は馬鹿だから現行HTMLでは何でもいいってどういうことか分かってないんだろ、どうせ。
> multiple=""
> multiple="false"
> multiple="true"
> multiple="multiple"
> multiple
> これらがぜんぶ同じ。笑うしかないわなw
> お前みたいな馬鹿のせいでこうなったんだよ。

そんなに不思議なことじゃない。というかおそらくHTML3とかの時代から
挙動は変わってない。

なぜならmultipleは属性であって、その属性があれば有効になるから
値が何であろうと、それを参照していない。

これは知らないものは無視するというHTMLの動きの原則にあっているし
昔からの挙動だと思う。

**Name_Not_Found** · 2015/04/06(月) 21:27:19.02

>>597
別に煽ってるつもりはないし、相変わらず何も分かってないのはそっちでしょ。
>>The values "true" and "false" are not allowed on boolean attributes.
ってのはあくまでNoteであって、"true"/"false"を使ってはいけないという仕様があるのではなく、
"true"/"false"にboolean attributesとしての特別の意味はないから気をつけてね程度のもの。
実際は属性値として設定しておくことは可能でその場合はtrueとみなされる。
嘘は良くないよ。

**597** · 2015/04/06(月) 22:13:53.36

>>611
煽ってるつもりがないなら悪かった
だが誤解しているのはそちらなので、譲りたくない気持ちは分かるがもう一度考えてくれ

> "true"/"false"を使ってはいけないという仕様があるのではなく、
断言する。ある。

NOTEのすぐ上にこう書いてある
https://html.spec.whatwg.org/multipage/infrastructure.html#boolean-attribute
> If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.
『属性が存在するなら、その値は「空の文字列」か「大文字小文字を区別せず属性名に一致する文字列」（前後に空白文字は認めない）である必要がある』
と、明記してある。
つまり、<select multiple>も<select multiple="">も<select multiple="multiple">も<select multiple="MuLtIpLe">もいい。
しかし、<select multiple="true">や<select multiple="hoge">や<select multiple="ok">はダメだ。

ちなみに「NOTE」は日本語の「ノート」という意味もあるが、「重要/注目/注記」という意味もある。
multiple="true"は君に限らず多くの人が間違えることなので、わざわざ注記してくれてるんだよ。

**Name_Not_Found** · 2015/04/06(月) 22:28:54.23

>>612
横から失礼、それはあんたの勘違い。よく読み直そう。

**597** · 2015/04/06(月) 22:41:25.57

教える価値のない相手なのでレスはやめる
スレ汚しすまなかった

**Name_Not_Found** · 2015/04/06(月) 22:50:38.35

いやちょっと待て、あんた盛大に勘違いしといて「教える価値(ry」ってドンだけ….

**Name_Not_Found** · 2015/04/06(月) 22:57:13.96

> 横から失礼、それはあんたの勘違い。よく読み直そう。

なんで勘違いって言ってるくせに
その勘違いの場所を具体的に指摘できないの？ｗ

もうそれで勝負付いているんだけど、
気づいているかな？

**Name_Not_Found** · 2015/04/06(月) 22:57:15.17

急に逃げててワロタｗｗ
どこが勘違いしてるか指摘してやって恥かかせてやろうぜ

**Name_Not_Found** · 2015/04/06(月) 22:58:09.54

じゃあ今から、どの部分が勘違いか指摘していやる。
仕様書読むからちょっと待ってろ

**Name_Not_Found** · 2015/04/06(月) 23:01:15.48

>>594を読め。
https://html.spec.whatwg.org/multipage/forms.html#the-multiple-attribute
>>The multiple attribute is a boolean attribute

この部分の行間を読めばわかるでしょ？
boolean attributeって書いているってことは
論理的に考えるとtrueでもいいはずだ

**Name_Not_Found** · 2015/04/06(月) 23:03:11.86

boolean attributeって書いてあるだけで、trueが許されるなんて書いてないんですがｗｗｗ

あ、それが行間を読むってことなんですねｗ

書いてないけど、お前ん中ではそうなんだろうな理論ですねｗ

**Name_Not_Found** · 2015/04/06(月) 23:03:50.90

本気で言ってんの？

**Name_Not_Found** · 2015/04/07(火) 04:25:19.86

>>620
横だけど、
"true"が許されないってどういう意味で言ってる？
getAttributeでは当然"true"が帰ってくる
値は何でもいいので属性があれば有効というのが正式な動作だよ

**Name_Not_Found** · 2015/04/07(火) 08:39:57.29

いい加減スレチだから余所でやれ

(X)HTML/CSS/Dreamweaverの質問に優しく答えるｽﾚ18
http://peace.2ch.net/test/read.cgi/hp/1424788106/

【WHATWG】HTML5 Part6【W3C HTML WG】
http://peace.2ch.net/test/read.cgi/hp/1393153279/

**Name_Not_Found** · 2015/04/07(火) 08:49:24.85

>>622
> "true"が許されないってどういう意味で言ってる？
HTMLの正しい仕様の話に決まってるだろｗ

> getAttributeでは当然"true"が帰ってくる
JavaScriptは無関係ないので他所でやれｗ

**556** · 2015/04/07(火) 10:16:28.32

>>607
おおお・・・シンプルかつ読みやすい方法、ありがとうございます。
これは元リスト側の選択したoptionを、別のタグ(template)に置き換えている、
という認識でしょうか。
自分の拙い頭脳では、どうやって元の場所と認識しているのか、まだピンときていませんが・・・
>>595でまとめた方法より見やすいので、こちらを採用させて頂きたいと思います。
ありがとうございました。

**556** · 2015/04/07(火) 10:32:49.56

>>607
・・・あれ、jQuery 2.1.3を使用したら動かなくなりました(´・ω・｀)
Ａ→Ｂは動作しますが、Ｂ→Ａが反応しないようです。

**Name_Not_Found** · 2015/04/07(火) 21:20:22.94

>625
> これは元リスト側の選択したoptionを、別のタグ(template)に置き換えている、
> という認識でしょうか。
あってます。

>>626
> ・・・あれ、jQuery 2.1.3を使用したら動かなくなりました(´・ω・｀)
あれ、ほんとだ。

edgeは正式版の最新版だと思ってたら3.0.0.preだったよ。

一応修正した。
http://jsfiddle.net/L2p6zkux/9/

ぐぐるとreplaceWithするとdataが消えるとかあるけど
仕様なのかバグなのかよくわからない。
少なくとも3.0.0 preでは挙動が変わってるようだ。

**Name_Not_Found** · 2015/04/07(火) 21:28:36.37

やっていることは

位置を覚えておく必要があるから、optionを別のものに
置き換えてその場所をポインタにする。
置き換えるのはいいとしてなにに？ template
（HTMLの使用上許されている物はこれしか無いから）

置き換えるのはreplaceWithでできるけど、
元に戻すための情報が必要だね。data()で保存。
保存する値は要素ごとに違うから、replaceWithは
関数を引数にして新しい要素を作ってdata()で保存させる。

戻すときはその情報を使って戻す。

まあこんな感じ。

考え方のコツは、要素（複数のoption）を一つ一つ
処理していくんじゃなくて、「複数のoption」という一つの塊をみて
どばっと置換。どばっと戻す。って考えることかな。

塊で処理したいけど、一つ一つの要素で微妙に違いがある場合は
このようにreplaceWithの引数に関数を指定すれば良い。

不具合のせいでreplaceWithがbefore & detachになってしまったけど。

**Name_Not_Found** · 2015/04/07(火) 21:29:57.71

.replaceWith()は内部的に.remove()を使っている。
.remove()は仕様通りDataやイベントリスナを削除するので、.replaceWith()でもDataが消えちゃうみたいだね。

**Name_Not_Found** · 2015/04/07(火) 21:35:45.21

あぁ、なるほど、だからdata()を使わずに
要素のプロパティに直接保存した時は問題なかったのか。

replaceWithした時に残る情報、残らない情報とがあって
統一されてないから3.0でバグとして修正されたのかな。

覚えておこう。

**Name_Not_Found** · 2015/04/07(火) 22:05:43.46

ごめん、勘違いだったorz
ソースを見たところ、別に内部的に.remove()が使われているわけではなく、
.replaceWith()自体でDataの削除をしていた。
削除の挙動的には.remove()と同等みたいだけど。

あと、ドキュメントに該当の記述があったので参考までに。
http://api.jquery.com/replacewith/
Additional Notes:
The .replaceWith() method removes all data and event handlers associated with the removed nodes.

**Name_Not_Found** · 2015/04/07(火) 23:07:19.17

<template>にそういう使い方があったのか
勉強になった

**Name_Not_Found** · 2015/04/08(水) 04:43:44.44

>>624
正しいではなく上品な使い方の間違いでは？
HTMLは道具なんだからそれを意図的に使えれば正しいといえる。

HTML5はいろいろな場合における細かい挙動まで整備されたんだから、
HTML4以前のように上品に使わないと動作が保証されないということはない。
今回"true"を何が何でも使っちゃいけないという合理的な理由は見つからないし、
仕様に則っても間違いではない。

自分に無駄にルールを作って、道具に使われちゃいけないと思うよ。
それを意味もなく人に強制するのはもっとよくない。
早く誤ちを認めたらどう？

**Name_Not_Found** · 2015/04/08(水) 08:47:48.03

>>633
"正しい" であってるよ。
HTMLには仕様書があって
その仕様書に書かれていることだから。

**556** · 2015/04/08(水) 09:18:59.51

>>627-628
ありがとうございます！
わかりやすい解説も助かります！

それでは名無しに戻ります。
色々とありがとうございました。

**Name_Not_Found** · 2015/04/08(水) 09:48:10.77

なんだ今度は言葉遊びが始まったのか

**Name_Not_Found** · 2015/04/08(水) 12:00:56.95

>>634論外
仕様書が読めるようになってからまた来てね

**Name_Not_Found** · 2015/04/08(水) 18:42:16.16

jQueryってまとめてできるんだ　すげー

**Name_Not_Found** · 2015/04/08(水) 21:06:28.73

>>638
それがjQueryのもっとも重要な所で、これをわかっているかどうかで
jQueryに対しての評価が違う。

時々document.querySelectorAllがあるからjQueryは
もう要らないっていう人がいるけどこれはわかってない人。

セレクタからDOM要素を取得することはできるけど、
その取得した要素に対して簡単に操作する方法をDOMは提供していない。

$('.class').remove(); 例えばこんなの

jQueryは.classに当てはまる要素全てを塊として、.remove()メソッドを実行できるが
DOMでやるならば、ループして一個づつ処理しないといけない。

DOM標準にjQueryのような仕様が入る気配はないし、
jQueryに変わるライブラリなら出来る可能性があるが、
.remove()、.add()、.attr()、.data()、.on()、・・・
必要なのを全部書いていたら、それjQueryでよくね？ってなっちゃう。

VirtualDOMを使うライブラリのように、jQueryどころか、
document.querySelectorAllを含むDOM操作がまったく必要ない
ライブラリを使うならば話は別だが、DOM APIを使うよりもjQueryの方が
良いという事実は今後も揺らぐことはないだろう。

**Name_Not_Found** · 2015/04/08(水) 21:34:52.49

自分はループして一個ずつ処理するのでいいと思うけどな。
document.queryAll('.class').forEach(el => el.remove());程度の記述量で済むわけだし、
逆にただそれを省くために色々な不要な処理も入った半ばブラックボックス化してるライブラリを勉強して使った方がいいとは思えない。
jQueryの良いところはDefferdとかAnimationとかAjaxとかひと通り必要なものが揃ってたことであって、
それらが潰れた今となっては、もう必ずしも必要な存在ではないというか、使わない方が良い存在になってきているのは事実。
>>639が言ってるのは結局はまだほんの少し使える部分もあるよってことでしかない。
DOM操作だけのサブセットを使うというんならまだアリだと思う。けしてベストではないけど。

**Name_Not_Found** · 2015/04/08(水) 21:35:59.64

> document.queryAll('.class').forEach(el => el.remove());程度の記述量で済むわけだし、

動かないだろｗ

わかってない証拠、

**Name_Not_Found** · 2015/04/08(水) 21:38:47.91

DOM操作だけのサブセット＝ jQueryの中から必要な物を厳選＝ jQueryの機能の殆ど＝ならQueryでいいじゃんｗ

jQueryはよく絞り込まれてるよ。どのメッソドもほしいもの。

**Name_Not_Found** · 2015/04/08(水) 21:42:13.10

>>641
どこがどう分かってないのか説明よろ。
>>642
それちきんとコード比でも見て言ってるの？

**Name_Not_Found** · 2015/04/08(水) 21:42:32.89

document.queryAll('.class').forEach(el => el.remove());
を正しく書くなら
Array.prototype.forEach.call(document.querySelectorAll('.class'), el => el.parentNode.removeChild(el));
だな

議論に参加しようと思ったら突っ込まれるところを作ってはいけない

**Name_Not_Found** · 2015/04/08(水) 21:43:26.62

>>643
> どこがどう分かってないのか説明よろ。

せめて動くコードを書けって言ってる。

想像の中で動くであろうコードを書いて、ほら短いといっても、
それはお前の頭んなかの想像の話だろｗってことだ。

**Name_Not_Found** · 2015/04/08(水) 21:47:11.05

> el => el.parentNode.removeChild(el)
この書き方は現状Firefoxでしか動かないから、これが現実的なところだろうね。

Array.prototype.forEach.call(document.querySelectorAll('.class'), function(el) { el.parentNode.removeChild(el) });

この後、メソッドチェーンしたいんだけど？と言われたら（笑）

**Name_Not_Found** · 2015/04/08(水) 21:47:21.33

>>644
話の流れ的に紛らわしかったかもしれないけど、よく見て。
NodeListを返すquerySelectorAllじゃなくて、Elementsを返すqueryAllを使った。
ElementsはArrayを継承してるからforEachが直に使えるでしょ？

**Name_Not_Found** · 2015/04/08(水) 21:48:51.19

>>646
メソッドチェーンしたければmapを使えばいいよ。

**Name_Not_Found** · 2015/04/08(水) 21:49:12.95

>>647
え？ remove()は？

もしかして、お前の想像の世界ではあるって
ことになっんの？

想像の世界の技術で反論（笑）

そんな感じで、さまざまなメソッドを
オレオレライブラリで作るんだろう？ｗ

だったらjQueryでいいじゃんってなるって
最初から言ってる。

**Name_Not_Found** · 2015/04/08(水) 21:50:30.15

>>648
だから動くコードを書けって言ってる。

結局書くと、ばれるのが怖いんだよ。

だから、擬似コード書いて
勝った気になってる。

**Name_Not_Found** · 2015/04/08(水) 21:51:52.66

$('.class').remove();

Array.prototype.forEach.call(document.querySelectorAll('.class'), el => el.parentNode.removeChild(el));

可読性が大きく違いすぎるｗ

**Name_Not_Found** · 2015/04/08(水) 21:52:50.16

>>649
Elementはremove()を持ってるよ。

**644** · 2015/04/08(水) 21:55:58.15

>>647
適当なこと言ってすまなかった
DOMのLS見てきたけど、今までとかなり変わってて驚いた
勉強し直してくる

**Name_Not_Found** · 2015/04/08(水) 21:57:02.90

>>652
> オブジェクトは 'remove' プロパティまたはメソッドをサポートしていません。

説明してくれるかい？

**Name_Not_Found** · 2015/04/08(水) 21:59:12.88

各ブラウザ間の互換性を取るための
ライブラリが必要だな！

jQuery（ボソッ）

**Name_Not_Found** · 2015/04/08(水) 22:00:04.50

>>650
queryAllはまだどのブラウザにも実装されていないけど、モダンブラウザかIE11以降でエミュ可能。
removeはChromeとFirefoxで入ってるのを確認した。
ES6の構文は必要ならトランスパイラを使えばいい。
自分が問題視しているのは、学習コストとそれが古いものになることでの無駄。
もう標準が用意されるってわかった時点で、その機能はポリフィルに切り替えて行くべきだと思ってる。

**Name_Not_Found** · 2015/04/08(水) 22:01:52.87

いや、だからjQueryでいいでしょ？

結局お前が示したコードよりも、
さらにjQueryの方が短くて、
どのブラウザでも動くんだし。

**Name_Not_Found** · 2015/04/08(水) 22:06:06.68

どんなに頑張っても可読性はjQuery ＞ DOMだからねぇ。
DOMの進化が10年遅すぎた。

その10年の間にjQueryは誰もが持ってる必須の知識となってしまったし、
DOMを使った結果、jQueryより劣ることしかできないんじゃ
なんのためにDOM使うのか理由がない。

せめてこれぐらいは、DOMでも25文字ぐらいでできてもらわないとね。
$('.class').remove();

**Name_Not_Found** · 2015/04/08(水) 22:08:49.78

>>655
それは当然大事。
ただ、jQueryが生まれた当初と比べて、互換性がまだまだ取れないという点は未だ残っているが、
そもそも標準機能が不足してるという点は改善されてきてる。
各機能の有り様について標準が提供されているときは、それに従うべきだと思う。
そうするとライブラリというよりポリフィル的なものになる。
そういう意味ではjQueryはとりあえず使っとけと言うものでは無くなった。
特にjQueryは標準にかなり影響を与えていて、標準がjQueryを改善した、
似てるけれど少し違うものを用意しているという問題もある。
つまりjQueryのAPIは腐ってきてるということ。
ただしDOMAPIもそれほど豊富なわけではないのでまだまだDOM操作のフレームワークやライブラリは必要。
とはいえ比較的基礎的なAPIを提供するjQueryをわざわざ使う価値と、合うケースは減ってきてると思う。

**Name_Not_Found** · 2015/04/08(水) 22:12:23.57

$　→　$ = document.queryAll.bind(document)
on　→　ES7を先取りしてObserableに切り替える
でいいんじゃない

**Name_Not_Found** · 2015/04/08(水) 22:18:05.80

Observableな感じを思い浮かべるとメソッドチェーン指向ってのは正しい気がする
そういうスタイルで書くならやっぱり同期メソッドもチェーンで書きたいよね
でもObservableとjQueryを組み合わせるのは難しそう
ここを標準に期待するのは無理だから、おそらくまたどこかのいいライブラリがデファクトスタンダードになって
それを標準が追いかけるようになるんだろうね
いつまでたってもライブラリからは逃れられずに時代は繰り返される

**Name_Not_Found** · 2015/04/08(水) 22:20:24.65

あーでもExtensible Webに則るとそういう世界であってるか

**Name_Not_Found** · 2015/04/08(水) 22:33:57.57

もしElementsにElementのメソッドつけようと思ったらこんな感じになる？
Elements.prototype.__proto__ = new Proxy(Array.prototype, {
　get(aryProto, key, elems) { return (key in aryProto) ? aryProto[key] : (...args) => elems.map(el => el[key](...args)) }
});

**Name_Not_Found** · 2015/04/08(水) 22:47:53.41

あまり知られてないがスムーススクロールも標準でできるようになったんだよな。
http://dev.w3.org/csswg/cssom-view/#enumdef-scrollbehavior
Chでようやく認識するようになった段階で動くのはFxくらいだが。

**Name_Not_Found** · 2015/04/08(水) 23:41:12.44

>>663を試そうと思ったけど、なぜか手元のFF37だと上手くいかない…。
原因を調べるとどうやらprototypeとproxyを組み合わせると上手く動かない。
var o = Object.create(new Proxy({ hoge: 1 }, {
　get(){ return 2; }
}));
console.log(o.hoge); // 2
console.log(o.fuga); // なぜかundefined???
これはバグ？

**Name_Not_Found** · 2015/04/09(木) 00:23:10.37

バグだよ、もう１年くらい前から放置されたまま

**Name_Not_Found** · 2015/04/09(木) 00:29:19.81

と思ったら最近修正されたみたいだな
少なくともNightlyでは直ってる
https://bugzilla.mozilla.org/show_bug.cgi?id=914314

**Name_Not_Found** · 2015/04/09(木) 08:20:21.95

バグだったのか
サンクス

**Name_Not_Found** · 2015/04/09(木) 20:51:58.01

>>663
標準化される前に、標準のprototypeを拡張するのはよくないよ。
あとから標準化された時に名前がかぶっていたら互換性の問題が発生する。

Prototype.jsがそれで痛い目にあってる。
http://qiita.com/jwhaco/items/b5b474883d3020f6dc5f

標準のprototypeを拡張するぐらいなら、
独自のオブジェクトでラップした方がいいと思う。
それがjQueryでやってることでも有る。

**Name_Not_Found** · 2015/04/10(金) 04:15:21.28

良いも悪いもElementsを拡張しようと思えばそうするしか無いでしょ。
まあサブクラスを作るのが一番筋がいいと思うけどな。

**Name_Not_Found** · 2015/04/11(土) 00:52:09.93

> まあサブクラスを作るのが一番筋がいいと思うけどな。
それを実現しようと思ったら、document.getElementsByNameの
戻り値をサブクラスにするってことになるんだけど、
getElementsByNameはdocumentだけにあるものじゃない。

すべての要素に、getElementsByNameがあるわけだから
Elementsを拡張するのであれば、Elementを拡張しなければならなくなる。

もちろんgetElementsByNameだけじゃないね。getElementsByTagNameとかもそう

サブクラスを作るって言えば簡単に思えるかもしれないが、
実際には標準のDOMのElementのメソッドを書き換えまくることをしないといけない。

それで安定して動くのか？って考えると難しい話なんだよ。
だから現実には標準のprototypeを書き変えることをしない。

ブラウザという実行環境がユーザーの手にあって開発者の自由にできないものは、
開発者が自由に実行環境を決めることが可能なデスクトップアプリや
サーバーサイドアプリと同じやり方でやったらだめなんだよ。

**Name_Not_Found** · 2015/04/11(土) 02:06:19.34

callで置換されたthisを一時的に変更するにはどうすればいいでしょうか
例えば、
function A(x) {
this.piyo = new B(x);
this.C = x;
};
A.prototype.do = function() {
this.piyo.do.call(this); //(1)
};
function B(x) {
this.B = x;
};
B.prototype.do = function() {
console.log(this.B); // undefined
console.log(this.C); // 10
};

var hoge = new A("10");
hoge.do();

というコードがあったとします。
この時、(1)でthisをhogeとして呼び出したのでthis.Bがundefinedになりますが、
this.Bの時だけthisをpiyoとして呼び出したいのです。
(1)をthis.piyo.do();として、console.log(this.C);をconsole.log(B.C);とすると、クラス変数ではないのでundefinedとなります。

**Name_Not_Found** · 2015/04/11(土) 03:02:58.80

>>671
頭が硬いね。
別にそうしなくてもSub.from(hoge)としてラップすればいいんだよ。
jQueryみたいな１から作るのと違うのはElementsのメソッドを活かしながら必要な機能のみを安全に拡張できるところ。

**Name_Not_Found** · 2015/04/11(土) 03:27:54.79

必要な機能？

onは必要だしattrやpropやdataも必要
addもremoveも、insertもbeforeもafterもreplaceWithもだし、
eachやgrepも必要だろう。
もちろんメソッドチェーンも必要だし、
逆に必要じゃない機能ってなんだ？

結局jQueryの再実装をしているだけなんだが。

**Name_Not_Found** · 2015/04/11(土) 03:30:29.40

>>673
標準のDOM要素に標準化されてないメソッドを追加すると
あとで同じメソッドが標準のDOM要素に追加された時困るから
やるべきじゃないよ。

継承しても一緒。継承元に有る標準のメソッドを
オーバーライドしてしまうことになる。

**Name_Not_Found** · 2015/04/11(土) 04:42:32.48

>>675
オーバーライドしてしまうのなら問題ないよ。
>>663が問題なのはオーバーライドしないことで、同名の標準ができた時に壊れることだから。
それに標準のものには追加してないでしょ。
別個体のサブクラスに明示的にラップするという操作を伴うものだから、他への影響はないよ。

誰かがしちゃいけませんって言ったことを理由も考えずに信じ続けるのは良くない。

**Name_Not_Found** · 2015/04/11(土) 11:07:38.98

>>676
> オーバーライドしてしまうのなら問題ないよ。
おいおいｗ問題を認識してないのかよ。

DOM非標準のものならば、自分しか使わないから問題ないが
DOM標準の場合は、オーバーライドしてしまったら
他のライブラリが改変された関数を使ってしまうかもしれないだろ。

だからjQueryなどはDOMとは全く別のオブジェクトで
ラッピングするという手法をとっているのだが。

話をまとめるか？

1. 標準のElementsにはattr()というメソッドはありませんでした。
2. だから標準のElementsを拡張してattr()を追加しました。
3. このattr()は当然オレオレ実装です。
4. あるときElementsに標準仕様でattr()が追加されました。
5. オレオレattr()と標準attr()で仕様が違いました。
6. 他のライブラリは標準attr()だと思ってるのにオレオレattr()が呼び出されて困りました。

こういう話なんだが。これprototype.jsで実際に起きた話な。

で、お前はサブクラスなら問題無いと言っているわけだが、
サブクラスでも問題有るんだよ。なぜならElementsを返すのは誰？って話。

例えばdocument.getElementsByTagName()だけじゃなくて
全ての要素.getElementsByTagName() やその他多くの全て。

すべての要素のgetElementsByTagName()だけでなく、
createElement('div') で作られた要素のgetElementsByTagName()も
サブクラスを返すように改変しないといけない。
そうすると、DOMのElementのprototypeを改編する話だってのはわかるな？

**Name_Not_Found** · 2015/04/11(土) 16:10:30.03

>>677
＞＞サブクラスを返すように改変しないといけない
だからそうじゃないって言ってるだろ。
>>673を見たのか？
逐一Elementsをサブクラスにラップして使うやり方について言ってるの。
だからElementsを利用してる他のものに影響を与えることはない。
まず人の話をよく聞いてから批判しような。

**Name_Not_Found** · 2015/04/11(土) 16:24:25.13

>>678
あんたたサブクラスとラップという用語を
ちゃんとわかってないって言うことがよくわかったよｗ

ラップするならばサブクラスにする必要はないし普通はしない。
jQueryはDOM要素郡（そこでいうElements）をラップしたもの。

**Name_Not_Found** · 2015/04/11(土) 16:25:41.48

> jQueryはDOM要素郡（そこでいうElements）をラップしたもの。

正確に言うならば、jQueryの$()などで返すjQueryオブジェクトは
DOM要素郡（そこでいうElements）をラップしたもの。

**Name_Not_Found** · 2015/04/11(土) 16:27:48.12

だーよーねー！

**Name_Not_Found** · 2015/04/11(土) 16:49:55.33

そもそもElementsを何のサブクラスにするって言ってるんだろう？
ちゃんとわかってるなら○クラスのサブクラスにするって
具体的に言えるはずだ。ぜひ○の中身を答えて欲しい。

先回りしていっておくと、世の中には○クラスを引数にする
関数が存在するが、○クラスを互換性がない形に改変すると
その関数の引数に入れられなくなる。（本当にサブクラスなら入れられる）
だが改変しないとメソッドチェーンが使えなくなる。

**Name_Not_Found** · 2015/04/12(日) 01:02:35.47

>>679
分かってないのはあんた。
Elementsに元々あるメソッドを使うためにもそうするのが一番自然、
言い訳見苦しいよ。負けを認めなさい。

**Name_Not_Found** · 2015/04/12(日) 01:39:27.58

>>683
> Elementsに元々あるメソッドを使うためにもそうするのが一番自然、
Elementsに元々あるメソッドって何のことだよｗ
なんのサブクラスにしたいわけ？
答えられてないよね？

> 言い訳見苦しいよ。負けを認めなさい。
ワロタｗ
勝ったつもりでいるんだｗ

**Name_Not_Found** · 2015/04/12(日) 02:03:53.43

元々のメソッドを使う方が絶対にいいはずだって
固定観念を持っているんだろうね。

jQueryのeachではなく、
Elements.forEach（Array.forEach）を使ったほうが
いいはずだって思ってるのだろうけど、
forEachではメソッドチェーンが出来無くなってしまうわけで

元々のメソッドを使うとjQueryからすると劣化してしまう。
劣化しないように作るとなると元々のメソッドはほぼ全て使えなくなってしまう。

ここまで考えずに、元々のメソッドを使う方が絶対にいいはずだって
固定観念を持っているんだろうね。 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

**Name_Not_Found** · 2015/04/12(日) 02:15:33.98

forEachでなくmapを使えばいいんじゃね？

**Name_Not_Found** · 2015/04/12(日) 02:30:38.96

>>684
queryAllとかあるでしょ。
それらを一々再実装するの？
元からあるのを使った方がいいに決まってる。

>>685
mapを使えばmapはthisのコンストラクタを見て、
きちんとサブクラスのインスタンスに結果を追加していってくれる。
他のArrayのメソッドでも同じ。
そういう意味でもサブクラスにするのは正しい。

**Name_Not_Found** · 2015/04/12(日) 03:04:21.11

>>687
> それらを一々再実装するの？
君はライブラリを使うってことを覚えようよｗ
jQueryが実現しているから使うだけ。

それにqueryAllが返すElementsの話だろ？
Elementsをサブクラスにしろっていう話なんだから。
queryAllがあるのはElementであってElementsじゃない。

mapがあるのはArrayであってElementにはない。
Elementsにも無い。（queryAllが返す要素の配列は、本当の配列じゃないから）

それらを一々サブクラスに再実装するの？ｗ

**Name_Not_Found** · 2015/04/12(日) 03:48:03.50

>>688
ライブラリを使えばいいというのはそのとおりだよ。ライブラリはダメとか言ってないだろう。
そういう話ではなく、どういう手法がいいかということで、
jQueryのように丸っと世界を構築するよりも、>>663のようにするよりも、サブクラスを用意するのが一番折り合いがとれてるという話をしてるんだ。
なにを勘違いして一人で苛立ってるんだ？

そしてElements.prototype.__proto__ == Array.prototypeだし、
queryAllが返すのだって列記としたArray exotic objectだから。
ES6からはビルトインコンストラクタはnewTargetを見て適切なプロトタイプを持ったインスタンスを作ってくれるでしょ？
継承するというのはそういうことだよ。

もうホントにね、人の話は聞かない、仕様も読まない知らない、考える力もない、反省もしない。
君と話してると呆れて疲れるね。

**Name_Not_Found** · 2015/04/12(日) 08:57:02.29

>>689
焦点がずれてるな。サブクラスにする危険性をわかってない。

まずElementsがArrayだとしてjQueryに比べれば大幅にメソッドが足りない。
onとかattrとかきりがないから全部言わないよ？

そこでElementsのサブクラスを作ってメソッド追加しろって言いたいんだろ？
それが危険だという話。

ElementsのサブクラスはArrayでは無くなってしまうから。

なぜなら、
Elementsのサブクラスにhogeというメソッドを作った。
将来のArrayが拡張してhogeというメソッドを作った。
ElementsのサブクラスのhogeとArrayのhogeは別物
つまり、ElementsのサブクラスのはArrayではなくなる。

型あり言語なら型とシグネチャで正しくディスパッチしてくれるが
JavaScriptのような言語では無理

そして問題はまだある。

Elementsのサブクラスを作ったからといって、
queryAllがElementsのサブクラスを返してくれるわけじゃない。

DOMのあらゆるAPIがElementsの代わりに、
Elementsのサブクラスを返すようにモンキーパッチしまくらないといけない。
何かを忘れていると、よくわからないエラーが発生することになる。

危険性があるうえに、既存のメソッドを間違いなく修正するという大変な作業が必要。
サブクラスの仕様を考えただけで全てがうまくいくって考えてるようだが経験と想像力が足りないよ。

**Name_Not_Found** · 2015/04/12(日) 09:00:27.79

あと、想像の世界の話をしてないで
実際の動くコード書きなさい。
jsfiddleって知ってるかい？

**Name_Not_Found** · 2015/04/12(日) 09:57:34.37

またjQuery厨が暴れて生温かい視線を浴びてるのか。

**Name_Not_Found** · 2015/04/12(日) 16:01:40.91

>>690
論点がずれてるのはあんた。
オーバーライドは問題にならないという話はもう上でしただろ。
想像力がないのか？
もし万が一新しいメソッドがArrayやElementsに追加され、
それがサブクラスと被ったら、ライブラリをバージョンアップすればいいだけ。
サブクラスは元クラスのプロトタイプ拡張と違って、明示的に使ってない周りへ影響を与えないし、
環境が新しくなっても、古いバージョンのライブラリに依存してる古いコードが壊れることもない。

それと、queryAllがサブクラスを返したりすることはやらないと言ってるでしょ。
一度ラップしてやれば、例えばmapなんかはArrayではなくきちんとサブクラスのインスタンスを返してくれるように
ES6では設計されているので、何度もラップしたりすることなくチェーンできる。