Yahoo!用戶界面博客（YUIBlog）

YUI的3.3.0預覽版3

在十一月YUIConf我們發布了YUI的3.3.0預覽，我們的下一個主要版本銳3代碼行 。 我們現在到我們的第三個預覽版，如果你有一些在冬季假期的時間來幫助我們，我們很樂意為您給它一個旋轉淺嚐輒止。 可以使用的CDN的銳3.3.0pr1種子文件開始， 分佈從YUILibrary.com下載 ，或檢查出的主辦上YUIBlog （ 3.3.0pr3分佈注：由於缺乏YUIBlog的表現也相當呆滯組合處理;放心，您的CDN驅動實現一般會比相應3.2.0使用更快）。

一些新的東西，看在這個版本：

• 所有新的自動完成（試用版）
• 所有新圖表（試用版） ，SVG的支持，帆布和VML
• 所有新的DataTable（試用版） ，從流行的YUI 2組件更加模塊化升級的開端
• 新的撥號控制（試用版） ，一個創新的雅虎設計師傑夫·康尼夫創建一個有限的範圍內控制或滑塊
• 所有新調整大小工具（測試版） ，由愛德華多的Liferay，合著者倫德格倫內特基於YUI的3卡瓦諾AlloyUI擴展可用的YUI 3畫廊提供。 （你能滿足愛德華多和內特在這AlloyUI旋風之旅2010年在YUIConf拍攝 。）

還有更多的愛YUI的3.3.0，我們將分享更多的信息，作為GA日期臨近。 目前，我們希望在一月的第二個星期的釋放窗口。 我們歡迎您的反饋，在預覽銳論壇和機票數據庫，如果你發現所關心的問題，當你測試出自己的實現與新版本。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

YUILibrary.com停機維護（更新：現在備份）

更新12/21/2010下午12:32：備份和運行-讓我們知道，如果你看到任何問題。

我們今天上午已經取下來YUILibrary.com維修。 我們預計這項工作將持續4-6小時。 我們帶來的不便表示歉意，我們會盡量保持盡可能短的停機時間。

如果你有緊急支援問題，在此期間，考慮下降＃YUI通道上的Freenode.net，在那裡你會經常發現數十名成員互相幫助，銳界的。

YUIBlog和@ YUILibrary的運行更新時，該網站將是備份。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

YUI的2.9.0版本更新

YUI團隊下週將開始規劃版本2.9.0將在下半年的2011年第一季度出貨。 銳2.9.0將2.x的代碼行的最後一個主要點釋放，球隊將積極檢討開放對YUI 2項目的所有門票，要么將他們分配到的2.9.0版本的一部分，收盤他們“無法修復”，或將它們轉移到YUI的3個項目。

時間和資源約束的現實迫使我們把重點放在重中之重項目，將提供一些封閉了YUI 2.x的和3.x的發展，讓我們加倍我們的努力。 這裡有一些標準，我們將使用來指導我們在決定什麼應該包含在2.9.0版本：

• 負面影響的核心用例的問題。
• 新興的A級矩陣的新的瀏覽器版本有關的問題。
• 改進和新功能將被取消優先銳2和3銳認為。

來自發展中國家的兩個並行代碼行只重點銳3 YUI團隊的過渡並不意味著結束的YUI 2項目。 所有目前和未來的銳2版本將繼續對雅虎的CDN承載，YUI 2代碼庫將繼續託管在GitHub上，我們希望在未來探索以社區為基礎的維護銳2。

，我們將繼續我們的規劃過程中，我們會微調我們的時間表，從社會反饋，溝通整個發行週期的最新進展。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

嚴格模式來鎮

這是時間和季節，當世界各地的人們忘記了他們之間的分歧，並在和平和友誼，共同慶祝一週年ECMA大會批准的ECMAScript的編程語言標準，第五版。 ES5中最重要的特點是嚴格的新模式。 嚴格模式是一種選擇的模式，修理或消除語言的最棘手的一些特點。

指定嚴格模式

有兩種方式，要求嚴格模式。 首先是插入該pragma

  “使用嚴格”; 

在一個文件或編譯單元的頂部。 它必須出現在任何其他的語句，但它可能是由前面的空白和註釋。 它有一個無用的字符串文字敘述的形式，使ES3的系統，它將被忽略。 這意味著，它有可能，寫ES5/strict方案，也可以運行在舊的瀏覽器。 嚴格的代碼也可以交互與非嚴格的代碼（或馬虎 ），所以嚴格的函數可以調用馬虎的功能，草率的函數可以調用嚴格的功能。 這種高度的兼容性，通過嚴格的模式容易。

