ラベル 2. LOGREPO (構築編) の投稿を表示しています。 すべての投稿を表示
ラベル 2. LOGREPO (構築編) の投稿を表示しています。 すべての投稿を表示

2010-11-13

ソースコードの色付け - google-code-prettify を使う

古いブックマークを整理していて google-code-prettify を紹介するマイコミジャーナルの記事を見つけた(→「【ハウツー】ハイライトもGoogle流 - "google-code-prettify"でソースコードに色付けを」)。

ブログの記事に埋め込むコードの色付けをしたくて調べていたときに見つけたものだったのだろう。ブックマークしただけで放置して(忘れて)しまっていたのは、外部ファイル(JavaScript と CSS)を使うその仕組みが Blogger で使うには不向きだったから。

しかし今は、GAE を外部ファイルの置き場所として使う方法を知っている(→「外部ファイルの置き場所としての Google App Engine」)。さらに Blogger Glass は、まさにこういうモノを組み込むためにあると言って良い。Blogger Glass に組み込み、さらに Blogger のテンプレートにも組み込んでみた。Blogger のテンプレートではスタイルシートと同様 Style Repository に google-code-prettify を置いた。

使い方

マイコミジャーナルの記事にも簡単な使い方が書かれている。公式なドキュメントとしては README が用意されている。

一番単純な使い方。pre 要素のクラスとして prettyprint を指定する。

class ListViewHandler(webapp.RequestHandler):
    def __init__(self):
        self.app = info.App()
        self.view = info.ListView()

    def get(self):
        util.save_url(self.request, self.response)
        util.fill_app_attrs(self.app, self.request.uri)
        label = self.request.get("label", default_value=None)
        page = int(self.request.get("page", default_value="1"))
        if page > 0:
            self.fill_view_attrs(label, page)
            self.response.out.write(util.render_template(self.app, self.view))
        else:
            self.view = info.MetaInfoView()
            self.fill_metainfo(label)
            self.response.out.write(util.render_template(self.app, self.view))

主要な言語は自動的に認識してくれるが、クラスとして明示的に指定することもできる。クラス属性に prettyprint の後に lang-* という形式で追加する。「*」の部分の書き方は README の「How do I specify which language my code is in?」を参照のこと。Python なら py、Ruby なら rb、つまりはソースファイルの拡張子だと思って良いようだ。

class ListViewHandler(webapp.RequestHandler):
    def __init__(self):
        self.app = info.App()
        self.view = info.ListView()

    def get(self):
        util.save_url(self.request, self.response)
        util.fill_app_attrs(self.app, self.request.uri)
        label = self.request.get("label", default_value=None)
        page = int(self.request.get("page", default_value="1"))
        if page > 0:
            self.fill_view_attrs(label, page)
            self.response.out.write(util.render_template(self.app, self.view))
        else:
            self.view = info.MetaInfoView()
            self.fill_metainfo(label)
            self.response.out.write(util.render_template(self.app, self.view))

行番号を表示させることもできる(5行ごと)。これは linenums を追加する。行番号を 1 以外から開始させるには linenums:15 のように番号を指定すれば良い。

class ListViewHandler(webapp.RequestHandler):
    def __init__(self):
        self.app = info.App()
        self.view = info.ListView()

    def get(self):
        util.save_url(self.request, self.response)
        util.fill_app_attrs(self.app, self.request.uri)
        label = self.request.get("label", default_value=None)
        page = int(self.request.get("page", default_value="1"))
        if page > 0:
            self.fill_view_attrs(label, page)
            self.response.out.write(util.render_template(self.app, self.view))
        else:
            self.view = info.MetaInfoView()
            self.fill_metainfo(label)
            self.response.out.write(util.render_template(self.app, self.view))

既存のスタイルと組み合わせることも可能。以下の例は、このブログでこれまで使ってきた code クラスと prettyprint クラスを同時に指定したものだ。ちなみに、複数のクラスを適用する場合はクラス名を空白で区切って並べれば良い。↓の例では class="code prettyprint" と書いている。

class ListViewHandler(webapp.RequestHandler):
    def __init__(self):
        self.app = info.App()
        self.view = info.ListView()

    def get(self):
        util.save_url(self.request, self.response)
        util.fill_app_attrs(self.app, self.request.uri)
        label = self.request.get("label", default_value=None)
        page = int(self.request.get("page", default_value="1"))
        if page > 0:
            self.fill_view_attrs(label, page)
            self.response.out.write(util.render_template(self.app, self.view))
        else:
            self.view = info.MetaInfoView()
            self.fill_metainfo(label)
            self.response.out.write(util.render_template(self.app, self.view))

スタイルの調整

prettyprint クラスのスタイルは、配布パッケージにふくまれている prettyprint.css で定義されている。ただ、主にトークンの種類による色分けの定義のみで、フォントサイズやフォントの種類については定義されていない。つまり、ブログのスタイルを引き継ぐことになる。

prettyprint.css を組み込む位置に注意すれば、ブログの CSS 中で prettyprint クラスのスタイルを追加(あるいは上書き)することができる。

実際、上の例では以下のようなスタイルをブログ側のスタイルで定義している(Blogger Glass の場合)。

pre.prettyprint {
    margin: 0 2em;
    padding: 5px 1em 5px 1em;
    border: #cccccc 1px dotted; /* silver */
    font-size: 10pt;
    font-family: "Monaco", monospace;
    overflow: auto;
    background-color: #ffffff;
}

これは従来の pre.code のスタイル定義と背景色以外が同一のものだ。

関連リンク

関連記事

2010-09-21

Blogger で作ったブログを iOS デバイス対応にする

このブログを iOS デバイスに、とくに iPad に対応させようと試行錯誤を始めたのが 8 月の下旬。そろそろ一ヶ月になるが、ようやく iPad を中心に一群の iOS デバイスに対応させる作業が完了した。新しい iPod touch (→ 第4世代になるらしい)でも確認したから Retina ディスプレイを備えた世代のモノでも大丈夫だ。

デバイスを切り替える方法の調査から、スタイルシートを Blogger の外部に置く方法の調査やら考察に進み、Google App Engine (以下、GAE) を使う方法に気付く。さらには GAE アプリでスタイルシートを切り替える方法を採り、今に至っている。

細かなことになるが、Google Font API を試したことや、iPhone シミュレータを使って iOS デバイスでの見た目を確認することを思い付いたり、Redmine でプライベートな問題追跡を始めたのも、この作業の中でのこと。

