Studio TA Subsite の案内とお知らせ

カテゴリ:PC環境(ハード/ソフト)( 71 )

「Stylus」の不具合修正が進行中

2017年 12月 06日

連日のアップデート


私自身の作業に係るので毎日ウォッチしているのですが、今朝も「1.1.7.4版」のアップデートが行われました。 やはり、複数セクションの先頭しか表示されない不具合に陥り、再インストールが必要でした。

複数セクションが扱えないのは致命的な問題ですから、この不具合はそのうち解決されると思いますが、どの程度まで不具合が認知されているのか、成り行きを知りたくなるのは人情です。


具体的な情報がFirefox版にあった


当初は Chrome / Firefox 版の両方で管理画面の問題が生じていたのですが、Firefox版はすぐ不具合が解決された様に見えました。 Chrome版は複数セクションの問題が残り現在に至っていますが、作者のメインサイトでは、連日行われる修正アップロードの内容を見つける事が出来ませんでした。(何処かに書かれているのかも知れませんが)

ところがたまたま、余り見ていなかった Firefoxのアドオン配布サイトを覗くと、今回のアップデート内容がしっかり書かれていました。

下はそのハードコピーですが、ここ数日の思いあたる内容が書かれています。

a0349576_14165123.png

「style name wasn't saved, which broke style manager」
編集画面でスタイル名を変更しても反映せず、そんな事をしている内に、管理画面の全登録スタイルが空白になる不具合。

「saving of global sections was broken」
不具合が生じると、単セクションに試験的にセクションを追加して複数セクションにすると、元に戻ってしまいます。 そもそもChrome版では複数セクションが表示できない状態になるのですが。


Firefoxはβ版なのか?


当初はFirefox版はβ版の扱いでしたが、最近はβ版なのか正式版なのかが曖昧になっています。 Firefoxのアドオン管理画面では、β版の表示が既にありません。 そして、Firefox版とChrome版は、現在は全く同じバージョンナンバーに統一されています。

今回の不具合については、本来はChrome版として報告してほしい事が、Firefox版のページに詳しく載っている点が良く判りません。 私がFirefox版の不具合を詳しくテストしていなかっただけで、実際は同様の問題があったのかも知れませんが。


不具合はすべて認知され改善されつつある


いずれにせよ、Chrome版で私が困っている事が全て書かれているので、作者が問題をすでに認知している事が判り、解決は近いと思われます。

また、バージョン履歴の12.04の「1.1.7.3版」では、私が問題にしていなかった他の多くの修正を扱っています。「1.1.7.1版」前後のアップデートは新機能を多く追加していて、それらの問題修正をしていた様です。

「Stylus」は Chrome版 Firefox版 Opera版 の3種を展開しています。 個人で展開するのはかなりの労力が必要でしょう。




この記事はカテゴリ「スキン編集」にトラックバックしています。



[PR]
by Ataron | 2017-12-06 13:55 | PC環境(ハード/ソフト) | Comments(0)

「Stylus」の再インストール手順

2017年 12月 05日

自動アップデートによる不具合


2017.12.03 Stylus ver 1.1.7.2 のアップデート以降、編集画面で複数セクションの後方セクションが表示されない不具合が発生しました。 これは Chrome版 Stylus に限った問題で、「Stylus」のアンインストールと再インストールで改善する事が判っています。 しかし、12.05 ver 1.1.7.3 の自動アップデートで再発し、ふたたび再インストールが必要になりました。

スタイル編集をしないユーザーには影響が無さそうですが、編集するユーザーにとっては自動アップデート毎に再インストールが必要で、この様な状況が当面続きそうです。 そこでこの機会に「Stylus」の再インストール手順を纏める事にしました。



インストールしていたスタイル群を保存する


それまでに「Stylus」にインストールしていたスタイル群を保存します。 管理画面のメニュー「バックアップ」の 「スタイルをエクスポート」を押します。

a0349576_14433779.png

Chromeウインドウの下端にダウンロード枠が表示され、エクスポートしたファイルが左端に表示されます。「v」マークをクリックして 「フォルダを開く」を押します。

a0349576_14454077.png

ウインドウの「ダウンロード」フォルダーが開き、その中にエクスポートしたファイルが表示されています。

a0349576_15071174.png

デフォルトで判りやすい「stylus_xxx」のファイル名になりますが、私はFirefox版「Stylus」との混同を避けるために「Chrome」の文字を追加しています。 バックアップしたファイルを確認したら、エクスポートは完了です。



Stylusの環境を確認して控えておく


「Stylus」自体の環境設定で再現が必要なものは、そう多くないでしょう。

◎「管理画面メニユーのオプション」を確認。 デフォルト設定を変更しているものがあれば、スクリーンショットなどで控えておきます。

a0349576_16055948.png

◎「編集画面メニユーのオプション」を確認。「書式整形」の設定も忘れない様にチェック。

a0349576_16091082.png



Stylusをアンインストール


Chromeの拡張機能の管理画面に行き、「Stylus」の項で 「Chromeから削除」を実行します。

