JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net

JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net (767ﾚｽ)
上下前次1-新
抽出解除ﾚｽ栞

1(6): デフォルトの名無しさん [] 2015/12/07(月) 07:26:33.87 ID:NYLGCW0V(1) AAS
実際にJavaScriptを書いている人の情報交換所です。
プログラミング既習者専用です。初心者の方はご遠慮下さい。
玄人の方、歓迎致します。

44(3): デフォルトの名無しさん [sage] 2016/02/08(月) 22:51:41.45 ID:vWC/lFUG(1/2) AAS
C言語信者な元ゲームプログラマーで今有明海の漁師です。
C言語信者なのは、スピード命！スクリプトとかCPU資源浪費しすぎだろ！
って思ってるから。
そんな私が、手持ちAndroid７インチタブレットで漁業用GPSロガーを使いたくなって
Google Maps API を触ってみた。

凄え。。。
Javascriptでなんでもできるじゃん・・・まじかよ・・・
Androidアプリ書こうかと思ったけどJavascriptでいいわ。
PCからも見れるしね。
まだ航跡記録とかマーカー記録とか作ってない中途半端な状態だけど
休みの日に酒飲みながら機能追加していくの楽しすぎるｗ
http://www13.plala.or.jp/tarna/maps/ariakekai/index.html
有明海を見てね。
長崎県と熊本県の間の内海です。