ま、一番の苦労は、Blogger の(複雑な)テンプレートとの格闘だったけどな。ちなみに、そこでは Safari の「開発」メニューから起動できる「Web インスペクタ」が大活躍だった。これなくして、Blogger のテンプレートから生成される HTML の解析は困難だったろう。ましてやスタイルの定義は不可能だったに違いない。CSS によるスタイルの定義が、どう適用されているかの表示は、Blogger のスタイルを上書きするために、なくてはならないものだった。Safari、バンザイ ヽ(`д´)ノ。

もっとも、Firefox にしろ、Chrome にしろ、最近のブラウザでは似たような機能は利用できるみたいだけどね。

スタイル定義における基本方針

多少、ブレたりもしたが、最終的には以下の方針に落ち着いた。

  1. iOS デバイスに対応する
  2. iPad (横向き)を基本サイズにする
  3. iPad (縦向き) はサイドバーを表示しない
  4. iPhone は向きに関係なくサイドバーを表示しない
  5. Mac 以外のデバイスでは通信量を考慮に入れる

作業を始めた当初は、iPhone の横向き 480px を、iPad の縦向き時のメイン領域にして、サイドバーも表示させようと考えていた。しかし、これだと iPad の向きを変えたときに、一行に表示されている文字数が変化してしまい、見づらいことがわかった。これを避けるため、縦向き時と横向き時のメイン領域の横幅を同じにしたい。かといって、サイドバーがあまり細くなっては、これまた中身が見づらい。悩んだ末、縦向き時にはサイドバーの表示をあきらめた。結果として、サイドバーが見たければ向きを変えるというユーザ体験を導入したことになった。

デバイスの向きを変えるとメニューの類が表示されるというユーザ体験は、iPad 標準アプリの「メール」や「メモ」などのものに少し似ている。

メイン領域

iPad で縦向き時にはサイドバーを表示させないので、画面幅 768px はすべてメイン領域の表示に使う。そして、横幅 768px をこのブログでの基本幅とし、Mac 向けのスタイルでもそのまま適用する。

一方、iPhone に最適化する際は横向き 480px での表示を基本とし、縦向きでの見た目は最低限の調整に留めた。なので、iPhone でこのブログを見るときには、なるべく横向きにして見てほしい。

サイドバー

メイン領域が 768px だから、サイドバーは iPad の横向き時の幅からメイン領域を除いた部分に表示する。つまり、1024 - 768 = 256 で 256px になる。

メイン領域と同じく、サイドバーの幅 256px も Mac 向けスタイルにもそのまま適用する。

Mac 向けのレイアウト

iPad の横向き時と同じレイアウトになる。縮尺は正確ではないけれど、27 インチ iMac で表示させた場合、横幅 768px + 256px は、だいたい左図のようになる。

ちなみに、Mac 上の Safari で 1024px のウェブページを表示させるにはウィンドウのサイズを 1040px にすると良い(→ AppleScript を使って URL を Safari のタブで開く)。余分な 16px はスクロールバーの分だ。

通信量に対する考慮

大した量じゃないという気もするのだが、Google Font API を使うのは Mac のみとした。

そもそも、iPhone の場合で、common と iphone の 2つ CSS ファイルで約 18 KB ある。通信量のことを気にするなら、これ自体も十分ムダだよな。

まとめ

Retina ディスプレイ搭載の iPhone 4、iPod touch (4G) への対応に少し不満が残っているものの、ほぼ満足行くスタイルに仕上がった。iPad や Mac で見たときはもちろん、iPhone で見ても、コンテンツを見る分には十分だ。

サイドバーをふくめたナビゲーション全般で改良の余地はあるけれど、HTML と CSS でやれる範囲はここまでだろう。この先は、JavaScript の活躍する領域になる。ただ、Blogger のテンプレートとの格闘には良い加減疲れたので、これ以上手を加えることはないと思う。スタイルのバグ修正や、ちょっとした新スタイルの追加はするけれど。

むしろ、Blogger は記事の投稿だけに使って、記事を見るには別のアプリやウェブアプリを使う方が良いんじゃないか、と思い始めている。先のナビゲーションの改良なんかもやりやすい。特定のブログを表示するためだけの iPhone アプリがあっても良いじゃないか。ブログシステム全体を作るのは大変でも、見るだけに特化するなら HTML + CSS でやることの延長として考えられる。

関連リンク

関連記事

2010-09-19

Retina ディスプレイ搭載の iPod touch

発表されてすぐに発注したのが 9/2 の早朝、出荷は 2 〜 3 週先だと言われしょんぼり。待つこと 2 週間。出荷を知らせるメールが届いたのが 9/16。上海からやって来るとわかる。待つこと、さらに 3 日。ようやく、今日、新しい iPod touch をゲット。

まずは、写真をいくつか載せておく。

iPod touch、到着
薄い! (; ゜Д゜)
背面は iPod 伝統の鏡面仕上げ
電源、オン!
アクティベーション完了

ファーストインプレッション

やはり一番のオドロキは、その薄さだ。iPhone 3GS と並べて見ても一目瞭然。こんなに薄くて大丈夫なのか、と心配してしまうほど。初代の iPod のことを思い出すと嘘のような薄さだ。

最近は、iPhone しか使っていないし、その前でもすでにウチの iPod の主力は nano に移っていた。だから久しぶりに鏡面仕上げの背面を見て、これが iPod だよな、と思い出した。指紋がベタベタつくし、ケースに入れずに使うと傷だらけになったりするけど、それも iPod らしさってもんだ。

まだ、アプリを同期させていないので、ebook を表示させたときの Retina ディスプレイの見え方なんかは試していないけど、それはおいおい。

ウェブページを Retina ディスプレイ搭載機器対応にする

デバイスの検出

すでに、このブログは iPhone (3G/3GS) 対応になっている(iPad 対応はそれなり)。その仕掛けの主要部分が GAE アプリによるスタイルシートの切り替えだ。その肝になっているのが、リクエスト機器が送ってくるユーザエージェント文字列によるデバイスの検出だ。こう書くと大袈裟だが、やっていることはユーザエージェント文字列の中から "iPhone" や "iPad" といった文字列を探しているだけだ。

iPod touch 対応にするため、まずは上述の仕掛けの中で iPod touch を検出する。そのためには iPod touch が送るユーザエージェントの文字列を知らなければならない。調べれば(ググれば)わかるだろうが、ここは実機で確かめることにした。そのためのテストプログラムがこれ。

(useragent.cgi)
 1: #! /opt/local/bin/ruby1.9 -w
 2: # -*- coding: utf-8 -*-
 3: 
 4: # useragent.cgi: check the user-agent string sent by client devices.
 5: # Last modified: 2010-09-19
 6: 
 7: require 'cgi'
 8: 
 9: cgi = CGI.new
10: 
11: puts "Content-type: text/plain"
12: puts
13: 
14: print cgi.user_agent
15: STDERR.puts cgi.user_agent

CGI を実行できるフォルダ(Snow Leoaprd の Apache なら標準で /Library/WebServer/CGI-Executables)に置いてブラウザからアクセスすれば良い。iPhone や iPod のようなデバイスだと、ブラウザの画面から Mac にコピペできないので、標準エラー出力にもユーザエージェント文字列を書き込んでいる。こうすると Apache のエラーログ(Snow Leopard の標準設定なら /var/log/apache2/error_log)に書き出される。

ついでなので、iPod touch 以外のデバイスでもユーザエージェントを調べてみた。

各種デバイスのユーザエージェント文字列
DeviceOSUser-Agent
Mac Snow Leopard 10.6.4 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; ja-jp) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5
iPhone 3GS iOS 4.1 (8B117) Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; ja-jp) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7
iPad iOS 3.2.2 (7B500) Mozilla/5.0 (iPad; U; CPU OS 3_2_2 like Mac OS X; ja-jp) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B500 Safari/531.21.10
iPod touch
(Retina Display)
iOS 4.1 (8B117) Mozilla/5.0 (iPod; U; CPU iPhone OS 4_1 like Mac OS X; ja-jp) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7

iPhone と iPad を "iPhone"、"iPad" で検出したように、iPod touch も "iPod" で検出すれば良いことがわかる。

Retina ディスプレイの検出

iPhone にも 3G/3GS と 4 があるように、iPod touch にも Retina ディスプレイを搭載している新モデルと旧モデルがある。これら新旧のモデルの区別には、今のところ CSS のメディアクエリーを使うしかないようだ。

iPhone 4 の CSS を切り替える方法」にあるように -webkit-device-pixel-ratio: n で新旧モデルを切り替える。n = 1 なら旧モデル、n = 2 なら Retina ディスプレイ搭載のモデル、となる。

あれ、どちらも 320 * 480 なんだけど……

実際にスタイルを定義し始めるまでは、上述のようにして Retina ディスプレイ搭載モデルを検出すれば、640 * 960 の画素数の画面として扱えると思っていた。しかし、新モデルも、Safari から見ると、デバイスの画素数はやはり 320 * 480 なのだ。1/2 ピクセル単位で指定できるのでない限り(できる? できないよね?)、スタイルを定義する観点から言えば、新旧モデルに差はないということだ。

iPhone 4 の CSS を切り替える方法」の最後に少し書かれているように、JavaScript を使って、viewport を書き換えるという方法もある。ただし、このページに載っているコードそのままだと、iPod の向きを変えたときに width が変わらない。もう少し、工夫が必要らしい。

小さい文字がくっきり見える

CSS の定義上は変わらないと言っても、実際に見比べれば Retina の解像度には目を見張るものがある。はっきり言って全然別ものだ。わかりやすい例を挙げると、Retina ではより小さなポイント数の文字がはっきりと読める。iPhone 3GS では 10 pt より小さいと見えにくくなるが、Retina の iPod touch なら 9pt でも余裕で読める。

この違いならスタイルに反映させることができる。つまり、Retina モデルでは少し小さい文字を表示に使うというものだ。実際の表示を写真で示す。以下の写真を iPhone/iPod touch 等で見るときは、本体を横向きにしてほしい(サムネイルを 400px にしてあるので)

文字表示の比較
iPhone 3GS { font-size: 11pt; }
iPod touch (Retina) { font-size: 10pt; }
iPhone 3GS { font-size: 11pt; }
iPod touch (Retina) { font-size: 10pt; }

iPod touch のフォントを 9pt にしていないのは、さすがに目が疲れそうだから。くっきりと読めるということと、楽に読めるということは別物だからね。

関連リンク

関連記事

2010-09-09

iPhone シミュレータをウェブページの作成に活用する

おそらく、iPhone や iPad 向けのウェブページを作っている人はみんなとっくに気付いていて、当たり前のように実践しているに違いない。最近になるまで気付かなかったわたしが間抜けなのだ。それは、ウェブページの見た目(やウェブアプリの動作)の確認に iPhone シミュレータを使うという方法だ。

もちろん、実機で確認する方が確実だし、最終的には必須でもある。しかし、ページを作っている最中にちょっと確認するのであれば、シミュレータを使うのもありだろう。何より、Mac の中で完結できるから、手軽さで実機を使うことに優る。また、Mac の Safari でユーザエージェントを切り替えたり、ウィンドウサイズを iPhone や iPad に合わせるよりも簡単だ。

起動、そしてデバイスの切り替え

まずはシミュレータのありか。

/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications

このシミュレータは iOS SDK にふくまれているものなので、iOS SDK をインストールしていない Mac ではどんなに探しても見つからない。ちなみに、iOS SDK のダウンロードだけなら無料でできる(開発者としての登録は必要)。

通常、iPhone シミュレータは Xcode の中から起動するから、単独のアプリだとは気付きにくいけれど、上記の場所に iPhone Simulator.app として存在している。Finder からダブルクリックすれば、通常のアプリと同様に起動する。

iPhone シミュレータという名前だが、iPad シミュレータにもなる。それには、メニューから「ハードウェア」>「デバイス」で目的のデバイスに切り替える。バージョン 4.1 では iPad、iPhone、そして iPhone 4 の 3 つから選べる。また、シミュレートする iOS のバージョンも別途選べるようになっている。ただし、デバイス専用のバージョンを選ぶとデバイスも同時に切り替わる(例: 3.2 は iPad 専用)。

ちょっとおもしろいのは、iPhone 4 を選んだときだ。iPhoen 4 の画素数そのままに巨大なウィンドウが表れる。iPhone のときの 4 倍(タテ、ヨコ、それぞれ 2 倍)だ。まあ、これでは Retina ディスプレイのシミュレートとしては不足だけどね。肝心の解像度(326ppi)を再現できていないのだから。

使い方は iPhone (や iPad) と同様。ただし、タッチスクリーンではないから、タップはクリック、スワイプはドラッグになる。また、マウス単独では不可能なマルチタッチのピンチオープン、クローズには Option キーを併用したドラッグとなる。Magic TrackPad の場合はそのままのジェスチャになればウレシイんだが、残念だけどそうはなっていない。

シミュレータの Safari でページを見る

シミュレータと実機の比較
シミュレータ
(iPhone)
実機 (3GS)

これは、実際にシミュレータと実機でこのブログを開いたときのスクショだ。それぞれを見ればわかるが、見た目の差はないと言って良い。フォントの種類もサイズも同一。行の高さも、折り返す位置も同じ。

ウェブアプリとなると実行速度や搭載メモリの差、さらには特性の差(センサー類は使えない)が差異として表れるかもしれないが、ウェブページの見え方を検証するのであれば、シミュレータも十分に役立つ。

関連リンク

関連記事

2010-09-05

GAE アプリによるスタイルシートの切り替え

簡単そうだと思ったのでやってみた。実際、簡単だった。要した時間のほとんどは Python の文法を調べることだった。

今回の切り分けでは、以下のようにリクエスト URL に応じて共通スタイルと機器用スタイルに分け、さらに機器用スタイルではユーザエージェントを使って実際の機器に合わせたスタイルに切り替えている。

リクエスト URL返されるデータを収めたファイル
http://stylerepo.../logrepo/common logrepo_common.css
http://stylerepo.../logrepo/device ユーザエージェントに応じて logrepo_ipad.csslogrepo_imac.css に切り替える

つまり、以下のように 2 つのリンクを書くだけでデバイスに応じたスタイルに切り替えられるわけだ。

(スタイルへのリンク方法)
<link type='text/css' rel='stylesheet' href='http://stylerepo.../logrepo/common' />
<link type='text/css' rel='stylesheet' href='http://stylerepo.../logrepo/device' />

切り替えの仕組み

今回の変更で、stylerepo の構成は以下のようになっている。

(stylerepo アプリ構成の一部)
/stylerepo/
    +-- app.yaml
    +-- index.yaml
    +-- logrepo/
    |   +-- __init__.py
    |   +-- base.py
    |   +-- common_handler.py
    |   +-- default_handler.py
    |   +-- device_handler.py
    |   +-- logrepo_common.css
    |   +-- logrepo_ipad.css
    |   +-- logrepo_iphone.css
    |   +-- logrepo_mac.css
    +-- main.py
    +-- stylesheets
        +-- mac.css

前回の状態から logrepo ディレクトリが増えた。また、app.yaml にも手が入っている。

app.yaml

共通スタイルと機器用スタイルの切り替えはリクエストする URL を替えることで行う。この仕組みは GAE に用意されていて、設定を app.yaml に記述すれば良い。

app.yaml では、リクエストの URL パターンごとに処理を行うハンドラを記述する。この URL パターンの記述には正規表現が使えるためコンパクトかつ高機能な記述が行える。たとえば、以下のような記述。

(app.yaml より)
- url: /logrepo/(common|device)
  script: logrepo/\1_handler.py

この指定は リクエスト URL が /logrepo/common または /logrepo/device で終わっていた場合に、続くハンドラに処理させることを意味する。ここで commondevice の選択は正規表現になっていて、実際のリクエストにふくまれている文字列(commondevice) がスクリプト名の指定中では \1 として参照されている。すなわち、/logrepo/common でアクセスされたときには logrepo/common_hander.pyに、/logrepo/device としてアクセスされたときには logrepo/device_handler.py に、それぞれ処理が任せられる。

2010-09-02

CSS スタイル定義の優先順位

Blogger のスタイルを変えたい

ここしばらく続けて、CSS のことを調べたり考えたり試したりしているのは、このブログのスタイルを変えたいから。Blogger でこれをやるには、ブログごとに XML で提供されているテンプレートを変更すれば良い。ただ、これが結構面倒なのだ。

なぜ、面倒なのか。まずはテンプレートになっている HTML/XML の構造が複雑なことがある。1 つのテンプレートで表紙から個別ページ、ラベルによる検索結果のページに対応することに加えて、ウェブ上でページ要素(サイドバーなどのコンテンツ)を追加できる等の機能にも対応している。さらに最新版ではテンプレートデザイナーと呼ばれるテンプレートの編集機能にまで対応した作りになっているためだ。

レイアウトを構成する要素のネストは深いく、一番シンプルなテンプレートでさえ、ブログコンテンツの p 要素と body 要素の間に 10 以上の(主に div 要素による)ネストができる。まあ、これは高機能化が複雑さを増すことの良い例ともいえる。

加えて、ユーザが手を出せないスタイルがリンクされることもある。XML のテンプレートを見ているだけではわからないが、実際のブログの HTML ソースを見ると Blogger が提供する CSS ファイルがリンクされていることがわかる。

もちろん、テンプレートにスタイルを記述すれば HTML に直接埋め込まれることになるため、Blogger 提供の外部 CSS の定義を上書きすることは可能だ。実際、これまでそうしてきたし、今回もそのつもりだった。だが、ときどき、この上書きが期待どおりに効果を表さないことがある。これはなぜなのか?

Safari の設定で「メニューバーに"開発"メニューを表示」を有効にしてやると、「Web インスペクタ」が使えるようになる(メニューから「開発」>「Web インスペクタを表示」を選ぶ)。この機能ではページの要素のネストの様子や、各要素に付けられたスタイルの一覧、さらにはスタイルの上書きされている様子も見ることができる。

この機能を使って、期待どおりに効果が表れないスタイルを調べていくうち、ただ単純に後に書かれているから優先になる、というわけではないことがわかってきた。

CSS における優先順位

(「World Wide Web Guide: 段階化の順序」より)
Cascading Style Sheets の Cascade とは順序立てられたリストのスタイルシートという意味から名付けられたもので、スタイルシートが段階的に継承していく働きを表しています。そして、順序立てられたリストの中で記述されている位置やセレクタの違いにより、段階化の順序(スタイル情報が反映される優先順位)は異なってきます。

ブラウザが仕様をどこまで厳密に実装しているかにもよるのだけど、CSS のスタイル定義ではセレクタの書き方によって優先順位が変わる。CSS では基本的に、後の定義が前の定義を上書きする。しかし、優先順位によっては後の定義よりも前のものの方が効果を表すこともある。たとえば、以下の記述の場合、header クラスの div にある h1 に対しては、後ろにある赤色の指定は前の灰色の指定を上書きできない。

(CSS スタイル定義サンプル)
 1: .header h1 { color: gray; }
 2: h1 { color: red }

2010-09-01

外部ファイルの置き場所としての Google App Engine

さて、前回(→ 外部ファイルの置き場所を求めて……)の記事では、外部 CSS ファイルの置き場所として Google App Engine (以下、GAE) にたどりつくまでを書いた。

GAE でやってみることにしたのは「静的なコンテンツを動的に生成しても良いじゃないか」と思いついたためだ。「なんとゼイタクな」とか「ムダなことを」なんていう声が頭の中を駆け巡りもしたが、現在のコンピュータ(とインターネット)にまつわる技術は、ある意味、計算と通信の資源を湯水のごとく使うことで発展してきたようなものだ。安価で(無料あるいはそれに近い価格で)提供される資源は、どんどん使うことが正義なのだ。ムーアの法則が成立する状況が続く限り「豊穣の時代」が続くのだ。いいじゃん、これぐらい。

「静的なコンテンツを動的に…」に思い至ったのは、コンテンツを要求する側(ブラウザ)にとっては HTTP の向こう側で何が起こっていても関係ないんだ、と気付いたから。ま、当たり前のことなんだけどね。

GAE アプリの作り方

GAE に登録

まずは、アカウントの登録。アカウント自体は Google アカウントだが、App Engine を使い始めるには携帯電話を使った認証が必要になる。具体的には、登録の際にロケーションと携帯電話のキャリアを選び、その SMS あるいは携帯電話用のメールアドレスを指定する。すると、携帯電話に認証コードがメールで送られてくる。そこに書かれたコードを登録画面で入力する、というものだ。

わたしの場合、iPhone のメールアドレス(i.softban.jp)を指定した。すぐに「Google App Engine Code」というタイトルのメールが送られてきた。中にあった 7 桁の番号を登録画面に入力して登録完了。

アプリケーション ID の登録

アカウント登録が完了したら、先にアプリケーション ID を登録してしまう方が良い。この ID を SDK でアプリケーション名として使うことになるからだ。また、この ID はそのままアプリの URL にもなる(独自ドメインを使う場合は別)。具体的には、helloworld という ID なら http://helloworld.appspot.com/ でこのアプリを開くことになる。

ID の登録は GAE の The Administration Console から行う。

アプリケーション ID は先着順。凡人がパッと思い付く程度の名前はもう大抵取られているよ。GAE を使う上で、ここが一番の難関かもよ(´・ω・`)。

