[試] 重新定義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 屏寬和屏高的matrix: Display pixels Resolution (portrait)…

[Continue reading]

防止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

[Continue reading]

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

[Continue reading]

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

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

[Continue reading]

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

Unicode的中文叫「萬國碼」,「理論上」,使用Unicode(UTF-8)的網頁可以在同一頁顯示不同語言,是一種很偉大的產品。 對,「理論」…除非,你要在Chrome上同時顯示泰文和UTF-8符號… 說到尾,Unicode還是極度依賴用戶端上的字款,要是字款沒有個別的字符,或者瀏覽器會察覺到某字符不存在時也不會去找其他字款,這你也沒辦法。 當然,沒辦法也得找辦法… 誰叫要靠這混飯吃………

[Continue reading]

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

除前述的「input field內設神秘清除功能」外,IE 10同時會無故在文字連結 :active 時加上神秘的底色。我猜這是微軟為了「讓Windows 8 / IE 10能在平板電腦上操作時,能有更佳用戶體驗」的超前衛點子──設計思考:「在平板時用IE的話,手指點擊下去如果沒有 :active的話,那親愛的用戶就不知道他們『真是點擊了甚麼』啦」 真聰明,你老爸我最愛就是在公車地鐵茶餐廳內捧著23吋屏幕的「平板」用Windows和IE 10… 解決這些白痴的白痴點子: a:active { background-color: transparent; } 要是你要再定義某連結的底色,再用class去處理好了。

[Continue reading]

IE:Padding出沒注意!

其實我幾乎可以確定,微軟Internet Explorer的工程團隊都是從地獄來的撒旦使者,加入資訊科技界的唯一目的是就把災難帶給網站開發人員… 這次是IE的表單元件checkbox和radio。

[Continue reading]

以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時,會出現一個消除框中內容的小交叉。 看圖(喔!前面的那一個才是): 這可不是一個普通的「X」,而是用Wingding 2字款顯示出來的一個不折不扣的「交叉」! 當然,世界不是只有IE,更不是只有IE 10… 不少網站早就用javascript在文字框加進了消除功能,結果…… 就是要找出個方法去消滅這個微軟IE團隊充滿愛心的雞肋交叉。於是IE 10又內建了有一個很有愛的vendor specific CSS,去供我們這些不懂愛的人去把這雞肋交叉解決掉: input[type=text]::-ms-clear { display: none; }

[Continue reading]