元スレ+ JavaScript の質問用スレッド vol.115 +
JavaScript覧 / PC版 / みんなの評価 :
851 = :
>845以降のレスが消えてるね
新スレも一部消えていたけど、板移転の影響かな
852 = :
>874までならログを保存してあるけど、それ以上はわからない
http://codepad.org/boBOpl2e
854 = :
まぁログ速でもscでもどこでも見れるさ
855 = :
>>846
この機能ですが、ほとんどのアプリがそうなるので
windows自体の機能かもしれません
856 = :
質問です
システムが勝手に吐き出すhtml 「A」がありますがこれにcssとjavascriptで装飾と動きを与えたいと思っています
そこで「B」のhtmlファイルに、このシステムが吐き出すファイル「A」から.loadで読み込んだhtmlを
表示させたところ、「B」のヘッダに記述したｃｓｓを適用させることができました
が、「B」のファイルに記述したjavascriptが動きません。
.loadで読み込んだhtmlに対してjavascriptで効果を与えることは出来ないのでしょうか？
もし出来るのであればどのような方法がありますか？
857 = :
firefoxでも選択されますね
preventDefaultしているのに選択されるのが奇妙ですが・・
858 = :
ぶっちゃけ疑問に思っている方が不思議だわｗ
>>857
パソコン歴とか年とかどれくらい何？
普段何やってる人？
859 = :
>>858
しょうもない煽りですね
あなたよりは経験あると思いますよ
860 = :
デフォルト動作を無効にしているのに選択される合理的な理由を
万が一言えるのなら言ってみてくださいね
861 = :
ちなみにcssでuser-select: none;を指定すれば選択されないようにできるという目処は立ちました
ですが、やはりpreventDefaultしているのに文字列選択されるのはクソだと思うし、許しません
863 = :
>>856
読み込む順序は？
ちゃんと、Aを読み込んだ後に、JSを実行している？
864 = :
コピペを防ぎたいのか知らんがソースを表示すれば簡単にコピペは可能
865 = :
>>840
> これがchromeで想定していないところで発動して困っています
発動条件が書いてないので答えようがない、が正直な答え
そもそも、Googleに報告はしてるんだろうね
866 = :
コピペを防ぎたいのではなく、アプリを操作中に選択状態になるのが困るということです
867 = :
マウスカーソルを動かさないまま変更する汎用的な方法はありますか？
自分が見つけたのはカーソル直下の透明要素のcursorを変更し、
数百ms待ってから透明要素を消すことで出来るのですが
ディレイを入れず変更直後に透明要素を消すと変わりません（chrome）
このディレイの値が環境依存っぽくて気になります
ディレイを入れずに変更できる方法はないでしょうか？
869 = :
localstorageのsetItemの第一引数に変数は使えますか？
870 = :
>>869
試してみればいいじゃん。
871 = :
localstorageで使える残り容量ってどうやれば知れますか？
872 = :
>>871
残りの利用可能容量は Quota Management API を使ってプログラム上で取得することができます。
874 = :
http://developer.chrome.com/extensions/notifications
Internal server error
サーバもろくに管理できねーのか
876 = :
>>859
と言うことは、ただのアホか
877 = :
キー入力の状態を明示的に「bodyをクリックした時と同じような状態」にするにはどうしたらいいでしょうか？
chromeで、contenteditableな領域でIMEオンのまま他のbuttonをクリックすると、
フォーカスは外れるのですが、そのままキー入力をすると、
contenteditable領域にキー入力が送られてしまいます
buttonではなくbodyなどをクリックすることでblurした場合は、そのようなことはありません
バグだと思いますが、buttonクリックでは「半blur」のような状態になるのです
なので完全にblurしたいのですが、スクリプトにより要素でblurを発行しても、完全blurにはなりません
完ブラするにはどうしたらいいでしょうか
878 = :
はっと思いつき、
input textにフォーカスを移し、すぐにblurする、
というウルテクで完ブラすることが出来ました＼(^o^)／
contenteditableという十分に枯れてないコンポーネントでのみ起きる現象だったので。
879 = :
>>872
そういうものがあったのですね
調べてみます
ありがとうございました
881 = :
> わすれちゃいけないのが関数定義はブロックスコープだということ
それがどうかしたの？
882 = :
変数もブロックスコープじゃん
883 = :
いや、全て関数スコープだと思うが…
ブロックスコープはES6になるまで存在しない
884 = :
だよな
887 = :
>>883
ブロック中の関数宣言はES5までは仕様外でブラウザの独自実装
ブロックスコープか関数スコープかはブラウザによる
例えばChromeはブロックスコープ、Firefoxは関数スコープ
ただしES6ではブロックスコープになったのでこれからはそれに統一される
またそれに先立ってES5のstrict modeでは明示的に禁止されてる
あとES5まででもtry-catch(e)のcatch節中のeはブロックスコープになる
function test() {
var F = function () { return 'OK' }
if (true) { function F() { return 'NG' } }
return F
}
test()()
888 = :
>>887
ブラウザの独自拡張を当然の動作であるかのように「関数定義はブロックスコープ」や「変数もブロックスコープ」と主張するのは違うと思ったのでES5仕様に則り、「全て関数スコープ」とした
「ES5では」と書かなかったのは反省してる
ところで、「ES6ではブロックスコープになった」のは知らなかった
まともな実装ならブロック内で関数宣言しないと思うが、コードによっては大きな影響がありそうだな
889 = :
>>887
だからなんなんだよ？
ブロックスコープで関数宣言するってはない誰もしてないだろ。
関数スコープで関数宣言するのなら、
動的なものでもない限り、静的に関数宣言、つまり
var func = function () {・・・} よりも
function func() {・・・} の方がふさわしいって話を
みんなしてるんだが。
function文とfunction式の違い、式である必要がないなら
function文を使いましょう。
890 = :
ん？ まさか { }でくくられたものは全て
ブロックコープだって思ってないか？
function foo() {
function bar() {・・・} // ← ここはブロックスコープではない。
if (・・・) {
// こことかがブロックスコープ
}
}
891 = :
うーん、なんか主張が噛み合ってないね。関数スコープってのは逆に言えばブロック中に書いても滲み出るものであって、
そもそもブロック中に置けないのなら関数だってブロックなんだから、むしろブロックスコープだという方が一般的な言葉の印象として正しいと思うけどな。
まあそれはブロックスコープより関数スコープが「基本」だと思ってるからだろう。そこが咬み合わない原因かもしれない。
ブロックスコープが「基本」で関数スコープが第二の面白いスコープだと思えば、関数直下にしかない状況でわざわざ関数スコープを優先的に先に考えるのは変だと気付く
ES6からはブロックスコープだがES5までは関数スコープだったとわざわざ言うとまるでブロック文中に書いたときの挙動が変わったように思える。
だが実際の実装ではまさにそうなってるんだから、むしろ関数スコープだったと言えるのは、ES5というより実際の実装の方ではないだろうか？
893 = :
ここは質問者の答えは出るけど
その後よくわからんJavascript勉強会が始まる
895 = :
>>891
お前が馬鹿なだけじゃね？
そもそも関数スコープとブロックスコープの違いを知らなかっただろ？
それを無理やり「俺は知ってた」みたいにこじつけるのやめとけよ。
896 = :
>>891
Firefoxの独自拡張をES5標準と勘違いしているのでは？
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Functions_and_function_scope#Conditionally_defining_a_function
http://nanto.asablo.jp/blog/2005/12/10/
897 = :
>>891
お前何いってんの？ ECMAScriptの仕様調べないで、自分の定義から
仕様を推測するとかアホなことやってんの？ お前の印象なんかどうでもよくて、
ブロックスコープと関数スコープのどちらが基本とか関係なくて、
単に仕様では「ES5までは関数スコープしか存在しなかった」という事実でしか無いだろ。
実装がどうとかそんなの関係なく関数スコープしかなかったの。それがECMASCriptの一般的な言葉。
で関数定義はブロックスコープで行った場合の挙動は実装依存だが、
関数スコープで行った場合の挙動は明確で使用することに何の問題もない。
898 = :
ES5において、スコープは
グローバルスコープ と 関数スコープしか無い。
関数の中にあるものは関数スコープで、そうでないものはグローバルスコープ
ES6では新たにブロックスコープができた。
ブロックスコープとは関数スコープの中でブロックを作った時に出来るスコープで、
そのスコープ内でのみ存在する変数はletを使って定義する。
letを使わない限り変数は関数スコープとなり、ブロックスコープはオプションと考えられる。
899 = :
>>898
>ブロックスコープとは関数スコープの中でブロックを作った時に出来るスコープ
グローバルスコープの中では、ブロックスコープはできないってこと？
900 = :
ES6でスコープのデフォルトがブロックスコープに変わったとか
そういうことが起きたわけじゃない。
従来通りのコードを書けばES5のとおり関数スコープ（関数の中でなければグローバルスコープ）
それが互換性というものなのだから当然。
そこに新たにブロックスコープという概念が追加された。だがそれは追加機能であり
letを使わないとそのスコープは利用されない。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.105 + (1001) - [97%] - 2013/5/20 4:45
- + JavaScript の質問用スレッド vol.109 + (1001) - [95%] - 2013/10/7 13:16
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.126 + (348) - [95%] - 2023/1/12 17:00
- + JavaScript の質問用スレッド vol.100 + (1001) - [95%] - 2012/6/13 22:46
トップメニューへ / →のくす牧場書庫について