document.elementFromPoint

fredshare 發(fā)布于2019-08-21 14:16 / 2776人閱讀

摘要：除了坐標(biāo)問題外，該方法只能返回頂層元素，也就是在有個(gè)元素重疊的情況下，只能返回最上層的元素。

先說一下這個(gè)方法的參數(shù)

elemntFromPoint(x,y);//傳入坐標(biāo)值，返回當(dāng)前頁面上包含該坐標(biāo)點(diǎn)的頂層元素

注意2點(diǎn)，坐標(biāo)值和頂層元素

先說坐標(biāo)，因?yàn)椴煌娜死斫馐遣灰粯拥?，也就造就了這個(gè)方法在不同的瀏覽器中表現(xiàn)是不一樣的，所以在傳入坐標(biāo)時(shí)就分整體頁面坐標(biāo) 和可視區(qū)域坐標(biāo)，我們看上篇文章中的圖來理解下：

中間的方塊是可視區(qū)域，紅點(diǎn)相對(duì)可視區(qū)域的左上角我們稱之為 clientX和clientY,相對(duì)于頁面起始處的左上角稱之為 pageX和pageY

有的瀏覽器在調(diào)用elementFromPoint時(shí)要求傳入clientX和clientY而有的要求pageX和pageY,具體的詳見：http://www.quirksmode.org/webkit.html 看 elementFromPoint部分，上面也提到如果在標(biāo)準(zhǔn)中進(jìn)行規(guī)則統(tǒng)一，也會(huì)規(guī)定使用可視區(qū)域的坐標(biāo)

顯然我們?nèi)绻眠@個(gè)方法時(shí)，就要注意兼容了，而對(duì)于同一種瀏覽器，因?yàn)榘姹镜牟煌瑢?dǎo)致同樣的這個(gè)方法可能要求傳入的坐標(biāo)也不同，比如chrome瀏覽器，那么，我們?cè)撊绾稳ゼ嫒菽兀?/p>

The w3c specification says:

The elementFromPoint(x, y) method, when invoked, must return the element at coordinates x,y in the viewport. The element to be returned is determined through hit testing. If either argument is negative, x is greater than the viewport width excluding the size of a rendered scroll bar (if any), or y is greater than the viewport height excluding the size of a rendered scroll bar (if any), the method must return null. If there is no element at the given position the method must return the root element, if any, or null otherwise.

調(diào)用elementFromPoint時(shí)，必須傳入可視區(qū)域內(nèi)的坐標(biāo)，如果你傳入的坐標(biāo)不在可視區(qū)域內(nèi)，即使在這個(gè)坐標(biāo)處有元素，也將返回null;我們可以根據(jù)這個(gè)特性來寫兼容代碼：

使用jq實(shí)現(xiàn)的代碼如下，我們可以很方便的改寫成自已的

(function($) {
    var check = false,
        isRelative = true;
    $.elementFromPoint = function(x, y) {
        if (!document.elementFromPoint) return null;
        if (!check) {
            var sl;
            if ((sl = $(document).scrollTop()) > 0) {
                isRelative = (document.elementFromPoint(0, sl + $(window).height() - 1) == null);
            } else if ((sl = $(document).scrollLeft()) > 0) {
                isRelative = (document.elementFromPoint(sl + $(window).width() - 1, 0) == null);
            }
            check = (sl > 0);
        }
        if (!isRelative) {
            x += $(document).scrollLeft();
            y += $(document).scrollTop();
        }
        return document.elementFromPoint(x, y);
    }
})(jQuery);

原理就是上面說的，如果頁面有滾動(dòng)，則嘗試獲取頁面坐標(biāo)最邊緣處的元素，如果能獲取到，說明是使用頁面坐標(biāo)，因?yàn)樵谟袧L動(dòng)的情況下，獲取可視邊緣處的坐標(biāo)，頁面坐標(biāo)會(huì)大于可視區(qū)域的坐標(biāo)，所以如果是用可視區(qū)域坐標(biāo)，肯定返回null

嗯，一切看起來都還不錯(cuò)，IE6 7就不行了，仔細(xì)看了下這個(gè)方法，這個(gè)方法最早應(yīng)該是IE特有的，最后被其它瀏覽器實(shí)現(xiàn)，在IE下，一直使用的是可視區(qū)域的坐標(biāo)，但是在IE6 7的情況下，當(dāng)你傳大于可視區(qū)域的坐標(biāo)時(shí)，也是可以獲取到值的，也就造成了上面兼容代碼無法在IE6 7下正常工作，所以上面的代碼并沒有考慮IE6 7的情況，需要你添加一些判斷。

除了坐標(biāo)問題外，該方法只能返回頂層元素，也就是在有2個(gè)元素重疊的情況下，只能返回最上層的元素。

之前我也有寫過高效拖動(dòng)的文章，比如拖動(dòng)排序分類，常見的是鼠標(biāo)在拖動(dòng)的時(shí)候，不停的計(jì)算鼠標(biāo)是在哪個(gè)分類上面，然后做出變換的效果，如果列表元素比較少的情況下還是可以的，如果大于1000個(gè)，而這些分類的高度不定，通過這個(gè)循環(huán)判斷的方法顯示就會(huì)覺得很卡

我在之前的文章中提到可以在mousemove時(shí)，不讓任何元素?fù)踔髽?biāo)（通常我們可能會(huì)在拖動(dòng)時(shí)，讓被拖動(dòng)的元素隨鼠標(biāo)一起移動(dòng)，這時(shí)候元素可能擋在鼠標(biāo)的下方），可通過事件的event.target獲取鼠標(biāo)指向的元素，這樣列表中有多少個(gè)元素都不會(huì)影響到效果

回頭說一下setCapture方法，該方法是IE下讓元素捕獲到事件，比如鼠標(biāo)移到瀏覽器外邊也可以響應(yīng)得到，然而這個(gè)方法在firefox在4版本時(shí)被引進(jìn)firefox中，引入后如果拖動(dòng)時(shí)你調(diào)用了setCapture，就算鼠標(biāo)下面沒有東西擋著，event.target也始終是鼠標(biāo)按下時(shí)的target，IE中則不是，調(diào)用setCapture后，mousemove時(shí)依然可以獲取到，當(dāng)然IE下可能要用event.srcElement獲取

所以，保險(xiǎn)起見，我們要調(diào)用setCapture，而調(diào)用后，firefox4以后又不能及時(shí)獲取到鼠標(biāo)下的元素，拋開這些，在ios設(shè)備上，touchmouse時(shí)，同樣也是獲取不到手指指向的元素，所以只好回頭折騰這個(gè)elementFromPoint了。

在折騰這些的時(shí)候，還發(fā)現(xiàn)諸如getBoundingClientRect在ios設(shè)備上也是有問題的，這個(gè)方法正常返回相對(duì)可視區(qū)域的坐標(biāo)，而在ios上，實(shí)現(xiàn)的卻是相對(duì)頁面的坐標(biāo)，實(shí)在讓人郁悶

回頭再看一下兼容，之前做瀏覽器間的兼容，更多的是這個(gè)瀏覽器有這個(gè)方法，那個(gè)瀏覽器有那個(gè)方法，方法的不同而已，現(xiàn)在的兼容則是同樣的方法，最終的結(jié)果不同，比如setCapture還有g(shù)etBoundingClientRect等，可能還有其它一些有問題的方法，這種兼容起來更麻煩，遠(yuǎn)不如沒有方法來的干脆些。