わたしはオッサンなんで、このルールは好きじゃないんですよ。
//で始まってると、ルート相対パスと見間違えちゃうんだよね。
それに、ソースファイル上ではそのHTMLがhttpsかどうかがわからないじゃないですか。
自身のドキュメントのスキーマに準じたURIの解決に頼るのは、メンテナンス性があるとは思わないんですよね。
Googleが言ってたら正しいと思わない方がいいっすよ。あいつらは自分たちのことしか考えてないっすからね。
- ブコメでGoogleのコーディング規約の批判はGoogleに向けろって言ってる人いました。
- 大事なのは選ぶことだそうですが、スキーマの省略は選ぶべき項目だとは思いません。
- なのでわたしはそれを選んだことに苦言を呈します。

p.23、24

.editorconfigにどう書けばいいかをだな……。

p.25

HTMLのルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。

p.26

正しいHTML

HTMLの正しさとは？
参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。

p.27、28

default.cssの中身がどうなってるか知らないけど、link[rel="stylesheet"]は「そうするほか解決できない」という理由がない限り、htmlのhead要素内に書きましょうね。
あと、CSS ファイルを外部化しただけで「プレゼンテーション（スタイル）と振る舞い（スクリプト）は、ストラクチャ（マークアップ）から分離する」ことができるわけじゃないので、それも忘れずによろしくです。

p.29、30

こういうのは、文字参照で記述しなければならない記号を規定して列挙しときましょうね。

p.31

アクシビリティー（笑）さっきから誤字脱字が多いんだが。

p.32

えっとえっと……「スプレッドシートのスクショです」って説明されて、ユーザーに何がわかりますか？
「このスプレッドシートでは、年を行に、月を列した2010年から 2015年までのアクセス数の分布が表でまとめられている」くらいのコンテキストを入れていきませんか。
気遣いではなくウェブサイト製作者の責任として。
ちなみにalt属性のテキストは、コンテンツマネージャーが考えるべき範囲だと思ってます。

p.36、37

クォーテーションとかはさ、lint設定を開発に組み込む方法を紹介すべきじゃないですかね。
gulpに普通にありますよ。 https://www.npmjs.com/package/gulp-htmlhint
あと、容量の削減とかいうなら、空要素のスペースとスラッシュのことも、書いて欲しかったっす。
正直、開発ソースの容量を削減するのは無意味だと思いますけどね。

p.40

CSSの教科書

いやいや、CSS”設計の”教科書ですからね、その本。
脱字なのかな！？

p.42、43

その命名だとまだ粒度が大きくて、何を示しているのかわからないと思うのはわたしだけでしょうか。
それでどのコンポーネントなのか特定できる程度の規模のサイトなら、CSS 設計いらないんじゃないですかね。

p.44、45

セレクタの単語は、むしろ絶対に省略させないようにした方がいいと思うんですよね。
省略していいなら、省略のルールまで決めていきましょう。
教えてgooに非常にいいページがありますよ。 http://oshiete.goo.ne.jp/qa/341377.html

p.49、50

ステートの上書きまでショートハンドでまとめて書くなんてことはしませんよね？さすがに。

p.57、58

HEXの短縮は規定しなくていいと思います。
ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
gulpでできますし、ググれば出てきます。
ちなみに、#f00よりもredの方が1バイト少ないんですよ。
容量削減は人が思いつきでやるには不十分なのです。
そんなのはビルド時に機械がやればいい。
容量の削減を理由に人の行為に制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。

p.61、62

もしかして勘違いしているんじゃないかと思ったんですが、「プロパティの終端」は、「宣言」の終端ではないですよ、一応。

p.63、64

と思ったら宣言のことを「プロパティ名」ってさ。どういうことです。

p.71

TODOでコメント書くのって、一時的なメモというか、あとでリファクタリングする前提のコメントだと思ってました。
だから、TODOで「何のためのものなのか誰が入れたのか」書かれててもどうしようもないような。

p.72、73

FLOCSSとMindBEMdingを共存させるなら、書くべきことが足りなすぎませんか。

p.73

block__element__elementは使用しない

