― MozillaZine.jp フォーラムは Mozilla 製品に関する情報交換の場です ―



All times are UTC + 9 hours

新しいトピックを投稿する トピックへ返信する  [ 7 件の記事 ] 
作成者 メッセージ
投稿記事Posted: 2011年8月22日(月) 13:07 
オフライン

登録日時: 2011年8月22日(月) 11:18
記事: 8
以下のコードで、mousedown時のイベント順序がChromeと異なります。
CSSはオブジェクトの振る舞いを規定するので、
Chromeの順序がアプリを書く上では簡単な気がしています?

操作と振る舞い
1.Chrome
(1)Aqua2というボタンをmouseで押下
(2)Aqua2というボタンがactiveで示した座標に移動
(3)alert("_mouseDown")がポップアップ

2.Filrefox
(1)Aqua2というボタンをmouseで押下
(2)alert("_mouseDown")がポップアップ
(3)ポップアップ状態でmouseを押下したままでenterキーを押すと
 Aqua2というボタンがactiveで示した座標に移動

eventListenerとCSSでは、イベント順序としてdefaultはオブジェクトの振る舞いを
規定するCSSが先で有るべきの様に思います。


<!DOCTYPE HTML">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type='text/css' media='screen'>
#b1 {
position: absolute;top: 10px; left: 10px; width: 155px; height: 35px;
}
#b1:active {
top: 21px; left: 11px;
}
</style>
</head>
<body>
<input type="button" id="b1" value="Aqua 2"/>

<script language="JavaScript">
window.addEventListener("mousedown",_mouseDown,false);
function _mouseDown() {alert("_mouseDown");}
</script>

</body>
</html> :shock:


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年8月24日(水) 17:04 
オフライン

登録日時: 2011年8月22日(月) 11:18
記事: 8
イベント順序がChromeと異なる続き

mouseup時のイベント順序がChromeと異なる

mouseup時、マウスupがボタンのエリア内にとどまったままmouseupする場合は、
Chromeと同じであるが、マウスupがボタンのエリア外(mouseout)にでて
mouseupする場合は、mouseoutの振る舞いがChromeと異なる。

これも、Cheomeの方がアプリケーションを作る上では自然な順序に思われます。

1.Chrome
mouseout時にCSSで規定した初期状態にもどる

2.Firefox
mouseout時にCSSで規定した初期状態にもどらない

<!DOCTYPE HTML>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type='text/css' media='screen'>
#b1 {
position: absolute;top: 9px; left: 10px; width: 155px; height: 35px;
}
#b1:active {
top: 21px; left: 11px;
}
</style>
</head>
<body>

<input type="button" id="b1" value="Aqua 2"/>

<script language="JavaScript">
var elm = document.getElementById("b1");
elm.addEventListener("mouseup",_mouseUp,false);
function _mouseUp() {alert("_mouseUp");}
</script>

</body>
</html>


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年8月25日(木) 14:44 
オフライン

登録日時: 2009年4月26日(日) 00:32
記事: 97
お住まい: 大阪
具体的にDOMイベントとCSSの疑似クラスとの間にルールはないので私見ですが……

mousedownの件、具体的にDOMイベントとCSSの疑似クラスとの間にルールはないので私見ですが、私はFirefoxの挙動の方が自然に思えます。いくつかのDOMイベントは、preventDefault()でデフォルトの動作をキャンセルすることができますが、CSSの疑似クラスの適用をそのイベントのデフォルトのアクションのひとつだと考えると、それをキャンセルできない(既に実行してしまっている)Google Chromeの動作の方がおかしいと思います。実際にFirefoxで:activeをキャンセルできるかどうかは知りませんが、あくまで順序としては、の話。

mouseupの件はCSSの仕様書見る限り、Firefoxの方が正解だと思いますが。
http://www.w3.org/TR/css3-selectors/#th ... -hover-act

ボタン上でmousedown、カーソル移動して、一度外へ、カーソルをボタンの上に戻してmouseup、これでもclickイベントは発生しますので(これは仕様通り)、その間ずっとボタンはactiveだと考えるのが普通ではないでしょうか。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年8月25日(木) 19:52 
オフライン

登録日時: 2011年8月22日(月) 11:18
記事: 8
アドバイスをありがとうございます。

少し早とちりして間違えました。ご指摘の通り
マウスがボタンのエリア外(mouseout)にでてた場合は、
こちらは、firefoxの方がアプリケーションを作る上では自然な順序に思われます。

論点としては、
mouseup時、マウスがボタンのエリア内にとどまったままmouseupする場合は、
Firefoxの動きはChromeと同じである。ということです。

具体的には、mouseup時の上記の場合、DOMイベントの前にボタンは初期状態(最初の状態)に戻る。
とFirefoxは振舞います。

前提であるCSSの疑似クラスの適用をそのイベントのデフォルトのアクションのひとつだと考えると、
イベントのデフォルトのアクションはキャンセルできません。そもそもキャンセルすることは想定されていないから
之でいいという考えもありますが。