嚴格的代碼將處理所有代碼中的文件或編譯單元"use strict";序言。 有一個問題，雖然性能方面的考慮，目前迫使我們一起串連許多JavaScript文件，以避免累積的HTTP延遲。 如果一個文件"use strict";的序言有馬虎的代碼追加到它，草率的代碼將作為嚴格的處理，可能會失敗。 有一個簡單的規則：不要在嚴格相同的文件和草率，但我們已經看到一些著名的網站得到這個錯誤。

第二種方式是作為一個函數的第一條語句插入的pragma。 聲明的整體功能，將是嚴格的，包括任何嵌套在它的功能。 寬嚴方面的功能範圍，如此嚴格的代碼和草率的代碼可以混合在同一個文件。 這第二種形式與模塊模式和它的許多變化，工作得非常好。 第二種形式是首選，因為它避免了串聯危險。

  （函數（）{
    “使用嚴格”;
    / /這個函數是嚴格...
 }（））;

 （函數（）{
    / /但是這個功能是馬虎...
 }（））; 

範圍

從歷史上看，JavaScript已經困惑如何職能範圍。 有時候，他們似乎是靜態範圍，但某些功能，使他們像他們動態範圍。 這是混亂的，使程序難以閱讀和理解。 誤解造成的錯誤。 它也是一個性能問題。 靜態作用域將允許綁定變量在編譯時發生，但動態範圍的要求意味著必須綁定推遲到運行時，其中一個顯著的性能損失。

嚴格模式要求所有的變量綁定靜態進行。 這意味著，以前需要動態綁定的功能，必須消除或修改。 具體來說， 與語句被淘汰， eval函數的能力，篡改它的調用者的環境受到嚴重限制。

嚴格的代碼的好處之一是，像工具YUI壓縮可以做得更好處理。

隱含的全局變量

JavaScript已暗示了全局變量。 如果你不顯式聲明一個變量，全局變量是隱式聲明為你。 這使得編程的初學者更容易，因為他們可以忽略其基本的家務瑣事。 但它使較大的程序的管理困難得多，它大大降低可靠性。 因此，在嚴格模式下，隱含全局變量不再創建。 你應該明確聲明所有的變量。

全球洩漏

有很多的情況下，可能會導致this勢必全局對象。 例如，如果你忘記調用構造函數時提供了new前綴 ， this將勢必意外的全局對象構造函數的，而不是初始化一個新的對象，因此，它反而會默默地與全局變量篡改。 在這種情況下，嚴格的模式，而不是將this undefined ，這將導致構造函數拋出異常，而是允許更快被檢測到的錯誤。

嘈雜的失敗

JavaScript已只讀屬性，但你不能創建它們自己，直到ES5的Object.createProperty功能暴露了這種能力。 如果試圖分配一個值到一個只讀屬性，它會靜靜的失敗。 轉讓不會改變財產的價值，但你的程序將繼續進行，儘管它有。 這是一個完整的危險，可能會導致程序進入不一致的狀態。 在嚴格模式下，試圖改變一個只讀的屬性，將拋出一個異常。

八路

八進制（基數為8）的數字代表的是做機器級編程的機器上的字的大小分別為3的倍數時非常有用。 你需要八進制時，工作與疾病預防控制中心6600大型機，其中有一個60位的字的大小。 如果你能讀八進制，你可以看作為20位的字。 兩位數字表示運算的代碼，和一個數字確定的8個寄存器之一。 在緩慢的過渡，從機器代碼高級語言，它被認為是有用的編程語言中的八進制形式提供。

在C中，一個極為不幸的代表性octalness選擇：前導零。 因此，在C，0100意味著64，而不是100，和08是一個錯誤，而不是8。 更不幸的是，這種不合時宜的已被複製到幾乎所有的現代語言，包括JavaScript，它僅用於創建錯誤。 它有沒有其他目的。 因此，在嚴格模式下，不再允許八進制形式。

等等

的arguments偽陣列成為多一點點在ES5類似數組。 在嚴格模式下，它失去了它的callee和caller屬性。 這使得它可以通過你的arguments而放棄了很多保密的情況下不受信任的代碼。 此外， arguments功能的財產被淘汰。

