Writing forward-compatible websites

  • 版本網址代稱: Web_development/Writing_forward-compatible_websites
  • 版本標題: Writing forward-compatible websites
  • 版本 ID: 19534
  • 建立日期:
  • 建立者: Sonrisa
  • Is current revision?
  • 回應 308 words added, 9 words removed

版本內容

這個頁面將解釋如何撰寫在新的瀏覽器版本發布時不會遭受毀損的網頁。

這對內聯網和其他非公共網站尤其重要,如果我們不能看到你的原始碼,我們將無法看到它是否已遭受毀損。底下所提到的原則可能無法全數做到,但盡可能遵守這些原則,對於你的網站在未來發展維護上有所幫助。

JavaScriptEdit section

Prefix all global variable access in onfoo attributes with “window.”

使用 "window." 前綴修飾(Prefix) 所有存取於 onfoo屬性的全域變數Edit section

當一個事件處理程序內容屬性(Event Handler content attribute)(例如: onclickonmouseover 等等)被使用在 HTML 的元素上時,所有對於屬性的名稱查找首先發生在元素本身,再者,如果 element 是個 form control 則發生在 element's form,然後是 document,然後是 window(你定義全域變數的地方)。例如,如果你有這樣的標記(markup):

<div onclick="alert(ownerDocument)">Click me</div>

然後點選 text 以提醒 div 的 ownerDocument 。即使是在全域範圍內宣告 var ownerDocument 這種情況依然會發生。

這意味著,無論你何時在事件處理程序內容屬性存取了一個全域變數,包括呼叫任何全域函數,如果一個規範增加了一個新的DOM屬性到具有和你的變數或函式相同名字的元素或文件就可以結束了名稱衝突,瀏覽器使用他。如果出現這種情況,你的函式突然宣告停止這種情況已經多次在各個網站發生HTML5的發展中

為了避免這種情況,完全權限的全域變數可以使用"窗口”,像這樣:

<script>
  function localName() {
    alert('Function localName has been called');
  }
</script>
<div onclick="window.localName()">Clicking me should show an alert<div>

Don't concatenate scripts you don't control

Edit section

"use strict;" 指令在ECMAScript中,當使用於文件級別上,適用於文件中的一切。因此,追加上取決於嚴格模式行為的腳本嚴格的模式的腳本會導致東西被破壞。

Ask the authors of any JavaScript libraries you use to also follow these guidelines

Edit section

推薦喜愛的程式庫給開發者,他們遵循這些指示去開發。如果他們不這樣做,你在未來不能依靠程式庫在未來被破壞不幸,程式庫這些準則是共同的罪犯。

Sniffing

Edit section

Sniff for specific features

Edit section

如果您打算使用某些功能,使用物件偵測去嗅探準確的特點,如果可能的話。舉一個簡單的例子不假設任何瀏覽器中的"filter" in body.style測試必須是真正的Microsoft Internet Explorer,因此window.event對象提供事件處理程序。不要假設以為瀏覽器會支持一個給定的DOM功能的,還必須具備其他一些特別是非標準,DOM功能。或反過來說,他們不會支持一些其他功能(例如,不假設瀏覽器支持onload的腳本元素將永不支持他們的onreadystatechange)。作為瀏覽器的收斂行為,他們都增加新的功能,並刪除它們。他們還修正錯誤。所有這些都發生在過去,會再次發生。

所以,不要一個功能或對象嗅探,然後假設,因為它的存在或不存在,其他一些功能或對象也必須存在或不存在

Don't UA-sniff

Edit section

這的確是假設一個功能(存在一個特定用戶代理(UA)的字符串的子串)意味著大約存在的東西其他功能情況特別常見的實例。

If you have to UA-sniff, only sniff for past browser versions

Edit section

