MozTW 討論區

各項 Mozilla 相關軟體與技術討論
現在的時間是 2024-03-29, 15:54

所有顯示的時間為 UTC + 8 小時





發表新文章 這個主題已被鎖定,您不能編輯或回覆這個主題。  [ 9 篇文章 ] 
發表人 內容
文章發表於 : 2004-02-12, 02:31 
離線
[網站管理員]
頭像

註冊時間: 2002-01-07, 19:28
文章: 3080
來自: 台灣
Mozilla 網站設計常見問題
原文: http://www.mozilla.org/docs/web-developer/faq.html

這份文件回答了一些與 Mozilla 相關的網頁設計常見問題,而文件最後也附上其他一般網頁常見問題的連結。

Q: 什麼是「Quirks」模式與標準模式?

A:
Mozilla 裡有「兩個半」的佈局模式,分別是「Quirks」、「近乎標準」及「標準」模式。在「標準」模式裡,Mozilla 的目標是將符合全球資訊網協會(World Wide Web Consortium,W3C)推薦書的網頁以推薦書中闡述的方式處理。而在以「與舊版回溯相容」為目標的「Quirks」模式中,Mozilla 會仿照過去瀏覽器的幾種行為來處理網頁,這可能會讓符合 W3C 推薦書的文件以不符規格的方式顯現。「近乎標準」模式則與「標準」模式非常相似,但因某些緣故(下一個問題會闡述)其將以傳統方式來描繪含有圖片的表格。佈局模式的挑選取決於 HTML 文件起始處 doctype 的宣告與否及宣告模式。

要確保 HTML 的「標準」模式啟動,最簡單的方法是使用這種 doctype 宣告:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

要確保 HTML 的「近乎標準」模式啟動,最簡單的方法是使用這種 doctype 宣告:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

兩種宣告中,前者是給不含任何宣告失效標籤的文件;後者則是給可能含有宣告失效標籤的文件。無論是何者,此文件都該合乎並通過 CSS2 佈局模組的驗證。

而要啟動 HTML 的「Quirks」模式,最簡單的方法是省略 doctype 宣告。但不管怎樣,我們並不鼓勵建立依賴 quirks 模式的文件。

「近乎標準」模式在 Mozilla 1.1 beta 及 Mozilla 1.0.1 中才出現的,在更早的版本中,現在以「近乎標準」模式佈局的文件會直接啟用「標準」模式。

這種依照 doctype 來辨別佈局模式的方法只適用於標為「text/html」的文件,而 XML 文件則必然會啟動「標準」佈局模式(標為「application/xhtml+xml」的文件亦同)。這代表一份符合 XHTML 1.0 Transitional 規格並標記為「text/html」的文件,會因附錄 C 的理由以「近乎標準」模式佈局;而同一份文件,標記為「application/xhtml+xml」後則會用應有的準則,以「標準」模式對待。

Q: 為什麼在「標準」模式下時,表格中的圖片邊緣會有間隔?

舊的瀏覽器與 CSS2 box layout model 兩者在「版面區塊的預設垂直尺寸」跟「圖片的預設垂直對齊方式」方面略有出入,而如果明確指定圖片的 CSS 屬性(加上圍繞圖片的<a>標籤)可以解決這種排版上的問題。

如果某個以「<td class="imgcell">」定義的表格儲存格內只有一個圖片,則所需的 CSS 定義便是:
.imgcell img, .imgcell a { display: block; }

更長的說明…

Q:我設定的樣式沒有用!為什麼會這樣?

