Studio TA Subsite の案内とお知らせ

<   2015年 04月 ( 22 )   > この月の画像一覧

浜の宮公園 2015.04.30 みんな居るのかな?

2015年 04月 30日
2013年4月以来の浜の宮公園です。 調べると去年は来なかった様だけど... 駅前の店舗や家並みが変わっていたりして、あれっと思うところがあります。

ここは連休に人が押し寄せて来る所ではありません。 静かな松林は、おそらく日頃と同じでしょう。 学校の吹奏楽部のホーンの音が聞こえて来ますが、それも松林の中に消えて行きます。

松林の中を歩き始めてすぐ出会ったのがツグミ達でした。 明石公園にはもう居ないのですが、ここでは少なくとも数羽が居残っている様です。
b0174191_20543300.jpg
松林に入って半時間ほどして、カササギの声らしきものがちらっと聞こえました。 少しずつ聞こえた方に近付くと、また「カキャッ」と独り言を言ってます。 しかしなかなか姿は見えません。 声のするあたりを10分程探して、やっと姿の見える場所を見つけました。
b0174191_21102992.jpg
何か物思いにふけっている様な感じ。 新しい松の雌花が沢山出てます。 これが好物だとか聞きます。 今日は、彼(彼女?)しか見つけることは出来ませんでした。
b0174191_21150496.jpg
遠い距離ですが、撮影出来ただけでも喜ばねば。 通りかかった地元の方は、何羽かを時々見かけると教えてくれました。 何処かに数羽ほどが居るのでしょうか?

カササギ君が姿をくらまして探していると、思わぬお客さん。 キビタキかな。
b0174191_21252718.jpg
高い松林の上層では、色々な鳥さんが行き交っているのでしょう。
地元のオジサンが「東の入口付近に巣があるよ」と教えてくれたので、行ってみました。 そこでも別のオジサンが声をかけてくれて、あれっ、あそこってね ^^; この公園を散歩するオジサン達は気さくな人が多く、また皆んなカササギ達のことが好きみたいです。
b0174191_21314079.jpg
これは旧い巣か、今の巣なのか判りませんが、カササギ達が頑張っている証拠ではあります。 かなり沢山の針金ハンガーが混ざってますね。

+

公園の端に市民プールがあります。 未だ開かれていないので、草が生えていたりしますが、不思議に楽しい景色でスナップしました。
b0174191_21420832.jpg
帰りがけに神社の裏手を周ると、カラス夫婦にグワーグワーとけん制されました。 巣が近くにあるかもと探したのですが判りませんでした。
b0174191_21562396.jpg
こんなにひつこくけん制されたのは初めてですが、カラス達にとってはそういう時期らしいです。

+

EOS7D + EF400mm F5.6L 、SIGMA 28mm F1.8 で撮影、画像はクリックで拡大表示します。




[PR]
by Ataron | 2015-04-30 22:03 | 鳥さんの写真 | Comments(0)

明石公園 2015.04.29 ゴールデンボーイズ

2015年 04月 30日
連休幕開け、天気まあまあ。 友人が参加したいと言うので、ポイントで落ち合いました。

テニス場は女子学生達の大会で、やたらと賑やかです。 そのせいか、ママ達は姿を見せません。 我らヤジキタはオムスビ弁当を囲み、とりあえず一般客に倣いました。 しかし、半時間以上待ってもママ達は現れず、少し寒くて友人を付き合わせるのは無理な気配。

で、大芝部でハト達に餌をやって帰ろうということに。 友人は早速ハトを見つけて餌やり開始です。
b0174191_11003718.jpg
これがハト達に大受けし、最初の十羽が更に倍になりました。 すると、何処からかママとキッズ2が現れて、友人の近くに降りて来ました。
b0174191_11004497.jpg
なんや、最初からこうしたら良かったんかとは、後で言えるセリフです。 まあ、後はポイントに戻って、無事に物資伝達を完了。 キッズ2は、やっぱり2個止まり。 ハト達もポイントに着いて来て、たらふくパンのヘタを食べました。 左ユビも知らん顔で混ざってましたね。 いや、ママ達が来てくれて良かった。

+

EOS7D + EF70-200mm F4L IS USM で撮影、画像はクリックで拡大表示します。






[PR]
by Ataron | 2015-04-30 11:13 | 鳥さんの写真 | Comments(0)

ページの幅構成の整理

2015年 04月 30日
殆ど私自身の覚書きになりますが、ブログページの幅設定について整理しておきます。
予定されるコメント記入欄復活で、調整にページの幅設定がからんで来るかもしれないので。

当方のスキンの原型はエキサイト提供「ワイド」で、それをアレンジしたものです。
b0174191_09153920.png
ウインドウの横方向への拡大に応じて、「本文」内容が幅を拡げて表示される構成。 これに併せ、ブログ名を表示した「ブログタイトル」「投稿タイトル」「コメント表示枠」「ページャー」等は、自在に横拡張する仕様です。

