Studio TA Subsite の案内とお知らせ

<   2016年 05月 ( 22 )   > この月の画像一覧

編集画面をアレンジする(5)/ エキサイトブログ IE11版-1列パレット

2016年 05月 29日
前ページの IE11版-2列パレット から、画像パレットを1列で縦スクロールするものにアレンジしました。
こちらの方が画像パレットの幅が節約出来、パレット上の画像自体は大きく判別し易くなります。 私の実際の編集スタイルからは、こちらの方が使い易くてしかもコンパクトです。

(余談: 画像を差し替えたい時にしか使わない左メニュー「画像管理」、記事に張付けるを押すと、その画像を貼った新しい投稿画面が出来るだけです。 このウインドウと編集ウインドウを別個に開いて、画像を編集ウインドウに貼れると便利なんですけど、ダメみたい。 なんだかなぁ。)

1E11でブラウザ画面拡大率125%文字サイズ「大」で編集中の画面のハードコピーです。 ブラウザの拡大率を100%として画像をクリックすると等倍表示されます。(IE11版-1列パレット)

b0174191_08593505.png

●画像パレットは更に幅も高さもコンパクトになり、ブラウザの拡大率150%でも普通にウインドウを扱えます。 逆に、ブラウザの拡大率を100%に抑えた文字サイズ「最大」もバランスが良く、2列パレットよりこちらの方が適応性が秀でていると感じます。

●画像パレット部とウインドウ最小幅の他は、デザインの詳細部分は共通です。 文書の編集枠の縦幅は同じですが、こちらの方がよりコンパクトです。

●テキスト入力枠の「box-shadow」(落込み影 デフォルト)は余り美しくないので、この編集ページに限り抑止しました。

●画像をドラッグ&ドロップする部分は、文字サイズ固定で行崩れを抑止。 また、背景色をブルーにして「アップロード中」「送信エラー」等の表示が確認し易い様にしました。

●これで「マイブログ」スイッチがあれば理想なんですが、IEの場合はスイッチ位置を元のまま利用したデザインを造るしか、手段がありません。

●別案ですが、文書編集要素と画像パレットを固定し、全体スクロールは編集枠の下部分のみというレイアウトも良いかなと思います。 編集枠自体がスクロールしてしまうのが不便な時がよくあります。 昔のメーラー等はそういう事がなくて使い良かったのですが。

●以下の枠内のテキストをメモ帳にコピペし、適当な名前の「~.css」ファイルとして保存、それをIE11にユーザースタイルシートとして設定します。

IE11でユーザースタイルシートを設定する方法は、過去記事「価格.com 掲示板をメイリオで見やすくする」を参照ください。


〔IE11版-1列パレット CSS〕



#wrapper {
min-width: 800px !important; }

.ad728 {
display: none; }

.page_entry input[type='text'], .page_entry textarea {
box-shadow: none !important; }

.page_entry #form {
width: 100% !important;
position: absolute !important;
top: 0px;
left: 0px;
padding: 15px 0px !important;
background: #fff;
z-index: 1; }

.page_entry #entryEditHead-new {
border: none !important;
padding: 0 !important;
margin: 0px 15px !important; }

.page_entry .innTable01 {
display: none; }

.page_entry #entryEditHead-new th {
display: none; }

.page_entry #entryEditTitle {
width: 340px; }

.page_entry .alert.alert-red {
position: absolute;
left: 360px;
z-index: 2; }

.page_entry #entryEditCategory {
position: absolute;
top: 20px;
left: 375px;}

.page_entry #entryEditCategory select {
font-size: small !important; }

.page_entry #entryEditCategory option {
font-size: 1em; }

.page_entry #entryEditHead-new tr:nth-child(3) {
position: absolute;
top: 60px;
left: 257px;
z-index: 2; }

.page_entry #entryEditTags span.tags {
width: 125px !important; }

.page_entry #entryEditTags span.tags input {
width: 108px !important; }

.page_entry .entryElement .btn-s {
display: none !important; }

.page_entry #entryEditWrap {
margin: 0px 15px !important; }

.page_entry #entryEditInner {
margin: 0px 0px 15px !important; }

.page_entry #entryEditContents {
margin-right: 155px !important; }

.page_entry #entryEditContents .entryPreview.btn-s {
height: 38px !important;
padding-top: 6px !important;
top: 50px !important;
right: 95px !important;
z-index: 3; }

.page_entry #entryEditContents #preview {
font-weight: bold !important; }

.page_entry .entryTutorial01 {
display: none; }

.page_entry .tabmenu ul, .page_entry .tabmenu a {
padding: 0 !important; }

#_entryContent, #_moreEntryContent {
font-size: small !important;
height: 500px !important; }

#entryContent, #moreEntryContent {
font-size: 1.07em !important;
line-height: 150% !important;
height: 500px !important; }

#exFooterWrapper {
display: none !important; }

.partsWrap#wrapper {
min-width: 0px !important; }

.page_entry #entryEditIframe {
width: 155px !important;
position: absolute !important;
top: 0px;
right: 2px; }

#entryEditIframe iframe {
width: 155px !important;
height: 670px !important; }

#partsImage #droppable {
margin: 15px 5px 10px !important; }

#droppable {
font-size: 13px !important;
color: #fff !important;
background: #4096ee !important;
box-shadow: none !important; }

#partsImage .mod-fileUpload {
margin: 0px 5px 0px !important; }

#partsImage .fileUploadWrapper {
margin: 0 !important; }

#partsImage .optionGroup {
margin: 5px !important; }

#partsImage .optionGroup span {
display: none !important; }

#partsImage .optionGroup select {
font-size: small !important;
height: 26px !important;
padding: 2px 5px !important; }

