總結一下一些知識。
1.利用css穿透
常見發生場景：假如我們需要通過input，type=『file』來上傳檔案，而這個input的預設樣式，可以說是非常地「不人道」。所以我們希望通過一張，與這個input大小一樣，位置一致地蓋在上面。這個時候，顯然，這個時候點選，input是不會起作用的。就是因為img隔絕了click的穿透，而我們希望的是，這個img只是視覺上遮擋了input的樣式，但是點選的時候還是點選到input。所以，只要讓img可穿透即可。
css**如下：
img
2.實現自定義原生select控制項的樣式
由於select移動端原生樣式很醜，但是原生彈出效果是符合我們設計的原則。直接修改select的樣式的時候，乙個奇怪的現象出現了，在chrome上除錯的時候，自己定義的樣式起了作用，在android手機上也起了作用，但是到了ios手機上就不行了，典型的不相容問題，這個時候禁用原生的樣式即可。
css**如下：
3.文字溢位處理
移動裝置相對來說頁面較小，很多時候顯示的一些資訊都需要省略部分。最常見的是單行標題溢位省略，多行詳情介紹溢位省略。
css**如下：
//單行.single
//多行
.more
4.300毫秒的故事
移動裝置訪問的web頁面都是pc上的頁面。在預設的viewport（980px）的頁面往往都是需要「雙擊」或「捏開」放大頁面來看清頁面。而正是為了確認使用者是「雙擊」還是「單擊」。safari需要個300ms的延遲來判斷。而後來的iphone也一直沿用這樣的設計，再後來android也沿用了這樣的設計。於是，「300ms的延遲」就成了一道規範。
處理方法：
使用自定義tap事件代替click事件。 原理：在touchstart、touchend時記錄時間、手指位置，在touchend時進行比較，如果手指位置為同一位置（或允許移動乙個非常小的位移值）且時間間隔較短（一般認為是200ms），且過程中未曾觸發過touchmove，即可認為觸發了手持裝置上的click，一般稱它為「tap」。
5.tag透傳的解決方案
①.使用緩動動畫，過渡300ms的延遲。
②.中間層dom元素加入，讓中間層接受這個「穿透」事件，稍後隱藏。
③.「上下」都使用tap事件，原理上解決tap透傳事件（但不可避免原生標籤的click事件）。
④.改用fastclick的庫。
6.開啟彈性滾動
css**如下：
body
注意：android不支援原生的彈性滾動，但可以借助第三方庫iscroll來實現。
7.點選不靈敏
起因：由於使用touch觸發自定義tap事件，提速約200ms，但是touch事件對點選區域要求更大，偶有不觸發。
解決方案：
①同時使用touchend和click觸發tap事件，如果touchend已經處理，則click不處理。
②全域性捕獲click事件，如果click事件和tap事件的點選座標一致，且相差不到1s。則在捕獲階段阻止事件預設行為的同時取消冒泡。
8.chrome除錯快捷鍵
①ctrl+shift+f 全文查詢
②ctrl+o 查詢檔案名
③ctrl+shift+o 查詢js函式名
9.彈性
主要用在百分比布局中，用乙個父標籤包裹img標籤，父元素的寬度用**查詢來改變。
css**如下：
img
10.一畫素邊框設定
很多時候，想保持邊框的大小在任何設定上都是1px，但是因為1px使用2dp渲染，也就是說會顯示為2px大小。所以，要採用css3縮放一下。
css**如下：
.folder li.folder li+li:before
努力學習。。。
移動端開發的一些問題
解惑好文 移動端h5頁面高畫質多屏適配方案 對比了下文章和公司目前狀況，關於清晰度這一點，公司沒有這方面的要求，我們也沒有做這麼複雜，所有一律用 2x。我確實已經遭遇過好幾次還原度不高的問題，一度覺得很費解，我實話我真的看不出來還原度有多麼的不高。dpr在移動端開發中應該是需要特別注意的一點，dpr...
開發的一些總結（2）
1.static的意義 如果任何乙個x前加了static修飾，那麼這個x允許其他原始檔建立同名函式且不衝突。不能被其他原始檔訪問 修改，可以直接用class訪問，不用例項化。同時static類的東西也不能操作非static型別的東西。在標頭檔案如果說明了乙個static型別變數，就要在,cpp檔案的...
移動端的一些坑
1rem大小的設定，1rem 100px html media screen and min width 320px media screen and min width 375px media screen and min width 414px media screen and min widt...