2015年11月02日

IFTTTの試験

IFTTT、RSS更新をトリガーとして「with image」でレシピを作成すると、画像が何もないときにエラーになって、何も投稿してくれない。
これはまずいので、「with image」抜きのレシピを作って、あえて{{EntryImageUrl}}を入れてみるとうまくいくかしら。
41QIoohdKhL._SL500_AA300_.jpg
【関連する記事】
posted by シマウマ at 20:24| Comment(0) | テスト | このブログの読者になる | 更新情報をチェックする

【サイトのスマホ対応】target-densitydpi=device-dpiはやめとこう

Android4.1の標準ブラウザとchromeで、どうも表示文字サイズなどにかなり違いが出てしまう。
標準ブラウザだと文字が小さい。つまり大きな画面を表示しているようだ。
その両方で
alert(window.innerWidth);
とすると、違う数値を返してくる。
My端末の横幅は480で
標準ブラウザでは「479」を返してくるが、
chromeは「328」!
へえー。。。。
へえー。。。。。。。。。
どうりで違う文字サイズ(見た目)になるはずだわね。
あらためて試験すると↓こうなった。
20151101_095937.png 20151101_100011.png
こりゃたいへん。
だが、標準ブラウザとchromeでさほどの違いなく表示されるページはごまんとある。
ウチだけなんでなんで? とあちこちつついてみると、
viewportの設定に問題? 原因があった。
上記htmlのviewportは、
<meta name="viewport" content="target-densitydpi=device-dpi, width=device-width, maximum-scale=1.0, user-scalable=yes">
だったが、このうち原因となっていたのは、
target-densitydpi=device-dpi
の部分だった。これを設定していると、標準ブラウザが480ベースを守ろうとする。chromeは守らない
ということがわかった。この記述をはずしてやると上記スクリプトの返りは
標準ブラウザ:320
chrome:328
となりかなーり近づく。当然文字サイズなどもほぼ同じサイズで表示されるようになった。大きなデザイン上の相違もなくなった。
chromeはシェア率も高く、こちらの表示を妥協するわけにはいかなかったので標準ブラウザの動きをそれに近づけることができて、まずはよかった。。。かな。
でもそもそもはchrome(など)の挙動が変なんじゃないのか??
これ(target-densitydpi=device-dpi)を入れ知恵したやつ、あるいはchromeの挙動そのもの、なんかいろいろ納得いかない、いつもの奇妙な世の中だが、ここはいつもの忍耐、
「target-densitydpi=device-dpiはやめとこう」(唱和願います)
ということにして生きていこう。

≫続きを読む
posted by シマウマ at 12:04| Comment(0) | html-css | このブログの読者になる | 更新情報をチェックする

2015年10月30日

【サイトのスマホ対応】youtube埋め込みに注意せよ

Android板chromeでは問題ないが、標準ブラウザで動作が停止してしまう現象。
パートごとにコメントアウトしていくと、youtube埋め込みが原因だった。
1ページ内にたかだか4つの埋め込みをしているだけだったが、それでは当方の端末では駄目だったようだ。
http://blog.psocafe.com/view/2968
こちらの助言にしたがって埋め込みを減らしてサムネイル画像に変更して解決
サムネイル画像は、youtubeから常にゲットできるんだねぇ。
http://youtubethumbnailgenerator.blogspot.jp/

posted by シマウマ at 11:27| Comment(0) | html-css | このブログの読者になる | 更新情報をチェックする

2015年10月28日

IEで img タグの width が効かない

IEで<img>タグ内のの width が効かないことがあった。
<img src="…" width="70">
で原寸表示されてしまう。
<img src="…" style="width:70">
で正しくリサイズされた。
なんだろ。。。

posted by シマウマ at 10:33| Comment(0) | html-css | このブログの読者になる | 更新情報をチェックする

2015年10月27日

noscript処理は必要なんだろうか。

いまどき必要?
さて?
やる必要があるとなると、けっこう手間ですよね。

タグ:javascript 忍耐
posted by シマウマ at 23:31| Comment(0) | javascript | このブログの読者になる | 更新情報をチェックする

【サイトのスマホ対応】お役立ちリンクとメモ

サイトのスマホ対応を数年おくれくらいでしたので、お役立ちリンクとメモ。

(1) http://mattkersley.com/responsive/
ここは、スクリーンサイズ別のサイトの見え方をシミュレートしてくれるところ。
すばらしい。
UserAgentは変わらないのでこれだけでスマホ対応というのはちょっと無理があるかもだけど、だだだっとウィンドウを並べてくれるので、わかりやすい。

(2) http://walking-elephant.blogspot.com/2012/04/user-agent.html
これは少し古めだが、超驚いたサイト。
UserAgentを変更してスマホのシミュレートするのは、chromeやIEで拡張機能なしで簡単にできたんだね。 全然知らなかった。あんまりネットでも紹介されてないよね。。。アタリマエすぎるのかな。
携帯(ガラケー)のシミュレートもできるのかな。やってみてない。
chromeはエラーチェックなどもしてくれるみたいだけど、うーん、まだ使いこなせてない。
IEのF12 開発者ツールではWindowsPhone以外のUserAgentは自力で入力する必要がある。
UserAgent一覧はこちら。
http://www.openspc2.org/userAgent/

