SASSでアンパサンドを後置できるって知らんかった

こんにちは!
またちょっと間があいてしまいました、有村です!!
日々コードレビューをしていると、新しい考え方や「ほうほうそりゃ知らんかった」って書き方に出会えて楽しいですね!
というわけで、今日のテーマはSASSでアンパサンドを後置できるって知らんかったです!

私がアンパサンド(&)を使うのは、だいたい

こういう、MindBEMdingの記法的な、「前のclass名と連結させる」ときです。

なので、アンパサンドって「前置しかできない」って思い込んでたんですが…。
普通に後置できるらしいですね。

ここで振り返り。
アンパサンドは「親セレクタの参照」。
そして、後置もできるってことは…

みたいな、「基本は display: block; だけど、fugaの子孫要素として居る場合は display: inline;」みたいなこともできるわけですね!

そこで私は期待した………

みたいに、子孫要素じゃなくて、要素セレクタ + class名指定で、限定指定みたいなことできるんじゃね?と…。
↑で言うと、「基本は .btn は display: flex; だけど、button要素の時だけは display: block;」みたいな。

それを考えた理由は、かつてのbutton要素に display: flex; が効かねぇの記事から。

そこでこんなコード書いてみた。

お気付きの方も多いでしょう……

ってなった。そりゃそうか。惜しい。

次は、こういう書き方をしてみた。

アンパサンド前のスペースを削ってみた。そしたらこうなった。

「”&” may only be used at the beginning of a compound selector.」

コンパイルすらできなかった!!!!
「&__」はいいけど、「__&」はダメってことね……。

ちょっと調べてみたけど、SASS側でどうこうはできなそう…
なので、実現方法としては

で対応しました…。

ん〜結果は同じなんですけど、この書き方だと「基本は display: block; で、button要素じゃないときだけ display: flex;」って、
「基本と例外」が逆転しちゃってるのが、目的に合ってないような気がするんですよね…。
とはいえ、今はこれしか思いつかなかったので、↑の実装で落ち着かせてます。
それ以外は、視認性も特段悪いわけではないと思うので…。

というわけで!
やりたかったことが完全に実現できたわけではないのですが、アンパサンド後置できる!って学んだことは大きな収穫です!
適材適所で活用していきたいと思いまーす!!

それでは、きょうはこのへんで。

inlineで隙間が発生してしまうのはなぜ?

こんにちは、有村です!
体調崩し気味ですが、比較的元気なうちに記事を書くぞ!!

今日のテーマは、inlineで隙間が発生してしまうのはなぜ?
です!
最近これを人に説明することが多いな〜と思ったので、メモしておくことにしました。
(うまく書けたら 「これ見といて^^」 でやり過ごせるかもしれない!やったね!)

たとえば、このようなコードがあったとしましょう。

これで、実際にレンダリングされるときには、liは横並びで表示されますね。

が!!!!
横並びに表示されたけど………なんかそれぞれの要素に隙間ができるんですケド!?!?
という経験、皆さんおありじゃないですか。
こんなかんじ。
戦士 白魔道士 黒魔道士 竜騎士

なんかよくわかんねーけどスペース空くわーってことで、

みたいに ul のfont-sizeを0にしてみたりとか、

のように繋げて書いてみたりとかしてましたが。。

そもそもなんで勝手に隙間が空くんだ?

てことで、その理由。
Enterキーで改行を行うと、改行が空白類文字として扱われるから。
ということは…実態は、
戦士(ulのfont-sizeで空白類文字)白魔道士(ulのfont-sizeで以下略)黒魔道士(ulのfont以下略)竜騎士(ulの以下略)
こうなっていたということですね!!
だから、ulのfont-sizeを0にしてみたり、繋げて書いて改行を無くすと、不要な隙間が生まれなくなるんですね!

