主に不具合と感じられた挙動について

●メンテ後検証、速報版（2015/03/19）

　Firefoxでは、編集画面の動作的に「特にこれ」といった変化は感じられず。タイプしても装飾しても、たぶん同じ。
　Chromeは普段使いしていないので記憶もアレなんですが、H3を適用するために選択した段落＋空の2段落が選択され続けるのは相変わらず。ただ、H3をクリックすると最初だけは通常のフォントがH3になるんだけれど、後は選ばれている段落の前の１段落（選択されていない最終段落）が、なぜか操作の対象になっていて、そこだけがH3のオン・オフになっている。前は選択していたところも動いていたような気がしないでもないような…うーん。

　一応、Win版のSleipnir（6.1.5.4000）も導入してみました。

（選び方の微妙な違いによる、「選択状態の違い」に注目）

　なんかこう、また違った微妙な挙動をしているのですが、見えてないというだけでChromeもFirefoxも似た感じの動作をしているのだろうか？みたいな。

　使いこなせていないので、細かな要素の表示や検証などのSSは撮っていませんが、Elementsで赤バツが３、警告系の黄色！が２とか出てるな、この編集ページ。あぁ、アップした画像周りがエラー扱いになってるのか。…まぁいいや。時々眺めてみるようにしてみまーす。あ。選択範囲のひとつ前の段落が操作対象になる、H３の例のアレは健在でした。もう完全に不具合の放置ですよね、コレ。

　Win系OSではH3が解除出来ないことはなかったのだけれど、（もしかしたら、しなくても）異なるOSでは異なる部分も普通にあるので、OS依存系のトラブルなのかもしれないデス。

　上部にハッシュタグの検索窓がつきましたが、ハッシュはその前後に半角スペースの記述が必要であるだとか、そういう辺りはどうなったの？っていうトコまではやる気がしないし。検索では半角スペース抜いてもいいんだよね？ね？
　まぁ、運営がバリバリお知らせを流して、使ってみることが大事だとおもうんだ。多分、その過程でちょっとした不具合にイラっとするハズだから。

●週末検証のおさらい（2015/03/16）

Tips
・H3機能を使う時は、対象段落内の１文字程度を選択するとよい
・空白段落を置くことでは、したくない装飾の巻き添えは防げない
・選択しにくい場合、後ろから前に向けゆっくりドラッグするとよい

部分検証済み
・一度公開した（有料含む）ノートのDescriptionは、後で編集作業を行っても作業中に他人のそれとは混ざらない
・キーボードからの文字列選択では、パレットは起動しない（要マウス選択）

仮説（ウチでは検証できないものを含む）
・H3の多重装飾などに見える状態は、タグの不具合ではない
　→ ブラウザのCSS解釈の不具合
　→ CSS記述上の不手際　のどちらかが原因と推測される
・キーボードでのカーソルが勝手に戻る挙動時は保存プロセスが動作しており、作業者の作業環境に大きく依存する
　→ Win8.1+Firefoxでは感じられないが、Chromeでは時々戻される
・選択範囲の拡張は、現状では「システム都合」。防ぎようがない

●空行２行のおまじない、失効（2015/03/15、03/16追記有）

　今回は結論から先に。今まで空の段落を2つほど噛ませておけば、上の方にある段落への装飾の巻き添え事故は防げるといった記述をしてきました。しかし、それは幻想でした。巻き添え、くらいます。

　実験環境：うちでは毎度のWin8.1（64bit）下で動作するFirefox最新版（36.0.1）。
　選択の方法は、一般的なユーザーがそうするであろう、対象としたい段落全体を選択してパレットを表示させ、H3ボタンを押す手順。表示され続けているパレットのH3ボタンをクリックしていくと、上の段落を巻き込んでH3の装飾が実行されるといういつものアレに。今回は空の段落で大きくスペースをとっていても実行された、という点に意味がありました。空の段落を２つほどもとっておけば大丈夫、という今までのウチでの動作からの暫定対処を見事にひっくり返してくれました。

　「選択方法」には人の個性同様に多様性があった方がよいと思うのですが、それぞれに挙動が異なるのでは困ります。太字などではきっちり対象を選択するので、習慣的にもH3を適用したい部分（段落）をきっちり選択する人が多いんじゃないか、と過去の経験則を含めてで推測します。見出しとかいう本来的な意味など関係なく、大きな字で目立たせたい、程度の使われ方になっていると思うので、そうしたことを踏まえて、（大変でしょうが）機能の改善・改修を行っていって欲しいと思います。

2015/03/16追記：Chromeによる追加検証