SDK をインストール

アプリの開発をするには SDK が必要で、Mac 版も用意されいる。ダウンロードした SDK のパッケージを開くと GoogleAppEngineLaucher.app がぽつんと入っている。これを /Applications にコピーすれば OK。

初回の起動時に、何やらコマンドラインのツールのシンボリックリンクを /usr/local/bin に作っても良いか、と確認してくる。OK を押せば確かに /usr/local/bin シンボリックリンクができている。おそらく、これは、ユーザが Terminal 上からも GAE Launcher の機能を使えるようにするための作業だろう。

初回起動時に現れる確認ダイアログ
シンボリックリンク張っても良い? ここに張ったよ!

2010-08-31

外部ファイルの置き場所を求めて…

CSS によるスタイル定義を外部ファイルにしたい

Blogger には画像とブログ自体のテキスト以外のデータを置く場所がない。Google の提供する他のサービスにも汎用のデータファイルをウェブからアクセス可能な形で保持してくれるものはない。そう思ってきた。だから、このブログのスタイルを変えるときにもブログのテンプレート自体に埋め込むしかない、と。

外部 CSS ファイルを使いたい理由

もし、CSS によるスタイル定義を外部ファイルにしてどこかに置けるなら、iPad (や iPhone) 対応もブラウザのユーザエージェントで切り分ける方法を取れる。メディアクエリーを使い CSS の中で対応するよりも、(デバイスの特性値の組み合わせではなく)デバイス自体を判別するという点でスマートだ。また、デバイスごとのスタイル定義をすべて読み込む必要もなくなり、ロードするサイズも減る。iPhone に iPad 用や Mac 用のスタイルを読ませることもなくなるわけだ。