じゃあdisplayがblockのときはどうなるの?と思って調べてみましたが、MDNやW3Cで答えを探し当てることができず…。
が、先人の方々の説明等を読み漁ってみて、実際の挙動と照らし合わせてこうかな?と思いました。

blockの場合、開始と終了タグ前後の改行は無視される。
ただ、

としたときは、黒魔道士の項と白魔道士の項の先頭には空白が入らないものの、レンダリングしてみると、
「黒魔道士は いちばんつよいよ!」
「白魔道士も すきだよ!」
と文章中にスペースが空いてしまいます。なぜなら、開始と終了タグの前後の改行ではないから。

また、もはやブロックレベル要素というものはHTML5に存在しませんが、MDNのブロックレベル要素のページの、

ブラウザは一般的に、前後に新しい行を伴ってブロックレベル要素を表示します。

が理由のひとつなのかなと思いました。
「前後に新しい行を伴う」ことが前提であれば、そこに改行があろうともなかろうとも、

みたいな書き方をしても強制的に行が変わるので、「無視をする」という挙動になるのかな?と推測しました。

このあたりは自分もかなり悩んだので、今回記事にすることで頭の整理ができてよかったです!
それでは、きょうはこのへんで。

JSONとJSONPの違いって?その2

継続は力なり!1ヶ月なにも書いてなかった!
こんにちは継続失敗した有村です。忙しかったの(言い訳)

前々回の ボタン作成で失敗したこと への記事にコメントありがとうございました!
超遅くなったのですが返信させていただきました!
ボタン周りはあれから1ヶ月、さらに色々と気付きがあったので、「失敗したことシリーズ」としてちょくちょく纏められたらいいな〜と思ってます!(どれだけ失敗する気)

さてさて、では今日のお題。前回の続き。
「JSONPを使えば、どうして他ドメインのJSONを使えるの?」という、「は?結論はよ」なところで止まっていました。書きます。

まず、JSONPについて。なんの略かというと…
JSON with padding
…marginとかそういう系?…ではなくて。ここでのpaddingは「不必要な挿入句」とか、要らないけど入れたわ、みたいなニュアンスらしい。

じゃあ何をpaddingしてるの?というと、JavaScript
じゃば…すくりぷと………?

一度、JavaScriptの特性(?)を。JavaScriptは、外部サイトのものでも実行できる。
「あ〜jQueryダウンロードしてサーバに上げてってやるのめんどくせ〜、Googleのとこから持ってくるようにしちゃお」
ってやりませんか?具体的にはこう。

Googleはどう考えても外部サイトですよね。そうじゃなかったらそれは中の人だ。

で、ここで衝撃の事実!(私的には)
JSONPは、JavaScriptの実行だった!!
えーーーーーー!!!!
JSONは、同一元生成ポリシー(XMLHttpRequest)に引っかかるから、別ドメインのデータを読めない。
ならば、別ドメインでも実行できるJavaScriptでデータを受け渡せば良いじゃないか!という発想。な、なるほど…!!

一連の流れとしては、雑にまとめるとこうらしい。

1.
コールバック関数を用意します。その中にJSONデータを利用した処理を書きます。実行時、引数にデータが入ってきます。

2. リクエストを投げます。
3. 「データを引数としてコールバックを実行する」というスクリプトとして返ってきます。1で用意したコールバックが呼び出されます。

4. コールバックが実行されます。

以上。

…ん?でもこれって、JavaScriptの実行を相手に委ねちゃってることにならないか?ということは、悪用される危険もあるのではないか…??
あ!だから適当にJSONP使ったら殴るって言われたんだ!
リスクや信頼性を考慮した上で実装しなさいよ、ってことだったんですね…。

というわけで、「JSONとJSONPの違いって?」の結びとしては…
JSONは同一ドメインでしか使えない。JavaScriptではない。
JSONPはJavaScript。
という感じでしょうか!

そういえば、先輩に「VPNってなんの略?」と聞かれて、「ばーちゃる… なんちゃらねっとわーく……」と答えてしまったので、
過去記事が全く身についてないことが分かりましたね!やった!!
それでは、きょうはこのへんで。

