用pre控件一是為了讓字體等寬避免寬度的微小變化,二是可以方便的填空格進去調整寬度而不用填
打開關閉狀態可以通過讀取元素的c屬性,當然也可以直接用標記相應屬性的全局變量來代替,免去了再讀取元素屬性的麻煩:
6月11號
嗯,在這里要再三強調一下,本人接受過一段時間的自衛術訓練,包括如何在這樣的情形下與身材比自己大一圈的對手搏斗,我們都是有過若干預案的,比如偷襲(第一預案,當時不具備這個條件);尋找手持武器自衛(第二預案,除了被搶去的iPad,手里只剩一個單反相機了,作為攝影協會老會員,這個預案也必須否決);裝瘋(撲上去大喊大叫亂打一氣,逮到機會就抱緊對手狠咬一口,從氣勢上嚇懵對手————考慮到自己門牙打過補丁,咬人這招不到萬不得已不用)。圍觀群眾切勿效仿。
(醫院給病人套一個腕帶,把我的名字拼錯了。把寫在名字前面的visa的issue place當成first name了)
12號
(iPad尸體)
(換機協議)
(網友普遍認為這個apple guy很帥)
13號
14號
早上把美國拍片的結果發給馬醫生看,馬醫生初步認為8、9肋骨輕微骨折,無錯位。7肋骨可疑。
下午重新排了片,劉主任分析結果,骨頭問題不大,主要是軟組織拉上,開了些中藥,建議靜養幾天。
第一個cache-read耗時0.2秒多,第二個(并行發起)0.3秒多,第三個0.4秒多,接下去每個圖片的耗時差不多都比上一個慢0.1秒以上。結論很明顯了,并發的cache-read會相互堵塞,非常嚴重的相互堵塞。
以上抓包是在IE6下完成的。在IE7和IE8下面情況要好一些,但是問題性質是相同的。
很多我們曾經以為cache的非常好速度應該非??斓膚eb應用,也許其實存在著嚴重的cache-read速度瓶頸而不為我們所知。
網上沒有搜到太多關于cache-read時間的文章,看來真是個盲點。
解決方案和網絡延遲是類似的,減少cache-read請求,把多個小文件和小圖片合并成大文件和大圖片(而不要一廂情愿的以為小文件被瀏覽器緩存后會有很好的速度表現),區分優先級引用資源。還有一個可能有用的:交錯的發起不可避免的異步動態網絡請求和cache-read請求,讓網絡延遲和cache-read延遲時間疊加在一起,來節省用戶實際要等待的時間。
文章作者說“跑到微軟那一查,給的答復讓我吐血:Do not enable HTTP compression for the script files 請不要對腳本文件開啟http壓縮 只好在服務器端增加對瀏覽器的識別代碼,如果是ie6,就不壓縮腳本文件了 雖然腳本能運行了,可是用戶體驗就... 哎,我恨ie 6”
唉,說啥好呢?
真相是,微軟的答復(http://support.microsoft.com/kb/327286/en-us?sid=64&spid=2073) 里面提供了兩個解決方案,其中第一個描述的稍微啰嗦了一點,被這個作者直接忽略掉了。第二個解決方案只有一句話,顯然更容易被讀懂:
If you use a Cache-Control: no-cache HTTP header to prevent the files from caching, remove that header. In some situations, if you substitute an Expires HTTP header, you do not trigger the problem.
-or-
Do not enable HTTP compression for the script files.
Emu雖然英文比較爛,四級老考不過,為了方便大家還是翻譯一下吧,不然又該有人讀不下去了。
1.如果你使用了Cache-Control: no-cache 這個 HTTP 頭來防止文件被緩存,移除這個頭就好了。有些情況下,如果你用一個Expires頭來代替(前面這個出問題的http頭),(也可以起到相同作用而)不會觸發這個問題。
或者
2.不要壓縮腳本文件。作者: KeeKim Heng, Google Web Developer
在我們開發互聯網富應用(RIA)時,我們經常寫一些javascript腳本來修改或者增加頁面元素,這些工作最終是DOM——或者說文檔對象模型——來完成的,而我們的實現方式會影響到應用的響應速度。
DOM操作會導致瀏覽器重解析(reflow),這是瀏覽器的一個決定頁面元素如何展現的計算過程。直接修改DOM,修改元素的CSS樣式,修改瀏覽器的窗口大小,都會觸發重解析。讀取元素的布局屬性比如offsetHeithe或者offsetWidth也會觸發重解析。重解析需要花費計算時間,因此重解析觸發的越少,應用就會越快。
DOM操作通常要不就是修改已經存在的頁面上的元素,要不就是創建新的頁面元素。下面的4種優化方案覆蓋了修改和創建DOM節點兩種方式,幫助你減少觸發瀏覽器重解析的次數。
方案一:通過CSS類名切換來修改DOM
這個方案讓我們可以一次性修改一個元素和它的子元素的多個樣式屬性而只觸發一次重解析。
需求:
(emu注:原文作者寫到這里的時候腦子顯然短路了一下,把后面的Out-of-the-flow DOM Manipulation模式要解決的問題給擺到這里來了,不過從示范代碼中很容易明白作者真正想描述的問題,因此emu就不照翻原文了)
我們現在需要寫一個函數來修改一個超鏈接的幾個樣式規則。要實現很簡單,把這幾個規則對應的屬性逐一改了就好了。但是帶來的問題是,每修改一個樣式屬性,都會導致一次頁面的重解析。
解決方案
要解決這個問題,我們可以先創建一個樣式名,并且把要修改的樣式規則都放到這個類名上,然后我們給超鏈接添加上這個新類名,就可以實現添加幾個樣式規則而只觸發一次重解析了。這個模式還有個好處是也實現了表現和邏輯相分離。
(emu注:作者在這里再次腦子短路,把DocumentFragment DOM Generation模式的介紹提前到這里來了,emu只好再次發揮一下)
上一個方案解決的是修改一個超鏈接的問題,當一次需要對很多個超鏈接進行相同修改的時候,這個方案就可以大顯身手了。
需求
需求是這樣的,我們要寫一個函數來修改一個指定元素的子元素中所有的超鏈接的樣式名(className)屬性。要實現很簡單,我們可以通過遍歷每個超鏈接并且修改它們的樣式名來完成任務。但是帶來的問題就是,每修改一個超鏈接都會導致一次重解析。
解決方案
要解決這個問題,我們可以把被修改的指定元素從DOM里面移除,再修改所有的超鏈接,然后在把這個元素插入回到它原來的位置上。為了完成這個復雜的操作,我們可以先寫一個可重用的函數,它不但移除了這個DOM節點,還返回了一個把元素插回到原來的位置的函數。
方案三:一次性的DOM元素生成
這個方案讓我們創建一個元素的過程只觸發一次重解析。在創建完元素以后,先進行所有需要的修改,最后才把它插入到DOM里面去就可以了
需求
需求是這樣的,實現一個函數,往一個指定的父元素上插入一個超鏈接元素。這個函數要同時可以設置這個超鏈接的顯示文字和樣式類。我們可以這樣做:創建元素,插入到DOM里面,然后設置相應的屬性。這就要觸發3次重解析。
解決方案
很簡單,我們只要把插入元素這個操作放到最后做,就可以只進行一次重解析了。
不過,要是我們想要插入很多個超鏈接到一個元素里面的話,那么這個做法還是有問題:每插入一個超鏈接還是要觸發一次重解析。下一個方案可以解決這個問題。
方案四:通過文檔片段對象(DocumentFragment)創建一組元素
這個方案允許我們創建并插入很多個元素而只觸發一次重解析。要實現這點需要用到所謂的文檔片段對象(DocumentFragment)。我們先在DOM之外創建一個文檔片段對象(這樣它也就不需要解析和渲染),然后我們在文檔片段對象中創建很多個元素,最后我們把這個文檔片段對象中所有的元素一次性放到DOM里面去,只觸發一次重解析。
需求
我們要寫一個函數,往一個指定的元素上面增加10個超鏈接。如果我們簡單的直接插入10個超鏈接到元素上面,就會觸發10次重解析。
解決方案
要解決這個問題,我們要先創建一個文檔片段對象,然后把每個新創建的超鏈接都插入到它里面去。當我們把文檔片段對象用appendChild命令插入到指定的節點時,這個文檔片段對象的所有子節點就一起被插入到指定的元素里面,而且只需要觸發一次重解析。
Functions invoked by setTimeout are passed an extra "lateness" argument in Mozilla, i.e., the lateness of the timeout in milliseconds.
使用谷歌瀏覽器(chrome)的時候,有的時候腳本程序會捕獲到“Uncaught TypeError: Object #<an HTMLObjectElement> has no method 'create' ”這個錯誤,在chrome的用戶論壇上也有人在問這個問題。
這個錯誤應該是由于最新版的谷歌瀏覽器沒有自帶完整的google gears組件導致的??雌饋碜钚掳娴腸hrome瀏覽器會在用戶第一次使用gears組件的時候自動下載和安裝該組件,而在安裝成功以前我們雖然可以成功創建 application/x-googlegears 對象,卻無法調用它的create方法創建任何有用的東西。
這個時候其實沒有太多的事情可以做,基本上我們我們只能檢測這個對象的create接口是否存在,發現不存在的時候提示用戶耐心等待,過一段時間后再刷新,或者下回再來看看,希望它已經自己安裝好了。