a0349576_16283711.png

この後、全ての Chromeウインドウを一旦閉じて Chromeを再起動します。



Stylusを再インストール


「Stylus」を 以下のChromeのストアから再インストールします。



インストール後は「Stylus」の環境を再構築します。

◎スタイル群を元通りに戻します。 管理画面のバックアップの 「インポート」を押します。

a0349576_16362641.png

先ほどエクスポートしたファイルを選択して「開く」を押します。

a0349576_16523318.png

下の確認画面が表示されるので、インストールしていたスタイル群に間違いがなければ「OK」を押します。

a0349576_16572383.png

◎「Stylus」の各オプションを、控えを元にして設定しなおします。

以上で再インストールは完了です。




この記事はカテゴリ「スキン編集」にトラックバックしています。



[PR]
by Ataron | 2017-12-05 17:42 | PC環境(ハード/ソフト) | Comments(0)

活発に更新される「Stylus」 2017.12 トラブル

2017年 12月 04日

Stylus ver 1.1.7.1 の問題


拡張機能「Stylus」は、私が多くの恩恵を受けているブラウザアドオンです。 毎日の様に使用するのですが、12.03の夜からトラブル発生。

新しいスタイルを作成すると、管理画面でそれまでの登録が全て見えなくなります。 実際の動作、ブラウザ表示へのスタイル適応機能は、それまでと変わらないので、自分でスタイルを作らないユーザーは気付かないかも知れません。 しかし、私にとっては何も出来なくなり、Stylusの再インストールや、バックアップした登録スタイルの呼び戻しなど、焦りました。

「新しいスタイルの作成」「スタイル名の変更」などが出来ない状態で、ネット上には未だ報告もない様子でした。 これを書いているのも、その目的があります。



原因はUSERCSS関連らしい


管理画面を眺めると、「Stylus」のバージョンアップがあった様で、「フィルター」「新しいスタイルを作成」に「Usercss」関連の項目が増えています。

管理画面

a0349576_11505450.png

編集画面

a0349576_11512003.png

この「Usercss」の意味は私にはまだ良く判りませんが、「スタイルの記録形式」を言っている様です。

「Mozilla形式」を例にすると、「Mozilla 形式のコードは userstyles.org に投稿することができ、従来の Stylish for Firefox でも使用できる」と説明されています。「Mozilla形式」の内容は「CSSコード」と「適応先内容」を梱包したものです。 この梱包の形式を統一する事で、拡張機能の時代や種類にかかわらず、ユーザーがスタイル資産を受け継いだり、公開したり、交換できる様にしたものと言えます。 簡単に言えばスタイルのファイル形式ですね。

「Usercss」も、リンク先のサイトを見と、そういう形式の新しいものを「Stylus」で独自に始めている様に見えます。 私は、この評価や使用は、先の課題です。

ただ、この機能への対応が、今回のトラブルの元らしい。「フィルター」にこの項目が追加され、スタイル管理に「Usercss」のフラグが付いたのは間違いなく、この過程で登録スタイルのリストの動作が不完全なままのバージョンを提出したのでしょう。

かなり荒っぽいアップデートですが、メーカーでは無いですから、こんなものなのかも知れません。



「Stylus」のアップデートの設定


作業の途中で不具合に気付いたので、「いつのまに?」と思って調べたのですが、Chrome版には拡張機能「Stylus」自体のアップデート設定がありませんでした。

下はChromeの拡張機能の管理画面の「Stylus」に関する部分です。

a0349576_11515774.png

ここに「Stylus」のバージョン表示が有り、今朝12.04には「1.1.7.2」とバージョンが更新されていました。 これは、自動的に更新される様で、更新を手動にする事は出来ない様です。(ただし、Firefoxのβ版には更新の設定項目があります)

「1.1.7.2」の更新内容を確認すると、「新しいスタイルを作成」でリストが空白化する問題は解決していました。 また「スタイル名」を変更して登録する事が可能に復旧しています。

ただ、スタイルに複数セクションがある場合、第1のセクションしか表示されない状態で、私の場合は複数セクションが普通なので作業がストップしたままです。 これに関しては、まだ作者が気付いていない可能性があり、下手な英語でコメントを送りました。

〔追記〕2017.12.04
夕方、サポートサイトで返事を読んでいると、周囲のコメントで、最初の「空白化」について書いている人がいました。 そのやりとりに再インストールで解決したとあり、私も「1.1.7.2版」を再インストールしてみました。 最初より落ち着いて、今度はChromeやPCの再立ち上げもしたところ、すっかり問題が解決しました。 最初は上書きインストールだったので、これが良くなかった様に思えます。

〔追記〕2017.12.05
再び「1.1.7.3版」にアップデートがあり、複数セクションの場合に先頭セクションしか表示されない不具合が再現しました。 当面、アップデートによる再発が予想されます。 症状正常にする方法は以下です。

●「Stylus」を一旦 Chromeより「削除」→ Chromeの再起動 →「Stylus」の再インストールで正常になります。

