管理者画面の「動作設定」( config.php )の「携帯用ページをテスト」を「モバイルページをテスト」に変更し、「携帯」「スマートフォン」「しない」の3項目から選択するようにした。

rnote.php 本体を修正し、 $g_bCellphone に加え $g_bSmartphone を追加した。そして、スマートフォン検出のために「mobiledetect」の Mobile_Detect.php を追加し、スマートフォンを検出するようにした。

$HOME/entries/ の中に、 error_s.skin, html_body_s.skin を追加し、スマートフォンの場合にそれらのスキンを用いるようにした。

$HOME/style/ の中に、 style-sites_s.css を追加し、スマートフォンの場合にそのスタイルシートを読み込むようにした。

これらの作業をしてみて気づいた。 rNote はページのキャッシュを作成する機能をもっているが、これはPCからのアクセス用のキャッシュのみなので、携帯からのアクセス時には、キャッシュは無効となり動的に生成されるようだ。

このへんは改善の余地があるのではないか。昨今のアクセス状況を見ると、PCだけでなくスマートフォンからのアクセス率が増えているようなので、携帯用ページはまだしも、スマートフォン用のページはPC用同様にキャッシュを生成するべきと思う。

この記事のリンク元 | 10 | 8 |

この記事のリンク用URL&トラックバックURL : https://red-souls.jp/ichounoki/rnote/dev/20190901_180459109926.htm


google は「モバイルフレンドリーテスト」という機能を持っている。

これは、あるサイトの表示が、スマートフォンなどでの表示に適切に対応しているかどうかをチェックしてくれる機能だ。

rNote の現状を考えてみると、 docomo や au などのガラケーに対する対応しかされていない。その対応方法は、クライアントからの request http header を見て、 user agent が携帯のものであった場合には、PC用の表示とは異なる携帯用の表示を行うよう動作するようになっている。

この方法は、スマートフォン全盛の現在でも有効だが、その場合、「スマホ向け表示を分けているときはVary HTTPヘッダーを使うこと など10+4記事(海外&国内SEO情報)」で説明されているように、サーバからの response http header に vary http であることが示されるようにすると良いようだ。

具体的には、 apache2 を使用しているサーバの場合、 .htaccess に、

Header set Vary User-Agent

と記述するだけでよい。

ただ、この方法だと、前述の google のテストに通らない場合があるようだ。理由は簡単で、 google がテストのためにサイトにアクセスしてくる際の bot の user agent が不明なため、サイト側でその user agent をスマートフォンからのアクセスとして認識しないためだ。これを解決するためには、一度 google のテストを実行し、その際にアクセスしてきた google の got の user agent 名を調査し、その名前にサイト側で対応しておく必要がある。しかし、 google の bot の user agent 名は、いつ変更されるか分からないため、変更された場合、 google にモバイルフレンドリーなサイトであると認定されなくなることになる。

一方で、モバイルフレンドリーなサイトにするためのもうひとつの方法として、「メディアクエリ」を使用する方法がある。これは、ヘッダでスタイルシートを読み込むタグの要素に media 要素を追加し、

<link rel="stylesheet" href="/ichounoki/rnote/medium.css" media="screen and (min-width:480px) and (max-width:1024px)"> 

のように、画面の幅などによって異なるスタイルシートを読み込むようにする方法だ。または、「レスポンシブの基本、メディアクエリの書き方」で説明されているように、

@media screen and (min-width:480px) and ( max-width:1024px) {p {  } /* 横幅が 480 pixcel から 1024 pixcel までの場合の p タグのスタイル */}

のように、画面の幅などによって異なるスタイルが選択されるようにスタイルシート内に記述する方法だ。

ただ、この方法を試したところ、実際には、画面ではなく、ブラウザのウィンドウの幅によって切り替わってしまうようだ。つまり、例えば、PCで表示させていても、ブラウザのウィンドウの幅を短くしていくと、タブレットやスマートフォン用の表示に切り替わってしまう。これでは、まずいのだが、提示されたサンプルを見る限り、条件分けの記述に screen も指定されているようなので、この指定で画面の幅であるように動作しないのであれば、お手上げな気がする。

また、根本的な問題だが、この方法では、クライアントの表示サイズによって切り替えることができるのは、あくまでも「スタイルシートだけ」なので、「タグで表現された表示内容そのものは変更できない」のだ。現在の rNote が携帯用の表示を行う場合に、その小さな画面と画像表示能力を考慮して、表示する項目や表示するテキスト自体を変更していることを考えても、ただスタイルシートだけしか変更できないのでは、小さな画面用の表示として満足のいく設定ができるとは思えないので、自分的には、この、「メディアクエリ」という方法自体、構造的に既にダメである。

というわけで、 rNote-re の機能として、現状に対応させるためにモバイルフレンドリーにするとしたら、実装方法としては、 rNote と同様にクライアントの種別を user agent で読み取って表示自体を切り替えるという方法になるだろう。ただし、上述した通り google の変更を小豆に発見して対応する必要がある。