けど、Blogger には、そして Google にも、外部 CSS ファイルを置く場所はない。

Google 以外のサービスはどう?

もちろん、レンタルサーバを借りるという方法がある。月額がワンコインで足りるものもある。CSS ファイルを置く程度のことならそれで十分だ。ま、そこまでするなら Blogger にこだわる必要もなくなる。レンタルサーバ上で WordPress なんかに乗り換えれば、こんなことや(スタイルを変更するために) Blogger のテンプレートの構造で悩むこともなくなる。けど、やはりネットの向こう側のことでは Google にこだわりたいんだよね。

Amazon が提供するウェブサービスに S3 というサービスがある。正式名称を Amazon Simple Storage Service と言い、そのものずばりの「インターネット用のストレージサービス」だ。「インターネット上の」ではなく「インターネット用の」になっていることに注目。つまり、インターネット上で稼動するウェブサービスから使われることを前提としたストーレジなのだ。

ここに外部 CSS を置くことはできるだろうか? もう少し正確に言うと、S3 に入れたデータは HTTP 経由で公開アクセス可能なのだろうか?

(S3 公式サイト; Amazon S3 Functionarity より抜粋)
Authentication mechanisms are provided to ensure that data is kept secure from unauthorized access. Objects can be made private or public, and rights can be granted to specific users.

