现代浏览器都可以直接使用selectionStart和selectionEnd来获取文本框光标的开始和结束位置。这是很实用的属性，但是由于在不同浏览器中，光标的行为本身有差异。所以导致各浏览器获取光标开始和结束位置的值也存在差异，这和用户体验是息息相关的。
各浏览器间相同的光标行为
在文本框上按下鼠标时，mousedown事件中可以获取到鼠标按下前文本框内的光标位置，即使文本框在鼠标按下之前没有焦点，也可以获取到上次失去焦点之前的光标位置。这意味着文本框在失去焦点时并不会把光标位置数据清空。无焦点的文本框会在处理完mousedown事件之后得到焦点，并触发focus事件。TAB键也可以把焦点移到某个文本框，这种方式获取焦点会默认选中所有文字。当整个window失去焦点时，文本框的光标也会失去焦点，这会触发blur事件。当window恢复焦点时，原来有焦点的文本框也会恢复了焦点，这会触发focus事件，并且文本框依然保留失去焦点时候的选区。
Chrome27中的文本框行为
当文本框得到焦点时会把原本的光标位置清零，这个清空光标位置的行为在focus事件处理之前。这意味着，在focus事件中光标的开始和结束位置通常都是零。即使是用TAB键来获取的焦点（这个会直接选中所有文字），在focus事件中光标的开始和结束位置也依然是0。可以看做是，focus之前的操作会在触发完focus之后再对光标生效。比如鼠标点击无焦点的文本框，mousedown事件触发之后产生focus事件，但是鼠标效果是在处理完focus事件之后才产生的光标，而focus之前会对原先的光标清零，所以这样无法获取到最新点击的位置。当然，前面说它“通常”是零就意味着存在例外的情况。比如整个window失去焦点后再恢复的情况，这时原来的光标位置不会被清空，所以window恢复焦点时触发的focus事件中可以取到光标位置。
Firefox22中的文本框行为
当文本框得到焦点时不会把原本的光标位置清零。使用鼠标点击来获取焦点鼠标操作对光标的影响会在focus事件之前生效，这就意味着focus事件中可以获取到鼠标最新的点击位置。但是对于使用TAB键来获取焦点时它则是在focus事件之后才影响光标，所以这种情况focus事件中获取到的是上一次失去焦点时的光标位置（由于不会清零）。另外，Firefox中对文本框选区和普通的文字选区的实现方式是一样的，所以即使文本框没有焦点也可以直接从上面的选区拖动文字。这意味着如果鼠标点击在一个已经选中的选区上，即使目标文本框没有焦点也会在focus之前触发dragstart。而拖动事件有保护选区的效果，所以鼠标按下时不会破坏原有的选区。这时再触发的focus中鼠标点击也可以获取到上一次的光标位置了。这种情况应该属于Firefox的BUG，这里不做其它考虑。
IE10中的文本框行为
当文本框得到焦点时不会把原本的光标位置清零。操作对光标的影响总是在focus事件之前生效。这意味着无论是使用鼠标操作还是使用TAB键来获取焦点，都总是能在focus事件中获取到最新的光标位置。
总结
我觉得Chrome的逻辑是最严密的，IE的逻辑是最实用的。对于Firefox，我已经没什么可说的了。
本文版权归属：康宝莱减肥 转载请注明，肆意删除链接，我们将保留追责权利
阅读(908) | 评论(0) | 转发(0) |
