Help us understand the problem. What is going on with this article?

HTMLコーディングテクニックの栄枯盛衰・輪廻転生10選

More than 1 year has passed since last update.

ファーストサーバ Web担の一人、1000oldです。

Web担といっても私の場合は一般的なイメージとは程遠く、コーディングに始まり、マニュアルや『常時SSL Lab.』の執筆、WordPressテーマ制作、サーバーのお守りなど、要は何でも屋さんです。

この何でも屋状態の仕事の中でQiitaを参照することは何回もありましたが、今回、Advent Calendar に乗っかって初めて投稿してみます。

制作者・コーダーの観点から…

Advent Calendar は、私以外ほとんどの方が開発者・技術者なので、難しい話題はそちらにお任せするとして、私はHTMLのコーダーの観点から書いてみようかと思います。

大学の頃の実習で初めてHTMLに触れてから20年近く、最初の会社で技術者として挫折、何でも屋Web担に転身してもう15年以上。

その間には、当時は画期的!と思ったものでも、時代の趨勢により今では鬼籍に入った、また入りかけのテクニックがたくさんあります。

そのテクニックを振り返りつつ、輪廻転生した代替技術/機能を紹介してみようかと思います。

1. レイアウトといえばtableコーディングだった。

Webサイトのデザインが上がってきたら、ページ全体を構成するtableの中に、ヘッダー用などの各要素のtableをそれぞれ入れて、この2つのセルは結合して…と設計していました。
本来floatでやるべきこともほぼtableで。

セルの結合が思ったようにならず、設計からやり直したことも。

そしていざコーディングすると、tableタグは必ずtr、tdなどの開始/終了タグがセットなので、幾重にもネストされたHTMLのソースコードは、それはそれはメンテナンス性の悪いものでした。

divタグのネストも複雑になりがちですが、tableタグのネストに比べたら全然見やすいと個人的に思います。

現在ではtableは本来の用途に使いなさい、という流れになりましたが、2000年台の中盤までは大手のWebサイトでも使われていた手法です。

そういえば、HTMLメールなどでは未だに現役ですね。

img01.png

:angel: 輪廻転生の結果

各要素をdivタグで囲んでレイアウトするのが基本。
配置はCSSのfloatやdisplayで。
文書構造を考えるなら、HTML5で追加されたsectionやnav、article、asideを使うことも。

また、Bootstrapなどのフレームワークのレイアウトグリッドを使うと簡単ですね。

2. ヘッダーやメニューはframeで別々に作っていた。

tableコーディングとともに、2000年台の中盤までは一般的だった手法。

メニューやヘッダーは固定にして、メインカラムだけ切り替えたいはずが、targetの指定を間違えて全部切り替わってイラッ!としたり。

検索結果で出てきたページがメインカラムだけで、どうやったらトップページに行けるの?とか、よくある話でした。

SEO的に良くないとして、フレームコーディングは積極的に避けられるべき技術になってしまいましたね。

img02.png

:angel: 輪廻転生の結果

CSSのブロック要素 &『overflow:scroll;』、場合によってはiframeタグを使うことも。

3. 文字やセルの色付けのためのHTMLタグ/プロパティがあった。

HTMLを手作業でコーディングしていた頃は、CSSなんか知らん!な時代で、装飾要素をHTMLタグ内に書くのは普通にやっていました。

文字色を変えるなら『<font color="#ff0000">』とか、tableの背景色を『<table bgcolor="#ffffff">』とか、HTMLタグに色を書くなんてのは普通に使っていました。
配置には<td align="center" valign="middle"> とか。

でもこれ、類似箇所を一度に変えたい、ってなると泣かされたことも数知れず。

現在ならHTMLメール以外でインラインに装飾要素を書いてたら、何やってんねんって怒られますし、HTML5ではfontタグなどは廃止されましたね。

:angel: 輪廻転生の結果

すべてCSSでカタが付きますね。

  • color
  • background
  • border
  • text-decoration などなど

4. 賑やかしにmarqueeやblinkを使っていた。

字を横にスライドさせて表示するmarqueeタグや、文字を点滅させるblinkタグ。