オブジェクト(ユーザが S3 に収めたデータをこう呼ぶようだ)は private にも、public にもできると書いてある。

(同上)
Built to be flexible so that protocol or functional layers can easily be added. The default download protocol is HTTP. A BitTorrentTM protocol interface is provided to lower costs for high-scale distribution.

デフォルトのダウンロードプロトコルが HTTP だと書いてある。

ということで、(試していないから確実ではないが) HTTP でパブリックアクセスできるようだ。有料だけど、データのサイズと転送量が少量だから、びっくりする額になることはないだろう。レンタルサーバを借りるよりも(今まで経験したことがないから)おもしろそうだ。

とまあ、こんな流れで昨日まではすっかり、S3 を試すゾ、という気になっていた。今日、Google のあるサービスのことを思い出すまでは。

静的ファイルがダメなら、動的に作ってしまえば良い

何も CSS がファイルでなければならない理由はない。「ファイル」と呼んでいるものの、ブラウザにとって必要なのは HTTP リクエストに対して text/css で返されるデータストリームだ。サーバの HDD にファイルとして存在していようが、サーバ上のプログラムが生成したデータだろうが、ブラウザは気にしない。

静的な CSS ファイルを動的に生成してやれば良い。つまり、極端な例なら CSS のデータを文字列としてプログラムに埋め込んで、それを出力させれば良い、ってことだ。

これなら、Google のあのサービスが(きっと)使える。

2010-08-26

twitter より (2010-08-25)

Powered by twtr2src.

2010-08-25

ウェブページのスタイルを iPad に最適化する方法

増えたデバイス

かつては、Mac (や PC) だけがウェブブラウザだった。今では iPhone に加えて、iPad が「普段使いのブラウザ」として加わった。Mac 向けに作ったページをそのまま開くこともできるけど、やはりデバイスに最適化されたデザインのページは見やすい。このブログも iPhone や iPad ですっきりと表示させたい。多少の手間はかかるけど、やるだけの価値はある。

iPad はウェブブラウザのリファレンスプラットフォームだ

以前にも、このブログを iPhone 対応させたことがあった(テンプレートを変えたために今ではその効果は失われている)。あのときは、単にサイドバーを非表示にしただけだった。今回は、レイアウト全体を見直してみよう。

iPad で見ることを前提に、幅を 768 ピクセル、および 1024 ピクセルで、レイアウト(メインとサブの 2 列構成)をデザインする。1024px仕様を手直しすることで、Mac 用のデザインを仕上げる。iPhone 用のものは、768px仕様からサイドバーを非表示にすることで作る。こうすることで、iPhone、iPad、そして Mac の 3 つのデバイスで、ほぼ同じ見た目にすることができる。