#partsImage .optionGroup option {
font-size: 1em !important; }

#partsImageContainer {
overflow-y: scroll !important;
margin: 0px 5px 10px !important;
height: 360px; }

#partsImageContainer li {
margin: 0px 0px 10px !important;
width: 122px !important;
height: 80px !important; }

#partsImageContainer li a {
background-size: cover !important;
width: 118px !important;
height: 76px !important; }



●編集枠の下側の「トラックバックURL」記入欄、「みんなの投稿」投稿指定欄、を全く使用しない場合、以下の4項目をスタイルシート末尾に追加すれば、これらの表示を消すことができます。


.page_entry #entryTrackback {
display: none; }

.page_entry #blog2media {
display: none !important; }

.page_entry #entryOptionsPstdate {
padding: 0 !important; }

#sideRakutenMW {
display: none; }




ブログサイト上の画像の配置はアバウトです。 エキサイトは左詰め・中央・右詰めだけ、画面上サイズも一定の規則でリサイズされる等、スマホ版に至っては全くあなた任せです。 編集画面上では画像と文字サイズのバランス等も適当で、まあプレビューまで判りません。

配置を固め尽くしたスキンを造り、編集画面も同様に固めれば、WYSIWYG的なブログ編集がある程度は可能でしょう。(ブラウザ側の環境でズレは出る?) そんな場合に、この編集画面上の画像サイズ調整が必要かもしれません。 でも、ここで採り上げる主な目的は、この調整が編集ウインドウの適応性を拡げる場合があるからです。

平均的に使用する画面拡大率や文字サイズは、ユーザーの環境により幅があるでしょう。 しかし、その人の平均的な設定で編集画面が最も使い良ければ、それにこした事はありません。 編集枠内の画像サイズも、調節出来ればもっと使い良くなるという場合があるかもしれません。

理由があって画面拡大率を異常に大きくしている時は、挿入した画像が拡大されて編集を邪魔をするかも知れません。 下は、ブラウザ拡大率250%、文字サイズ「最大」の編集画面です。(1列パレット使用でハードコピーを縮小しています) この状態は編集枠の画像が文書の編集を妨げています。 場合によっては、ブログ画面上の「実際の見え方」より編集時に「見える行数」が必要な場合があるのです。

b0174191_00251679.png
エキサイトのシステムは、編集枠の画像幅に「400px」の上限を設けて、編集を妨げない様にしています。 この値で普通は過不足を感じませんが、上の例では上限値を「200px」等と書換えれば一気に編集が快適になるでしょう。

編集画面上の画像サイズに関しては、過去記事「画像のページ上と通常編集画面上の表示サイズ」を参照ください。

●オプションとして、「通常編集」画面の画像幅の上限値を変更するCSSを追記します。 これは2列タイプにも使えます。

●最初の方は、参考でエキサイトのデフォルトの様子です。 下が変更を指定するCSSで、ユーザースタイルシートに追記すれば、変更が適応されます。 反対に、ユーザースタイルシートからこの項目を消すか、IEでユーザースタイルシートの適応のチェックを外せば、エキサイトのデフォルトに戻ります。

〔エキサイトのデフォルトCSS〕


img.IMAGE_LEFT, img.IMAGE_RIGHT, img.IMAGE_MID {
max-width: 400px;
margin-top: 15px;
margin-bottom: 15px;
cursor: pointer !important; }



〔編集枠内の画像幅の上限値を 200px に指定するCSS〕


.page_entry #_entryContent img, .page_entry #_moreEntryContent img {
max-width: 200px !important;}





[PR]
by Ataron | 2016-05-29 00:48 | ブログスキンのアレンジ | Comments(0)

編集画面をアレンジする(4)/ エキサイトブログ IE11版-2列パレット

2016年 05月 28日
ネット上のページは、一般にはページの配信者側のデザインで表示されます。 しかし、それを受信者側の好みのデザインで表示させることは原理的に可能です。 Htmlやスクリプト等は書換えられないので当然制限がありますが、ユーザーの望むフォントを適応したり、自分に適したレイアウトに出来れば、これは大変に便利です。 こういう操作は、一般に「User Stylesheet」の適応と呼ばれるものです。

「編集画面をアレンジする」の(1)~(4)で、Google Chrome 環境で実用的な編集画面をデザインして来ましたが、これは User Stylesheet 操作に優れた Chrome ならではでした。 しかし、同様の事をIEで少しだけ齧っていたのを思い出し、IEでどの程度可能か試してみました。 IEで User Stylesheet の利用は「インターネットオプション/ユーザー補助」を使う方法のみに限られます。 これは広域でのフォント指定程度の用途で装備された様です。 種々のサイト個別に指定を指定したり出来ないので、あらゆるページに通用する(予定外のページで機能しない)様にコードを記述する配慮が必要です。


最初に組んだCSSをIE11で適応したものです。(IE11版-2列パレット)

b0174191_19143466.png

●画面上の文字のフォントサイズは、IEの文字サイズ指定に従います。(エキサイトのデフォルトは従わない) これにより、編集画面の表示バランス調整がより細かに幅広く可能です。

●調整範囲を拡げる目的で、ウインドウ幅をデフォルトより狭く調整可能としました。 拡大率150%等で編集中に画像を見易く扱いたい場合、ウインドウを小さく出来ると便利だからです。 その設定のせいで、エキサイトの他の設定画面の段組みが崩れる場合は、単にウインドウを拡げれば普通に戻ります。 配信デザイナーは体裁上で出来ませんが、私は体裁より便利を採りました。

●画像パレットは殆ど元デザインのまま移動をしました。 私の扱いでは2列は幅が無駄で、画像の順序も戸惑いがちですが、これはアレンジコード行を節約しました。

