Web標準前途是否依賴瀏覽器技術
互聯(lián)網(wǎng) 發(fā)布時間:2008-10-17 19:22:00 作者:佚名
我要評論
當我讀了一遍Aaron Gustafson的Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 后,我心里的第一反應就是深深的否定這種觀點. Aaron描述的version-targeting機制是
加快發(fā)展
我們已經有了一個版本目標的例子(Doctype轉換). 當我用這種方法實現(xiàn)了, 我卻陷入了混亂. 畢竟, 我是Doctype轉換的推行者, 并且現(xiàn)在還在依賴它進行工作. 我應該憎恨這整個想法嗎, 或者不?
就像在2000年的Doctype轉換, 版本目標否定廠商的說法,怕破壞了現(xiàn)有的網(wǎng)站,現(xiàn)有的行為是不能改變的. 如果IE 8能夠修正它對一些CSS屬性或DOM方法的實現(xiàn)的話, 那在IE 9中的錯誤我們就可以在站點不被破壞的基礎上修正了.
而且, 如果這一切就像標榜的那樣, 那最終會讓web開發(fā)更少的依賴于虛擬計算機. 如果你需要支持當前的瀏覽器,又要顧及之前版本的, 你只需要更改你的X-UA-Compatible值到一個較早的版本然后看看事情變得怎么樣了 - 不需要VirtualPC的副本. 這不會立刻發(fā)生, 但是這是合理的最終結局. 新的嗅探測試
我們超越了瀏覽器嗅探, 不是嗎? 沒有人把這稱為 "脆弱" 與 "弄巧成拙"?
我們知道的瀏覽器嗅探技術和版本目標器之間有至關重要的差別. 首先, "瀏覽器嗅探技術" 在現(xiàn)在意味著 "編寫代碼檢查正在用什么瀏覽器, 然后對標簽/CSS/JS/服務器端響應/任何東西進行相應的調整." 版本目標器完全相反, 它讓 "瀏覽器自己檢查頁面是什么時候開發(fā)的, 并做出相應的調整." 換句話說, 版本目標把web開發(fā)者從嗅探中解放出來, 并把這個責任交給瀏覽器開發(fā)商.
這不是個能輕松討論的改變. 瀏覽器的實現(xiàn)者們常用資源有限的借口來回絕我們, 但是卻依然指揮著比我們之中的任何人能召集的還要多的資源和技術進行回退測試. 而且, 瀏覽器開發(fā)商對確保版本目標像承諾的那樣不破壞舊站點比網(wǎng)站作者更新舊站點以支持新瀏覽器具有更大的既得利益. 后知后覺的好處
瀏覽器嗅探技術和版本目標器之間的第二個區(qū)別是瀏覽器嗅探技術是向未來看, 而版本目標器是向過去看. 向未來看是瀏覽器嗅探之所以脆弱的主要原因之一: 很難去預知未來. 舉例來說: Safari在用戶端的標識符中包含了"like Gecko"讓很大一群嗅探腳本出錯了 - 甚至是那些做得比較好的. 這些腳本的作者因為不能預知一個Apple的non-Gecko的瀏覽器會在用戶端標識符中包含"Gecko"這個詞而完全失敗了.
現(xiàn)在, 我們的前景是瀏覽器自身會做瀏覽器嗅探了, 然后會向后看了, 這會有更多的穩(wěn)定性: 過去的總是比預知未來更容易掌握.
此外, 我們已經為瀏覽器們寫了足夠的腳本和Hacks來適應他們, 是不是該是瀏覽器開始來適應我們的頁面的時候了? 總而言之
我們知道向前兼容的研究工作. 更多的是, 雖然關于它的一切我們都知道了. 在互聯(lián)網(wǎng)初始的時候, 除Doctype轉換以外, 瀏覽器一直是以"所見即所得"為目標的. 開發(fā)者們在推測未來的瀏覽器要做什么的同時還要被迫保持和過去的瀏覽器一樣的行為.
向前兼容的發(fā)展以及它的親戚: 逐步加強是適合的,必須的, 因為這是我們的網(wǎng)站能在未來正常工作的唯一希望. 對向前兼容的歌頌在我們工作的世界中是必需的.
在另一個瀏覽器開始采用版本目標的世界里, 可能就是另一種選擇了. 誰會知道會發(fā)生什么? 可能我們會發(fā)現(xiàn)向前兼容變得非常脆弱, 甚至相當可笑.
我們說向前兼容的發(fā)展是衡量一個專家的的標志, 因為我們的直接決定了這樣. 版本目標的出現(xiàn), 那種要求可能就會完全消失了, 呈現(xiàn)出來的不再出錯,但是變得毫無意義. 雖然我根深蒂固的本能仍在抵抗這種結論, 但是我不得不進我最大的努力去看這個可能會發(fā)生的未來, 然后問自己, 這會不會比我們知道更好或是更壞?
這看起來更好.
在最后, 讓我非常震驚的, 我原來并不討厭這個想法. 版本目標使瀏覽器更容易開發(fā)新的功能, 并且在原有功能上修復錯誤和缺點, 這會潛在的加速web設計和發(fā)展, 單單這一個理由就就足夠給它一個機會了. 是的, 但是...
當然, 我還是有所顧慮.
最大的顧慮是保真度. 會不會IE 8的向后兼容代碼工作起來看起來還是像IE 8一樣, 或者會不會有細微的改變但是還是破壞了舊的網(wǎng)站? 可能會這樣, 但是我們不敢說, 新的缺陷會影響未來瀏覽器的向后兼容嗎? 畢竟, 門會向兩邊擺: 廠商可能會讓他們的"向后看"代碼不是很嚴密, 就像開發(fā)者可能會讓他們的 "向前看" 代碼不是很嚴密一樣. 諷刺一下.
另一個小小的顧慮是版本目標代碼在瀏覽器程序上的大小問題. 這會讓瀏覽器變成一個臃腫的程序嗎? 一些人會認為 "誰在意啊? 現(xiàn)在的硬盤都很大了!" 但是我仍舊堅定的不同意"資源廉價"的觀點. 不管它們如何的廉價, 那也都是人們努力出來的. 我真誠的希望未來的瀏覽器不會需要1或2G的存儲空間, 它的歷代版本Jacob Marley他過去的行為一樣. 名詞解釋
我完全不是 "edge" 這個詞的崇拜者. 原因是, 它的存在似乎使每個人都用自己的方法使用鎖定機制, 比如 "IE=1024"或是其他更大的數(shù)字. 問題在于提供一個關鍵詞當量創(chuàng)建一個官方賦予的氛圍的事情, 我不認為microsoft會提供. 讓所有人都使用這個機制是他們的利益所在, 這個關鍵字在希望取消它的人們面前充當著一個眼色,一個點頭. 我完全贊同人們遵守這個鎖定機制,如果他們希望的話 - 我能更好地完成這個工作, 但是這需要用到hacks, 而并不是官方的關鍵字.
Doctype作為版本目標
我想我會感到高興, 如果頁面在不使用任何版本目標信息也能被處理的話. 如果一個頁面不包含任何版本目標信息, 那么Doctype就會充當版本目標的代理人. 比如說, 所有的HTML 4和XHTML 1的Doctype會在IE 7中作為默認鎖定值. 在未來, HTML 5的Doctype會作為IE 9或IE 10的默認鎖定值, 這取決于被打開的文件.
當然, 開發(fā)者可以提供一個明確的瀏覽器版本來忽略所有的: 一個 HTML 2的文檔可以被IE9鎖定, 一個HTML 6的文檔可以被IE 7鎖定. 但是在沒有明確的版本目標信息時, Doctype要作為替身來連接到一個特定的版本. Microsoft的觀點, 這是必需的: 如果沒有這種方式, 沒有目標的頁面會被新版本的IE破壞. 我了解這點. 但是這意味著為了能像他們本來的樣子那樣處理頁面, 隨著瀏覽器的進步, 你就必須為目標機制作Hacks: 用一個很大的版本號數(shù)字 - 或者用edge關鍵字, 如果它沒有被剔除的話.
最大的挑戰(zhàn), 似乎是, 他們必須確保版本目標在未來的瀏覽器中以這樣的方式運作而要像Doctype轉換那樣的不會破壞網(wǎng)站功能. 換句話說, 我們還要確保它的向前兼容.
我想我的那些本能最后又出現(xiàn)在身邊了.
我們已經有了一個版本目標的例子(Doctype轉換). 當我用這種方法實現(xiàn)了, 我卻陷入了混亂. 畢竟, 我是Doctype轉換的推行者, 并且現(xiàn)在還在依賴它進行工作. 我應該憎恨這整個想法嗎, 或者不?
就像在2000年的Doctype轉換, 版本目標否定廠商的說法,怕破壞了現(xiàn)有的網(wǎng)站,現(xiàn)有的行為是不能改變的. 如果IE 8能夠修正它對一些CSS屬性或DOM方法的實現(xiàn)的話, 那在IE 9中的錯誤我們就可以在站點不被破壞的基礎上修正了.
而且, 如果這一切就像標榜的那樣, 那最終會讓web開發(fā)更少的依賴于虛擬計算機. 如果你需要支持當前的瀏覽器,又要顧及之前版本的, 你只需要更改你的X-UA-Compatible值到一個較早的版本然后看看事情變得怎么樣了 - 不需要VirtualPC的副本. 這不會立刻發(fā)生, 但是這是合理的最終結局. 新的嗅探測試
我們超越了瀏覽器嗅探, 不是嗎? 沒有人把這稱為 "脆弱" 與 "弄巧成拙"?
我們知道的瀏覽器嗅探技術和版本目標器之間有至關重要的差別. 首先, "瀏覽器嗅探技術" 在現(xiàn)在意味著 "編寫代碼檢查正在用什么瀏覽器, 然后對標簽/CSS/JS/服務器端響應/任何東西進行相應的調整." 版本目標器完全相反, 它讓 "瀏覽器自己檢查頁面是什么時候開發(fā)的, 并做出相應的調整." 換句話說, 版本目標把web開發(fā)者從嗅探中解放出來, 并把這個責任交給瀏覽器開發(fā)商.
這不是個能輕松討論的改變. 瀏覽器的實現(xiàn)者們常用資源有限的借口來回絕我們, 但是卻依然指揮著比我們之中的任何人能召集的還要多的資源和技術進行回退測試. 而且, 瀏覽器開發(fā)商對確保版本目標像承諾的那樣不破壞舊站點比網(wǎng)站作者更新舊站點以支持新瀏覽器具有更大的既得利益. 后知后覺的好處
瀏覽器嗅探技術和版本目標器之間的第二個區(qū)別是瀏覽器嗅探技術是向未來看, 而版本目標器是向過去看. 向未來看是瀏覽器嗅探之所以脆弱的主要原因之一: 很難去預知未來. 舉例來說: Safari在用戶端的標識符中包含了"like Gecko"讓很大一群嗅探腳本出錯了 - 甚至是那些做得比較好的. 這些腳本的作者因為不能預知一個Apple的non-Gecko的瀏覽器會在用戶端標識符中包含"Gecko"這個詞而完全失敗了.
現(xiàn)在, 我們的前景是瀏覽器自身會做瀏覽器嗅探了, 然后會向后看了, 這會有更多的穩(wěn)定性: 過去的總是比預知未來更容易掌握.
此外, 我們已經為瀏覽器們寫了足夠的腳本和Hacks來適應他們, 是不是該是瀏覽器開始來適應我們的頁面的時候了? 總而言之
我們知道向前兼容的研究工作. 更多的是, 雖然關于它的一切我們都知道了. 在互聯(lián)網(wǎng)初始的時候, 除Doctype轉換以外, 瀏覽器一直是以"所見即所得"為目標的. 開發(fā)者們在推測未來的瀏覽器要做什么的同時還要被迫保持和過去的瀏覽器一樣的行為.
向前兼容的發(fā)展以及它的親戚: 逐步加強是適合的,必須的, 因為這是我們的網(wǎng)站能在未來正常工作的唯一希望. 對向前兼容的歌頌在我們工作的世界中是必需的.
在另一個瀏覽器開始采用版本目標的世界里, 可能就是另一種選擇了. 誰會知道會發(fā)生什么? 可能我們會發(fā)現(xiàn)向前兼容變得非常脆弱, 甚至相當可笑.
我們說向前兼容的發(fā)展是衡量一個專家的的標志, 因為我們的直接決定了這樣. 版本目標的出現(xiàn), 那種要求可能就會完全消失了, 呈現(xiàn)出來的不再出錯,但是變得毫無意義. 雖然我根深蒂固的本能仍在抵抗這種結論, 但是我不得不進我最大的努力去看這個可能會發(fā)生的未來, 然后問自己, 這會不會比我們知道更好或是更壞?
這看起來更好.
在最后, 讓我非常震驚的, 我原來并不討厭這個想法. 版本目標使瀏覽器更容易開發(fā)新的功能, 并且在原有功能上修復錯誤和缺點, 這會潛在的加速web設計和發(fā)展, 單單這一個理由就就足夠給它一個機會了. 是的, 但是...
當然, 我還是有所顧慮.
最大的顧慮是保真度. 會不會IE 8的向后兼容代碼工作起來看起來還是像IE 8一樣, 或者會不會有細微的改變但是還是破壞了舊的網(wǎng)站? 可能會這樣, 但是我們不敢說, 新的缺陷會影響未來瀏覽器的向后兼容嗎? 畢竟, 門會向兩邊擺: 廠商可能會讓他們的"向后看"代碼不是很嚴密, 就像開發(fā)者可能會讓他們的 "向前看" 代碼不是很嚴密一樣. 諷刺一下.
另一個小小的顧慮是版本目標代碼在瀏覽器程序上的大小問題. 這會讓瀏覽器變成一個臃腫的程序嗎? 一些人會認為 "誰在意啊? 現(xiàn)在的硬盤都很大了!" 但是我仍舊堅定的不同意"資源廉價"的觀點. 不管它們如何的廉價, 那也都是人們努力出來的. 我真誠的希望未來的瀏覽器不會需要1或2G的存儲空間, 它的歷代版本Jacob Marley他過去的行為一樣. 名詞解釋
我完全不是 "edge" 這個詞的崇拜者. 原因是, 它的存在似乎使每個人都用自己的方法使用鎖定機制, 比如 "IE=1024"或是其他更大的數(shù)字. 問題在于提供一個關鍵詞當量創(chuàng)建一個官方賦予的氛圍的事情, 我不認為microsoft會提供. 讓所有人都使用這個機制是他們的利益所在, 這個關鍵字在希望取消它的人們面前充當著一個眼色,一個點頭. 我完全贊同人們遵守這個鎖定機制,如果他們希望的話 - 我能更好地完成這個工作, 但是這需要用到hacks, 而并不是官方的關鍵字.
Doctype作為版本目標
我想我會感到高興, 如果頁面在不使用任何版本目標信息也能被處理的話. 如果一個頁面不包含任何版本目標信息, 那么Doctype就會充當版本目標的代理人. 比如說, 所有的HTML 4和XHTML 1的Doctype會在IE 7中作為默認鎖定值. 在未來, HTML 5的Doctype會作為IE 9或IE 10的默認鎖定值, 這取決于被打開的文件.
當然, 開發(fā)者可以提供一個明確的瀏覽器版本來忽略所有的: 一個 HTML 2的文檔可以被IE9鎖定, 一個HTML 6的文檔可以被IE 7鎖定. 但是在沒有明確的版本目標信息時, Doctype要作為替身來連接到一個特定的版本. Microsoft的觀點, 這是必需的: 如果沒有這種方式, 沒有目標的頁面會被新版本的IE破壞. 我了解這點. 但是這意味著為了能像他們本來的樣子那樣處理頁面, 隨著瀏覽器的進步, 你就必須為目標機制作Hacks: 用一個很大的版本號數(shù)字 - 或者用edge關鍵字, 如果它沒有被剔除的話.
最大的挑戰(zhàn), 似乎是, 他們必須確保版本目標在未來的瀏覽器中以這樣的方式運作而要像Doctype轉換那樣的不會破壞網(wǎng)站功能. 換句話說, 我們還要確保它的向前兼容.
我想我的那些本能最后又出現(xiàn)在身邊了.
相關文章

