伴隨着Web標準發展

原創 vic78 2020-06-16 14:01

內容

  1. 簡介
  2. 歷史
  3. Web標準
  4. 結構和表現
  5. (X)HTML（可擴展超文本置標語言）
  6. CSS(層疊式樣式表)
  7. 可訪問性
  8. URLs(頁面地址)
  9. 參考資料
  10. 專業詞彙

1. 簡介

本文闡述了Web標準是如何使一個開發者建設網站更加的節省時間與金錢，如何使瀏覽者獲得更好的瀏覽經歷，以及他們的原因。同時，討論中還涉及到一些方法，準則和好的實例用來幫助您建設一個對儘可能多的人都充滿親和力的高質量的網站。

2. 歷史

在90年代後期，當互聯網和web逐漸成爲主流時，Web瀏覽器的開發商還沒有完全的支持CSS（層疊式樣式表，對於Web開發人員來說，他們可以用CSS來控制Html文檔的表現）。考慮到CSS1是在1996年制定的，而CSS2是在1998年才制定的，所以這種對CSS支持的不足也是可以理解的。

由於瀏覽器對CSS的支持不夠，再加上一些平面設計師的要求（這些要求與他們經常與印刷品打交道有關）導致他們爲了控制網頁的視覺表現而濫用HTML。一個典型的例子就是，當設計師可以用border="0"來隱藏表格的邊框時，用隱藏表格來控制佈局的方法同樣被使用。另一個例子是對“transparent”（透明）的使用，同樣是不可見，他們卻使用空白的GIF圖片來控制佈局。

由於HTML從來就沒被用來控制一個文檔的表現，導致大量的亂碼、非法代碼、瀏覽器的專用代碼和屬性就被隨意的使用了。“校驗”這個詞也很少被人問津。對於這些代碼來說，標籤湯（tag soup）是一個很形象的名字。

新版本的web瀏覽器的發佈，使得對CSS的支持得到了加強與擴展，但是並沒有達到它應有的水平。儘管瀏覽器的開發商對CSS支持的步伐很緩慢，但是現在已經有許多瀏覽器選擇了支持CSS，此時，不應該再有任何理由再像以前那樣使用HTML了，應該讓它恢復本來的面貌：去描述文檔的結構 ，而不是它的表現。 正因爲此，我們現在才能夠用CSS來達到其本來的目的了。

3. Web標準

什麼是web標準？

Web標準是一些規範的集合，是由W3C和其他的標準化組織共同制定的，以用它來創建和解釋網頁的基本內容。這些規範是專門爲了那些在網上發佈的可向後兼容的文檔所設計，使其能夠被大多數人所訪問。

結構化語言

表現類語言

對象模型

腳本語言

本文關注的是XHTML 1.0 Strict（代表結構）、CSS Level 1和Level 2（代表表現）、ECMAScript 262（代表腳本--並不是指那些腳本的例子）。

當一個文檔被認爲離Web標準不遠了的時候，那就意味着，除了具有上面所提到的技術，還應當：

  • 由符合標準的XHTML組成
  • 用CSS來佈局而不是表格
  • 使用結構化、語義化的標記
  • 能夠在任何瀏覽器中顯示

注意，“能夠在任何瀏覽器中顯示”並不意味着“在任何一個瀏覽器中顯示的效果相同”。使一個文檔在不同的瀏覽器和平臺上都有相同的顯示效果是不可能的，除非您僅僅使用圖片，因爲發佈在網上的文檔將被不同的操作系統上的不同的瀏覽器軟件所顯示，並顯示在不同大小與質量的顯示器上（或者顯示在非顯示器上），瀏覽者也可能改變了瀏覽器的默認字體或者其他喜好。希望這些能使您減少了一些挫折感。每一個做網頁的人都應該瞭解，一些技術上的先決條件我們不得不考慮，就像那些出書、拍電影、拍電視的人一樣，他們也有一些其他方面的前提必須要考慮。

爲什麼要使用Web標準？

一些Web開發人員和Web設計師對使用Web標準持牴觸態度。普遍的看法是它太難了，不管它是怎麼運作，我使用的那些軟件總會創建出一些不規範的代碼。.

學習新的技術並放棄您所熟知的技術，這很容易引起情緒上的反感，併產生牴觸的情緒。然而，如果您很理智的觀察一下現在的形勢，將會發現，通過學習和使用Web標準會得到許多好處。舉幾個例子：

  • 更簡易的開發與維護: 使用更具有語義和結構化的HTML，將讓您更加容易、快速的理解他人編寫的代碼。
  • 與未來瀏覽器的兼容: 當您使用已定義的標準和規範的代碼，那麼您這個向後兼容的文本就消除了不能被未來的瀏覽器識別的後患。
  • 更快的網頁下載、讀取速度: 更少的HTML代碼帶來的將是更小的文件和更快的下載速度。如今的瀏覽器當處於標準模式下將比它在以前的兼容模式下擁有更快的網頁讀取速度。
  • 更好的可訪問性: 更少的HTML代碼帶來的將是更小的文件和更快的下載速度。如今的瀏覽器當處於標準模式下將比它在以前的兼容模式下擁有更快的網頁讀取速度。
  • 更高的搜索引擎排名: 內容和表現的分離使內容成爲了一個文本的主體。與語義化的標記結合會提高您在搜索引擎中的排名。
  • 更好的適應性: 一個用語義化標記的文檔可以很好的適應於打印和其他的顯示設備（像掌上電腦和智能電話），這一切僅僅是通過鏈接不同的CSS文件就可以完成。你同樣可以僅僅通過編輯單獨的一個文件就完成跨站點般的表現上的轉換。

Web標準可以爲網站的創建者節省時間與金錢，還可以爲網站的瀏覽者提供一個更好的經歷。此外，Web標準是未來的。如果你還沒有使用Web標準，那麼現在應該開始動手了，否則你會落伍的。

相關文章:

校驗

校驗是一個控制的過程，在這個過程中，文檔必須遵守語言的規則。你可以通過對比，檢查出文本中的拼寫或語法錯誤。

規範是網頁開發中的一個重要部分。許多很難被發現的錯誤可以在驗證中發現。錯誤可能是一個微不足道的打字錯誤，也可能是嚴重的元素和屬性的不規範錯誤。

