+ 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/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 />.
(空要素は終了タグを持つか、開始タグが /> で終了するか、どちらか一方が必要です。)

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

>>407
つかXAMLってWPFかよ。以下読んだ。
https://docs.microsoft.com/ja-jp/dotnet/framework/wpf/advanced/xaml-overview-wpf

見た目、以下か。
・終了タグ必須
・textNodeなし、絶対にタグで囲め
・case sensitive

まあ確かにHTMLを参考に作ったんだからこうなるわな。仕様としては妥当だ。
とはいえ冗長だし、人間が書く用ではないが。
.（ドット）で明示的にプロパティと分かるようになっているね。
確かにこれの方がいい。

ただ個人的には、XAMLとか中途半端なことをせず、
WPFはHTMLを全面採用した方がいいとは思ったが。

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

>>420
え？お前マジでそれいってんの？
知識なさすぎるだろｗ

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

1つ目

> つかXAMLってWPFかよ。
XAMLはXAML、WPFとともに作られたがWPFではない
実際にXamarinでも使われている

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

>>405
ほんと？情報ありがとう。
じゃあ Firefox の実装が変なんかな。
どんなに
GainNode.gain.value = v;
なり
GainNode.gain.setValueAtTime(v, t);
なりで指定しても GainNode.gain.value が 0.1400049 みたいな固定の値しか返してくれないんだ。
初期値(=1)でもないし、なんじゃその値は。
自分のためにつくってるプログラムだから Firefox でないと意味ないし…。まあ別の方法でリリース制御はできたからいいけど。

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

2つ目

> 見た目、以下か。
名前からXAMLはXMLの一種だと気づけ
そもそもXMLにはHTMLという決まったタグはなく
タグを仕様として作ってから使うもの、その仕様の一つがXAML

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

3つ目
> ・終了タグ必須
XMLなんだから当たり前

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

4つ目

> ・textNodeなし、絶対にタグで囲め
XMLなんだからtextNodeある

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

4つ目

> ・case sensitive
XMLなんだから当たり前

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

6つ目

> まあ確かにHTMLを参考に作ったんだからこうなるわな。仕様としては妥当だ。
XMLをベースに作った。HTMLは関係ない

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

7つ目

> とはいえ冗長だし、人間が書く用ではないが。

人間でも読み書きしやすい

> http://ytabuchi.hatenablog.com/entry/2017/01/04/160000
> 新年一発目は XAML Previewer についてです。Xamarin.Forms の XAML は手書きする必要があります。

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

8つ目

> ただ個人的には、XAMLとか中途半端なことをせず、
> WPFはHTMLを全面採用した方がいいとは思ったが。

HTMLはタグセットが決まってるのでそんな事はできない

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

ほんとひどいわｗ
1レスでいくつ突っ込めば良いんだか

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

> ID:C4tJt4pN
いろいろ、お疲れ様(大変だな…)

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

そもそも属性を要素とみなしてしまえばRangeで扱えるようになるとか言ってるが
今まで属性はRangeに含まれていなかったのに、勝手に含まれるようになれば
互換性が壊れるって分からんのかね？

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

この人HTMLを<tag attribute="属性値">内容</tag>みたいな書式のことだと思ってるのでは

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

>つまり終了タグ無し要素は無しになってるだろ。
空要素の記述方法が、XMLでは<hoge></hoge>か<hoge />とする。HTML5では<hoge>とすることになっただけ
パース後の内部表現は同じ

>XHTMLとかも要するにAltHTMLだろ
すでにhtml5が発行されて、議論は終結した。

>パーサ
例えば、こういうコードがすでに存在するとする。
<input value="aaa">bbb</input>
現在はXMLとして書くと「<input value="aaa" />bbb」となるが仕様変更すると「<input value="aaa">bbb</input>」となり、解釈が変わってしまう

>未確定文字
とりあえず、WindowsのIME関連のAPIを調べてみればわかるけど、かなり複雑な部類
スマホの横持ちとかでは、全画面が入力欄になったり、音声入力があったり、将来的な変化も見込まれる

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

JavaScriptやDOMに疎いのはまだしも、XMLの知識がおかしいのは流石に現代プログラマーとしてヤバさを感じる

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

>>435
> 例えば、こういうコードがすでに存在するとする。
> <input value="aaa">bbb</input>
> 現在はXMLとして書くと「<input value="aaa" />bbb」となるが
これは本当なのか？この記述をしているところのソースくれ。
なお俺はこれは間違っていると思うぞ。
俺は　/>　で閉じて良いのは中身がないときだけであり、
中身がある場合は常に閉じタグ</input>を使わなければならない、と理解している。
勿論、ご指摘のように、俺はXML専門家ではないが。