如果你有訴諸於UA嗅探,只用它來針對特定瀏覽器的以往版本。首先,有一個預設的原始碼路徑在未知的瀏覽器和在當前和未來版本的瀏覽器測試運行。然後,如果在預設的原始路徑無法在過去版本的或特定的瀏覽器使用則破損將無法被你的預設原始碼路徑偵測在使用某些功能的情況下嗅探,它是可以添加嗅探針對舊版本特別瀏覽器的駭客。
If you have to resort to UA sniffing, only use it to target past browser versions of particular browsers. First, have a default code path that runs in unknown browsers and in the current and future versions of browsers you are testing with. Then, if the default code path doesn't work in past versions of particular browsers and the breakage cannot be detected by sniffing for the absence of certain features your default code path uses, it's OK to add hacks that are targeted to old versions of particular browsers by sniffing for those old browser versions.
對於這樣的忠告,“當前”意味著你測試的瀏覽器的最新版本。例如,如果你已經測試了預設的原始碼路徑,正常運行Firefox Aurora中,但Firefox的測試版的最新版本有一個錯誤,使您的預設原始碼路徑失敗,/*這是可以治療極光是在Firefox的版本號時刻為“電流”測試*/,並考慮測試版作為“過去”的版本,儘管它並沒有被釋放到廣大市民中。

For the purpose of this piece of advice, "current" means the most recent version of a browser you have tested. For example, if you have tested that your default code path runs properly in Firefox Aurora but Firefox Beta and the latest release have a bug that make your default code path fail,/* it is OK to treat the Firefox version number that is in Aurora at the moment of testing as "current"*/, and consider the Beta version as a "past" version even though it hasn't been released to the general public yet.

Don't unnecessarily create separate codepaths for different browsers

Edit section

不要不用自己的方式來運行不同的原始碼根據任何物體檢測或UA嗅探如果對涉及codepaths之一實際上在所有的瀏覽器。有一個很好的機會改變行為,互相銜接,從而打破你發送一個或多個替代路徑的網站瀏覽器。

Don't go out of your way to run different code based on either object detection or UA sniffing if one of the codepaths involved actually works in all browsers. There is a good chance of browsers changing behavior to converge with each other and hence breaking the site for those you've sent down one or more of the alternative paths.

Testing

Edit section

Test with all major engines

Edit section

測試你的程式碼至少在火狐,Chrome或Safari(因為兩者都基於相同的WebKit引擎),Opera和Internet Explorer。如果您遵循上述這樣,你有一個單一的程式碼路徑對於目前所有的和未知的瀏覽器測試,這種單一的原始碼路徑在所有的主要引擎,使得它極有可能您的程式碼將不會在未來被破壞。

Test your code at least in Firefox, Chrome or Safari (since both are based on the same WebKit engine), Opera, and Internet Explorer. If you are following the advice given above so that you have a single code path for all current and unknown browsers, testing that this single code path works in all the major engines makes it extremely probable that your code won't break in the future.

有時瀏覽器執行一個給定的功能略有不同。如果你有一個單一的程式碼路徑,在所有的頂級引擎中作用,這意味著,你可以使用瀏覽器的行為已經融合的特點,或,如果行為還沒有完全融合,你的程式碼工作堅持標準,無論引擎的行為。

Sometimes browsers implement a given feature slightly differently. If you have a single code path that works in all the top engines, it means that you are either using features where browser behavior has already converged or, if the behavior hasn't quite converged yet, your code works regardless of which engine's behavior standards turn out to uphold.

Browser-specific features and prefixes

Edit section

Don't target hacks at current or future versions of browsers

Edit section

這也是一個共同的假設目前的錯誤之間的相關性之間意味著未來的錯誤相關性的實例。針對舊版本的瀏覽器的當前版本不再有錯誤,你靠你的黑客是確定的,一旦瀏覽器有修改X錯誤,你可以知道,對於某些有錯誤X的所有版本,也有錯誤Ÿ,使用存在缺陷X目標的解決方法去針對錯誤Y。

This is also a common instance of assuming that present correlation between bugs implies future correlation between bugs. Targeting hacks at old versions of browsers whose current versions no longer have the bug you're relying on for your hack is OK; once a browser has fixed bug X, you can know for certain that all releases that had bug X also had bug Y and use the presence of bug X to target workarounds for bug Y.

對於這樣的忠告,“當前”是指一個以上的UA嗅探意見的情況下,你已經測試瀏覽器的最新版本。

For the purpose of this piece of advice, "current" means the most recent version of a browser you have tested, as in the case of the UA sniffing advice above.

Avoid depending on cutting-edge nonstandard features

Edit section