不幸的是，許多人並不驗證他們的文檔。一些人或許根本不知道驗證這回事，還有一些人想不起來去驗證，甚至還有一些人故意的逃避驗證。這種情況的出現，大部分的責任要歸咎於Web瀏覽器的開發商。大多數的瀏覽器都會去盡全力的去解釋不規範的HTML代碼，並努力的去猜測作者的意圖，以此來避免顯示錯誤的信息。這種行爲就導致瞭如今混亂代碼的泛濫。這種標記的問題是，它帶來了一些不可預測的結果，因爲它依靠的是Web瀏覽器錯誤的處理。

沒有任何原因不去驗證您的HTML和CSS。相反，它還會給您帶來許多好處。

Why we won’t help you 是Mark寫的一篇闡述驗證優點的文章，十分的棒。裏面還解釋了爲什麼如果您在驗證您的網站之前去求助，那麼想從論壇和郵件列表中的人取得幫助會非常的困難。

一些HTML編輯器（像 BBEdit 和 Homesite) 都嵌入了校驗工具。如果你的開發工具裏沒有嵌入校驗的話，你可以使用W3C的校驗服務，可在線使用:

理解校驗顯示的錯誤提示可能有一些困難。一個位於文檔前面的錯誤可能會導致另外幾個額外的錯誤。改了第一個錯誤後，通常你就會減少一定數量的錯誤了。下面這個網址，將有一些常見錯誤提示的說明： Common XHTML Validation Errors

確保你的代碼是完全規範的，總是一件好事，但是當一些校驗的錯誤很難避免時，就會有一些特殊的情況。其中最常見的的例子就是在一篇文檔中嵌入FLASH或者一些其他需要插件的內容。下面是關於這個問題的相關文章 Flash Satay: Embedding Flash While Supporting Standards和Embedding flash without <embed>.

4. 結構和表現

當討論Web標準時，一些事情總是被提及，那就是結構和表現分離的重要性。剛開始的時候理解結構和表現的不同之處可能很困難，特別是如果你不習慣於思考文檔的語義結構時。然而，理解這點是很重要的，因爲，當結構和表現分離後，用CSS文檔來控制表現就是很容易的一件事了。

結構 是由文檔中的主體部分，再加上語義化、結構化的標記。

表現 是你賦予內容的一種樣式。在大多數情況下，表現就是文檔看起來的樣子，但是它同樣可以影響一個文檔“聽”起來的樣子----畢竟不是每個人使用的都是圖像化的瀏覽器。

儘可能的把結構和表現相分離。理論上講，你應該用一個HTML文檔來保存內容與結構，用一個CSS文檔來控制整個文檔的表現。

如今表現與結構的分離在網上還不是很普遍。大多數網站上的HTML代碼既缺少語義也缺少結構。

用表格佈局

爲了使表現和結構相分離，你必須用CSS來代替表格去控制一個文檔的表現。當你習慣於用表格來佈局的時候，這將使你感覺很奇怪很不適應，但是，這並不像它看上去的那麼困難。你可以在網上找到許多可用的幫助，它的好處太多了，所以它確實值得您去花時間去轉變一下思想，這點很重要。

相關文章:

語義化的HTML

分離結構與表現的另一個重要方面是使用語義化的標記來構造文檔內容。一個XHTML元素的存在就意味被標記內容的那部分有相應的結構化的意義，沒有理由使用其他的標記。換句話說，不要讓CSS使一個HTML元素看起來就像另一個HTML元素，比如用<span>來代替<h1>標記標題。

通過使用語義化的HTML，你將會使文檔中的不同部分對於任何瀏覽器都變得有意義，無論瀏覽器是現今PC上的最新的圖象化瀏覽器，還是不支持CSS的老瀏覽器，或者還是Unix shell中的文本瀏覽器。

標題

爲了給標題做標記, 要用<h1>、<h2>、 <h3>、<h4>、<h5>或者<h6>，這完全取決於標題的等級。<h1>是最7高的等級。

例如:
<h1>文檔標題</h1>
<h2>次級標題</h2>

文檔標題

次級標題

段落

用<p>來標記段落。不要使用<br /> 來生成段落間的空行。用CSS來控制段落間的空隙（Margins），這個空隙可以確保段落標記的正確無誤。

例如:
<p>浪奔浪流，萬里滔滔江水永不休，淘盡了世間事，混作滔滔一片潮流，是喜是愁，
浪裏分不清歡笑悲憂，成功失敗，浪裏看不出有未有。愛你恨你問君知否，似大江一發不收，
轉千灣轉千灘，也未平復此中爭鬥，又有喜又有愁，就算分不清歡笑悲憂，仍願翻百千浪，
在我心中起伏夠。</p>

浪奔浪流，萬里滔滔江水永不休，淘盡了世間事，混作滔滔一片潮流，是喜是愁，浪裏分不清歡笑悲憂，成功失敗，浪裏看不出有未有。愛你恨你問君知否，似大江一發不收，轉千灣轉千灘，也未平復此中爭鬥，又有喜又有愁，就算分不清歡笑悲憂，仍願翻百千浪，在我心中起伏夠。

列表

一些事物的羅列應使用列表來顯示。在XHTML中有三種列表的方法：無序、有序和自定義。

無序列表, 就是我們所熟知的圓圈列表, 以 <ul>開始，以</ul>結束。每一個列表項都包含在<li>之中。

有序列表，以<ol>開始，以</ol>結束。

自定義列表有一些不同，可以用來標記一些列表項和描述，以<dl>開始，以</dl>結束。每一個被描述的項目，要包含在<dt>中，而描述的內容要包含在<dd>中。

例如:
<ul>
    <li>項目一</li>
    <li>項目二</li>
    <li>項目三</li>
</ul>
  • 項目一
  • 項目二
  • 項目三 
<ol>
    <li>項目一</li>
    <li>項目二</li>
    <li>項目三</li>
</ol>
  1. 項目一
  2. 項目二
  3. 項目三 
<dl>
    <dt>上海灘</dt>
    <dd>這部拍攝於1980年的《上海灘》堪稱是香港電視史上最成功、最經典的劇集。
    當年在香港播出以後，產生了巨大的轟動效應。</dd>
    <dt>周潤發</dt>
    <dd>和所有偉大的影星一樣，周潤發印證了一個時代，一個香港電影的黃金時代。
	風衣墨鏡、冷血雙槍、陽光微笑，都封存膠片之中，當我們回首尋望的時候，發哥已被刻爲一個時代的座標。</dd>