以下是一份檢查清單:
    該 HTML 文件是否能通過驗證?CSS 在標籤大雜燴中可起不了作用。
      <link> 跟 <style> 元素都應該在 <head> 元素的內部出現。
    該 CSS 樣式是否能通過語法檢查
      所有非 0 的數字後面都該附加適當的單位,數字及單位之間不含空白字元(例:1.2em)。
      屬性名稱及屬性值之間該放的是「冒號」而非「等號」。
      .css 的檔案中不該出現任何 HTML 標籤(像是 <style>)。
      font-face 並非 CSS 的屬性之一,正確的屬性名稱是「font-family」而 @font-fact 屬於 at-rule。
      如果你使用了 @import,則應該將其置放在 CSS 檔案的最上頭。
    該 CSS 檔案的 HTTP 檔頭中「Content-Type」一項是否為「 text/css 」?
      Web sniffer 可以幫你檢查檔案的 HTTP 檔頭資訊。
    樣式類別(class)及 ID 名稱都有大小寫之別(case-sensitive)。
    在 XML 中,element selector(譯註: Type selector)有大小寫之別。
    樣式表的處理指令(processing instruction)只能出現於 XML 檔的前言(prolog)之中,另外它們也只能在 XML 檔案中使用,而不能用於標示為「text/html」的檔案。
    寬(width)及高(height)不能套用在 inline 的元素上(如預設的 <span>)。(譯註:表示如果 <span> 的 display 設定為 block 則不在此限。)
    「text-align: center;」是將某個區塊(block)內的 inline 內容置中,而不是(也不該是)用來將區塊本身置中的。要將區塊置中,可以將「margin-left」及「margin-right」屬性設定為 auto,並將「width」指定一數值、讓該區塊比其容器區塊(containing block)來得小即可。

當然也可能(雖然機會不大)是你碰上了程式錯誤,這裡有份加註 Mozilla 程式錯誤的 CSS1 規格書

Q:圖層(Layer)沒用!為何會這樣?

<layer> 是個特有的擴充標籤,並非 HTML 規格的一份子。我們不支援 <layer> 標籤,請改用 <div> 標籤

Q:JavaScript 沒用!為何會這樣?

有些 document 物件的屬性如 document.all 與 document.layers 並非 W3C DOM 標準的一份子。Mozilla 不支援它們,請改用 document.getElementById() 方法

此外,某些老舊的瀏覽器偵測程式(client sniffer)會將新瀏覽器排除在外。公用 API(W3C DOM)的目的在於互通(interoperability),再額外偵測出不支援此公用 API 的特定瀏覽器。當使用 DOM 時,最好先檢查一下你想用的物件及方法。舉例而言,你可以用如下方式檢查瀏覽器是否支援 document.getElementById():

代碼:
if(document.getElementById) {
  /* 在此放置支援 document.getElementById() 時所要執行的�{式碼 */
}


Q:為何 Mozilla 不將我設定的 alt 屬性顯示為工具提示(tooltips)?

alt 屬性的本意不是拿來作為「工具提示」的,其用意是做為「替代文字」、在圖片無法顯示時才取而代之。眾多 Windows 平台上瀏覽器的做法反而背道而馳。

Mozilla 並不將 alt 屬性顯示為工具提示,因為如此一來是變相鼓勵網頁作者誤用屬性。

    一旦將替代文字顯示為工具提示,網頁作者就可能寫出不良的替代文字,因為他們會將其視為輔助的工具提示,而非「圖片的替代品」。(「不良」指的是在圖片無法顯示時,文字涵義不足以替代圖片的情形。)
    一旦將替代文字顯示為工具提示,有些作者就不會想要寫替代文字了,因為他們不想要顯示工具提示。(如此一來,無緣得見圖片的參觀者就越發難懂網頁的意思了。)


有另外一種屬性可以讓 Mozilla 將其顯示為工具提示:「title」。事實上,在 HTML 4.01 規格書中建議可讓 title 屬性顯示為工具提示。不過當然這種建議不見得必為所有瀏覽器採納,例如有些瀏覽器就將 title 屬性顯示在狀態列中。

此時或許有些人會在討論區或 Bugzilla 中貼篇「不過 IE...」的文章,但請注意:即便是 Mac 版的 IE 5 在遇到 alt 及 title 屬性時,處理方式也與 Mozilla 相同;另外,Windows 版的 IE 也可以將 title 屬性顯示為工具提示。

Q: 為什麼我不能在 XML 文件中使用 HTML?

只有使用了正確命名空間(namespace)的元素才能被視為 XHTML 標籤。XHTML 的正確命名空間 URI 為「http://www.w3.org/1999/xhtml」,並非 HTML 4.0 規格書的 URL。此外,所有的 XHTML 元素及屬性皆必須為小寫。

