html/css

段落って難しい。

お恥ずかしい話なんですけど、段落というものがよくわからんです。

わからんといっても、段落には形式段落意味段落の2種類があることや、それぞれの概念も一応知ってるつもり。
しかしそれでもイマイチ段落というものがどうしたら適切になるのかよくわからんのですよ。

意味段落をフィーリングでしか片付けられない。

わからんわからん言っても少なからず文章は書いてきたわけで、じゃあ今までどうやってきたのか?と過去を振り返ってみるとやっぱりフィーリング。
それと嗜好。

例えばその昔、次のような出来事がありました。

「あんたの書く手紙の文章が誰かに似ていると思っていたんだけどわかった、原田宗典っていう最近はエッセイばっかり書いてるけど小説家の文章に似てるんだ、読んだ事ある?」とたずねられた事があって、「読んだこと無いし誰だかしらん、どこが似ているのか?」と答えたら「大雑把に言うと文章に句読点というか読点があまりないところ」とのこと。

当時はなぜか読点(、)が嫌いだったのと、文章によくわからん勢いを持たせたくて区切りのわからない文章を書いていたので、たしかに上で言われたような書き方をしてた。

不思議な事に、そんな書き方をしていても(日本語で?)紙に書く手紙だと普通に読めてとくに読みづらくなりもしないみたい、言い回しが関係してくるのかもしれないし内容がないからなのかもしれないけど。

けどそのノリでメールを書いたり、フォーラムで質問したり回答したり、blogに文章を書くとこれがうまいこといかない(というか、うまいこといってない手応えを感じる)。
自分でも見づらいし。

徐々にメールは短文になり、質問などは細かく説明するようになって(気力と時間がある時は)文節が長くなって、blogの時はいまだにどうしたらいいのかわからないまま。

でもってWebサイト作成時の話

時代やhtmlの習熟具合によって変化してきた。
なぜなら最初は<p>(paragraph)の存在すら知らなかったので例に漏れず<br>の連続だったような気がするけど、詳しい事は覚えてない。

Web制作とは直接関係ない仕事でWebサイトを編集するようになってから(文章のルールが決められていない場合)は、句点(。)で改行が入ると個人的に見やすいような気がしたので句点ごとに<br>、これが形式段落。
1行分のスペースが開いたら意味段落だと思って<br>の連続で意味段落としてた、多分まだ<p>タグを知らない酷い話。

Web制作の会社に就職して、独学でHTMLを勉強してWeb標準っちゅー流れがある事を知ったり、lintで文法をチェックするようになったり、アメブロによくある改行を多用してるブログに嫌悪感を持つようになったり、観覧者のブラウザサイズは一定じゃないのに何かに合わせて改行をコントロールするのはどうなんだろう?と考えたりしてるうちに<br>を使う事に抵抗を感じるようになって句点(。)ごとに<p>を使うようになる。
しばらくそんな状態でやってきて今も基本は全部<p>だけど、<br>で形式段落、<p>で意味段落か形式段落に落ち着いた感じ。
結局、意味段落はここは意味の繋がりがあるよねってフィーリングのまま。

段落とかパラグラフとか

段落について調べて(検索)していくと、日本語には元々段落というものは存在しなかった的な話があったり面白い(Ted’s Coffeehouse 2: 日本語文章においての段落概念の欠如 (The Lack of the Paragraph Structure in Japanese Writing))

例えば『源氏物語』にはパラグラフ構造がなく、始めから最後までのっぺらぼうに続いており、日本の古典はすべてそうである、といっている。現在印刷されている古典にパラグラフの形が見られるのは、後の編集によるものであろう。

パラグラフって何だろう?

文章の節または段落。みたいな説明をよくみる。
または、トピックであったり、ひとつのテーマだったり、論点だったり主張だったり。

なるほどなぁと思った説明があったので引用させてもらうと。
パラグラフについて書いた外山滋比古。パラダイムのシゲルちゃんじゃないからね。(日本人と西欧人の思考形式の違いかぁ、一応なるほどだけど・・・) – Comments by Dr Marks