●Chromeと違い、IEではスタイルシートが全てのページに適応されます。 編集ページにアクセスする時は良いですが、全く無関係のページでも、同じセレクタ(例えば"input"とか"textarea"等)が使われているとスタイルが適応されます。 筋違いの指定で無変化の時もあれば、大いに変化するかも知れません。「見栄え」以上の問題はないとしても、想定外は避けたいものです。
編集時ONでそれ以外はOFFがベストですが、エキサイト内でウロウロする時も多く、頻繁に切り替えるのは実用的ではありません。 ブログ「設定」の一部が「編集」なので、これらのページ間で共通したセレクタが使われ、一般のサイトよりこっちの方が誤適応が生じ易そうです。
方策としては、極力セレクタを長く厳密な記述とし、固有の場所以外で適応されない様に用心しました。 また、例えば「編集」の左メニューを消す指定は他の「設定の画面」でも実行されます。(Chromeはその心配が要りません) そんな記述を避けてアレンジをしています。 この理由で「マイブログ」のスイッチは作れません。 他画面でスイッチの場所が変わってしまうからです。

●無駄な表示は無くして、編集がし易く、大きくもコンパクトにも使える様に心がけています。 また、スタイルシートのCSSの設定値を書き換えれば、編集枠の縦幅や画像パレットの上下配置など、好みに変えられます。


以下の枠内のテキストをメモ帳にコピーペーストし、ファイル名を「excite_style.css」等と適当な「.css」ファイルとしてして保存し、ユーザースタイルシートとしてIEに読み込ませます。

IE11でユーザースタイルシートを設定する方法は、過去記事「価格.com 掲示板をメイリオで見やすくする」を参照ください。

上に説明した様に、IEに設定したままでOFFにしない場合、他のサイトのページに反映される可能性が無いとは言えません。 見栄え以上の問題は無いと思いますが、気になればOFFにという使い方になるでしょう。


〔IE版-2列パレット CSS〕


#wrapper {
min-width: 845px !important; }

.ad728 {
display: none; }

.page_entry input[type='text'], .page_entry textarea {
box-shadow: none !important; }

.page_entry #form {
width: 100% !important;
position: absolute !important;
top: 0px;
left: 0px;
padding: 15px 0px !important;
background: #fff;
z-index: 1; }

.page_entry #entryEditHead-new {
border: none !important;
padding: 0 !important;
margin: 0px 15px !important; }

.page_entry .innTable01 {
display: none; }

.page_entry #entryEditHead-new th {
display: none; }

.page_entry #entryEditTitle {
width: 340px; }

.page_entry .alert.alert-red {
margin: 90px 0px 10px 0px !important; }

.page_entry #entryEditCategory {
position: absolute;
top: 20px;
left: 375px;}

.page_entry #entryEditCategory select {
font-size: small !important; }

.page_entry #entryEditCategory option {
font-size: 1em; }

.page_entry #entryEditHead-new tr:nth-child(3) {
position: absolute;
top: 60px;
left: 257px;
z-index: 2; }

.page_entry #entryEditTags span.tags {
width: 125px !important; }

.page_entry #entryEditTags span.tags input {
width: 108px !important; }

.page_entry .entryElement .btn-s {
display: none !important; }

.page_entry #entryEditWrap {
margin: 0px 15px !important; }

.page_entry #entryEditInner {
margin: 0px 0px 15px !important; }

.page_entry #entryEditContents {
margin-right: 200px !important; }

.page_entry #entryEditContents .entryPreview.btn-s {
height: 38px !important;
padding-top: 6px !important;
top: 50px !important;
right: 95px !important;
z-index: 3; }

.page_entry #entryEditContents #preview {
font-weight: bold !important; }

.page_entry .entryTutorial01 {
display: none; }

.page_entry .tabmenu ul, .page_entry .tabmenu a {
padding: 0 !important; }

#_entryContent, #_moreEntryContent {
font-size: small !important;
height: 500px !important; }

#entryContent, #moreEntryContent {
font-size: 1.07em !important;
line-height: 150% !important;
height: 500px !important; }

#exFooterWrapper {
display: none !important; }

.partsWrap#wrapper {
min-width: 0px !important; }

.page_entry #entryEditIframe {
width: 200px !important;
position: absolute !important;
top: 5px;
right: 2px; }

#entryEditIframe iframe {
width: 200px !important;
height: 810px !important; }

#droppable .textL2 {
top: 10px !important; }

#partsImage .optionGroup select {
font-size: small !important;
height: 26px !important;
padding: 2px 5px !important; }

#partsImage .optionGroup option {
font-size: 1em !important; }




●編集枠の下側にある「トラックバックURL」の記入欄、「みんなの投稿」への投稿指定欄、は全く使わないという人が多いのではないでしょうか。 使用しない機能のスペースを整理すると、編集枠が上方に逃げてしまう事が少なくなります。 これは実際の作業に都合が良いものです。

以下の項目をスタイルシートの末尾に書き加えると、これらの項目の表示を消すことができます。


.page_entry #entryTrackback {
display: none; }

.page_entry #blog2media {
display: none !important; }

.page_entry #entryOptionsPstdate {
padding: 0 !important; }

#sideRakutenMW {
display: none; }




[PR]
by Ataron | 2016-05-28 21:20 | ブログスキンのアレンジ | Comments(0)

明石公園 2016.05.26 なぎ

2016年 05月 26日
薄曇りと思っていたら小雨にも降られました。 迎え梅雨とか言うらしいけど。

昼に公園に着いたが、池の水面は凪の様に静か。 ハトの姿は十分程の間、一羽も見えません。 何とも変な雰囲気で、デッキの方へ探しに向かうと西の対岸の休みの樹のあたりに、ハト達を集めているオジサンが見えました。 彼の所に集まっているにしてもえらく少ない様です。 人影の少ないボートデッキで餌やりが終わるのを待って暇つぶし。


