乙個因為系統字型大小設定導致的rem計算渲染異常問題

測試同學突然拿著一部手機過來說，h5渲染各個元素都變大了，有些元素撐出了螢幕外面。

本來以為是某個webview的渲染相容問題，結果發現所有的瀏覽器都這樣。

莫名其妙，隱約感覺是 rem計算出了問題，開始一點點查。

因為，組內移動端專案，統一約束了寬度滿屏7.5rem，所以，先看看這個比例：

alert($("#flag").width()/$("#flag").height());

如下圖，正常是7.5，測試同學拿來的bug機，6.52。。。尼瑪，什麼鬼。 

其實，最開始，並沒有想為啥會不是7.5，當時只是解決問題，頁面開始渲染的時候，我先偷偷算一下當前渲染的是不是7.5，如果不是，我給強行掰過來。

正常情況下：

根節點的 fontsize=螢幕寬度/7.5

現在出了異常，系統實際寬度滿屏6.52個rem的情況下，渲染效果變大了。在初始計算的fontsize基礎上做了比例放大加持，那解決方案應該是：

相應比例縮小一下初始的fontsize，改為fontsize=fontsize*這個比例（即6.52/7.5）

**如下：

/*

* html 頭部最早執行的js片段 用於rem計算等 */
(window.onresize = function
() );
})();

雖然解決了問題，但是，其實這樣並不是太好，因為畢竟使用者改了系統字型大小設定，他就是想看更大的東西的。

所以，原則上來說，css的布局上，應該更流式布局一些，而不是全部rem做等比縮放。

但是呢，這樣下來，ui和前端開發成本就都高了。

得不償失，收益比低呢。

哈哈。

乙個因為粗心的Bug

資料繫結,分頁顯示 private void updatamenu final edittext search pageid 0 listwz.setadapter null filterarray new jsonarray filterarray usedatabase.wzarray sear...

Calendar 導致的乙個bug

查詢不到資料。把calendar生成的date通過gettime 列印出時間戳。因為資料庫裡的資料是每天生成的，所以對應的時間毫秒為0，而calendar生成的時間沒有對毫秒進行set值覆蓋，導致使用到了當前時間的毫秒值。此時由於查詢條件是 導致這部分資料被忽略掉了。由於 calendar.geti...

因為乙個L 引發的失瘋病

因為乙個l引發的失瘋病 某天，朋友發過了乙個js驗證的 所阻止不了提交，如下，其實，細心點很容易解決的 要不你們先試試 後面寫總結。輸入姓名 輸入性別 男女 解決過程。省略，對我而言 最重要的是學習到什麼。總結 1.首先 jquery 中submit 事件是針對 form 元素使用 也就是 form...