Q: Mozilla 是否支援動態下載的字形?

Mozilla 不支援動態下載字形。

動態下載字形通常被用來作為過去瀏覽器支援不足情形下的補救措施。這些網站(例如某些印度網站)將文字以某種拉丁語調編寫,然後讓瀏覽器用某種字體使那些文字看起來像是梵文,那些語調加上字型之後就成了某種人類可讀的語言。同樣的做法也常在希臘文字及數學符號的情形下發生。

顯然,當了解 Unicode 的瀏覽器面世時,「某種拉丁語調」轉換後依舊只能是「某種拉丁語調」(從 Unicode 的觀點來看,原來書寫時是什麼顯示出來就是什麼)。所以與其支援動態下載的字型,Mozilla 選擇將焦點放在背後真正的問題上:擴大 Unicode 的支援範圍。

不過,在某些平台上的印度語至今仍有些許問題。舉例來說 Mac OS X 上的 Mozilla 不使用系統上的梵文字體,卻可使用協力廠商的字體(如 TITUS Cyberbit)。

Mozilla 在 Unicode 的支援上已經費了很大的工夫。支援動態下載字型勢必得再花費大量心力,亦有可能受到重重專利權問題的阻礙,但即便成功效果也有限。因此,對於非 ISO-8859-1 的字元集 Mozilla 提供了 Unicode 的支援,比個別網站分開下載字型還更為符合需求。

Q: Mozilla 支援 XSL 嗎?

Mozilla 支援 XSLT,但不支援 XSL-FO。

Mozilla 的佈局引擎是為 CSS 格式模型所設計的。CSS 非常適合用以在互動程式中為結構式 HTML 或類似語言套用樣式,不需知曉輸出裝置的真實屬性。也就是說,CSS 適合在網頁瀏覽器上運作。

引言回覆:
Bob: 下面這個翻得有點心虛, 有什麼錯誤麻煩一定要告訴我... @_@...


Q:為什麼我的網頁在 Mozilla 上看起來不如我所想?我的網頁的確不合標準,但好的瀏覽器應該要如作者所想般顯示網頁!

網頁作者們該以網站標準傳達心中所想,否則便需人類般的心智能力,才能猜測每個作者的想法、找出其意圖-這在軟體中辦不到。即使有人類能推斷他人意圖,在軟體中要做到如此境界必然也會異常緩慢且錯誤連連。

一般常見的爭論不做他想:「Mozilla 應該要能夠跟某 x 瀏覽器一樣如何如何...」(其中的 x 是該使用者最喜歡的「非」Mozilla 瀏覽器),但要在各方面都做得跟某 x 瀏覽器一樣並非如此容易,即使是看起來簡單至極的動作也可能有很大的難度。

不同的人都有不同的那個「 x」,而第二個問題是網站作者在偏離標準的方式上實在五花八門,太有創造力了。事實上由於網頁的長度無所現制,所以偏離標準方式的數量也從來沒有上限。所以,要去測試 Mozilla 是否能與其它「x」瀏覽器在各方面皆完全相同,實在是強人所難。(同樣的,標準之間相結合所產生的功能數量也從來沒有上限,這讓軟體品質管制上多了一層挑戰。)

況且,「x」瀏覽器在面對不符規格的輸入時所產生的反應也並非總在意料之中,有些情況的反應是源於複雜程式裡出乎意料的交互作用。就算你能修改「x」瀏覽器的原始碼,也無法擔保不會引發更多程式交互上的意外。

其他常見的爭論是要求 Mozilla 只要在某種特定情況下的行為跟「x」瀏覽器一樣就好,但事實常常證明 Mozilla 早就是那樣做了。Mozilla 的「標準」模式顯然已與其他遵照相同規格、正確實做的瀏覽器行為一致。另一方面,Mozilla 的 quirks 模式也已能接納一般舊瀏覽器能支援的非標準程式。

與其花時間精力去做反向工程來複製一個某瀏覽器的分身,向標準看齊才是更有意義的舉動。(他人訂立的)標準可以確保交互流通,比連錯誤都一起複製過來的瀏覽器分身好多了。

