+ 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/03/28(水) 19:34:04.98

>>281
> まあ別にそのバーをデザイン上の問題でどうしても透明にしようが何れにせよ
> テキストとは別にDnD可能領域をつけることでできるよ
それは分かっているし、実際 autohide のタイトルバーも採用するつもりでいる。
ただし別件でだが。

> テキストの部分触ってもDnDできなくて、その周りの空白部分でDnDできるとか分かりにくいし
これで十分なんだよ。
カーソルが「文字選択」なら文字選択になるし、「それ以外」なら移動になる。
必要なら「移動」カーソルに変えておいてもいい。だったら見たとおりにしかならんだろ。
そもそもこの切り替えも付けるし。（全面移動か、上記自動切り替えか）
なお、デザイン上、余白部分はかなりあるから、つまむのに苦労するということはない。

というか「余白」という曖昧な表現を使っているから不味いのか？
例えば、PDF文書なら、通常左右の端から3cmずつくらいは必ず「余白」になってるだろ。
そして文字選択する場合、必ず当該文字の真上から開始するのだから、あれも単純に、
・文字領域の上からDnDを開始した場合、文字選択
・左右の余白領域の上からDnDを開始した場合、「手のひらツール」で文書そのものの移動
でよかったと思うんだよ。それでカーソル形状を変化させてれば、混乱しようもない。

**デフォルトの名無しさん** · 2018/03/28(水) 19:35:25.71

ポップアップが巨大で１画面の高さを超えることもあるから、タイトルバーでは駄目だというのもある。
例えば2chで同一IDや返信をポップアップするとして、数が多ければ１画面の高さを越えるだろ？
これと同じ。俺も必要なだけ出すから。これに対する解は、

A. ポップアップにタイトルバーとスクロールバーを装備（正規ウインドウ化）
B. ポップアップを元画面に固定、元画面のスクロールによってスクロールさせる…大体の2chブラウザがこれ
C. ポップアップ自体に移動/スクロール機能を付ける…現状だが文字選択が出来ない
D. Cに対して自動切り替え機能を導入し、文字選択できるようにする…これをやろうとしている

なんだよ。君がA推しなのはいいし、実際そうしているアプリもある。
ただ、今俺が試したいのはDなんだよ。多分混乱はしないし、一番いい解だと思うから。
Bは、元画面をそこまでしか読んでいないのに、
ポップアップを読む為にスクロールして、戻ってこないといけないのがウザイ。
Aは、ポップアップとしては不味いＵＩだと思っている。
ポップアップはタイトルバー等がないことによって「不完全なウインドウ」であることを明確にしている。
そしてそれは「不完全」だからこそ、自動消滅するということで辻褄が合っている。
「完全な」ウインドウが自動消滅するようでは不味いんだよ。俺はそこは、

・タイトルバー等を装備した「完全な」ウインドウは永続的であり、明示的消去動作のみによって消去される
・「不完全な」ウインドウは、自動消滅する

という、分かりやすいラインに従うべきだと思っている。
ポップアップを移動させたいが為だけでタイトルバーを付けてこの原則を崩すのは悪手だ。

ということを言い出してもきりがない。
所詮はGUIは感性の産物でユーザー主観でしかない。
だから全部実装してユーザ選択にするのがベストだし、最終的には多分そうする。
そして今回はDを実装して試そうとしているだけ。

**デフォルトの名無しさん** · 2018/03/28(水) 19:36:37.06

>>283
> TextNodeはDOMの仕組み的にElementじゃない
見た目そんな感じだね。

> 持つべきではない
そんなわけない。TextNodeがTextElementであっても何も問題ないだろ。

> 普通に<span>とかのインライン要素で囲めば判定できる
出来ない。正確に言うと、出来ることを保証できない。
<span>で囲んだだけでCSSでは別扱いでき、フォントサイズ等が変更される可能性もある。
だからこの方法では「出来るときもある」だけであり、「出来る」というのは間違い。
ただなるべく無駄なことはしたくないので、DOM変更で対応するのは最後になる。
あと、この方法だと結局長方形としてしか扱えず、
複数行で最終行だけ短いとき等にも対応できない。
ブラウザ自身はこういう場合も問題なく当たり判定して、文字の上の時だけカーソルを変えている。