●「本文幅」はデフォルトが720px(最小値)と設定していて、本文コンテンツ(動画・ブロック要素等)の最大幅がそれを超える場合は、その値が本文幅の最小値となる。 但し本文コンテンツが幅720px以上の写真画像(静止画)の場合は、幅720pxに縮小掲載される。 つまり、この種のコンテンツを含む本文幅の最小値は720pxとなる。
(注)ブログスキンの編集画面の本文幅設定ボックスにより、本文の掲載画像の幅上限値が設定される。 またこの値に応じて、システムの指定CSSの部分が書換えられる。 その場所は、知りうる限り以下に書く「.bbs_preview」である。 私の場合、本文幅フレキシブル化のアレンジで上書きしている可能性があり確実でないが、システムが本文幅の指定をする場所は他にもあるかも知れないし、またスキンによって異なるかも知れない。

●この最小値を押し拡げない様に「他記事のサムネイル画像」(5個)の幅を各140px、計700px に設定。 この部分のCSS設定が、実際の本文幅の最小値の指定になっている。
.bbs_preview { width: 720px; }

●ページ末尾の「ポストテイル」(投稿日時|カテゴリ|トラバ|コメント|等の行)がブラウザの文字サイズ最大時も行あふれしない値として、「本文幅」のデフォルト720pxは適当。

●最上段の「エキサイトヘッダー」で右端にCMが入り、「ログイン」ボタンが隠れる場合がある。 これはウインドウ幅が980px以上では生じないので、「ブログ全体の表示幅」を980px以上として設計すると都合が良い。

●「右メニュー」(固定幅)は見易さを勘案すると180pxが欲しい。 メニュー上のリンク文字が途切れがちなのは、せりだしで改善。

おうよそ以上のことが幅設計の要件で、ノートPCや小型端末からの参照も考慮し、なるべくコンパクトに収めるのが基本。(幅があるページは小型画面では横スクロールが必要となる) スマホは専用スキンが適応されるので考えに入れない。

この条件で煮詰めたのが現在の幅設定です。
b0174191_02225326.png

A: 本文左マージン 40px
B: 他記事サムネイル画像 計700px
C: ポストテイル
D: メニュー左マージン 40px
E: メニュー幅 180px
F: メニュー右マージン 10px
G: 本文幅 デフォルト(最小値) 720px

「ブログ全体の表示幅」は 40px+720px+40px+180px+10px=990px
これは本文内容が幅720px(最小値)以下の場合で、内容の幅が最小値を超えると、990px以上の幅となる。

+

ブログ名を表示する「ブログタイトル」はウインドウサイズに応じて幅が拡縮します。 ここはHtml上では以下の様にtableで構成されています。

<table width="100%" align="center" id="HEADLOGO" border="0" cellspacing="0" cellpadding="0">
~~~~~~~
</table>

この構成は元スキンから受継いだものですが、実はちょっとした問題があります。
「ブログ全体の表示幅」より狭いウインドウで表示した場合、当然ウインドウには横スクロールバーが出ます。 この状態から、
(1) ウインドウ枠のドラッグでウインドウ幅を拡げた場合は、「ブログタイトル」は設計通りに横に拡がり、ウインドウ幅が「ブログ全体の表示幅」を超えた所で横スクロールバーが消えます。
(2) 横スクロールバーを右へドラッグして、ウインドウ幅を変えずに画面の隠れた内容を表示させると、「ブログタイトル」の右側は途切れたまま表示されます。(下図)
b0174191_02362239.png
(2)は私の意図した結果ではありません。
この様な操作をして気付く閲覧者は少ないかもしれませんが、余り嬉しいものではありません。

この問題を、少し改善する方法があります。 「ブログタイトル」(table)の幅の最小値を、あらかじめ「ブログ全体の表示幅」の最小値より少し大きめ(ここでは1000px)に指定してしまうのです。

table#HEADLOGO {
min-width: 1000px;
box-shadow: 0px 6px 8px #aaa; }

このページ内の最大幅の表示物を「ブログタイトル」に設定したわけです。 これにより、ウインドウ幅が1000px以下では必ず横スクロールバーが出ます。 この時(2)の操作をしても「ブログタイトル」は1000px以上の幅なので、先の様に切れることはありません。

しかし、この方法にも限界があります。 「本文幅」がデフォルト値の720pxを10px以上超えた場合です。 (「本文」に幅の大きなブロックなどの内容がある場合です) この場合は「ブログ全体の表示幅」が1000pxを超えます。 この条件でバーの右端までスクロールさせると、「ブログタイトル」の右端が表示されてしまいます。 要するに、「ブログタイトル」が最大幅の表示物でなくなったので「端」が見えてしまうのです。
...えっ、「min-width値」を十倍にしたら? そういうのもアリだけど、必ず横スクロールバーが出るページになるからね ^^;

写真画像等に関しては、スキン基本設定での「本文:720px」の指定に従って、システムが画像幅を自動的に720px以下にして表示します。 そういう影の援助のおかげで、普通は「本文幅」がデフォルト値を超えることはなく、ページデザインのバランスが保たれ、タイトル切れも生じ難くなっています。
しかし、Html編集で幅のあるブロック要素を指定したり、幅のある動画を取り込んだ場合など、まれにタイトル切れが生じてしまいます。

下に敢えて「幅 800px」のブロックを造り、このページで「ブログタイトル」の右端が見れる様にしました。

 <-- 幅は800pxです --> 