少し蒸し暑く、もうすぐ夏なんだと思いながらアイスコーヒーを買い、いつものポイントに戻りました。 そしてポイントで待つこと10分、やっと2~3羽が飛んで来ました。 最初は数羽から、数分後に10羽位に増え、最初のマーカーは左アシ。 そしてパンクが加わり20羽前後で静かな食事タイムです。 パンクは最近手から食べる事を覚え、盛んにベンチに上がって来ます。
b0174191_16244704.jpg

いつもの事ですが、チュンやムクッちが取り巻きます。 パンが無くてメンゴ。
b0174191_16280771.jpg

最終的に20羽前後、手持ちの食事がほぼ無くなった時に左ユビが来ました。 何処かで少数で行動していたに違いありません。 最近、下の写真の白と薄茶のハトを良く見かけます。 「ピンク」としてマーカーに加えましょう。
b0174191_17120621.jpg

今日の数だとマーカーの抜け落ちも多く、良く来ていたダブルも居ませんでした。 アシタはどうしてるのかなぁ?


Panasonic DMC-G3 + G20mm F1.7 で撮影、画像はクリックで拡大表示します。





[PR]
by Ataron | 2016-05-26 16:36 | 鳥さんの写真 | Comments(0)

編集画面をアレンジする(3)/ エキサイトブログ

2016年 05月 26日
前回の「編集画面をアレンジする(2)/ エキサイトブログ」で実現したブログ編集環境をテストしていますが、文書編集時の問題を発見したので若干のコード修正をしました。

問題は、コピーペースト時にフォントサイズ形容が必ず埋め込まれてしまい、過剰にファットなHtmlソースが記述されるという状態です。 これは、「通常編集」のHtml入力支援機能を、私がアレンジしたCSSが変な動作をさせる様に思えます。


問題の状況を説明します。

「通常編集」と「HTML編集」の文書編集枠のフォントサイズを本来の「13px」から「16px相当」に拡大させるCSSは次の項目です。 この指定は Stylist に登録して編集画面に適応されているものです。


#_entryContent, #entryContent {
font-size: 1.6rem !important; }


この指定をした「通常編集」枠で、文字変換して図形文字「■」を書き込み、これをコピペして連続ペーストさせます。
これは「通常編集」枠では下の様になります。





このHtmlソースを「HTML画面」で見ると驚きます。 下の様になっていました。


■<span style="font-size: 1.6rem;">■</span><span style="font-size: 1.6rem;">■</span><span style="font-size: 1.6rem;">■</span><span style="font-size: 1.6rem;">■</span><span style="font-size: 1.6rem;">■</span><span style="font-size: 1.6rem;">■</span><span style="font-size: 1.6rem;">■</span><span style="font-size: 1.6rem;">■</span><span style="font-size: 1.6rem;">■</span>


一回のペーストごとに「 <span style="font-size: 1.6rem;"> </span> 」でフォントサイズ指定をしています。

上記のCSSの影響らしく、それを省いてやると問題は生じないことが判りました。 しかし、編集枠のフォントサイズは、このスキンアレンジの中で重要なポイントで、外すわけには行きません。
入力支援機能がこんな動作をしない様に色々コードを変えて調べると、どうやら「フォントサイズを計算をさせる指定の仕方」が引き金になると判って来ました。


「 font-size: 1.6rem 」「 font-size: 1.24em 」「 font-size: 124% 」等の指定では、みんな上記の様なHtmlが出て来ます。 それに対して「 font-size: 16px 」「 font-size: medium 」等ではHtmlソースは以下の様になります。


■■■■■■■■■■<br>


これが普通のあるべき状態です。 何のサイズ指定も無い「標準」文字入力が必要なのです。

話がややこしいですが、求めている環境は、「通常編集」枠で指定の無い「素文字」が16pxサイズに表示される環境です。 その環境で入力した文字が「素文字」であっても「16pxサイズ指定付き文字」でも、入力中は「通常編集」からは同じ「16px」の文字に見えます。
しかし、ブラウザの文字サイズ変更をすれば「素文字」はそれに従いますが、「16pxサイズ指定付き文字」は変わりません。 単にHtmlソースがファットになるだけでなく、これは問題のある状態なのです。

現在、上記の様に「 font-size: 16px 」「 font-size: medium 」等の「換算の必要のない指定」に改めるしかありません。 ただ「px」の指定では、「編集枠内の編集時に見えるフォントサイズ」がブラウザの文字拡縮「極大・大・中・小・極小」に従わなくなります。 これを避けるには「medium」「small」の指定方式しか選択の余地がない様です。 ただ、編集画面のスキンアレンジ後の環境の話で、既に「自由にカスタマイズできる」わけで、ここで「px」指定を避ける理由は強くありません。

エキサイトによる編集画面のデフォルトデザインは「13px」指定です。 IEやChrome等の文字拡縮に応じないので、全体画面を拡大して使っている人は少なくないでしょう。 Edgeはその機能自体がないので、ますますそういう人が増えそうです。 そうなると、サイドメニューやタイトル枠が無駄に大きく、何か使いがっての悪い編集画面と付き合わざるを得なくなります。 いや、そう私が感じて来たから、この編集画面のレイアウトに拘ったわけです。

Html入力支援機能に関する問題は色々と気になりますが、今回の問題はこれで解決されそうです。 ブログ編集画面のスキンに関しては、関係個所を修正しておきました。



[PR]
by Ataron | 2016-05-26 00:45 | ブログスキンのアレンジ | Comments(0)

編集画面をアレンジする(2)/ エキサイトブログ Chrome版-2行タイトル