JSONとJSONPの違いって?その1

こんばんは、有村です。
気温の変化で、日々の服装に困る。

で、今日のテーマはJSONとJSONPの違いって?です!

Ajaxとか、フロントエンドならJSONを日常的に使いますね。
でも私、JSONPって、実は使ったことがなかったんです。使っても無意識のコピペくらい。
そういえば、「適当にJSONP使ったら殴る」って言われたこともありましたね…(遠い目)

なので、なんかよく分からないけどJSONPは危険なやつらしいってことと、他ドメインとのやりとり以外では使わないんだなってくらいしか理解していませんでした。
けど、なんでJSONPが危険なの?と改めて聞かれて答えられなかった&ついに使う機会に遭遇してしまったので、
少しづつ紐解いていこうと思いました。

まずは、JSONがなんの略か、から。
JavaScript Object Notation
notationは、特定の記号体系を持つ表記法のこと。なるほど。JavaScriptのオブジェクトの表記法、みたいな感じでしょうか。

MDNを見ると、

JavaScript の構文に基づいていますが、JavaScript とは異なります。

と書いてあります。あくまで別物ということですね。

で、先述のようにAjaxでJSONを読み込んで、それを基にDOMを操作したり(例えば「もっと見る」機能とか)すると思うんですが、
なぜJSONは別ドメインのものを使えないのでしょうか?
そこがクリアできれば、JSONPって要らないはずなのに。

理由は、ブラウザには同一生成元ポリシーというものがあって、自分(つまり表示中のページ)を生成したドメイン以外とは通信ができないようになっているから、らしい。
ええ…でもCSSとかJSとか、外部で読めるやん…と思ったのですが、ドンピシャで「XMLHttpRequest」が禁止されています。

Ajaxを使ってJSONデータ読み込むとき、XMLHttpRequestって使いますよね…つまり……
別ドメインのJSONを使えないのは、同一生成元ポリシーに引っかかるからなんだ!
なるほど…少しJSONちゃんのこと分かってきましたよ!

そしたら次に気になるのは、「JSONPを使えば、どうして他ドメインのJSONを使えるの?」ということなのですが…

まずはJSONをちょっと理解したところで、明日以降の続きに回したいと思います!力尽きた。

それでは、きょうはこのへんで。

ボタン作成で失敗したこと

こんばんは、有村です。
新年度を迎えても、実装でうんうん唸ってます。いつになったら立派になれるんだろうか。

さて、今日は備忘録としてボタン作成で失敗したことを残しておきたいと思いまーす!

何に失敗したかというと、ボタンに当てるCSSの選択と、HTML側の構造です。
(全然まだ最適解だとは思ってないのですが)

簡単に要所だけ書きますが、私こんな感じのソースを書いてました。

やりたかったのは、ボタンの中身を天地中央にするということ。
最初はline-heigetとpaddingを使っていたのですが、font-sizeとの兼ね合いもあったりとかで、「それだと高さを意識してボタン作るのが若干面倒だなぁ…」と思い、上のような形に作り変えました。

flexだとalign-itemsがあるじゃないですか。
そりゃ使うじゃないですか。
そしたらですよ。
実機(iPhone)で見たら崩れてた。

具体的にどう崩れていたかというと、ボタンの文言が思いっきり左に寄ってました。
普段はchromeのエミュレータで実装しているので、全く気付かなかったんですよね…。

なんでー!?って調べてみたら、どうやらブラウザのデフォルトスタイルとdisplay: flex;が干渉し合っており、flexのほうが競り負けているようだと知りました…。
いやらしいのがchromeは問題なく見れるということ。まだ見れてないですけど、IE11も大丈夫らしい。Edgeはダメだとかなんとか。

そこで有村は色々考えました。