AudioContext 實現(xiàn)音頻可視化(web技術分享)
這篇文章主要分享的是web技術的 AudioContext 實現(xiàn)音頻可視化,要實現(xiàn)音頻可視化得先實現(xiàn)一些炫酷的效果需要借助 Web Audio API提供的一些方法 AudioContext,下面詳細內容2022-02-23
這篇文章主要給大家介紹了web技術中的WebRTC記錄音視頻流,文章內容圍繞主題展相關資料,需要的小伙伴可以參考一下,希望對你有所幫助2022-02-23- 這是我通過網(wǎng)上查閱資料總結的一些編碼規(guī)范,用于鞏固對html,css頁面重構時的基礎,需要的朋友可以參考下2020-12-19
前端編碼規(guī)范(4)—— CSS 和 Sass (SCSS) 開發(fā)規(guī)范
這篇文章主要介紹了前端編碼規(guī)范(4)—— CSS 和 Sass (SCSS) 開發(fā)規(guī)范,需要的朋友可以參考下2017-01-21Web前端開發(fā)規(guī)范2017(HTML/JavaScript/CSS)
這是一份旨在增強團隊的開發(fā)協(xié)作,提高代碼質量和打造開發(fā)基石的編碼風格規(guī)范,其中包含了 HTML, JavaScript 和 CSS/SCSS 這幾個部分。我們知道,當一個團隊開始指定并實行2017-01-21- 這篇文章主要為大家介紹了前端開發(fā)團隊遵循和約定的代碼書寫規(guī)范,意在提高代碼的規(guī)范性和可維護性,需要的朋友可以參考下2017-01-21
- 這篇文章主要為大家詳細介紹了響應式Web之流式網(wǎng)格系統(tǒng)的相關資料,感興趣的小伙伴們可以參考一下2016-07-04
在網(wǎng)頁標題欄上和收藏夾顯示網(wǎng)站logo的實現(xiàn)方法
下面小編就為大家分享一篇在網(wǎng)頁標題欄上和收藏夾顯示網(wǎng)站logo的實現(xiàn)方法。希望對大家有所幫助。一起跟隨小編過來看看吧,祝大家游戲愉快哦2016-03-16- 基于很多用戶都在下載Visual Foxpro 6.0,但是有安裝vtp6.0經驗的朋友確很少,在安裝過程中總會出現(xiàn)這樣那樣的問題,基于這些問題,下面小編抽個時間把Visual Foxpro 6.02015-09-09
網(wǎng)站日志200 0 64狀態(tài)碼的分析(協(xié)議子狀態(tài))
網(wǎng)站日志200 0 64狀態(tài)碼的分析介紹2012-10-29