Q: 我找不到我要的答案,該去哪裡詢問呢?

試著在與你問題相關的 comp.infosystems.www.authoring.* 新聞群組中發問,如果你的問題與 JavaScript/ECMAScript 或 DOM 相關,可於 comp.lang.javascript 中發問(當然,請記得先閱讀該群組的常見問題集)。請勿於 Mozilla 開發新聞群組中張貼網頁設計的相關問題。

* comp.infosystems.www.authoring.html Web Authoring FAQ
* comp.infosystems.www.authoring.stylesheets FAQ
* ciwas stylesheet authoring FAQ
* comp.lang.javascript FAQ

作者:Henri Sivonen (原文有email地址, 請不要寄信問網頁設計的問題)
翻譯: Bob Chao

===
2004/3/18, 修正一句:否則便需人類般的心智能力,才能猜測每個作者的想法、找出其意圖
thx lockchou

_________________
雜工 :: 柏強 / Bob Chao
發問討論請保持禮節,在志工社群裡沒有人有「義務」要為您做些什麼。

* MozTW 志工無限招募中,開放網路世界需要您的一臂之力


最後由 BobChao 於 2004-02-12, 09:23 編輯,總共編輯了 3 次。

回頂端
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
 個人資料  
 
 文章主題 :
文章發表於 : 2005-05-17, 20:51 
離線
[網站管理員]
頭像

註冊時間: 2002-01-07, 19:28
文章: 3080
來自: 台灣
我正在更新這份文章,還缺兩段好長啊,有空的幫忙一下...

引言回覆:
Mozilla 在 HTTP 表頭中的 Accept 處表明偏好 application/xhtml+xml,而後才是 text/html。這是否表示我該送 application/xhtml+xml 的資料給 Mozilla?

The preference for application/xhtml+xml was added to theAccept header in order to enable the serving of MathML to both Mozilla and IE with Apache without scripting back when the MathPlayer plug-in for IE did not handle application/xhtml+xml.

If your document mixes MathML with XHTML, you should use application/xhtml+xml.

If you’re developing XHTML Basic content for mobile devices and are serving it as application/xhtml+xml, you can serve it as application/xhtml+xml to Mozilla as well without taking special steps (except perhaps providing a different style sheet for the handheld and screen media).

However, if you are using the usual HTML features (no MathML) and are serving your content as text/html to other browsers, there is no need to serve application/xhtml+xml to Mozilla. In fact, doing so would deprive the Mozilla users of incremental display, because incremental loading of XML documents has not been implemented yet. Serving valid HTML 4.01 as text/html ensures the widest browser and search engine support.

There is a fad of serving text/html to IE but serving the same markup with no added value as application/xhtml+xml to Mozilla. This is usually done without a mechanism that would ensure the well-formedness of the served documents. Mechanisms that ensure well-formed output include serializing from a document tree object model (eg. DOM) and XSLT transformations that do not disable output escaping. When XHTML output has been retrofitted to a content management system that was not designed for XML from the ground up, the system usually ends up discriminating Mozilla users by serving tag soup labeled as XML to Mozilla (leading to a parse error) and serving the same soup labeled as tag soup to IE (not leading to a parse error).


引言回覆:
application/xhtml+xml 跟 text/html 的文件處理上有何不同?