2016年 05月 25日
「編集画面をアレンジする(1)/ エキサイトブログ」で、文書編集画面のレイアウトをカスタマイズしたのですが、気に入って調子に乗りました。 もっと徹底的にアレンジしてやろうというわけです。 このカスタマイズは、ブラウザにフィルターをかける様な手段ですから、ブラウザとそれに特化したプラグインアプリが必要です。

私が使用しているのは、Google Chrome と Stylist という組み合わせです。 IEや他のブラウザにも同等の事を実現出来るプラグインがあるかもしれません。 もしそんなプラグインが利用できるなら、ここに紹介するコードがそのまま使えるでしょう。(Edgeはそういう環境が現在未完成とのことです) Stylist の扱いについては、「編集画面をアレンジする(1)」を参照ください。


前回は、Stylist がどの程度の量のコードをこなせるか判らず、アレンジ項目を節約して4項目に抑えました。 しかし、今回は、かなり細かに調節したので20項目以上と、ずいぶん増えています。 これぐらいの行数だと痒い所に手が届くアレンジが出来ます。

下が編集画面の様子です。 ブラウザ拡大率100%時(フォント中)の実寸ハードコピーです。

b0174191_03374806.png

●「タイトル枠・カテゴリ・タグ枠」と「本文編集枠」をウインドウの上側左に寄せ、「画像パレット」を上方にシフトしています。

●タイトル枠等は枠名札を省き、配置を変えて詰めています。 テンプレート枠は使用頻度が少ないので省略、元の4段を2段に減らし省スペース化しました。(テンプレートが必要な時は Stylist を一旦OFFにして使用)

●「通常編集」「HTML編集」「プレビュー」のスイッチを「編集ツール」と同枠に入れて省スペース化。 機能説明の(?)小ボタンを3ヵ所、HTML編集の自動改行の「NEW」表示を削除。

●省スペースで出来た余裕を「本文編集枠」の縦幅に充てています。「編集ツール」が隠れた時に、それを出そうとして、上方へスクロールさせ過ぎることがありませんか。 編集枠の上部を詰めると行き過ぎが減ります。 また、編集枠の縦幅が広いと、枠内スクロールが減って編集枠自体が移動する事も減ると思います。

●「タイトル枠」「本文編集枠」はフォントサイズ1.6rem(ブラウザの「フォント中」設定時で16px)として、本来の13pxより見易くしました。 「フォント極大」は少し窮屈ですが、他のサイズもOKです。 スキンをカスタマイズすれば、任意のフォントサイズのバランスを得られます。

(注)エキサイトの編集画面のフォントサイズ指定は、「 html { font-size: 62.5%; } 」を基準にする一般的な方法です。 ブラウザの標準フォントサイズは16pxですから、その62.5%(つまり10px)をhtmlの標準サイズ(1rem)にしています。 この「rem単位」を使い、10px=1rem、13px=1.3rem、16px=1.6remという覚え易い換算で、各所の文字サイズを指定しています。 rem単位は入れ子になっても値が乗算されず、扱い易い指定方法です。

〔追記〕ここのサイズ指定の仕方が原因して、無駄なサイズ指定がソースに入る事が判りました。 詳しくは「編集画面をアレンジする(3)」を参照ください。 この理由で、文字編集枠の文字サイズ指定は「mediun」「small」等の指定方法に改めています。(下記のコードは修正済です)

●「マイブログ」のスイッチは、新しいタブでマイブログを表示する場合に便利です。 Chromeなら新しいタブを開いて自分のブログを指定して開いても良いですが、ひと手間省けます。 編集時に自分の記事を参照する時は便利です。 ただ、このスイッチ、編集の保存終了した場合に、終了後に表示される画面の変な場所に残りますが、実害はありません。

●タブ選択の右端に「タブのヘルプ」のスイッチ一部がはみ出してみっともないが、スイッチとしては機能します。 オプションのCSSで削除可能です。

●コードが多いので編集画面を開く時に少し待たされる様な気がしますが、実際は極僅かな差ではと思っています? 画像管理パレットの読込みが遅れる様ですが、パレット表示前でも編集を始められます。

●案外と重要な効果かもしれませんが、作業を邪魔しがちなアドが結果として隠れてしまいました。 ウインドウ画面がすっきりするのは良いことです。

●このバージョンは「通常編集」時の画像サイズと文字の比率を考慮していません。 エキサイトは元々そういう設計で、「出来上がりはプレビューしてね」と言ってます。 ただ、これはもう少し改善の余地があるかもと考えています。


Stylistに登録する CSSのコードです。


#loginUser {
display: none; }

.ad728 {
display: none; }

form#form {
position: absolute;
top: 0px;
left: 0px;
width: 100%;
background-color: #fff; }

#entryEditHead-new table.innTable01 {
display: none; }

#entryEditHead-new {
margin: 10px 5px; }

#entryEditHead-new th {
display: none; }

#entryEditTitle {
font-size: medium; }

#entryEditCategory select {
font-size: 1.3rem;
padding: 0; }

#entryEditTags {
position: absolute;
top: 63px;
right: 215px; }

#entryEditTags span.tags {
width: 160px; }

#entryEditTags span.tags input {
width: 140px; }

#entryEditInner {
margin-right: 0px; }

#entryEditContents {
margin-right: 220px;
margin-left: 15px;
position: relative; }

.entryPreview.btn-s {
top: 8px;
right: 12px !important;
z-index: 10; }

input#preview {
font-size: 1.3rem;
font-weight: bold; }

#editorSwither {
position: absolute;
top: 15px;
right: 105px; }

#editorSwither a {
padding: 0; }

.entryTutorial01, .entryTutorial02, .entryTutorial03 {
display: none; }