76(8): デフォルトの名無しさん [sage] 2016/04/25(月) 17:28:53.92 ID:q4sdOoqx(1) AAS
>>72
Array#forEachのコールバック関数にcurrentValueをthis値束縛する動作が自然ではなく、それによるメリットもないからだ
prototype上のメソッドでもないただのコールバック関数がなぜarrayでもグローバルオブジェクトでもなく、cirtentValueに束縛するのだ？
Function#bindでthis値を1に変更した場合、全ての要素値が1と扱う実装に利便性があるとは思えない
(arrayに束縛するならわからんでもないが)
forEachは第3引数でコールバック関数のthis値を指定できるが、これは異なるスコープからデータを渡すのに便利だ
(jQuery#eachにはこの機能はない)

イベントハンドラ関数のcutrentTargetへのthis値束縛もDOM3までは存在せず、DOM4で実装から逆輸入して規定されたものだ
addEventListenerには元々、handleEventでthis値を束縛する機能があり、thisをcurrentTargetとして扱うコードはhandleEventを利用した途端に修正を迫られる
event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
ちなみに、jQueryではhandleEventを利用出来ない

jQueryがthisを多用するのは仮引数を書く手間を減らす為だけに定められた歪なものだ
ECMAScriptでは関数呼び出しされるまでthis値が定まらない不定値だが、jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない

80(3): デフォルトの名無しさん [sage] 2016/04/25(月) 22:47:27.73 ID:wavxOtJH(3/4) AAS
>>76
> jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
> this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない

そんなことしません。

そう言う用途として使うのは、DOM要素のdatasetだよ。
このdatasetっていうのは比較的最近できたもので昔はなかった。

だけどjQueryは要素ごとの情報の格納場所の必要性を昔から認識していたため
datasetが作られるよりも前からdata()メソッドと言うのを持っていた。

そしてdata()メソッドがある理由の一つとして、
thisに直接値を格納するとブラウザのバグでメモリリークになる可能性があるから
「this（DOM要素）にデータを格納してはいけない。」と言っていたぐらいだ。

事実はあんたが思っているのと正反対だよ。

82(3): デフォルトの名無しさん [sage] 2016/04/25(月) 23:32:07.55 ID:olQI0pZ8(1) AAS
>>76でhandleEventの話が出ているが、使った人ならわかると思うが、
handleEventはswitchでイベントを振り分ける必要があって使いづらい。

なぜこんな仕様があるかというと、そもそもDOMはJavaScript以外の言語も
考慮されて作られているという事実で説明できる。

つまり関数の引数、つまりaddEventListenerの引数に関数を渡せない言語が存在する。
具体的に言うとJava。Javaでは引数に関数を指定することができず、
オブジェクトは指定できる。

handleEventインターフェースを実装したオブジェクトを引数に取る関数と
考えるとhandleEventという仕様がなぜ存在するかがわかる。
これは便利だから追加された機能じゃない。Java等で必要だったっから
追加された仕様であって、JavaScriptでは関数をそのまま指定した方がいい。

154(3): デフォルトの名無しさん [sage] 2016/05/15(日) 09:04:33.00 ID:u/cc/woI(1/9) AAS
>>153
> １０年は自分にとってWebにおいて永遠と等しいように感じる。
これでいいんだよ。逆に有限で廃止すると混乱する。

> １０年も経てば流石にどんな仕様でも削除出来ると思うよ。
どんな糞仕様であっても放置しているだけでは削除できない。
typeof(null) が object なのを削除できてないだろ？
あるいはthisがグローバルになるという糞仕様も削除出来てないだろ。
この2つなんて、ただのバグの温床であって、活用できるものではない。
ではデフォで"use strict"にできているかというと、これも出来てないだろ。
そういうものなんだよ。

Webの仕様で、ただの案ではなく、完全に「正式仕様」として認識されたもので、
「正式に廃止」されたものがあるかい？
上記を見る限り、使われなくなったものは多々あっても、「正式に廃止」されたものは無いんだと思うよ。

> しかし、ブラウザがその実装を取りやめるのは、各ブラウザが収集している
> ユーザーが閲覧しているページでのAPIの利用頻度が実際にほぼ無視できるレベルまで落ちた時だから
まあこれは一概には言えないけどね。chromeはJavaを切ったろ。無視できるレベルではなかったと思うよ。
実際に、俺は偶に遭遇するしね。
これも「正式に廃止」したのではなく、勝手にサポートを止めただけだ。
事実上の廃止勧告であったとしても、仕様から「正式に廃止」することは無いのだと思うよ。

本来、仕様策定とは、こういった混乱を防ぐためのものだ。W3Cは全く機能していない。
この点については、
>>131
> （昔的な）標準機構（形・影は薄れてきてる）はこれから何をするのがよいのか。
WHATWGは新仕様の採用には積極的なのだから、もうそっちは完全に任せて、
W3Cは旧仕様の削除に専念するのもありだと思うよ。
後者は要するに利害関係者間の調整であって、WHATWGの連中がやりたがる仕事ではないし、
本来の「仕様策定」側の仕事でもあるから。

158(4): デフォルトの名無しさん [sage] 2016/05/15(日) 17:01:58.55 ID:79V1eiQO(3/6) AAS
>>154
'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
typeof nullの挙動は２年前治そうという案の盛り上がりが頂点に達したのだが互換性のために断念した。
が、将来的な演算子オーバーロードの仕様が入ると共に直す策を入れようと言う案は出てる。
もしくは、V8が画策している型付厳格JSの方向性が成ればそちらでも更生は可能。

でも自分としては、動的言語で型を一生懸命「事前にチェックする」のは良くないという持論を持っている。
その代わり、せっかく備わっている暗黙の型変換を利用して、型を「揃えて」おくのが良いと思う。
例えば自然数入力を期待してpromptを出し続けるのであれば、
do{
n = prompt('自然数') | 0
}while(n <= 0)
で良い事が多いし、良いとするようにする。
この場合入力がキャンセルされた際のnullも、空入力の""も+演算子で0になる。
そういうパターンを活用し、そういうパターンが活用できるようなロジック・仕様を組み立てるのが、
JSをスクリプト言語として上手く活用していく上での１つの答えと思っている。

そういう感じで、nullに関して重要なのは、もっとよく扱えるようにする事かもしれない。
例えば昔から案があって、直近はそろそろ仕様に入りそうなくらい盛り上がってきたこれ
https://esdiscuss.org/topic/existential-operator-null-propagation-operator
こういう演算子が入ったりすれば、ますます「事前にチェックする」必要性がなくなる。

167(6): デフォルトの名無しさん [sage] 2016/05/15(日) 20:45:26.55 ID:u/cc/woI(6/9) AAS
>>158
> 動的言語で型を一生懸命「事前にチェックする」のは良くないという持論を持っている。
流儀があるのなら好きなようにすればいいし、コーディングルールに引っかからなければいいとは思うが、
それは一般的にはトリッキーだと言われると思うぞ。

null と　'' を弾きたいのなら、普通はチェック部分に纏めて以下にする。
do{
n = prompt('自然数');
} while(!n || n <= 0)
知ってないといけないことは、null は偽(常識）, '' は偽(JavaScript特有)だ。
前者は他言語でもそうなので、後者だけ知っていれば済む。

それに対して、君のコードは
1. null | 0 の結果がどうなるか(JavaScript特有)
2. '' | 0 の結果がどうなるか(JavaScript特有)
を知っていなければならない。自動型変換後のビット演算だ。かなり仕様の隅っこ。
そしてそれは制御論理とは本質的に関係ない。
つまり「JavaScript知ってる俺カッケー」でしかないんだよ。

しかも、論理構造に無駄があるだろ。
俺のコードは、弾く部分で弾いているだけ。
弾かれる対象を確認するためには、whileの1行を見れば済む。
君のコードは、不正入力は後で弾かれる入力に変換して、結果的に後から弾く構造になっている。
だから弾かれる対象を確認するためには、2行見ないといけない。
記述が分散している分、バグも含みやすい。

だから無駄に難しいコードになっているんだよ。
それで速度等のメリットがあればいいんだけど、今回については無いと思う。したがって、糞コード扱いされる。

君は無駄に3倍難しいコードを書いている。
それは、俺のような単純明快なコードを書くように勤めれば、同じ労力で3倍の規模のコードを扱えることを意味する。
君のやり方だと能力の2/3をみすみす捨てているようなものなんだよ。勿体無いだろ？

185(3): デフォルトの名無しさん [sage] 2016/05/17(火) 09:05:07.26 ID:sIex+koZ(1) AAS
>>180
確かに個人的にはそういうコードを毎回書いても楽しいから苦にならないのだが、
何もそうしろと言いたかったわけではなく、一般的に利用するときは
ただそういうフレームワークを読み込んで、各リソースURLに「#priority」を付けるだけ
ってのは十分労力の割に結果がデカイと思うよ。

WebやJSの歴史見ても、「面倒なことは事はやらない」ってより、
「面倒なこと、汚いことは事はライブラリやフレームワークがやる」だった。

209(3): デフォルトの名無しさん [sage] 2016/06/09(木) 09:39:33.79 ID:FTTkP1ld(1) AAS
arrow function の引数の丸括弧を省略する記法嫌いな人って多くないのかな

const fn = arg => { console.log(arg); };

const fn = (arg)=>{ console.log(arg); };

213(4): デフォルトの名無しさん [sage] 2016/06/09(木) 14:51:10.11 ID:eWu1TzV4(1) AAS
>>209
省略できるものは原則省略したほうがいい。セミコロンも含む。
短く書けるとき、あえてそうしないというのは、
何らかの特別な意味を表す必要がなければしない方がいい。

217(3): デフォルトの名無しさん [sage] 2016/06/11(土) 16:40:46.73 ID:tWgkOxEq(2/2) AAS
>>215
釣りではない。
GitHubやnpmなど、セミコロンフリーのスタイルは確立されている。
自分も様々なスタイルを試した結果、今はこれに賛同しているだけ。
ただし、この２つは同じく原則省略でも細部の取り回しが異なる上、自分もそれらとは微妙に異なる。
ルールセットの他の部分は当然違う。結構細かくいろんなスタイルが存在する。
そのどれもが考えられてるのだから悪いとかフザケてるとか思うようなことでないと思う。
それなのに人の信念というか、正義を釣り呼ばわりするのはかなり独りよがりだと思う。
でも落ち込まないで、そんな君も好きだよ。

270(3): デフォルトの名無しさん [sage] 2016/06/27(月) 01:40:09.28 ID:n3Kagte5(2/5) AAS
一応全体的に遅いということなのでそうだと勝手に思っていた。古いが以下。
http://blog.livedoor.jp/abars/archives/52103965.html

とりあえず確かめてみた結果、読み書きは1.5倍程度遅い。
許容範囲かといわれれば微妙だな、、、、
なおデータがなかなか安定しなかったので、若干怪しい。
サイズは俺が使う予定の1000にした。
このサイズなら確保との差が見えないが、オリジナルのサイズ(1.6M)だと見えていた。

function testArray(data, n, iter, start) {
var time_enter = Date.now();
for(var j=0;j<iter;j++)
for(var i = 0; i < n; i++) data[i] = i & 0xFFFFFFFF;
var now = Date.now();
return [now-time_enter, now-start];
}

function check(iter){
var start = Date.now()
console.log('array: '+testArray(new Array(count), count, iter, start));
start = Date.now();
console.log('Int32Array: '+testArray(new Int32Array(count), count, iter, start));
}

var count = 1000;
for (var i=100;i<100000000;i*=10) check(i);

304(3): デフォルトの名無しさん [sage] 2016/07/18(月) 00:12:28.04 ID:CK8ZYmxh(1/12) AAS
>>302
Note1だろ？
> Date objects handle the absence of a hint as if the hint String were given.

辿ってみたが、なるほど[[DefaultValue]](8.12.8)の所でデフォがDateに関してはStringというのは分かった。
そしてValueOf()が返してくるのはこれだから、Add側がString連結になっているのはこれでいい。
ただこれだとsub側が都合が悪い。つまり、もう一度書くと、以下になっているわけだが、

> - は ToNumber(GetValue(target)) を引いて差を返す (11.6.2) (>>291)

GetValue(target)がデフォでStringを返してくるのでデフォのままでは引き算は出来ない。
一応GetValueにはPreferredTypeを指定することが出来て、
Numberを指定していれば数値が返ってくる。
だから仕様としてsubを定義する為には、subの時はNumber指定しないといけない。
で、それはどこに書いてあるんだ？

なおお前が大好きなmoment.jsも確認したが、同様に直ではなく、こちらはvalueOfを使っていた。
> mom._d.setTime(mom._d.valueOf() + milliseconds * isAdding);
> http://momentjs.com/downloads/moment.js
つってもMDNには同じだと明記されているが。
> This method is functionally equivalent to the Date.prototype.getTime() method.
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/valueOf

いずれにしても、何かしら理由があったんだと思うが。
とりあえず5.1で確認出来たらその記載が旧仕様にあるかどうかを確認すればいい。

つかこの際英語は関係ないだろ。そういうのもコンプレックス出まくりだから止めたほうがいい。
英語は日本語より下手なのを自覚した上で、ヒット件数と内容をとるか、言語をとるかでしょ。

336(3): デフォルトの名無しさん [sage] 2016/07/19(火) 02:25:00.57 ID:9Xihfq37(1/2) AAS
相変わらずアスペ全開だな。

まあついでに言っておくと、JavaScriptの連中は仕様書を書いている連中すらゴミだってことだ。
オブジェクト指向を理解出来てない。

Type固有の案件は全部15章に突っ込まないと駄目だ。
11章の演算子(+)に書くとか、親クラスのメソッドに子クラス毎にif文入れているようなものだ。
あの仕様書では頭からお尻まで全部読まないと理解できない。典型的な駄目コードだ。
だから俺も読み込むまでに余分に時間がかかった。

var Object = {
operator+: funciton() {
if (typeof(this)==='Date') // 11.6.1 NOTE1 // 現行仕様書
}};

var Date = {
operator+: function() { // 15.9.X　// こっちに書くべき
}};

Type固有の例外規定が15章に書いてない時点で仕様書の構造がゴミ。
但し書きはダブって良いので、15章にも書き、そっちがオリジナルであるべき。
上記上側みたいに、Dateオブジェクトの特別扱いを、子クラスでメソッドをオーバライドせず、
親クラスのメソッドにいちいちif文入れてこられたらキレるだろ？
上記下側のように、子クラスでオーバライドした上で、
親クラスのメソッドに「Date型ではオーバライドされています」とコメントを付けておくべき。

344(3): デフォルトの名無しさん [sage] 2016/07/19(火) 19:56:18.15 ID:Lmd4i1Ew(2/2) AAS
まあそういう挙動が変だ、嫌だって言うなら
delete Date.prototype[Symbol.toPrimitive]
すれば変えられる。
誰かは言わないけど世の中には
delete Object.prototype.__proto__
とか嫌いで許せない物をまず削ってから始める派の人も居るみたいだしね。

358(3): デフォルトの名無しさん [sage] 2016/08/21(日) 21:25:32.47 ID:u7v77FIA(1/3) AAS
IndexedDBでdeleteObjectStoreする時にトランザクションが（仕様上）取れなくて、
そのままdb.close()するとエラーになる時があるんだが、これってどうすればいいのだ？
e.target.errorは以下。e.target.transacsionはnull(IDBFactory.openで呼んだ直後）

target:IDBOpenDBRequest
error:DOMException: The connection was closed.
code:20
message:"The connection was closed."
name:"AbortError"

createObjectStoreはtransactionプロパティがあるのでそれでoncompleteを待てるのだが、
deleteObjectStoreは何故かvoidを返す仕様で、待ちようがない。
ならばそのままクローズで良いのかと思いきや、エラーになる。
https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase/deleteObjectStore

普通ならIDBDatabase.transactionがプロパティでそこから辿れるはずなのだが、メソッドだし。
deleteの時にトランザクションがないわけがないし、
それにアクセス出来ないのは仕様上の欠陥だと思うが。
createObjectStoreがobjectStoreを返すのは便利で良いが、本来はTransactionを返すべき。
だったら空オブジェクトにtransactionプロパティだけでも付けておいてくれないと対応出来ない。

なおヒット状況は、
1. あらかじめIndexedDBに500個ほどオブジェクトストアを作っておく。
2. open直後にそのうち3つほどを連続して消す。
3. クローズ。
この3のタイミングの取り方が分からない。

IndexDBは初めて使うので、使い方が間違っていたり、
或いは大幅に勘違いしてるかもしれないけど、その辺も含めてよろしく。
なおアプリとしてはもう一度削除されるだけなのでクリティカルな問題ではない。

379(3): デフォルトの名無しさん [sage] 2016/08/22(月) 01:25:17.05 ID:utwn7AiT(5/11) AAS
>>378
だから、FileSystemApiがだよ。
フォルダとしては見られないか、超掘り返さないと見れないよ。
更にいうと、エクスプローラでなんなりするべきものじゃない。

それはもう、Electronかなんかで作れ。な？

お前が勘違いしてるのは、多分indexedDBへの保存の方法だとの思うけど。
そのために必要な階層構造を保ったまま、indexdDBに十分入れれるからな。

546(4): デフォルトの名無しさん [] 2020/05/04(月) 22:38:13.60 ID:Zdi/ARyL(1/2) AAS
いやJavaはひととおりマスターしたから
オブジェクト指向はバッチリ理解している。

JavaScriptは気持ち悪いことが多すぎる。関数が変数に代入できることとか。
まるで物理で光が粒でもあるし波でもあるという二重性のことを習ったときのように頭が混乱する。

このへんの考え方について詳しくコツを教えていただけませんか？

595(3): デフォルトの名無しさん [] 2020/07/23(木) 00:05:54.40 ID:qAfVnVsp(3/7) AAS
$("div").click(function(){
$(this).css('background','red');
})

のこの$(this)が$("div")を指す理由はなんですか？
Javaではthisというのはそれを定義したクラスのインスタンスを指すと習いましたが。

606(3): デフォルトの名無しさん [sage] 2020/07/23(木) 20:38:07.50 ID:QHkNbR5l(1/8) AAS
>>598
ID:/b5pS+w+ の言っていることは全面的に正しいが、補足すると、
> thisの正体を見分けるコツはないですか？
こんな事を言っている時点で糞サイト（或いはゴミ本）に騙されているから止めとけ。
見分ける必然性も意味もない。単なる暗黙の引数程度でしかなく、
実際にそれなりに組織的にコーディングするとcallはそれなりに使う。

DOM APIのthisがe.currentTargetを指すのはそもそもJava用の仕様、
つまりJavaでもクライアントスクリプトを書けるようにする為の仕様らしい。（とここ5chで聞いた）
しかし現在はJavaで書く奴なんて一人もいないし、JavaScriptにおいてはe.targetを全面的に使うのが正しい。
理由は、
1. thisにはe.currentTargetが入っているが、マトモなサイトなら通常はbubbleを利用する為、e.target主体で書くことになる。
　つまりこの仕様のthisでは使い物にならない。
2. e.currentTragetで役に立つ場合は、Elementに直接onXXXかaddEventListenerした場合だが、
　こんな事をやっているのはjQueryを使っている程度の簡単なサイトだけ。
　やれば分かるがbubbleを利用した方が実行効率もよく、コードも綺麗になるから、マトモなサイトは全部そうしてる。
　ただし、Elementに直接貼った方が直感的で分かりやすいので、jQueryのような簡単/初心者向けの場合には活用される。
　(なおjQueryでもbubble主体で書くことは可能ではあるが、それをやるとjQueryの意味がほぼ無くなるので普通はやってないと思う）

622(4): デフォルトの名無しさん [sage] 2020/07/23(木) 22:57:37.04 ID:k24nyzXR(12/21) AAS
>>619
> そしてbubbleを使わずに一々全Elementにイベントを付けていくのは完全に旧式であって、

jQueryでは全Elementにイベントハンドラを使えずに、
ocumentエレメントにイベントハンドラを付ける場合このように書きます。

$(document).on('click', 'a', function() {
　$(this).css("background": "red");
});

知ってましたか？ｗ

623(5): デフォルトの名無しさん [sage] 2020/07/23(木) 23:16:41.69 ID:k24nyzXR(13/21) AAS
https://jsfiddle.net/m8q15376/

例えばこの2つのコードはイベントハンドラをつけてるところは違いますが
同じよう動作をします。thisが使えない？何の話でしょうかねｗ

$("#id1").on('click', 'a', function() {
　$(this).css("background", "red");
});

$("#id2 a").on('click', function() {
　$(this).css("background", "red");
});

626(3): デフォルトの名無しさん [sage] 2020/07/23(木) 23:22:10.11 ID:QHkNbR5l(7/8) AAS
>>623
だからそれ明らかにイベントバブル使ってないじゃん。
それを>>622形式で書いた時にe.targetが無いとどうしようもないでしょ。
それを言ってるんだよ。

642(4): デフォルトの名無しさん [sage] 2020/07/24(金) 01:22:11.42 ID:2LubhzPR(3/17) AAS
>>626
訂正、>>623でもバブルを利用しているようだ。

jQueryはこの形式だとDelegated event handlers として扱われ、
on時点でサブクエリして一致した子要素に付けるのではなく、
内部的にバブルしてきたイベントを使い、実行時にクエリして一致を確かめるようだ。（後半部は予想、実装依存）
https://api.jquery.com/on/

だから確かにバブルを利用してはいるが、これだともっさり遅くはなる。（とはいえGUIの場合は大抵問題にはならない）
jQueryは使ってないし今後も使う予定もないので仕様には詳しくなく、見た目で判断してしまった。
なるほど何だかんだで上手く出来てはいる。

が、まあ、いずれにしてもこれをDOMAPIだけで書くのも別段苦労しないし、
jQuery内部でe.targetを使っているだけで、e.targetが無ければjQuery自体が組めないだけでしかない。

>>640
イベントデリゲーションの方がかなりオレオレ用語だと思うが。
確かにMDNには書いてあるが、俺は今まで聞いたこともなかったし、そもそもそれを「デリゲーション(ｷﾘｯ」とかいうのもどうかしてると思うが。
OOPで言う委譲に当たるから「デリゲーション」なんだろうが、それはOOPで言う「継承か委譲か」、という話とは全然違っていて、
単に親要素でしかなく、子要素とは何の関わりもない。（一応包含してはいるが）
だから無理やりOOP的な解釈をすれば「デリゲート」しかないのだろうけど、
それは、世の中の全てを無理矢理OOPで解釈するJava脳みたいな感覚を受け、
Java以外で普通にOOPを分かっている奴からしたら相当気持ち悪い使い方だし、実際に流行ってもないだろ。
これが気持ち悪いと思わないのは君がOOPを理解してないからだよ。
ただし俺はGUI自体がOOPにフィットしないと思っているから、GUIしかやらないのなら理解している必要はないとも思うけども。

そして君は都合の悪い>>633は無視なのか？
既に言ったが、現在の状況でe.targetが無くなることはない。
ただ、あの辺デタラメに拡張して仕様がグダグダなので、整理しろよな、とは思うが。

674(3): デフォルトの名無しさん [sage] 2020/07/24(金) 10:12:17.88 ID:2LubhzPR(11/17) AAS
>>670
一応読んだぞ。

まあそう思うのは自由だが、それは最初に書いてあるとおり、
> To handle cases where one event has more than one handler, event bubbling concept can be implemented. The major use of event bubbling is the registration of default functions present in the program.
つまり一つのElementに複数のイベントハンドラを付けたい時にバブルを活用出来るとか、
或いはrootにデフォルトのイベントfunctionを付けておけばそれを「上書き」する際に活用出来る、みたいなわけだが、
そんな使い方してるサイトなんて無いぞ。というかそんなことしたら怒られると思うが。
複数付けたければ普通にaddEventListenerすればいいだけだし、
サイトのスクリプトがユーザースクリプトその他によって「上書き」される前提で書いているサイトなんてほぼ無い。
あるにしてもこんな邪道なやり方ではなく、「サイトのスクリプトをオフにする」という、公式な無効化機能が付いてる。
というか、そうじゃないとお互いに困るだろ。お前はそれも分からないレベルなのだろうけど。

>>671
逃げたって何の事よ？
jQueryが採用しているとかそういう話ではなくて、
そもそもバブルは（お前が拘っている『DOMの仕様』なのだから）jQueryとは関係なく、勝手にする物だ。
そしてバブルを利用した書き方＝親で纏めて処理する方式なら、
jQueryの得意とするqueryをすることがないからjQueryを使う意味がない、と言ったんだよ。
それはお前が本当に『書ける』というのならすぐに分かる話だろ。
お前はやっぱり書けないのだと思うよ。

720(5): デフォルトの名無しさん [sage] 2021/06/12(土) 15:43:59.92 ID:TONJAMor(1/2) AAS
プロならLPIのHTML５レベル２は持ってて当たり前なのでしょうか？

721(4): デフォルトの名無しさん [sage] 2021/06/12(土) 21:20:44.77 ID:uQ7TEz17(1/2) AAS
>>720
俺はWeb系ではないが、採用条件として明示してあるのでなければ、無視でいいと思う。

一般にIT系では採用時に資格は重視されない。理由は簡単で、
・進化が早く、資格として整備された時(数年後)には既に陳腐化している。
・精々数時間で50-100問(数分/問)を課すテストで計れるのは、「知識」であって、「実力」ではない。
だから逆に言えば、ほぼ進化がなく、それなりに知識が必要だとされる分野は、資格も話題にはなってる。
これは他スレ読めば分かると思うけど、JAVA/オラクル/MS位だね。その他は全部ゴミだと思っていい。
進化も早く、知識も浅くて済むJSでは、今後とも資格は主流にはならないよ。

なおみんな「実力」は計りたがっており、テストで計れれば画期的だから、資格ビジネスも乱立するわけだが、
実際はこれは出来ない。理由はこれまた非常に簡単で、タイムスパンが全然違うから。
現代のプロのIT現場では通常の「テスト」のように、数分で完了するような仕事はない。
(その程度だとアマチュアでも問題なく出来てしまうため、今のプロには回ってこない)
人を採用するような規模の企業での実際の仕事は、数ヶ月〜1年くらいのスパンになるから、
テストで計れる「知識量」よりも、分からないことをWeb等で調べる「検索力」「応用力」、
或いは同僚に聞いたり教えたり仲良くやっていける「コミュ力」、
そしてプログラミングの本質である「設計力」が問われ、テストに比べれば時間制限なんて無いに等しい。
だから「テスト」で計ること自体がそもそも無理なんだ。

734(3): デフォルトの名無しさん [sage] 2022/09/04(日) 12:37:49.60 ID:FTTWPGH/(1) AAS
>>733
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/RegExp
のlookbehind assertions。safariが未対応

上下前次1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 2.937s*