即使前綴功能,使用它可能是危險的:作為規範的發展同樣可以改變瀏覽器的前綴實施跟踪規範。一旦特點被標準化,前綴的版本是有可能被刪除。

Even if the feature is prefixed, using it could be dangerous: as the specification evolves the browser's prefixed implementation can likewise change to track the specification. And once the feature is standardized, the prefixed version is likely to be removed.

前綴,瀏覽器開發者提供非標準功能試驗,並提供反饋,是注定不會被開發。如果您選擇使用它們,需要經常更新您的網站以趕上變化。

Prefixed, non-standard features are provided by browser developers for you to experiment with and offer feedback on, and aren't meant to be deployed. If you choose to use them, be prepared to need to frequently update your site to keep up with changes.

When using cutting-edge features (even standard ones) that are not universally implemented, make sure to test fallback paths

Edit section

要確保測試在瀏覽器中沒有實現的功能當你使用,特別是如果你不每天使用這種瀏覽器當在網站上的工作時。

Make sure to test what happens in a browser that doesn't implement the feature you're using, especially if you don't use such a browser day-to-day while working on the site.

Don't use vendor-prefixed features except to target old buggy versions

Edit section

賣方前綴的功能,可以在將來的版本中改變。然而,一旦瀏覽器出貨量已沒有前綴的功能,您可以使用前綴版本針對舊版本,確保總是使用不帶前綴的功能版本可用時。一個很好的例子,對越南盾的CSS前綴,已售出的牌子,它漂亮的財產沒有前綴的實施,使用行為的價值“有時”,從不同的前綴版本的瀏覽器供應商:

Vendor-prefixed features can change behavior in future releases.  Once a browser has shipped a feature unprefixed, however, you can use the prefixed version to target old releases by making sure to always use the unprefixed version of the feature when available.  A good example, for a browser vendor using the -vnd CSS prefix that has shipped an unprefixed implementation of the make-it-pretty property, with a behavior for the value "sometimes" that differs from the prefixed version:

<style>
  .pretty-element {
    -vnd-make-it-pretty: sometimes;
    make-it-pretty: sometimes;
  }
</style>

上述規則的聲明的順序是很重要的:沒有前綴的人需要排在最後。

The order of the declarations in the rule above is important: the unprefixed one needs to come last.

Don't use unprefixed versions of CSS properties or APIs until at least one browser supports them

Edit section

直到有體面的東西沒有前綴的版本廣泛支持,其行為仍然可以以意想不到的方式改變。最特別的是,的版本,不要使用不帶前綴如果沒有瀏覽器支持。你不能假設,最終版本的語法,將是任何的前綴版本的語法相同。

Until there's decently widespread support of the unprefixed version of something, its behavior can still change in unexpected ways.  Most especially, don't use the unprefixed version if no browser actually supports it. You can't assume that the syntax of the final version will be the same as the syntax of any of the prefixed versions.

Code hygiene

Edit section

Avoid missing >

Edit section

通過一個驗證程序是確保這個問題的方法之一,但即使你的網站沒有完全驗證,你應該確保你所有的>字符呈現。失踪的可能會導致意想不到的情況下由於以下的標記名稱,作為前一個標籤上的屬性處理。這可以工作對一個位元,然後打破規範的含義,該屬性的重視。下面是一個例子,在瀏覽器中工作,不在支持HTML5的瀏覽器:

Passing a validator is one way to ensure this, but even if your website doesn't validate entirely you should make sure all your > characters are present. Missing those can lead to unexpected situations due to a following tag name being treated as an attribute on a previous tag. This can work for a bit, then break if a specification attaches a meaning to that attribute. Here's an example that works in browsers without HTML5 support but breaks in a browser supporting HTML5:

  1. <form action="http://www.example.com">  
  2.   <input type="submit" value="Submit the form"  
  3. </form>  

due to the missing > on the input tag.

Don't leave experiments that didn't work in your code

Edit section

If you try using a CSS property to do something you want, but it has no effect, remove it.  It might start doing something you don't expect in the future.

版本來源