#new_icon {
display: none !important; }

#_entryContent {
font-size: medium;
height: 600px; }

#entryContent {
font-size: medium;
line-height: 150%;
height: 600px; }

#entryEditIframe {
position: absolute;
top: 10px;
right: 5px; }

#entryEditIframe iframe {
height: 775px; }

#entryOptions .head-h3 {
margin: 30px 0px 10px; }

#entryOptionsPstdate, #entryOptionsPpenflag {
margin-left:20px; }

#exFooterWrapper {
display: none; }

#myblogBtn {
position: absolute;
top: 15px;
right: 270px; }

#myblogBtn a {
background: none;
text-indent: 0px; }




以下はオプションのCSSです。 枠内の各項を上の末尾に追記することで、それぞれの環境が追加されます。

●タブ指定枠の「ヘルプ」、画面下方の「トラックバックURL」記入枠、「みんなの投稿」投稿枠を消すためのCSSです。 画面下方が短くなり不用意にスクロールする事が減ります。


.entryElement .btn-s {
display: none; }

#blog2media {
display: none; }

#entryTrackback {
display: none; }

#entryOptions .head-h3 {
margin: 30px 0px 10px; }

#entryOptionsPstdate {
padding: 0; }

#sideRakutenMW {
display: none; }




●以下は、More愛用者の為のオプションです。

「More入力枠」のフォントサイズを「本文編集枠」(1.6rem)と同じにするオプションです。「More」機能を使用する場合は以下の2項目を追加します。


#_moreEntryContent {
font-size: medium;
height: 600px; }

#moreEntryContent {
font-size: medium;
line-height: 150%;
height: 600px; }



「More入力」で編集する場合は「画像パレット」が離れて大変に不便です。 以下の項目を追加すると画像パレットがスクロール固定されます。 ウインドウ全体をスクロールして下方の「More編集枠」を上げると、「画像パレット」を横に持って来ることが出来ます。


#entryEditIframe iframe {
position: fixed; }





[PR]
by Ataron | 2016-05-25 07:01 | ブログスキンのアレンジ | Comments(0)

改善されたのか? Html入力支援機能 / エキサイトブログ

2016年 05月 23日
最近気になっているのが、Htmlソースに「<div></div>」が過剰に挿入される事です。 「HTML編集」の画面を開かないと、これには気付かないと思いますが、「通常編集」の改行で分けられた「文」は、みな1文ずつ「div」要素として扱われます。

この様なHtmlの生成の仕方は最近になってからのものです。Chromeを使って「通常編集」にアクセスした場合の様です。 実際の様子の一例として「通常編集」で以下の文章を入力したとします。

これは一行の短い例文です。
これは一行の短い例文です。

一行飛ばして再び短い例文です。

このHtmlソースを開けて見ると

<div>これは一行の短い例文です。</div>
<div>これは一行の短い例文です。</div>
<div><br></div>
<div>一行飛ばして再び短い例文です。</div>

と展開されるのです。 この過剰な「<div>」は、Html入力支援機能が働いた結果です。

「<div>」は構造タグで、オールマイティに各種要素を内包出来て、Html入力支援機能が通常編集から入力されてくる文を扱う際に便利な気がします。 以前は「<p>」を使って文を詰めていたと思うのですが、段落タグ「<p>」は内包出来る要素に制限があり、タグの開き結びの自動入力修正の結果で文法エラーを出す可能性を含んでいたはずです。(追記:IEで「通常編集」にアクセスした場合に、Chromeと異なり「<p>」が挿入されることが判りました。)

このあたりに関係する過去記事の「段落の背景色付け」を参照ください。 当時は自動入力修正で勝手に入る「<p>」タグで、困った事が何度かありました。 「<div>」を使うかぎり「<p>」の様に段落による行間が開くことはないので、この意味では扱い易いものです。

ただ、上のHtmlソースの「<div>」は、とても無駄な記述に感じます。 普通なら、下の様なソースですっきり書けるのですから。

これは一行の短い例文です。<br>
これは一行の短い例文です。<br>
<br>
一行飛ばして再び短い例文です。<br>

以前は、HTML編集に入って<p>タグの整理に励んだものですが、今度は<div>タグ整理をすることになったわけです。 画像のデータ量に比べたら、テキストのHtmlソースが少しぐらいファットになったところで、大したことはないと言えばそうですが、もう少しすっきりと展開が出来ないものでしょうか。


〔追補〕
他のテキストファイルなどからテキスト内容を持ち込む場合、HTML編集画面にペーストするとファットにならずに済みます。 その際、「自動改行」のON/OFFにより結果が異なり、普通はONが簡単と思われます。

結局、エキサイトのシステムに改善があったのではなく、IEとChromeでは「通常編集」枠の挙動が異なるという問題でした。 詳しくは、後の記事「編集枠のペースト時の挙動の謎 / IE11」「編集枠のペースト時の挙動の謎 / Chrome と Edge」を参照ください。



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

ブログの本文フォントサイズの考察

2016年 05月 22日
ブラウザ画面で、ページの主要な文書内容に使われるフォントを仮に「本文フォント」と言うことにします。 新聞なら見出しではなく記事本文のフォントが「本文フォント」というわけです。

もし、文章をちゃんと読もうと思った場合、この「本文フォント」を見やすい様に、ブラウザのズームを調節すると思います。 あるページの「本文フォント」が大きく、そこからそれが小さな他ページに移った場合、余りに落差があれば戸惑い、ブラウザの調節をせざるを得ません。 最もそういう確率の少ない「本文フォント」のサイズは、結局は最も多数派のサイズという事になるでしょう。