(3)cssの切り替えについて
http://webdesignerwork.jp/web/responsivewebdesign/
基本、上記を参照してやってみた。スクリーンサイズだけを根拠にした切り分け。
要するに @media screen and (min-width: 641px(例)){…の使い方を勉強したってこと。
上記のうち、タブレット判定(641px-768px)は要らない気もする。シミュレートしたり実機で見たりしてもPCと同一のコードで現状はいけてる。スクリーンサイズだけで対象をタブレット扱いすることも無理があるし。
ほかにスマホ判定やタブレットが必要な場合はphpで。当方はスマホ判定だけしているので以下。
という感じ。
javascriptでもできる。
https://w3g.jp/blog/js_browser_sniffing2015
こっちの方がいいかも。

でも、スクリーンサイズとは別にスマホ判定していいことって実際にはあんまりないような気も。
スマホだけ <a href='tel:… を使う、くらいかなぁ。
そんなのPC環境でもあってさほど悪くないし、実際のところスマホかどうかの判定っていまやあんまり意味なくて、スクリーンサイズ判定で必要十分ではないかしら。

(4) CSS切り分け以外に必要なこと
body{ -webkit-text-size-adjust: 100%; }
は必須。
<meta name="viewport" content="width=device-width, maximum-scale=1.0, user-scalable=yes">も必須。
viewportについてはこちらも一読を!
当方は多数の項目を一覧表示させたインデックス画面から各項目の詳細情報を見せるとき、PCではインデックス画面内に表示してきたがスマホでは別ウィンドウを開くように仕様変更した。
このように<a>タグの行き先自身を変えるようなときはCSSだけではできないので、スクリーンサイズなりスマホなりの判定で条件分岐してやる必要がある。

(5) 画像サイズ
上記参照(3)にあるようにcssで
img{
max-width: 100%;
height: auto;
width /***/:auto;
}
としとけばおおむね解決だが、
  • スマホモードでメニューを縦並びにすることになるとメニュータイトルに使ってる画像などが100%では幅不足になる。スマホ表示で縦並びにする画像は幅640pxで作っておいてwidth指定するのが吉。
  • lightbox_plus利用のページでは上記のimgタグ一括の定義では問題が出た。lightboxの別窓がいつまで待っても開かなくなった。lightboxで開かせる画像ではこの定義をはずす必要がある。
(6) ガラケーのシミュレート
今回の作業とは関わりないが、ガラケーのシミュレートならここが定番。
Goo モバイル サイトビューワ
http://emu.mobile.goo.ne.jp/emu/emu.php
docomoが作っているスタンドアロンのアプリもあるが、それよりもいい。
実は携帯用の関連サイトを検索する場合もこれを使っていたりする。


posted by シマウマ at 00:04| Comment(0) | html-css | このブログの読者になる | 更新情報をチェックする

2014年02月04日

dlvr.it

IFTTTは本文全文ではなく概略を投稿するためには、RSS自身からcontent(本文)をなくさなければならない。contentをなくせばdescription(概略)を参照してくれる。
RSS自身にはcontentを含めたい気もする。だってほかで使うのに不便じゃない?
とうことで、RSS解釈の自由度が高いという噂のdlvr.itを試す。
41QIoohdKhL._SL500_AA300_.jpg
文章中に画像を入れてみる。
dlvr.itは、RSSをTwitterやfacebook、Google+にも投稿できるが、さすがの商人、Google+へ投稿するためには有料プランに申し込まなければならない。一月千円、一年で一万円ほどかかる。ちょっとなぁ。
などと、本文を多めに書いてみる。
posted by シマウマ at 17:57| Comment(0) | facebook | このブログの読者になる | 更新情報をチェックする

2014年02月03日

SeesaaのRSS

ブログの記事の概要を自動でfacebookに転送したい。
facebookアプリであるRSSGraffityはまずまず安定して動いてくれていて重宝しているけれど、なぜか時々文字化けする。これを解消するために別の転送方法をさぐっているわけです。
IFTTTは、RSSをfacebookやTwitterその他のSNS、あるいはEvernoteなどにも転送をしてくれる画期的サービスです。様々なサービスサイトを使ってやっていたことがこれだけでできるのではないかと期待を抱かせます。(Google+にはいまのところIFTTT単体では対応していないです。IFTTT→Buffer→Google+という経路で実現できます。)
IFTTTは割と転送内容が自由に設定できます。
{{EntryTitle}} {{EntryUrl}} {{EntryContent}} …
といったアイテムが自由に配置できるスタイルになっています。素晴らしい。
しかしながらなぜか記事の概要(名付けるとすれば {{EntryDescription}})が選択肢に無い。
したがってfacebook転送内容に本文記事を「すべて含めるか/何も含めないか」の選択しかできません。

というところが現状。
ではRSS自身に本文(content)を含めず概要(description)しかないとしたらどうなるかの試験中です。
posted by シマウマ at 10:45| Comment(0) | facebook | このブログの読者になる | 更新情報をチェックする

2014年02月01日

IFTTTでtwitterにも

IFTTTすごいかも。これでRSSからのFacebokとTwitterへの投稿はできる。
Facebookへの投稿は「Create Link Post」が適当。
ただし、、、、残念ながら現状ではGoogle+には対応していない。
惜しい!!
41QIoohdKhL._SL500_AA300_.jpg
これは文章中に画像がある場合のTwitterへの投稿試験。
posted by シマウマ at 15:31| Comment(0) | facebook | このブログの読者になる | 更新情報をチェックする

IFTTT Create Link Post

IFTTT に Create Link Postで投稿してみる。
途中の画像
Toco Toucan.jpg
少し長めの文章。
【覚え書き】
facebookページからRSS Graffitiを削除してしまったのだが、復活したくなった。
これが意外に面倒だった。
パーソナルページにはアプリが残っているから、facebookページへ登録するだけなのだが、facebookページへのアクセス許可画面でエラーになって前に進めなくなった。
結局、facebookページの管理者に別の人になってもらって、その人にRSS Graffitiをインストールしてもらう形で復活できた。
他のアプリでもそういうことがあるのかも。
posted by シマウマ at 14:46| Comment(0) | facebook | このブログの読者になる | 更新情報をチェックする