</dl>
上海灘
這部拍攝於1980年的《上海灘》堪稱是香港電視史上最成功、最經典的劇集。 當年在香港播出以後，產生了巨大的轟動效應。
周潤發
和所有偉大的影星一樣，周潤發印證了一個時代，一個香港電影的黃金時代。 風衣墨鏡、冷血雙槍、陽光微笑，都封存膠片之中，當我們回首尋望的時候，發哥已被刻爲一個時代的座標。

CSS使你不想用傳統列表來呈現內容成爲可能。導航欄（一個鏈接的列表）就是一個很好的例子。使用列表作爲菜單的好處是當一個瀏覽器不支持CSS時，這個菜單仍然起作用。

引用

用<q>來標記簡短的單行引用。Web瀏覽器會自動識別在<q> 之間的內容。不幸的是，IE不能識別，並且有些時候，<q>會引起一些可訪問性的問題。正因爲如此，一些人建議儘量不要使用<q>,手動的插入引用標記。在一個包含適當的類的<span>中加入單行的引用內容，那麼就可以用CSS來給引用設計樣式了，但是這個沒有語義上的意義。 您可以讀讀Mark Pilgrim寫的The Q tag 關於處理<q>相關問題的看法。

對於那些一段或者好幾段的長篇引用，就應當使用<blockquote>了。CSS可以用來定義引用的樣式。注意，一段文章是不可以直接放在<blockquote>中的，引用的內容還必須包含在一個元素中，通常是<p>。

屬性cite既可以與<q>一起用，也可以與<blockquote>一起用，用來提供引用內容的來源地址。需要注意的是，如果你使用<span>來代替<q>標記引用內容,那麼你就不能使用cite屬性了。

例如:
<p>我的座佑名<q cite="http://www.x5.com.cn/">別人的高標準，是我的基本要求。</q>.</p>

我的座佑名別人的高標準，是我的基本要求。.

<p>我的座佑名<span class="quote">&#8220;別人的高標準，是我的基本要求。
&#8221;</span>.</p>

我的座佑名“別人的高標準，是我的基本要求。”.

<blockquote cite="http://www.w3cn.org/">
    <p>&#8220;我們大部分人都有深刻體驗，每當主流瀏覽器版本的升級，我們剛建立的網站就可能變得過時，
	我們就需要升級或者重新建造一遍網站。例如1996-1999年典型的"瀏覽器大戰"，
	爲了兼容Netscape和IE，網站不得不爲這兩種瀏覽器寫不同的代碼。同樣的，
	每當新的網絡技術和交互設備的出現，我們也需要製作一個新版本來支持這種新技術或新設備，
	例如支持手機上網的WAP技術。類似的問題舉不勝舉：網站代碼臃腫、繁雜浪費了我們大量的帶寬；
	針對某種瀏覽器的DHTML特效，屏蔽了部分潛在的客戶；不易用的代碼，殘障人士無法瀏覽網站等等。
	這是一種惡性循環，是一種巨大的浪費。&#8221;</p>
</blockquote>

“我們大部分人都有深刻體驗，每當主流瀏覽器版本的升級，我們剛建立的網站就可能變得過時，我們就需要升級或者重新建造一遍網站。例如1996-1999年典型的"瀏覽器大戰"，爲了兼容Netscape和IE，網站不得不爲這兩種瀏覽器寫不同的代碼。同樣的，每當新的網絡技術和交互設備的出現，我們也需要製作一個新版本來支持這種新技術或新設備，例如支持手機上網的WAP技術。類似的問題舉不勝舉：網站代碼臃腫、繁雜浪費了我們大量的帶寬；針對某種瀏覽器的DHTML特效，屏蔽了部分潛在的客戶；不易用的代碼，殘障人士無法瀏覽網站等等。這是一種惡性循環，是一種巨大的浪費。”

強調

<em> 是用作強調的，<strong>是用作重點強調的。 大部分瀏覽器用斜體顯示強調的內容，用粗體來顯示重點強調的內容，然而，這是沒有必要的，如果是爲了確定強調內容的顯示方式，最好的方法就是使用CSS來定義他們的表現。當你想要的只是視覺上的效果時，就不要使用強調了。

例如:
<p><em>強調</em> 的文本通常用斜體顯示，
然而， <strong>特別強調</strong> 的文本通常以粗體顯示。</p>

強調 的文本通常用斜體顯示, 然而，特別強調的文本通常以粗體顯示。

表格

XHTML中的表格不應用來佈局。然而如果是爲了標記列表的數據，就應該使用表格了。爲了使數據表格有更強的訪問性，瞭解和使用各種構造表格的組件就很重要了。比如表格標題 (<th>)、摘要(summary 屬性)和首部說明 ( <caption>標籤)。

例如:
<table class="舉例" summary="1999年到2003年，列表顯示中國的平均人口增長率。">
    <caption>中國的年均人口的增長, 1999–2003</caption>
    <thead>
        <tr>
            <td>&#160;</td>
            <th scope="col">1999</th>
            <th scope="col">2000</th>
            <th scope="col">2001</th>
            <th scope="col">2002</th>
            <th scope="col">2003</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th>人口</th>
            <td scope="row">8 861 426</td>
            <td scope="row">8 882 792</td>
            <td scope="row">8 909 128</td>
            <td scope="row">8 940 788</td>
            <td scope="row">8 975 670</td>
        </tr>
        <tr>
            <th>增長</th>
            <td scope="row">7 104</td>
            <td scope="row">21 366</td>
            <td scope="row">26 368</td>
            <td scope="row">31 884</td>
            <td scope="row">34 882</td>
        </tr>
    </tbody>
</table>
中國的年均人口的增長, 1999–2003
 19992000200120022003
人口8 861 4268 882 7928 909 1288 940 7888 975 670
增長7 10421 36626 36831 88434 882

想了解更多的關於表格及其使用的細節, 請參閱Tables in HTML documents 和 HTML Techniques for Web Content Accessibility Guidelines 1.0。

相關文章:
  • SimpleQuiz

    一個很好的資源，告訴您如何用語義化的方法來標記。

5. (X)HTML

使用HTML4.01是可以製作出現代的、結構化的、兼容標準的站點的。然而，爲了做到向整潔的語義化的代碼的轉變，並且爲XML和未來的其他標記語言做好準備，建議大家使用XHTML1.0 Strict來創建新的站點，本文中的例子用的就是XHTML1.0 Strict。