確かに「パラグラフとは段落のこと」である。そして、その段落とは文章の区切りであり、字下げ(indentation)や行を空けることによって区切られた文(sentence)のまとまりである。また、それぞれの文のまとまりは、一つ一つの段落の中で意味やアイディアが完結している。したがって、この最後の点が日本語の段落とは様相を異にする。

日本語の段落は、国語学者によって形式段落と意味段落という区別が試みられたように、普通は一つの(外形的・形式的)段落が意味やアイディアを完結することがない。一般的には日本語の段落はすべて形式的な(つまり字下げや行空けがあるだけで)段落に過ぎず、意味やアイディアが完結していない。意味やアイディアが完結するためにはいくつかの形式段落を繋ぎ合わせなければならない。そして、意味としてあるいはアイディアとして一まとまりになった(完結した)段落を無理に意味段落と呼んでいる。

したがって、日本語の見かけ上の段落(形式段落)は短く切れ切れであるが、英語のパラグラフであれば、見かけ上の段落(形式段落)と意味のまとまりの段落(意味段落)が合致するため、日本語の段落よりはるかに長くなる。(英語のパラグラフはすべて意味段落。)どうして日本語の段落が形式的で短いかということについては諸説ある。どうやら、英語の段落のように長い日本語は読みにくくなるらしい。これは確かにそうで、余も日本語のブログの段落は短い形式段落を採用している。

最初の「紙に書いた文章の読みやすさが変わらないようだ」云々は、句読点はないけど見かけ上のまとまりがあったからとか、読んでる人達が段落にこだわりがなかったからとか、短い文章だったからとか、社交辞令だったとかの理由が考えられるのかな?

Webの場合、日本語の段落として扱うより英語のパラグラフとして扱った方が自然ぽい。

パラグラフ・ライティングとトピック・センテンス

そうすると(うちはよく知らないんだけど)英文の定番らしいパラグラフ・ライティングとトピック・センテンスを使えば論理的な文章を自然なマークアップで記述できるようになるのかな?

パラグラフライティングの参考

第3回プロから学ぶ「わかりやすい文章の書き方」
実践!作文研究~メールマガジン・第190号
パラグラフライティングとトピックセンテンス | SEO 検索エンジン最適化 ソーシャルニュース

トピックセンテンスの参考

「トピック・センテンス」とは何か
トピックセンテンス(小論文の書き方)
実践!作文研究~メールマガジン・第194号

問題は

すでにある変更できない(そしてパラグラフ・ライティングとトピック・センテンスを踏まえていない)文章は、どのようにマークアップしたら適切になるのか?
なんだけど、やっぱりフィーリングなの?

簡単に Another HTML-lint gatewayで html のチェックが出来るブックマークレット。

[追記]現在は使えなくなっちゃいました><;;;

うおおおおおおおおおおおおおおおお 突然ですがこれは『気合いの雄叫び』ですッ!

昔は Web developer ( Firefoxのアドオン ) から簡単に、現在見ているページをAnother HTML-lint gatewayでチェック出来ていたのですが、ある日気がつけば以下の文言が表示されるようになって慌てた人も多いのではないでしょうか?

[image]このメソッドは禁止しています。 フォームページ から利用して下さい。とブラウザに表示されている画面

自分がそうだったからって、他の人もそうなんじゃないですかとか決めつけちゃって失礼ですよね、ごめんなさい。
とりあえず、ひとしきり騒いだ後、“外部からのGETリクエスト停止” になった事を知り肩を落としそして少し泣きました。

それ以来 ( 2009年4月30日以降) html の検証をするには、Another HTML-lint gatewayにアクセスして
チェックしたいHTMLのURLを指定するか、HTMLを下のテキスト領域に直接記述して、[チェック] ボタンを押して使う事になりました。

当時はもう文法チェックする頻度も下がってはいたけど、Web developerからチェックする事に慣れきっちゃっていたので
いざ普通に使おうとしたらウオオオオオ ウダラァーーーッとまでは行かないまでも、面倒くさい事面倒くさい事。

