整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
事跟我說他用jQuery取不到頁面上隱藏元素input的值，他的html頁面大概內容如下。
<!DOCTYPE html>
<html lang="zh">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script type="text/javascript" src="jslib/jquery-1.11.2.min.js"></script>
<title>淺談Html頁面內容執行順序</title>
<script type="text/javascript">
var userId = $('#hiddenUserId').val();
var contextPath = $('#hiddenContextPath').val();
var userName = $('#hiddenUserName').val();
</script>
</head>
<body>
<input type="hidden" id="hiddenUserId" value="101" />
<input type="hidden" id="hiddenContextPath" value="/web" />
<input type="hidden" id="hiddenUserName" value="小明" />
</body>
</html>頁面中的JS腳本在head中，JS腳本要讀取的input在body中。瀏覽器對html頁面內容的加載是順序加載，也就是在html頁面中前面先加載，因此當加載到JS腳本時，input還沒有加載到瀏覽器中。JS是一種解釋性的腳本，也是從上而下順序執行，由于這段JS代碼是立即執行的，所以當JS在執行的時候，讀取不到input的值。
最直接的修改方法是把JS放到網頁的最下面執行。
<!DOCTYPE html>
<html lang="zh">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script type="text/javascript" src="jslib/jquery-1.11.2.min.js"></script>
<title>淺談Html頁面內容執行順序</title>
</head>
<body>
<input type="hidden" id="hiddenUserId" value="101" />
<input type="hidden" id="hiddenContextPath" value="/web" />
<input type="hidden" id="hiddenUserName" value="小明" />
<script type="text/javascript">
var userId = $('#hiddenUserId').val();
var contextPath = $('#hiddenContextPath').val();
var userName = $('#hiddenUserName').val();
</script>
</body>
</html>把JS放到網頁的最下面，這樣在JS執行的時候，網頁內容都已經加載完畢。把JS放在網頁的最下面方法并不是最好的解決方法，大部分情況JS并不是總能放在網頁的最下面。這時可以用window的onload事件，onload事件在整個頁面都加載完成后才觸發，可以把JS腳本放在onload里面執行。不同瀏覽器onload事件添加方式也不一樣。
IE下事件：
window.attachEvent('onload', function(){
var userId = $('#hiddenUserId').val();
var contextPath = $('#hiddenContextPath').val();
var userName = $('#hiddenUserName').val();
});Chrome/Firefox等DOM標準事件：
window.addEventListener('load', function(){
var userId = $('#hiddenUserId').val();
var contextPath = $('#hiddenContextPath').val();
var userName = $('#hiddenUserName').val();
});由于不同瀏覽器的事件添加方式不一樣，jQuery為我們提供了通用的初始化方法，該方法在頁面加載完成時觸發。
$(function(){
var userId = $('#hiddenUserId').val();
var contextPath = $('#hiddenContextPath').val();
var userName = $('#hiddenUserName').val();
});上面方法本質就是添加onload監聽事件。
最終修改后的頁面
SS加載存在先后順序，不嚴謹的書寫順序將會導致界面出現偏差。并且正確的書寫順序也可以提高代碼的可讀性。
正確的排序方式如下：
(1)定位屬性：position display float left top right bottom overflow clear z-index flex
(2)自身屬性：width height padding border margin background
(3)文字屬性：font-famliy font-size font-style font-weight font-varient color
(4)文本屬性：text-align vertical-align text-wrap text-transform text-indent text-ecoration letter-spacing white-spacing white-space text-overflow
(5)CSS3中新增屬性：content box-shadow border-radius transform……
css順序按照以上順序書寫即可。
<h4 id="目的減少瀏覽器的reflow回流提高瀏覽器加載速度">目的：減少瀏覽器的reflow(回流)，提高瀏覽器加載速度
接下來講解瀏覽器的渲染原理
瀏覽器引擎簡介
瀏覽器——Firefox、Chrome和Safari是基于兩種渲染引擎構建的，Firefox使用Geoko——Mozilla自主研發的渲染引擎，Safari和Chrome都使用webkit。
渲染主流程
渲染引擎首先通過網絡獲得所請求文檔的內容，通常以8K分塊的方式完成。下面是渲染引擎在取得內容之后的基本流程：
①解析html以構建dom樹 -> ②構建render樹 -> ③布局render樹 -> ④繪制render樹
css樣式解析到顯示至瀏覽器屏幕上就發生在②③④步驟，可見瀏覽器并不是一獲取到css樣式就立馬開始解析而是根據css樣式的書寫順序將之按照dom樹的結構分布render樣式，完成第②步，然后開始遍歷每個樹結點的css樣式進行解析，此時的css樣式的遍歷順序完全是按照之前的書寫順序。在解析過程中，一旦瀏覽器發現某個元素的定位變化影響布局，則需要倒回去重新渲染。
概念：
DOM Tree：瀏覽器將HTML解析成樹形的數據結構。
CSS Rule Tree：瀏覽器將CSS解析成樹形的數據結構。
Render Tree: DOM和CSSOM合并后生成Render Tree。
layout: 有了Render Tree，瀏覽器已經能知道網頁中有哪些節點、各個節點的CSS定義以及他們的從屬關系，從而去計算出每個節點在屏幕中的位置。
painting: 按照算出來的規則，通過顯卡，把內容畫到屏幕上。
reflow（回流）：當瀏覽器發現某個部分發生了點變化影響了布局，需要倒回去重新渲染，內行稱這個回退的過程叫reflow。reflow會從 (html)根節點 這個root frame開始遞歸往下，依次計算所有的結點幾何尺寸和位置。reflow幾乎是無法避免的。
repaint（重繪）：改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部布局的屬性時，屏幕的一部分要重畫，但是元素的幾何尺寸沒有變。
例如：現在界面上流行的一些效果，比如樹狀目錄的折疊、展開（實質上是元素的顯 示與隱藏）等，都將引起瀏覽器的 reflow。鼠標滑過、點擊……只要這些行為引起了頁面上某些元素的占位面積、定位方式、邊距等屬性的變化，都會引起它內部、周圍甚至整個頁面的重新渲染。
注意：
(1)display:none 的節點不會被加入Render Tree，而visibility: hidden 則會，所以，如果某個節點最開始是不顯示的，設為display:none是更優的。
(2)display:none 會觸發 reflow，而 visibility:hidden 只會觸發 repaint，因為沒有發現位置變化。
(3)有些情況下，比如修改了元素的樣式，瀏覽器并不會立刻reflow 或 repaint 一次，而是會把這樣的操作積攢一批，然后做一次 reflow，這又叫異步 reflow 或增量異步 reflow。但是在有些情況下，比如resize 窗口，改變了頁面默認的字體等。對于這些操作，瀏覽器會馬上進行 reflow。
覽器的工作機制，一句話概括起來就是：web瀏覽器與web服務器之間通過HTTP協議進行通信的過程。所以，C/S之間握手的協議就是HTTP協議。瀏覽器接收完畢開始渲染之前大致過程如下：
從瀏覽器地址欄的請求鏈接開始，瀏覽器通過DNS解析查到域名映射的IP地址，成功之后瀏覽器端向此IP地址取得連接，成功連接之后，瀏覽器端將請 求頭信息 通過HTTP協議向此IP地址所在服務器發起請求，服務器接受到請求之后等待處理，最后向瀏覽器端發回響應，此時在HTTP協議下，瀏覽器從服務器接收到 text/html類型的代碼，瀏覽器開始顯示此html，并獲取其中內嵌資源地址，然后瀏覽器再發起請求來獲取這些資源，并在瀏覽器的html中顯示。
離我們最近并能直接顯示一個完整通信過程的工具就是Firebug了，看下圖:
其中黃色的tips浮層告訴了我們”colorBox.html”從發起請求到關閉連接整個過程中每個環節的時長（域名解析 -> 建立連接 -> 發起請求 -> 等待響應 -> 接收數據），點擊該請求，可以獲得HTTP的headers信息，包含響應頭信息與請求頭信息，如：
//響應頭信息 HTTP/1.1 304
Server: Apache/2.2.4 (Win32) PHP/5.2.1 Connection: Keep-Alive Keep-Alive: timeout=5, max=100 Etag: "1e483-1324-a86f5621"
//請求頭信息 GET /Docs/eva/api/colorBox.html HTTP/1.1 Host: ued.com User-Agent: Mozilla/5.0
Firefox/3.6.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-cn,zh;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: http://ued.com/Docs/ If-Modified-Since: Thu, 17 Feb 2011 10:14:07 GMT If-None-Match: "1e483-1324-a86f5621" Cache-Control: max-age=0
另外，ajax異步請求同樣遵循HTTP協議，原理大同小異。
瀏覽器加載顯示html頁面內容的順序
我們經常看到瀏覽器在加載某個頁面時,部分內容先顯示出來,又有些內容后顯示。那么瀏覽器加載顯示html究竟是按什么順序進行的呢?
其實瀏覽器加載顯示html的順序是按下面的順序進行的：
1、IE下載的順序是從上到下，渲染的順序也是從上到下，下載和渲染是同時進行的。
2、在渲染到頁面的某一部分時，其上面的所有部分都已經下載完成（并不是說所有相關聯的元素都已經下載完）。
3、如果遇到語義解釋性的標簽嵌入文件（JS腳本，CSS 劍 敲創聳盜E的下載過程會啟用單獨連接進行下載。
4、并且在下載后進行解析，解析過程中，停止頁面所有往下元素的下載。
5、樣式表在下載完成后，將和以前下載的所有樣式表一起進行解析，解析完成后，將對此前所有元素（含以前已經渲染的）重新進行渲染。
6、JS、CSS中如有重定義，后定義函數將覆蓋前定義函數。
Firefox處理下載和渲染順序大體相同，只是在細微之處有些差別，例如：iframe的渲染
如果你的網頁比較大，希望部分內容先顯示出來，粘住瀏覽者，那么你可以按照上面的規則合理的布局你的網頁，達到預期的目的。
JS的加載
不能并行下載和解析（阻塞下載）
當 引用了JS的時候，瀏覽器發送1個jsrequest就會一直等待該request的返回。因為瀏覽器需要1個穩定的DOM樹結構，而JS中很有可能有代 碼直接改變了DOM樹結構，比如使用 document.write 或 appendChild,甚至是直接使用的location.href進行跳轉，瀏覽器為了防止出現JS修改DOM樹，需要重新構建DOM樹的情況，所以 就會阻塞其他的下載和呈現.
為了更清楚的顯示頁面元素的加載順序，動手寫了一個程序，程序對頁面中的每個元素都延遲10秒。
程序的位置在見附件。
首先查看TestHtmlOrder.aspx這個頁面，使用HttpWatcher來檢測頁面元素的加載。
從下面的圖中可以看到加載順序。
IE首先加載了主頁面TestHtmlOrder.aspx，
下載了主頁面后，頁面首先顯示的是“紅色劍靈”、“藍色劍靈”幾個字，但此時顯示的是只是黑色字體，沒有樣式，因為樣式還沒有下載下來。
接下來頁面中的標簽是JS標簽，屬于嵌入文件，因此IE需要將其下載下來。這有兩個文件，雖然IE同時能夠和WebServer建立兩個鏈接，但是此時并沒有使用兩個連接，而是使用一個連接，在下載完成后，接下來才下載另外一個文件。
究其原因，是因為JS包含了語法定義，在第二個文件里面的函數可能用到了第一個文件里面的變量和函數，IE沒有辦法判斷，或者需要很耗時的判斷，才 能判斷文件下載的先后順序。而在解釋方面，IE對JS文件是下載一個，解釋一個(可以執行文件TestJsOrder2.aspx)。如果先下載的是第二 個文件，此時就會發生解釋錯誤。因此需要開發者自己在放置JS文件位置時，按先后順序放好，IE依次下載進行解釋。后面的函數覆蓋前面的函數定義
在下載完成后，我們看到helloWorld，helloworld2，開始順序執行。而此時字體的樣式表和圖片仍然沒有下載下來。
在helloWorld，helloWorld2執行過程時，此時頁面停留在函數執行的中斷點(alert部分)。此時IE并沒有去下載CSS的文件。由此說明JS函數的執行會阻塞IE的下載。
接下來我們看到CSS文件的下載也是使用了一個連接，也是串行下載。其串行下載的原因和JS串行下載原因是一樣的。
在兩個CSS文件下載過程中，我們看到“紅色劍靈”，“藍色劍靈”依次變為紅色和藍色，兩者顏色的轉換時間相差在10秒，說明樣式文件和JS文件一樣是下載完一個解析一個的。
現在轉到TestCssOrder.aspx看一下，可以看到 開始時“紅色劍靈”，“紅色強壯劍靈”，顯示為紅色，過了10秒“藍色劍靈”顯示為藍色，再過10秒，“紅色強壯劍靈”字體變粗了，同時“紅色強壯劍靈 2”開始出現。在剛開始“紅色劍靈”，“紅色強壯劍靈”顯示紅色時，第三個樣式還沒有下載下來，此時IE使用已經下載到樣式對上面的元素渲染了一遍，此時 雖然“紅色劍靈”，“紅色強壯劍靈”樣式定義不同，但是顯示效果一樣。第三個文件下載后，此時IE又重新對“紅色強壯劍靈”渲染了一遍，此時其變為加粗， 以上所有的文件加載并且渲染完成后，開始渲染下面的標簽“紅色強壯劍靈2”
有一點需要證明：在IE使用樣式對標簽進行渲染時，是不是停止了其他頁面元素的下載?原來我想通過加長渲染時間(利用濾鏡，將標簽元素數目增大)來檢測，不過沒有驗證成功。只是從JS函數的執行推斷CSS的渲染也是如此。
接下來看到的是圖片文件下載，此時看到的是兩個圖片同時開始下載，而且是下載完成后，立即在頁面上開始顯示，直到所有的圖片下載完成。
注：一個測試文件在網絡傳輸上所花費時間的辦法。
首先需要明白檢測中w ait值的意義：wait = 服務器所花時間 + 網絡時間
服務器所花時間我們可以用Thread.Sleep(10000);來讓其休息10s，
比如這個：
由此大概可以計算出 10.002-10 = 0.002秒，這就是大概在網絡上所花的時間。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