* An XML parser (expat) is used instead of the tag soup parser.
o Most well-formedness constraints are enforced. (Currently Mozilla does not catch character encoding errors, because the document is re-encoded using a lenient encoding converter before the document reaches the XML parser. This is a bug.) Despite common allegations to the contrary, the document is not checked for validity.
o Entities other than the five pre-defined ones (&lt;, &gt;, &amp;, &quot; and &apos;) are only supported if the document references a public identifier for which there is a mapping in Mozilla’s pseudo-DTD catalog and the document has not been declared standalone.
o In older versions of Mozilla as well as in old Mozilla-based products, there is no pseudo-DTD catalog and the use of entities (other than the five pre-defined ones) leads to an XML parsing error. There are also other XHTML user agents that do not support entities (other than the five pre-defined ones). Since non-validating XML processors are not required to support entities (other than the five pre-defined ones), the use of entities (other than the five pre-defined ones) is inherently unsafe in XML documents intended for the Web. The best practice is to use straight UTF-8 instead of entities. (Numeric character references are safe, too.)
o document.write() is not supported. The stream that is going into the parser can’t be tampered with in mid-parse.
o Things that look like XML comments are treated as XML comments—even inside script or style elements.
o Elements need to be in the XHTML namespace in order to be treated as XHTML elements.
o meta tags are not examined for character encoding information.
o tbody, head, body, and html are not inferred if the tags are not explicitly present.
o CDATA sections are supported.
o XML empty element notation (<foo/>) is supported.
* The document is not loaded and rendered incrementally. That is, the document is displayed only after the entire document has been received and parsed. Contrary to a common misguided assertion, this is not done in response to a requirement set forth in any W3C specification. In particular, the XML specification does not require the entire document to be checked for errors before rendering can start. The lack of incremental loading and display is simply a bug (or a missing feature).
* The layout mode is the (Full) Standards Mode regardless of doctype.
* CSS works according to the XML+CSS rules.
o HTML-specific CSS exceptions do not apply. For example, the body element gets no special treatment.
o CSS selectors are case-sensitive.
o Namespace at-rules are supported.
* The DOM is in the XML mode.
o Namespace-aware variants of methods need to be used when working with elements (eg. createElementNS() instead of createElement()).
o In older versions of Mozilla, the document object does not implement the HTMLDocument interface.
o Element and attribute names are not normalized to upper case.
o In older versions (including Firefox 1.0), content cannot be added using innerHTML.
* Other namespaces are supported.
o MathML
o Simple XLink
o SVG (in SVG-enabled builds only)
o XUL (Please note that XUL is Mozilla-specific and, therefore, using it on the public Web causes interoperabilty problems.)
* xml:base is observed when following links.

_________________
雜工 :: 柏強 / Bob Chao
發問討論請保持禮節,在志工社群裡沒有人有「義務」要為您做些什麼。

* MozTW 志工無限招募中,開放網路世界需要您的一臂之力


回頂端
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)
 個人資料  
 
 文章主題 :
文章發表於 : 2005-05-18, 22:59 
BobChao 寫:
Q: Mozilla 是否支援動態下載的字形?

Mozilla 不支援動態下載字形。

動態下載字形通常被用來作為過去瀏覽器支援不足情形下的補救措施。這些網站(例如某些印度網站)將文字以某種拉丁語調編寫,然後讓瀏覽器用某種字體使那些文字看起來像是梵文,那些語調加上字型之後就成了某種人類可讀的語言。同樣的做法也常在希臘文字及數學符號的情形下發生。

顯然,當了解 Unicode 的瀏覽器面世時,「某種拉丁語調」轉換後依舊只能是「某種拉丁語調」(從 Unicode 的觀點來看,原來書寫時是什麼顯示出來就是什麼)。所以與其支援動態下載的字型,Mozilla 選擇將焦點放在背後真正的問題上:擴大 Unicode 的支援範圍。

不過,在某些平台上的印度語至今仍有些許問題。舉例來說 Mac OS X 上的 Mozilla 不使用系統上的梵文字體,卻可使用協力廠商的字體(如 TITUS Cyberbit)。

Mozilla 在 Unicode 的支援上已經費了很大的工夫。支援動態下載字型勢必得再花費大量心力,亦有可能受到重重專利權問題的阻礙,但即便成功效果也有限。因此,對於非 ISO-8859-1 的字元集 Mozilla 提供了 Unicode 的支援,比個別網站分開下載字型還更為符合需求。

上面這段只是找台階下啊--事實是Mozilla.org的確想做但在技術上遭遇瓶頸,所以目前無法支援任何一種規格的動態字型。除了支援某些不在Unicode碼位內的怪異語言(星界系列的亞維文該算吧? :twisted: )這種用途外,動態字型真正重要的作用是在字型作者允許的範圍內提供字型的動態下載功能,而能達到如PDF般所見(字型)即所得的能力。話說動態字型是CSS2的規格之一,所以bug 52746多一天不解決,Mozilla/Firefox就多一天無法完全相容CSS2。 :evil:


