1. 名詞解釋

DPI - dots per inch (每英寸點密度)
PPI - pixels per inch (每英寸像素密度)

簡單來說，DPI是邏輯解析度，PPI是實體解析度(各家手機的螢幕解析度)

以圖像顯示或字型來說：MAC螢幕預設常用DPI為72、windows系統則是96或120；印刷用的DPI常用為300


2. Device Pixel Ratio(裝置像素比)

以 iPhone 為例
http://www.paintcodeapp.com/news/iphone-6-screens-demystified

視網膜解析度與css背景圖
http://weedygarden.net/2010/10/retina-display-and-css-background-images/

字型光柵化
http://zh.wikipedia.org/wiki/%E5%AD%97%E4%BD%93%E5%85%89%E6%A0%85%E5%8C%96

以下網站可測試此螢幕的裝置像素比
http://www.devicepixelratio.com/


3. 利用css media query 針對不同像素比顯示不同的排版

測試該瀏覽器能使用media query的功能語法
http://cssmediaqueries.com/overview.html

1. 先登入 Skype 的網路版。

2. 找到帳戶設定，把 Microsoft 帳戶連結移除即可。

 
 

一般在製作手機版或是自適應性網站時會加一個meta tag: <meta name="viewport" content="width=device-width,initial-scale=1.0">
但是這樣在IOS系統時，字體的大小會隨著螢幕轉向(螢幕解析度改變)而變大或縮小



解決辦法： 在css的body中加入"-webkit-text-size-adjust:100%;"

自從網站上了 net4.0 之後，網站會有為數不少的 "潛在危險" 的 exception
大都來自不友善的攻擊，想要測試網站的漏洞
網站做這層防護是好事，只是這個東西太敏感了，連簡單的冒號 & 符號都會跳 exception
更慘的是 Google Analytics 會在一些 user cookies 寫入xml文字 ( __utmz=... )
導致正常的 User 都不能正常瀏覽我們網站

解法有兩種:
1. 直接在 web.config 直接設定 不檢查

<system.web>

    <httpRuntime requestValidationMode="2.0" />

    <pages validateRequest="false" />

</system.web>

2. 自訂 RequestValidate (4.0以上才可以用)
請參考此文章 http://msdn.microsoft.com/en-us/library/system.web.util.requestvalidator(v=vs.100).aspx

後者比較算是正解 基本上處理掉 <script 我想 XSS 就解決一大半
 

一般在崁入youtube影片時，影片的寬高是固定的

隨著螢幕大小自動調整寬高的方式：


CSS：
.video-container {
    position: relative;
    padding-bottom: 56.25%;
    overflow: hidden;
}
 
.video-container iframe,
.video-container object,
.video-container embed {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
}


HTML：
<div class="video-container">
    <iframe src="http://www.youtube.com/embed/dFVxGRekRSg" frameborder="0" width="560" height="315"></iframe>
</div>

calc()是CSS3的一個計算長度單位的新功能，能使用數學四則運算方式。

1. 使用“+”“-”“*”“/”四則運算；

2. 可以使用百分比、px、em、rem等單位；

3. 可以混合使用各種單位進行計算。

例：
.thing {
  width: 90%; /* fallback if needed */
  width: calc(100% - 10px);
  width: calc((100% - 12px) / 2);
  width: calc(100%/3 - 2*1em - 2*1px);
}

4. 使用時，"+" & "-" 兩邊需加空格(一定要加)， "*" & "/"兩邊是不用加空格(要加也是可以)

5. 瀏覽器的支援：IE9+ , Firefox4.0+ , Chrome , Safari , iOS Safari6.0+ , Android Browser 4.4+
   寫法： width: -moz-calc((100% - 12px) / 2);
              width: -webkit-calc((100% - 12px) / 2);
              width: calc((100% - 12px) / 2);
 

 .mobile-share_fb{ display:block; background:url("http://www.shopunt.com/css/mobile/images/mobile-s9398562778.png") no-repeat; background-position: 0 -1648px; height: 80px; width: 80px;} 

 .shrink-attr{ background-size: 152px 2104px; width: 40px; height: 40px; background-position: 0 -824px;} 

 .fb-test{ display:block; background:url("http://www.shopunt.com/images/logo_welcome.jpg") no-repeat; background-size:50% 50%; width: 105px; height: 105px;} 

 

http://graph.facebook.com/?id=http%3A%2F%2Fwww.shopunt.com%2FShowPicture.aspx%3FPic%3D20140610133552854

一開始我用的是先傳 : CONVERT(varchar(10), Create_Date, 111) 的結果到VB 
後還Bike 教我可在SQL就先轉成 "weekday" : Datepart(dw,Create_Date) 但是效率還是有點慢
後來發現加在一起可以變更快 : Datepart(dw,CONVERT(varchar(10), Create_Date, 111))
可能是因為先變成比較好判斷的長度  實驗幾次後真的會比較快一點 
varchar(10)  可以取到需要的位數就好 varchar(10)  似乎會比 varchar(100) 再快一點 雖然測試機差異不大

今天在觀察 Chrome 怎麼處理網頁中的 <script type="text/javascript" src="/scripts/unt.14.04.10.19.05.42.js"></script>  時，終於明白何時才會 200 (From Cache) (unt.14.04.10.19.05.42.js 是假的，實際會被重導到 scripts.aspx 來處理。)

1. 在網址列，同網址再按一下  Enter 載入時，Chrome 會對相同的網址再次送出 request。

2. 若是點選頁面中的連結或是在網址列輸入其它網址，才有可能看到 200 (From Cache)

在情況 1 時，若是有使用 Response.Cache.SetLastModified(Now) 則會看到 304 ，否則會把 Script 重新載入一次。

所以在 Server 最佳的(我覺得)寫法是:

Response.Cache.SetCacheability(HttpCacheability.Private)

Response.Cache.SetExpires(Now.AddYears(1))  '一年後才會到期，沒有這個就不會有 200 (From Cache)

Response.Cache.SetLastModified(Now)  '若是 Browser 送出了一個新的 Request, 有可能會回 304

不過有趣的是，在 scripts.aspx 收到帶有 ​If-Modified-Since 的 Request 時，是怎麼判斷要回應 304 的，我在 .vb 裡面沒有加上這個處理吔。