<div style="background: lightcyan; border: 1px solid black; border-image: none; width: 800px;">

上の水色のブロック右端が隠れるまで、ブラウザのウインドウ幅
を狭くします。(PC環境の話です)
ウインドウの下端に横スクロールバーが出ているでしょうか。
その状態で、
●下のスイッチを押してこのページ上部に移動する
●次に、横スクロールバーを使ってページ右端を表示させる

     [スイッチ]

実際にタイトルバー端の切れるのが見れましたでしょうか ^^;



[PR]
by Ataron | 2015-04-30 03:41 | ブログスキンのアレンジ | Comments(0)

Canonの望遠レンズがマイクロフォーサーズで使えそう

2015年 04月 29日
パナのマイクロフォーサーズ、私は大いに気に入った機種です。 野鳥撮影の場合は、EVFによるマニュアルフォーカスが実用になる事を、しっかり判らせてくれたシステムです。 で、EF400mm F5.6Lを購入した時も、早速にG3に着けてテストなんぞをしました。(イソヒヨドリを探せ 2012.09.06

最近は殆どマイクロ4/3機を持ち出すことがないのですが、主な理由がCanon望遠レンズの良さに慣れてしまったからでしょう。 それに、AF任せの即写はCanonの得意とする所ですし。

+

優れた望遠レンズ群のラインナップがあれば、マイクロ4/3は野鳥向きにも利点の多いシステムですが、悲しいかなそれが未だにありません。 手元にある望遠EFレンズを使用したくても、単なるマウントアダプターではAFはもちろん絞りすら効かないので、まあ使えません。

数年前にEFレンズの電子機能をコントロール可能なアダプターが登場しましたが、とても買う気になれない価格でした。 こんなのは動画のプロがどうしても要るので買うんじゃないかと思ったもんです。 ところが最近になって、ずいぶんと価格を抑えた電子マウントアダプターが出始めた様子です。

  価格.COM掲示板 M4/3用 AF対応 EFレンズアダプター 発表!

ここで紹介されていたのが、下の KIPON社製 EF-MFT AF というマイクロ4/3用の電子式マウントアダプターです。
b0174191_10294568.jpg
電子接点があり、小型ながら内部に専用チップを備えているのでしょう。 発売元 KIPON社の発表は以下のリンク先にありますが、価格は36000円程度の様です。

 焦点工房 KIPON 世界初! EFレンズ→マイクロフォーサーズ HIGH SPEED AF電子マウントアダプターを海外発表!

ここまで価格が下がって来れば射程内に入ります。 先ず絞りがボディからコントロール出来るのは決定的です。 更に、AF性能もやたら遅いというわけではない様子で、更に絞りや手振れ補正が効くのですから期待大です。

この流れは注目せざるを得ません。 5月中旬発売以降の評価を早く聞きたいものです。 マイクロ4/3陣営に、ニッチな世界から日差しが射して来た様な...

こちらに続きます。

[PR]
by Ataron | 2015-04-29 10:57 | 撮影機材/技術 | Comments(0)

コメント欄の仕様変更 再び / エキサイトブログ

2015年 04月 29日
当エキサイトブログは、昨年10月にコメント作成欄が別ウインドウ化されましたが、今回は、以前の様に同ウインドウ上にコメント作成欄を表示するタイプも選択可能になる様です。

これは4月17日が最初の発表で、調整や機能追加で4月下旬から更にズレて5月12日(火)に実施予定となっています。 詳細は以下のリンクを参照ください。

  <追記4/24>コメント投稿機能の仕様変更について

昨年10月よりブログのコメント入力欄を別ウィンドウ上で表示させる仕様に変更をさせていただいておりますが、利便性向上のため、変更前の仕様(ブログ記事上でコメントを送信できるように入力欄を表示する)の2パターンでコメント投稿機能の設定を選択できるように現在開発を進めております。

...とのことです。 以前の変更は「スパム利用の排除」が主目的でした。従って、「スパム利用の排除」機能を備えた同ウインドウのタイプが用意されると思われます。 いずれにせよ、別ウインドウ化で困っていた人には朗報に違いないですね。

私の場合は、またCSSを弄るかと楽しみにしてますが、同ウインドウの方が圧倒的に制御し易くなります。 別ウインドウだとCSSではほぼ制御出来ませんから。 もし、コメント入力欄が以前の様に狭い幅だったら、私はひっくりかえるかもね。(関西人はトンデモなく驚くと一斉にコケルのです)

+

少し話が変わりますが、以前から気になっている事。 それは、ブログの「設定」の頭の方で「新管理画面」「現行版の管理画面」を選択出来ますが、これが一本化される様子がない事です。 当初は「新管理画面」にいずれ移行するのだろうと思っていたのですが。

デザインは「新」の方が現代的で、原稿編集も「新」の方が捗りますが、細かいところで「現行版」でしか出来ない事があります。
b0174191_00570615.png
上図の「HTML不使用」の編集モードは「新」の方にはなく、「新」の「HTML編集」とは異なります。 滅多に使わないのですが...必要な時もあります。

また、スキンで使用する画像を「新」は登録出来ますが削除できません。 「現行版」は登録も削除も出来ます。 他にも、「新」は「現行版」から完全に移行しきっていない所がある様です。 単に面倒で移行作業を放置しているのか、したくても出来ないソフトウエア上の理由があるのか判りませんが。 私は、現状では「現行版」が無くなると「ちょっと困る」かなと思います。 そういうの判って、いつまでも選択出来る様に残しているのでしょうか?

とにかく、エキサイトさんが頑張って、良い環境を更新してくれるのは大いに感謝します。




[PR]
by Ataron | 2015-04-29 01:26 | ブログスキンのアレンジ | Comments(0)

明石公園 2015.04.19~26 桜の春は通り過ぎた

2015年 04月 27日
CSS(カスケーディングスタイルシート)を弄り出すとなかなか止まらなくて、写真の方をほったからしにしてました。 公園には休みごとに行っていたので、ちょっとふりかえって。

4月19日、日曜日の公園、これは以前も見かけたことがありますが、蛇を見つけたセキレイは大変に執着するのです。 セキレイは水場に居ることが多く、ヘビに遭遇し易いでしょうが、他の鳥達はどういう反応をするのでしょう? この時は、2羽のハクセキレイ達が、逃げもせず蛇の近くでじっと観察していました。
b0174191_22535581.jpg
ツグミっちの姿を見るのは、今期はこれが最後になりました。 足元は散り桜の跡。
b0174191_22543938.jpg
同じ場所で聞きなれないさえずりに気付き、主を探すとヤマガラ君でした。 時たま見かけますが、シジュウカラやエナっちよりずっと確率が低い。 この公園ではもっぱら単独行動だからでしょうか。
b0174191_23093567.jpg
桜は先ず花びらを落とし、次にこの写真に沢山写っている茎(ガク)を落とす様です。 この2ステップに今まで気付きませんでした。

この日、キッズ2は1個だけを取ってすぐに居なくなった。 ママはいつも通り。

+

4月25日、土曜日。
昼は垂水で友人と昼飯と昼ビール。天気が良くて街のお店をスナップ。 着付け屋さん?
b0174191_23391739.jpg
夕方に明石公園に到着、ママ達は間もなく現れる。 ずっとポイント近くに居るのでしょうか?
この日、キッズ2は2個持って行くが、3個目は待っても来ない。
b0174191_23413467.jpg
ママの方はいつもの通り。 水場に物資を隠すことが多く、ちょっとした泥溜りに埋めて、上に水藻を被せたりしています。
b0174191_23535572.jpg
+

EOS7D + EF70-200mm F4L IS USM、SIGMA 28mm F1.8 で撮影、画像はクリックで拡大表示します。



[PR]
by Ataron | 2015-04-27 23:55 | 鳥さんの写真 | Comments(0)

ユニクロブログパーツをアニメーションスクロール表示させる

2015年 04月 26日
ブログパーツのユニクロカレンダーは気に入ってるのですが、動画はShockwaveFlashであり、サイズは縦長(160×320px)か横長(424×200px)のどちらかの固定しか選べません。 はめ込み合成の様に動画が画面内に表示され、ブラウザの拡大率を変化させてもサイズは不変です。
(追記: このブログパーツ動画のサイズが変わらない問題は、当記事アップロード時の状況で、後に改善されました。 改善は Flash Player のバージョンによるものと思っています。)

縦長(小)のカレンダーは私の標準とするIEの拡大率125%では表示が小さく(他の環境では様々なバランスが有り得るでしょうが)、横長(大)を使いたいところです。 このブラウザの拡縮に応じないパーツを、狭いメニュー枠内に表示する手段として、思い着いたのが自動スクロール(アニメーションスクロール)です。

CSSアニメーションは、現状のブラウザによってはCSS記述を変える必要がある様です。
とりあえずIE11で動作するCSS指定は以下の様なものです。

:nth-child(17).MNTRAY:hover {
width: 150px; /* ブログパーツはせり出しなし */
right: 0px; }

@keyframes uniqlo { /* アニメーション名uniqlo の動作内容 */
0% { right: 0px; } /* ※u1 */
100% { right: 240px; } } /* ※u1 */

.BLOGPARTS {
overflow: visible !important; /* ※u2 */
position: relative;
animation: uniqlo 60s linear 1s infinite normal; } /* ※u3 */

最初の1項目は「:hover」時に、メニューのせりだしがない設定です。

2項目は「uniqlo」名のアニメーションの内容の設定。
※u1 設定値は、横移動の開始位置と終了位置の設定になります。「0px -> 240px」という値は、ブラウザ拡大率の「100%~125%」あたりでカレンダー内容が無駄なく表示される値で、拡大率によりスライド終了端が変わります。 カレンダーが隅に隠れ始めると早めに最初に戻ります。 「-150px -> 424px」とすると、全く隠れた所からスライドインし、見えなくなるまでスライドアウトします。

3項目は「.BLOGPARTS」というブログパーツを格納するブロックの指定です。
スクロールは、このブロックをアニメーション移動(right値を変化)させて実現しています。
※u2
を指定しないと、メニュー幅に設定した範囲以外は、スクロールしても表示されなくなります。
※u3は「.BLOGPARTS」のアニメーション動作の設定です。2項目のアニメーション内容が、各設定値で動作します。

このCSSの指定は、ブログパーツの設定時に登録する「ユニクロカレンダーのスクリプト」内容と不可分です。 先ず、カレンダーのスクリプトをユニクロのサイトで取得し、一旦はtextとして保存します。 その内容を一部書き換えて「背景透過」型とします。

取得したスクリプトは下の様な構造で記述されています。

<object ~~~~~~~~~~~~   />
<param ~~~ />
<param ~~~ />

<embed ~~~~~~~~~~~~ ></embed>
</object>

これは、対応ブラウザを想定した2段構造の記述の様で、
上の前半部分(object)に
<param name='wmode' value='transparent'>

を追加し、
下の後半部分(embed)に
wmode='transparent'

を追加します。

これをブログパーツの設定でスクリプトとして登録すればOKです。

+

以上でIE11ではアニメーション動作が問題なく演出されましたが、Chromeやその他のブラウザにはベンダーフィックスというお呪いを付加しないとアニメーションしません。 いずれは後に統一したCSS記述で通せる様になるでしょうが。
先の3項のCSS記述の内、最初の行以外を下の様に拡張しました。

@keyframes uniqlo {
0% { right: 0px; }
100% { right: 240px; } }

@-moz-keyframes uniqlo {
0% { right: 0px; }
100% { right: 240px; } }

@-webkit-keyframes uniqlo {
0% { right: 0px; }
100% { right: 240px; } }

.BLOGPARTS {
overflow: visible !important;
position: relative;
animation: uniqlo 60s linear 1s infinite normal;
-moz-animation: uniqlo 60s linear 1s infinite normal;
-webkit-animation: uniqlo 60s linear 1s infinite normal; }

これでChromeでもアニメーション動作が実行されました。

+

〔追記〕
私のメインマシンでは問題なくアニメーションが演出されたのですが、サブマシン(Win7)のChromeでは私のブログを開くと「Shockwave Flashがクラッシュしました」とブラウザが帯で表示し、動画が表示されません。 このブログパーツのみの話で、他のFlash動画が再生されないわけでなく、システムに致命的な問題があるとは思えません。

ネットで色々調べると、どうやら複数のFlashプラグインがインストールされているのが原因している様でした。 この状態が問題を生じるには条件があり、私のアニメーション設定もその一つでしょうか。 私のページのアニメーションがクラッシュして見えなくても、参照側のシステムを敢えて改善する必要はなのですが、気に入らないならプラグインの整理で改善するかもしれません。 私のサブマシンでは首尾よく改善され、Chromeでもブログパーツの動画を再生できました。



[PR]
by Ataron | 2015-04-26 23:32 | ブログスキンのアレンジ | Comments(0)

メニュー構造(せりだすメニュー)の更新

2015年 04月 26日
右メニューは全体がせりだす構造でしたが、これをメニュー項目単位がせりだす構造に改めました。 また、今まで背景画像(グラフィック)で角丸や影を描出していましたが、「border-radius」「box-shadow」で描画する方式に改めました。 グラディエーションによる立体表示は採り入れておらず、グラフィック描出には及びませんが、これはまたの課題です。

下図は従来のメニューのハードコピーで、背景画像は「最上辺」「中央部」「最下辺」の3パーツです。 メニュー右辺の影はメニュー幅を取られるので描いていませんでした。
b0174191_18345640.png
影描出で問題になったのは、(a)項目単位の影がメニュー表面に描かれてしまう点と、(b)右辺の影がメニュー全体の影と重なって描画される点です。
b0174191_18361438.png
右辺の影を良く見ると、メニュー項目の繋ぎ目で濃さが乱れてます。
(a)の対策で、各項目の下側に影をマスクして隠すパーツを付け、(b)には項目単位は右側に出る影を控えめに設定することで対応しました。
b0174191_18374488.png
赤い部分がマスクのパーツです。 右辺の影は重なりが改善され、前図より影が淡く、乱れも目立たなくなっています。 右の実際のメニュー上にマウスポインタを乗せて確かめてください。

+

メニュー構造について、Htmlに則して説明します。
エキサイト提供スキンでは、何種類かのメニュー構造がありますが、ユーザーが設定したメニュー内容を実際のHtmlに反映する基本システムは同じです。 システムは、ユーザーが登録したHtml内で「<$~~~$>」の型の特別な部分に、必要な内容をインポーズして最終的なHtmlを生成します。
下は「スキン編集」画面ですが、「全体」が大元になるHtmlで、その本文部分にインポーズされるHtmlが「本文」に、また右メニュー部分にインポーズされるHtmlが「右メニュー」に登録されています。
b0174191_18411239.png
「全体」に置かれたHtml中で、メニューに関したインポーズは、以下の3個です。
  <$description$>
  <$logoimage type=1$>
  <$menuright$>


「全体」のメニューに関した部分だけですが、スキンにより異なりますが、似た様なものが多いでしょうから下に参考に示します。

<div class="MN_TOP"></div>
<div class="MN_BODY">
<div class="PROFILE">
<center><$description$></center>
<center><$logoimage type=1$></center>
</div>
<div class="MN"><$menuright$>
</div>
</div>
<div class="MN_BOTTOM"></div>

また、最後の「<$menuright$>」には、「右メニュー」に置かれた雛形Htmlを元に、ユーザーごとの内容を書き込み、指定された個数を並べて生成したHtmlがインポーズされます。「右メニュー」の雛形Htmlにも以下の2個のインポーズが含まれています。
  <$mntitle$>
  <$mnbody$>

私の今までのスキンで「右メニュー」に登録していた雛形Htmlは以下です。 これも、同様の提供スキンは多いと思います。

<div class="MNTTL"><$mntitle$></div>
<div class="MNBODY"><$mnbody$></div>

上の雛形に沿ったHtmlが、最終的なHtmlのメニュー部内にメニュー項目の数だけ並ぶことになります。

+

以上が画面上に表示されるメニューのどれに相当するかを以下に示します。(メニュー数は3とした模式図で、上記の私のスキン上のClass名を表示しています。スキンによりClass名やHtml構造に違いがあり得ますので注意してください)
b0174191_18395992.png
左の〔従来のメニュー構造〕で、「MN_TOP」「MN_BOTTOM」は背景画像を表示する目的のブロック要素でしたが、〔新しいメニュー構造〕では存在意味を失いました。(今後のグラディエーション導入用等に残し、表示はされません)
従来では、メニュー項目の並びを囲む「MN」に「:hover」を設定して「せり出し」をさせていました。 新メニューでは、各メニュー項目ごとに「せり出し」させるために「MNTRAY」を新たに造って囲み、また不要な影をマスクする「MNSPACER」を追加しています。 Htmlの改造は、「右メニュー」に登録された雛形HTMLを下の様に書き換えただけです。

<div class="MNTRAY">
<div class="MNTTL"><$mntitle$></div>
<div class="MNBODY"><$mnbody$></div>
</div>
<div class="MNSPACER"></div>

上図「新しいメニュー構造」では、この雛形が縦に3個並んでいます。

+

以上のHtml更新にともなった、CSSの更新の要点は以下です。
(不要となった指定分の削除、微妙な配置修正などは省略しています)

div.MN_BODY {
background: #b8dcef;
border-radius: 6px; /* メニュー全体の角丸 */
box-shadow: 4px 4px 6px #aaa; } /* 全体の影指定 ※b1 */

.MNTRAY {
background: #b8dcef;
padding: 0px 15px 0px;
box-shadow: 2px 4px 6px #aaa; } /* 項目ごとの影指定 ※b2 */

.MNTRAY:hover {
width: 240px; /* せり出し後の幅 */
position: relative;
right: 90px; /* せり出しの表示位置調節 */
border-radius: 4px 0px 0px 4px; } /* せり出しの角丸は左側のみ */

.MNSPACER {
height: 8px; /* マスク縦幅で影を隠せる値 */
background: #b8dcef;
position: relative;
z-index: 1; } /* マスクとして重なり上側を指定。 IEでは不要の様です */

最初に書いた(a)の対策が「.MNSPACER」です。 「height」を調節して影をカバーする値としています。重なりの上側を指定する「z-index」は無くても問題が無い様ですが、思わぬ影露出を防ぐ念のためです。
(b)の右側辺の影干渉のために全体の指定「※b1」に対して、「※b2」は横へのシフトを減らしています。「box-shadow」を透過値付きで記述して不透過としても、影自体は下の影を透過し表示される様です。(IE11では) 従って、影の干渉を避けるには影のシフト値の調節しか手がありませんでした。
なお、「.MNTRAY:hover」には「box-shadow」の行がありませんが、これは「.MNTRAY」の設定を継承するので省いています。

+

メニュー雛形のHtmlを変更すると、メニューで「:nth-child(n)」を使ったセレクタ指定があった場合は、「n」値を含めセレクタの書き換えが必要になります。(Html構造上の配置が変わるため)
この「n」値の例は「エキサイトブログのメニュー構造は色々 /サイドメニュー篇」「エキサイトブログのメニュー構造は色々 /ボトムメニュー篇」が参考になります。

今回、この様なメニュー上の従来セレクタは全て書き換えが必要でした。 上側が従来、下側が新しいセレクタです。

〔メニュー第1項---検索タイトル関係〕
:nth-child(1).MNTTL::before { }
:nth-child(1).MNTRAY > .MNTTL::before { }

〔メニュー第1項---検索記入枠関係〕
:nth-child(2).MNBODY table { }
:nth-child(1).MNTRAY > .MNBODY table { }

〔メニュー第4項---以前の記事関係〕
:nth-child(8).MNBODY { }
:nth-child(7).MNTRAY > .MNBODY { }

また新たに、メニュー「メモ帳」で登録していた外部リンクのメニュータイトルを「::before 」で書き込めることに気付き、以下の項を追加しました。

:nth-child(13).MNTRAY > .MNTTL::before {
content: "外部リンク+"; } /* メモ帳による外部リンクのタイトル表示 */

今回の更新は、各メニュー個別に「せり出し」を制御できる効果があります。
最下段のブログパーツは「せり出し」の意味がなく、表示乱れを抑止するのに腐心した部分です。「メニューの幅を克服(せり出すメニュー)」を参照くださいる。 最下段メニューは以下の記述で、せり出しをさせない様に指定するだけで以前の指定は不要になりました。

:nth-child(17).MNTRAY:hover {
width: 150px; /* ブログパーツはせり出しなし */
right: 0px; }

+

ユニクロブログパーツは、大サイズを使用したい事、ブラウザの拡大表示機能に対応しない埋め込み動画である事などの理由で、アニメーション(スクロール)表示の導入を試みています。
これは別稿に整理します。




[PR]
by Ataron | 2015-04-26 17:35 | ブログスキンのアレンジ | Comments(0)

「以前の記事」のスクロールバー表示 / スクロールのトラップを改善

2015年 04月 18日
メニュー上の「以前の記事」を、私はスクロール表示して選択できる様にしています。 このアレンジは以下の過去記事に説明があります。
  「以前の記事」をスクロールバー表示
上の記事を纏めると、「以前の記事」に関するCSSアレンジの項目は下の項のみです。

nth-child(8).MNBODY {
width: 100%;
height: 120px;
overflow-x: hidden;
overflow-y: auto;
scrollbar-base-color: #9cd6f4;
scrollbar-arrow-color: #888; }

但し、「nth-child(8)」の「8」は、メニュー構造が私のタイプの場合で、「以前の記事」がメニュー上で「4」番目の場合に、「上から8番目のMNBODY」に「以前の記事の月別リンク」が並ぶことから、「8番目の子要素」というセレクタ表記を採ったものです。

+

このスクロール表示は気に入ってますが、ひとつ問題点がありました。 それは、マウスのスクロールホイール等でページをスクロールさせる時に、ポインタがこの「以前の記事」上を通ってしまうと、ページのスクロールが止まり、「以前の記事」のスクロールになってしまう事です。(スクロールのトラップ)

下の様に、マウスがメニュー上を通らないと問題なくページはスクロールされます。
b0174191_23395737.png
しかし、ポインタがメニュー上を通った場合に、下の様に「以前の記事」の場所に入ると、ページのスクロールは閲覧者の意思に反して一旦停止となります。
b0174191_23422736.png
スクロールの指示は「以前の記事」のスクロールと受け取られてしまうからです。 「以前の記事」が端までスクロールすると、再びページスクロールとなります。 また、ポインタを他の場所に移せば抜けられますが、少し嫌な仕掛けに感じます。

+

これは、「:focus」(擬似クラス)を使ったセレクタ記述で、うまく回避できそうと判りました。 スクロールバーは常時は表示しない設定とし、意図的にこの「以前の記事」のエリアをクリックした時(フォーカスした時)のみ、スクロールバーを表示させれば良いわけです。

以上の方針に沿って、上記のCSS記述を以下の2項に改めました。

:nth-child(8).MNBODY:focus {
overflow-y: auto; } /* フォーカス時に 縦スクロールバーを表示 */

:nth-child(8).MNBODY {
width: 100%;
height: 120px;
overflow-x: hidden;
overflow-y: hidden; /* 本来の値は auto(表示)を非表示指定にしている */
scrollbar-base-color: #9cd6f4;
scrollbar-arrow-color: #888; }

これで、ページスクロール時に不本意にトラップされる事がなくなりました。
b0174191_00021796.png

めでたしめでたし ...と思ったけれど、これでは「以前の記事」欄がスクロール可能だと判りません。 閲覧者が気付いてクリックしてくれるかもしれませんが。

そこで、ここにスクロールバーのフェイク画像を背景画像として貼り付けることにしました。
b0174191_22530730.png
常時は「ドラッグバーの無いスクロールバー」の画像を表示します。 スクロールの機能は無いので、画面のスクロール操作をトラップすることはありません。 でも、これで「以前の記事」はスクロール表示であることが判り、バーをスクロールさせようとクリックすれば、実際のスクロールバーが表示されてスクロール操作になります。

下図の青枠(Grafic)がフェイク画像の本体です。 画像は400%に拡大して取得した画像で、バーとその周囲のみです。
「以前の記事」(:nth-child(8).MNBODY)の実際のエリアは、下図の赤枠の部分です。 この赤枠内に右寄せで画像を配置し、縦横比は変えずに縦方向は赤枠にぴったり内接する様に「 background-size: auto 100%」という指定をしています。 この「-size」の利用で、400%の画像を実画面では縮小して表示させ、鮮明さを失わない様にしています。
b0174191_23173972.png

このフェイク背景画像の導入に関するCSSの項目は以下です。

:nth-child(8).MNBODY:focus {
overflow-y: auto; } /* フォーカス時に 縦スクロールバーを表示 */

:nth-child(8).MNBODY {
width: 100%;
height: 120px;
overflow-x: hidden;
overflow-y: hidden; /* 本来の値は auto(表示)を非表示指定にしている */
scrollbar-base-color: #9cd6f4;
scrollbar-arrow-color: #888;
background-image: URL(http://pds.exblog.jp/pds/XXXXXXX.gif); /* 背景画像のURL*/
background-repeat: no-repeat; /* 画像を1つだけ表示させる(反復なし)*/
background-position-x: right; /* 画像の右寄せ */
background-size: auto 100%; } /* 縦横比は変化させず、縦方向は表示枠内に内接 */

まあ、これでなんとか目的を達したと思います。 右メニューに実装していますので、動作を確かめてみてください。

+

と書いたところで、Chromeでテストしてみてがっかり!

「:focus」での動作が、IEとChromeで異なります。 本来は「input」「textarea」「select」等の要素に適応される「:focus」を、IEではクリックした他の要素にも修飾を適応し、これはIEの独自の解釈の様です。 従って上記のCSS表記では、Chromeやおそらく他のブラウザでもクリックしてもスクロールバーは表示されない状態です。

これは対策が必須ですが、「フェイク画像をクリックして実際のバーを表示させる」記述はIEだけに読ませ、他のブラウザには「スクロールバーを表示する」記述を読ませることが出来れば、全て上手く収まります。
ネットで調べたところ、こういう事を実現する方法は、余り理想とは言えないですが「CSSハック」に拠るのが一般の様です。

:nth-child(8).MNBODY {
width: 100%;
height: 120px;
overflow-x: hidden;
overflow-y: auto; /* 従来の値 auto(表示)に戻している */
scrollbar-base-color: #9cd6f4;
scrollbar-arrow-color: #888; }

@media all and (-ms-high-contrast:none){ /* この項はIE10,IE11にのみ適応させるハック記述 */
:nth-child(8).MNBODY {
overflow-y: hidden; /* IE10,IE11では非表示に指定(上項の後方で指定のこと) */
background-image: URL(http://pds.exblog.jp/pds/XXXXXXX.gif); /* 背景画像のURL*/
background-repeat: no-repeat; /* 画像を1つだけ表示させる(反復なし)*/
background-position-x: right; /* 画像の右寄せ */
background-size: auto 100%; } } /* 縦横比は変化させず、縦方向は表示枠内に内接 */

:nth-child(8).MNBODY:focus {
overflow-y: auto; } /* フォーカス時に縦スクロールバーを表示 */

最初の項は、従来のスクロールバーを表示させるものに戻しています。 これは、全てのブラウザに有効な内容です。
第2項のセレクタはCSSハック記述で、IE10とIE11のみでこの項が有効に反映されます。 内容はスクロールバーは非表示で、フェイク画像を表示するものです。
最後の項はIEで有効ですが、他ブラウザでは無効なのでそのまま表記してあります。

結局、トラップ回避の効果は最近のIEに限定されてしまいました。 そのうち良い方法が見つかるかもしれませんが。 改めて、IE10とIE11の方は右のメニューで実際の動作を見てやってください。 他のOS環境などでの動作なんかは...判らないもんねぇ。



〔追記〕2016.11.22

このページのトラップ防止の方式は、以降に新しい方式に改めています。

  CSSで作るマスク:スクロールトラップ防止(1)
  CSSで作るマスク:スクロールトラップ防止(2)
  CSSで作るマスク:スクロールトラップ防止(3)実装

説明が冗長なので、簡単に内容を知るには「(3)実装」から参照ください。 これが現在、当ブログで使っているスクロールトラップ防止の仕組みです。





[PR]
by Ataron | 2015-04-18 00:03 | ブログスキンのアレンジ | Comments(0)

メニュー「検索」のスイッチの大きさ(続き)

2015年 04月 16日
前稿で「検索」のボタンと記入枠のアレンジ修正をして、周辺のデザインをもう少し煮詰めました。

1)「検索」ボタンのデザインをエキサイトのデブォルトからアレンジしてしまう。(シンプルなデザインだが色を好みに設定出来る)
2) ボタンの「検索」の文字をもう少し小さく「0.8em」とする。
3) 記入枠とボタンの「a要素」の paddingを再調整。
4) 記入枠は「:focus」(擬似クラス)を導入し、記入の時点は「白」、常時は「薄いブルー」で余り目立たない様にする。

更新したCSSは以下の4項です。

input[NAME='q'] {
width: 100%;
font-size: 1em;
padding: 0em 0.12em 0.04em;
border: 1px solid #d5f1ff;
background: #d5f1ff; } /* 記入枠の常時の配色 */

input[NAME='q']:focus { /* 記入枠に記入中は枠内が白反転する設定 */
background: #fff; }

input[value='検索'] {
font-size: 0.8em;
padding: 0.14em 0.5em 0.20em;
background: #9cd6f4; /* 検索ボタンの常時色 */
border: 1px solid #d5f1ff; }

input[value='検索']:hover { /* 検索ボタンにポインタが乗れば白反転 */
background: #fff; }

下図は以上の修飾の結果です。

常時は検索枠は「#d5f1ff」(薄いブルー)、検索ボタンは「#9cd6f4」(メニュー周囲と同色)で、必要以上に目立たなくなりました。
b0174191_22553326.png
記入枠に記入中は必然的にメニューはせり出して、記入枠の背景色は「白」となります。
b0174191_23050164.png
検索ボタンにマウスが乗ると、ボタンは白反転します。
b0174191_23062896.png
padding値は、文字の枠内での高さとボタンと記入枠の並びを考慮して、決めた値です。



[PR]
by Ataron | 2015-04-16 23:08 | ブログスキンのアレンジ | Comments(0)