GIFアニメーションと合わせて、なんか動いている感を出すには最適、に思われましたが、IEの独自仕様という落とし穴が。
HTMLが文書構造を定義するもの、という観点からすると、これらのタグの異端児扱いは至極まっとうなことなんだけど。

でも青二才でWindowsでしか作業していなかった当時の私は、IE以外の他のブラウザ、何やってんねん!って思った記憶が。
HTML5やCSS3の登場以降、IEのア◯ー!誰やIEなんか作ったん!って叫びたくなることが多いですが、当時は逆だったんです。
少なくとも私の周りでは。

:angel: 輪廻転生の結果

CSS3のtransitionでlinerとかdurationとか組み合わせて再現はできるけど。
今やってたらやっぱりちょっと恥ずかしい??

5. 隙間の調整に画像を使っていた。

幅、高さが各1pxの透過GIF画像を「spacer.gif」とかで作り、必要な箇所にimgタグでつっこんでいました。

widthやheightは必要に応じて変えて、多いときは1ページに10個以上使ったり。
間違えて画像を消して、ページのいたるところに「×」が表示されて恥ずかしい思いをしたことも。

ただ、これもHTMLの本来の定義からすると無駄なタグなわけで。

img03.png

:angel: 輪廻転生の結果

CSSでmarginやpaddingを細かく調整すれば済む話なんですよね。
今考えたらなんでみんな画像に固執してたんだろう…

6. 動きをつけるならFlashだった。

これ、どんな人でも最初に見たときはすごい!と思ったはず。

15年ほど前によく聴いてたアーティストの公式サイトがFlashとかでガチガチに作られてて、結構かっこよかったので、どんなふうにしたらこんなの作れるんだろう、と勉強しました。

ActionScriptが難しくて、なかなか難儀しましたが。

でも脆弱性が多く、挙句スティーブ・ジョブズにケチョンケチョンに言われたのが運の尽き。
Adobeもサポート終了を宣言してしまいましたね。

他のものはともかく、Flashに関しては何らかの形で残っても良い技術だと個人的に思います。

:angel: 輪廻転生の結果

HTML5のvideoタグやcanvasタグ、audioタグなどの組み合わせになりますが、ちょっとやりたいことと違うんですよね…

7. トップページのロード時にMIDIで音楽を流していた。

法人のWebサイトはそんなに需要ないかもしれませんが、個人のWebサイトでは一時期流行し、MIDIの素材屋さんも数多く存在しました。

私も十数年前に学校関係のWebサイト制作をした際、校歌を流したいという要望で対応したのが最初で最後でした。

もともと大学時代にシンセサイザーで遊んでいたので、MIDI音源作るのはお手の物。
オルゴールの音で校歌を作って流してみると、サイトがショボくてもそこそこ立派な感じに錯覚するという。

embedタグを使うのが一般的でしたが、IEの独自仕様のbgsoundタグなんてのもありましたね。

:angel: 輪廻転生の結果

HTML5のaudioタグで、十分事足りますけど、今やるとそもそも音鳴らす必要ある?ってツッコまれますよね。多分。

8. ガラケー用のページを作っていた。

初めてHTMLタグを手打ちして作ったサイトと大して変わらないレベルのものを、まさか仕事で作るようになるとは…と愕然とした記憶があります。

そんな単純なページでも、docomo、au、Softbank(Vodafone、Yahoo!ケータイ含む)など、キャリアによる仕様の違いを理解するのに難儀。auの「HDML」なんて独自仕様があったのも思い出しました。

とにかく軽く。画像のフォーマットもキャリアによっては限定されてたりして、きれいなJPEG画像を泣きながらGIFに変換するとか、いろいろありました。

個人的には、UserAgentで振り分けるってことを、PC用のブラウザではなく最初にガラケーで覚えたのが印象深いです。

あと、数字ボタンを押してリンクを選択させるにはこのタグ、みたいな、利用者の動きに合わせた記述とか配置とか、ある意味UI的な要素の勉強にもなりましたね。

:angel: 輪廻転生の結果