> とりあえず、WindowsのIME関連のAPIを調べてみればわかるけど、かなり複雑な部類
> スマホの横持ちとかでは、全画面が入力欄になったり、音声入力があったり、将来的な変化も見込まれる
それで？
未確定文字は結局の所、
・未確定でも値に反映して確定後に書き直す…俺の環境
・確定するまでは値に反映しない
のどちらかしか無いと思うが。

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

>>435
> 現在はXMLとして書くと「<input value="aaa" />bbb」となるが
HTML parserで動かしてないか？
XML parserならSynraxErrorになりそうだが、Content-Typeは正しく指定されてるのかね…

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

>>437
ソース以前に動かしてみては？

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

後方互換性の話かと
現在のHTML5では、<input>要素に終了タグを書いても無視されるので

<p>xxx<input value="aaa">bbb</input></p>
のパース後のDOMは
p
├xxx : テキストノード
├input value="aaa": HTMLInputElement
└bbb: テキストノード

これをXMLで表記すると　<p>xxx<input value="aaa" />bbb</p>

仮にHTMLがinputをnon-emptyとして扱うするように仕様変更すると、パース後のDOMが変わり
p
├xxx : テキストノード
└input value="aaa": HTMLInputElement
　　└ bbb: テキストノード

仕様変更の前後どちらの文書なのか検出してパーサを変えなきゃいけない。
ブラウザはバリデータではないから、間違ったマークアップが施された文書だからって無視するわけにはいかない。

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

>>439
おｋ。動かしてみたが再現した。
詳細は>>440の通り、今のDomParserだと</input>を無視するからだね。

>>440
> 仕様変更の前後どちらの文書なのか検出してパーサを変えなきゃいけない。
それはお約束がド頭に付いていることになってるから問題ないだろ。

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

>>441
＞それはお約束がド頭に付いていることになってるから問題ないだろ。
HTML5にはつかない。
HTML5にはDTDがないので

<!DOCTYPE html>

としか書かれていない。仕様変更の前後を識別できない。

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

>>442
ならHTML6には付ければいいだけの話だろ。

**デフォルトの名無しさん** · 2018/04/08(日) 00:09:15.29

>>443
HTMLは4.01以前と違ってそうやって大きくバージョンを区切る方式を取りやめ
HTML Living Standard として日々更新を続けるようになりました。

HTML1.0→2.0→3.2→4.01のような大々的変更を移行期間を取って行うのではなくて、
日々少しずつ更新される HTML Living Standard に追従してブラウザは機能を実装し、
ある程度の段階でマイナーバージョンとしてw3cが勧告を出す、という流れになっています

ですから、文書のパース結果のDOMが変わるような大々的変更はしばらく行われることはないでしょう。

**デフォルトの名無しさん** · 2018/04/08(日) 00:09:47.27

>>437
未確定文字は、実装依存で各ブラウザによって動作がかなり違う
ブラウザはもちろん、OS、デバイス、デバイスの状態、IME、IMEの設定などに左右されるので対応困難
求めるものにもよるけど、現状のなんとなくvalueを見るが限度。「Range で統合的に取り扱う」なんてのは結局実現できない

もっと変なことをしたいなら、オンラインのエディタとかVSCodeとかをみてみるといいよ。苦しいながら、実装はしてある

DOMパーサの破壊的変更は過去のブラウザやパーサが全滅するわけで、相当の理由と議論がなければ無理。
refererのスペルミスを直せレベルのハイリスク・ノーリターン

**デフォルトの名無しさん** · 2018/04/08(日) 00:25:59.31

2chで知りたいことがあったら知ったかぶりしていい加減なことを言えばいいというのは本当だな

**デフォルトの名無しさん** · 2018/04/08(日) 00:39:24.70

>>441
> 詳細は>>440の通り、今のDomParserだと</input>を無視するからだね。

今のDomParserというが、HTML5では仕様化された。

なんと現実に存在する動きに合わせて仕様が作られ
間違ったHTMLであっても、どのブラウザでも同じように表示されるように
間違ったHTMLをどのように解釈するかが仕様化された

**デフォルトの名無しさん** · 2018/04/08(日) 00:39:48.62

訂正なんと現実に存在するブラウザの動きに合わせて仕様が作られ

**デフォルトの名無しさん** · 2018/04/08(日) 00:46:38.70

>>440
なるほどね、HTML parserでXHTMLを読み込ませたケースを想定しているのか

> ブラウザはバリデータではないから、間違ったマークアップが施された文書だからって無視するわけにはいかない。
いや、XHTML parserなら正しく文法エラーをはねるよ
HTML parserが文法違反に寛容なだけ

**デフォルトの名無しさん** · 2018/04/08(日) 00:48:51.56

>>442
というか、Content-Typeでparserを振り分けてるから、bodyを読み込んだ後でparser分岐が発生する仕様にすると遅すぎるよね

**デフォルトの名無しさん** · 2018/04/08(日) 00:52:09.01

html5のDOCTYPEはこのように短い。 <!DOCTYPE html>

html4まではこのように長かった。だがこれが正式な書き方だった。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd";>

なぜhtml5ではこのように短くなったか？それは単に長いという理由の他に
IE6では当時は間違った書き方である <!DOCTYPE html>でも標準準拠モードとして
扱うという仕様だったため、ならもうhtmlだけでいいじゃん、動くしｗｗｗ
という理由でこうなった

また、metaタグによるcharsetの正しい指定方法は本来これ

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
contentが属性であり、その中に値として "text/html; charset=utf-8" と書かなければいけなかった
html5では<meta charset="utf-8">だけで良い。

なぜこのような仕様になったか？それは間違ったHTMLでも
それなりに解釈してあげるよというそれはIE6のおせっかい機能を仕様にしたものだった。

iE6のおせっかい解釈

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
↓ http-equiv 書かないやついるかもしれないだろ？
<meta content="text/html; charset=utf-8">
↓ ダブルクォートでくくらないやついるかも知れないだろ？
<meta content=text/html; charset=utf-8>
↓ content 書かないやついるかもしれないだろ？
<meta charset=utf-8>
↓
よし、これでIE6動くんだから、これをHTML5の仕様にしてしまおうぜ！
HTML5の仕様を考えたやつはいい意味で頭がおかしい。
かくしてHTML5は間違ったHTMLを解釈する方法が仕様化された

**デフォルトの名無しさん** · 2018/04/08(日) 00:58:14.62

>>449
> いや、XHTML parserなら正しく文法エラーをはねるよ
> HTML parserが文法違反に寛容なだけ

XHTMLはXMLをベースとしてしたから、XMLとして
正しくなければ描画できない。

これはどのブラウザでも同じように解釈させるため
間違った書き方を排除することで、どのブラウザでも
同じように描画できるようになるはずだった。

だが現実には単にエラーになるHTMLばかりで
手間がかかるだけで何もメリットを生み出さなかった

それをよこめにブラウザベンダーXHTMLではなく
現実的な回答をHTML5という形で実現させた。

それが間違ったHTMLを解釈するための仕様だ。
これにより、HTML5は文法違反であっても
どのブラウザでも同じように解釈されるようになった

今は文法違反を単に無視するのではない、
文法違反は仕様どおりに解釈するのだ

**デフォルトの名無しさん** · 2018/04/08(日) 01:00:34.14

2018年に「HTML6」なんてワードがITエンジニアの口から出てきたらそれだけで採用面接落とされるよ

**デフォルトの名無しさん** · 2018/04/08(日) 02:37:17.99

>>452
HTML StandardはXML parserも定義しているわけで、XMLが完全に排除されたわけではないけどね
選択の自由はユーザにある

**デフォルトの名無しさん** · 2018/04/08(日) 08:42:00.29

>>423
例えばGainへの接続を切ったり、その前のノードを止めたりして
Gainへデータが流れていないとvalueは変わらないぞ

**デフォルトの名無しさん** · 2018/04/08(日) 21:52:46.54

Javaの教祖マーティン・ファウラー御大、名著「リファクタリング」第２版にJavaではなくJavascript を採用してしまうｗｗｗｗｗ
https://martinfowler.com/articles/201803-refactoring-2nd-ed.html

**デフォルトの名無しさん** · 2018/04/08(日) 22:32:39.78

>>456
「Choosing JavaScript was deeply ironic for me, as many readers may know, I'm not a fan of it. [2] It has too many awkward edge cases and clunky idioms. 」

**デフォルトの名無しさん** · 2018/04/09(月) 01:47:06.19

but still has annoying holes that are built into the fabric of the language from its earliest days.

**デフォルトの名無しさん** · 2018/04/09(月) 01:53:52.04

