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

**デフォルトの名無しさん** · 2018/02/18(日) 16:48:01.14

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

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

前スレ
+ JavaScript の質問用スレッド vol.124 + [転載禁止](c)2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1427008785/

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

**デフォルトの名無しさん** · 2018/04/06(金) 23:13:33.61

jQuery君みたいにあだ名つけようぜｗｗ

**デフォルトの名無しさん** · 2018/04/06(金) 23:47:31.85

>312 は初心者なんだろうな
> <input>自体がHTML的に中途半端(終了タグがない等）だから、整備中か？
終了タグがないのはinputは空要素だから。とかは基礎知識だから覚えとくといいよ。

世の中にはたくさん考慮する事があって、例えばinputの種類によっては削除ボタンとか、パスワードを可視化ボタンを出すブラウザもある。
他にもプレースホルダとか、入力状態のIMEをどう考えるのか？そうすると、単純にテキストを描画してるだけではないし、文字の横幅だけという訳にはいかない。
writing-mode:vertical-rlの場合はscrollWidthは期待した値にならないし、IMEやUnicodeの将来的な拡張にも備える必要がある。

とりあえず仕様とかわからんが、動けばいーやというのがお前みたいな初心者

**デフォルトの名無しさん** · 2018/04/06(金) 23:57:34.88

>>321
何度も言うが、そう思うのはお前の自由。
他の人がどう取るかは、他の人の自由。

俺は初心者がお前みたいな馬鹿に騙され続けるのを止めようとしている。
それがJavaScript界の浄化に繋がると期待している。

**デフォルトの名無しさん** · 2018/04/06(金) 23:59:20.26

>>322
そう思いたいならお前の自由だよｗ

**デフォルトの名無しさん** · 2018/04/07(土) 00:18:39.91

「お前らは分かってない」が口癖のいつもの人
分かってない君でいいんじゃないの

**324** · 2018/04/07(土) 00:19:53.16

>>324は>>320宛

**デフォルトの名無しさん** · 2018/04/07(土) 00:41:47.74

じゃ分かってない君で。

**デフォルトの名無しさん** · 2018/04/07(土) 01:06:26.30

>>313
偉そうだが、中級者をけなすあなたは上級者なのか？

**デフォルトの名無しさん** · 2018/04/07(土) 01:46:06.50

それはお前が勝手に決めることだ。
腕がよければ相手の力量を正確に見積もれるし、
逆に、見誤るようならそれはお前が無能である証明でしかない。

**デフォルトの名無しさん** · 2018/04/07(土) 02:19:11.59

分かってない君は初心者だな。基礎知識も足りないし、頭の中の情報も更新されてない。
教えてもらったことの検証も間違ってたり、用語の使い方も不自然だったり

多分、Web以外の得意分野があると思い込んでるけど、実はそちらも中級者ぐらいとみた

**デフォルトの名無しさん** · 2018/04/07(土) 02:26:59.60

動くコードをささっと作れるやつが一番すごい

**デフォルトの名無しさん** · 2018/04/07(土) 04:10:57.41

Web Audio API の GainNode って、現在の値が valueで取得できるわけじゃないんだな。
console.log(GainNode.gain.value); とやっても常に同じ値しか出ない。
ADSR の R の部分を作ってて気づいたんだが、どうにも現在値が取得できないので困った。
仕方なく別の方法にしたけど… じゃあなんのための getter なんだこれは？

**デフォルトの名無しさん** · 2018/04/07(土) 06:35:27.60

Gainは回路上における音量のつまみだぞ、けして測定器ではない
色で行ったらアルファ、もしくはcssみたいなもの
そして色と同じく音の大きさっていうのは相対的なものだし、
色の輝度と明度が違うように、音にも音量以外にも音圧があるし、
もちろん周波数によっても感じ方が違う

それとAudioParamのvalueは仕様上getterではなくただの値だぞ
内部プロパティもといネイティブ世界の値とリンクさせないといけないから
実装上アクセサになってるが、別にクオンタム毎の捜査/更新でも良いし、
ProxyやArrayのlengthのような実装の方が仕様に沿っているが
簡潔さを考えた場合にアクセサにしたのだろう

**デフォルトの名無しさん** · 2018/04/07(土) 08:38:40.65

>>313
＞D. inputをcloneNodeして中身をコピーし、その場に貼り、不可視で計測する
＞E. spanに中身をコピーし、styleも全コピーし、どこかに貼り、不可視で計測する
＞styleのコピーがいる分EはDより面倒で「コードが増える。」

同じものを同じ場所に貼り付けたら同じスタイルになると無邪気に思っていらっしゃる感じかなー

他分野でスーパーエンジニアでいらっしゃるあなた様の考える仕様がどれだけ素晴らしいかは推し量るのも恐れ多いですけれども
Webのフロントエンドについてはブラウザの実装が全てなので、仕様に文句つけてる暇はなく、
糞仕様の糞APIに付き合うかラップしたフレームワークを作るか使うかしかないし、
APIに文句ばっかりつけてるうちは永遠にフロントエンド初心者だよ

**デフォルトの名無しさん** · 2018/04/07(土) 09:10:37.59

>>>333
> 糞仕様の糞APIに付き合うかラップしたフレームワークを作るか使うかしかないし、
その通りだ。だから俺は一番マシな解法でやる。それは既に示した。
それよりもマシな解を示せるのなら偉ぶって構わないとは思うが、
そうではないのにお前らがただ上級者ぶるのは俺には理解不能だ。

それとは別に、これを認めるのなら、
当然これがお前らの成長を阻害している要因の一つだとは認識できるだろ。
仕様のグダグダな所を暗記するのがプログラミングの勉強ではない。
お前らがブラウザ互換性の問題の勉強に費やした時間もまた、無に帰すときが必ず来る。
PHPとかも相当酷いから、
逆に暗記重視の文系プログラマにとっては安住の地になっている感があるが、
そうではない奴はPHPを目の敵にしてるだろ。

仕様のグダグダな部分はだんだんと修正されていく。
APIが不備な部分はだんだんと整備されていく。
ブラウザの互換性もだんだんと上がっていく。
お前らが腕前をこれらに依拠しているのなら、お前らの存在価値は自然と目減りしていく。
それを自覚しろと言っているのだよ。

とはいえ、君らがどうするかは君らの自由だが、
間違ったことを垂れ流してミスリードし、次世代の足を引っ張る権利は君らにはないんだよ。
だからそれはマジで止めろと言っている。

**デフォルトの名無しさん** · 2018/04/07(土) 09:25:51.50

jQuery兄さんにこてんぱんにされてから
長文書くようになったなぁｗ

**デフォルトの名無しさん** · 2018/04/07(土) 10:33:07.55

>>328
いや、他者評価ではなく、自己評価を聞いてるんだが
「お前がそう思うならお前の中ではそうなんだろう」なんて切り返しは要らん

仕様が分かっていないと自認する割には、他人を初級者～上級者まで評価する程度の実力を持っていると思っている節があるようだし、おなた自身の認識に矛盾がある

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

「ならば……今すぐ怠惰なエンドユーザーどもすべてに環境をアップデートさせてみろ！」って感じ

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

>>334
変な要求を場当たり的に解決できたのを自慢げに語られてもねぇ

DOMを触れる前提の解決策はすでにマシとは言いがたい
ReactやVunみたいに分離や仮想DOMが普及してきてる

**デフォルトの名無しさん** · 2018/04/07(土) 12:14:34.26

>>312
＞<input type="text"></input>で入力が内部textNodeになれば、それが出来るだろ。
input要素はtextだけじゃなくて、dateとかrangeとかいろいろある

これらはHTMLに直接記述したり、JSから取り扱うときにはDOMStringにシリアライズされるけれども、
その意味するものがテキストとは限らないし、UAでの表示・入力方式もカレンダーなど、テキスト以外の形態を取るかもしれない。
つまり、input要素のvalueはDOMStringではあってもTextであるとは限らない。

type="text"だけ例外的にvalueではなくてcontentのtextNodeで扱うのは統合性の観点から問題があるし、
JSで扱うときにDOMStringになるからといって、テキストでないものをUAでの取り扱いも無視してtextNodeとしてcontentに入れてしまうのは
HTMLやそのDOMの基本構造から外れてしまい、これも統合性の観点から大問題。

＞Webの場合はこの辺の「統合的」な視点が全く欠けており
統合的な観点が欠けているのはどなたでしょうかね。

**デフォルトの名無しさん** · 2018/04/07(土) 12:25:06.56

>>338
> ReactやVunみたいに分離や仮想DOMが普及してきてる

jQueryの73.4%に比べれば1%以下では普及してるとは言えないです
https://w3techs.com/technologies/overview/javascript_library/all

**デフォルトの名無しさん** · 2018/04/07(土) 12:51:18.67

そんなことはない
例えば現代の日本人の0.5%に使われてる着物というものがあったら
大ヒット大普及と言えるだろう

**デフォルトの名無しさん** · 2018/04/07(土) 12:59:31.49

>>340
無意味な使用率とかを見ちゃうようではなぁ
自分で、
>お前らが腕前をこれらに依拠しているのなら、お前らの存在価値は自然と目減りしていく。
とか言っちゃうくせに新しい技術への考慮をしないとは

事実jQuery使ったサイトは多いけど、すでにあるものの修正か、使いたいライブラリがあるか、シンタックスシュガーとして楽するみたいな使い方ばっかりだな
標準APIとCSS,JavaScriptの機能拡充で使う必要性はかなり薄れた

**デフォルトの名無しさん** · 2018/04/07(土) 13:00:44.25

用途も使われてきた期間も違うから比べるもんでもないけどね

**デフォルトの名無しさん** · 2018/04/07(土) 13:01:53.79

>>342
それ別人やぞ

**デフォルトの名無しさん** · 2018/04/07(土) 13:10:00.78

>>341
> 例えば現代の日本人の0.5%に使われてる着物というものがあったら

それは「着物」の場合ですね。別の話です。

**デフォルトの名無しさん** · 2018/04/07(土) 13:12:20.89

>>342
> 事実jQuery使ったサイトは多いけど、すでにあるものの修正か、使いたいライブラリがあるか、シンタックスシュガーとして楽するみたいな使い方ばっかりだな

因果関係が逆になってますね。

楽するみたいな使い方ぐらいしかする必要がないからjQueryを使うんですよ
ほとんどはReactとかAngular使ってデスクトップアプリみたいなものを
作りたいなんて思ってないんです。

企業サイトを楽に作りたいだけです。

需要があって供給が決まります。

**デフォルトの名無しさん** · 2018/04/07(土) 13:23:15.13

なぜ普及率云々の話になってるんだ？
普及率なんて使うときの目安にもならんのに

**デフォルトの名無しさん** · 2018/04/07(土) 13:26:09.73

普及率を見て何かを決めるんじゃなくて、
何かを見て決めて実行した結果が、普及率として形になるんだよ。

結果を言ってるだけ。目安にしろと言ってない。

**デフォルトの名無しさん** · 2018/04/07(土) 13:27:36.70

>>339
> type="text"だけ例外的にvalueではなくてcontentのtextNodeで扱うのは統合性の観点から問題があるし、
いや、それはtextNodeではないぞ
彼も同じ勘違いをしていたようだが、彼には初心者特有の「事実と想像(思い込み)を区別できてない」ものを感じた

**デフォルトの名無しさん** · 2018/04/07(土) 13:27:52.26

>>339
> type="text"だけ例外的にvalueではなくてcontentのtextNodeで扱うのは統合性の観点から問題があるし、
これは俺の書き方が悪かったが、
俺は<input>全体が<div><span>と同格に扱える仕様であるべきだと思っている。
(今回はtpye='"text"だったから分かりやすいようにそれ限定で書いていただけ）
同様に<textarea>もだ。
そうすれば、<textarea><input>の場合だけ value にしている if 文が抜ける。
本来はこれが正しい仕様だ。valueは生の値、textContentはDOMStringだ。

というか方向は確実にこっちで、
HTMLInputElementはNodeを継承しているのだからtextContentをオーバーライドしてないことがおかしい。
これについては互換性の問題は深刻ではないので、追加（というより修正）されてもおかしくない。
お前らはここら辺の、「本来あるべき形」ってのが見えてない。
それはプログラミングで統合的に扱おうとしてないからだ。

ここら辺の、「仕様」の例外はどうやっても避けられないから、処理を分けるしかない。
それはわざわざ汚いコードを書かされる羽目になり、
「処理を分けずに書くことが出来る上級者」にとってはものすごいストレスになる。
一方、「いちいち処理を分けて書くしかできない初心者」にとっては何もなく、
ここら辺がPHPが上級者に『だけ』強烈に嫌われる理由でもある。
PHPは言語仕様自体が酷すぎて、上級者でも本当に酷いコードを書かされる羽目になる。
結果、上級者は去り、PHPは初心者の楽園となり、それはそれで楽しいのだろうが、
上級者のコード（美しいコード）がその世界に存在しないってのは、PHPerが馬鹿にとどまる理由の一つでもある。
JavaScriptは言われるほど酷くはないが、同様に、
仕様が汚いから美しいコードが存在しにくいというのはあって、
これもお前らの上達を阻害している要因ではある。

JavaScriptのスレは他言語と比べて活発で、今日でも休日なのにお前らは投稿しまくりだ。
お前らが努力をしてないってわけではないのだろうさ。
ただ、上記のように、環境が悪いから上達しにくい、ってのはあるんだよ。
だから、これらを正しく認識した上で、空回りは止めろと、俺は言ってるんだよ。

**デフォルトの名無しさん** · 2018/04/07(土) 13:29:29.94

>>348
だから、それはどうでもいいだろ
自己満足にしかならん

**デフォルトの名無しさん** · 2018/04/07(土) 13:32:48.21

> これは俺の書き方が悪かったが、
> 俺は<input>全体が<div><span>と同格に扱える仕様であるべきだと思っている。

知らんがな。お前が思ってたからってだから何だよ？
理由の一つぐらいいえ。

俺なら言えるぞ、inputはdivやspanと同格に扱えるものではない。
なぜならdivやspanは出力するためのものだ。
intputは逆に入力するためのものだ。

見やすさと入力のしやすさは違う。出力は製作者側がコントロールできるが
入力は何を入力するかは決められない。どうやって入力するかも決められない

本質的にまったく違うものなんだから、お前の主張は根本から間違いだってわかる

**デフォルトの名無しさん** · 2018/04/07(土) 13:33:31.08

>>351
何の自己満足？

俺は単に事実を提示しただけ

**デフォルトの名無しさん** · 2018/04/07(土) 13:47:34.83

>>350
おまえは ID:k7L1I/bs と同一人物なのか
自作自演してまで味方を増やそうとするとは

**デフォルトの名無しさん** · 2018/04/07(土) 13:47:40.70

>>352
お前、、、レスする前にまずは全文読めよ。

ただまあ、
> 俺なら言えるぞ、inputはdivやspanと同格に扱えるものではない。
> なぜならdivやspanは出力するためのものだ。
> intputは逆に入力するためのものだ。
これは「オブジェクト指向では」間違いだということになっている。
とはいえ見た限り、DOMのオブジェクト指向は後付で、ややちぐはぐなのも事実だが。

君が非オブジェクト指向派で、
> 本質的にまったく違う
と思うのならそれはそれでいいが、
おそらくDOMについてはオブジェクト指向で取り扱う方が正しい。

おそらく君はそれ以前で、「オブジェクト指向」を理解できていないのだと思う。
これについては勉強した方がいい。
ただまあ、オブジェクト指向自体の勉強はやややりにくいのも事実だが…。

**デフォルトの名無しさん** · 2018/04/07(土) 13:49:14.74

>>353
自分が使用しているライブラリの普及率の高さを見てニヤニヤする自己満足
事実は事実だが、掲示する意味がないといってるんだよ

**デフォルトの名無しさん** · 2018/04/07(土) 13:58:19.63

> おそらくDOMについてはオブジェクト指向で取り扱う方が正しい。

知ってる。ってか常識

DOM とは Document Object Model の略

なんでお前そんなレベルの話してんの？

**デフォルトの名無しさん** · 2018/04/07(土) 13:59:10.47

>>355

> なぜならdivやspanは出力するためのものだ。
> intputは逆に入力するためのものだ。
> これは「オブジェクト指向では」間違いだということになっている。

なってない。というか、なってるという証拠示せよ

**デフォルトの名無しさん** · 2018/04/07(土) 14:02:32.70

>>352
>>357
>>358
日本語でおｋ

**デフォルトの名無しさん** · 2018/04/07(土) 14:03:50.69

>>350
＞本来はこれが正しい仕様だ。valueは生の値、textContentはDOMStringだ。
それは思いっきり間違った仕様だし、典型的なアンチパターンです。
valueから一意に計算されるものをvalueと別に保持するべきではないし、
「とある属性の値をDOMStringに変換したもの」は要素の「内容(Content)」ではないので、
これをtextContentで返すべきでもありません。

textContentは要素の"内容"であるべきで、inputだけ例外として内容でないものをContentとしては
HTMLというもの全体の統合性が失われる。
目先の処理の統合性のために、データ構造そのものの統合性を失わせるのでは本末転倒。

HTMLにおいて"内容"(Content)というのは特別な意味を持つ専門用語なので、
そういった基本を学んでからDOM APIに文句をつけることをおすすめします。

＞HTMLInputElementはNodeを継承しているのだからtextContentをオーバーライドしてないことがおかしい。
オーバーライドしてますよ。空要素(内容を持たない要素)なので常に空文字列が返ります。

【HTMLはJavaScriptのためにあるものではないので】
JavaScriptから扱うときの処理を数行減らすためだけに、データ構造の整合性を失わせることはできません。

**デフォルトの名無しさん** · 2018/04/07(土) 14:05:06.45

>>359
日本語を勉強しろ

**デフォルトの名無しさん** · 2018/04/07(土) 14:24:33.89

>>360
君がそう思うのならそれはそれでいいのだが、
俺の考えだけ言っておくと、以下になる。

> inputだけ例外として内容でないものをContentとしては
inputの表示内容を textNode にしてchildNodes[0]にすれば、
Range で統合的に取り扱えるようになる。
そのときにその表示内容が textContent で取得/変更出来るのは自然だ。
だから、「inputは空要素」というのがそもそもの間違いで、
XHTMLではとりあえず終了タグ付けようとしただろ。（ポシャったが）
あれは方向はあってるんだよ。

> オーバーライドしてますよ。空要素(内容を持たない要素)なので常に空文字列が返ります
これが後付なんだよ。今の仕様を無理矢理OOPに乗せて、
オーバーライドしたことにして辻褄を合わせている。今の君の主張のようにね。

同様なのはNodeもそうだが、例えば、
https://developer.mozilla.org/ja/docs/Web/API/HTMLInputElement
で見ると、継承階層は
EventTarget <- Node <- Element <- HTMLElement <- HTMLInputElement
であり、実は addEventListenerはEventTargetのメソッドだ。
だから理屈的には textNode に対しても addEventLister できる事になり、
確かに出来るのだが、イベントには反応しない。
これも同様に、Element階層でイベントに反応するaddEventListerがオーバーライドされており、
EventTargetのaddEventListerはただの空関数です、ということは出来る。
しかし明らかに辻褄合わせだろ。間違ったOOPの使い方であってさ。

こんなのを見てOOPを学べるはずもない。教材が悪すぎる。
そりゃ ID:C4tJt4pN が理解できてないのも一理あるだろうよ。

**デフォルトの名無しさん** · 2018/04/07(土) 14:32:37.51

> inputの表示内容を textNode にしてchildNodes[0]にすれば、
> Range で統合的に取り扱えるようになる。

それは悪いやり方ですね。
textNode ならtextNodeのメソッドを持っていなければいけないので、
つまり、inputの表示内容の、nextSiblingやparentElementってなんでしょうって
話になりますね。

**デフォルトの名無しさん** · 2018/04/07(土) 14:34:56.87

>>362
> こんなのを見てOOPを学べるはずもない。教材が悪すぎる。

お前の頭が悪すぎるだけだよｗ

1. a は b である！（お前の間違った考え）
2. しかしにbはaと考えると問題が有る（間違った前提だからそうなる）
3. よって、aはbであるDOMはクソ（そもそもaがbであると言い出したのはお前）

まあ、こういう論理してますからねｗ

**デフォルトの名無しさん** · 2018/04/07(土) 14:37:37.19

>>363
nextSibling は null になる。childNodes.length===1だから。
parentElement は当然<input>だ。
特に問題ないし、自然だろ。

**デフォルトの名無しさん** · 2018/04/07(土) 14:38:01.23

>>362
＞inputの表示内容を textNode にしてchildNodes[0]にすれば、
＞Range で統合的に取り扱えるようになる。
繰り返しますが、HTMLはJavaScriptのための（ｒｙ
それからこれも繰り返しますが、【input要素の表示内容はテキストとは限らないので】、textNodeにはできません。

＞だから、「inputは空要素」というのがそもそもの間違いで、
<input type="color" value="#808040">を
<input type="color">#808040</input>と書けというのは明らかに不条理ですよ
2018-04-07というのは便宜上このようにシリアライズしているだけであって、"#808040"というテキストを表しているわけではないし、
UAで表示されるのもテキストとは限りません。
実際、Windows+ChromeではHTMLに直書きしたり、JavaScriptで読み取る際にこそシリアライズされた文字列を使いますが、
ユーザーにはただ色そのものが表示されるだけですし、入力時にもこのシリアライズ文字列は使われなません。

＞そのときにその表示内容が textContent で取得/変更出来るのは自然だ。
input要素がテキストを表示するとは限らないので、textContentで表示内容は取れません。
表示内容は画像かもしれないし、カレンダーかもしれないし、アナログ時計かもしれないし、ただの色かもしれない。

**デフォルトの名無しさん** · 2018/04/07(土) 14:39:07.53

>>366
＞2018-04-07というのは便宜上このようにシリアライズしているだけであって、"#808040"というテキストを表しているわけではないし
訂正
#808040というのは便宜上このようにシリアライズしているだけであって、"#808040"というテキストを表しているわけではないし

dateからもっとわかりやすいcolorに変えてからの修正ミス

**デフォルトの名無しさん** · 2018/04/07(土) 14:39:19.08

TextNodeがイベントに反応しないっていうのも間違いで
現在は（おそらく）TextNodeが反応するイベントがないってだけで
過去にはありましたからね
https://stackoverflow.com/questions/4789342/textnode-addeventlistener

var textNode = document.getElementById("div").firstChild;

textNode.addEventListener("DOMCharacterDataModified", function(evt) {
alert("Text changed from '" + evt.prevValue + "' to '" + evt.newValue + "'");
}, false);

**デフォルトの名無しさん** · 2018/04/07(土) 14:41:21.58

>>365
> parentElement は当然<input>だ。
> 特に問題ないし、自然だろ。

あっはっは、馬鹿も休み休み言え

<span><input value=1>a</span>
<span><custom value=1>a</span>

**デフォルトの名無しさん** · 2018/04/07(土) 14:42:58.26

HTMLの属性を要素としてみなすと、
HTMLとしての整合性が取れなくなるからね。

**デフォルトの名無しさん** · 2018/04/07(土) 14:44:12.19

XPathとかで全てのテキストノードを消すと
inputの中身まで消えちゃうｗｗｗ

**デフォルトの名無しさん** · 2018/04/07(土) 14:44:12.20

>>366,367
君のこだわりがよく分からないが、さらにつき合うと、

> 表示内容は画像かもしれないし、カレンダーかもしれないし、アナログ時計かもしれないし、
それならそれが入ればいいだけだろ。textならtextNodeであって。
具体的には、
<input><img></img></input>
<input><calender></calender></input>
<input><analogClock></analogClock></input>
で特段何か問題が発生するとは思えないが。

**デフォルトの名無しさん** · 2018/04/07(土) 14:46:38.83

xpathでテキストノードを選択すると

<span value=0><input value=1 data-value=2>a</span>

valueの1とaの両方にマッチするっていうのは
非直感的なクソ仕様ですよ

「input要素に限りvalueはテキストノードとして扱われます」

なんて書いてあったら、そいつは本当に人間なのか？って思うｗ

**デフォルトの名無しさん** · 2018/04/07(土) 14:52:13.75

>>366,367
というかな、多分君は「抽象思考」が出来ていない。

タグってのは単なる「参照」なんだよ。（プログラミング用語での参照、日本語でいう参照ポイント）
今問題なのは、<input>の中身に参照がないから捕まえられないことであって、
それは単にタグ付ければ回避できる、って話であって、
逆に、単に参照を付けただけだから、それで何か新しい問題が発生するって事もないんだよ。

HTMLが先進的だったのは、文章にタグを付けて、参照できることにしたことなんだよ。
それ以前は文章→ビットマップに変換だから、当たり判定なんて基本的に出来ないし。
だって参照がないから。

**デフォルトの名無しさん** · 2018/04/07(土) 14:54:40.04

>>372
<input type="date">でカレンダーで日付を表示するのか、
2018-04-07みたいな文字列の形式で日付を表示するのかは
【ユーザーエージェント依存】なので、そんなことはできませんし、できる必要もありませんし、
マークアップ側が指定すべきものでもありません。

HTMLとして必要な情報は「これは日付の入力フォームである」という情報だけであり、
リッチクライアントならカレンダーを表示するだろうし、
テキストブラウザなら「2018年4月7日」などとテキストで表示され、数字を編集することになるだろうし、
音声ブラウザなら音声的に処理するでしょう。

あなたは全てのクライアントがいずれ完全互換になるとか思っているのかもしれませんが、
人間自体が完全互換ではないので、そうなる未来は我々の生きている間にはおそらく来ませんよ

**デフォルトの名無しさん** · 2018/04/07(土) 15:01:51.14

>>375
だからそれが、「参照ポイントを付加した」だけだ、って言ったんだよ。

今<input>で出来ていることを、
<input><中身></中身></input>に変更したことによって生じる違いは、
・中身に参照を追加した
だけなんだよ。今できていることが出来なくなることはない。

君はだいぶ論点がずれている。
君は表示のことしか考えてないが、そもそも参照を付加しても表示は何も変わらない。
だから君の375での指摘は全く意味をなしてないんだ。分かるか？

**デフォルトの名無しさん** · 2018/04/07(土) 15:02:54.26

横からすまんが、踊る分かってない君に対する皆さんの誠実な突っ込みには大変勉強させていただいております。

**デフォルトの名無しさん** · 2018/04/07(土) 15:04:44.25

> 今<input>で出来ていることを、
> <input><中身></中身></input>に変更したことによって生じる違いは、
> ・中身に参照を追加した
> だけなんだよ。今できていることが出来なくなることはない。

DOMツリーを全操作して、子要素がないものを全部取得することができなくなる

**デフォルトの名無しさん** · 2018/04/07(土) 15:05:43.59

value要素だけを特別扱いするということは、
処理をシンプルにできなくなる

**デフォルトの名無しさん** · 2018/04/07(土) 15:05:54.25

>>375
OOPで言うと、参照を付加する＝今privateな物をpublicにしただけなんだよ。
だから何も変わらない。これで分かるか？

**デフォルトの名無しさん** · 2018/04/07(土) 15:06:56.16

> OOPで言うと、参照を付加する＝今privateな物をpublicにしただけなんだよ。
> だから何も変わらない。これで分かるか？

既存のpublicなメソッドに名前を変更すると
互換性が壊れる。

**デフォルトの名無しさん** · 2018/04/07(土) 15:07:22.32

新たにメソッドを増やすときは、今までとは違った名前にすることは
互換性を保つ上であたりまえのこと。

**デフォルトの名無しさん** · 2018/04/07(土) 15:18:00.29

element.value で参照できるものに対して
element.childNodes[0].nodeValue でも参照できますとか
混乱のもとでしかない

オブジェクトの属性が、
オブジェクトが所有するオブジェクトの属性と同じとか
オブジェクト指向が分かってないとしか思えない

**デフォルトの名無しさん** · 2018/04/07(土) 15:24:17.18

>>376
いやだから、<input><calender></calender></input>なんてやって
「この<input type="date">の中身はカレンダーです！」とか宣言できないし、しちゃいけないし、できちゃいけないんですよ
それを決めるのは開発者じゃなくてユーザーです
ユーザーが自分の環境で一番使いやすい入力・表示形式を選びます

あるinput要素にtextContentとして扱える内容があるのかどうか、開発側にはわからない、
ユーザーエージェント依存の部分なので、<input>は空要素でなければなりません。

＞今privateな物をpublicにしただけなんだよ。
だからそこpublicにしちゃダメなんですよ、UAによって何してくるか違うところなんで
開発者はユーザーエージェントがなんであれ、統合的に処理できるようにしなきゃいけないので
あるかどうかもわからないtextContentじゃなくて、どういう形式のフォームが使われるにせよ
確実に存在する"値"のシリアライズ文字列だけをvalueプロパティから取り出して扱うわけです。

**デフォルトの名無しさん** · 2018/04/07(土) 15:27:44.00

>>383
異なるノードから同参照になる例としては、要素ノードと属性ノードがある
後はHTML Standardで反映型属性(正確な用語は忘れた)があって、valueもそれだった記憶がある

**デフォルトの名無しさん** · 2018/04/07(土) 15:41:38.38

>>385
> 後はHTML Standardで反映型属性(正確な用語は忘れた)があって
反映型IDL属性だった
https://teratail.com/questions/86442

いずれにしても重要なのは仕様を正しく理解して使いこなす事であって、仕様が分からない状態でコードを作り上げる事じゃない
彼は分からない道具を組み合わせて、分からないままでコードを書き上げようとしている

createTextRangeを知っていて、代替APIを発見できない検索スキルの低さも問題だが(初心者でも数秒で発見できる)
https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setSelectionRange

**デフォルトの名無しさん** · 2018/04/07(土) 15:51:25.82

>>332
音の大きさとかじゃなくて、単にそのつまみ自体の値が欲しいのよね。
setValueAtTime でオートメーションを GainNode に大量に入れてやるわけだけど、
リリース(音の停止)の時はそれを現在位置でキャンセルして、現在の値からフェードアウトさせる必要がある。
その現在の値(つまり、最後に設定した値)が GainNode.gain.value で取得できないから、何やねんこれはとなってるわけ。

**デフォルトの名無しさん** · 2018/04/07(土) 15:52:59.09

>>385
> 後はHTML Standardで反映型属性(正確な用語は忘れた)があって、valueもそれだった記憶がある
value属性は反映されてなかったので、撤回する
すまん

**デフォルトの名無しさん** · 2018/04/07(土) 15:53:45.66

>>384
> あるかどうかもわからないtextContentじゃなくて、どういう形式のフォームが使われるにせよ
> 確実に存在する"値"のシリアライズ文字列だけをvalueプロパティから取り出して扱うわけです。
そもそも textContent は階層が潰れた文字列だし、
そこに textNode ならそれそのまま、
<calender>ならそれに対して textContent を発行した内容を返せばいいだけだろ。
それがシリアライズ文字列を返すのならそれが返るし、そうじゃない仕様なら空でもいいし。
いずれにしても普通の<div>等のtextContentと矛盾無く同じ並びになると思うが。
あれも多分 childNodes.map(function(v){return v.textContent;}).join(' ') だろ。

俺には何故君が出来ないと思えるのかさっぱり分からない。
ここで与太議論しても何も変わらないから終わりでもいいのだけど、君がこだわる理由も分からない。
当たり前だが、DOMの仕様がクソなのは君のせいじゃない。
あれは見た限り元々OOPじゃなかったのを無理にOOPに乗せようとしてるからおかしな事になってる。
でも多分、方向性としては正しいし、次第に綺麗に整備されていくだろうよ。

**デフォルトの名無しさん** · 2018/04/07(土) 16:01:21.65

> 当たり前だが、DOMの仕様がクソなのは君のせいじゃない。
> あれは見た限り元々OOPじゃなかったのを

ここだけ読んでもほんと頭が悪いなｗ

DOMはDocument Object Modelの略
すなわち「モデル」だ

OOPはobject-oriented programmingの略
すなわち「プログラミング」だ

モデルはでプログラミングじぇねぇ

**デフォルトの名無しさん** · 2018/04/07(土) 16:32:44.95

確かに、DOMはIDLの集合でしかないな
OOPはプログラミングなので、対象が違う

**デフォルトの名無しさん** · 2018/04/07(土) 16:36:10.91

HTMLはぁ～
Javascripとんのためにあるんやないんやでぇ～♪

**デフォルトの名無しさん** · 2018/04/07(土) 16:50:07.71

>>389
＞ここで与太議論しても何も変わらないから
そうですね、あなたがここで何を言おうとあなたの言うような仕様にはならないでしょう

「色データを文字列で表現したもの」と
「色を表すテキスト」は別物ですし、textContentやtextNodeは「色を表すテキスト」にしかなりません。
HTMLの基本構造としてそういうものなので。

<input type="color">が扱うことがわかっているのは「色データそのもの」や「色データを文字列で表現したもの」で、
「色を表すテキスト」を扱うかどうかはブラウザ依存で、開発者にはわかりません。

あなたの言うような仕様だとしたら、ブラウザは
カラーコードをユーザーにそのまま表示している時: "#00a3af"
色そのものしか扱ってない時: ""(空文字列)
ひどい時: "浅葱色"
をtextContentとして返してくるでしょうから、何が返ってくるのかわからないtextContentなんて誰も使わないでしょう。

**デフォルトの名無しさん** · 2018/04/07(土) 17:00:45.23

>>393
> あなたの言うような仕様だとしたら、(中略）
> をtextContentとして返してくるでしょうから、何が返ってくるのかわからないtextContentなんて誰も使わないでしょう。
それでいいと思うが。両方とも。つまり、
・textそのものでない場合はそれなりの文字列で返す仕様でいい。
　まあ普通色ならARGBかWebColorの文字列になると思うが、それは仕様で決めればいい。
・誰も使わなくてもいい。
君は何がそんなに気に障っているのだ？それで誰も困らないだろ？
今できていることが出来なくなるわけでもないし。

**デフォルトの名無しさん** · 2018/04/07(土) 17:01:52.07

> 君は何がそんなに気に障っているのだ？それで誰も困らないだろ？
> 今できていることが出来なくなるわけでもないし。

できなくなるんだから問題だって言ってるだろｗ
人の話聞けよ

**デフォルトの名無しさん** · 2018/04/07(土) 17:07:52.41

>>393
ちょっと言い方が曖昧だった。
多分、色について textContent で内容を取るのなら、
それはそのまま style:color に対して指定できる文字列が仕様としては良いだろう。
だから #xxxxxx とか red とか、まあそれはご存じの通り、で。

**デフォルトの名無しさん** · 2018/04/07(土) 17:10:47.60

>>394
＞・textそのものでない場合はそれなりの文字列で返す仕様でいい。
＞　まあ普通色ならARGBかWebColorの文字列になると思うが、それは仕様で決めればいい。
<input type="color"> が、カラーコードのテキストノードを子要素として持つというのは
img要素が画像データを文字列にシリアライズしたものをテキストノードで子要素に持ったり
audio要素が音声データを文字列にシリアライズしたのものをテキストノードで子要素に持つようなものです。

明らかにHTMLの構造として異常ですから、確実に却下されるでしょう。

**デフォルトの名無しさん** · 2018/04/07(土) 17:19:55.31

>>397
> img要素が画像データを文字列にシリアライズしたものをテキストノードで子要素に持ったり
> audio要素が音声データを文字列にシリアライズしたのものをテキストノードで子要素に持つようなものです。
そこはgetterでしょうに。

**デフォルトの名無しさん** · 2018/04/07(土) 17:25:29.79

またSPAの時みたいに思いこみで話してんの？
というか毎回なの？こいつ。

**デフォルトの名無しさん** · 2018/04/07(土) 17:27:22.22

>>398
textContent は子孫要素のテキストノードをまとめたものを返すものですから、
<input type="color">がtextContentでカラーコードを返すとすれば、
子要素としてカラーコードのテキストを持つということであり、
これはimg要素が画像データを文字列にシリアライズしたものをテキストノードで子要素として直接持っていることに相当します。

これもさっき言いましたが、HTMLとそのDOMにおける"Content"の意味、ちゃんと勉強してくださいね。

**デフォルトの名無しさん** · 2018/04/07(土) 17:27:29.89

あぁ、SPAやろうだったか。
動くコードも書かずにぐちぐちいうだけ
jQuery兄さんの足元にも及ばないな

**デフォルトの名無しさん** · 2018/04/07(土) 17:36:08.31

なんていうか意図的に「文字列」と「テキスト」を混同しているみたいだな
textContentで子孫ノードにないものを返すのはありえないし、
参照するデータのシリアライズ文字列をいちいちテキストノードで保持するというのもこれまたありえない

**デフォルトの名無しさん** · 2018/04/07(土) 18:43:27.70

>>402
だからそこはgetterだろと（2度目）

**デフォルトの名無しさん** · 2018/04/07(土) 19:18:27.37

>>403
お前の提案したAPIだとテキストノードで保持することになるって意味な

**デフォルトの名無しさん** · 2018/04/07(土) 19:19:40.39

>>387
テストしてみたが当たり前に取得できるぞ

**デフォルトの名無しさん** · 2018/04/07(土) 19:21:04.09

>>403
他の人も同じこと思ってるけど、
的はずれな用語を持ち出してきても意味不明なんだよ。

お前の言うgetterがなんなのかわけわからんし、
おそらくお前自身がわかってない。
わかってるというのならgetterとやらでどうなるのか説明してみ

**デフォルトの名無しさん** · 2018/04/07(土) 20:00:16.59

根本的に基礎知識不足がひどいな

>XHTMLではとりあえず終了タグ付けようとしただろ。
全然違う。HTMLとXHTMLの概念は変わらず、空要素も両者ある。
XHTMLは<br />のように「空要素のスラッシュを義務化」しようとしただけ。

>input
オブジェクトを定義するXAMLとかでは<TextBox>value</TextBox>みたいにできるから、できても変ではない。
(ただし、Xamlはあらゆる属性を子要素として記述できるというだけ)

しかし、HTMLは文章の構造を定義するmので、今更変更するメリットはない
>互換性の問題は深刻ではないので
これは間違い。かなり規模のでかい破壊的変更になる。
・親も含めてtextContentやinnerHTMLの結果が変わる
・過去のHTMLの解釈が大幅に変更され、パーサが複雑に
・セキュリティ上の多数の懸念

概念的にもinputは「フォームの部品」であり、それ以上分解できなくても不自然ではない

>Range で統合的に取り扱えるようになる
それは無理。それこそ表示はブラウザに依存するから。IMEの未確定文字などの複雑な概念は単純には処理できない

>getter
意味がよくわからん

**デフォルトの名無しさん** · 2018/04/07(土) 20:06:24.32

Rangeで同じように扱えるようにするだけのために
HTMLを壊そうとしてるんだよなｗ

**デフォルトの名無しさん** · 2018/04/07(土) 20:10:45.55

分かってない君は語彙が変なのが余計にわかりづらさを助長してるな

「ポップアップ」「参照」「参照ポイント」「getter」あたりは世間と認識がだいぶずれてる

**デフォルトの名無しさん** · 2018/04/07(土) 20:35:46.41

>>407
> 空要素についても同様に終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
> 終了タグを付与する <br></br> という表記の場合は、タグの間に空白類文字すら含めてはいけない。
> また、後方互換性のために <br></br> ではなく、<br /> と表記することが推奨されている
> https://ja.wikipedia.org/wiki/Extensible_HyperText_Markup_Language
つまり終了タグ無し要素は無しになってるだろ。
> 「空要素のスラッシュを義務化」
この解釈は矮小化してる。上記参照。

> (ただし、Xamlはあらゆる属性を子要素として記述できるというだけ)
俺は知らんがXAMLの連中はそれの方が一般的でいいと解釈したんだろ。わからんでもないだろ。

> しかし、HTMLは文章の構造を定義するmので、今更変更するメリットはない
そう思うのは勝手だが、XHTMLとかも要するにAltHTMLだろ。
HTMLもJavaScriptも色々糞な所はあるんだよ。(HTMLそのものというよりはDOMだが)
ただ、両方とも我慢できないほどではないから現状があるわけで。
> パーサが複雑に
これはない。単純になる。

> 概念的にもinputは「フォームの部品」であり、それ以上分解できなくても不自然ではない
<input type="text">についてもそう思うか？

> IMEの未確定文字などの複雑な概念は単純には処理できない
そんなに複雑だと思うか？
俺が試した限り、未確定文字もインクリメンタルサーチに当たるから、単純に、
・未確定文字も「入力されている」扱い
・確定時に該当部分を消して書き直しているだけ
っぽいぞ。少なくともvalueと見た目からはそう見える。
まあこれは余談だが。

> 意味がよくわからん
お前もかよ

**デフォルトの名無しさん** · 2018/04/07(土) 20:43:14.47

> これはない。単純になる。

それはない。複雑になる。

**デフォルトの名無しさん** · 2018/04/07(土) 20:45:19.21

属性を子要素にするとか何も分かってない

まず属性は複数ある。

<input value="a" type="text">
この場合、typeも子要素になる。
valueとtypeの両方が子要素になってしまう。

**デフォルトの名無しさん** · 2018/04/07(土) 20:46:47.05

>>410
＞つまり終了タグ無し要素は無しになってるだろ。
終了タグとか関係なしに、内容を持たない「空要素」という概念があって、
は？　どこをどう読んだらそういう解釈になるのか。文盲？
空要素という概念が先にあって、表記形式として<br></br>か<br />のどっちか使えってだけで
XHTMLでは空要素にとって終了タグがあるかどうかなんて　ど　う　で　も　い　い　ってことなんだけど
終了タグも<br />も空要素の表現手法であって、空要素が主、タグは従

タグにやたらこだわってるあたり、本当にWebの基礎の基礎がわかってないんじゃない？
タグなんて要素を表現する書式でしかないんだから、XHTMLでスラッシュが義務化されようが
終了タグが容認されようが、「空要素」という概念自体には何の関係もないよ

＞そんなに複雑だと思うか？
＞俺が試した限り、未確定文字もインクリメンタルサーチに当たるから、単純に、
だからー、それユーザーの環境によって違うのね
ユーザーによってデバイスもOSもブラウザも入力メソッドも何もかもバラバラ
お前の環境ではそうだった、っていうのはお前の環境ではそうっていう以上のものではないので、この議論に無意味

お前Webでユーザーの環境を開発者が決定できると勘違いしてるんじゃね？

**デフォルトの名無しさん** · 2018/04/07(土) 20:48:02.82

>>413
行がちょっとずれたけど、2行目は5行目の前あたりに入れて読んでねー

**デフォルトの名無しさん** · 2018/04/07(土) 20:49:49.80

>>413
了解。お前は文盲と理解した。お前とのレスもこれまで。

**デフォルトの名無しさん** · 2018/04/07(土) 20:53:55.19

>>415
＞＞空要素についても同様に終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
＞終了タグ無し要素は無しになってるだろ。
文盲はあなたですよねー、

＞終了タグを付与するか、開始タグの末尾を「/>」としなければならない。
いいですか。"終了タグを付与する」" OR "開始タグの末尾を「/>」とする"のどっちかをやれって言ってるわけだよ
"開始タグの末尾を「/>」とすれば、終了タグはなくてもいい"って言ってんの

終了タグ無し要素は無しって何？

**デフォルトの名無しさん** · 2018/04/07(土) 20:54:26.50

分かってない君の敗北宣言出たから勝負ありだね

**デフォルトの名無しさん** · 2018/04/07(土) 21:02:05.48

空要素は終了タグつけるか、終了タグなしなら /> で開始タグを閉じてね
どっちかといえば終了タグなしの /> が推奨だヨ

っていうテキストを読んで「終了タグ無し要素は無しになってる」とか本気で文盲としか思えん

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

しかもなーんで引用するのがw3cじゃなくてWikipediaなんですかねえ
もしかして上級者気取りで仕様書程度の英語も読めない感じ？

https://www.w3.org/TR/xhtml1/#h-4.6
以下引用、括弧内は引用者訳

4.3. For non-empty elements, end tags are required
(空でない要素は終了タグが必須です)

4.6. Empty Elements
Empty elements must either have an end tag or the start tag must end with />.
(空要素は終了タグを持つか、開始タグが /> で終了するか、どちらか一方が必要です。)