XHTML 1.0 是以XML 1.0對HTML 4的改進，它的發展，以用來代替HTML。XHTML 1.0 Strict（這是我一直所倡導的）不支持表現類的標記（HTML 4.01其實也不支持，但是現在我們討論的是XHTML）。正因爲此，XHTML1.0 Strict就促使了表現與結構的分離。

XHTML 1.1（XHTML的最新版）從技術上說，使用起來有一些複雜。因爲規定中聲明XHTML 1.1的文檔應當使用MIME類型 application/xhtml+xml, 不應當被看作text/html。 並不是嚴格的禁止使用text/html, 只是不建議使用。 另外一方面，XHTML 1.0 （應當使用 application/xhtml+xml）同樣可以使用MIME類型 text/html, 如果它是可兼容的HTML。W3C的註解XHTML Media Types 中包括了MIME類型（W3C推薦使用的類型）的概要。

不幸的是，一些老的瀏覽器包括IE不能識別MIME類型 application/xhtml+xml, 並且會終止顯示源代碼，甚至會乾脆拒絕顯示整個文檔。

如果你想使用application/xhtml+xml, 你應當讓服務器檢驗一下讀取文檔的瀏覽器是否支持MIME類型，如果能，就使用它，如果不能，就使用text/html。

如果你使用的是PHP作爲服務器端的腳本，那麼下面的這段腳本能夠讓你的文檔針對不同的瀏覽器使用不同的MIME類型:

<?php
if (stristr($_SERVER[HTTP_ACCEPT], "application/xhtml+xml") || 
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
    header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
    header("Vary: Accept");
    echo("<?xml version=/"1.0/" encoding=/"iso-8859-1/"?>/n");
    }
else {
    header("Content-Type: text/html; charset=iso-8859-1");
    header("Vary: Accept");
    }
?>

這個腳本是檢測是否用戶代理髮送了一個包含“application/xhtml+xml”的Accept HTTP頭，或者如果用戶代理是W3C HTML校驗器（不會發送合適的Accept HTTP頭的，但是它依然支持 application/xhtml+xml）。如果上面檢測的回答是肯定的，文本將被看作 application/xhtml+xml。那些瀏覽器也會收到一個XML的聲明。對於另外的一些瀏覽器（包括IE的是所有版本），文檔都將被看做text/html。在文檔中也沒有添加額外的XML聲明，因爲如果添加的話，會使IE/WIN轉化到我們所不希望的Quirks模式。

在Content-Type頭部之後,一個被更改過的頭部，將被髮送到中間的緩存中（比如一些代理服務器），用來告訴他們文檔的內容類型隨着客戶端對文檔的請求而改變。

如果想了解更多的PHP檢測腳本, 請參考Serving up XHTML with the correct MIME type. 那個腳本對請求客戶端的q-rating（它聲明瞭更夠很好的支持某種MIME類型）進行了考慮，在發送text/html 文檔給不支持 application/xhtml+xml的客戶端之前，把XHTML轉化成HTML 4。

下面的是一個相似的腳本，針對ASP（VBSscript）:

<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0 
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
    Response.ContentType = "application/xhtml+xml"
    Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
    Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>

值得注意的是，當一個文檔的MIME type是application/xhtml+xml時，一些瀏覽器（像Mozilla）是不會顯示包含錯誤的文檔的。這在開發過程中是一件好事，但是對於那些剛剛更新完站點且不是XHTML專家的人來說，就會出現一些問題，除非您能確保所有的代碼都是規範的。如果出現了這種問題，您可以考慮使用HTML 4.01 Strict來代替XHTML。

下面列出了一些在使用XHTML 1.0 Strict中需要特別注意的地方:

  • 永遠使用小寫字母，讓引號伴隨者屬性: 所有元素和屬性的名字都必須使用小寫，所有屬性值必須使用雙引號。

    錯誤: <A HREF="index.html" CLASS=internal>
    正確: <a href="index.html" class="internal">

  • 關閉所有的元素: 在HTML中一些元素沒有必要被關閉。當下一個元素開始的時候，上一個元素就自動被關閉。XHTML中是不允許這樣的。所有元素都必須被關閉，即使其中沒有內容（如<img>）。

    錯誤: <li>Item 1
    正確: <li>Item 1</li>

    錯誤: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    正確: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>

    錯誤: <br>
    正確: <br />

    錯誤: <img src="image.jpg" alt="">
    正確: <img src="image.jpg" alt="" />

  • 屬性不能被縮減: 在HTML裏，一些屬性可以被縮減。而XHTML則不允許這樣做。

    錯誤: <input type="checkbox" id="checkbox1" name="checkbox1" checked>
    正確: <input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" />

  • 不要使用被排斥的元素: 一些元素和屬性在HTML 4.01 Transitional和XHTML 1.0 Transitional是被允許的，而在XHTML 1.0 Strict下則不被支持(還有in HTML 4.01 Strict)。比如<font>、<center>、 alink、align、width、 height (對於某些元素)和background。

相關文章:

Doctype（文檔類型）

現在只有很少的HTML文檔有一個正確而完整的doctype或者DTD(文檔類型聲明)。它現在更多的是在起裝飾作用而沒有什麼功能作用，但是就在幾年前剛開始的時候，一個doctype的定義，對瀏覽器解釋這個文檔起到很大的作用。

所有的HTML和XHTML文檔都必須使它的doctype聲明合法化。 doctype可以告訴我們在文檔中使用的是什麼版本的HTML和XHMTL，也決定了校驗器以何種方式校驗，瀏覽器以何種模式解釋。如果文檔中有一個正確而完整的doctype，許多瀏覽器將會轉換到標準模式，那就意味着與CSS的規範更加接近了。因爲瀏覽器不必再把時間用在彌補、解釋不規範的HTML上了，所以文檔的顯示速度也加快了。這同樣也會減少在不同瀏覽器上顯示的差異性。

下面的doctype聲明是針對XHTML 1.0 Strict的，它將會促使擁有“文檔類型轉換器”的瀏覽器使用他們的標準模式。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
相關文章:

字符編碼

所有的XHTML文檔都應當定義他們的字符編碼。