私の確認の仕方が悪いのでしょうか?

これに対し、Chromeでは、「CSSの疑似クラスの適用のアクションの後に、eventListenerのDOMイベントが補足できる」というものです。

つまり、仕様が一貫しているように見受けられます。

前々から気になっていましたが、このたびChromeで確認してみると、靄(もや)が晴れた気分になりました。

過去に議論し尽くされた問題であれば、ご容赦ください。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年8月25日(木) 23:26 
オフライン

登録日時: 2008年5月26日(月) 01:41
記事: 1345
お住まい: 冥府
関連するかは不明ですが、以下のフォーラムにonmouseに関係する比較とバグ報告が寄せられてます。

* CSSでスクロールバーの表示/非表示を切り替えた際、レイアウトが崩れる - Google Chrome 公式ヘルプフォーラム

Webkit特有のバグとの事ですが、こう云う事からもGeckoに信頼性を寄せたいですね。

_________________

*Windows 10 21H1 64bit/*GoogleJapaneseInput:ATOK2017:MS-IME
Firefox 95.0:Beta 96:Developer Edition 96:Nightly 97.0a1:
Thunderbird 91.4.0:Earlybird 96:Daily 97.0a1:SeaMonkey 2.53.10/2.58a1:
Opera 82.0.4227.23:Google Chrome 96.0.4664.93/98.0.4756.0(Official Build)canary:
SRWare Iron 96.0.4900.0:Lunascape 6.15.2:Avant Ultimate 2020 build 3, 3.17.2020


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年8月26日(金) 07:48 
オフライン

登録日時: 2011年8月22日(月) 11:18
記事: 8
そうですね、
レンダリングエンジンという意味では、現在のところGeckoは信頼性が高いのは同意します。

上で、
「具体的にDOMイベントとCSSの疑似クラスとの間にルールはない」
との事ですので、ルールを明確に作って、ブラウザの差異がなくなればいいなと。

アプリケーションを書いてる側にとって、この差異を回避するトリックを考え出すのは
車輪の再発明と思います。

私の私見ですが、
「CSSの疑似クラスは、DOMイベントに優先する」というものです。
これは単に、アプリケーションを書いたときの順序として、こちらの方が簡単だと思うのです。

たとえば、ボタンを押して何かが動く場合で、かつ動く処理に時間を要する場合において、
現在のFirefoxの順序だと、処理を動かすためのトリックを少し書かなければいけません。

これまでJavascript Nativeでアプリケーションを書いてきた中で、
イベントをキャンセルする場面は、これまで1度しか無く、windowに対する
mousedownイベント時のみです。

むしろFirefoxのイベント順序をひっくり返す側の処理を書いてきました。

私の経験が少ないだけなのか、そもそもの私のアプリケーションの
作り方がおかしいのかもしれませんので、皆さんの経験が聞きたいです。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年8月26日(金) 10:43 
オフライン

登録日時: 2009年4月26日(日) 00:32
記事: 97
お住まい: 大阪
tuneoogawa さんが書きました:
論点としては、
mouseup時、マウスがボタンのエリア内にとどまったままmouseupする場合は、
Firefoxの動きはChromeと同じである。ということです。

具体的には、mouseup時の上記の場合、DOMイベントの前にボタンは初期状態(最初の状態)に戻る。
とFirefoxは振舞います。

前提であるCSSの疑似クラスの適用をそのイベントのデフォルトのアクションのひとつだと考えると、
イベントのデフォルトのアクションはキャンセルできません。そもそもキャンセルすることは想定されていないから
之でいいという考えもありますが。

私の確認の仕方が悪いのでしょうか?


ソースを見た限り、全てのコンテンツがmouseupイベントを処理した後にFirefoxはactive状態を解除しています。まさか、alert()で確認しようとされていますか? alert()はモーダルダイアログを作り出してしまうので検証には使えませんよ?

ちなみに、ソースで見た感じ、mousedownをpreventDefault()するとactiveになるのをキャンセルできますが、mouseupをpreventDefault()してもactiveは必ず解除され、またマウスキャプチャもリリースされるようになっていました。

tuneoogawa さんが書きました:
過去に議論し尽くされた問題であれば、ご容赦ください。


www-dom@w3.orgに投稿すべき内容だと思いますよ。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
期間内表示:  ソート  
新しいトピックを投稿する トピックへ返信する  [ 7 件の記事 ] 

All times are UTC + 9 hours


オンラインデータ

このフォーラムを閲覧中のユーザー: なし & ゲスト[15人]


トピック投稿:  可
返信投稿:  可
記事編集: 不可
記事削除: 不可
ファイル添付: 不可

検索:
ページ移動:  
Powered by MozillaZine.jp® Forum Software © phpBB Group , Almsamim WYSIWYG
Japanese translation principally by ocean