回頂端
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)
  
 
 文章主題 :
文章發表於 : 2005-05-19, 01:46 
離線
頭像

註冊時間: 2004-09-17, 18:02
文章: 1913
來自: MSB, MND
Mozilla 在 HTTP 表頭中的 Accept 處表明偏好 application/xhtml+xml,而後才是 text/html。這是否表示我該送 application/xhtml+xml 的資料給 Mozilla?

加到表頭 Accpet 處的偏好 application/xhtml+xml 是為了當 IE 的 MathPlayer Plug-in 無法處理 application/xhtml+xml 時,同時在 Mozilla 和 IE 的 Apache 沒有 scripting back 時送出 MathML 資料。

如果你的文件混合了 MathML 與 XHTML,你應該用 application/xhtml+xml 送出資料。

如果你正在開發以 XHTML 為基礎供行動裝置瀏覽的資料而且以 application/xhtml+xml 送出,那麼你也可以用 application/xhtml+xml 送出資料給 Mozilla 而不需要特別的步驟 (除非你要提供 handheld 與 screen media 兩種不同的樣式表。)

但是如果你只要用到普通的 HTML 功能 (不用 MathML) 而且用 text/html 送給其他瀏覽器,就不需要用 application/xhtml+xml 送出資料給 Mozilla。事實上這樣做會讓 Mozilla 使用者的增量顯示失效,因為 XML 的增量載入尚未被實作。以 text/html 送出經驗證的 HTML 4.01 可以確保最多的瀏覽器和搜尋引擎的支援。

There is a fad of serving text/html to IE but serving the same markup with no added value as application/xhtml+xml to Mozilla. This is usually done without a mechanism that would ensure the well-formedness of the served documents. Mechanisms that ensure well-formed output include serializing from a document tree object model (eg. DOM) and XSLT transformations that do not disable output escaping. When XHTML output has been retrofitted to a content management system that was not designed for XML from the ground up, the system usually ends up discriminating Mozilla users by serving tag soup labeled as XML to Mozilla (leading to a parse error) and serving the same soup labeled as tag soup to IE (not leading to a parse error).

--
好難翻喔...= =" BobChao 自己修一下,最後一段讓別人翻好了= ="

_________________
吟風齋


回頂端
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
 個人資料  
 
 文章主題 :
文章發表於 : 2005-05-19, 18:44 
離線
[網站管理員]
頭像

註冊時間: 2002-01-07, 19:28
文章: 3080
來自: 台灣
Alica 寫:
上面這段只是找台階下啊--事實是Mozilla.org的確想做但在技術上遭遇瓶頸,所以目前無法支援任何一種規格的動態字型。除了支援某些不在Unicode碼位內的怪異語言(星界系列的亞維文該算吧? :twisted: )這種用途外,動態字型真正重要的作用是在字型作者允許的範圍內提供字型的動態下載功能,而能達到如PDF般所見(字型)即所得的能力。話說動態字型是CSS2的規格之一,所以bug 52746多一天不解決,Mozilla/Firefox就多一天無法完全相容CSS2。 :evil:


ㄜ 其實我看完那個 bug 嗅不出"的確想做"的意味
不過怎麼解釋總是有個說法 認不認同就隨個人囉

有空的話幫翻一下啦著實難譯

_________________
雜工 :: 柏強 / Bob Chao
發問討論請保持禮節,在志工社群裡沒有人有「義務」要為您做些什麼。

* MozTW 志工無限招募中,開放網路世界需要您的一臂之力


回頂端
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)
 個人資料  
 
 文章主題 :
文章發表於 : 2005-05-20, 07:00 
離線
[MozTW 版主群]
頭像

註冊時間: 2003-09-15, 03:47
文章: 1016
來自: Taiwan
草率交卷...

application/xhtml+xml 跟 text/html 的文件處理上有何不同?