　IEでは編集作業そのものが出来ない仕様なので、IEに表示された「推奨ブラウザ」の筆頭であるらしいGoogle Chromeの最新版（41.0.2272.89）でテストしてみました。選択した範囲のソースは表示出来なかったので、編集画面で2つ目の段落全体を選択してH3を解除、再度適用する動作をさせてみました。再度の適用動作の前には以下の図の通りの範囲が拡張されて選択されていました。範囲が変化しなかったFirefoxよりも視覚的に分かりやすいエラーだと思いますし、開発の人も謎動作は部分的には分かってるんじゃないかな…ということがより鮮明になる結果に。

　また、ChromeではFirefoxと違って狙った位置に画像が正しくUpされなかったり、画像が入り込んだ段落に入力してあった文章が消えるといった症状が見受けられました。これはこれで違う意味でクリティカルなエラーのような気がします。アップデートの頻度が高いブラウザでもあるので、なかなか難しい側面もあるでしょうが、推奨と自ら指定しているからにはカッチリきっちりと机上の設計通りの動作をさせて欲しいと思います。

修正、なるべく早めにお願いしたいです。
（関係ないけど、Chromeはずっと昔に適用したスキンが痛い仕様になっているので、SSを晒すのはちょっと気恥ずかしい。）

●H3機能についての暫定対処方法（2015/03/14）

　noteの運営の人が見ていたら、ちょっとこの画像を見て欲しい感じです。

　操作の対象として選択しているのは画面下の少し長めの文章（段落）。実際にボタンが出ていて、操作の結果として変化したのは、（空行を挟んで）上の段落。ブラウザ付属の解析機能を出したからだとも言えるんだけれど、パレットは上の選んでいない段落を選んでいる様子、なのです。元々いじり倒していた画面上では、選択範囲内の場所でオン・オフが出来てました。

　実際問題として「H3」のボタンをオン・オフしていると、選択している段落の上の段落も巻き込まれるというのは、下の方の記事にも書いた通り。ただ、どこの段落のどの位置にパレットがあるのか？というのが、見た目と実際とで異なっていたようだ、というのがここでの問題…みたいな。

　さて。今回の記事のメインになる「暫定的な対処方法」なのですが、H3が段落全体に対して機能するタグである、ということを踏まえて。

　・H3の適用、解除には段落全体を選択しない。
　　　→段落内の１文字選択でも、H3は段落全体に適用される。
　　　　また、他の段落へと（隠れ）選択対象が移動することがない。
　　　　（ただし、私のWin＋Firefox環境と検証の回数範囲内）

ということに。もちろん、まだ文章の途中にある段落（＜ｐ＞タグの中に＜br＞が存在するところ、＜ｈ3＞が適用されても＜br＞が残るところ）に限定した検証と、繰り返しチェックをしただけ…ですが。

　ちなみに。新しい課題として、最終段落に＜h3＞が適用され続けるという新しい症状（？）が、私のテキストノートの一部に発生している模様。空行なので影響はない話だったのですが、どうやっても（ダミー文字列消去は一応除く、）H3が解除できませんでした。多分、先頭段落の解除問題と根が同じ問題…のような気がしてます。

●ちょいメモ（2015/03/12）

　Twitterのアカウントからnoteのアカウントを作ったので、Twitterアカウントの画像がそのまま使われていました。今日、なんの気なしに開いてみたら自分のアイコン画像がすべて「黒丸」状態になっていてびっくり。

　Twitterで長らく使用している、シュタインズゲートの牧瀬クリスアイコンは、公式できちんと配布されたものなのですが、記憶に間違いがなければTwitterアイコン用として配布されたものなので、改めてここに設定するのも気が引け…。ということで、自分が撮影した富士山の画像から適当に選んで変更しておきました。

　確かにプロフ画像の写真ボタン周辺をいじったりもしましたが、キャンセルをして、一般的に言う「変更」はしてはいないんですよね。キャンセルした、という行為が画像を捨てるという意味ならば、その際に「捨てた」のかもしれませんが。いろいろと謎が多いサービスです、ハイ。

（黒丸状態を見た最初の感想は、あ…余計なことをして運営さんに凍結されたかな？でした。）

●不具合検証、速報版２（2015/03/12）

　Ｈ３タグ周りの挙動について、さくっとした検証をしてみました。

　画像、フチ有りにすべきだったと後悔。とりあえず、最初の画像では行を選択してH3を適用しています。上の文章までは1行、下の文章まで2行の空行があります。