あれから一年余、なんと現在も有効なAnother HTML-lintのブックマークレットがありましたッ!
Another HTML-lintのブックマークレット | 沖縄のWebデザイナーChopstickBrunch
また、簡単にlintにかけられるなんて日が来るなんて、感無量。

続きを読む

自動改行(word-break・word-wrap・white-space プロパティ)をコントロールして、テキストがボックスから飛び出さないようにしたい。

ん~、違いがようわからん。

テキストがボックスからはみ出る

上記3プロパティの動作確認用ページ (ポップアップで開く)
Firefoxはどれを指定しても、連続した半角英数が長いとtableが伸びちゃうなぁ。

以下、自分の解釈メモ ( なので正しいかどうか怪しいです )。

続きを読む

z-indexの使い方

z-indexは、position ( relative / absolute / fixed ) と一緒じゃなきゃ適用されないッ!
といまさら知った自分にビックリ。

でも、positionを使ってない要素達の重なり順をコントロールしなきゃならないシチュエーションに遭遇する事なんて、ないだろうから知らなくてもなんとかなるんもんだ。

ついでにその他 z-index の事。

  • 数字が小さい方が背面で大きい方が前面。
  • マイナスも指定できる。

IE 6,7 絡みの事。

  • 入れ子の中で使った場合、その親要素の次に出てくる要素の方が前面に来る。
  • 親要素にz-indexを使うと解決できる。

左 / IE7で表示、右 / IE8で表示したスクリーンショット
左:IE7 / 右IE8

あんまりposition使わないから関係なさそう。

Internet Explorerのテキストフィールド(input type=”text”)のテキスト縦位置をイイ感じにしたい。

テキストフィールド ( input ) に padding ではなく height を指定したい時があるんですけど
そうするとIEで文字が上揃えになっちゃってるみたいなんですよね。

IE 8 の表示(6~8同じ感じだった)
IEのinput内テキスト縦位置

Firefoxは最初っからイイ感じ。
firefoxのinput内テキスト縦位置

html

css

細かい事で申し訳ないけど気持ち悪い、なんとかしたい。

IEでも縦位置中央にするには

試してみた結果、heightと同じ値をline-heightに指定する方法が有効ぽかった。

続きを読む

続き / スクロールに合わせて、移動するメニュー(要素)

この投稿には最新版(続き)があります。
懲りず ) jQueryを使った画面スクロールに合わせてついてくるフローティングメニューが一応形になりまんた。

jQuery練習中

二転三転中、最初の見極めが甘いんだろうなぁ
作って試してみると、じゃあこうゆう時はどうなる?こうなったら?が出てくること出てくること。
あーしたい、こーしたいって欲も。

前回の練習以降に変更した事。

_1.footerと被った部分の処理とあえて移動させない処理。
ウインドウサイズをちょこちょこ縮めていくと(普通はそんな使い方しないけど)メニューとフッターが被る。
処理を1.ヘッダーが画面内にある場合 / 2.フッターが画面内にある場合 / 3.両方画面内にない場合の3段階に分けて、メニューが移動する位置などを決めるようにした。

_2.コンテンツの中身が全然ないhtmlの場合
4.ヘッダーもフッターも同じ画面にある場合はどうなるの?と思って試してみた。
コンテンツ部分を短くしたら(このページは現在製作中です的な長さ、公開するなよって話)不具合が。

_3.コンテンツの中身が全然ないhtmlの場合:修正
短い場合の修正として、コンテンツの高さを無理やり広げた。
そうしたところ、今度はbodyの高さを取得する順番なんかが狂ってしまった。
スクロールに合わせて移動するメニューなのに移動させない処理を追加

_4.javascript外部化、要素名を変数化
いままでのままだと、移動する要素ややヘッダーやフッターの名前を変更したい時に書き換える部分が沢山あるので変数にした、速度とかも。あとhead内の記述から.jsにした。

続きを読む