* 用 XML 剖析器 (expat) ,而不是標籤雜燴(tag soup)剖析器。
o 強制大部份的完構(well-formed)(目前 Mozilla 不會逮住字元編碼的錯誤,因為文件在送至 XML 剖析器前已先被寬鬆的編碼轉移器重新編碼過。這是個 bug)。雖然一般被宣稱有,但文件正確性沒有被檢查。
o 除了五個預先定義的 &amp;lt;、&amp;gt;、&amp;amp;、&amp;quot; 與 &amp;apos; 外,實體支援的條件為該文件有引用一個公用識別符(public identifier)且該識別符在 Mozilla 的假 DTD 目錄內有對照,還有該文件並未被宣告為獨立。
o 舊的 Mozilla 與以 Mozilla 為基礎的產品內沒有假 DTD 目錄,因此使用五個預先定義實體外的實體將引發 XML 剖析錯誤。還有其它的 XHTML 用戶代理不支援五個預先定義實體外的實體。因為不確認的 XML 剖析器不被要求支援五個預先定義實體外的實體,在網上 XML 文件內使用(五個預先定義的之外)實體的本身並不安全。最好的方法是直接用 UTF-8 而不是用實體。( 數字字元參引也是很安全。)
o document.write() 不受支援。傳送剖析器的 stream can’t be tampered with in mid-parse.


回頂端
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
 個人資料  
 
 文章主題 :
文章發表於 : 2005-05-27, 00:45 
離線
[網站管理員]
頭像

註冊時間: 2002-01-07, 19:28
文章: 3080
來自: 台灣
新版, for review:

http://leolo.ath.cx/~bobchao/other_file ... orking.php

有三個地方我不會,幫忙解釋一下意思吧... 倫倫翻了第一段、Daniel 翻了第二段,但是由於翻完了我還是看不懂所以先沒有用 =.= 第三段是我不懂的東西

---------------------

挖勒,前面那兩段真的很難很難翻耶。

Entities other than the five pre-defined ones (&lt;, &gt;, &amp;, &quot; and &apos;) are only supported if the document references a public identifier for which there is a mapping in Mozilla’s pseudo-DTD catalog and the document has not been declared standalone.

我的理解:

1. 五個預設實體可以用 (當然囉)
2. 其他實體,要用的話有以下條件: 1) 文件先用 DOCTYPE 宣告所屬類型的 Public ID (ex: "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd")
2) 此 Public ID 在 Mozilla 內有相對應的虛擬 DTD
3) 虛擬 DTD 中已經定義此實體


更白話點講: Mozilla 裡面 (為了分析 XML) 已經內建一些 DTD 了,由於不是真的放在網路上的那份,所以稱為 pseudo-DTD。分析 XML 文件時,如果此文件定義的 DTD 剛好 Mozilla 自己有,那就用自己的、不另外找 DTD 來配合分析。

我想或許就是 {安裝路徑}/res/dtd 裡的那些?

這樣對嗎?如果對,這段文件我不打算照原文翻譯... 太難翻了有看沒懂,改用列表式...

如果錯,來教我一下吧 ^^;

_________________
雜工 :: 柏強 / Bob Chao
發問討論請保持禮節,在志工社群裡沒有人有「義務」要為您做些什麼。

* MozTW 志工無限招募中,開放網路世界需要您的一臂之力


回頂端
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)
 個人資料  
 
 文章主題 :
文章發表於 : 2005-05-27, 09:00 
離線
[MozTW 版主群]
頭像