冗長になるからやめようって思ってるなら、やめるのはいいけど、そもそもB__E__EはBEMじゃないってことを忘れないでほしいっすね。
https://en.bem.info/faq/#why-does-bem-not-recommend-using-elements-within-elements-block__elem1__elem2
「冗長になるから」じゃなくて「BEMじゃないから」やめろ、です。

p.78、79

打ち消しを減らすのは悪いことじゃないっすね。
でも、追加的なスタイルの宣言をモディファイアの仕事にさせるのは、なかなか危ないと思うんですよね。
決まったルールもなく大量にモディファイアが増えたCSSはコンポーネント管理されていると言えるんでしょうか。
再利用性？　必要になったら作り直す方が早いと思いませんか？
設計してても作り直すことになると思いますけどね。
あなたはそのプロジェクトのコンポーネントがどうスケールしていくかなんて、予測できているんですか？

p.80、81

言ってることは概ね正しいっす。でもサンプルのCSSにタイプセレクタが入っているのはツメが甘いとしか。

p.87

日本語校正を。

GoogleChromeなら変換時に右側に△マーク〜

それGoogle 日本語入力のことかな〜それともChromeにそういう機能があるのかな〜

p.96

この手の分類で上手くいくというのは幻想。試しに次の画像のファイル名を考えてみてください。
「ボタンを示すアイコンで、テキストが含まれていて、背景で使うことが想定されるもの」

コンポーネント単位で使う画像ファイルと、ページ単位で使う画像ファイルがあるのが変なんですよね。
- 管理区分が横断しているというか。
- 画像もすべてコンポーネント単位で管理すればいいわけなんですが。
  - でもあなたはきっと、同じファイルを別名で複数持っておくことを許してくれなそうだ。

p.98

※svgにすることで1つの画像でまかなえる場合はsvgを使用する

言っている意味がよくわからないです。
インライン SVGを使用してfillプロパティーなどで色のバリエーションを管理するってことでしょうか。だったらsvg ファイルとしては保持されないですが。
もしくはSVG スプライト？　スプライトならpngでよくないですか？　なんでわざわざsvg？
急にsvgが出て来て混乱しちゃう！

p.102

ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
Jadeについては何かルールは設けないのでしょうか。
JavaScriptについては……？

そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。

ルールを設けるのは悪いことではないですが、穴があってはいけません。
- あいまいな基準や不足だらけのルールに、誰が期待できるでしょうか。
エビデンスの弱さも気になります。
コーディングルールの半分くらいはnodeプラグイン互換のlintツールでチェック可能です。

結論：いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

Permalink | 記事への反応(0) | 11:26

2016-03-22

■GoogleChromeのはてなブックマーク アプリさあ

これね

http://b.hatena.ne.jp/viewer

記事一覧でマウスホイールが使い物にならないんだけど

他の人は普通に使えてるの？

Permalink | 記事への反応(0) | 18:52

2016-03-18

■

GoogleChrome 拡張ではてブするときに、引用したい部分をあらかじめドラックしてからボタンを押すと引用符付きでコメント欄に引用文が出てくるの便利。

これでコピペしなくても引用が楽になる。

Permalink | 記事への反応(0) | 13:56