在嚴格模式下，重複鍵功能常會產生一個語法錯誤。 具有相同名稱的函數不能有兩個參數。 函數不能有一個變量具有相同的名稱作為它的參數之一。 函數不能delete自己的變量。 試圖delete一個非配置屬性現在拋出一個異常。 原始值不隱裹。

如果你的程序通過JSLint ，它可能會在嚴格模式下工作。

它仍然是一個不完美的世界

在JavaScript中仍然存在的問題，嚴格模式沒有解決。 例如，插入分號仍然是危險，和0.1 + 0.2仍是不等於0.3。 糾正這些問題，將不得不等待未來版本。

為什麼要嚴格模式事宜

在嚴格模式除了程序的可靠性和可讀性明顯的好處，幫助解決混搭問題。 我們希望能夠邀請到我們的網頁第三方的代碼，做有用的東西，沒有給這些代碼的許可證接管瀏覽器或歪曲自己的用戶或我們的服務器，為我們和我們的用戶。 我們需要約束的第三方代碼。 像系統谷歌的卡哈做到這一點，但在顯著的成本，在性能和不便。 自己ADsafe系統也這樣做，但在消除成本this []標從語言，它可以使通過困難。 嚴格模式，使我們能夠第三方代碼的方便性和性能的ADsafe卡哈表現。 我們的網站變得更加複雜和更加緊密，這將是極為重要的。

嚴格的模式不解決XSS問題。 這個問題的解決取決於採取了一些積極的行動W3C的 。

ES5/strict現在是預覽，並很快將在所有符合標準的瀏覽器中無處不在的標準設備。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

CSS position屬性

此屬性適用於所有的元素。 它有五個可能的值：

• static
• relative
• absolute
• fixed
• inherit

位置：靜態

從第9 可視化格式模型 ：

框是一個正常的框，按照正常流動奠定了。 top ， right ， bottom ，和left屬性並不適用。

我注意到在此演示

• 第二個框中顯示了它的確切位置，將沒有表態。
• 考慮到價值top 不適 ，因為在“靜態”的背景下， 框偏移的計算值始終是auto 。

需要記住的事情

• 如果一個元素的屬性的position具有價值的static ，該元素不說定位 。
• 因為static初始值（默認值），有沒有必要，除非它是覆蓋不同的價值包括在聲明塊造型。

位置：相對

從第9 可視化格式模型 ：

框的位置是按正常的流量（這就是所謂的正常流動中的地位）。 然後箱子被抵消相對其正常位置。 當一個盒子B是相對定位，下面的方塊的位置，不能抵消，雖然B組計算。

我注意到在此演示

• 盒子'兩個'向下移動300個像素，但框'三'，以及下面的段落留在地方。 它出現一樣，如果從頁面框被取消，其身後留下的足跡。 這是因為抵消了相對定位的框， 不干擾流 。
• 相對定位的框重疊的下列元素。 這表明在其他箱子的前面 。

需要記住的事情

• 計算出的值總是左=右，頂部=底部。 如果包含塊的direction是成為ltr ，'左'的勝利和“正確”的價值- '左'。 如果包含塊的direction是rtl ，“正確”的勝利和'左'被忽略。 作者可以採取同等價值相反的特性是如何工作的優勢。
• 與“絕對”的模式不同的是， top ， right ， bottom ，和left屬性不能伸展，也不縮小框（他們不能改變它的大小）。

位置：絕對

從第9 可視化格式模型 ：

框的位置（和可能的大小）指定的top ， right ， bottom ， left屬性。 這些屬性指定框的包含塊的偏移。 一個絕對定位的框從完全正常流動（它有沒有影響對後來的兄弟姐妹），並分配一個包含塊的位置。 此外，雖然絕對定位的框有利潤，他們不與任何其他的利潤率崩潰 。

我注意到在此演示

• 指定偏移，因為沒有框，盒子'兩個'沒有從原來的位置移動，但如果我們使用了top:0;left:0;例如，框會在視口的左上角 。
• 佈局明智的，它是像盒子'兩個'已與樣式display:none 。 從流框已被刪除。
• 盒子'三個'盒子'兩個'流出來，提出了反對盒'一'（遵循段）。
• 從流中刪除所有元素一樣，盒子'兩個'水平收縮包裝。

需要記住的事情

