Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

文本框行为差异:焦点、选区、光标

  现代浏览器都可以直接使用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,我已经没什么可说的了。
网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^