無料ブログ「rentafree.net」の管理人ブログ

document.execCommandが廃止されたとか・・・

先程<menuitem>がFirefoxで無効になった件で記事を書きましたが、
元々の本物のコンテキストメニューでは非表示になっていましたが、コンテキストメニュー風のUIだと「切り取り」「コピー」「削除」の項目が表示されるようになっていました。
こちらの機能について確認しましたが、document.execCommandという機能を使って実装しておりブラウザ標準の「切り取り」「コピー」「削除」と同等の動作となります。

ですが、どうもdocument.execCommandという機能は廃止されたようです。
でも現時点で機能しています。
というかそもそもこの機能は標準化されていない機能だったと記憶しており、廃止されたというより標準化されないことが決まったという感じだと思います。
標準化された機能ではないですが、すべての主要ブラウザで機能するようです。

これも<menuitem>と同じようにいつか削除されるかもしれないので変更したいですが、
こちらは代替手段の存在しない<menuitem>と違いClipboard API というもので代替できるようなのですが、Firefox 87からの機能のようなのでFirefox 87が出てからに考えます。
あと、EdgeにはすでにClipboard APIが実装されているようなのですがMSIEは非対応のようです。
こちらで変更する場合は両対応にできると思います。

ssl.rentafree.netの証明書

letsencrypt がワイルドカード対応になってサービス全体がSSL対応になりましたが、
元々SSLだった ssl.rentafree.net は有料証明書使ってる状況。

3月に期限なんで ssl.rentafree.net もletsencrypt に変更しようか検討中。
サイトシールが欲しいが、letsencryptの方が自動更新で便利だしシールのためだけに有料使うのは・・・

ユーザーサイトもSSL対応させようと思っていじってます。

ユーザーサイトもSSL対応できそうなんで、ユーザーサイトの出力等に変更行いました。
また、現時点で https://ユーザードメイン/ で一応接続可能です。

テンプレート変数
&$BlogTop;
&$CSS;
&$FeedAtom;
&$FeedRss1;
&$FeedRss2;
がこれまでは http:// から始まるURLを出力していましたが // から始まるURLを出力するようになりました。

&$Canonical; は現時点では http:// からのURLを出力します。
設定で https:// に変更できるように考えています。
SSL設定の場合はHSTSをやるかもしれません。

公式テンプレートに埋め込まれているリンク先も // から始まるように変更されています。
非公式テンプレートをお使いの方は、必要なら対応してください。

JavaScript APIのリンク先も // から始まる感じになっています。


Wikiと掲示板も同じようにします。

XML-RPCのパスワードとユーザーパスワードを別のものにします。

これまでブログのXML-RPC機能はユーザーのログインパスワードで利用できましたが、
機能を利用しない場合は無効にすべきだと思うので、仕様を変更します。

[変更済み]
ブログ基本設定にAPIパスワードの項目を設けました。
これがXML-RPC用のパスワードになります。

[現行仕様]
現在はAPIパスワードが設定されていない場合は、これまで通りユーザーのログインパスワードで利用できます。
APIパスワードを設定した場合はログインパスワードでは利用できません。

[将来]
APIパスワードが設定されていない場合はXML-RPCが利用できないようにします。
猶予期間は1ヶ月程度で考えています。

超長期放置のアカウント削除について

現在200日ログインしていないアカウントに属するドメインは配信が停止するようになっていますが、
それより長期で放置されているアカウントについてデータを消してリソースを解放しようかと検討しています。
200日放置で停止されたドメインはログインすると復活します。

削除を実装する場合は1000日程度で考えてます。

停止も200日だと長いので100日程度に減らそうかとも考えたのですが、
どっちもどっちな気がするので現行の200日のままにする方針。

テンプレートの共通化

ブログ、Wiki、掲示板のテンプレートについて、現在はデータベースとCSSの配信システムが分離しているのですが、データベース構造とCSSの配信処理がほぼ同じものなので、
データベースの仕様を少し変更すればデータベースとCSSの配信システムを統一して全体の配信コストを減らせそうなので、共通化を検討します。

やる場合は、
ブログが圧倒的に利用者数が多いのでブログのデータベースをベースにしてブログに影響が出ないようにします。
Wiki、掲示板はテンプレートのIDが変更されるので切り替えるタイミングとユーザーの編集作業が重なった場合影響が出そうですが、利用者数少ないので多分問題は生じないです。