• 計算值display對於任何 “絕對”或“固定”的定位的元素是block 。
• 對於任何 “絕對”或“固定”的定位的元素計算值float是none 。
• 一個包含塊“是一個盒子，建立一個定位的情況下， 建立一個“地位”的“絕對”，“相對”或“固定”，它是由最近的祖先，這意味著父框可能不包含塊 。
• 一個絕對定位框的默認位置並不總是一樣的，如果它與頂部樣式：0;左：0;（LTR的上下文中）。 這是出於兩個原因：
  1. 最近的定位祖先建立的定位框的包含塊，如果沒有，參考容器是根元素。 在它的根元素的生命是一個長方形的包含塊稱為初始包含塊。 為連續介質，它的視口的尺寸（屏幕上的一個窗口或其他觀賞區），挂靠在畫布原點。 這個例子表明定位在視口中的對話框（默認包含塊）。
  2. 元素被放置在填充框，而不是內容框也包含塊的邊界框 。 這個新的例子演示盒'兩個'將是填充框的邊緣，如果沒有觸及內容框的邊緣（包含塊body ）。
• 框的大小 ，可能的結果top ， right ， bottom ， left屬性值。 舉例來說，清空所有屬性框拉伸，以配合其包含塊的填充框的尺寸。 清空所有框的偏移量 （注：IE6 不舒展盒）。
• 要創建一個面具覆蓋， 不滾動文件（如前面的例子 ），或者使用fixed ，而不是 absolute式body position:relative 初始定位塊 是視口（造型html不會在IE瀏覽器） 。 由於這疊加的演示顯示。
• position:absolute觸發hasLayout的 。

最重要的是要記住

因為這種定位計劃從流中刪除框，它被認為是壞的實踐Zhang佈局使用。

位置：固定

從第9 可視化格式模型 ：

固定的定位是絕對定位的子類。 唯一的區別是，對於一個固定的位置“框中，包含塊是由建立視口 。 對於連續介質 ，固定框不動文檔時滾動。 在這方面，它們是相似的固定背景圖像 。 分頁媒體 （如文件的內容分割成一個或多個離散頁），固定位置的框在每一頁上都重複。 這是有用的，例如，放置在每一頁的底部簽名。 大於頁面區域框固定的位置，被裁剪。 “固定位置”框中的初始包含塊不可見的部分將無法打印。

在本演示中要注意的事情：

• 由於固定的定位是絕對定位的子類，一切是真實的“絕對”也是真正的“固定”（元素收縮包裹，它是從流，等刪除）。
• 箱子被定位在視口中 ，它不會滾動頁面。
• 在IE 6中， 作為一個靜態框框出現，但有該“滑稽” 的解決方法 。
• 打印文件時，箱'兩個'出現在每一頁。

事情要記住：

• 根據“絕對”的模式框的位置計算，但框是固定的，除了一些參考。 在掌上電腦，投影，屏幕，TTY，電視媒體類型的情況下， 視口中的固定框和滾動時不動。
• 內容可能inaccessile短視用戶框的一部分，如果視口區域以外。
• 在打印介質類型的情況下，可能要防止每個打印頁上出現的元素。 也許使用@ media規則，如：

    @媒體印刷{ 
     ＃標誌的位置是：靜態;}
   } 

• 喜歡position:absolute ， position:fixed將觸發hasLayout的在IE瀏覽器。

位置：繼承

如果對於一個給定的框指定position:inherit ，那麼它會採取相同的計算值作為屬性框的父。

請注意，IE 6和7不支持這個關鍵字，除了與使用direction和visibility （見CSS屬性值的繼承 ）。

需要考慮的事情

框偏移

要知道，絕對和固定定位框，值設置在top ， right ， bottom的百分比， left是根據包含塊 （這可能不是父框）尺寸計算。

“位置”和“溢出”

風格一箱overflow:hidden剪輯相對定位元素（嵌套的框），但它不會總是隱藏絕對定位的。 這是因為父框並不總是包含塊（ 與最近的祖先的“位置”， “絕對”，“相對”或“固定”）。

總之，這意味著將顯示絕對定位的元素以外的一個盒子樣式與溢出：隱藏的，除非其包含塊的框本身或元素內說框中。 這個演示頁面顯示是如何工作的。

利潤率

作者可以使用的元素上的利潤，無論其定位計劃。

在IE的情況下

在IE瀏覽器，“定位”一個盒子可能是福還是禍：