ともあれ、3 種類のデバイスに対応するのだから、デバイスごとにスタイルを指定しなければならない。まずはその方法を(前の iPhone 対応のときより少し詳しく)調べてみた。

デバイスごとにスタイルを指定する

CSS2 には、画面や印刷といった「表示の媒体」(メディア)に合わせてスタイルを指定する機能がある。 CSS3 では、これが拡張され、媒体(メディア)ごとの特性(幅、高さなど)に応じてスタイルを指定できるようになっている。 これがメディアクエリーと呼ばれる機能だ。 Mac 用の Safari はもちろん、iPhone/iPad 用のものもメディアクエリーをサポートしている。 このため、CSS スタイルを適切に記述してやれば、ひとつのウェブページを、開くデバイスに合わせて見た目が切り替わるようにすることができる。

デバイスを識別する

メディアクエリーを使いスタイルを切り替える場合、識別の鍵になるのは画面の幅だ。iPhone なら画面の最大幅が 480 ピクセル(横向きにしたとき)、iPad なら 1024 ピクセル(同じく横向き)になる。

通常、画面幅を鍵にして 2 つのデバイスごとにスタイルを指定する場合、以下のようになる。

(画面幅で切り替え; 2 デバイス)
@media only screen and (max-device-width: 480px) { ... }
@media only screen and (min-device-width: 481px) { ... }

前が画面幅が小さいデバイス(例: iPhone)向けのスタイル、後がそれ以外のデバイス向けになる。

デバイスが 3 つならどうなるか?

(画面幅で切り替え; 3 デバイス)
@media only screen and (max-device-width: 480px) { ... }
@media only screen and (min-device-width: 481px) and (max-device-width: 1024px) { ... }
@media only screen and (min-device-width: 1025px) { ... }

only というキーワードは、(メディアクエリーを知らない)古いブラウザに、この記述全体を無視させるための仕掛け。メディアクエリーをサポートしているブラウザは単に only を無視するので付けたところで影響はないが、(古いブラウザを使う人がまだいるかもしれないので)付けておく方が安全だ。

参考までに、iPhone 3G/3GS、iPad の画面幅についてまとめておく。

機種
iPhone 3G/3GS 320 480
iPad 768 1024
iPhone 4 640 960

iPhone 4 のピクセル数は 3G/3GS の 4 倍(縦横が2倍)だが、(iPhone 4 の Safari は)画面幅のメディアクエリーに関して旧機種と同様に振る舞うらしい。このため、iPhone 4 を 3G/3GS と区別するためには、画面幅ではなく -webkit-device-pixel-ratio という特性を使うようだ(→ 詳細は「iPhone 4 の CSS を切り替える方法」を参照)。いかんせん、iPhone 4 をまだ手に入れていないから試しようがない。

2010-08-24

Google Font API を使ったフォントの表示

(Google Font API - Google Code より)
The Google Font Directory provides high-quality web fonts that you can include in your pages using the Google Font API.

しばらく前になるが、Google がフォントの提供を始めた(今のところ、まだ beta 扱い)。フォントファイルを提供するだけではなく、ウェブページからリンクするサービスを用意することで、ページの表示時にブラウザがフォントを動的にダウンロードできるようにしたのだ。

使い方

ウェブページ用に使う方法

公式ドキュメント( "Getting Started - Google Font API" ) に書かれている方法は、HTML 中の LINK 要素を使い、Google Font API の URL に対してフォント名を指定するというものだ。以下の記述を HTML の HEAD 要素の中に記述する。

<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Tangerine">

スタイルの定義では、他のフォントと同じように扱うことができる。

font-family: "Neuton", Verdana, "HiraMaruProN-W4", serif;

このように指定すれば、英数字の部分については、Google Font API の Neuton または (Google Font API が使えないなどの場合は) Verdana が使われ、日本語部分に対しては「ヒラギノ丸ゴ ProN」が使われる。もし、3 つとも使えないなら、デフォルトの serif フォント(ひげつき) が使われる。

Mac 上の Safari で試すと、こんな風になる。英字部分には Tangerine、日本語部分には「ヒラギノ丸ゴ ProN」が使われていることがわかるだろう。「Making ...」の部分には影がかかっているけど、これは CSS の text-shadow で付けたのであって、Google Font API とは関係ない。

では、外部 CSS を使っている場合はどうすれば良いのか? その場合は、@import で Google Font API の URL を(フォント名とともに)指定すれば良い。具体的には、CSS ファイルの先頭に以下のように記述する。

(外部 CSS の場合の記述例)
 1: /* Google Font API ( http://code.google.com/apis/webfonts/ ) */
 2: @import url('http://fonts.googleapis.com/css?family=Lobster');
 3: @import url('http://fonts.googleapis.com/css?family=Neuton');
 4: @import url('http://fonts.googleapis.com/css?family=Droid+Sans+Mono:regular');

この例では Lobster、Neuton、および Droid Sans Mono の 3 つのフォントが利用可能になる。

iPhone で表示させたサンプル

Google Font API の 公式FAQ には iPhone、iPad、iPod、それに Android はサポートしていない、と明記されている。しかし、今回試してみた限りでは問題なく表示できた。試したのは iPhone 3GS (iOS 4.0.2) と iPad (iPhone OS 3.2.2) だ。

これ(→)は、iPhone で iMac の Apache 経由でページを開いた状態でスクショにしたものだ。

ブログタイトルの部分が Lobster フォント、記事のタイトル(「iPhone 対応」の iPhone という文字)が Neuton フォントによる表示になっている。

2010-08-16

Gist を使って記事にコードを埋め込む (続き)

今日気付いたことだが、前回書いた Gist を利用する方法には少し問題があった。

この方法ではコードを表示するために script 要素を使う。以下のようなタグとして記事の HTML 中に埋まることになる。

(Gist を使ったコードの埋め込み用 script タグ)
<script src="http://gist.github.com/524290.js?file=embed_code.rb"></script>

Safari などのブラウザで見る限り、これで問題はないが、RSS リーダーでは問題になる。実際、Google Reader で前回の記事を見ていて、Gist からの埋め込みコードが表示されないことに気付いたのだ。Safari で RSS フィードを表示させた場合や JavaScript を無効にした状態も同様。試してはいないが、JavaScript をサポートしないブラウザも同じはず。

外部サービスを利用する以上、そして JavaScript を使う以上、これは避けられない問題だ。便利さを求めると、何かを犠牲にしなければならない。

とはいえ、何も表示されないのはイヤな感じなので、せめて Gist の該当コードのページへのリンクを noscript を使って表示させてみることを考えた。試してみたところ、Google Reader では noscript 部分が表示された。iPhone アプリの「MobileRSS Free」でも OK。Safari で JavaScript を無効にした場合も noscript 部分の内容が表示される。ただし、Safari に RSS フィードを表示させた場合はダメだった。noscript が無視される。RSS リーダーによっては noscript を無視するものもあるってことだ。