<p>這個頁面將解釋如何撰寫在新的瀏覽器版本發布時不會遭受毀損的網頁。</p>
<p>這對內聯網和<span>其他</span><span>非公共</span>網站尤其重要,如果我們不能看到你的原始碼,我們將無法<span>看到</span><span>它是否已遭受毀損</span>。底下所提到的原則可能無法全數做到,但盡可能遵守這些原則,對於你的網站在未來發展維護上有所幫助。</p>
<div id="section_1"> <h2 class="editable">JavaScript<a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=1" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h2> <div id="section_2"> <h3 class="editable">Prefix all global variable access in <code>onfoo</code> attributes with “<code>window</code>.”</h3> <h3 class="editable"><span class="icon">使用 "window." 前綴修飾(Prefix) 所有存取於 </span><code>onfoo</code><code>屬性</code>的全域變數<a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=2" title="Edit section"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></a></h3> <p><span>當一個</span>事件<span>處理程序</span><span>內容</span><span>屬性(</span>Event Handler content attribute)(例如: <code>onclick</code>, <code>onmouseover</code> 等等)被使用在 HTML 的元素上時,所有對於屬性的名稱查找首先發生在元素本身,再者,如果 element 是個 form control 則發生在 element's form,然後是 document,然後是 window(你定義全域變數的地方)。例如,如果你有這樣的標記(markup):</p> <pre>&lt;div onclick="alert(ownerDocument)"&gt;Click me&lt;/div&gt;</pre> <p><span>然後</span><span>點選 text 以</span>提醒 <span>div 的 </span><span>ownerDocument </span>。即使是在全域範圍內宣告 var ownerDocument 這種情況依然會發生。</p> <p>這意味著,無論你何時在事件處理程序內容屬性存取了一個全域變數,包括呼叫任何全域函數,如果一個規範增加了一個新的DOM屬性到具有和你的變數或函式相同名字的元素<span>或文件</span>就可以結束了名稱衝突,瀏覽器使用他。<span>如果出現這種情況</span>,你的函式突然宣告停止<span>。</span><span>這種情況已經</span><span>多次在各</span><span>個網站發生</span><span>在</span><span>HTML5的</span><span>發展中</span><span>。</span></p> <p><span>為了避免這種情況</span>,完全權限的全域變數可以使用"<span class="atn">窗口”</span>,像這樣:</p> <pre>&lt;script&gt;
  function localName() {
    alert('Function localName has been called');
  }