最好的網頁編碼方法是配置你的網絡服務器，使其發送帶有字符編碼的HTTP content-type頭部。關於如何使用去做的具體細節，請參閱你所使服務器軟件的說明。

如果你使用的是Apache，你可以通過在你的.htaccess文件中添加一兩條規則來定義字符編碼。例如，你的所有文件使用的都是utf-8, 添加下面的語句:

AddDefaultCharset utf-8

定義具有相同擴展名的文件的字符編碼,則使用下面的代碼：

AddCharset utf-8 .html

如果你的服務器允許你用PHP腳本時，你可以使用以下的代碼來定義字符編碼:

<?php
    header("Content-Type: application/xhtml+xml; charset=utf-8");
?>

如果你的頁面是HTML, 請把application/xhtml+xml換成text/html。不管是什麼原因，如果你不能配置你的服務器使其定義爲你所使用的字符編碼，你可以在<head>中使用<meta> 。即使你的服務器配置正確了，這也是個定義字符編碼的好方法。

例如, 下面的<meta>告訴瀏覽器這是一個使用ISO-8859-1字符編碼的文檔:

<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1" />
相關文章:

6. CSS

CSS過去經常被用來定義字體的屬性，而現在可以用它來控制整個文檔的佈局。然而，爲了有效的用CSS來控制佈局，需要做一些不同的處理，這種不同是跟用表格佈局相對比的。

爲了CSS可以高效的控制佈局，結構化、語義化的XHTML是必不可少的。

瀏覽器的支持

正如前面所提到的，在過去幾年，瀏覽器對CSS的支持程度已經改進了很多。不幸的是，瀏覽器的開發商好象對實施開放的標準並不感興趣，所以不同瀏覽器對CSS的支持程度也大相徑庭。就算是支持程度最好的瀏覽器，在軟件中仍然有一些bug，使得瀏覽器以錯誤的方式運行。

現在(2004年), 對CSS支持比較好的瀏覽器有Mozilla (還有以Gecko爲內核的: Firefox, Camino, Netscape 6+), Opera和Safari (還有以 WebCore爲內核的: OmniWeb 4.5 and later)。 Internet Explorer 6/Win並沒有如此好的CSS支持程度，但是它將讓你爲其做出大量的基礎工作。Internet Explorer 5/Mac對CSS 1的支持很出色, 但是卻不支持CSS 2。 IE 5.* for Windows的支持性也很好, 但是仍然有一些問題值得你去注意。早期版本的IE以及Netscape 6以前的版本就沒有必要提及了。

因爲現在大多數人都使用IE/WIN，所以你將不得不讓它成爲特殊分子。這並不是說，你不能或者不應該使用有更好支持CSS能力的瀏覽器來提高他們的設計能力。

現在在用的瀏覽器中，並不是所有的瀏覽器都有很好的CSS支持能力，使其能夠具有解釋用CSS佈局的優秀圖形化站點的能力。幸運的是，對於大多數網站，只有很小比例的訪問者還在使用不能解釋CSS的老瀏覽器。

值得注意的是，這些人並不會被排斥在外的。在90年代，瀏覽器檢驗腳本是一個很流行的方法，它告訴那些使用“錯誤”瀏覽器的使用者一個新的網址，那個網址告訴他們去升級瀏覽器，好重新連接到那個網站。

現在，你可以以一種更好的辦法應付不被支持的瀏覽器。使用邏輯化、語義化的一個最大的好處就是它使文檔在沒有CSS時，仍然可以使用和訪問。表現（就是文檔看上去的樣子）在一個支持性好的瀏覽器中也將呈現的不一樣，但是它的內容將永遠不變，大多數情況，對於訪問網站的人來說，內容實際上比表現的方式更加重要。這就是爲什麼給那些支持性不好的瀏覽器發送一個沒有樣式的頁面，要比把他們排斥在外要好的原因。

有好幾種方式去解決這個問題：一種最常見的方法是使用@import來鏈接相應的的CSS文件。Netscape 4和老的瀏覽器不支持@import所以將不會導入CSS文件。還有許多方法來向瀏覽器隱藏CSS。大多數隱藏CSS的方法是利用了瀏覽器對CSS解釋時的漏洞。這意味着總會存在瀏覽器通過升級彌補漏洞的危險。所以越少的依賴CSS hacks（CSS漏洞）越好。

很明顯的，你可以使用服務器端技術去做一個瀏覽器檢測，然後針對不同的瀏覽器，發送不同的CSS文件。如果你這麼做了，你必須要確保檢測腳本是通用的，以避免因爲瀏覽器的升級或者新的瀏覽器發佈導致發送錯誤的CSS文件。

相關文章:

用不同的方法應用CSS

有以下幾種方法使一個HTML文檔中的元素應用CSS。

外鏈式

把所有的CSS規則都寫在一個或幾個單獨的文件中，這種做法有許多優點。HTML文檔會變得非常的小，CSS文件被存在瀏覽器的緩存中，僅僅需要下載一次即可，並且你只需要修改一個文件就可以改變整個網站的樣式。一個外鏈式的CSS文件，見如下:

h1 {
    font-weight:bold;
}

注意: 在外鏈的CSS中沒有<style>標籤。

你可以使用<link>標籤來把一個CSS鏈接到HTML文檔中:

<link rel="stylesheet" type="text/css" href="styles.css" />

或者在<style>中使用一個@import標籤 :

<style type="text/css">
@import url("styles.css");
</style>

直線式

通過使用style屬性,你可以直接的在HTML中應用CSS:

<h1 style="font-weight:bold;">Rubrik</h1>

這種情況，應儘量的避免，因爲他把結構和表現混在一起了。

內嵌式

內嵌式CSS是寫在<style>標籤中，也是寫在文檔的<head>中:

<style type="text/css">
h1 {
    font-weight:bold;
}
</style>

這種情況也應該儘量避免，最好還是把HTML和CSS用單獨的文件存放。

相關文章:
  • At-Rules

    關於CSS導入和media類型的說明。

CSS的語法

一條CSS的規則是由一個選擇器和一個或多個聲明組成。選擇器決定了CSS規則可作用於文檔中的哪個或哪些元素。一個屬性和一個值組成了一個聲明，聲明要用大括號（{}）括起來，並且每個聲明要用分號（；）結束。

一個簡單的CSS規則如下:

p {
    color:#0f0;
    font-weight:bold;
}