1. かつてのpadding方式に戻す。
paddingを駆使して高さを設定するのはやはり面倒では?
高さを設定したいなら素直にheigetを使うべきじゃないか?
よって却下。

2. ボタンってもともと天地中央だから何もしなくてよくない?
わざわざflexを使った理由は、それがbuttonだけではなく、aタグなど他の要素でも使用されるため。
よって、buttonのデフォルトスタイルに頼ればいいや〜が使えない。
これも却下。

3. buttonがダメならinputは?
そもそも試していないけども、inputは空要素なのでbeforeやafterが使えなかったり、小回りが効かない時点で却下。

4. HTMLとCSSを書き換える

みたいな。要は間にspanをかませる。
デメリットとしては、本来ひとつで完結するはずなのに、buttonとspan(場合によってはaとspanなども)のようにHTML側の記述が増えてしまうということ…
けれども、現時点ではこれ以上の策は無さそうだし、「ボタンを配置する時はspanもセットで」というルールがあればいい話なのかなと思ったので、この案を採用しました。

form系はどうも痒いところに手が届かない感がありますね…
いつか「そんな日もあったね〜www」という時代が来ればいいのですが。
ひとまず締めとしては、Appleさん早くなんとかして!!!!

それでは、きょうはこのへんで。

迷いながらボタンを作っている。

こんばんは、有村です。
お花見、歓迎会、懇親会……コミュ障には辛い季節がやってきましたね!

さて今日のテーマは、迷いながらボタンを作っているです。
もちろんボタンってウェブサイトのボタンですよ。有村はフロントエンドエンジニアですよ。

で、ボタンなんですけど…何に迷っているかというと、ボタンをどう設計すればいいの?ということ。

私がまずやったこととしては、

  • それぞれのボタンの共通部位を見つける
  • ボタンのデザインと役割の紐付けをする

でした。
たとえば、「先に進む」や「戻る」的なボタンがあったとして…

  • 共通部位 … 角っこが丸い。font-weightがbold。テキストは天地中央。
  • 先に進む系は背景とボーダーが赤、テキストが白。戻る系は背景が白、ボーダーとテキストが灰色。

みたいな感じ。

そこでボタンを設計しようと思ったところ、先輩に強調されたのが、ボタン自身に具体的な幅を持たせるなということ。
私はなんでだろうと思ったのですが、よく分からないなりにアドバイスに従い、こんな感じのextendとmixinとclassを作りました。

なんかいい感じじゃないですか!?
と思っていた時期が私にもありました。

Aページ「ここのbtn_nextは幅100px、高さ20px、font-sizeは13pxやで〜」
Bページ「ここのbtn_backは幅100%、高さ40px、font-sizeは15pxやで〜」
Cページ「ここはbtn_nextとbtn_backは横並びでどっちも幅を均等に、2つの間にはmarginを15px、高さは30px、font-sizeは15pxにするで〜」

ありますね!あると思います!!!!
つまり何が起きたかと言うと、
ページ(というか配置場所)によって、幅や高さやfont-sizeが違う。
うわぁどうしよう!!!!

んん…まぁできないこともない…でもなんだろう、このオーバーライドっぷりは。
最初のうちはこれでもなんとかなったんですけど、たとえば「入力フォーム系に配置するボタンは常にサイズが一定」とか、別のルールとバッティングした時に、収集がつかなくなったんですよね…。

そこで、一度立ち止まって考え直すことにしました。

絶対に変わらないもの = extend
角っこが丸い。font-weightがbold。テキストは天地中央。

それぞれのボタンとして独自のもの = mixin
ボーダー色、背景色、テキスト色

場所によって変わるもの = ボタン自身は具体的な数値を持たない
幅、高さ、font-size

これをソースに起こしてみると…

からの、

からの、

のように、ボタンの大きさがどのようにあるべきかを別のclassに委ねると、変なバッティングも起きなくなる…!
更に、form_btnはサイズ指定しか持っていないので、btn_backやbtn_next以外のボタンが来ても対応できる…!