●元の環境を維持するため、管理画面の「バックアッブ」で「スタイルのエクスポート」をしてから「Stylus」を削除し、再インストール後に「スタイルのインポート」をする事をお勧めします。

この経験から「Stylus」の再インストール手順を纏めました。 以下を参照ください。



Chrome管理画面のオプション


ついでですが、Chrome版のオプションについて。「Stylus」のオプションは「管理画面」「編集画面」にもあってややこしいが、「Chromeの拡張機能管理画面」に表示される「Stylus」のオブションに関してです。

●「Chromeの拡張機能管理画面」は「 chrome://extensions/ 」をChromeのアドレスバーに入れると表示されます。 あるいは「Stylus」の「{S}」アイコンの左クリックで「オプション」を押して開く事が出来ます。

●この画面が開いたら、もういちど「{S}」アイコンを左クリックして、「すべてのスタイルをオフにする」をチェックします。

a0349576_11561645.png

●この画面の「Stylus」の項に戻って、下の「オプション」を押します。

a0349576_11515774.png

●これで下図のオプション画面が表示されます。

a0349576_11572684.png

この画面の「更新」は、「Stylus」の管理画面にある「全スタイルの更新をチェック」と同じ意味で、「userstyles.org」からインストールしたスタイルの更新に関しての設定です。 つまりこれは、拡張機能「Stylus」自体の更新に関してではありません。



活発なアップデート


今回のアップデートは少し荒っぽかったのですが、私自身もスタイルを公開していて、アップデートして後から不具合を見つけて慌てて再アップデートする事が、ちょくちょくあります。 アップデートの際はもちろん確認作業はしますが、簡単なCSSのデザインですらそうですから、スクリプト等のプログラムとなると、複雑さは想像がつきます。 結局、今回は1日前後で修正版が出ていたという事の様です。

個人や小数で無償で頑張ってる人達を応援したい気分こそすれ、咎める気持ちは全く生じないものです。 今回、サポートにコメントすると、すぐに返事がありました。 とても元気な環境で「Stylus」が育てられている様です。




この記事はカテゴリ「スキン編集」にトラックバックしています。



[PR]
by Ataron | 2017-12-04 12:10 | PC環境(ハード/ソフト) | Comments(0)

縦スクロールバーの謎(Chrome)

2017年 11月 24日
 「overflow」が変な扱われ方になった? 