　次に、そのままH3のボタンをオンオフしてみると…上の方にある行だけ、何故かH3が適用されたり、解除されたりという「連動」の状態になります。もちろん、画像のように選択されていないのに、です。「え？」みたいな謎な挙動。画像内にもありますが、下の文章に対してはこのテストでは一切影響していません。空行が２つあるか否かが分岐点になる可能性もありますが、それについてはまだテストしません。（一応、1行目だけを正しく選択して、H3を解除すると通常のｐタグで括られた段落に戻り、brタグも内包していることは確認しました。）

　「2」の状態から、H3とH3の間の空行にダミーのテキストを入力してみました。空行に対してはH3のタグが適用されていない模様。つまり、行それぞれに対してH3のタグが始めと閉じになって、きちんと（タグ的な意味で正しく）適用されている模様。
　「お前が何を言っているのか分からない」という方は、ちょっとHTMLの初歩でも検索して、さらっと眺めてきてもらえば分かるかと思います。「不具合を～」の前に＜h3＞があって、「～よっと。」の後に＜/h3＞になっているワケではない、くらいの意味です。（＜＞は、意図的に全角文字で記述してあります。半角でも問題ないとは思いますが…。）

　もちろん。見た目の問題ではなく、そもそも行が違うのでｐタグの扱いがどうなっているのか？などという技術的な問題などは知る由もありませんが…ｈタグに内包出来ないタグ（ｂタグなど）は混ざることはなさそう、という感じにブラウザ上からの観察では見受けられました。それが本当かどうかは知らないけど。←

　そうそう。ページ単位では分かりやすいソースが表示出来ないんだけれど、文字列を選択してソースを表示させると見えちゃうので、一応確認してみた画像がこちら。

　h3部分に限定して反転表示させていますが、何も入力していない空行を含めてｐタグで括られた「（HTMLにおける意味上での）段落」には、何故か改行タグが入っています。注目したいのは、選択していないのに選択されているような挙動を示した1行目。ｐタグの中に改行タグが見当たらない！のです。自動生成されるものなので、私が消したとかいう話、ではありません。最初からないのかなどは確かめる気力もなくなりましたが、改行タグが実は「ストッパー」的な役割をしているのではないか？みたいな推測をしたくなります。

　ついでにいえば、「（上記ソースは、画像挿入～中略～です。）」という段落がありますが、ここはセンタリングをしてあります。注目して欲しいのはそこではなく、あったであろう＜br＞（改行タグ）が「該当段落から消えている、ない」という点。ｐタグそのものがｈタグなどで消えた場合や、ｐタグが初期状態ではなく、text-alignなどの属性を追記されるタイミングで、なんらかの理由で必要となっている＜br＞タグが消失する。それによってユーザー側からすると「なんだこれ？」な挙動になる…ような気がします。

　なお。リンクを含む段落もありますが、そこでは改行していないのに改行タグがある状態が保持されているので、リンクの場所によるのかもしれませんが、上述したストッパー的な役割としての改行タグは機能しているものと思われます。

　あと。珍先生のSSで気付いたのは、ここまで私が「改行タグ」と呼んできた＜br＞、確かに改行を意図するタグなんですが、半角スペースとして表示されるブラウザもある…んですよね。実際に改行が生じていないだけに、ちょっと特殊な用途で使っていそう、です。

追記：その後、選択範囲をちょこっと変えて（ブラウザからの見た目は全く同じ！）みたら、全く異なる挙動に。テキストエリアの１行目はｐタグがh3タグに完全に置き換わるのは仕様（繰り返し確認できた為、）と考えてよさそうです。

　問題は「安定しない」部分。半角文字など全然選んでなんかいないのに、なぜか前の段落の＜br＞＜/p＞または＜/h3＞部分が選択出来てしまうとか、ワケが分からない…という感じに。h3を適用した後、ボタンをオフ・オンしているとすぐ前の段落が（上のサンプルだと「あああああ」だけ、）h3の巻き添えになりました。仮説としてかなーり甘かった模様。noteの技術部、なんとかしてくれ。（他人事）

いろいろ面倒そうなので、やはりまとめて週末以降に眺め直します…。

●不具合検証、速報版（2015/03/12）

　ちょっと準備しておこうかなと、検証用テキストを適当にタイプしたノートを用意して、ソース（厳密にはページ情報のみ、）を表示してみたら…。

　新規ノート作成、というのは分かる。参照元なる場所が、私の作成している文章なので私のアカウントであることも分かる。だが、meta要素に表示されている、知らない他人の要素はなんなんだ…？私はFirefox 36.0.1で「駄文テキスト」をタイプしていたし、SSもそれを証明している。そもそも。そろそろWin7もお払い箱になろうかという世の中で「x-ua-compatible」がIE=10の設定を使っていたりするから、（非対応の）IE11辺りに嫌われるのではないかい？なんてことを考えてみたり。