這個例子中, p就是選擇器,表示這條規則將作用於文檔中的所有被<p>包圍的內容。這個規則中，有兩條聲明，它們共同作用，使<p>中的內容所有字體爲綠色並且加粗。

想了解更詳細的CSS規則，可以參閱 CSS Beginner’s Guide, CSS from the Ground Up或者一個CSS手冊。

相關文章:

多餘的元素和類

當我們剛開始學CSS時，很容犯一些錯誤：使用不必要的XHTML元素、多餘的類和額外的<div>。並不是說這些代碼是不規範的，而是它與一些原則（如結構與表現相分離，使用簡單的整潔的標記）相矛盾。

下面是一個使用不必要XHTML元素的例子:

<h3><em>Headline</em></h3>

如果你想使標題行變成斜體，可以使用CSS來重新定義<h3>元素:

h3 {
    font-style:italic;
}

下面是一個使用多餘的類的例子:

<div id="main">
    <div class="maincontent">
        <p class="maincontenttext">
            CSS的用法的奧祕很多
        </p>
    </div>
</div>

下面這麼寫可能更好:

<div id="main">
    <div>
        <p>
            CSS的用法的奧祕很多
        </p>
    </div>
</div>

爲了控制div#main中的元素，你可以在CSS代碼中使用相關的的選擇器，例如:

div#main p {
    /* rules */
}

多數情況下，CSS允許你把想要的樣式來定義XHTML，而不用增加額外的的標記。但是有的時候，增加一些額外的代碼也是必要的。

CSS小竅門

很明顯，一旦你去很認真的學習使用CSS，你一定會發現某些問題，這些問題可能是由誤解造成的，可能是由對規則的不瞭解或者瀏覽器的漏洞造成的。CSS Crib Sheet就是一個好建議的薈萃，有Dave Shea整理，下面還將有一些重要的而且是Dave沒有提及的小竅門。

  • 先校驗: 在調試的時候，先由校驗開始吧，HTML和CSS都要進行校驗。許多問題都是由不規範代碼引起的。

  • 先在最先進的瀏覽器中調試，然後才輪到其他的瀏覽器: 如果你剛開始就用對CSS支持不好的瀏覽器調試，那麼你所編的CSS將會逐漸適應這種錯誤的處理。當你繼續在更先進的瀏覽器中測試，一些你所不希望的內容就會出現了。最好還是首先在一個有很好標準兼容性的瀏覽器中運行，然後再把代碼拿到老一點的瀏覽器中去測試。

  • 理解CSS的盒模型: 爲了獲得一個元素的實際的寬度和高度，你需要用padding和border來增加它的 width或者height。在Internet Explorer 5.*/Win中, padding和border是被包括在已知的width和height。

    假設你有如下的CSS代碼:

    div.box {
    width:300px;
    padding:20px;
    border:10px solid;
}

    所以這個div的總寬度是360px。

    10px + 20px + 300px + 20px + 10px = 360px

    在Internet Explorer 5.*/Win中，實際上總寬度爲300px, 內容的寬度爲240px。

    300px - 10px - 20px - 20px - 10px = 240px

    爲了繞過這個問題, 你同樣可以使用CSS hack來給不同的瀏覽器提供不同的值，或者你儘量避免在同一個元素中同時定義width和 padding或者width和border。

    想了解關於CSS盒模型的更詳細內容，請參閱 Box model。

  • 爲非零的數值加上單位: CSS要求一些屬性值（如width、height、font-size）必須要有單位。當屬性值爲0時是可以例外的。在那種情況下，沒有單位也是必須的，因爲0就是0，什麼單位也都無所謂了。

  • 理解漂浮物: 儘管漂浮物這個概念很難理解，但是它很重要，因爲CSS中會頻繁的使用它來佈局。有一些關於漂浮物的好文章，如Containing Floats、Floatutorial和Float: The Theory。

  • “LoVe/HAte”: 按照如下順序爲鏈接定義僞類：Link, Visited, Hover, Active。

  • “TRouBLed”: 當使用簡寫來定義margin、padding和border時, 他們的順序是從上開始的順時針方向: 上、右、下、左。

  • 以其功能給CLASS和ID命名，而不是它的表現: 如果你有一個CLASS名爲.smallblue, 過後你決定用它來定位文本，使其爲大號、紅色，那麼CLASS的名字就會被弄混淆的。最好能用名字來描述功能和結構，如.copyright和.important。

  • CSS是個敏感的東西: 當HTML屬性中的class和id與CSS一起使用時，那可就要小心了。 (參見CSS2 syntax and basic data types)。

  • 檢查你的ID: 文檔中一個元素只能使用一個id，且id必須唯一，而class可以被多個元素所共享。

  • 使用合法的字符爲 class 和 id命名: Class 和 id 的名字只能由數字、字母和連字符組成，數字和連字符是不可以開頭的。(參見 CSS2 syntax and basic data types).

  • 正確的註釋: CSS的註釋是以/*開頭，以*/結尾的:

    /* This is a comment */

CSS佈局

有很多例子和階梯教程指導您如何使用CSS佈局。建議您從簡單的例子開始，學習它的原理，然後再去學習複雜的佈局。

相關文章:

7. 可訪問性

可訪問性並不是單單針對殘疾人，儘管這是這是一個創建具有可訪問性站點的一個主要原因。一個具有親和力的站點對任何人來說，顯示效果都同樣出色，無論他是不是殘疾人。它可以被更多使用不同瀏覽器或瀏覽設備的人所訪問。

有一種對可訪問性站點的常見誤解，認爲它與衆不同，或者不如那些不具有可訪問性的站點具有視覺吸引力。

這有一個例子將告訴您可訪問性是如何給每一個人造福的：一個網站有一個表單，用它來進行註冊參加一個研討會，表單中，你可以選擇去參加三個城市中的一個城市的研討會。每一個城市名字旁邊都有一個單選按扭。如果表單的創建者沒有可訪問性的意識，那麼使用圖像瀏覽器的人就不得不把鼠標放到很小的單選按扭上，然後點擊它來選擇城市。如果開發者瞭解可訪問性，並且在每個按扭旁邊用<label>標記說明，那麼您就可以點擊城市的名字來選擇地點了。那麼，您認爲哪種方法使表單使用更簡便呢？