ブログのHTML編集枠に下の枠内のHTMLを記述すると、「■■」のある文字列を折り返しをしない1行で、背景が灰色のブロック内に表示するという事になります。(実際のHTMLは改行無しの数珠繋がりです。

<div style="overflow: auto; width:400px; padding: 0 20px;background: #ddd; border: 1px solid #aaa;">
<span style="white-space: nowrap;">
■■■■■■■ これはサンプル ■■■■■■
</span>
</div>

このHTMLで、囲みの<div>は400pxの幅で、それより幅の短い文字列ではスクロールバーが表示される事はないはずです。

■■■■■■■ これはサンプル ■■■■■■

ところが実際は縦スクロールバーが出る事があります。 もしChromeをお使いでしたら、ブラウザの拡大率を125%等の倍率にして、このページを見てください。
文字列をもっと長くしたものが下です。

■■■■■■■ これはサンプル ■■■■■■■■■■■■■■■■

横スクロールバーはHTMLの通りですが、今度は縦スクロールバーが出たり、出なかったり。 なんじゃこれは。


 ブラウザによる見え方の違い 

上の表示はブラウザによって異なる様です。「スクロールバーの表示の仕方」がブラウザによって異なる仕様なのは、昔から皆を悩ませて来た問題ですね。 今回はそれは別件なんですが、これを見ている人が何を言ってるのか判らなくならない様に、まずハードコピーで上の見え方を示すと。

b0174191_10231260.png
b0174191_10234880.png
b0174191_10241976.png
b0174191_10254699.png

マイクロソフトのEdgeは相変わらず独自路線でIEと同じ、スクロールバーを出してくれず折り返されます。 ChromeとFirefoxは同じ表示になりました。 で、今回の縦スクロールバーはChromeだけの問題の様です。



 異常表示はまばらに出る 

現象は、このコードを複数並べると気付き易いのですが、110%以上の拡大率で見ると、いくつか置きに縦スクロールバーが出たり出なかったりします。 ブロックは全く同じコードですが、拡大率により異常表示が出るブロックが変わります。 これは、編集画面上でもブログ誌面上でも同じです。

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

「overflow: auto;」の指定で、文字列が右端に達しておらず、また本来は縦スクロールバーは出ないはずです。 しかし、縦スクロールバーが出たり出なかったりするという事です。

横スクロールバーを意図的に表示させるこういったブロックは、コード掲載などで昔から利用して来ました。 ブロックの書き方を定型化して同じ形なのに、縦スクロールバーのこんな出方は気付かなかったのです。 最近にこの様なことが生じた様に思えますが、確証がありません。


〔追記〕
問題の切り分けのために、インラインの指定を部分的に外して行きました。

<div style="overflow: auto; width:400px; padding: 0 20px;background: #ddd; border: 1px solid #aaa;">
<span style="white-space: nowrap;">
■■■■■■■ これはサンプル ■■■■■■
</span>
</div>


〔padding: 0 20px〕を削除

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■


〔background: #ddd〕を削除

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■


〔border: 1px solid #aaa〕を削除

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■


なんとなく予想していた「border」が関係しているらしい。 実際に私のページで生じている事は、こういう縦幅が極小のブロックではなく、縦に数十行以上のブロックでも、同様に不規則にスクロールバーが表示されてしまいます。

当然、「overflow-x:auto; overflow-y: hidden」等で逃げる事は出来そうですが、理屈の不明な表示の放置は、という気がします。 この定型でHTMLのインラインでブロックのスクロール表示の仕方を指定しているのは、スマホでのコード表記枠の見え方を考慮しているからです。 エキサイトの場合、スマホでの表示は、HTMLでスタイルを指定するインライン記述でしか修飾出来ないのです。 この様なブログシステムは多いのですが、スマホ向けのCSSデザインはブログシステム任せで、ユーザーが細かいアレンジや要望を盛り込む事は出来ないため、苦労します。


とりあえずの改善策で、「overflow-x:auto; overflow-y: hidden」としてみます。

<div style="overflow-x:auto; overflow-y: hidden; width:400px; padding: 0 20px;background: #ddd; border: 1px solid #aaa;">
<span style="white-space: nowrap;">
■■■■■■■ これはサンプル ■■■■■■
</span>
</div>

上のコードのサンプル

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

■■■■■■■ これはサンプル ■■■■■■

400pxを越える長い内容の場合

■■■■■■■ これはサンプル ■■■■■■■■■■■■■■■

■■■■■■■ これはサンプル ■■■■■■■■■■■■■■■

■■■■■■■ これはサンプル ■■■■■■■■■■■■■■■

まあ、あたり前ですが、これで意図した通りの表示になる様です。

他の解決策を探して、「height」「line-height」「上下padding」など闇雲に試しましたがどうも妙薬は見つかりません。



[PR]
by Ataron | 2017-11-24 02:13 | PC環境(ハード/ソフト) | Comments(0)

英語かぶれなのか

2017年 11月 22日
ユーザースタイルシートというブラウザの機能を使って、ブログ編集画面のアレンジを手がける様になってずいぶん経ちます。 これは、ブラウザ表示にユーザー側で勝手にアレンジを施せる、使ってみると大変有効な機能です。

そのベースになるのがブラウザ拡張機能とかアドオンと呼ばれる「補完的プログラム」で、私は最近は「Stylus」という拡張機能を使っています。 この拡張機能をブラウザに導入して、その上で自分でCSSを紡いでいわゆる「スキン」を作るのです。 これはアプリケーションデザイン的な面白さがある作業です。


さて、ブログ編集画面のアレンジが一段落して手が余って来ると、何かアレンジしたくて仕方なくなります。 そこで、手短なアレンジ対象に、アレンジのために有る拡張機能自身のアレンジという、妙な事を初めてしまうのです。 まあ、猟師が鉄砲を磨く様なものでしょうか。

「Stylus」の日本語版の主画面は、こんな画面です。 拡張機能はブラウザをまるでアプリケーションの様にみせています。

b0174191_00523682.png

左上のタイトルは英語版の直訳で、文字が大き過ぎて折り返して、これは手抜きの移植です。 しかし、どうも「漢字」というのはソフトウエアに似合わない気が昔からします。 私の英語かぶれかも知れませんが、アルファベットは並びが幾何学的に揃って見え、スイッチデザインにマッチする様に感じるのです。

上の画面をアレンジしたのですが、ついでに英語版に演繹しました。「Stylus」の作られた言語圏のユーザーに、私のアイデアを宣伝して見ようと思ったからです。

b0174191_01093442.png

最初は、どうしたら「Stylus」の英語版が入手できるか判らずウロウロしました。 しかし、その必要が無かったのです。 Chromeでは設定画面で言語を英語に切り替えると、この拡張機能も自動的に英語表記(つまり英語版)に変わりました。 今や私達は、世界中で殆ど同じブラウザを使っているのですね。

上図は、その英語圏化したChrome上で「Stylus」にアレンジを施したもので、ボタンデザインは私の装飾ですが、左側のメニューが英語表記に変わってます。

英語版はバー型のボタンが日本語版に比べて短く納まります。 それが造られた本家はスマートで、日本語版は無理やリ漢字をあてがった感があります。 デザインが何か変だと思っていたのが、本家を見るとやけにカッコ良かったりするのですね。


下はStylusのコード編集画面です。 これも英語版でアレンジ後のものです。

b0174191_01234368.png

考えると日本語は変わった言語です。 漢字・ひらがな・カタカナ・英数字・ついでに記号なぞ、なんやかやと混ぜて平気という、世界的に見ても変わった混合方式ではないでしょうか。 そのごった煮文化の脳は、反対に形式化・単純化されたものに憧れるのでしょうか?


[PR]
by Ataron | 2017-11-22 01:34 | PC環境(ハード/ソフト) | Comments(0)

訂正箇所をHTML編集画面ですぐに見つける方法

2017年 09月 23日
普通の投稿では余り長文にならないので、この話は少し特殊でしょう。

スキンアレンジなどでCSSコードを扱う場合、全文がとても長くなります。 また、HTML編集画面は、コードとタグが入り乱れて来ます。 こんな投稿を扱っている時に、「通常編集」で訂正したい場所を見つけ「HTML編集」で訂正しなければならなくなった時の問題です。

「通常編集」と「HTML編集」の画面は、スクロール位置は全く連動していませんから、その箇所をHTML編集画面の中で探すことになります。 これが短い投稿文なら簡単ですが、「入り乱れた」投稿文の場合、なかなか探すのに苦労したり、勘違いして別の所を弄ってしまう事があります。

編集画面のアレンジをしているので、CSSでこれを改善する方法を考えたのですが、Javaスクリプト等を使わないと難しい様です。 で、ブラウザの検索機能を使った代案の覚え書きです。



先ず、普通は使わない文字で、主要フォントからマークに利用する文字を探します。 Windowsなら「文字コード表」で探せば、沢山候補があります。

a0349576_22540594.png

これをIMEに文字登録します。 私は1文字登録を良く使いますが、この場合は「た」の読みで「❖」のマークを登録しました。「た」と打って変換すればこのマークが直ぐに出る様にしたわけです。

「通常編集」で訂正したい場所を見つけたとして、その近辺で、後で処理がし易い場所にこのマーク文字を書き込みます。 下図はその例で「❖」を書き込んでいる所です。

a0349576_22403327.png

「HTML編集」に切り替えます。 Chromeでは「F3」を押すと、下図の様に検索窓が出ます。

a0349576_23045242.png

ここで、先の「❖」を打ち込み、「Enter」を押すと、自動的にこのマーク行までスクロールします。「❖」を消して「訂正箇所」を修復すれば、目的を達するというわけです。



Chromeで実際に試すと、「HTML編集」に切り替えてから、「F3」「た」「↓×2」「Enter」で、目的の行に到達しました。 慣れると、実用的なテクニックに出来そうです。 編集画面自体に、簡単にワープできる機能があれば良いのですが、ブログ編集画面ですからね。




この記事はカテゴリ「スキン編集」にトラックバックしています。



[PR]
by Ataron | 2017-09-23 23:31 | PC環境(ハード/ソフト) | Comments(0)

ログインできなくなった時の防備録 / エキサイトブログ

2017年 08月 08日
IE11のセキュリティ設定を色々触っていると、エキサイトブログにログインできなくなりました。 いや、正確に言えば、半分ログインしている状態です。

症状は明らかです。 ログインしていないと出来ない作業をしようとすると、エキサイトブログのトップページに飛ばされます。 要するにログインしろという事です。

a0349576_12094754.png

で「ログイン」を押してログインのページに入ると、既に「ログイン状態」になっています。

a0349576_12132613.png

この二つのページを往復しても、また一旦ログアウトしてやりなおしても、先に進めません。

これは、エキサイトブログ向上委員会のコメントの中で、時々見かけるトラブルです。 危機こそ好機なりと、かたっぱしから条件を変えてテストしてみました。



エキサイトのヘルプでは「Cookie」の削除を解決策の最初に書いています。


〔Cookieのリセット〕
IE11の「歯車マーク」から「インターネットオプション」を起動。

a0349576_12173232.png

最初のタブページ「全般」→「閲覧の履歴」で「削除」を押すと、下のダイアログが出ます。

a0349576_12212724.png

「クッキーとWebサイトデータ」にチェックを入れて(他は不要)、下の「削除」を押します。



〔サイトのプライバシー管理〕

次に書かれた対策です。「プライバシー」のタブページを開き、「サイト」をクリックします。

a0349576_12275176.png

ここで開くダイアログで、「exblog.jp」「excite.co.jp」の2ヵ所のドメインネームが登録されている必要があります。 ドメイン表記で、上の太字の通りでないとダメです。

a0349576_12313939.png



〔信頼済みサイトの登録〕

今回、これが効果がありましたが、IE11を起動すると初回だけはトップページに飛ばされる症状が残りました。「セキュリティ」のタプページで、一番上のゾーン選択で「信頼済みサイト」のアイコンをクリックします。 このページの設定は、4つのゾーンで別個の登録になっていますから、どのゾーンの設定か混乱しないでください。

a0349576_12380920.png

デフォルトで「信頼済みサイト」は下方の「保護モードを有効にする~」にチェックがないはずで、チェックが入っていたら外しておきます。 その上で、上図の「サイト」ボタンを押します。

信頼済みサイトのダイアログが開きます。 ここで〔サイトのプライバシ管理〕と同様に「exblog.jp」「excite.co.jp」を登録。 登録後に一度ダイアログを閉じ、もう一度開くと下図の様に「*.exblog.jp」「*.excite.co.jp」に変わっていました。 この登録枠はURL形式なので、適した形に変えられた様です。 下の「サーバーの確認」は、この形の登録なのでチェックなしです。

a0349576_17050569.png


これで一応ログインができる様になりましたが、妙な事にIE11を起動してから初回だけトップページに飛ばされる症状が残りました。 2度目編集画面に入る時は、問題ないのです。 しかし、元はトップページに飛ばされる事など無かったので、まだ変なわけです。



ここで、もう一度挑戦しました。

〔サイトのプライバシー管理 登録削除 そして 再登録〕

私のこの「プライバシー」の登録、実は最初から登録していました。 その状態での不具合だったので、「信頼済みサイト」の方を登録したのです。 しかし未だ完全ではないので、一度「プライバシー」の登録を削除してみました。 IE11を一旦閉じて再起動し、この「プライバシー」の登録をやりなおした所、トップページに飛ばされることが全くなくなりました。

最初から、この作業だけで良かったのかも知れません。 先ほどの「信頼済みサイト」の登録は削除しましたが、問題なくログインが出来る本来の状態になりました。



今後SSL化で、再び登録の内容が問題になるかも知れません。 またログインできなければ、なんとでも出来そうな気がします。 一度ひねくれてしまったシステムをいかにリセットするか、そんな問題に思えます。 今回の私のアガキ方、難儀している方の参考になれば幸いです。




この記事はカテゴリ「ブログ」にトラックバックしています。



[PR]
by Ataron | 2017-08-08 13:20 | PC環境(ハード/ソフト) | Comments(0)

Win10 カーネルこちょこちょイジったの?

2017年 07月 25日
しきりにアップデートの要請が出るので、Win10を再起動すると、やたらと時間がかかっています。

a0349576_21393413.png

暇だから画面のハードコピーを取ったが、再起動してクリップボードは飛ぶかなと思ったら、何故か上の画像が残ってました。 実際、数十分は何かやっていたので、これはカーネルまで弄ってるなと訝ったのですが、実際はどうでしょう。

●テキスト編集の時に画面中央に文字入力のポップアップが出る様になった
調べてみると、これはIMEの新機能で、嫌ならOFFに出来る様です。 タスクバーのIMEを右クリックして、下図の様に進むと表示のON/OFFの選択が出ます。 末行の「精細設定」で本来のダイアログが出る様に変更されてます。

a0349576_21394674.png

以下のサイトに目ぼしい変更点の内容と、それらの対処方法を整理してくれてます。 よくお世話になるサイトです。


●「コントロールパネル」がメニューの底に行ってしまった
OS設定の管理にコンパネを使うデザインは時代遅れとの判断なのか、フムフム。 まあ、設定はなんとでもアクセス出来るからいいけど。

●IE11に「Edge」を開くタブが勝手に付いた
こんなタブは要らないな。 そんなのするなら、早くEdge標準のユーザースタイルシート機能を作って欲しい。 もう1年も待ってるけど、Edge専用アプリを探してもその影もありません。 勝手に作れって? 私、そこまで詳しくないのです。 まあ、そんなのが揃わない間は宣伝をしても、Edgeユーザーは増えないと思う。

こんな事が、今回の感想。 アップデートは欠かせないですから。



[PR]
by Ataron | 2017-07-25 13:44 | PC環境(ハード/ソフト) | Comments(0)

エキサイトブログの常時SSL化に関する要チェックポイント

2017年 06月 07日
2017年夏にかけてエキサイトブログの常時SSL化が実施される様です。 最初の告知は以下です。
エキサイトブログは、余りアレンジユーザーは多くなさそうですが、そういったユーザーでなくても、SSL化によって自分のブログページの問題が生じないかは、SSL化の実施の過程でチェックした方が良い様に感じます。 私が知り得るポイントで、SSL化で最も問題になりそうな事は、URLが「ブログ記事」や「スキンコード」に記述されている場合です。

SSL化(安全対策化)されたブログページで、外部ファイルを参照する「http://」のURLが記述されている場合、ブラウザが警告を出す場合があるという情報もあります。 その場合、外部ファイル取得やリンク先へのジャンプに関して、ユーザーの選択を求める形が予想されますが、実際には常時SSL化が実施されてみないと判りません。

b0174191_09522169.png



〔ブログ記事上の外部リンク〕
例えば、YouTube動画の埋め込みで、動画コード内に「src="http://www.youtube.com.~」等と「s」抜きURLを書き込んでいる場合があります。 このブログページがどんな表示になるのか、動画は表示されるのか、今の所は不明です。 但し、エキサイトの編集アイコンでYouTube動画を埋め込んだ場合は、「src="//www.youtube.com.~」となる様で、これは問題が生じないでしょう。

動画に限らず、外部サイトやその記事などのリンクを記述していて、そのURLが「http://」である場合は、ブラウザで警告表示されるのでしょうか?

〔ブログ記事上の自ブログ他ページへの相対パスリンク〕
自分のブログの他ページへのリンクのURLを、相対パス表記で「href="/xxxxxxxx/"」等としている場合は、問題はないでしょう。(xxxxxxxxはブログ記事番号)

〔ブログ記事上の自ブログ他ページへの絶対パスリンク〕
エキサイトは「以前に投稿した記事(httpのURL)へのリンクは、そのままで問題ございません」としていますが、これはデスクトップに置いたリンクや、全く別のサイトに置いたリンクの事で、それらをたどる際は「https」にリダイレクトされ、ちゃんとページが表示されると言っているだけの様に見えます。(それは、システム側で可能な基本的なリダイレクトですから)

しかし、自ブログ他ページへのリンクのURLを、絶対パス表記で「href="http://~~"」等としている場合、参照先がリダイレクトされれば「https://」という所までブラウザが解釈してくれるか、或いはシステムがフィルターをかけてエキサイトブログのURLは「s」付きとしてブラウザに読ませるか、など、実際にSSL化されないと判らないものです。

〔ブログ記事上のリッチリンク〕
これは「src="//bp.exblog.jp/richlink/」という相対パス表記ですから、問題は生じないでしょう。

〔ブログ記事上の画像〕
普通に設置した画像はエキサイトの特殊タグで扱われ、その元はエキサイトの画像サーバのURLです。 現在のURLは「http://pds.exblog.jp/」ですが、SSL化以降は「https://」になり問題を生じないでしょう。 但し、特殊に外部の画像ファイルのURLをリンク先として記述している場合は、問題を生じ得る可能性があります。

〔ブログ記事上のジャンル(バナー)やライフログ〕
「href="http://www.exblog.jp/genre/」「src="http://md.exblog.jp/img/」「href="http://item.excite.co.jp/」等が使われていますが、SSL化以降は「https://」に変わると思います。 昔のページに配したこれらは、記述が「http://」のままでも、ページを表示した際は自動的にリダイレクトされ、問題はなさそうに思います。

〔ブログ記事上のマップ〕
埋め込まれるのはマップ機能の特殊コードで、問題は生じないと思われます。 ちなみに、Google Map のリンクコードは以前より「https://」で、それを埋めこんでいる場合も問題ないはずです。



〔ブログパーツなど〕
一例で私が使用しているユニクロカレンダーは「src="http://www.uniqlo.com/」を参照しています。 このパーツの動作はどの様になるのか? 他にも「http://」サイトを参照する埋め込みブログパーツはあるでしょう。

フェースブックボタンは「https://」参照ですが、各所に出て来る「Yahooの宣伝」は「http://」参照です。 これらはどうなるのか、無くなりはしないでしょうが。



〔スキン上のリンク〕
スキンのHtmlやCSS上に記述されたURLはどう扱われるのでしょうか? 公式スキンの場合は、書き込まれたURLは、おそらく殆どが背景や枠などのデザイン用の画像パーツでしょう。 参照対象のURLは「S」付きになるわけですが、スキン側の書き換えをするか、自動的なリダイレクトが働くので既存スキン書換えは無いかも知れません。私は後者を予測しますが。

スキンアレンジを施しているユーザーは、そう大した作業でも無いでしょうから、URL記述ヵ所を検索して「https://」に書き換える事をお勧めします。 エキサイト内のURLを参照するものである限り、問題は生じないと予測しますが、僅かでも表示スピード上でプラスになるかも知れません。



以上、常時SSL化が実施されたら、チェックしておきたい部分を挙げて整理しました。 私は、上記で「」を付けた項目は要チェックと考えています。



〔追記〕2017.06.08
URL表記の型式で調べると、「http://」「https://」等はそのURLのサーバーが通信する「プロトコル」を表すとあります。 現在のブラウザは、通信プロトコルを自動的に判断するので、一般にこの部分を省略したURL表記でこと足りるのでしょう。 今後、エキサイトブログに絶対パス表記でリンクを置く場合は、「//~~~」という表記型が間違いないと思います。

〔追記〕2017.06.12
私は編集画面アレンジにユーザースタイルシートを使用しています。 そのコード中のアイコン画像のURL指定では、IE版に限り「http://~」でないと無効になります。 Chrome版(Stylist拡張機能使用)では「//~」型が有効でした。 これは、CSSそのものより、それを扱う環境(ユーザースタイルシートの環境)に関係する様な気がします。 IEは一番気難しいのは他の事でも頻繁に経験しますから。

一方、CSSで一番皆んなが利用しているのがブログスキンですが、こちらのCSSに書き込んだ「http://~」型のURL指定は「//~」型に書換えても全く問題ない様です。 ブログスキンのCSS(Htmlも)は、エキサイト内部で先ず読みだされるからの様な気がします。 自分でアレンジしている場合は、ブログスキン上の「http://~」表記は、予防的に「//~」型に書き換えて良いと思われます。

〔追記〕2017.07.25
エキサイトの新しい告知がありました。
「ブログパーツで無効になる種類がある」「バナーの更新が必要なのがある」は、予想されていましたが、過去記事に貼った「バナー」も張り替えが必要な様に思えます。 サイドメニューならブログスキンの書き換えで簡単ですが、多数の過去記事内に貼っている方は、いちいち記事の再編集になりそうです。 これは諦める人が多いかも。

文句が沢山出そうですが、これは自ブログのシステムを見直す良い機会になると思います。



[PR]
by Ataron | 2017-06-07 14:00 | PC環境(ハード/ソフト) | Comments(0)

エキサイトブログ編集のツボ 画像を越えられないカーソルと消えるカーソル

2017年 04月 09日
ブログ編集をしていて最近気になった事は、文末の編集でカーソルが一時的に消失してしまう現象です。 通常編集を専らとするChromeユーザーは経験しているかも知れません。 IE11ではカーソル消失は無い様ですが、文末で先にカーソルを進め難い事は同様にあります。 いずれも、エキサイトブログの文書編集枠(通常編集)の特性とブラウザの仕様が絡まった問題に思えます。



今回の事象が一番良く判るのは挿入画像の前後ですが、ブロックや表等でも同様に生じます。 以下の説明はブラウザがChromeですが、IE11もほぼ同様です。


①最初は、編集中に画像を文末に中央配置で挿入したとします。

b0174191_21273796.png

上図の様な位置にカーソルがある場合、キーボードだけでは下図の様になって画像の後方に文字を書くことができません。

b0174191_21293546.png

もちろん、この場合はマウスでカーソルを画像の後方に置ければ解決します。

b0174191_21374901.png

b0174191_06272101.png



➁上記は画像が中央配置でしたが、左寄せや右寄せの場合は話が違います。 下図は、文末に挿入した画像を左寄り配置にした場合です。

b0174191_21410073.png

運よく画像の後方に何か文字や改行等が入っていた場合は、下の様に画像の側面(Html上は画像の後方)の先の部分にカーソルを進める事が可能です。

b0174191_21420505.png

しかし普通は、マウスを使ってもカーソルを画像の後方に置けません。

b0174191_21475278.png

こうなると、画像を中央配置にしてマウスで先に進めてから左寄せにするか、HTML編集で先を書く(HTMLでは確実に後方に進める事が可能です)しか無い様です。


➂最初の①の場合に、時々妙な状況に出会う事があります。

現象を確かめるには、①の状態で画像の後方にカーソルが置ける場合に、「Backspace」「Delete」で画像以降の入力を全て削除します。

b0174191_06474934.png

編集時に案外とこの様な状況にはならないのですが、この状況になると、マウス操作でもカーソルを画像の後方に置けない現象が生じます。

この場合、一般的にはHTML編集で、画像の後方に文字を書き込んで解決します。 しかし、HTML編集を開くのが面倒なら、画像配置のメニューを出して抜ける手があります。 これは以下に説明します。


④「カーソル消失」はChromeでのみ生じる様ですが、編集画面にスクロールバーが出る長さの文書の末尾に画像がある場合で、➂と同様に画像の後方に何の入力も無い状態で生じます。

下図は、➂と同様に画像以降の入力を綺麗に削除した状態で、画像の横に長いカーソルがあります。

b0174191_22001707.png

この時、マウスを使ってカーソルを置ける場所は、下図の ❶➋の場所か より手前の部分です。 また、右のスクロールバーはこれより下方が無い表示です。

b0174191_22063605.png

この状態になると、画像の後方にカーソルを置く事が出来ません。 以前の「画像周囲での文字入力」で採り上げていますが、❶➋の場所で文字を書いたり改行をするとややこしい事になります。 この状態はHTML編集で切り抜けるのが普通ですが、通常編集内で先に進む方法があります。

●先ず画像をクリックして画像位置指定のメニューを出し、無意味な様ですが位置指定「中」を押します

b0174191_22154636.png

この操作で、下図の様にスクロールバーが動き、文書の最下端が伸びた事が判ります。

b0174191_22180313.png

マウスのホイール等で文書の最下端を表示させ、下図の様にグリーンのあたりをクリックして、画像の後方にカーソルが置けないかを試します。

b0174191_22195305.png

●状況が変わらず、先の❶➋の場所にしかカーソルが置けないなら、素直にHTML編集に行った方がよさそうです。 しかしそうではなく、カーソルが消える「カーソル消失状態」になる事が良くあります。(これが生じる条件の詳細は不明です)

その場合はキーボードで「Enter」を入力すると、画像の後方にカーソルが現れます

以上の操作のコツを覚えれば、HTML編集に行く手間が省けます。「Enter」を押す時は、❶➋の場所にカーソルが無いか確かめましょう。




[PR]
by Ataron | 2017-04-09 22:45 | PC環境(ハード/ソフト) | Comments(0)