この記事のリンク元 | 9 | 8 |

この記事のリンク用URL&トラックバックURL : https://red-souls.jp/ichounoki/rnote/dev/20190901_155357263388.htm


いや、 HTML5 に限った話ではないようだが・・・、例えば chrome に比べ、 firefox はずっと広い幅になってしまうようだ。

ぱっと見た感じ、 chrome では半角文字の幅が基準に使用され、 firefox では全角文字の幅が基準に使用されているように見える。

ともあれ、結果として、特定ブラウザ上で表示を合わせても別のブラウザでは表示が崩れてしまう。なんとかするには cols を使用せず css で width を指定することになる。

だがそうすると px で指定することになるので textarea 内で使用されるフォントが可変だった場合に、現在のフォントの幅などに連動できなくなる。親要素に対する % 指定もできるようだが、自分の環境では px 指定でないと動作しなかった。自分の環境での css の定義され方に影響されているのかも知れないが、ぱっと見て分かるようなものではなかった。

textarea の cols 要素って文字数を指定する要素じゃないのか?なんのためにあるの?この要素は「 textarea に現在設定されているフォントの幅を基準に何文字分の幅かを指定する」と定義されるのが正しい気がするが、フォントの設定は css の領分なので、 html 側からその設定内容をそのまま利用することは出来ない気がするので、そもそも cols という要素は「あるべき定義」が不可能な存在である気がする。

だがしかし、こんな誰もが必ず使用を迫られるような要素の動作がブラウザ間でばっらばらなのは、とてもすごく困るのだが・・・。

この記事のリンク元 | 9 | 8 |

この記事のリンク用URL&トラックバックURL : https://red-souls.jp/ichounoki/rnote/dev/20190829_200516853019.htm

キーワード: html5 textarea cols


rnotepad.php を修正 2019-08-28 (水) 21:24:32+09:00

開発

「枠」ボタンを追加した。選択されたテキストを囲んでボタンを押すとタグを挿入し、四角い枠内にテキストを表示するようにレイアウトする。

こんな感じ。

「コード」ボタンを追加した。選択されたテキストを囲んでボタンを押すとタグを挿入し、 prism を使ったソースコード表示(行番号表示設定)をするようにレイアウトする。

また、先日、追記用の入力欄も追加したので、「 URL 」「強調」「斜体」「下線」「取消」「引用」「上付」「下付」「枠」「コード」の各ボタンが、本文入力欄、追記入力欄のどちらかフォーカスのある方に作用するようにした。

今まで、枠をつけたりソースコード表示をしたりするたびに、手作業でタグを書き込んでいたので、大分楽になった。

今回の修正で少し考える必要があったのは、ボタンが押されたときに選択されている文字列を把握するために、 textarea 要素に対して onSelect でテキストが選択されるたびにイベントを起こしていたのだが、逆にテキストの選択が解除されたときに起きるイベントが javascript のイベントに存在しなかったため、どのように実現するかという点だった。

結局、 textarea 要素に対して onkeyup と onmouseup を補足し、そのイベントハンドラ内で getSelection(e) で選択文字列を取得し選択中の文字列として保存することで、選択の解除を補足することができた。( onkeydown, onmousedown ではタイミングが早すぎて、まだ選択中の文字列が取得される。)

この記事のリンク元 | 9 | 8 |

この記事のリンク用URL&トラックバックURL : https://red-souls.jp/ichounoki/rnote/dev/20190828_212432537675.htm

キーワード: rNote rnotepad.php javascript


canvas で表示しているアニメーションの上に重なったカウンター、URL、画像のある場所では、 canvas にマウスイベントが届かないため、透明な別の canvas を更に上に配置し、そちらでマウスイベントを取得するようにして対処した。

しかし、今度は、アニメーション表示 canvas の上に重ねた URL 部分が反応しなくなった。透明な別 canvas の下にあるのだから当然と言えば当然だ。

で、調べた結果、やはり上に別の要素がある場合、下になった要素にはイベントが届かないことが分かった。また、設定で届くようにするような方法も用意されていないことも分かった。

とても困った仕様だが、そういう仕様なんだからしょうがない。

そこで、「複数枚重なったcanvasで透明領域にマウスイベントを見えている直下の要素に渡したい」を参考に、一番上の透明の canvas に届いたマウスイベント( click, mousemove, mouseover, mouseout )を、下にある要素に送るようにした。

これで URL をクリックした場合にリンク先に飛ぶ動作をするようにはなったが、マウスカーソルを URL 文字列の上にもっていっても色が変わるリンク文字列の動作をしてくれない。ということは、 mouseover, mouseout を送っても、色を変える動作はしないということだ。おそらく、イベントの種別として、 MouseEvent ではなく UIEvent を送る必要があるのだと思う。そして、 URL 文字列の要素に対し、 mouseover のイベントが届くタイミングで UIEvent の DOMFocusIn を送り、 mouseout のイベントが届くタイミングで UIEvent の DOMFocusOut を送ってやることでリンク文字列の色を変える動作をすると思われる。