使用語義化、結構化的XHTML將使你走向可訪問性站點之路。要對可訪問性的文檔有一個基礎的概念，嘗試使用一個文字化的瀏覽器（如：Lynx看看內容是否依然起作用。雖然這離通過可訪問性的驗證（這是你必須去做的）還差很遠，但是這是一個好的開始。

框架

許多網頁設計師喜歡使用框架把瀏覽窗口分割成幾個獨立的部分，每部分都是由獨立的HTML文檔組成，這樣做對某些程序（比如一個區域網的應用程序）可能很好，但是在公衆網上，使用框架將存在許多缺點:

  • 你會令瀏覽者迷惑。 做網頁的一個基本原則是每一個頁面用一個唯一的URL表示。打破這個原則，你將使瀏覽者很難明瞭網站的結構。
  • 框架帶來了搜索引擎的問題。 一個搜索引擎要把一個框架編入索引中，你就必須提供指向所有頁面的鏈接。從搜索引擎搜到你網站的瀏覽者也會遇到一些問題，他們很可能訪問的是缺少了某些重要信息（導航鏈接）的文檔。一些框架結構的網站試圖通過robots.txt訴搜索引擎不要把次級頁面編到索引中，以此來解決上面的問題。其他的一些網站則用javascript把通過搜索引擎過來的訪問者送到首頁。如果你的目標就是獲得少量的瀏覽者，這兩種方法都是可行的。
  • 框架破壞了書籤。 大多數瀏覽器不能在一個框架網站的頁面上使用書籤。當你打開書籤後，你將打開的是框架設置的默認地址，往往去的都是這個網站的首頁。
  • 打印變得愈加的困難。 許多瀏覽者在打印文檔的時候，同樣會遇到問題。大多數的瀏覽器都會要求你解開這個框架，否則不能打印。
  • 通過E-mail傳送鏈接變得更加的困難。 框架很有效的消除了往一個網站中的頁面發送鏈接的可能性。本質沒有變，只是提高了網站的複雜性。
  • 使網站具有可訪問性變得更加的困難。 這會讓那些不使用圖形化瀏覽器（它支持框架）的人遇到問題的。也正因爲此，可訪問性準則不建議大家使用框架。

此外，你這是在給自己找麻煩。框架將使一個網站在技術上更復雜。

表格

把“不要使用表格佈局”解釋成“不要使用表格”對一些人來說沒什麼區別。這個並不是如何去解釋的問題。如果你想標記一個列表數據，理所當然應該使用表格，這纔是表格應當起的作用。然而，有一點很重要：當你建立數據表格時，有許多方法可使他們更具有邏輯性和可訪問性。

相關文章:

表單

表單通常是沒必要去使用的，而且使用起來很困難，部分的原因是因爲他們是用不合邏輯的方法建立的，部分是因爲基本的HTML代碼並沒有使用標籤（標籤可以使表單更具有可訪問性，更容易使用）。一些相關的標籤（如<label>、<fieldset>和<legend>）是存在的，而且是應該被使用的。

一個普遍的問題是用什麼給表單佈局。一些人說，可以把一個表單看作一個列表數據，可以用表格來構造，然而還有一些人提議用CSS來佈局。兩種方法都是可用的，但是如果你用的是表格，請確保這個表格是有意義的，而且要保證當一個包含表單的表格被線性後是可用的。

相關文章:

JavaScript 和 cookies

不要依靠JavaScript。許多人（包括你自己）可能都會認爲如果把JavaScript從他們的瀏覽器中移除，就可以更加安全或者可以避免彈出窗口。他們也可能正在使用的瀏覽器壓根就不支持JavaScript。根據TheCounter.com的調查，6%的Web用戶不使用JavaScript, 而根據W3Schools.com的調查，這個百分比爲8%。

大多數情況，使用JavaScript的地方，對訪問者都沒什麼好處。當然有一些例子顯示Javascript能夠給訪問者提供更好的體驗。一個例子就是校驗表單的輸入。

值得注意的是這並不是說您不應該使用JavaScript。而是說你不應該創建一個依靠JavaScript運行的網站。

同樣的事也適用於cookies。如果瀏覽者不接受他們的網站就拒絕運行，那麼你的cookie就使用錯了。

8. URLs（頁面地址）

這部分跟Web標準和可訪問性無關，但是把它放在這是因爲一個URL的創建方式將對搜索引擎如何把站點編入索引以及它對訪問者的可用程度都有很大的影響。

一些搜索引擎機器人不能跟蹤以字符串結尾的地址。這種地址通常出現在一些把內容動態的存在數據庫的網站裏，看起來就像下面這樣:

http://yourdomain.com/products.asp?item=34627393474632&id=4344

最簡單的創建對搜索引擎機器人和人們都有易的URL的方法是改變它看起來的樣子，使URL看起來就像直接的某個目錄，上面的URL應該改變成:

http://yourdomain.com/products/item/34627393474632/id/4344/

Web服務器將會解釋新的URL，並在內部把它轉換成原始的URL，最終以字符串結束。這部分的結尾是一些站點的網址，上面將會有更多的相關信息。

一個更好的改變URL的方法（多少有一些麻煩）是徹底的把看到的URLS改寫成人們易讀的方式:

http://yourdomain.com/products/flowers/tulips/

這種URLs的好處是搜索引擎機器人將把你的站點更好的收入到索引中，對於大家來說，它的可讀性也更強，並使你避免了泄漏你所使用的服務器方技術。因爲在URLS中，並沒有顯示服務器專有文件的擴展名，如 .asp、.cf、.cgi 和 .jsp,這會使你更容易的更改服務器器方的技術，所以這種URLs顯得十分的必要。

如果你選擇使用包含字符串的URLs，把&編譯成HTML的實體&amp;是很重要的。如果你不這麼做，一些瀏覽器會替你完成這個工作，好象這是他們應該做的。當他們碰到&amp;，就把它看作一個實體的開始。如果緊接着&amp;後的文本符合HTML中的一個實體，瀏覽器就會轉變這個URL，大多數情況，這將會破壞URL中的字符串。

還有一件事值得一提，對於大多數站點，使用www這個次級域名是不必要的。應該用http://yourdomain.com/來代替http://www.yourdomain.com/。更多的內容請參閱no-www.org。無論你使不使用www，配置你的服務器地址，使其指向http://www.yourdomain.com/， http://yourdomain.com/也是同樣的道理。

相關文章:

9. 參考資料

精選的一些可供參考的書籍、站點和郵件列表。