ブログのスキンアレンジやブログ編集画面のアレンジを手掛けていると、他の人から見てどう見えるか、他の人が使ったら使い良いのか、と言う事を考えます。 この事に関係して、最も多数派の「本文フォント」のフォントサイズを調べたのですが、「13px~16pxが最も多いと言われている」程度のことしか判りませんでした。 私は現在のブログスキンの「本文フォント」のサイズを16pxにしていますが、これが適当なのかが気になり、色々なサイトを実際に調べて見ました。


実際に私が「お気に入り」に設定しているサイト、頻繁にお世話になるサイト、公的サイトやすぐ浮かぶ有名サイトなど、一般の「各種サイト」を先ず調べました。 また、それとは別にブログシステムを基盤にした「ブログサイト」を調べ、その結果を集計したのが下のグラフです。
b0174191_20282616.png
母数が足りていない気がしますが、「各種サイト」は13pxから16pxに大きな山をなし、もっと調べるとなだらかな幅のある山になりそうです。 端数サイズも多く、複数サイズを使う事が多く、下の「ブログサイト」に比較して大きいサイズを普通に使うという傾向を感じます。

「ブログサイト」の方は、私の各種ブログリンクを端緒に調べて行きました。 こちらは、13px(small)が多く、各種サイトではあまり見られない12pxという小さなサイズも散見されます。 ブログ各社が提供する公式スキンの指定がそのまま反映され、エキサイトもこれが殆どです。 他社ブログには、サイズが色々分散して、簡易なアレンジ機能があるのかと思うブログもあります。 サイズを指定できる人は大きめのフォントを選択する傾向があり、それが16pxを中心とした小さな山を作っている様です。


私のメインモニターでの話ですが、13px(small)の「本文フォント」の画面は、ブラウザの拡大率「150%」が必要です。 ドットの少ないサブの汎用モニターでも「125%」が必要です。 16px(medium/ブラウザデフォルト)の「本文フォント」なら、メインで「125%」、サブで「100%」という感じ。 なんでエキサイトは小さい文字が好きなんだろうと、つい思ってしまうんです。

安い汎用モニターでなんの拡大もしないで、普通に読める16pxあたりが本来じゃないのかなぁと、思う今日この頃。



[PR]
by Ataron | 2016-05-22 22:40 | ブログスキンのアレンジ | Comments(0)

洲本 久しぶりに訪れる

2016年 05月 21日
友人と連れ立って洲本に行って来ました。 天候は晴れて絶好の行楽日和でしたが、私は初夏風邪をひいていたらしくアップアップ。 それでも素敵な場所、写真を見返して思います。 また行くぞ。

洲本に行くには、舞子駅で電鉄から高速バスに乗換えが一番便利です。 バス路線は種類が多くて複雑ですが「洲本バスセンター」行きを確かめれば、間違いなく辿り着けます。
b0174191_11200913.jpg


洲本に着いたら海岸に出ます。 海に近付くと壊れたモノが多く、海に来たと思う。
b0174191_11275174.jpg

祭日ではないので人の居ない海岸でした。 しばし海岸で飲食をし^^; 日陰で休むと素晴らしい風が吹いていました。 気が済むまで休んでから洲本の街へ出かけました。 商店街は海からすぐ近くです。
b0174191_11320650.jpg

最初にここに来たのは1970年代の半ば、三洋電気の保養所が現場の一泊仕事があり、この商店街の傍の旅館に泊まった記憶があります。 記憶が断片化して怪しいかぎりですが。 それから何度か来ましたが、商店街はシャッターが降りた店が目立ち、以前はこんなじゃなかったのにと思う。

商店街の山側の路を歩いて、風化した看板に出会う。
b0174191_11514810.jpg
友人と一緒にカシャカシャ。 オジサン達はちょっと勘違いしていたのだが、調べると「キリンビール」と言ってたのを「キリンラガービール」に改めたのが1989年からで、この看板は少なくともそれ以降のもの。 潮風で傷みが早くよけいに旧く見えるのかもしれない。 ちなみに、他社ビールの殆どが製法上はラガービールだそうで、キリンはそれを商品名にしてしまったらしい。

その近所の民家の玄関に、ツバメの巣を見つける。 球状のガラスシェードの真上に、冠の様に巣を造ってます。 こういう造り方を見たのは初めてです。
b0174191_12100103.jpg
最初は不在と思って撮ってたら主が顔を出しました。


何か食べようと海岸の方に戻ると、バスターミナルの周辺は、古いレンガ造りを利用した洒落た建物群になっているのに気付きました。 洲本アルチザンスクウェアと称し、旧鐘紡工場を改築したそうです。
b0174191_12401943.jpg
この一角で食事とビール、オジサン達は樹の下でハト達と遊んでいる内に寝てしまったのですが、とても良い所らしいので建物の中に入られることをお勧めします。(入らずに寝るなんて僕らだけか)

そんなこんなで、島に渡ってあっけなく帰って来たのですが、淡路島はとても好きなところです。 若い頃の「夏休みの時間」が、いつもそこにある様な気が、私はするのです。


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






[PR]
by Ataron | 2016-05-21 12:52 | 単なる写真 | Comments(0)

編集画面をアレンジする(1)/ エキサイトブログ

2016年 05月 18日
エキサイトの編集画面の幅が狭いと感じられたことはないでしょうか?

PCの環境は様々、ユーザーの傾向も様々、充分だという人もあれば、狭くて書きにくいという人もいるでしょう。 私は後者なんです。 私の自然と思われる書き込み枠の幅には、どうも足りてない様に感じて仕方がありません。
で、ちょっとChrome Developer Tools(IEやEdgeではDOMになります)を使って、編集画面の構成を調べました。 文書編集画面もブログの表画面も、ブラウザがエキサイトのデータを表示している点では同じです。 スキン編集でブログの表示構成を調整する要領で、編集画面の構成をアレンジ出来るのではと思って試してみると、これが上手く行きました。