&lt;/script&gt;
&lt;div onclick="<strong>window.</strong>localName()"&gt;Clicking me should show an alert&lt;div&gt;
</pre> </div> <div id="section_3"> <h3 class="editable">Don't concatenate scripts you don't control</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=3" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p><code>"use strict;"</code> 指令在ECMAScript中,當使用於文件級別上,適用於文件中的一切。因此,追加上<span>取決於</span>非<span>嚴格</span><span>模式</span><span>的</span><span>行為</span>的腳本<span>到</span>嚴格的模式的腳本會導致東西被破壞。</p> </div> <div id="section_4"> <h3 class="editable">Ask the authors of any JavaScript libraries you use to also follow these guidelines</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=4" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p><span>推薦</span><span>你</span><span>喜愛的程式庫給開發者</span>,他們遵循這些指示去開發。如果他們不這樣做,你在未來<span>不能依靠程式庫在未來被破壞</span><span>。</span><span>不幸</span>的<span>是</span><span>,程式庫</span>這些準則是共同的罪犯。</p> </div>
</div>
<div id="section_5"> <h2 class="editable">Sniffing</h2> <div class="editIcon"> <h2 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=5" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h2> </div> <div id="section_6"> <h3 class="editable">Sniff for specific features</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=6" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p><span>如果您打算</span><span>使用某些</span>功能,使用物件偵測去嗅探準確的特點,如果可能的話。舉<span>一個簡單的例子</span><span>,</span><span>不假設</span>任何瀏覽器中的"filter" in body.style測試必須是真正<span>的Microsoft Internet Explorer</span><span>,因此</span><span>如</span><span>將</span>有<span>window.event對象</span>提供事件處理程序。不要假設以為瀏覽器會支持一個給定的DOM功能的,<span>還必須具備</span><span>其他一些</span>,<span>特別是</span><span>非標準</span>,DOM功能。或反過來說,他們不會支持一些其他功能(例如,不假設瀏覽器支持<span>onload的</span><span>腳本元素</span>將永不支持他們的onreadystatechange)。作為瀏覽器的收斂行為,<span>他們都</span><span>增加新的功能</span>,並刪除它們。他們還修正錯誤。所有這些都發生在過去,會再次發生。</p> <p><span>所以,不要</span>為<span>一個</span>功能或對象嗅探,然後假設,因為它的存在或不存在,其他一些功能或對象也必須<span>存在或</span><span>不存在</span><span>。</span></p> </div> <div id="section_7"> <h3 class="editable">Don't UA-sniff</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=7" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p><span>這的確是</span>假設一個功能(存在一個特定用戶代理(UA)的字符串的子串)意味著大約存在的<span>東西</span><span>或</span><span>其他功能</span><span>的</span><span>情況</span><span>下</span><span>,</span><span>特別</span><span>常見</span>的實例。</p> <div id="section_8"> <h4 class="editable">If you have to UA-sniff, only sniff for past browser versions</h4> <div class="editIcon"> <h4 class="editable"><span class="icon"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=8" title="Edit section"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></a></span></h4> </div> <div id="gt-res-wrap"> <div class="almost_half_cell" id="gt-res-content"> <div dir="ltr"><span id="result_box" lang="zh-TW"><span>如果你有</span>訴諸於UA嗅探,只用它來針對特定瀏覽器的以往版本。首先,<span>有一個預設的原始</span><span>碼路徑</span>在未知的瀏覽器和在當前和未來版本的瀏覽器測試運行。然後,如果在預設的原始<span>碼</span><span>路徑無法在</span></span>過去版本的或特定的瀏覽器使用則破損將無法被你的預設原始碼路徑偵測在使用某些功能的情況下嗅探,它是可以添加嗅探針對舊版本特別瀏覽器的駭客。</div> <div dir="ltr">If you have to resort to UA sniffing, only use it to target past browser versions of particular browsers. First, have a default code path that runs in unknown browsers and in the current and future versions of browsers you are testing with. Then, if the default code path doesn't work in past versions of particular browsers and the breakage cannot be detected by sniffing for the absence of certain features your default code path uses, it's OK to add hacks that are targeted to old versions of particular browsers by sniffing for those old browser versions.</div>  <div dir="ltr">對於這樣的忠告,“當前”意味著你測試的瀏覽器的最新版本。例如,如果你已經測試了預設的原始碼路徑,正常運行Firefox Aurora中,但Firefox的測試版的最新版本有一個錯誤,使您的預設原始碼路徑失敗,/*這是可以治療極光是在Firefox的版本號時刻為“電流”測試*/,並考慮測試版作為“過去”的版本,儘管它並沒有被釋放到廣大市民中。</div> </div> </div> <p>For the purpose of this piece of advice, "current" means the most recent version of a browser you have tested. For example, if you have tested that your default code path runs properly in Firefox Aurora but Firefox Beta and the latest release have a bug that make your default code path fail,/* it is OK to treat the Firefox version number that is in Aurora at the moment of testing as "current"*/, and consider the Beta version as a "past" version even though it hasn't been released to the general public yet.</p> </div> </div> <div id="section_9"> <h3 class="editable">Don't unnecessarily create separate codepaths for different browsers</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=9" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>不要不用自己的方式來運行不同的原始碼根據任何物體檢測或UA嗅探如果對涉及codepaths之一實際上在所有的瀏覽器。有一個很好的機會改變行為,互相銜接,從而打破你發送一個或多個替代路徑的網站瀏覽器。</p> <p>Don't go out of your way to run different code based on either object detection or UA sniffing if one of the codepaths involved actually works in all browsers. There is a good chance of browsers changing behavior to converge with each other and hence breaking the site for those you've sent down one or more of the alternative paths.</p> </div>
</div>
<div id="section_10"> <h2 class="editable">Testing</h2> <div class="editIcon"> <h2 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=10" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h2> </div> <div id="section_11"> <h3 class="editable">Test with all major engines</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=11" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>測試你的程式碼至少在火狐,Chrome或Safari(因為兩者都基於相同的WebKit引擎),Opera和Internet Explorer。如果您遵循上述這樣,你有一個單一的程式碼路徑對於目前所有的和未知的瀏覽器測試,這種單一的原始碼路徑在所有的主要引擎,使得它極有可能您的程式碼將不會在未來被破壞。</p> <p>Test your code at least in Firefox, Chrome or Safari (since both are based on the same WebKit engine), Opera, and Internet Explorer. If you are following the advice given above so that you have a single code path for all current and unknown browsers, testing that this single code path works in all the major engines makes it extremely probable that your code won't break in the future.</p> <p>有時瀏覽器執行一個給定的功能略有不同。如果你有一個單一的程式碼路徑,在所有的頂級引擎中作用,這意味著,你可以使用瀏覽器的行為已經融合的特點,或,如果行為還沒有完全融合,你的程式碼工作堅持標準,無論引擎的行為。</p> <p>Sometimes browsers implement a given feature slightly differently. If you have a single code path that works in all the top engines, it means that you are either using features where browser behavior has already converged or, if the behavior hasn't quite converged yet, your code works regardless of which engine's behavior standards turn out to uphold.</p> </div>
</div>
<div id="section_12"> <h2 class="editable">Browser-specific features and prefixes</h2> <div class="editIcon"> <h2 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=12" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h2> </div> <div id="section_13"> <h3 class="editable">Don't target hacks at current or future versions of browsers</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=13" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>這也是一個共同的假設目前的錯誤之間的相關性之間意味著未來的錯誤相關性的實例。針對舊版本的瀏覽器的當前版本不再有錯誤,你靠你的黑客是確定的,一旦瀏覽器有修改X錯誤,你可以知道,對於某些有錯誤X的所有版本,也有錯誤Ÿ,使用存在缺陷X目標的解決方法去針對錯誤Y。</p> <p>This is also a common instance of assuming that present correlation between bugs implies future correlation between bugs. Targeting hacks at <strong>old</strong> versions of browsers whose current versions no longer have the bug you're relying on for your hack is OK; once a browser has fixed bug X, you can know for certain that all releases that had bug X also had bug Y and use the presence of bug X to target workarounds for bug Y.</p> <p>對於這樣的忠告,“當前”是指一個以上的UA嗅探意見的情況下,你已經測試瀏覽器的最新版本。</p> <p>For the purpose of this piece of advice, "current" means the most recent version of a browser you have tested, as in the case of the UA sniffing advice above.</p> </div> <div id="section_14"> <h3 class="editable">Avoid depending on cutting-edge nonstandard features</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=14" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>即使前綴功能,使用它可能是危險的:作為規範的發展同樣可以改變瀏覽器的前綴實施跟踪規範。一旦特點被標準化,前綴的版本是有可能被刪除。</p> <p>Even if the feature is prefixed, using it could be dangerous: as the specification evolves the browser's prefixed implementation can likewise change to track the specification. And once the feature is standardized, the prefixed version is likely to be removed.</p> <p>前綴,瀏覽器開發者提供非標準功能試驗,並提供反饋,是注定不會被開發。如果您選擇使用它們,需要經常更新您的網站以趕上變化。</p> <p>Prefixed, non-standard features are provided by browser developers for you to experiment with and offer feedback on, and aren't meant to be deployed. If you choose to use them, be prepared to need to frequently update your site to keep up with changes.</p> </div> <div id="section_15"> <h3 class="editable">When using cutting-edge features (even standard ones) that are not universally implemented, make sure to test fallback paths</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=15" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>要確保測試在瀏覽器中沒有實現的功能當你使用,特別是如果你不每天使用這種瀏覽器當在網站上的工作時。</p> <p>Make sure to test what happens in a browser that doesn't implement the feature you're using, especially if you don't use such a browser day-to-day while working on the site.</p> </div> <div id="section_16"> <h3 class="editable">Don't use vendor-prefixed features except to target old buggy versions</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=16" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>賣方前綴的功能,可以在將來的版本中改變。然而,一旦瀏覽器出貨量已沒有前綴的功能,您可以使用前綴版本針對舊版本,確保總是使用不帶前綴的功能版本可用時。一個很好的例子,對越南盾的CSS前綴,已售出的牌子,它漂亮的財產沒有前綴的實施,使用行為的價值“有時”,從不同的前綴版本的瀏覽器供應商:</p> <p>Vendor-prefixed features can change behavior in future releases.  Once a browser has shipped a feature unprefixed, however, you can use the prefixed version to target old releases by making sure to always use the unprefixed version of the feature when available.  A good example, for a browser vendor using the <code>-vnd</code> CSS prefix that has shipped an unprefixed implementation of the <code>make-it-pretty</code> property, with a behavior for the value <code>"sometimes"</code> that differs from the prefixed version:</p> <pre>&lt;style&gt;
  .pretty-element {
    -vnd-make-it-pretty: sometimes;
    make-it-pretty: sometimes;
  }
