のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,063,110人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

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

    JavaScript覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで
    301 = :

    javascriptからアプリを起動しツイートしようとすると
    このページをtwitterで開きますか？のように確認ウィンドウが出てしまうのですが
    これを回避することは可能なのでしょうか？

    305 = :

    CSSのみで指定できる箇所にチャンネルを識別できる情報があれば可能なければ不可能

    それすらわからない君にはどのみち無理ですね

    308 = :

    >>307
    いやいやww

    310 = :

    スレここであってるかな？
    fancybox3に詳しい人います？
    マイナーなのか調べてもあんまりヒットしないし公式ドキュメント見てもわからんくて。。

    いわゆるモーダル系のjsライブラリなんだけど背景クリックしてもモーダルを閉じないオプションあれば教えてください

    312 = :

    子要素のイベントを親要素が取得する方法ってイベントバブリングだかで取得するしかないのでしょうか？
    例えばモーダルの中にアコーディオンメニューがあった場合、アコーディオンをクリックすると高さが増えるので
    ブラウザの高さよりも高くなることもあると思います。
    その場合に、クラスを付与してモニョモニョしたいといった用途です。

    また、モーダルの中でアコーディオンメニューが開くに限定せず、何かがクリックされて高さが変動する、
    不特定な状態で進めたいと考えています。

    現状イベントバブリングで対応できそうだったのですが、不特定なクリックイベント側で
    e.stopPropagation(); の記述があったら詰んでしまうと思いまして代替案が無いか質問いたしました。

    313 = :

    子要素の高さに合わせて親要素の高さが可変するように作っておくべき

    314 = :

    モーダルがブラウザの高さを超えた場合にレイアウトがが変わる仕様なので、質問しました。
    バブリングを使わなくても、同等のイベントを記述すれば、捕捉できそうなので解決ということで。
    ありがとうございました。

    315 = :

    すみません。
    どちらかというとプログラミング一般の質問になってしまうのかもしれないのですが
    ご意見をいただけますと幸いです。

    なにかしらのフォームがあるとします。
    ちなみにサーバーはNodeですが、あまり関係ありません。
    UXのためにフォームにはバリデーションがしっかりかけられており、
    ユーザーが期待しない値を入力したときには親切なエラーが定義されています。

    こういう状態で、サーバー側に意図しない値が来たときの挙動はどうすれば良いでしょうか？
    それが悪意のあるものであれば、どのように対応しても良いと思いますが、
    ブラウザが古い、何かしらのアシストツールの効果、（想定外の）APIとしての利用なども考えられると思います。

    ケースバイケースだと思いますが、ベテランの人たちの直感的に、
    サーバー側でもきっちり値の判定をして、HTTPエラーコードを返すのが良いのか、
    親切なエラーメッセージを返すのが良いのか、どちらでしょうか。

    それとも、校正はバリデーションに全て任せて、値を有効値に加工してそのまま鵜呑みにするのが良いのでしょうか。
    例えば値Xがユーザーの年齢なら、Xは1桁か2桁の数字列文字列を確認した後数値に直し、if(X<=3)throwなどとする代わりに、
    X = +Xなどとして、Xがたとえ0や負値になっても（それが脆弱性に繋がりそうでない感じなら）そのまま扱う、ということです。

    316 = :

    サーバー側でも基本的に同じチェックをして入力が不正ならエラーとして扱う
    ただし親切なエラーメッセージを出すかどうかはものによる
    不親切でもよければ汎用的なエラーメッセージを使うことはよくある

    クライアント側に比べてサーバー側の入力チェックを緩くするケースは
    種類の異なる複数のクライアントをサポートする必要があって
    一番緩いクライアント仕様に合わせる必要がある時くらい

    317 = :

    悪意について書いてるから理解してるじゃない
    それが最低ラインだから当然だよね

    鵜呑みにというか忖度すると、思ってもみなかった所で躓くから、俺はサーバでは厳密にエラー入力として処理
    それが不便なら入力の方でマイナス符号とかの不正入力はバリデーションすればいいって主張
    エラーメッセージは好きにすればいいと思うけど、そんな物を利用者に見せたりしても仕方ないと思う
    親切なエラーメッセージに凝るくらいなら親切な入力で弾いとけよと

    318 = :

    なるほど。
    ・手を抜くなら徹底的に手を抜く
    ・厳密にするなら徹底的に厳密にする
    という２択に自分の中で無意識に絞っていましたが、
    正解はその間にありそうだということに気づくことができました。
    どうもありがとうございました。

    323 = :

    はい、jsのクソ仕様来ました～

    324 = :

    クソ仕様って何の事？

    325 = :

    クロージャーはクソ仕様
    C言語にそのようなものはない

    326 = :

    関数に放り込むべき2つ目の引数はいつ決定するの？
    まさかクリックした瞬間って訳でもないだろうし
    年取ったせいかコード読んでも意図が読めん

    329 = :

    >>326
    年のせいにするな。お前がアホなんや

    330 = :

    >>323
    JSには基本的に「クソ仕様」というものはない
    主要なコミュニティがあってスタイルが決まっている言語とは違って
    そういう束縛がなくバリエーションに富んだ書き方が自由にできるのがJSの良さ
    それが嫌なら幾らでもaltJSがある

    JSをわざわざ使っていて厳格だとか単純性にこだわるのはアホ
    JSをあえて使うのならその奥深い複雑性を活かして効率化を図り、
    厳格性ではなく曖昧性を生かして問題を問題でないように吸収するのがJSの使い方
    それが嫌ならJSで頑張ろうとせずに素直にaltJSを使うのが1000倍賢い

    Cが使いたかったらCで書いてemscriptenでも通せばいいだけ
    無理してJSでC風に書く必要はないし、ましてや他人にそれを押し付ける理由は１つもない

    334 = :

    >>332
    私は「基本的に」と言った
    var、undefinedもそれ自体がまるごとクソ仕様なのではない
    使い方、組み合わせによっては注意すべきポイントが出てくるということで
    そういう機能までクソ仕様と言ったら多くの言語の多くの機能がクソ仕様になる
    var、undefinedも他の言語も含めて広い目で見たとき取り立ててクソ仕様と断定できるほどではない
    分かったか？（ﾄﾞﾔ）

    335 = :

    お前あいかわらず長文クソレスしかしないな

    336 = :

    クロージャーって1回しか使わない処理をエレガントに書くためのものだろう？
    簡単な条件式で内容変える程度なら三項演算子とかでもいいけど（あれはエレガントとは言えぬが）

    337 = :

    クロージャってjsだと劣化クラスみたいな感じだよな
    他の言語のクロージャとは違う

    338 = :

    >>336
    1回しか使わないんだったら引数で渡せばいい話で、外のスコープの変数にアクセスする必要なんてない。

    >>337
    javaと間違えてね？

    339 = :

    >>336
    それは単なる無名関数では？ｗ
    使わなかろうがクロージャくらい覚えとけよｗ
    なんで知らない段階で否定すんだよｗ
    否定するにしても知ってて否定するほうがカッコいいぞ？ｗ

    340 = :

    >>337
    >他の言語のクロージャとは違う

    何が違うの？

    341 = :

    >>339
    別に否定なんてしとらんが
    ていうか無名関数とクロージャーって同じものじゃないのけ

    342 = :

    同じものではないな

    343 = :

    関数とスコープくらい別物

    344 = :

    関数とスコープは直交した概念だから比較対象として不適切

    345 = :

    んでもクロージャーって、意図からしてスコープの追加じゃない？

    347 = :

    new Function 構文を使った事なかったんで知らんかった
    ローカルではなくグローバルのレキシカル環境を参照するから個別なクロージャには出来ないのか

    348 = :

    Shadow DOMのようにこの先スコープの浸透を防いで隔離する機能が入る可能性は高い
    最近盛り上がってるのだとモジュールブロックとか
    http://github.com/tc39/proposal-js-module-blocks

    349 = :

    なんでえ藪から棒に

    350 = :

    >>334
    基本的にどんな言語にもクソ仕様はあります
    JavaScriptも例外ではありません


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド

    トップメニューへ / →のくす牧場書庫について