> 使いにくい人もいるだろうね
どのみちユーザ選択にするから問題ない。

> 長押しで移動モード
これはかなり最悪。ゆっくり選択することが出来なくなる。
右クリックメニューで「移動」「選択」モードの明示的切り替えの方がマシ。

今のところmousemove/downをdispatchEventしてSelectionが変化するか見ようとしているが、
反応しねえ。

**デフォルトの名無しさん** · 2018/03/28(水) 22:56:50.85

Canvasに描画すればmeasureTextできるから、努力すれば各行の幅が取れる

もしくはSVGのforeignObjectにスタイルなどを適切に適応したポップアップ部分の複製を入れて
テキスト背景色などを調整した上Canvasに描画して当たり判定をする

**デフォルトの名無しさん** · 2018/03/28(水) 23:26:57.64

適用な

**デフォルトの名無しさん** · 2018/03/29(木) 01:17:47.41

Range.getClientRects()で出来そうだ。
知恵を貸してくれた皆様ありがとう。

**デフォルトの名無しさん** · 2018/03/30(金) 12:37:48.86

Houdini v2でテキスト周りの処理ができるようになればいいね

**デフォルトの名無しさん** · 2018/03/30(金) 22:24:23.40

いや何のことだ？

Range.getClientRects()では文字単位でピクセル値も出せるから、当たり判定は問題なく出来た。
結局の所、俺がRangeを知らなかっただけだった。最初からこれでよかった。
というか、一般的にテキストの当たり判定は出来ないので、HTMLでもそうだと思いこんでいた。
なんだかんだでHTML周りはよくできている。（他のＧＵＩに比べて）

これについては、これまで何回か聞く人もいて、>>287とずっと言われてたろ。
まあ俺もそう思っていたのだが、実はそうじゃなかった、というわけさ。
互換表を見る限り目新しいAPIというわけではなさそうだが、
普通は使わないから知名度が低いのも致し方無しか。

ちなみにuhyohyoでは解説されてる。
https://uhyohyo.net/javascript/8_1.html
正直俺はこのサイトの書き方は嫌いなのだが、ここの内容はいい。
こいつは少なくともある程度以上の腕だというのが読んでいても分かる。
JavaScriptを解説しているサイトって、初心者が一生懸命やった記録を残しました、
みたいなところばかりで、ポイントがずれているから、ミスリードされる。
この辺を自分で判別できない初心者ならuhyohyoを全部読むのもありだと思うぞ。
（結果的には俺がそうすべきだったわけだが)

RangeはNodeをElementにキャストできる。（意味的に）
だからNodeがElementの親でメソッドが足りない、という点はほぼ全て回避できるはず。
本来の使い方か？といわれたら微妙だが。

**デフォルトの名無しさん** · 2018/03/31(土) 20:30:23.50

残念だけどこれじゃ添字などに完璧に対応できてるわけじゃない
たまたま日本語だから上手く言ってるように見えるだけ

**デフォルトの名無しさん** · 2018/03/31(土) 21:02:26.43

カーソルの形状も文字の選択もマウスに依存したUIだから、タッチデバイスとかで使う人がいるなら相当気をつけて実装しないとまずかったりもする

**デフォルトの名無しさん** · 2018/04/01(日) 12:20:15.96

jplayerっていう動画とか音声を再生するプレイヤーが
再生終了後に広告載ようとしてるのですが、
class名=jp-video-playのとこにリンク付きのimgを入れたんだけど
何故か、クリックしてもa hrefの無効になってるみたい。
a hrefが無効ってvoid(0)とかしかないと思ってるんですが、
jquery.jplayer.jsを読んでもさっぱりわかりません。
jp-video-playがshow()とhide()してるだけでした。
a hrefが無効って何が原因なんでしょうか？

<div class="jp-video-play">
<a href="https://www.yahoo.co.jp/";><img src="C9GWegFV0AA_j_m.jpg" width="150px" id ="a03" class="test2" /></a>
</div>

**デフォルトの名無しさん** · 2018/04/01(日) 14:52:16.87

