Skip to main content

4 posts tagged with "HTML"

View All Tags

· 2 min read

昨日、HTMLのことを考えていたら、大きな過ちを発見! HTML(構造) + CSS(修飾) + JavaScript(動作)ではなかった。 大きくはこの通りなんだけど、もうひとつの要素を忘れていたよ。 だから、コンテンツをパーツとして扱うことにしっくりこなかったわけだ。

今日も引き続きこんなことを考えていて、ちょっと考えがまとまりつつあったので、散歩してきた。 ふらふらしてたら谷中銀座というところにたどり着いた。 有名な場所らしい。

東京ではあまり入道雲を見た記憶はないんだけど、これは地域性のもの? 子供の頃はでーっかい入道雲をよく見たんだけどなぁ。

· 6 min read

今日は午前中に渋谷で仕事関係のお話。 その後、Sさんとランチ。 午後からはNさんに会ってきました。 その後、アロマのお店でホームページの話を少しして帰ってきた。

午前の話も、午後の話も、アロマのお店も全てホームページに関係する話題があった。いまさらだが、今後のCMSはどうなっていくのか不安。 以下、思いっきり個人的な意見なので、反論は多々あると思う。

世の中にCMSはいくつもあるが、どれも使い易さに欠ける。個人的にはよく出来てるなぁ〜って思うCMSもあるけど、これをホームページの運用者が使おうとすると、簡単ではない。 最近感じることはCMSがどうこうというよりは、ホームページの運営, デザイン, 管理, etc... の限界をCMSが最終型だと思ってない?ってこと。 CMSの話をしていてよく感じるのは、CMSが終着駅のようなイメージ。CMSで運用することばかりを考えていて、CMSに合わせている気がする。もちろん、使うにはCMSの癖をというのは把握して、それに合わせる必要もあるが、癖を利用しているというより、癖にうまく乗ることが目的になってる気がする。 CMSはレールであって、方向性も幅も、その上を走る列車も多種多様にあって、終着駅なんて見えるところにあったらまずいんじゃないの?

今後、コンテンツはHTMLだけでなくなっていくと思うのに、CMSに振り回されている気がする。iPhone, iPadアプリなんて独自規格なのに市場に広まっている。それどころか、ホームページもiPhoneに最適化もしている。もし、iPhone, iPad対応なんてことになってもCMSで管理していくの?だとしたら今のCMSだと何か違うくない?

HTMLに目が向きすぎていてはこの記事は理解してもらえないだろうな・・・と思う。ブラウザ上で動いてくれたら別にHTMLじゃなくてもいいと思ってる。そうは言っても、現実問題、HTMLが一番敷居が低く、最適なんじゃないかな?とも思ってる。そういう意味で、HTMLを使ってコンテンツを表現したり、伝えたりはしたいけど、HTMLしか見えてないわけでも、CMSで管理する都合上でもない。 実際、HTMLってよく出来ていると思っている部分がある。HTML(構造), CSS(修飾/design), JavaScript(動的/Action)の棲み分けはいいと思ってる。いいと思っているんだけど、サイトの作りがよくないとも思ってる。それぞれのサイトでは最適化してあって、3要素がうまく連携しているんだろうけど、サイトの範囲内だけ。これってもったいない。 それと、感覚的なことで、根拠は何もないのだが、HTMLとCSSの関係に関するバッドノウハウが出回っているような気がする。

いろんなコンテンツを配信していく上で最適な環境が欲しい。HTMLの配信にCMSが向いているのかもしれないが、HTMLはコンテンツのひとつでしかないということ。

こういうことを真剣に考えている方々と仕事をして行きたいが、思っているよりも少ないらしい。畑が違うとか、そんな理由で出会ってないだけかな? もう少し違う分野にも足を踏み込んでもいいのかもしれない。

· 5 min read

ここ数日、HTMLチックの構文解析のコードを書いてる。 やりたいことはHTMLの解析に絡むんだけど、テキストの置換をしたいだけ。 なので、HTMLの仕様に沿っているか?というと、それほど沿ってない。 タグで括られたテキストをいじりたいなぁ〜ってことに対応する程度。 今後も曖昧なHTMLをさらに曖昧に書く人たちはいるだろうという推測も兼ね、必要最低限な解析で幅広く対応。

scala.util.parsing.combinatorを利用しているので、構文解析自体、似非かも?

実装していて思ったのは、(わかっていたけど)曖昧性が強いなぁ〜ってこと。 XMLならもっと簡単なのに・・・ってのが多い。 例えば、こんな感じ。

  • 閉じタグの省略。
  • 属性を " " で括る必要が無い。
  • 属性名しか存在しない。
  • scriptタグ内に "<" が存在する。

閉じタグを省略した場合、ルールに則って推測するのだが、これ、省略〜。 閉じタグ省略時は子要素としては扱いません。 インライン要素の場合は子要素にするとか、その程度の判断くらいは可能だけど、今回は "マークアップされたテキストの解析" を目的としているため、タグの名前は持ってない。 そのため、どれがインライン要素か?って情報は持ってないし、持ちたくない。 これで困ることがあるとしたら、その要素が置換対象となっていた場合。 それも、きちんとタグを閉じればいいわけだし、これくらいの制約はいっか、と判断。

HTMLに限らずだと思うけど、構文解析する場合、解析した結果、何かをしたいはず。 となると、解析前の情報はいらないことが多々あって、ホワイトスペース(改行とか空白とか)の情報って人が見やすくするためだけにあったりするのだが、今回は解析前の状態に戻したかったりもする。 解析前の状態に戻すということはホワイトスペースも必要になるので、この情報もきっちり取得してます。

字句解析に正規表現を使ってるので、処理速度が遅かったら本格的に書きなおさなきゃならないんだけど、どうなることやら。 今のところ、解析結果を保持するつもりだけど、保持の方法はまだ考えてない。 安易なのは、まんまオブジェクト(笑)

悩んだことがひとつ。 改行を含む文字列をなんでも取得したかったんだけど "." では取れなかった。 DOT ALLオプションも見当たらないし・・・と思って見つけたのが "[sS]" という表記。 "スペースとスペースじゃないもの" って、全部ってことじゃん!ってことで、解決。 相反するものの和を取ったら全部です(笑)

· One min read

あるページをHTMLで表現したいとする。 この場合、まずは必要な情報を集め、分類し、それをタグで括ってみる。 例えば、divである程度の意味付けをし、属性(cssを考慮するとclass)を付与。

その後、CSSと画像を用意してもらってページを作る。 この時、基本的には構造を表すHTMLはいじらないことを前提とする。

こんな作り方をしてみたいが、これってデザイナにとってはデザインしづらいのだろうか?

あっ、これってデザイン出来ない人がデザインを付けて欲しいなぁ〜っていう大前提があるんだった(笑)