　推測でしかないけれど、書き始めた直前に保存された（システム的な意味で確定、格納された？）ノートのmeta要素が参照されてしまう、編集画面上だけの不具合であって欲しい…。

　ということで。気になる公開後の「駄文テキスト」のmeta要素を表示してみたら以下のように。

　これさぁ、正しいといえば正しい（noteの営業的な意味でのみ、）けれど、「どうして検索にHitしにくいのか？」という疑問まで解消しましたわ…。何をどう書いても、noteのサービスのことしかないんだもん。個人レベルのウェブサイト的には、テンプレといえばテンプレではあるけれど、各アカウントで設定していることなどが一切含まれないのね。というか、編集中に見えていた（他人の）情報、あれくらいの情報がdescriptionの半分くらいあてもいいと思うんだけれど、ダメなんですかね…。

　珍先生の『味処 渋谷』は、記事の作業をしている最中に課金があり、その際に参照されたのが、meta要素の他人の記事、またはアカウント名だったりしそうな予感。

　これ、検証も進めないとアレだけど、運営サイドが内部挙動をきちんと分かってないかもしれない悪寒。

●動作検証の対象というか宿題予定（メモ）（2015/03/12）

　珍先生はじめ、noteの不具合的な挙動に関するノートやマガジンなどがそれなりの数で見つかったので、「そこんとこどうよ？」という検証を近日実施予定。

　もちろん。部外者（＝非note運営）による、目に見えた形での挙動の記述になるので（もちろん予定）、有用性はイマイチ…かも。

割と大事なことなので：ちなみに。中村珍先生の有料noteの購読用アカウントではありますが、珍先生のために（検証っぽいことを）やっている訳ではなく、個人的に「こういう謎挙動が大好物だから」ですので、あしからず。

参考記事
・noteのネガティブ挙動に関するメモ

●装飾用文字選択方法の暫定対処案

　やはり「選びにくい」と感じることが多いのですが、マウスによる選択の暫定対処方法

・選択したい部分（文字列）を後方から前方に向かって選択する

　ひとまずこの方法で選ぶ限りなら、比較的ざっくり選択しようとしてもよい感じです。というのも、前方にも範囲外の規定（下の記事参照）があるようなのですが、人間の手の動く速度より、範囲選択の反転表示の方が一瞬早く表示されるので「手が止まりやすい、止めやすい」。よって範囲内で止められる…というオチ。後方に向かって選ぶ分には「それ」がとても分かりにくいので、体感してもらうのが一番かな、と。
　一応、ドラッグ中にカーソルの形が変わってしまっても、編集時のカーソルの形の場所まで戻ってくれば、パレットは表示されるようなので、「カーソルの形状から目を離すな」というのが後方に向かって選択する時の目安になるかな、なんて思います。（ムリダロ）

　ま。システムとしては「ダメ」なんですけどね。（2015/03/12）

●2月22日現在に感じている、不具合的な挙動について

　ある程度以上のストレスフリー感に歓喜したいところだけれど、新たに気になる症状が。noteを使っていくうちに気になる話だと思うので、症状の報告例などはかなり少なそう。むしろ「ない」レベルであろう、細かいお話を少し。（いろいろなBlog投稿システムなどを利用してきたので、それらと比較すると「あり得ない」レベルのお話なのだが。）

１．既に公開済みのテキストの編集時に、任意の場所の上にテキストを追加したい場合、すぐに段落を変える（空の段落を挿入する）ことが出来ない場合が多い。（当面の対応策：違う場所で行頭にカーソルがある時、丸が黒地で白文字の「＋」が出る場所を作り、それを見てから実際に行いたい編集を始めてみる。ただし、すぐに結果が出るとは限らない。）

２－ａ（誤った認識）「Ｂ」（ボールド）機能を使っており、前後に「＋」マークが生じないようなテキストを書いてしまった場合、上下に空の段落を挿入し、段落全体を選択して太字を解除しようとしても、機能選択をするパレットが出てこない。

２－ｂ（正しいと思われる認識）「Ｂ」機能は、段落全体を選択して一括して解除することが出来ない。また、画面上での表示行が変わっている場合、その選択範囲が短くても、太字が適用されている範囲を選んでもパレットが出ないことがある。（出ることもあるが、法則性などは不明）

３．（項目２を検証中に確認出来た点）この記事の下にある、別見出しの2月22日付けで書いた記事で、上記の現象を確認しつつ、解除方法などを模索をした。