また、親にサイズ感を委ねるという意味ではカスケードでもいけると思います。

まだ悩みに悩んでいるのですが、今のところたどり着いたのはこんな感じです。
何が正解かは分からないけど…

「あーこれやっぱり違う!」ってなったら、また記事にしようと思います。

それでは、今日はこのへんで。

colgroupとcolの違いって?

こんばんは。有村です。
またご無沙汰してしまいました。ちゃんと仕事してます。

日々新たな発見というのはあるものですが、最近特に「あ〜そういえば知らないな〜」となっているのがtable
さらに言えば、colgroupとcolの違い。
テーブルレイアウト(笑)とか笑ったりしていましたが、よく考えたら私この子のことよく分かっていなかった。

colはcolgroupの子要素であるというのは大前提として…。
colは列の幅指定でよく使いますが、とあるソースを読んでいたら

という記述がありました。
そこで私は疑問に思ったのです。

と何が違うのか?と…。

というわけで調べました。

Q. colgroupって何してるの?
A. 列を「意味的なまとまり」としてグループ化している

意味的?どういうこと?というと…
たとえば前者、colgroupが2つに分かれている場合の例。

商品名 1月販売数 2月販売数
商品A 5 10
商品B 7 12

これを見ると、一番左の列は「商品名」、あとの2列は「月」を表していることが分かります。
つまり、列の意味として「商品名」「月」という2つのグループができているということです。
対して後者の例だと、

12月販売数 1月販売数 2月販売数
3 5 10
6 7 12

3列全てが「月」という同じものを表しているので、1つのグループにまとめられるという感じです。

ただ見た目を整えるだけであれば全てのcolを同じcolgroupに入れても実装できますが、
せまんてぃっくを意識するなら、tableもちゃんと構造が分かるように組まないといけないということですね!

それでは、今日はこのへんで。

固定・可変・固定レイアウト?

こんばんは、有村です。
花粉症の人、大変そうですね。私はなったことないので分かりませんが…

で、今日のテーマは「固定・可変・固定レイアウト?」です。

固定幅
←可変幅→
固定幅

みたいなことをやりたかったのです。
こいつらの親はwindowサイズで幅が変わり、かつflexボックス。そして要素が「固定・可変・固定」で並んでるレイアウトです。

で、私は最初、CSSをこう書きました。

やりたいことは宣言した!って感じですね。後はflexちゃんがいい感じに横並びにしてくれるやろ〜って思っていたのですが。。

起こった問題:kotei2の幅が維持されていない。

なぜか、きっちりwidth指定しているはずのkotei2が、デベロッパーツールで見ると70pxだったり80pxだったり可変になってしまっていたんです。
お前が可変になるのかよ!!!!
これは困った…

でまぁ早速解決策。

これつけないといけなかった。

でも一体何がいけなかったんだろう?と有村調べました。

まずflexについて。こいつは「余白を埋めるときどうする?」を指定するプロパティ。
flex-growとflex-shrinkとflex-basisのショートハンド。
上の例のように単位なしでひとつだけ値を記述した場合は、flex-growを指定したことになる。

じゃあ次、flex-growって何?という話。
こいつは、要素がflexボックス内での余白をどれくらい占有するかを示すもの。
たとえば、

と指定すると、aとbとで1:2の割合で領域が振られる。

じゃあどういうことだってばよというと、最初の実装例の場合だと、kahenちゃんは「余白をどう扱うか」という指定を何も持っていなかった。
flexボックスちゃんから見れば、幅をどうすべきか分からない要素が中にいるわけで、「あ…じゃあなんかお前には適当に領域取らせるわ…」みたいな処理になったのでしょうか。
それに幅固定の要素も巻き込まれてしまってうまく領域の配分ができなかった。
…という感じかなと思います。

可変だから何も指定しなくていい、という認識は甘かったのですね!
原因分からなくてかなり詰まってしまいました!