&lt;/style&gt;
</pre> <p>上述規則的聲明的順序是很重要的:沒有前綴的人需要排在最後。</p> <p>The order of the declarations in the rule above is important: the unprefixed one needs to come last.</p> </div> <div id="section_17"> <h3 class="editable">Don't use unprefixed versions of CSS properties or APIs until at least one browser supports them</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=17" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>直到有體面的東西沒有前綴的版本廣泛支持,其行為仍然可以以意想不到的方式改變。最特別的是,的版本,不要使用不帶前綴如果沒有瀏覽器支持。你不能假設,最終版本的語法,將是任何的前綴版本的語法相同。</p> <p>Until there's decently widespread support of the unprefixed version of something, its behavior can still change in unexpected ways.  Most especially, don't use the unprefixed version if no browser actually supports it. You can't assume that the syntax of the final version will be the same as the syntax of any of the prefixed versions.</p> </div>
</div>
<div id="section_18"> <h2 class="editable">Code hygiene</h2> <div class="editIcon"> <h2 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=18" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h2> </div> <div id="section_19"> <h3 class="editable">Avoid missing <code>&gt;</code></h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=19" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>通過一個驗證程序是確保這個問題的方法之一,但即使你的網站沒有完全驗證,你應該確保你所有的&gt;字符呈現。失踪的可能會導致意想不到的情況下由於以下的標記名稱,作為前一個標籤上的屬性處理。這可以工作對一個位元,然後打破規範的含義,該屬性的重視。下面是一個例子,在瀏覽器中工作,不在支持HTML5的瀏覽器:</p> <p>Passing a validator is one way to ensure this, but even if your website doesn't validate entirely you should make sure all your <code>&gt;</code> characters are present. Missing those can lead to unexpected situations due to a following tag name being treated as an attribute on a previous tag. This can work for a bit, then break if a specification attaches a meaning to that attribute. Here's an example that works in browsers without HTML5 support but breaks in a browser supporting HTML5:</p> <div class="dp-highlighter"> <div class="bar"> <div class="tools"><a href="/en/Web_development/Writing_forward-compatible_websites#" title="en/Web_development/Writing_forward-compatible_websites#">view plain</a><a href="/en/Web_development/Writing_forward-compatible_websites#" title="en/Web_development/Writing_forward-compatible_websites#">print</a><a href="/en/Web_development/Writing_forward-compatible_websites#" title="en/Web_development/Writing_forward-compatible_websites#">?</a></div> </div> <ol class="dp-xml" start="1"> <li class="alt"><span class="tag">&lt;</span><span class="tag-name">form</span> <span class="attribute">action</span>=<span class="attribute-value">"<a class=" external" href="http://www.example.com" rel="freelink">http://www.example.com</a>"</span><span class="tag">&gt;</span>  </li> <li>  <span class="tag">&lt;</span><span class="tag-name">input</span> <span class="attribute">type</span>=<span class="attribute-value">"submit"</span> <span class="attribute">value</span>=<span class="attribute-value">"Submit the form"</span>  </li> <li class="alt"><span class="tag">&lt;/</span><span class="tag-name">form</span><span class="tag">&gt;</span>  </li> </ol> </div> <p>due to the missing <code>&gt;</code> on the <code>input</code> tag.</p> </div> <div id="section_20"> <h3 class="editable">Don't leave experiments that didn't work in your code</h3> <div class="editIcon"> <h3 class="editable"><a href="/en/Web_development/Writing_forward-compatible_websites?action=edit&amp;sectionId=20" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="/skins/common/icons/icon-trans.gif"></span></a></h3> </div> <p>If you try using a CSS property to do something you want, but it has no effect, remove it.  It might start doing something you don't expect in the future.</p> </div>
</div>
Revert to this revision