嫌いだけどそうせざるを得ないんだろうマーケティング的に。今更Javaの本書いてもなぁ。
かと言ってC#かというとう～ん。
消去法でこれしかないじゃん。
でもマーチンファウラーが書くとなるとクラスベースオブジェクト指向だろうな。クラスベース構文や方法論嫌ってるやつも多いjavascriptコミュニティでの受け取られ方やいかに。

**デフォルトの名無しさん** · 2018/04/09(月) 02:08:42.88

クラスベース構文や方法論嫌ってるやつも
使わざるを得ないだろ、ビジネス的に
JavaScriptという言語がクラスベース取り入れたんだから

**デフォルトの名無しさん** · 2018/04/09(月) 06:15:30.79

JSが取り入れたのはよりまともなクラスシステムなだけだぞ
クラスベースっていうのはそのクラスシステムに縛られざるを得ない言語のことを指すのであって
プロトタイプベースの言語でも結局構造化の過程で何らかのクラスシステムを利用するのは当然だけど
それに縛られないっていうのがポイントなんだから、そこは変わっていないぞ
あくまでまともな選択肢が増えたと言うだけだ

「mapメソッドが追加されたから、関数型嫌ってる奴も使わざるを得ない」
というのと同じくらい大げさ

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

functionでクラスが作れるとか特殊すぎだもんな
個人的には好きだけど

**デフォルトの名無しさん** · 2018/04/12(木) 15:16:11.08

最近monacaでアプリ作ってるって子から相談を受けて、調べた結果なんとか解決してあげられたんだけど
onsenUIってどうなの？
あと、リファレンスがまとまってる所が見づらかったので、良いサイトないかなって探してるんだけどどっかある？

**デフォルトの名無しさん** · 2018/04/12(木) 16:38:31.34

公式

**デフォルトの名無しさん** · 2018/04/13(金) 00:33:02.90

さよか…ありがとさん

俺の頭が悪かった
onsenUIやるのにいい感じのハウツーなサイトない？

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

公式リファレンス見てできるようにならんといつまで経ってもそのままだぞ

**デフォルトの名無しさん** · 2018/04/13(金) 09:57:14.70

コードを読むときには役に立つが、逆引きには全く使えなくない？
というか、リファレンスとか言うからいけないのか
サンプルが欲しいっす

あと、エミュレータと実機で動き違うの酷くね？
デバッガ入れるの面倒でエミュレータいじってたから普通にハマったわ

**デフォルトの名無しさん** · 2018/04/13(金) 09:57:44.50

ああ、monacaの話ね

**デフォルトの名無しさん** · 2018/04/13(金) 11:08:11.35

chromeのモバイルビューエミュレートも実機とは違うし。
何でも実機デバッグは基本。

**デフォルトの名無しさん** · 2018/04/13(金) 11:12:22.14

まともに動くと思った俺が馬鹿だったよ…
次は気をつけるので許してください

**デフォルトの名無しさん** · 2018/04/13(金) 11:26:25.29

せっかくだし、笑われついでに書いてしまうか
関数の呼び出しで

function hoge(){
alert❨"押された！c=" + para❩;
}

--中略--
page内
<ons-list-item tappable onclick="hoge(c=5)>押せ！</ons-list-item>

みたいなコードがあって、このc=5の意味が全くわからなくてさ
エミュレータ上ではcは1で初期化されてて
実機では3が代入されていた
jsは詳しくないけど、なんじゃこりゃと面食らってしまった
概念の名前だけでも誰か教えてくれないか？

もう一つはons.readyが呼ばれない件だから、一応リファレンスにも書いてあってなんか納得は出来たんだけども

**デフォルトの名無しさん** · 2018/04/13(金) 11:27:22.69

あ　実機で代入されていたのは「5」3だったらスマホ壊してたわ

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

>>471
そこで代入するのはなんと言うかエグいな。

**デフォルトの名無しさん** · 2018/04/13(金) 12:34:59.42

>>473
そもそもそんなコード、この環境以外で動くのか？
関数内でcは宣言してないから、スコープ的に見えないだろと思っていたら動いてて気持ち悪い…

**デフォルトの名無しさん** · 2018/04/13(金) 12:44:41.63

> 関数内でcは宣言してないから、スコープ的に見えないだろ

ハァ？Javascript知らないなら「Javascriptのことは門外漢ですが、」とレスの冒頭に書いとけよ。

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

>>475
すまんね
門外漢です

