1.input? placeholder問(wèn)題
在chrome 模擬移動(dòng)端調(diào)試時(shí)[左邊圖]宪躯,顯示的非常正常,但是在真機(jī)上[右邊圖]再膳,placeholder里面的內(nèi)容明顯靠上醉旦,非常的不美觀
在國(guó)外網(wǎng)站,對(duì)這個(gè)屬性的兼容性處理恒界,那就是不要設(shè)計(jì)input的line-height或者設(shè)置line-height為normal即可睦刃,
試了一下,雖然在谷歌模擬調(diào)試?yán)锷晕⑵鲜ǎ窃凇罢鏅C(jī)上”正常垂直居中~
2.line-h(huán)eight
line-height經(jīng)常用于文字居中涩拙,不同手機(jī)顯示效果不一樣枣宫。什么鬼~
在chrome模擬器上又是顯示得非常完美,但是吃环!Android和IOS又各自‘偏移’了也颤。如果把line-height加1px,iPhone文字就會(huì)稍微‘正常顯示’郁轻,由于我們app的ios用戶居多翅娶,并且android機(jī)型太多,不同機(jī)型也會(huì)顯示不同好唯,所以只能退而求其次了竭沫。line-height的兼容問(wèn)題不太好解決,容器高度越小骑篙,顯示效果的差距越明顯蜕提。
解決方案:稍微大一點(diǎn)的高度,最好把line-height設(shè)置為高度+1px靶端,兩個(gè)平臺(tái)顯示都不會(huì)太‘奇怪’谎势。
3.使用rem ?(兼容性:ie9+)
原理:瀏覽器的默認(rèn)字體高都是16px,未經(jīng)調(diào)整的瀏覽器在顯示1em=16px杨名。
rem則是只相對(duì)于根元素的font-size脏榆,即只需要設(shè)置根元素的font-size,其它元素使用rem單位設(shè)置成相應(yīng)的百分比即可台谍;
一般使用:
設(shè)置html的font-size為62.5%
html{
? ? ? ? ? font-size:62.5%;
}
body{
? ? ? ? ? ?font-size:12px;
? ? ? ? ? ?font-size:1.2rem;
}
p{
? ? ? ? ? ?font-size:14px;
? ? ? ? ? ?font-size:1.4rem;
}
4.實(shí)現(xiàn)自定義原生控件的樣式
由于select移動(dòng)端原生樣式很丑须喂,但是原生彈出樣式是符合我們?cè)O(shè)計(jì)的原則
解決方法:將原本select 設(shè)置為透明,z-index設(shè)置高~再用一個(gè)比較好看的樣式‘假裝’在表面
5.移動(dòng)端使用innerHtml繪制
使用innerHTML繪制大段趁蕊,之后想獲取HTML的ID節(jié)點(diǎn)坞生,事實(shí)上是獲取不到的,這種問(wèn)題在動(dòng)態(tài)創(chuàng)建DOM會(huì)經(jīng)常發(fā)生
這也是一個(gè)神器的問(wèn)題掷伙,博主自己寫了一個(gè)移動(dòng)端輪播插件是己,在chrome上瀏覽非常正常,但到了真機(jī)上卻顯示空白炎咖,各種百度赃泡,最后才發(fā)現(xiàn)這么坑的地方…
解決方案:嘗試了很多方法之后,老老實(shí)實(shí)在頁(yè)面直接用html結(jié)構(gòu)乘盼,如果有更好的方法升熊,也請(qǐng)告訴我。
6.300ms延遲
方案一:禁用縮放
在HTML文檔頭部包含如下meta標(biāo)簽時(shí):
缺點(diǎn)——就是必須通過(guò)完全禁用縮放來(lái)達(dá)到去掉點(diǎn)擊延遲的目的绸栅,然而完全禁用縮放并不是我們的初衷级野,我們只是想禁掉默認(rèn)的雙擊縮放行為,這樣就不用等待300ms來(lái)判斷當(dāng)前操作是否是雙擊。
方案二:更改默認(rèn)的視口寬度
如果設(shè)置了上述meta標(biāo)簽蓖柔,那瀏覽器就可以認(rèn)為該網(wǎng)站已經(jīng)對(duì)移動(dòng)端做過(guò)了適配和優(yōu)化辰企,就無(wú)需雙擊縮放操作了。
這個(gè)方案相比方案一的好處在于况鸣,它沒有完全禁用縮放牢贸,而只是禁用了瀏覽器默認(rèn)的雙擊縮放行為,但用戶仍然可以通過(guò)雙指縮放操作來(lái)縮放頁(yè)面镐捧。
兼容性問(wèn)題:
對(duì)于方案一和方案二潜索,Chrome是率先支持的,F(xiàn)irefox緊隨其后懂酱,然而令Safari頭疼的是竹习,它除了雙擊縮放還有雙擊滾動(dòng)操作,如果采用這種兩種方案列牺,那勢(shì)必連雙擊滾動(dòng)也要一起禁用整陌。
7. 虛擬鍵盤導(dǎo)致 fixed 元素錯(cuò)位
fixed元素一定會(huì)伴隨虛擬鍵盤的出現(xiàn),但是虛擬鍵盤只是“貼”在了viewport上瞎领,表面上不會(huì)對(duì)dom產(chǎn)生“任何”影響泌辫,但是這個(gè)時(shí)候fixed元素表現(xiàn)卻變得怪異起來(lái),會(huì)錯(cuò)位默刚。
解決原理:虛擬鍵盤彈出時(shí)將fixed元素設(shè)置為static甥郑,虛擬鍵盤消失時(shí)候設(shè)置回來(lái)。
解決方案:由于虛擬鍵盤出現(xiàn)并未拋出事件荤西,而檢測(cè)scroll或者resize事件,皆會(huì)有一定延遲伍俘,會(huì)出現(xiàn)閃爍現(xiàn)象邪锌。則當(dāng)前獲取焦點(diǎn)元素為文本元素,就將fixed元素設(shè)置為static癌瘾。
8.移動(dòng)端手勢(shì)
手指放在屏幕上:ontouchstart ? ? 手指在屏幕上滑動(dòng):ontouchmove ? ? ?手指離開屏幕:ontouchend
原理:
1.在touchstart事件觸發(fā)時(shí)觅丰, ?記錄手指按下的時(shí)間startTime,本次滑動(dòng)的初始位置initialPos妨退。
2.在touchmove事件觸發(fā)時(shí)妇萄, 記錄當(dāng)前位置nowPosition(實(shí)時(shí)移動(dòng)元素),滑動(dòng)距離movePosition(當(dāng)前位置nowPosition與初始位置initialPos的差值)咬荷,判斷正負(fù)數(shù)再?zèng)Q定是左還是右移動(dòng)冠句。
3.在touchend事件觸發(fā)時(shí), ? 記錄手指離開屏幕的時(shí)間endTime幸乒,獲得手指在屏幕上停留的時(shí)間(endTime-startTime)懦底,滑動(dòng)距離movePosition
判斷是否滑動(dòng):
如果停留時(shí)間少于300ms,則認(rèn)為是快速滑動(dòng)罕扎,無(wú)論滑動(dòng)距離是多少聚唐,都到下一頁(yè)
滑動(dòng)距離與‘容器’ ?大小進(jìn)行比較丐重,若超過(guò)‘容器’大小的1/3,則到下一頁(yè)