しかし、問題が2つある。

まず1つ目の問題は、 UIEvent を送るタイミングをどのように決めるかである。上にある canvas 上で mousemove, mouseover, mouseout のイベントが届いたときに elementFromPoint で、マウスカーソル位置にある下の要素を取得しているが、いつその下の要素の上にマウスカーソルが入り、いつ出たのかを決定することができないからだ。この問題は、elementFromPoint で発見した要素を currentItem に追加し同時にその要素に UIEvent の DOMFocusIn を送り、その後の elementFromPoint で、 currentItem が示す要素と異なる要素または null となった場合に、 UIEvent の DOMFocusOut を送ることで、なんとかなるかも知れない。

しかし2つ目の問題として、 UIEvent を発行し DOMFocusIn を下の要素に送った場合、その要素にフォーカスが変わるため、上にあるイベントを受け取っていた要素がイベントを受け取れなくなってしまうであろうことがあげられる。こちらの問題の方が致命的で、本来イベントを受け取るべき要素がイベントを受け取れなくなるということなので、 URL のリンク文字列の色を変えるためにイベントを送るという考え方自体がダメということである。

そこで考え方を変え、 mousemove の elementFromPoint で発見した要素がリンク文字列であれば要素を currentItem にセットしその要素の色をマウスホバー色に変え、その後の elementFromPoint で、 currentItem が示す要素と異なる要素または null となった場合に、その要素の色を戻すことで対応した。

下が完成版。

var currentItem = null;

var currentItemCol = 0;

function passmouseevent(e, type)

{

var mev;

var tmp;

var under;

tmp = event1.style.display;

event1.style.display = "none";

under = document.elementFromPoint(e.clientX, e.clientY);

if (type == "mousemove") {

if (under != null) {

if (currentItem != under) {

if ((currentItem != null) && (currentItem.tagName == "A")) {

currentItem.style.color = currentItemCol;

}

currentItem = under;

currentItemCol = under.style.color;

if (under.tagName == "A") {

under.style.color = "#ff00ff";

}

}

} else {

if ((currentItem != null) && (currentItem.tagName == "A")) {

currentItem.style.color = currentItemCol;

currentItem = null;

}

}

}

if (under != null) {

mev = document.createEvent('MouseEvents');

mev.initMouseEvent(e.type,

e.bubbles,

e.cancelable,

e.view,

e.detail,

e.screenX,

e.screenY,

e.clientX,

e.clientY,

e.ctrlKey,

e.altKey,

e.shiftKey,

e.metaKey,

e.button,

e.relatedTarget);

under.dispatchEvent(mev);

}

event1.style.display = tmp;

}

function testclick(e)

{

passmouseevent(e, 'click');

}

function testmove(e)

{

passmouseevent(e, 'mousemove');

}

今回やりたいことを始めてから完成までの経緯。

(1)トップページにアニメーションを表示したいな。

(2)バナー部分の、カウンターやURLリンクや画像の下に背景的に表示したいな。

(3)アニメーションはマウスカーソルにも反応してほしいな。

(4)あれ?カウンターやURLリンクや画像のところにマウスカーソルが来ると反応しないな。

(5)透明な canvas を一番上に用意して、そこでイベントを取ろう。

(6)あれ?URLリンクに反応しないな。

(7)要素の下の要素にもイベントを送る必要があるな。

(8)あれ?URLリンクの色がマウスカーソルホバー時に変わらないな。

(9)どうやらイベントを送っても変わってくれないらしい。

(10)イベントを送るタイミングを考えて、そのタイミングで代わりに直接色を変えよう。

やりたかったことは、ちょっとアニメーションを表示したかっただけなのだが、実現するために結局 javascript で相当難しい処理を実装する羽目になった。アニメーションの処理自体も javascript でゴリゴリ書かないと出来なかった。

この程度のことでこんな作業が必要なようでは、到底「HTML5 の登場でアニメーションが簡単にできるようになった」という状況ではないのではないか。アニメーションは Adobe Animate を使うとしても、今回のようなちょっとしたレイアウト上の希望で、いちいち javascript で複雑なコードをゴリゴリ書かないといけないというのは、ちょっといただけない。(ちなみに、以前は普通にパッケージとして購入できていた Adobe の製品だが、今では全て月額使用料を支払い続けなければ使用できない・・・。とてもじゃないが、もう Adobe の製品は購入できない。というか、月額で使用料が発生し続けるものって「購入」と呼べるのだろうか?)

この記事のリンク元 | 11 | 9 | 8 | 5 | 2 |

この記事のリンク用URL&トラックバックURL : https://red-souls.jp/ichounoki/rnote/dev/20190828_020141439237.htm

キーワード: HTML5 canvas javascript