**デフォルトの名無しさん** · 2018/04/13(金) 14:18:21.01

友だちが教えてくれた
要するに引数未定義でも引数を与えられるんだな
んで、代入式の戻り値が渡されていると
cは代入式が処理された際にグローバル変数として宣言された事になると

スッキリした
サンクス

**デフォルトの名無しさん** · 2018/04/13(金) 21:16:32.36

引数は関係がない
関数内のcはグローバルスコープのcを指していて
イベントハンドラ中のc=でそのグローバル変数のcに代入されてるだけ

**デフォルトの名無しさん** · 2018/04/13(金) 21:55:58.78

ありがとう
一応自分でも調べたよ
代入式の戻り値は代入した値で
この場合hogeの中ではargument[0]が5って参照できるんだってね
引数が多いときに便利らしいけど、Java勢だから想像すらできなかったわ
てか今見るとparaになっててだめだこりゃ

**デフォルトの名無しさん** · 2018/04/13(金) 22:16:57.07

>>479
横だが、まだそれでもだいぶ理解を間違えているがな。argumentSだ。
複数形かどうかはJavaScriptにおいては無駄に厳密に適用されてる。

あと、>>471のコードはかなり酷い。
公式でこれならかなり終わってるし、
なら数年以内に確実に廃れると思うから、そのフレームワーク自体使わない方がいいと思うぞ。

それから、Java自体はかなり終わっている言語な事を自覚した方がいい。
(>>456内でも言及されているが、関数ポインタがなかったというのが救いようがない)
それとは別に、JavaScripterもプログラマとしては終わっているから、
この意味ではまともなJava勢が流入してくることは俺は歓迎するが。

君はちなみにJavaならどれくらい書ける？

**デフォルトの名無しさん** · 2018/04/13(金) 22:20:20.57

>>480
お前Java書けなそうだなｗ
どうせ15年以上前の知識しか持ってないだろ？

**デフォルトの名無しさん** · 2018/04/13(金) 22:21:46.50

arguments[0] には 5 が(代入式 c=5 の評価値)入っていて、hoge から読み出せるが、この場合それは参照されていない。
グローバル変数 c が読み出されてるだけ。
もちろん良いやり方ではない。

**デフォルトの名無しさん** · 2018/04/13(金) 22:34:41.82

>>481
俺は>>456内での著者の判断には同意する。
ただしそれは>>459の言うようなマーケティング上の理由ではなく、
著者の言うような技術的な問題だよ。

マーケティング的にはJavaは最も成功した言語だし、
リファクタリングが今後必要なソフトウェア資産もJavaが最も多いのは事実だ。
JavaScriptなんて保守する価値もないゴミコードばかりだし、
それ以前に書き捨ての文化だろ。俺はこれが悪いとも思わないが。

**デフォルトの名無しさん** · 2018/04/13(金) 22:36:36.70

いや、私は考えが浅いですって
話はしなくていいからｗ

**デフォルトの名無しさん** · 2018/04/13(金) 22:43:53.29

この人HTMLやXMLの基礎の基礎も知らないで適当ぶっこいてボロクソに叩かれた人でしょ

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

>>480
うん、俺も書いてから漏らしたと思った
ありがとう

公式…？
分かりづらいかも知れないけど、俺>>463ね
知り合いの会社の新人の子とやらが書いたコードをデバッグしててハマったんだよ

俺がどのくらい書けるかって言われてもなあ
SIerだから推して知るべしって感じ
趣味で多少は書くし、量産型の中ではマシな方じゃないってレベル
あと、もう6年くらい前にInazumaVotouってAndroidアプリで投票騒ぎを起こしたことがあるよ
コードはウンコでスパゲティだったが、一応動いたな（笑）

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

で、なんのためにどれくらい書けるのか聞いたのか
おそらくスキあらば叩こうと思って聞いたんだろうなｗ

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

てか理解を間違えてるってのは複数形のこと？
他の事なら聞いておきたいなって

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

>>486
ググっても出てこないがイナズマイレブンの人気投票で大騒ぎしたあれか？

>>488
お前こっちに来るか？
JavaScript情報交換所(プログラミング既習者専用）
https://mevius.5ch.net/test/read.cgi/tech/1449440793/
Javaで3,000行以上平気で書けて、JavaScriptもやりたいというのなら俺は応援する。
正直なところ、JavaScript使いはプログラマではなくデザイナやExcelマクロレベルなので、
開店休業状態になってる。
他に聞いておきたいこともあれば、それも答えるが。