スマートフォンやタブレットなどが全盛のいま、ガラケー用のページは過去の遺物となり、キャリアの違いなんてのも遠い話。
端末ごとの解像度などが注目され、メディアクエリなどを駆使してレスポンシブに作ったりすることが一般的ですね。

ただし、「とにかく軽く」の思想は受け継がれており、AMP(Accelerated Mobile Pages)が登場しています。

9. 見栄えのために画像でガチガチに固めていた。

これは項目5.の隙間の調整とも少し被る部分があるのですが。

メインコンテンツ以外の共通メニュー、ヘッダー、フッターはすべて画像、メインコンテンツもメインタイトル、中タイトル、ボタンは画像、その配置には項目1.で紹介したtableコーディング。

共通メニューはマウスオーバーした時にロードする画像を「example_on.gif」みたいな別名で作ってたので、サーバー上は大量に画像があり、ネーミング規則をちゃんと作ったつもりでも画像が迷子になることがよくありました。

サイトのデザイン変更、ってなると、何百もある画像を全部書き出し直すという、恐ろしく非効率なこともやっていました。

あと、マウスオーバーで画像を変える仕組みは、CSSではなくDreamweaverのJavascriptと組み合わせるのが王道だったですね。

最初の会社ではFireworksを買ってもらえなかったので、「ホームページビルダー」に添付されている画像編集ソフトを重宝したのも良い思い出。

:angel: 輪廻転生の結果

今ならSEO的な観点からも、タイトルなどはできるだけテキストを使って文書構造を正しく作る、が基本です。

『border-raduis』や『box-shadow』とかを使うとボタンやタイトルが作れるし、マウスオーバーも『::hover』を使えば、ほとんどのものがCSSで代替できるようになりました。

あと、CSSで作っておくと、サイトのデザイン変更が簡単というメリットもありますね。

10. HTMLタグは全部大文字で打つものだった。

これ、私より少し後にこの世界に入った人に話しても通用しませんでした。

大学時代に初めてHTMLを触ったときには、タグは大文字で書くものと教わりましたし、卒論はFORTRANのプログラミングだったので、大文字でコードを書くことに抵抗は無いのですが、若い人からするとものすごい違和感を感じるようです。

でも、この記事を書くようになって、久しぶりにHTMLを全部大文字で書いてみましたが、確かに見づらいことこの上ない:sweat_smile:

慣れというのは恐ろしいものです。

img04.png

:angel: 輪廻転生の結果

今では余程の理由がない限り、小文字で書く以外の選択肢はないですね。

おまけ

今回の記事を書くにあたって、いろいろ昔のことを思い出したので、これ知ってたら年齢バレるで、ってのをついでに書いておきます。

  • カウンタでキリ番を踏んでいた。キリ番掲示板なるものがあった。足跡掲示板とかもあった。
  • 個人が借りる無料のホームページスペースといえば『ジオシティーズ』だ。(まぁ今もあるけど)
  • プロバイダに加入すると、もれなくホームページ用スペースがついてきた。もちろんURLの一部に「~(チルダ)」がつく。
  • 掲示板やブログ的なものは『CGIBOY』で借りていた。
  • DreamweaverやFireworks、FlashはAdobeではなくMacromediaだ。
  • 『相互リンク推奨』などと、今のGoogleさんが聞いたら目眩しそうなリンクのやり取りがあった。(法人のサイトでも結構あった)

最後に

新しい技術は次から次へと生まれて、使いにくい・古くなった・不要になった技術は消えていきます。

ドラム式洗濯機が出たときは「すげー!」って思いましたが、買った友人たちはみんな口を揃えて「次は普通の全自動にする」と言います。

仕組みとしてはすごいと思っても、何らかの理由で敬遠され、やがて消えていくかもしれない技術もたくさんあります。

Web担としては、常に新しい技術にアンテナを張っておく必要がありますが、たまにふと懐メロを聴きたくなるのと同じく、消えていった技術に思いを馳せるのも良いのではないでしょうか。

とかそんなことを言う私。歳を取ったのかなぁ…:scream:

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした