Official Google Data APIs Blog

Official Google Data APIs Blog
Bringing OpenID and OAuth Together
Official Google Data APIs Blog: Playing Around with Google AJAX and Data APIs
google code playground
OAuth Playground: Open-sourced

ECMAScript 5 Strict Mode, JSON, and More

ECMAScript 5 Strict Mode, JSON, and More

javascript lint

javascript lint
JSLint considered harmful? « Out of Hanwell

MooCanvas Moved and Updated

MooCanvas Moved and Updated
MooCanvas at Github

IE inherited margin bug: form elements and hasLayout

IE inherited margin bug: form elements and hasLayout

Can the padding/margin on radio buttons in IE6/IE7 be reduced to 0-1px? - Stack Overflow

Can the padding/margin on radio buttons in IE6/IE7 be reduced to 0-1px? - Stack Overflow

input.radio{margin-right:5px; 
height:14px;  /* for ie*/
width:14px; /*for ie*/
vertical-align:middle; /*for ff or will align to top*/
}

Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs

Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs
Definitive Guide to Taming the IE6 Beast

Fix relative positioning
Using position:relative in your designs is perhaps the easiest way to mess things up in IE6. Modern browsers display relatively positioned nested elements without issue, but IE6 frequently chokes up on even slightly complicated layouts. Fortunately, the solution is as easy as triggering hasLayout by adding zoom:1; to each relatively positioned element:

.selector {
  position: relative;
}
* html .selector {
  zoom: 1;
}

Note that you should not apply zoom:1; to any inline elements. Doing so will cause IE6 to treat them as block elements. Keep this in mind for the following solutions as well.

Fix negative margins
Negative margins are useful in a variety of scenarios, and most browsers handle them with no problem whatsoever. Unfortunately, IE6 doesn’t like negative margins unless you apply relative positioning to the target element:

.selector {
  margin: -1.5em;
}
* html .selector {
  position: relative;
  zoom: 1;
}

Note the addition of the zoom:1; declaration, which is required because of the relative positioning. Ain’t IE great?

Fix overflow problems
Fix overflow problems

Using the overflow in IE6 will sometimes lead to unexpected, unexplainable display issues. Fortunately, we can resolve many overflow-related display problems by triggering hasLayout via — yep, you guessed it — zoom:1;. Here is an example:

.selector {
  overflow: hidden
}
* html .selector {
  zoom: 1;
}

Another strange overflow-related issue is observed when font-style:italic; expands the width of its parent element. Thankfully, this nuance is easily resolved by applying the following CSS to the parent element:

* html .selector {
  overflow-x: hidden;
}

why encodeURIComponent() for data in body of POST XHR request? - JavaScript / Ajax / DHTML answers

application/x-www-form-urlencoded
This is the same format as a query string, but the string is passed in the request body rather than the URL.

multipart/form-data
This passes the raw, unescaped data in the the POST body by using a marker to define the data boundaries.

why encodeURIComponent() for data in body of POST XHR request? - JavaScript / Ajax / DHTML answers

Because POST uses the same characters to split ('&' and '=') by default. The method doesn't matter; the data is just offered in another part of the request.

GET looks like this (header):

GET /file.html?name=Bart&nr=4 HTTP/1.0

while default POST looks like this (body):

POST /file.html HTTP/1.0
Content-length: 15

name=Bart&nr=4

But the encoding of POST-ed data is only the default behaviour of the browser (which is done in Ajax "by hand" in such libraries).

<form method="post">

actually means:

<form method="post" enctype="application/x-www-form-urlencoded">

But it's possible to disable this URL-encoding for POST-ed data, mostly to transfer (binary) files to the gateway software. In the following example, you tell the form not to encode anything:

<form method="post" enctype="multipart/form-data">

This is the only case where 'é' will be passed as 'é'; under default GET/POST rules it will always be passed as '%E9'.

So as a general conclusion: Ajax libraries must invoke encodeURIComponent() when sending POST-requests in the "application/x-www-form-urlencoded" encoding type. They must always invoke encodeURIComponent() for GET. They must not invoke encodeURIComponent() in the POST "multipart/form-data" type.

Obviously, it also depends on how the gateway software is configured how to handle incoming data (this will be URL decoded by default).

URL-encoding is 'automatic' in browsers as long as you don't override this setting. POST or GET doesn't matter; browser will URL-encode all form values by default before sending them to server.

If you don't want this to happen, you should use

<form method="post" enctype="multipart/form-data">

to receive non-encoded data at server.

Steve Souders 的 Sprite Me,

http://www.stevesouders.com/blog/2009/09/14/spriteme/
Microsoft Doloto

HTTP Status Code

2xx Successful
3xx Redirection
4xx Client error
5xx Server error


0 Communication failure
200 OK
400 Bad request
403 Forbidden
404 Not found
408 Request timeout
410 Gone
500 Internal server error
502 Bad gateway
503 Service unavailable

Javascript Closures

Javascript Closures

某些 JPEG/JPG 圖檔在 IE 瀏覽器無法顯示解法 | Tsung's Blog

某些 JPEG/JPG 圖檔在 IE 瀏覽器無法顯示解法 | Tsung's Blog

之前遇到不少次廠商提供的圖片, 在 IE 就是無法顯示, 又不知道該怎麼跟廠商說問題在哪邊, 只能跟廠商說, 直接將圖拉進 IE, 會出現紅色大叉叉, 請自行修正... XD

感謝這篇 "有特定格式的 JPEG 圖檔無法在 IE 瀏覽器中顯示" 的說明.

依照這篇文章說明的, 原因是說, IE 只能讀取 RGB 模式的圖檔, 而於 IE 無法顯示的 JPG 圖檔, 應該是存成 CMYK 的模式.

解法, 利用 ImageMagick 的 mogify 轉換:

mogrify -colorspace RGB Your_CMYK_Image.jpg

display: inline-block

html>body .goog-inline-block { display: -moz-inline-box; display: inline-block; } 
.goog-inline-block { position: relative; display: inline-block; } 
* html .goog-inline-block { display: inline; } 
*:first-child+html .goog-inline-block { display: inline; }

TP非官方情報站»Blog Archive » ThinkPad X200s(CULV機種)簡測

TP非官方情報站»Blog Archive » ThinkPad X200s(CULV機種)簡測

Intel內部將CULV系列歸類在「Ultra-thin」這個產品區間，用來區隔採用Atom的Netbook及Montevina平台的傳統notebook。而CULV系列其實是由各種處理器所組合成的雜牌軍，依照效能高低可分為三級:

* Core 2 Duo(雙核心) SU9600(1.6GHz)/SU9400(1.4GHz)，3MB L2，TDP 10W
* Core 2 Solo(單核心) SU3500(1.4GHz)，3MB L2，TDP 5.5W
* Celeron 723(單核心/1.2GHz)，1MB L2，TDP 10W

以上都是45nm製程的Penryn核心，且FSB同為800MHz。所以CULV並不是「一顆」CPU的名稱，而是Intel為了主攻「Ultra-thin(超薄)」機種所推出的產品系列。

一、
參考其他網友的使用經驗，X200s（CULV723）如果搭配Vista使用，可能因為CPU時常滿載，一般使用的續航力約1-2小時，表現和X200差不多。

觀察ZDNET做的3810t評測，可發現CeleronULV723雖然性能和SU3500差不多，但耗電並不低，所以X200s(CULV723)的續航力表現才會和X200(C2D)如此相近。

換句話說，其實X200s(CULV723)是堪用、續航力不長、低價的機器，所以不太會影響到高價的X200s(C2D)，定位不同。

二、
另外，3810t用的6cell電池（56Wh），容量約為X200s(CULV723)系列4cell電池（28.8Wh）的兩倍。
但即使將3810t的電池使用時間折半，在該測試中的續航力表現，還是比X200s(CULV723)多出近50分鐘。
這可能意味著，
(1)13吋LED背光螢幕，比12吋CCFL背光螢幕耗電量更低
(2)SU3500遠比CeleronULV723省電

三、
不過考量SU3500的價格和CULV723相差約$100，以及X200s用LED背光+複合材質背蓋高昂的成本，這樣折衷的規格實屬合理。

其實小弟對Lenovo的反應這麼快，迅速推出X200s（CULV723），也相當欣賞。這款機型在價位和規格上的區隔也十分明確。

四、
但觀察可發現，其實對X200s(CULV723)這樣規格的產品，有需求的使用者，似乎在少數。相對之下，X200s(C2D)的使用者族群還可能更廣泛。
這是因為X200s(CULV723)規格低又不夠省電，還是此規格-價格區間的使用者不多，我就不清楚了。

五、
LED螢幕的低耗電似乎可有效延長續航力，期望X200在今年小改款時，提供有LED背光的機種，讓X200(C2D)的續航力進一步提高，以利和強調續航力的眾家CULV機種競爭。