以下が noscript を付けたサンプル。JavaScript が有効なブラウザなら Gist からのコードの表示が、無効あるいはサポートなしのブラウザなら Gist のページへのリンクが見えるはず。

具体的には、以下のように記述してある。

(Gist を使ったコードの埋め込み用 script タグ、noscript 付き)
<script src="http://gist.github.com/524290.js?file=embed_code.rb"></script>
<noscript><div>→ <a href="http://gist.github.com/524290">embed_code.rb</a></div></noscript>

noscript 部分を手で書くことになり少し手間が増えるが、それでもコードそのものを整形して埋め込むよりは簡単だ。

関連リンク

関連記事

2010-08-15

Gist を使って記事にコードを埋め込む

前回、コードをブログに載せる際、Github のようなリポジトリに登録してしまうのが手っ取り早いんだろう、と書いた。けど、ちょっと大袈裟な感じがする、とも。ググってみたところ、ちょうどぴったりのサービスを見つけた。Github が提供する Gist だ。

試しに、前回の記事に載せたコードを登録してみた。それを Gist 経由で貼り付けると、こうなる(↓)。

行番号が付かないのがちょっと残念だが、名前の通ったプログラミング言語なら文法に合わせた色付けもしてくれる。コード自体(「view raw」リンク)を取ることもできるから、ブラウザからコピーしてフィルタにかける手間もいらない。

サービスの利用に必要なのは Github へのユーザ登録。他は何も必要ない。

Gist の使い方はとても簡単。Gist のページを開いたら(→)、テキストエリアにコードをペーストし、ファイル名を入力(「name this file...」)、言語を選択したら、右下の「Create Public Gist」ボタンを押す。

登録が完了したら個別のページが開くので、コードリストの右上にある「embed」というリンクをクリックする。HTML に埋め込むための script 要素が表示されるので、コピーしてブログの記事にペーストする。

外部スクリプトだから、表示する時に一瞬引っかかるけれど、そこはしかたがない。見た目(フォントとか)をこちらで制御できないのが気になるところか。

今どきは、探せば大抵のことには、サービスが見つかるもんだね。

関連リンク

関連記事

2010-08-14

記事に埋め込むためにコードの断片を整形する

このブログの記事でコードを載せるときに使っている Ruby のプログラムだ。

整形すると言っても、実際にやっているのは HTML 系のエンティティのエスケープと行番号を振るだけ。長い行を折り畳むとか、インデントを調整するなどのような高級なことはしない。

(embed_code.rb)
 1: #!/opt/local/bin/ruby1.9 -w
 2: # coding: utf-8
 3: 
 4: require 'cgi'
 5: 
 6: source = ARGV.shift
 7: exit if ! source
 8: 
 9: def header(name)
10:   h = '<pre class="code"><code>' + "(#{File.basename(name)})"
11:   puts h
12: end
13: 
14: def footer
15:   puts '</code></pre>'
16: end
17: 
18: def scale(n)
19:   Math::log10(n).floor + 1
20: end
21: 
22: count = 1
23: lines = IO.readlines(source)
24: format = "%#{scale(lines.length)}d"
25: 
26: header(source)
27: lines.each do |code|
28:   code = CGI::escapeHTML(code.chomp)
29:   numbering = format % count
30:   STDOUT.puts "#{numbering}: #{code}"
31:   count += 1
32: end
33: footer

18 〜 20 行の scale は整数の桁数を求めるもの。行番号の出力のフォーマットに使っている。1 行目で ruby1.9 を指定しているけれど、1.8 系でも問題なく動く。整形するコードに日本語が混じっていると(コメントや文字列リテラルとして)、おかしなことになるかも。

ついでに、embed_code.rb で処理したテキストを元のコードに戻すプログラムが以下になる。ただし、embed_code.rb 出力そのものではなく、それを(HTML に組み込み)ブラウザで表示させた上でコピーしたテキストを入力にする。

以下のコード中にも、コメントとして入力サンプルを挙げてあるが、基本的には以下のフォーマットとなる。

  • 先頭行は括弧で挟まれたファイル名
  • コード本体には行番号が振られている。
  • 行番号の書式は、0個以上の空白と数字の列、その直後に「:」と空白が 1 つ。
  • それ以外の行は無視して良い。
(extract_code.rb)
 1: #!/opt/local/bin/ruby1.9 -w
 2: # coding: utf-8
 3: 
 4: # ---- input sample ----
 5: # (print_numrefs.rb)
 6: #  1: #!/opt/local/bin/ruby1.9 -w
 7: #  2: # coding: utf-8
 8: #  3: 
 9: #  4: def convert(ref)
10: #  5:   num = ref[2...-1].to_i  # Numerical reference must be "&#12345;"
11: #  6:   fs = "%c".encode("UTF-8")
12: #  7:   fs % num
13: #  8: end
14: #  9: 
15: # 10: STDIN.each do |numref|
16: # 11:   STDOUT.puts "#{numref.chomp} -> #{convert(numref)}"
17: # 12: end
18: # ----
19: 
20: outfile = nil
21: 
22: STDIN.each do |line|
23:   case line
24:   when /^\((.+)\)/              # file name
25:     outfile = File.open(Regexp.last_match[1], "w")
26:   when /^[ ]*[0-9]+:[ ](.*)/    # code body
27:     outfile.puts Regexp.last_match[1]
28:   else
29:     # nothing to do
30:   end
31: end
32: 
33: outfile.close

HTML から直接取り出すことも考えたが、ブラウザからコピーして……が実際の使い方だろうと判断した。取り出す方を自分で使うときは、以前、記事に埋めたコードが必要なのに元のファイルが見つからないときだ。なら、ユースケースは「ブラウザからコピー」になる。

github のようなリポジトリに登録してしまうのが手っ取り早いんだろうな。ちょっと大袈裟な感じがするけど。

関連リンク

2010-05-19