• position:relative (with haslayout)在IE6中，可以用來防止負利潤率從風格箱被修剪父容器（見如何定位框解決這個問題）。
• 定位元素“ 打擾 ”的方式在IE 6和7箱堆疊，因為這可能會建立一個新的堆疊範圍內（見一個測試案例 ）。

堆疊順序堆疊水平

• 根據源代碼的順序， 定位框在前面的花車和正常流動箱。
• 通過“Z-索引” 只有在定位框的屬性，作者可以指定堆棧的水平。
• 在IE6和7，定位框簡單的事實，可以建立一個堆疊環境（見上面“ 的IE瀏覽器的情況下 “）。

移動設備

閱讀庫爾德工人黨的文章， [第六屆]位置值 ，找出為什麼手機瀏覽器廠商不能真正支持position:fixed 。

進一步閱讀

• 可視化格式模型
• 位置（CSS屬性）
• 表態

由DrLangbhani一個“鬼”的比喻：

一個元素的相對位置始終相抵消它在流動的正常位置 。 換句話說，它被轉移相對的地方，這將是正常情況下，轉移它不會影響它周圍的元素的佈局。 這背後已經離開它的身體像一個幽靈。 有寬度和高度和身體影響及其周邊地區，而且是無形的。 幽靈般的方塊是可以移動，但仍然連接到老的身體，在其立場仍然從它測量。 現在，一個元素的位置絕對是更容易。 它不再影響（它拉佈局流）及其周圍地區。 它現在是一個身體沒有留下真實的鬼。 至於它的同級元素關注它，如果它不再存在。 為了得到這個位置，通過它的父元素，直到你找到任一位置之一：相對的，位置固定，]或立場：絕對的。 該元素將作為參考點。 如果你沒有找到一個“定位”元素，只將它從文件偏移。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

在銳3畫廊：傳送帶模塊

什麼是旋轉木馬？

傳送帶控制提供了一套垂直或水平排列在一個重載的頁面區域的狀物體之間的瀏覽部件。 “傳送帶”的比喻來自一個比喻，在電影拍攝天滑動轉盤，轉盤控制可以保持這個比喻的忠誠，讓一個連續的，通過所有的內容塊的圓形導航。

傳送帶是一個家庭的一部分，使你“超負荷”頁面上的空間，提供更多的內容，比在其尺寸適合的空間，同時，為用戶提供了一個簡單直觀的機制，及時發現和導航的附加內容的widget 。 手風琴，製表符，樹木和ScrollViews是這一流派的其他例子。

為何又一傳送帶控制？

YUI的3需要一個強大的，功能豐富的傳送帶（正如我們在有銳2 ）。 這個轉盤的設計目標是使精益和清潔，並添加額外的配置，通過插件，利用優勢銳3的模塊化保持亮度和速度的內在支持。

YUI的3 Widget框架

編寫自定義部件使用YUI 3最大的優勢之一是Widget的框架（Widget的框架： 用戶指南 ， 深入的視頻介紹 ）。 我的銳3畫廊傳送帶比較銳2.8.2傳送帶 ，銳3版本是精簡和優雅。 這是因為大多數提供了基礎，提供一套通用部件的屬性，有紀律的生命週期，漸進增強支持等方面的繁重的Widget類。

3 YUI的Widget框架還提供了一個一致的MVC模式，促進每一個部件，採用分離狀態的方法與UI更新方法。 這使得代碼非常乾淨和維護。 事實上，這是為什麼YUI 3傳送帶比其先前的銳2表​​妹更好的重要因素之一。

銳3插件模型允許開發人員添加新的功能或修改現有的行為對象。 這允許添加額外的功能，在傳送帶的上方，動態拉通過Ajax等元素，因此，YUI 3傳送帶沒有把它烤的動畫代碼，而是我已經創建了一個插件，它增加了動畫需要的地方的情況下支持。 這有助於保持非常輕量級的組件。

一個為自己的網站畫廊傳送帶

讀取傳送帶是什麼和如何它可以幫助你改善你的網站後，你希望感到渴望得到你的手臟。 不要擔心，我們銳3畫廊傳送帶延伸，實現您的網站上傳送帶，只要提供在HTML中的一個項目符號列表一樣簡單。 這不只是一個推銷 - 這就是我們最近如何融入雅虎體育搜索結果頁的一個展覽館傳送帶。

一個簡單的例子