註冊時間: 2003-09-15, 03:47
文章: 1016
來自: Taiwan
BobChao 寫:
Entities other than the five pre-defined ones (<, >, &, " and ') are only supported if the document references a public identifier for which there is a mapping in Mozilla’s pseudo-DTD catalog and the document has not been declared standalone.


<?xml version="1.0" standalone='yes'?>
Standalone Document Declaration (獨立文件宣告): 標示宣告可以影響(從 XML 處理器傳到應用程式)的文件的內容。一些例子為屬性預設值與實體(entity)宣告。獨立文件的宣告(這[url=http://wiki.moztw.org/index.php?title=一般技術規格]可以(may)[/url]是 XML 宣告的一部份)信號著在文件實體外部或在內部參數實體((parameter entity)有沒有有這類宣告。[定義:「外部標示宣告 (external markup declaration)」定義表示該標示宣告出現在外部子集(subset)或在參數實體(外部或內部,包括內部是因為不確認(non-validating)處理器不受要求要讀它)。]

所以,Mozilla 會支援五個預設實體之外的實體情況為:

1. 文件有用到公用識別符,並且 Mozilla 內部對照表列有該公用識別符,或者
2. 文件內部或外部有對這些實體做定義

註: PUBLIC "-//W3C//DTD XHTML 1.1//EN" 這是公用識別符,但是 PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" 有包括了外部定義的子集 URL


回頂端
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
 個人資料  
 
 文章主題 :
文章發表於 : 2008-10-14, 09:56 
離線
頭像

註冊時間: 2006-11-01, 15:18
文章: 132
Alica 寫:
BobChao 寫:
Q: Mozilla 是否支援動態下載的字形?

Mozilla 不支援動態下載字形。

動態下載字形通常被用來作為過去瀏覽器支援不足情形下的補救措施。這些網站(例如某些印度網站)將文字以某種拉丁語調編寫,然後讓瀏覽器用某種字體使那些文字看起來像是梵文,那些語調加上字型之後就成了某種人類可讀的語言。同樣的做法也常在希臘文字及數學符號的情形下發生。

顯然,當了解 Unicode 的瀏覽器面世時,「某種拉丁語調」轉換後依舊只能是「某種拉丁語調」(從 Unicode 的觀點來看,原來書寫時是什麼顯示出來就是什麼)。所以與其支援動態下載的字型,Mozilla 選擇將焦點放在背後真正的問題上:擴大 Unicode 的支援範圍。

不過,在某些平台上的印度語至今仍有些許問題。舉例來說 Mac OS X 上的 Mozilla 不使用系統上的梵文字體,卻可使用協力廠商的字體(如 TITUS Cyberbit)。

Mozilla 在 Unicode 的支援上已經費了很大的工夫。支援動態下載字型勢必得再花費大量心力,亦有可能受到重重專利權問題的阻礙,但即便成功效果也有限。因此,對於非 ISO-8859-1 的字元集 Mozilla 提供了 Unicode 的支援,比個別網站分開下載字型還更為符合需求。

上面這段只是找台階下啊--事實是Mozilla.org的確想做但在技術上遭遇瓶頸,所以目前無法支援任何一種規格的動態字型。除了支援某些不在Unicode碼位內的怪異語言(星界系列的亞維文該算吧? :twisted: )這種用途外,動態字型真正重要的作用是在字型作者允許的範圍內提供字型的動態下載功能,而能達到如PDF般所見(字型)即所得的能力。話說動態字型是CSS2的規格之一,所以bug 52746多一天不解決,Mozilla/Firefox就多一天無法完全相容CSS2。 :evil:


@font-face 現在的 Beta 1 應該就支援了 (或者是要 try server build 我也不確定)

也有測試用的 Live Example

只是 Bug 蠢蠢騷動不停....Orz

1. 只支援 Mac OS X 及 Windows (不包括 Windows NT)

2. 不支援 .otf 格式的字型檔,只能使用 .ttf

3. 暫不接受 Cross-site Access

4. 其他有的沒的

想比較的可以拿 Safari 3.1 來比較,是目前唯一有支援的正式 Release

--

現在好像 CSS 3 Multiple Background 也在實作中了

真是引頸翹望啊 XDDDDD


回頂端
Mozilla/5.0 (Windows; U; Windows NT 6.0; zh-TW; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
 個人資料  
 
顯示文章 :  排序  
發表新文章 這個主題已被鎖定,您不能編輯或回覆這個主題。  [ 9 篇文章 ] 

所有顯示的時間為 UTC + 8 小時


誰在線上

正在瀏覽這個版面的使用者:沒有註冊會員 和 8 位訪客


不能 在這個版面發表主題
不能 在這個版面回覆主題
不能 在這個版面編輯您的文章
不能 在這個版面刪除您的文章
不能 在這個版面上傳附加檔案

搜尋:
前往 :  
cron
Powered by phpBB® Forum Software © phpBB Group
正體中文語系由 竹貓星球 維護製作
© moztw.org, Mozilla Foundation
MozTW,Mozilla 台灣社群