Webfontについてちょっと調べてみた

↓を読んで「ん?」って思ってブコメを読んでちょっと納得して少し知らべて思ったことのメモ

画像アイコンはもう古い!CSSでスタイル自由自在のアイコンWebフォント – W3Q

重いんじゃね?

ベクターファイルだから基本的には軽くなることが多いらしい。自分で作ったこと無いからわからないけど、ベクターファイルでできてるんであれば大きな画像になればなるほど軽くなると思う。ただし結局はフォントセットを丸々ダウンロードすることになるから1箇所だけWebfontを導入してIcon作ってみましたとかだと重くなると予想できる。やるなら画面で使っているiconをすべてwebfontに変更してその組み合わせだけのフォントセットとかを作ってやれば軽くなるんじゃないかと思う。そうすればCSS Spriteと同じような効果が発揮されるんじゃないかと想像。

色付けれないんじゃね?

fontだから色付けられないんじゃないかと調べてみたらやっぱりそうみたい。基本的に装飾はCSS3で装飾してtext-shadowつけたりcolorで色変えたりとかそこら辺で頑張るのが普通っぽい。iconとか簡単かつ単色で問題ない画像ならいいだろうけど複雑で単色ではないものを実現したいときはwebfontを使うのは無理。relativeとかで重ねればなんとかなるのかもしれないけどそこまでの労力を払うなら画像用意したほうがよっぽどいい。

SEO的にどうなの?

Webfontって本来は普通の文章を装飾するためにあるものだからSEO的には全然ダメだと思う。普通に文章書いてて特殊なフォントで記載したタイトルとかを出したいからしょうがなく画像を使ってますとかそういうサイトならSEO的にいいと思うけど、今回の使用方法を考えると全然ダメ。これなら画像にaltをきっちり書いたほうが機械も理解しやすいだろうからそっちのほうがいいんだろうと想像。

Fontファイルがダウンロードされなかったら終わりじゃね?

普通にブコメでも突っ込まれてたけどそうだよなーって思う。webfontって単なるフォントだからaっていう文字コードがきたら☆っていうものを表示してねっていうだけの技術なんでわけわからないものが見える可能性がある。だけどちょっと考えると、リストのiconを表示したいんだったら上から順番に1,2,3,4とかいう数字に表示したいものを割り当てればダウンロードされなかったとしても普通に見えるだろうし、twitterのマークをtに割り当てるとか文字と画像が何となく分かる組み合わせだったら問題ないのかも。

まとめ

つらつらと書いてみたけどWebfontは文字の装飾で使うべきで画像の代わりに使うものではないと思う。でもいっぱいアイコンを使わなければならないサイトとかならダウンロードされなかった場合に表示される文字と画像とがつながっているのであればお気軽に使えるCSS Spriteの代わりとして使うのもありなのかなーって思った。僕としてはSVGでブラウザに画像書かせようぜ!っていうほうがメリットが大きいんじゃないかなーって思う。

参考

http://design.kayac.com/topics/2012/02/webFontIcons.php

便利!Webフォントをアイコンとして使う方法 – NAVER まとめ


HybridAuth を触ってみた

FacebookでTwitterやFacebookへのログイン機能をこれ1個で実装できるPHPライブラリ「HybridAuth」:phpspot開発日誌っていう面白そうな記事が回ってきたから触ってみた。備忘録もかねてできたことを列挙してみる。

ダウンロード

以下のページのダウンロードって書いてるところからダウンロード

HybridAuth, Open Source Social Sign On PHP Library

ファイルの中身

簡略化して列挙すると以下。

├─examples
│  ├─facebook_integration
│  ├─hello_world
│  ├─signin_signup
│  ├─social_hub
│  └─widget_authentication
└─hybridauth
    └─Hybrid

中身を見ると多分こんなかんじと思われる。僕は簡単に認証出来るだけでよかったからhallo_wordしか触ってない。ほかはざっと読んだだけだから間違ってるかも

  • facebook_integrationがFacebookでやる場合の簡単な使い方
  • hallo_worldが一番簡単な使い方
  • single_signupがMVCで分けてかける簡単なアプリを作るための雛形っぽい。DBまである
  • social_hubがマルチコネクトの管理までやってくれそう。SNS的なやつを作る雛形っぽい
  • widget_authenticationがボタンが並んだ認証画面を作る奴っぽい
  • hybridautoが本体

config.phpを変更

config.phpで以下の部分を弄る必要がある

  • base_urlをhybridauthを配置したURLを記載。ファイルの中身の「hybridauth」フォルダのURLを書くことになる。
  • providersで使うやつをenabledをtrueにして必要なkeyを入力

動かしてみる

とりあえずtwitter認証をやってみたかったから自分のアプリケーションIDとかをconfig.phpに入力して、index.phpに書いてある相対パスとか変更してhollo_world/index.phpを動かしてみると案外あっさり認証が動いた。これは便利。

http://choilabo.com/temp/index.php

試したURL。しばらくしたら消すかもしれないけど、Twitterで認証走ってsatohu20xxAppTestのアプリ名で「HybridAuthの日本語テストですぞ!!!」ってつぶやかれる。Tokenとかとってないからお試しにどうぞ。

ポストのテスト

せっかく認証まで言ったのでついでにポストも動かしてみる。

<?php
        $twitter->setUserStatus( "hogehoge" ); 
?>

みたいに書くと↓のように出力される。日本語もバッチリ出力されるんだけど、文字コードがShiftJISになっていたせいでエラーが返答され続けてちょっと悩んだ。。。

佐藤 真一郎さんはTwitterを使っています: "HybridAuth Test!!!"