讓我們先從一個簡單的例子，幾乎涵蓋了所有你需要知道的。 您使用的新畫廊傳送帶的最簡單的方法是讓銳3自動地加載它從雅虎的內容交付網絡。 回顧傳送帶是什麼，一個項目的滾動列表，我們創建了一個HTML列表。 我們有一個div中的列表，這使得我們的JavaScript輕鬆地找到並使用它。 如果您已經有一些數據是在您的標記列表的方式來表示，你可能也只是把它周圍的傳送帶格和測試你的運氣！ 這是非常重要的說，雖然我們使用了一個形象的例子，在這裡，你可以使用任何你想要的畫廊傳送帶！

  <div class="carousel" id="container">
   <OL>
     <LI> <img src="img/c1.jpg"> </ LI>
     <LI> <img src="img/c2.jpg"> </ LI>
     <LI> <img src="img/c3.jpg"> </ LI>
     <LI> <img src="img/c4.jpg"> </ LI>
     <LI> <img src="img/c5.jpg"> </ LI>
     </ OL>
 </ DIV> 

現在，我們有我們的數據工作，我們要加強顯示所有五個項目使用的傳送帶部件的外觀。 假設您已經使用YUI 3，這是一個簡單的任務。 唯一的事，你可能沒有見過的，取決於你有多深，已挖成銳3，在過去的畫廊，是我們明確指定庫版本。 這是必要的，因為我們使用的是一個全新的部件，這不是在畫廊，包括建立YUI的裝載機，試圖由默認加載。 然而，YUI和YUI庫成熟，這不會是必要的，在未來不再當默認生成數量增加。

 銳（{畫廊：畫廊2010.10.20-19-33'}）
 使用（畫廊“傳送帶”，“畫廊，旋轉木馬，ANIM”，“替代”功能（Y）{
   VAR傳送帶=新Y.Carousel（{boundingBox的：“＃容器”，
    contentBox：“＃容器> OL”}）;
   carousel.plug（Y.CarouselAnimPlugin，{動畫：{速度：0.7}）;
   carousel.render（）;
 }）; 

（順便說一下，如果你是全新的東西越來越感興趣，可以訪問YUI 3庫庫 github上或戈帕爾的叉子 ，他開發傳送帶。如果您發現了錯誤，我們總是很高興聽到這個消息。）

回到我們的例子... YUI將採取從這裡。 裝載機自動拉廊傳送帶和雅虎的內容交付網絡的依賴。 在那之後，傳送帶正在初始化並顯示出來。 然後，用戶可以單擊向左或向右的箭頭，左右滾動。 請原諒我在一個行帶來不必要的複雜性，但我無法抗拒。 我用Y.CarouselAnimPlugin順利地從一個網頁，而不是只顯示下一頁即刻讓我們傳送帶幻燈片。 隨時播放速度參數，如果你想。

正如你可以看到從上面的截圖中，傳送帶是建立和運行。 然而，CSS可能不適合，很好地把你的頁面的其餘部分。 這使我們下一節，我們將討論如何定制圖庫傳送帶。

自定義庫傳送帶

現在，您有您的傳送帶和運行，並確定為您的網站的使用情況，您希望希望它無縫集成。 如前所述，我們這樣做是為我們的體育搜索結果頁。 如果你想增加可見項的數目，例如三至四年，你可以這樣做，通過修改實例傳送帶行。

  VAR傳送帶=新Y.Carousel（{boundingBox的：“＃容器”，
  contentBox：“＃集裝箱OL”，numVisible：4}）; 

還不夠好？ 對，沒錯。 幸運的是，CSS允許我們添加我們自己的風格定義，甚至不接觸任何現有的CSS覆蓋最初的。 所以，你的第一步將是取下邊框，因為他們是相當突兀。 只需添加以下CSS到你的頁頭。

  。銳3，旋轉木馬{
  邊境：！都不重要;
 }
資產淨值的傳送帶。銳3 {
  背景：！都不重要;
 }
 。傳送帶OL李{
  邊境：！都不重要;
 } 

現在，看起來更好。 我也用負餘量，以減少我的傳送帶和標題之間的差距。 然而，我們仍然不完全。 我以為你也想用自己的自定義按鈕，它很好地融入您的頁面佈局。 在這個例子中，我們將使用雅虎的搜索結果頁上，也使用相同的按鍵。 這需要多一點，但仍然簡單，CSS。

 傳送帶的按鈕。銳3 {
  背景：URL（“sprite_button.png）不重複的滾動！0 0透明的重要;
  height: 20px !important; width: 28px !important;
 }
.YUI 3-carousel-nav-item {
  background: url("sprite_button.png") no-repeat scroll 0 0 transparent !important;
  background-position: -133px 0 !important;
 }
.YUI 3-carousel-first-button {
  background-position: -90px 0 !important;
  margin-right: 35px !important;
 }
.YUI 3-carousel-first-button-disabled {
  background-position: -60px 0 !important;
  margin-right: 35px !important;
 }
.YUI 3-carousel-next-button {
  background-position: -30px 0 !important;
 }
.YUI 3-carousel-button-disabled {
  background-position: 0 0 !important;
 }
.YUI 3-carousel-nav-item-selected {
  background-position: -121px 0 !important;
 } 

We will leave it to that for today and hope you feel ready to get started. At least that was all that we needed. However, depending on how big your site is and how interested you are in its performance, there are general thoughts about loading something from a third party content delivery network that also apply here. For example, Sidnei da Silva laid out some interesting thoughts in a blog post earlier this month. We would be happy to provide a How To that explains how a YUI widget and its dependencies can be moved to your own website, or even content delivery network, so you are able to keep the number of HTTP requests as low as possible. Let us know if you are interested, we are looking forward to your feedback!

More to Explore in the Gallery

The excellent team of Eduardo Lundgren and Nate Cavanaugh of Liferay have a Carousel component in the Gallery as well — certainly worth checking out if you're in the market for this kind of control.

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

銳劇院-瑞安樹叢：“引進YUI 3自動完成”（42分鐘）

In this talk from YUIConf 2010 , YUI 3 AutoComplete author Ryan Grove ( @yaypie ) takes you on a whirlwind tour of some of the many autocomplete patterns made possible by this component (which is coming in the soon-to-be-released YUI 3.3.0) and provides a deep dive into its powerful new YQL integration, filtering, and highlighting capabilities. ( Note : If you enjoy this talk, you might want to check out Ryan's other excellent talk from this year, “ Achieving Performance Zen with YUI 3 .”)

如果下面嵌入視頻不會出現在你的RSS讀者選擇正確，請務必通過點擊觀看視頻銳劇院的高分辨率版本 。

• Download HD video (480p ~297MB)
• 下載視頻（M4V）
• 下載幻燈片

Other Recent YUI Theater Videos:

• 保羅·唐納利和納格甚Susarla的 YQL的+銳大廈到高端應用 -發展中國家部件時，它不是如何使用YQL的數據，來了一個問題，而是如何訪問它。 在這YUIConf 2010年會議，YQL的工程師保羅·唐納利和納格甚Susarla的審查開始您的查詢在YQL的控制台，通過各種端點訪問YQL的數據，並通過YQL的各種認證層。
• Eric Ferraiuolo: TipTheWeb.org: Heavy Duty YUI 3 & YQL — In this session from YUIConf 2010, TipTheWeb cofounder and YUI contributor Eric Ferraiuolo discusses the creation of a project-scale codebase using YUI 3, YUI 3 Gallery, and YQL.
• Reid Burke: Yeti: YUI's Easy Testing Interface — Testing cross-browser web applications has been too difficult for too long: You're either manually reloading browsers or struggling with complicated automation software. In this session from YUIConf 2010, YUI engineer Reid Burke talks about how YUI's Yeti project helps to address these problems. Reid discusses when you should use automated testing for your frontend code, how Yeti works with YUI Test, how to setup cross-browser testing in minutes and how the YUI team uses Yeti to ship a better product.
• Douglas Crockford: Project Future — Yahoo! JavaScript architect Douglas Crockford reflects on the life of Walt Disney, who dreamed of creating a 'City of the Future' in Florida as part of the project that became Disney World. （這不是一個技術會議，而是關於一個大的夢想和生活的經驗教訓，我們可以從中。）
• Tom Hughes-Croucher: How to Stop Writing Spaghetti Code — In this session from YUIConf 2010, Yahoo! engineer Tom Hughes-Croucher explores different coding styles for event-driven, non-blocking server-side JavaScript and which styles are most successful.

的消委會內容/使用一種權限：

• http://www.flickr.com/photos/franksvalli/5166422476/
• http://www.flickr.com/photos/franksvalli/5165821437/

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！