twitter より (2010-05-18)

  • 07:43  [MM読了]銃・病原菌・鉄 (1) 上 —1万3000年にわたる人類史の謎 http://bit.ly/dsK0Zg ★★★☆☆
  • 08:24  近頃、twitter しか使わなくなっているので、twitter のつぶやきをまとめてブログに投稿してくれるサービスを使ってみることにする。 → http://twtr2src.ogaoga.org/
  • 08:25  ブログは Blogger を使っているので、設定なんかはここを参照した。 → http://www.kuribo.info/2009/08/twitter-twtr2src.html
  • 08:29  本来なら、「つぶやく」→「ちゃんと読めるようにまとめる」→「ブログに投稿」ってやるべきなんだよな。でも、いったん twitter に吐き出しちゃうと、そこで満足してしまう。
  • 08:30  今更なんだけど、twitter を使っていると、ブログの更新インターフェースって、結構メンドウなんだと気付く。メールから投稿っていう手もあるけど、それこそ twitter と変わらんし。
  • 08:37  ふむ。興味深いハックなんだけど、こういうのってデバイス側(のソフトのつくりこみ)で解決すべき問題じゃない(・ω・)? → http://www.ideaxidea.com/archives/2010/05/a_regist.html
  • 08:45  アドレス悵を開いたとき、どのページのどこにカーソルが当たっているべきか、っていう問題。あとは、アドレス悵のエントリから発信に至るまでの操作の問題。デバイス(ソフト)の反応速度とキー入力を取得するタイミングなんかも関係してくるかね。
  • 08:47  発信は課金に直結するから、メーカーは真剣に取り組むと思うんだけどね。解決は困難だってことか。
Powered by twtr2src.

2009-11-21

frickr から画像を貼ると・・・

Picasa ではなくて、flickr を使うとどうなるか。
こうなる。どっちが良いかね (・ω・)?

img の alt は空で貼り込まれるようだ。ここに画像のタイトルなんかを流し込んでもらいたいんだけど。

関連記事

2009-11-20

iPhone 対応してみる

今日はスタイルをいじる日。引用のためのスタイルだとか、ブログタイトルの下にあるナビゲーションメニューを整えたりだとか。勢い余って、iPhone で見たときにそれっぽく見えるようにしてみた。まずは、これが始めの第一歩。

デバイスごとに見かけを変えるしかけ

iPhone 対応にするには、大きく 2 つの作業が必要になる。 ひとつは、iPhone 特有の Viewport を適切に設定することだ。これには JavaScript でユーザエージェントを判定した後、iPhone (あるいは iPod touch) の場合は meta 要素を使って viewport を設定する。 もうひとつは、iPhone とその他(Mac や PC、等)でスタイルを切り替えられるようにすること。これには、メディアクエリーという CSS 3 の機能を使う。

Viewport の設定

(「iPhoneサイト制作ハンドブック」p.95)
Mobile Safari には、一般的な PC の Web ブラウザのような、サイズを変えらえるウィンドウがありません。Mobile Safari でコンテンツを配置するのに使われるのは、仮想的な表示領域である「Viewport」です。

Mobile Safari の表示と Viewport の関係は、スクリーンの背後にある Viewport の "風景" を、スクリーンのサイズに切り抜かれた "窓" を通して見ているようなイメージです。この "窓" のサイズは変えられませんが、Viewport の "風景" は、大きくなったり小さくなったり、拡大率が変わったりします。

iPhone の Safari で一般の(ie iPhone 対応になっていない)ページを開くと、ダブルクリックやピンチ操作で表示部分を拡大したり、縮小したりできる。あれはこの Viewport が変わっているのだ。コンテンツのレイアウトを iPhone 用に定義するのであれば、Viewport の拡大や縮小は不要。よって、今回、やるべきことは Viewport をサイズ、倍率ともに固定してしまうことだ。

属性設定値
widthdevice-width
user-scalableno
initial-scale1
maximum-scale1

他のデバイスでは意味のない定義だから、iPhone かどうかの判別をした上で meta 要素を挿入する (あっても邪魔にはならないと思うけどね)。これはは以下の JavaScript コードで行う。長い行は "\" で折り返してある。

(iPhone 判定)
 1: var is_iphone = navigator.userAgent.indexOf("iPhone", 0);
 2: var is_ipod = navigator.userAgent.indexOf("iPod", 0);
 3: if ((is_iphone & is_ipod) > -1) {
 4:  document.write('<meta name="viewport" \
                     content="width=device-width, \
                     user-scalable=no, initial-scale=1, \
                     maximum-scale=1" />');
}

これを script タグで囲って、テンプレートの head 要素内に置く。title 要素の前とか、すぐ後ろとか、その辺り。

引用文のためのスタイルを定義

引用文(blockquote 要素)を目立たせようと、スタイルを定義した。こんな風(↓)になる。

SICP:
Program must be written for people to read, only incidentally for machine to execute.

色は、Mail.app の「メモ」で使われている色(「#FEF8BC」)。 ノートのような罫線はぐぐって見つけたここからパクり(→ mugu - memo - CSSでノート風罫線)。画像はサイズを変更した上で使用させてもらっている。
作者に感謝。

2009-11-11

テンプレートを確認するためのサンプル

これは H4

この記事は、テンプレートで設定したスタイル等の見栄えを確認するためのサンプル集。ここは通常の段落(ただの p)。

  • これはリスト
  • MacBook (Early 2008)
  • Mac mini Server (Late 2009)
  1. これは番号つきリスト
  2. Snow Leopard 10.6
  3. Snow Leopard 10.6.1
  4. Snow Leopard 10.6.2
これは H5

↓はターミナルの出力を表示するスタイル。class つきの pre

[foo:~/] bar% git
usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
           [-p|--paginate|--no-pager]
           [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
           [--help] COMMAND [ARGS]

今度はソースコードを表示するためのスタイル。class つきの pre に code が入ったもの。

# This is a very long long long long long long long long long long long long line.
# This is a very long long long long long long long long long long long long long long long long line.
# This is a very very very very very very very very very very long long long long long long long long long long long long line.

次は本やウェブページからの引用に使う。blockquote

SICP
Program must be written for people to read, only incidentally for machine to execute.

そして dl

Macintosh
Apple 社が製造、販売しているパーソナルコンピュータ。
単価数量価格
1,0001010,000
10,0001001,000,000
合計-1,010,000

2009-11-05

ひとまず完成

最初の段階でやりたかったことはほぼできた。いつまでも外見ばかりをいじっていても仕方がない。ひとまず、ここで完成とする。残っている項目は、またしばらくしてから挑戦しよう。

あと残っているのは・・・

  • テンプレートをカスタマイズ (日めくりみたいな日付表示にしたい; そのための素材)
  • iPhone での表示に対応する (CSS を追加だけで良いのか?)

簡単にここまでの経過を書いておく。ベースとするテンプレートを探すのはあきらめた。B:Templatesには確認しきれないほどの量があるが、なかなか思うとおりのものは見つからない。それならいっそ自分で作ろうという気になった。実際には、Blogger の標準テンプレートに手を入れて、今のものが出来上がった。変更したのは、(a) カラムを 3 つにした; (b) 色をあちこち変えた(オレンジっぽく); (c) エントリ部分の行間を大きくした; (d) ヘッダの直下にメニューとなるリンクを置いた。そのぐらい。

カラムを 3 つにする方法については、そのうち書こう。