015-06-27ブログ記事のコピーと右クリック禁止でパクリ転載防止する方法トップ >ブログ運営ブログ記事のコピーと右クリック禁止でパクリ転載防止する方法右クリック禁止とコピー禁止のCSSを紹介します。これでブログの記事をパクられた。画像を勝手に利用された、というのが多少防げる。まあ著作権法違反は親告罪なので探して、訴えないといけないけど、その手間は多少減るでしょ。ビックするほど情報リテラシーが低いのでこの程度でめんどくせってなります。CSSでテキストのマウスドラッグでの選択とコピー禁止CSSのエリアに以下内容を記述することで、テキスト選択とマウスのドラッグを禁止してコピーを防止することが出来ます。body{user-select:none;-moz-user-select:none;-webkit-user-select:none;-webkit-user-drag:none;-khtml-user-select:none;-khtml-user-drag:none;}下書いたのに実際にやってないwwあれ？いれた？まぁ、あとで削除しとこまあちなみにこのブログで採用しているからコピー出来ないから簡単にできないよ！！って人いると思います。CSS解除して出来るようにするのが優しさだと思いましたが、めんどくささを体験してもらうためにそのままにします。そのうちもとに戻してるかもね！コピペさせてよ！という人向けにはてなブックマークに書いといたのでそこからコピーすればいいよ。ちなみにこれはFirefoxとsafariとGoogleChromeで有効で、あの憎きIEには通用しないので別の対処方法を入れます。あと右クリック禁止はこれだけだと出来ないのでそれもあわせて対策ちなみにはてなブログでスマホとPCのデザインをわけていると、PCのデザイン CSSに入れてもきかないっぽいので、細かいこと角のめんどくさいので適当にスマホ用のデザインページで<style></style>でくくってフッターにでも突っ込んでおくといいよ。それでとりあえず使えるから JavaScriptで右クリック禁止でコピーを禁止する右クリックで画像保存などができるので、画像保存禁止対策とインターネットエクスプローラー通称インターネットをみるやつの対策をジャバスクリプトでテキストのコピー禁止対策をします。<body></body>の間に以下のジャバスクリプトを記入<body oncontextmenu='return false' onselectstart="return false">はてなブックマークにコメントで書いといたのでそこからコピーすればいいじゃない！これで右クリックの禁止とIEでテキスト選択とコピーができなくなります。はてなブログならフッターエリアにでも突っ込んでおけばいいと思いますよ記事を引用コピペしたい場合 IEでジャバスクリプトをオフにするまあジャバスクリプトはオフにすれば回避されますが、どうせコピペしてパクるような人は、その程度の情報リテラシーなのでほかのサイトに行ってコピペすると思います。世の中の記事はだいたい誰かが同じようなことを書いているものです。調べればなんでも分かるのはそのおかげですし。普通に引用したい人はIEでジャバスクリプトをオフにするか、ソースコードからコピペすればOKです。はてなブログはRSS全文配信なんでRSS からコピペできるはてなブログの場合は、パクりたいブログ記事をRSS 登録すれば、RSS経由で記事を全部一気にコピペしてパクって転載することが出来ます。何でそんなの紹介するの？と言われそうですが、どうやってぱくった！！アップした瞬間にどうやってと思う人が出てくるからです。RSS からパクられないようにするには全文配信のはてなブログをやめればいいんですよね。ある程度ユーザー確保したら、WordPressあたりに引っ越せばいいんじゃないですかね。これで対策はできます。そもそもやだ！ぱくられたくない！と最初から思う人ははてなブログ以外を利用するという選択も必要ですね。パクるのをめんどくさくさせて他でパクってもらう対策ですね結局はパクられる対策としては、めんどくさい、なんかちょっとやばいかもと思わせて自分のブログでパクられる確率を減らしておけばいいんです。コピペ出来る方がそのサイトでわからないことがあったらすぐに検索できるからやらない方が便利よ。これやると、引用して言及してくれる人とはいなくなりますので、まぁ、いちいちやらないくてもいいとおもいます。今回は試しにこんな方法もそういえばあるよって感じで紹介。記事がパクられたら楽しんで記事ネタにしてストレス発散キュレーションメディアやバイラルメディアでパクられるのは、まあよく言われる有名税的な感じで仕方ないわ的な感じです。親告罪だしみつけだすのめんどくさいし。もし見つけたらそこで怒るよりも、パクられた時に楽しんで、このサイトにパクられた～！記事ネタ増えた～！やったね、試しに少額訴訟でも起こしてみようとか、プロバイダやキュレーションメディアなどに情報開示請求してみた。とかそういう遊びをして見るといいと思います。パクった人じゃなくて、ブログサービスなどを提供している会社やパクリメディア本体に集団訴訟してみた。とか遊べばいいんじゃないんですかね。テキストなんて海外で英語翻訳されたらもう調査するのも大変だし。100%防ぐのは無理ですからね。死んでから国ごとによって違いますが著作権なんて切れたら無料で使えるようになるし。あまりイライラしてもしょうがないです。まあ著作権は権利者の保護と文化の発展の両方の意味合いがあるので、文化に貢献した！とか思っておけばいいんじゃないんですか。

Permalink | 記事への反応(1) | 11:34

2013-11-25

■はてブにブラウザ 擬人化関連のまとめサイトのエントリあったんだけど

なんでIEが凄く遅いって事になってんの？