編集画面アレンジの目途がついたのですが、アレンジを編集画面を開くたびに適応させるには、特別なアプリが必要です。 Google Chrome は、こういう事を簡単に実現できるアプリが豊富にそろっていて、私は「Chrome Stylist」というフリーのアプリを Chromeに入れてます。

  Chrome Stylist の入手先(Chrome専用アプリです)

このアプリは、適応先のURL(この場合はエキサイトの編集画面です)と、適応させたいCSSを登録してやると、そのURLを開くたびに自動的にCSSに沿ったアレンジを実行してくれる、便利なアプリです。 以下に、これを使った編集画面のアレンジ方法を紹介します。



アレンジを施した後の実際の編集画面は以下の様になります。
b0174191_03053384.png

 アレンジの要点

①画像管理パレットを左メニューの上に移動 空いたスペースに文書編集枠を拡張
➁タイトル等の記入枠 通常編集枠とHTML編集枠の文字サイズを13pxから16pxに拡大

アレンジの結果、左側のメニューの一部が押せなくなりますが、文書編集時にメニューを押すことは先ずありません。 普通に「設定」を開いた場合はアレンジは適応されず、メニュー操作に困ることはありません。
アレンジ可能な部分は他にも多いが、上記のアレンジだけでもずいぶん快適な環境になったと私は感じます。



Stylist をChromeにセットする方法は、Chromeで先のリンク先に行き導入ボタンを押すだけで、とても簡単にセットされます。 セットされるとChromeウインドウの右上にStylistのアイコンが出来るので、これを右クリックして下図の様に「オプション」を選択します。
b0174191_03553240.png

Chromeに下の様な新しいウインドウが開くので「Styles」のタブを選択します。
b0174191_03555065.png

下図の様に、左下の「Add New Style」を押します。
b0174191_16162895.png

下の様な登録画面が出るので、これに新しいスタイル指定の登録をします。
b0174191_17435926.png

➂の枠に適当なスタイルの名前を記入します。仮に「 Excite 」としました。

④の枠にエキサイト編集画面のURLを記入します。
   URLは「 http://userconf.exblog.jp/entry/ 」です。

➄の枠に、下のCSS項目を記入します。( 枠内のテキストをコピーペーストします)

#entryEditContents {
margin-right: 0px !important; }

#entryEditIframe {
position: absolute !important;
left: 10px; }

#_entryContent, #entryContent {
font-size: 16px !important; }

#entryEditHead-new {
font-size: 16px; }

⑥最後に「Save」を押すと、そのボタンのすぐ右側に「Saved!」と確認が表示されます。 これで、この画面での記入内容が登録されます。
b0174191_16213155.png

一旦、Chromeを開きなおして、エキサイトの編集画面に入って見ます。 このページの最初の画面の様にアレンジが適応されていればOKです。 CSSによるアレンジは、データ表示のスタイルを変更するもので、データ自体に影響は生じません。 万が一間違いや不具合があったところで、このStylistで登録したスタイル指示を削除すれば元の表示に戻ります。

スタイル登録の取り消し、スタイルの一時的な停止、スタイル内容の更新など、先の登録画面を出して、いつでも自由に行えます。 このアプリでのCSS操作はラフな実験感覚で行えます。



上記で登録したCSSの簡単な説明です。

第1項 文書編集枠の右方向いっぱいに拡張
第2項 画像管理パレットの移動配置
第3項 通常編集枠とHTML編集枠の文字サイズを16pxに指定
第4項 上部のタイトル等記入枠の文字サイズを16pxに指定

第3項、第4項の文字サイズ16pxは、必要に応じてCSS項目を書換えて変更可能です。

文書編集枠の高さを増したい場合、以下のCSS項目を追記します。 内容は600pxの指定になっていますが、この数値は自環境に適した値に書換え可能です。

#_entryContent, #entryContent {
height: 600px !important; }

下は上部記入枠でカテゴリ選択枠のフォントのみ小さく、これを16pxに改善するCSSです。

select {
font-size: 16px !important; }



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

明石公園 2016.05.16 雨が近付いていた

2016年 05月 16日
月曜、昼から降るという予報で、少し早めに出かける。 公園に着いたのは昼前、すでに湿った風が吹き始めていました。

いつものポイントあたりで餌をふるまう人がいたらしく、北岸から眺めていた私には、なかなかハト達の動きが見えませんでした。 足元の緑がやけに魅力的で、ちょっと撮影。 もうシロツメ草の季節になりました。
b0174191_21511711.jpg
池の北岸の芝地には色々な草が育って、ふかふかとした歩き心地です。 雨を気にしながら池の上を眺めていると、急にハトの群れがポイントあたりから飛び出し、ボートデッキに移動しました。 彼らが私を見つけてくれないかと思っていると、一羽が勢い良くこちらに向かって飛んで来ます。 きっと左ユビ、そう思った時にはもう地上に降りて、その通りだと判りました。

彼は、先日と同じ服装なので判ったのだろうと思います。 それにしても、左ユビには他のハトにないものを感じます。 少し遅れて他のハト達が集まって来ました。
b0174191_22042108.jpg
食事を撒くと草の間に小さな種子が落ちて、ハト達には少し食べ難い場所だったかもしれません。 数はおよそ30羽ほどで、他のマーカーは、パンクと左アシです。
b0174191_22064852.jpg
雨が来る前に食事を配って、私は静かな公園を後にしました。


Panasonic DMC-G3 + G14mm F2.5 で撮影、画像はクリックで拡大表示します。




[PR]
by Ataron | 2016-05-16 22:11 | 鳥さんの写真 | Comments(0)