佐藤 真一郎さんはTwitterを使っています: "HybridAuthの日本語テストですぞ!!!"

他にもAPIはあるみたい。Token取る奴もあるみたいだからいざとなればTokenとっちゃって色々やれば別にAPIがなくても問題ない。

HybridAuth API

まとめ

Twitterしか試してないけどこれは便利。コードもわかりやすく書いてあるし、読みやすくてなにか起こった時でも自分で直せそう。これ使っていつかなんか作る。

PV至上主義っていい加減やめてほしくない?

あれって使ってる側としては何もいいことないよね。

確かにすごくわかりやすい評価だよね。目に見えて何回広告が表示されましたとか言いやすいし指標として分かりやすさは抜群。でもユーザが求めてるのって使いやすさとか表示速度の速さとかそっちじゃないですか。無料サービスとして使わせてもらってる立場で文句をいうのはなんだけど、このPV至上主義のせいでページを無駄に分割してるサイトが多すぎると思うんだよね。特にスマホ関連のサイトの無駄な分割っぷりったらありゃしない。画面が小さいってことと、回線が遅いってことを言い訳にしてるんだろうけど、たかだか文字を数百文字読み込んだところで1画像と転送量は変わらないんだからそんなねーだろってなる。

読み込み直したら新しい広告が出るから押し直すかもしれないじゃないとかそういう考え方もあるのかもしれないけどさ、次のページに行っても同じ広告とか出てる時があるわけでそれ全く意味が無いと思うんだよね。広告を出している側にしても見られもしないものに対してお金を払いたくないだろうし、ページを見に来ているユーザにとっても無駄な画面遷移が増えて読み込みの時間にいらいらするだけじゃない。まぁ、言ってもこっちはお金を払わずに見させてもらっている立場なんだから強く言えるわけないんだけど、最近は本当に無駄に記事を分割しているサイトが多すぎてめんどくさくなるんだよね。

もういっそのこと広告業者が同じIPから~秒以内にアクセスされた場合1PVとして数えます!みたいに宣言してくれれば無駄なページ遷移が減ると思うんだよなー。PV数は減るけどそのかわり1PVの重み付けは前よりも重くすれば別にWebページを作っている側も問題ないわけじゃない。どうせ入ってくるお金は一緒なんだったら使う人のことを考えて一回でもうちょっと文字を読み込んだほうがいいよなーって思ってくれるかもしれないわけじゃない。そうなってくれればもっと快適なネット環境になりそうだなというただの妄想。

僕がよく見るサイトとかが文字が多いサイトだから言えるだけのことで画像とか多いサイトだったら分割しないといけないんだろうし、広告出してる人も馬鹿じゃないから分割したほうがクリック率が上がるとかそういう統計的なものを調べてるんだろうけどね。ふと思ったから書いてみただけで特に落ちはない。

SASSを触ってみた

第16回 勉強会でのSASSがすごく便利そうだったので触ってみた。使い方の感想とメモ。

インストール

Macだったら以下のコマンド一発でOK。楽勝

sudo gem install sass

既存のCSSをSCSSファイルのコンバート

今までは生のCSSを記載していたから、どれだけの精度があるのか試しがてらCSSからSCSSへとコンバートしてみた。css2sassってコマンドがあるみたいだけど、お試しだから以下のウェブサービスで変換してみた。

css2sass | Convert CSS Snippets to Syntactically Awesome StyleSheets code

変換後のファイルと変換前のファイルを比べてみた感想としては、classとかidのネストを検出して変換しているように見える。僕としてはインデントとカッコの綴じ方とかが気に食わなかったけど、どういうふうに書けるのか?っていうのをCSSとSCSSとで比較できるという意味でかなり便利だと思う。

SASSファイルを監視して自動でCSSファイルに変換

これもコマンド一発。以下のコマンドで変換できる。

sudo sass input.scss:output.css

ディレクトリ指定とかコンパイルしたものを出力とか改行をちゃんと入れて出力とか色々オプションがあるらしい。詳しくは以下のURLの3を参考に。

web帳 | CSSライブラリ化? Sass(scss)のインストール方法 mac

mixinを書いてみる

mixin書くだけで十分捗ると言われていたので、mixiをとりあえず書いてみた。よくdivのbackgroundに画像を入れるたびに同じ事を書いていたのでまずはそこを変換してみた。

@mixin mixin-background-image($imageUrl:””, $size:contain) { background-image: url($imageUrl); background-position: center center; background-repeat: no-repeat; background-size: $size; }

使う場所には以下のように記載する。

@include mixin-background-image(“../img/arrow_sub.png”, contain); }

毎回書いている部分がちょっと減るからすっきりする。最初からSASSで記載していればもうちょっと共通的に使える部分をmixinで切り出すことで変更に強いCSSがかけるのかなぁという印象。ベンダープレフィックスをわざわざ書くのがめんどくさいのでそこら辺のmixinを書けばもっと楽になると思う。

まとめ

大体1時間ぐらいしか触ってないんだけど、SCSSで記載すればちょっと便利なCSSだと思って書くことができると思う。他にもいろいろ便利な機能はあるんだろうけど、とりあえずSASSとしてファイルを作ってみて同じ部分だけmixinで記載するってだけでも十分導入する価値はあると思う。今まで生のCSSを書いていた人は、今まで記載していたCSSの拡張子だけ変えてこれから先で弄る部分だけmixinで記載するって感じで使うのがいいのかなー。デザイナさんでもmixinしか使わないとかいうルールでやれば問題も発生しにくそう。ただ、watchでコマンド叩いてもらわないといけないってのがちょっときついかも。shell作るにしても「これ叩いて初めてくださいね。」みたいなルールが必要になるからちょっとだるい。