>>294
とりあえず、開発者ツールでa hrefの実際の値を確認
書き換えられてなければ、イベントでpreventDefaultされてるんじゃない？

**デフォルトの名無しさん** · 2018/04/01(日) 17:34:00.52

>>295
解決しました。ありがとうございました。

a hrefは書き換えはされていませんでした。
preventDefaultがされていたのが原因でした。
preventDefaultって機能の存在を知りませんでした。

jquery.jplayer.js
var handler = function(e) {
e.preventDefault();
};

**デフォルトの名無しさん** · 2018/04/02(月) 21:19:50.07

>>292
どういうケースを想定しているのか知らんが、
字毎のboundingBox(＝マウスでなぞったときに反転するエリアのはず）が取れるから、
全て対応できると思うぞ。

気になるuniコードがあればこちらで試してみてもいいが。

**デフォルトの名無しさん** · 2018/04/03(火) 22:37:13.67

>>297
言語やフォントやモードによっては日本語のぶら下がりのような禁則処理なんかで
ボックスからはみ出す場合もある

**デフォルトの名無しさん** · 2018/04/04(水) 00:42:30.57

>>298
そう信じるのはお前の自由

**デフォルトの名無しさん** · 2018/04/04(水) 06:18:39.49

オートハイフネーションのハイフンも取得できるの？

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

俺の環境でちょっと試した限り動いているぞ。

ページはMDNのCSSサンプルページからで、ちょっとfiddleで試した。
https://developer.mozilla.org/ja/docs/Web/CSS/hyphens
https://jsfiddle.net/qznatw8y/10/

・chromeではそもそも3例ともハイフンが表示されない
・FFでは3例目(auto)だけ自動挿入されてる (An ex"-"tremely long English word)

なので対象は3例目のこのハイフンであり、結果は以下で、right==93はハイフンを含んでいる。

DOMRect { x: 49, y: 349.1000061035156, width: 44, height: 18, top: 349.1000061035156, right: 93, bottom: 367.1000061035156, left: 49 } _display:108:23
07:20:27.560 DOMRect { x: 49, y: 368.1000061035156, width: 50, height: 18, top: 368.1000061035156, right: 99, bottom: 386.1000061035156, left: 49 } _display:108:23
07:20:27.562 DOMRect { x: 49, y: 387.1000061035156, width: 29, height: 18, top: 387.1000061035156, right: 78, bottom: 405.1000061035156, left: 49 } _display:108:23
07:20:27.564 DOMRect { x: 49, y: 406.1000061035156, width: 51, height: 18, top: 406.1000061035156, right: 100, bottom: 424.1000061035156, left: 49 } _display:108:23
07:20:27.568 DOMRect { x: 49, y: 425.1000061035156, width: 34, height: 18, top: 425.1000061035156, right: 83, bottom: 443.1000061035156, left: 49 }

**デフォルトの名無しさん** · 2018/04/04(水) 20:34:23.73

Androidのテキストレンダリング周りの処理見たことがあるけど
多分アラビア語とかになるんだろうけどマージンがある場合はBOXをはみ出して描画するようになってたと思う
BOX≒選択範囲だけどBOX≒描画範囲ではないからね
続け字が連続してきて何度もフォント設定の置換が入るとBOXがズレる仕様バグが残ってるし

**デフォルトの名無しさん** · 2018/04/04(水) 21:06:00.71

>>302
「続け字」というのは詳しく知らんが、英語の筆記体のようなものだとすると、
それは文字間の区切りが曖昧なだけであって、最終結果のBoundingBoxをはみ出る理由にはならんだろ。
君が何故出来ないことにしたいのか分からんが、
レンダリングしている物(ブラウザ)が返してきている値なんだから普通は問題なく信用できるし、
ブラウザにバグがあるというのならそれはまた別の話だ。

仕様バグ、というのも何が言いたいのか分からんが、
BondingBoxに仕様バグも糞もない。
「表示領域を囲んだ矩形を返せ」以外の仕様なんてないし。

**デフォルトの名無しさん** · 2018/04/04(水) 23:46:26.22

そういやrtlな言語だとどうなるんだろ？

**デフォルトの名無しさん** · 2018/04/05(木) 00:22:41.54

アラビア語かな？

**デフォルトの名無しさん** · 2018/04/05(木) 06:20:49.74

BoundingBoxは表示領域とは違うからな

**デフォルトの名無しさん** · 2018/04/05(木) 19:04:44.78

スレ違いとは思いますがAcrobatのJavascript APIについてこちらで質問してもいいでしょうか？

**デフォルトの名無しさん** · 2018/04/05(木) 21:35:42.76

input要素内部のテキストの幅を知りたいのだが、どうすればいい？

テキストの幅が取れることが分かったので、
ついでに間延びしている<input type="text'>について、
入力後にちょうどいい幅まで縮めようとしている。
前回ググッた時に見かけた覚えがあったのでだいぶ探してみたが、
どうやらcreateTextRange(IE専用）だったようだ。
chromeでやれる方法を知っている人がいれば教えて。
あるいはCSSで出来るというオチある？

見た目これはAPIを整備中、というところかな？
HTMLInputElementの継承とか見ると、オブジェクト指向しようとしている。
https://developer.mozilla.org/ja/docs/Web/API/HTMLInputElement
なら内部文字列は textNode 扱いで Range 経由で取得というのが妥当だが、
<input>自体がHTML的に中途半端(終了タグがない等）だから、整備中か？

なおjQueryUI等にこの機能を持っている物があればそれも教えてくれれば助かる。
参考に見に行く。

基本的には、フォーカスが当たったらちょっと伸びて、
フォーカスが外れたら入力文字列をちょうど表示しているところまで縮めたい。
ただし span 等に変更することはなく、inputのままで、だ。
span 等に変更すると、見た目、入力が出来ないのか？と勘違いされそうなので。
なお selection -> range -> getBoundingClientRect等で取得は試したが駄目だった。

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

こいつほんと馬鹿だな
そもそもinput要素がどのように表示されるか厳密に決まっているわけではない
環境に応じて調整されたUIが表示ができるようにするための専用要素なのだから
それを細かく調整しようと思うこと自体が誤り

**デフォルトの名無しさん** · 2018/04/06(金) 08:53:01.27

訳：わかりませんｗ
分からないなら黙ってればいいのに

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

裏で不可視状態で同じフォント、同じサイズ、同じ文字列のspan作ってDOMの適当なところに挿入
文字列の幅を取得してすぐDOMから削除でいいのでは

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

>>309
そんな的外れなことばかり言ってるからJavaScripterは馬鹿なままなんだよ。
お前らは何が正しいかすら理解できていない。
そしてそれすら自覚できてないから間違った情報を拡散し、余計に馬鹿が再生産されてる。
それは本当に止めた方がいい。

環境依存の部分を自動的に隠蔽したいのなら、<span>と同様、自動伸縮すればいいだけ。
手動でやれというのなら、通常のオブジェクト指向のように、統合的に扱えればいいだけ。
<input type="text"></input>で入力が内部textNodeになれば、それが出来るだろ。
Webの場合はこの辺の「統合的」な視点が全く欠けており、三流プログラマのやり方になっている。
そしてそれしか知らないから「jQueryは素晴らしいとか」とか明らかに間違ったことを言い出す。
そもそもjQueryみたいなグルーライブラリが必要なこと自体が間違っているし、
実際他環境ではそんな物は必要ないんだよ。お前らは知らないのだろうけど。
とはいえHTMLは全体的にはよくできているのも事実だが。
(そして俺は今回はscrollWidthで解決できてしまえそうだ)

余談だが、よく言われている「上級者はコードが短い」というのは、これなんだよ。
お前らはjQueryみたいな糖衣構文を使って短くすることしか出来ないからそうだと言い張っているが、
或いは宣言的に書くから短くなる、ということにして関数型()マンセーしているが、
それは自ら馬鹿であると主張しているのと同じだ。
上級者は同じ記述スタイルでも書くコードが少なくて済むんだよ。

ただこれを説明するのは難しかったのだが、Webには分かりやすい例がある事に気づいた。
要するに、上級者のコードには無駄な if が無いんだよ。
よく言われているブラウザの互換性の問題では、無駄に if 文を書く必要があるだろ。
当然、統一しておいてくれよな、と思ったことはあるだろ。余分なコードが無くて済むから。

同じなんだよ。上級者のコードでは内部的な互換性が高く、いちいち処理を分ける必要がない。
余分なコードがないから、コードが短くなる。
糖衣構文で短くなっているわけではない。
ただ、この違いを理解できない馬鹿が一文字一句の「コードの短さ」のみを主張しているだけでね。

**デフォルトの名無しさん** · 2018/04/06(金) 20:58:32.51

>>311
それは回りくどすぎる。というか悪いがその方法なら俺も当然知ってる。
というかな、上記にも絡むが、

・一通り出来ない＝初級者
・一通り出来る＝中級者　←お前ら
・最適なやり方を選択できる＝上級者

なんだよ。
何かお題が与えられたとして、やり方が分からない>>309は初級者。
とにかく実現は出来る>>311は中級者。多分お前らはここが多い。
ただ、本当にそれが最適か考えないと、上級者にはなれない。お前らはこれを怠っているから上達しない。

今回、「本来の」順で考えるなら、
A. CSSに何かプロパティを設定したら、勝手に伸縮する (例；逆だが text-overflow: ellipsis 等）
B. 直接クエリできるメソッドを使う (例: createTextRange、ただしIE専用)
C. input自体の幅を変更して計測する
D. inputをcloneNodeして中身をコピーし、その場に貼り、不可視で計測する
E. spanに中身をコピーし、styleも全コピーし、どこかに貼り、不可視で計測する
だろ。styleのコピーがいる分EはDより面倒で「コードが増える。」
逆に言えばこれがないから「上級者のコードは短い」んだよ。糖衣構文で短いのではなくてね。
ＣはDよりもさらに簡単で、いったん width='0px' にすれば scrollWidth で幅が取れるというもの。
可視状態でやっていいのか？というのはあるが、現実的に問題なさそうだからこれで行く予定。

それとは別に、A, B が存在する可能性もあるから聞いたんだ。俺は仕様に詳しいわけではないから。
ただこれも、環境が整えば当然のごとく A, B が出来るようになるわけだが、
お前らはこれが出来るべきだとも理解できてないからおかしな事になってる。
糞な仕様につき合っており、それで満足してしまっていて、問題を感じていない。
ちゃんと「本来はどうあるべきなのか」を考えるようにしないと上達しない。

**デフォルトの名無しさん** · 2018/04/06(金) 21:00:52.27

IE専用ｗｗｗ

**デフォルトの名無しさん** · 2018/04/06(金) 21:42:16.24

>>312
アホ
input要素が具体的にどのようなUIで表示されるかはHTMLの仕様外なんだよ
内部に入力テキストが表示されている必要も無いのだから
それに依存した動作をしようとすること自体がナンセンス

例えるなら右クリックメニューの内容に応じて何かをしたいと言ってるようなもの
それがどうしてもしたいならむしろ右クリックメニューを作れと言ってるんだよ
当たり前だろ

**デフォルトの名無しさん** · 2018/04/06(金) 21:51:01.44

この長文の人の明後日のモチベーションはどこからくるの？

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

jQuery兄さんに対抗してるんだろう

**デフォルトの名無しさん** · 2018/04/06(金) 22:26:12.66

jQuery兄さんは黙って実装コードを提示する
いろいろ言い訳してるやつとはレベルが違う

**デフォルトの名無しさん** · 2018/04/06(金) 22:53:48.94

>>315
お前がそう思うのはお前の自由。
俺はそういうお前らが駆逐される日が来ることを願っている。

お前を含めて、JavaScript界隈には間違っていることを平気で垂れ流す奴が多すぎる。
それでお互いの足を引っ張り合っていて、結果的にお前らは本来あるべきレベルにも達していない。
俺は多少でもそれを是正し、結果的に次世代の成長を早め、（というより本来の成長速度に戻し）
結果的にお前らが駆逐される日が来るように誘導している。

**デフォルトの名無しさん** · 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 でも参照できますとか
混乱のもとでしかない

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