記事読んで、あれそんなに遅かったっけ？と思い、GoogleChrome、Firefox、IEそれぞれ最新版で同じブラウザベンチマークいくつか回してみたんだけど、描画速度の速さは殆どがGoogleChromeよりは若干遅いけれど、Firefoxよりは明らかに速かったぞ？

もちろん三つともアドオン等は一切入れてない、ほぼ完全に素の状態で。

http://anond.hatelabo.jp/20131125003224

見たけりゃ見せてやるよ(震え声)

GoogleChrome	81.2ms
IE	153.2ms
FireFox	219.7ms

Permalink | 記事への反応(4) | 00:13

2013-08-11

■http://anond.hatelabo.jp/20130811003034

GoogleChrome自体は相当初期のバージョンから普通にパスワードを平文で表示可能だったんだけどな

少なくとも3年前のバージョンの時点で可能だった

これがなんで今頃騒ぎになってるのか、Google自体も困惑してるんじゃないかと思うよ

Permalink | 記事への反応(0) | 00:36

2013-08-09

■Mac+googlechromeのパスワード 管理

http://blog.elliottkember.com/chromes-insane-password-security-strategy

http://news.mynavi.jp/news/2013/08/08/054/index.html

http://www.itmedia.co.jp/enterprise/articles/1308/08/news033.html

クリック一つでパスワードが見えちゃう問題について。

このニュースは取り上げるサイトによっては、Windowsで動作確認した記者がFirefoxと比較してどうのこうのと語ったり、ブコメもドヤ顔で「今まで知らなかったのか」「気付かなかった奴が騒いでる」って見方のブコメを散見するがそれも違和感を感じる。

そういう話じゃないんだよな。

Macでは、Chromeが正式版になってパスワード管理がキーチェーンと連結されて実装された当初、Chromeの設定画面からパスワードを確認する場合はキーチェーンが立ち上がる仕様だった（はず）。

（ベータ時代はパスワード関連の設定画面ではまだ開発中と表示されたはず。ただちょっとそのあたり、ベータが取れる前後は記憶が定かでない。なんせベータとの違いがよく分からない有様だったから。記憶違いだったら申し訳ない）

http://internet.watch.impress.co.jp/docs/news/20091209_334515.html

例えば、Mac OSのパスワード管理機能「キーチェーン」がGoogle Chromeに統合されたため1カ所でパスワードを管理でき、他のブラウザで入力したパスワードをGoogle Chromeで利用できる。

あくまでキーチェーンの扱いはSafariと同じだったし、この時はSafari からパスワードを直接インポートできなかったと記憶している。

ちなみに、ヘルプの記載でも現在もキーチェーンで保存してるとしてる。

https://support.google.com/chrome/answer/95606?hl=ja

ウェブサイトのパスワードを管理する
Google Chrome では、さまざまなウェブサイトのユーザー名とパスワードを保存することができます。そのようなウェブサイトに次回アクセスすると、ブラウザによって自動的にログインフィールドに入力されます。
これらのパスワードは、その他のブラウザのパスワードが保存されているのと同じシステムに保存されています。Mac の場合、Google Chrome はキーチェーンアクセスを使用してユーザーのログイン情報を保存します。

おそらくこの記載はキーチェーンとの連携ができるようになった当初のものだろう。この後ろにchrome アカウントの話を付け足したのか。

とにかく、MacOSのほぼ全てのブラウザがキーチェーンによるパスワード管理をやってて（キーチェーンはアクセスできるアプリケーションを管理でき、ブラウザ以外も依存している）、ここに委ねてる。

だからパスワードの確認はキーチェーンで行う理屈で、Chromeのベータが取れた当初はそうだったはず（私の記憶では）だし、そうでなくてもGoogleの説明を受けたMac ユーザーはそういう認識だ。

元記事もSafariとの比較で言っている。

ようするに、Mac ユーザーからするとSafari等のキーチェーンを利用するアプリケーションと同様の方法で管理してますよって言ってるのに、実態が違うじゃないかっていう指摘だ。

（たしか WindowsにおけるIEも同じようにシステムの管理だと思う。この話において、Mac/Windows 対応であるFifefoxは例外なんだが、その管理と同等のレベルにしようという事で、それに倣ってマスターパスワードを装備している。ちなみにデフォルトじゃないという反論の意味がよく分からない。）