それでは、きょうはこのへんで。

MindBEMdingを学んでみた

微妙にご無沙汰しております。有村です。
春を感じるようになりましたね〜、冬が一番好きな私はちょっと寂しいです。

さて今日のテーマはMindBEMdingを学んでみたです。
最近CSS設計を考えるようになったのですが、ひとつひとつの思想をちゃんと理解していないが故、「ARIMURACCS」なる新しいルール(という名の無法地帯)を生み出すようになってしまって…
そこで、やっぱり基本はちゃんと押さえないとねということで、まずはMindBEMdingから学んでいくことにしました。

Q: MindBEMdingって何?
A: CSSの命名規則のこと。
具体的に説明。まず要素を
・ブロック … ひとつのかたまり。箱。
・エレメント … 箱(ブロック)の中に入っている要素。パーツ。ブロック無しでは存在できない。
・モディファイア … ブロックやエレメントを装飾するもの。
の3つで考える。

記法がちゃんと決まっている。
blockとelementを繋ぐときは、アンダースコアを2つ。
modifierを使うときは、ハイフンを2つ。
単語と単語を繋ぐときはハイフンで。

こんなかんじ。
案件やチームによって、アンスコを1つにしたり、単語の繋ぎをキャメルケースにしたり、アレンジを加えるケースもあるらしい。

Q: モディファイアって具体的にいつ使うの?
A: パターンをつけたいときに使う。
例、こんな感じ。

基本形とそのパターンの組み合わせ。
横並びリスト(基本形 + 何個並びなのかのパターン)やボタン(基本形 + 色やサイズのパターン)などでよく使いそう。

Q: ブロックから見て孫要素ができたときは、block__element__elementになったりするの?
A: BEMはHTMLの構造をエレメントによって表す必要はない。
つまりはこういうこと。

photoはブロックから見たら孫要素、さらに言えばphoto-boxの子要素だけれども、ネストの関係性を __element__element などで示す必要はない。

もっとあるけど、基本はこんな感じです。
どうでしょう?MindBEMding。特に複雑なルールでもないので、チーム内で「なんか命名ルール決めないとな〜」となったとき、導入しやすい印象を受けました。

それでは、今日はこのへんで!

strongをそれなりに真剣に考えてみた

こんばんは、有村です。
ぼーっとすることが増えてやばいなと思ってます。春だから?

さて今日は、みんな大好きstrongタグについて考えてみます!
WEBやっててstrong使ったことない人なんていないよね!ね!
さっそく始めます。

Q. 「重要」って、どこと比べて重要なの?
A. コンテンツ中の他の文章

我々の神、W3C様はこうおっしゃっています…

The strong element represents strong importance, seriousness, or urgency for its contents.

コンテンツの〜とか言われても、よく分からなかった有村。
私が引っかかっていたのは、この重要度が「ページ全体における重要度なのではないか?」と思っていたことです。
ページ全体における重要度になる = あっちこっちで使うと、一体どれが本当に重要なのかが分からなくなるのでは?と考えていたのです。

W3Cの資料など読んで、こう考えたら理解できました。

この場合、
「黒魔道士は、他のジョブより強い。」
という一文の中で、特に強いという部分に注目して欲しい!という意図だと思います。

では、この場合はどうでしょうか。

「黒魔道士は、他のジョブより強い。
最新のゲームが欲しい。」
前者は「強い」、後者は「最新のゲーム」という点が、これらの文で重要だと示していると思います。

つまり言い換えれば、「重要度」はそのコンテンツ = 親タグの中だけで有効になるということですね。
なので、他のコンテンツのstrongと比べて「どっちがより重要か」とか、レベルを競うようなものでもない。
もしレベルという話をするのであれば、strongのネストという使い方もありますが、それも同一コンテンツの中だけでのレベルになるのだと思います!

ということでおしまい。
それでは、きょうはこのへんで。