[試] 重新定義Foundation 5 framework的media query breakpoint

相比常見的Twitter Bootstrap,另一個比較不普及HTML framework──Foundation 5更較為適合作為手機應用 Mobile app 的UI介面,不論是用HTML+CSS+Javascript再用Phonegap之類製作的App、還是用UIwebView作UI的原生App。

不過,當Foundation 用在mobile 上製作responsive的app時,我對Foundation 5的breakpoint就不特別滿意,尤其是iPhone 6和6 plus出現後,當要處理iphone 6/6+ landscape和iPad portrait 的同時,那個不論不類的”medium”,也就是641 pixels 至 768 pixels的那個屏寬breakpoint就令我超不爽。

這是Foundation 5的預設breakpoints:

最小寬度 Min-width (em) 最大寬度 Max-width (em)
small 40
medium 40.063 64
large 64.063 90
xlarge 90.063 120
xxlarge 120.063

當然,這只是我的個人意見啦。

解決不爽的方法,是自行定義各mobile view的breakpoint。

首先,先要了解各iPhone的screen display pixels,我從Kyle J Larson的這篇blog文找到了下面的一幅參考圖:

iphone-6-screen-size

這是整理後各iPhone 屏寬和屏高的matrix:

Display pixels Resolution (portrait)
屏寬
screen width
屏高
screen height
寬度
width
高度
height
iPhone 4/4S 320 480 640 960
iPhone 5/5S/5C 320 568 640 1136
iPhone 6 375 667 750 1334
iPhone 6 plus 414 736 1080 1920

採用Retina display高解析度屏幕的iPad,display pixel是768 x 1024 (直)。

於是,我就把新的breakpoint range重新設定如下:

最小寬度
Min-width (px)
最大寬度
Max-width (px)
最小寬度
Min-width (em)
最大寬度
Max-width (em)
small 479 29.9375
medium 480 767 30 47.9375
large 768 1023 48 63.9375
xlarge 1024 1919 64 119.9375
xxlarge 1920 120 0

真的可行嘛?

不知道,我也只是在試,您看不到我在標題寫有「試」嘛麼?嘿嘿

防止iOS為input文字框中的英文首字母自動大寫

在iOS或其他手機上輸入email、用戶名的時候,OS會「親切」地為你輸入的西歐文字首字母自動大寫,也就是auto-capitalization。
於是email、用戶名就有可能怪怪的,在遇上區分大小寫 case sensitive的話,這個「親切」功能就變成麻煩。

在iOS裡的webkit加入了一個叫email的type用來區分電郵,當使用了 type=”email” 以後,該文字框的首字母自動大寫和自動拼字檢錯功能(auto-correct)就會失效:


<input type="email" />

上面的功能是在iOS 5以後才有。

如果您要的文字框不是email而是普通文字(如用戶名稱)的話,就用下面方法:


<input type="text" />

在遠古時代,也就是5以下版本的iOS,雖然也有 type=”email” 但卻不具體關上首字母自動大寫和自動拼字檢錯功能,所以還是要加上另外兩個attribute:


<input type="email" />

來自stackoverflow.com的參考連結
http://stackoverflow.com/questions/5171764/how-do-you-turn-off-auto-capitalisation-in-html-form-fields-in-ios

簡單快捷PHP單頁密碼

簡單快捷PHP單頁密碼

要簡單用密碼保護獨立頁面,不想用database、不用複雜的用戶管理?

從Stackoverflow找到了這個PHP方法–

  • 要保護的頁面叫”secure.html”
  • 負責保護、附密碼的叫”secure.php”

<?php
$user = $_POST['user'];
$pass = $_POST['pass'];
if($user == "admin"
&& $pass == "admin")
{
include("secure.html");
}
else
{
if(isset($_POST))
{?>
<form method="POST" action="secure.php">
User <input type="text" name="user"></input><br/>
Pass <input type="password" name="pass"></input><br/>
<input type="submit" name="submit" value="Go"></input>
</form>
<?}
}
?>

原文:

http://stackoverflow.com/questions/4115719/easy-way-to-password-protect-php-page

**由於是單純的文字密碼,加上另一個頁面就在伺服器的另一端,所以其實一點也不安全… 只是簡單的擋著陌生人亂來。

如何以HTML和CSS堆砌出 1, 1.1, 1.1.1 的多重清單格式

有想過,有天某個客戶要你把他們的那篇由律師精心打造的使用條款、法律聲明放到網站上面,然後列表數縮排的各項目(1)、子項目(1.2)、孫項目(1.2.3)的編號格式都要按本子列出來,弄出一個多層次清單(multiple level list)?然後才驚現,w3c標準的HTML原來沒有這樣的功能! multiple level list

你,不是世界唯一一個遇上這問題的人。 Continue reading “如何以HTML和CSS堆砌出 1, 1.1, 1.1.1 的多重清單格式”

泰文與UTF-8符號在Chrome上八字不合

Unicode的中文叫「萬國碼」,「理論上」,使用Unicode(UTF-8)的網頁可以在同一頁顯示不同語言,是一種很偉大的產品。

對,「理論」…除非,你要在Chrome上同時顯示泰文和UTF-8符號…

說到尾,Unicode還是極度依賴用戶端上的字款,要是字款沒有個別的字符,或者瀏覽器會察覺到某字符不存在時也不會去找其他字款,這你也沒辦法。

當然,沒辦法也得找辦法… 誰叫要靠這混飯吃……… Continue reading “泰文與UTF-8符號在Chrome上八字不合”

清滅IE 10文字連結神秘active底色

除前述的「input field內設神秘清除功能」外,IE 10同時會無故在文字連結 :active 時加上神秘的底色。我猜這是微軟為了「讓Windows 8 / IE 10能在平板電腦上操作時,能有更佳用戶體驗」的超前衛點子──設計思考:「在平板時用IE的話,手指點擊下去如果沒有 :active的話,那親愛的用戶就不知道他們『真是點擊了甚麼』啦」

真聰明,你老爸我最愛就是在公車地鐵茶餐廳內捧著23吋屏幕的「平板」用Windows和IE 10…

解決這些白痴的白痴點子:

a:active {
  background-color: transparent;
}

要是你要再定義某連結的底色,再用class去處理好了。

以CSS消滅IE 10的文字框的「消除」功能

微軟推出了IE 10一段時間,在試用過後,這個新的IE比先前的IE 9性能上更快,CSS3的對應也優於先前的版本,雖然我對強制在Windows 7的IE 10套用個人覺得全不討好的Windows 8 Metro UI風格一事上真的不敢恭維。

在Developer tool中IE 7 / 8 / 9 都用Metro UI,這算啥回事!

另外,IE 10「溫馨地」在input單行文字框加了一個無敵的功能──當文字框裡有文字兼onfocus時,會出現一個消除框中內容的小交叉。

看圖(喔!前面的那一個才是):
ie10-input-field-with-cross

這可不是一個普通的「X」,而是用Wingding 2字款顯示出來的一個不折不扣的「交叉」!

當然,世界不是只有IE,更不是只有IE 10… 不少網站早就用javascript在文字框加進了消除功能,結果…… 就是要找出個方法去消滅這個微軟IE團隊充滿愛心的雞肋交叉。於是IE 10又內建了有一個很有愛的vendor specific CSS,去供我們這些不懂愛的人去把這雞肋交叉解決掉:

input[type=text]::-ms-clear {
  display: none;
}