Books

CSS

Web發展概況

  • A List Apart

    一個在線週刊，探討設計、發展、和WEB內容的含義同時還關注着標準化設計的相關技術，以及給我們帶來的好處

  • webdesign-L

    一個熱忠於開發網絡的郵件列表。大多數與Web設計和Web開發相關內容列表裏都有討論

HTML

可訪問性

Web標準

XHTML

10. 專業詞彙

Accessibility
一個具有可訪問性的站點對於每個人都是可訪問的、可用的, 無論他們使用的是什麼硬件和軟件, 無論使用什麼作爲站點的導航。
CSS (Cascading Style Sheets)
一種描述站點表現樣式的規則。
HTML (HyperText Markup Language)
用它來標記文檔的結構。
Presentation
一個站點看（聽）起來的樣子。
Structure
一個文檔的主體，是對內容的邏輯化的標識。
Markup
通過標記一個文檔，你可以賦予這篇文檔及其內容以結構與意義。在網上，用HTML和XHTM作標記。
Validation
校驗是一個控制過程，在過程中使文檔遵守語言的規範。你可以通過對比，檢查出文本中的拼寫和語法錯誤。
W3C (World Wide Web Consortium)
一個組織，由他們來制定Web規範、準則和開發一些Web工具。
Web standards
這個就不用多說了，詳情請看 W3C。
XHTML (Extensible HyperText Markup Language)
根據XML對HTML的重新改造。
XML (Extensible Markup Language)
一個標記語言，看起來就像HTML，但是它允許作者根據描述的內容來自定義相應的元素。

驗證：xhtml1-strict 和 CSS

© Copyright 2004 Roger Johansson，x5

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

10 個實用的 Chrome DevTools 設計功能

Chrome DevTools 不只是開發者的工具，也是網頁設計師的好幫手。讓我來爲大家介紹十個非常實用的設計功能。 直達 Google 開發者在線課程，收穫 Web 技術乾貨 https://developers.google.cn/le

王莹 2021-11-30 09:53:49

PWA 的高級模式

漸進式 Web 應用 (PWA) 讓開發者打造的 Web 應用在體驗上能夠與用戶的桌面設備或移動設備上安裝的其他應用別無二致。在本次專題演講中，我們將瞭解各家公司如何結合運用緩存策略和現代 Web API 來實現快速而彈性的 Web 體驗。

王莹 2021-11-29 16:13:59

核心網頁指標的新變化以及成功模式

我們一直都在積極收集關於網頁指標的反饋，在本次專題演講中，我們將分享我們關於如何利用工具衡量和優化網頁指標的最新研究成果。 直達 Google 開發者在線課程，收穫 Web 技術乾貨 https://developers.google.cn

王莹 2021-11-29 16:13:59

隱私沙盒近期動向

web 平臺的默認隱私保障正在逐步強化。您的網站該如何爲更注重隱私保護的 web 做好準備？我們將爲您逐一介紹下面這些開發者須知事項：具體變化和原因、如何爲第三方 cookie 的停用做好準備、有哪些可用的工具、有哪些可嘗試的新 API、C

王莹 2021-11-29 16:13:59

Site Kit 和 CMS 核心網頁指標的新變化

Sitekit 是一個 Google 所開發的一站式工具套件，供網站站長和創作者查看網站性能和健康狀況。 在本次專題演講中，我們將展示 Sitekit 的強大功能，以及 Google 如何與網站構建平臺和託管服務提供商合作集成此一站式解決方

王莹 2021-11-26 10:09:03

2021 Google 開發者大會一覽，同步Android、TensorFlow、Web開發等最新動態

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"typ

罗燕珊 2021-11-16 19:33:53

ssm根據pdf模板導出pdf

一、使用word設計pdf模板，並另存爲pdf格式的文件。 二、使用Adobe Acrobat DC工具，打開pdf文件，工具中選擇準備表單並打開 三、在文件中設置域名稱，如下圖 四、下面是正式的操作 pom依賴 <!-- 生成P

LVAmber 2020-07-08 12:00:10

koa應用的部署

koa應用的部署 koa2項目的簡單創建到服務器的部署， 本例使用centos。 創建koa2項目 npm install -g koa-generator npm start 是 npm run start npm stop

这魏先森 2020-07-08 08:25:02

Ruby on Rails的國際化，本地化問題的解決(轉載)

原文出自: http://my.donews.com/woodstudio/ Ruby on Rails是一個很不錯的web開發框架，不過由於目前其本身對國際化的支持較差，所以需要一些輔助的東西來解決國際化問題。 我最先使用的是一個叫

iteye_17269 2020-07-08 02:37:16

Could not open ServletContext resource [/WEB-INF/a

   錯誤如下： org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from resourc

iteye_3794 2020-07-08 00:39:42

windows系統遠程提權、MySQL UDF提權

本文目錄權限提升提權本質提權分類windows系統提權基礎命令windows提權輔助工具輔助工具介紹windows遠程提權上手操作一下Mysql UDF提權udf介紹udf.dll獲取上傳udf執行提權命令 前言 小白一枚，之前聽

m0re 2020-07-07 23:45:29

前後端數據交互-json 你還不會傳集合嗎?

文章目錄json前端jsp後端配置導入beancontroller測試結果後端控制檯前端控制檯 json json(JavaScript Object Notation) 是一種數據格式，就是將key和value按規範封裝成一串字

唔仄lo咚锵 2020-07-07 22:40:07

關於DOM的一段話

[size=large]DOM實際上是以面向對象的方式描述的對象模型。DOM定義了表示和修改文檔所需要的對象，這些對象的屬性和行爲以及這些對象之間的關

iteye_17543 2020-07-07 22:21:22

RESTful風格API到底是什麼？

什麼是RESTful REST（Resource Representational State Transfer）是Roy Thomas Fielding在他2000年的博士論文中提出的。如果一個架構符合REST原則，就稱爲RES

hongmin.shm 2020-07-07 21:53:41

Spring攔截器Interceptor與Servlet過濾器Filter詳解

文章目錄一、先說結論1.攔截器Interceptor與過濾器Filter的區別2.攔截器鏈與過濾器鏈的執行順序Filter 鏈執行順序Interceptor 執行順序3.攔截器與過濾器的執行時機4.攔截器與過濾器的適用場景攔截器I

hongmin.shm 2020-07-07 21:53:41