　変な位置をボールド（太字）にしてあるのは、ここでの説明で利用するため。PCからブラウズした下の状態で、「います。」を選択して解除は普通に行えるが、「ます。現（私の表示方法での行末の文字が「現」の字、）」と選ぶとパレットが出ない。しかし「ています。現」と選べばパレットは出る。文字効果が設定されている先頭から選べばパレットは出る…のかも。（実際は、少し長めにドラッグすれば出ないので要注意。）
　だが、その1つ上の段落の「●【修正】画像の～」は、先頭の「●」から問題を選択する際、「題」の文字より少し後方までカーソルを画面上で流して選択すると、パレットが出ない。しかし、文字の途中くらいで（文字の2/3程度をマウスオーバーして）反転表示させた場所でマウスを止めた場合、パレットは出る。要は、大雑把なアクションで行末までを選択した場合、パレットが出ない。垂直に移動して行を跨ぐ選択もパレットが出たり、出なかったりと、別個の理由がありそうだけれど、一般的な編集作業では不便なので、ちょっと体感的に訳が分からない感じ。
　全く新規にタイプし始めた長文であれば、任意の長さでの強制改行（Shift＋Enter、すぐ上の「感じ。」と「全く新規に」の間で行っていること、）を行ってもパレットは表示される。（段落を跨ぐと、やはりNGになる。段落超え出来ない部分は仕様だと、一旦理解する。）

　追記の追記：全くの新規の文章でも、最後にマウスのボタンを離した場所が「編集カーソル」からOS標準の白い矢印（テストした環境は、Win 8.1＋Firefox 35.0.1）に変わった後ならば、パレットは表示されない。どうやら、テキストが表示されている周囲１文字弱程度を外れてマウスが外に出た場合、（仮に画面上では選択されているように表示されていても、）選択が無効となる模様。テキスト内では段落の境界（見えない）を超えた時点で「無効」な判定となる模様。（その際はカーソルも変わらないので、ユーザー的には非常に分かりにくい。）

上記文章の補足用簡易図　原寸2倍。（02/23追加）

　面積的な意味での小さいサイズの画像が常にセンタリングでしか入らないのも（装飾機能がやや少ないだけに）、少し不便に感じている。しかし、ちょっとした装飾の再編集作業で、その修正作業が非常に困難に感じられるのは、比較的早目に改善して欲しい課題、だろう。「売り物」を作りたい人たちがいるであろうだけに、運営サイドに対しては（非常に大変であっても、）今後の速やかなシステムの改善・進化に期待をしたいところ、である。用意した売り物はよいのだが、売る形にする時点で劣化してしまうのでは、もったいないとかいうレベルのお話では済まないのだ。
　とりあえず。編集中にマウスを移動させてはいけない領域がある（だろう）ことが、再現の面から分かった（気がする）。個人的には納得出来る範囲の挙動なので、しばらくは対処療法的に操作していくしかないようだ。（2015/02/22 初稿、同年02/23 画像追加等）

●【修正】画像のアップロード位置がズレる問題

　1月17日付の記事の内容は、既に修正されていることを確認しています。現在は、カーソルのある位置に画像が入ることはありません。

　実際にはもっと前に動作確認をしましたが、記事化が遅くなりました。情報の提供元は、漫画家の中村珍先生（@nakamura_ching）。該当ツイートのURLはこちら。動作の検証も、そのツイートを読んでから行ったので、実際に動作確認をしたのはその日付です。（2015/2/22）

●画像のアップロード位置がズレる問題

　画像Up時におかしなところに画像が挿入される問題、既に指摘されておられる方がいらっしゃったようなので、そのnoteをメモしておきます。

・【ＰＣ】テキストで画像を挿入した時、意図しない（マウスカーソルがある）場所に画像が追加される

　これ、私が何度か確認している範囲では、またちょっと違うお話のような気も。カーソルの点滅位置ではない、ということがポイントなると思うのだけれど、カーソルを文章がない下の方に置いたままでもそうなるような。

　あ、いや…そういうことか！挿入のための画面を呼び出して、ファイルの位置を選択するウィンドウの位置に（ぼーっとしていると）入ってるんだ…。ファイルのアップロードをクリックしたら、マウスカーソルを画面下の何も書いていないエリアまで（なるべく素早く！）振っておく。これで最下行…というか、本来意図している位置に画像が入った…。マジか、設計者。（Win8.1、Firefox 34.0環境下で再現。35.0での確認はとりあえず省略。）

　今のところ、ファイル選択のウィンドウ位置を変更することも出来ないし、自分の意識をかなり高めにするしかない、ってか…。はい、ひとつ仕様を覚えました。でも、これは早く直してくれ～。（2015/01/17）