上部帯UI

たまに、上部に横並びのメニューが配置(Windows等のアプリケーションのメニューバー的な)されているようなUIを使用したサイトを見かけますが、
そのようなUIを簡単に実現させられるような機能を実装させようかなーと考えています。

最初、サイドバーを上部帯形式で表示するようなテンプレートを作ってみようかなーと考えたのですが、
当サービスののテンプレートにはタブUIを使用したテンプレートが有りますが、
タブUIは公式Javascriptの機能で実現した上で、それを使用した公式テンプレートを用意するという形で提供し、テンプレート以外でもタブUIが使える汎用性の高いものとなっています。
帯UIを提供する場合も、同じように公式Javascriptの機能で提供した方が良いかな・・・と。

で、上のようなことを考えていて更に気づいたのですが、
既存のタブUI機能を、座標移動できるように拡張すればタブ機能と共通化できそうな・・・

既存コードをちょっと拡張するだけでできそうなので、近日中に作る方向で。

Copyleft 2010-2015

2015年になって日が経ちますが、トップページの「Copyleft 2010-2015」の表示が2014のままなことに気づいたので更新しました。
これ毎年更新忘れている気がしますw
新年の挨拶記事書くようにすれば忘れないかな。


サービスの更新の方は、今月はやらないと思うのですが、
現在のところサービス上でサイトを公開するにはブログとWikiの2通りあり、
ブログは日付順に記事が並ぶため、日記やニュースサイトを作成するのには向いていますが、固定記事の情報サイトを作成するのにはWikiの方が向いています。
ですが、Wikiは公開サイト上での編集を考慮しているためWiki公文で記述してHTMLを直接書かない使い方が基本となります。
管理者のみが編集するサイトを構築するのならHTMLを直接書けて、ブログと同じようにリッチエディタが利用できる方が良いと思うので、
ブログとWiki以外に、そのようなサービスを始めようか検討しています。

あと、現在は「試運転中」とのことにして無料アクセス解析サービスを提供していますが、
こちら利用者が全然いないのと、設置サイト側に何も表示しないので収益化が難しく当初よりあまりやる気がなく、提供サービス数の確保のためにやってた面もあるので、
新サービスを作るのなら、アクセス解析サービスは辞めようかなと思ってます。


ブログエディターのモバイル対応は、相変わらずモバイルのブラウザーがどれもコンテキストメニューとテキスト選択の共存ができていないので目処は経ちません。
しかし、最近Androidのアプリ開発をやろうかなと思ってるんで、
当サービスとは分離することになると思いますが、XML-RPCのブログクライアントアプリを作れないか検討しています。

QRコード・プラグインの仕様変更を考えています

現在のところブログのQRコード・プラグインは、
http://ユーザードメイン/m/
のガラケー用Compact HTMLテンプレートのページを表示するようにできていますが、
スマホが普及してガラケーでWEBサイトを見るという行為は行われなくなっていると思いますので、
QRコード・プラグインでPC用のURLを表示するように変更しようと考えています。

また、現在はサーバーサイドでQRコード画像を生成して保存していますが、ブラウザ側の処理で<canvas>表示させる仕様にするつもりです。
バージョン8以下のIE等古いブラウザは<canvas>に対応していないので、一部の閲覧者はQRコードを表示できなくなります。


詳細な仕様は検討中ですが、QRコードの生成処理はかなり面倒なので、QRコードの型番やマスク処理を固定化してプログラムコード量を減らそうと思います。
現在のところ型番40まで対応しているのでURLの文字数限界まで表示できますが、URL表示だけなら型番5固定で良いかなと考えてます。
型番5の誤り訂正レベルLで表示できる文字数(英数字モード)は154文字までなので、全ユーザーのURLが収まるはずです。

マスクパターンの評価処理は、処理を作るのも面倒ですし、端末への負担も大きそうなので省略するつもりです。
それにより、QRコード・リーダーが誤判別してしまう可能性もあるのかもしれませんが、多分問題ないです。

それか、汎用性の高いQR生成スクリプトを作ってしまって、公式JavaScriptの機能として用意してしまうのも良いかなと思ってます。