Aggregator

Google for Jobs とも呼ばれる求人検索の Job Posting 機能が 中南米のいくつかの国でも利用可能になった。これまでは、米国のみで提供されていた。

- 求人検索のJob Positing (Google for Jobs) が中南米の5か国で利用可能に -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

更新が頻繁なページの AMP 対応のベストプラクティスを解説する。2つの方法が考えられる――「何もしない」と「amp-list」を使う方法だ。

- 更新が頻繁なコンテンツのAMP対応ベストプラクティス -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、高津戸 壮さん（ピクセルグリッド）の『CSS設計方法論とその先』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

「CSS設計方法論とその先」を担当した高津戸です。ありがとうござました。

私のセッションはでは、具体的なコードの書き方というよりむしろ、コードを書く上での概念的なところに終始してお話させていただきました。セッション内で取り上げたOOCSS、BEM，Enduring CSS、Atomic CSSなどのCSS設計方法論の詳細につきましては、本セッションでは詳しく取り上げませんでしたが、もしセッションを聞いて、ご興味を持たれましたら、ご参照されることをおすすめします。特にBEMにつきましては、今やデファクトスタンダードとも言える書き方となっていると言ってしまっても良いほどに広まった考え方です。

アンケートでいただいた感想として、「結局どうすればいいのか分からなかった」という意見を拝見しました。申し訳ありません、その答えを提示することはできません。私のセッションで最もお伝えしたいことは、CSS設計はどうすれば良いのか、どこかに答えが転がっているわけではないということです。そして、そのヒントとなることをパラパラと紹介させていただきました。

CSSの設計について、そこまで突き詰めて考える必要がないケースというのも多いです（まず、そこも一つ重要な認識だと思います）。ですが、規模の大きいサイトになってくると、この問題は重くのしかかってきます。UIの統一性維持、運用コスト増加の回避、スケーラビリティの確保など、多くの問題を回避するためキーになってきます。そのような問題を解決することができるスキルというのは、単にコードを書く以上の能力が必要とされます。そして、それはHTMLとCSSを書く人が次のステップとして踏み出す一つの道かと私は考えます。

最後に宣伝となりますが、弊社サービスCodeGridにおいてもCSS設計に関する記事があります。月額有料制ですがもしよろしければご参照いただければと思います。

その他ご質問いただいたこと

ECSSで書かれた具体的なサイトが知りたい

コレだというのは自分も把握していないのですが、Enduring CSS著者のBen Frain氏が、ECSSを使ったサイトを集めたいと言っているのをGitHubやTwitter上で見かけました。

• Do you public a project example that you use ecss?
• Do you know of or have built a site that uses ECSS?

まぁ、サイトを見てもそのコンパイル元のソースコードが読めるわけではないのでなんともですが、よろしければご参照下さい。

セッション中の内容に関連するサイト

• Object Oriented CSS
• BEM
• airbnb/css: Airbnbスタイルガイド
• nao215/css-style-guide: Airbnbスタイルガイド翻訳
• stylelint
• U.S. Web Design Standards
• Atomic Design
• Defining Design Systems ? EightShapes
• Enduring CSS
• Atomic CSS
• Let’s Define Exactly What Atomic CSS is | CSS-Tricks

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、大串 肇さん（mgn）の『Gitの入門とGitを利用した共同制作方法』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

補足

こんにちわ。Gitの入門とGitを利用した共同制作方法を担当した大串です。

「Gitを使ってみようと思います。」「Gitの説明で一番わかりやすかった。」「チームで導入してみます！」「Git flowとGitHub flowの違いがわかった。」「Gitのイメージができた。」といったコメントを多くいただきました。スピーカー冥利につきます。ありがとうござます。是非今後Gitを使って下さい！

また、「わかりやすかった。」「時間が短く感じた。」「こんな風に教えてもらったことなかった。」「バスガイド並みにわかりやすい。」「かわいい。」といったお褒めの言葉も沢山いただきました。とても嬉しく感じています。ありがとうございます。

冒頭に伺った、「Gitを普段から利用しているか？」という質問について8割以上の手が上がったので、全体のセッションの時間配分において、初心者向けの内容を30%ぐらいにしました。結果として「初心者向けの内容をもっと聞きたかった。」という声を頂いております。

逆に、すでにGitを使ってられる方からは、「すでにGitを使っており、学ぶところがなかった。」という声もいただきました。このあたり調整が難しかったです。初めから運用だけとか初心者向けとしておいたほうが混乱が無くてよかったかもしれません。

読み飛ばしてしまった、初心者向けのフォローアップ内容としまして、Gitの基礎講座の動画を共有します。こちらはGitの初心者向けの集中特訓講座として行っている内容をそのまま動画にしたものです。本来は集中特訓講座受講生のみへの共有なのですが特別に共有させていただきます。初心者の方は是非ご覧になって下さい。

Git基礎講座(全24チャプタ)

https://www.youtube.com/playlist?list=PLvEni36L5VuX3rrE2lG5QTB2Cgyjixppy

質問

Sass,typescriptなどのコンパイルしなければならないときは、どのタイミングでやるのですか？

一般的にコンパイル後のファイルはGit管理に含めません。srcのファイルのみGit管理するケースが多いです。

年齢のいったディレクターなどが新しいことを覚えるのが嫌らしくGitをつかってくれません。どうしたら使ってもらえると思いますか？

とてもむずかしい問題ですね。まずはご自身だけでこっそりGitを使うことをおすすめします。案件が進んでいく中で、そのうち先祖返りしたり、最新版がどれかわからなくなったり、そのディレクターさんが困るタイミングがやってきたら、そのときにドヤ顔でGitから最新版を渡してあげるというのが一番ソフトな方法でGitの有用性を感じてもらえる方法かと思います。もしくは、新しいものは使わないなんて言っている、向上心のない人との仕事はとてもストレスになるはずなので、更に上の上司に相談するか、転職を考えるか、それでも我慢するかになると思います。使ってもらえるといいですね！

以前のイベントで大串からGitの話を聞き、一人でGitを始めることができました。この場を借りてありがとうございました！

嬉しいです。コチラこそ！！！　ありがとうございます！

告知

定期的にGitの集中特訓講座を開催しております、今後の告知については以下のFacebookページを御覧ください。

• https://www.facebook.com/pg/meganedotin/

また、社内へのGitの導入支援や、Gitを利用したプロジェクトマネジメントのお手伝いなどお仕事がございましたら、どうぞお気軽にお声掛け下さい。

• https://www.m-g-n.me/

ありがとうございました！

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、阿部 正幸さん（KDDIウェブコミュニケーションズ）の『ここまでのJavaScriptスタンダードと、これからのJavaScript ES6について』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

CSS Nite LP54に参加した皆さま長丁場のイベント参加お疲れ様でした。
「ここまでのJavaScriptスタンダードと、これからのJavaScript ES6について」に
登壇いたしましたKDDIウェブコミュニケーションズの阿部です。

今回はJavaScriptに苦手意識がある方を対象にオブジェクトに重点を置いて登壇いたしました。
紹介したオブジェクトを作ったプログラミングは、DOMや現行配布されているライブラリーを理解する上でとても重要な事項です。
難しいと感じた方は是非サンプルプログラムを触ってみてください。

これからのJavaScriptはと言うと、ECMAScript6のClassを使い似たようなプログラミングをします。
ECMAScript6はIE11で動作しませんので、ES5への変換が必要です。変換はBabelなどのコンパイルツールが多く利用されています。

現行のJavaScriptと、これからのJavaScriptを両面から見ていただくと面白いかなと思います。
セミナーで使ったコードは下記よりダウンロードいただけます。よく分からなかった、JavaScritpに苦手意識のある方は、ぜひお試しください。

また多くの方からJavaScriptのハンズオンセミナーに参加したいとお声がけいただけました。
本当にありがとうございます。
次回のハンズオンセミナーはデジハリ＠大阪校で開催します。
https://www.facebook.com/events/2066803030205952/

その他にも多くのイベント登壇しております。イベント情報に関しましては、Facebookや、Line@等でつぶやておりますので、是非フォローいただけると幸いです。

長くなりましたがセミナーに参加いただきました皆様、フォローアップメッセージを最後まで読んでいただきありがとうございました。
またみなさまにお会いできることを楽しみにしております。

----------------------
サンプルプログラム
----------------------

・コンロのサンプル
http://bit.ly/lp54zipfile

・JavaScriptの基礎
http://bit.ly/js-hands-on

----------------------
ソーシャルアカウント
----------------------

下記は私のソーシャルアカウントです。
LINE@ではセミナーの無料招待チケットなどもお配りしております。
お気軽にLine@、Facebookフォローいただけると幸いです。

Facebook
https://www.facebook.com/chiyo.abe

LINE@
http://line.me/ti/p/@gkv8736o

CPIスタッフブログ
http://shared-blog.kddi-web.com/

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、鹿野 壮さん（ICS）の『Grid Layoutがやってきた！ Flexboxやfloatとの適切な使い分け方法』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

「Grid Layoutがやってきた！ Flexboxやfloatとの適切な使い分け方法」を担当した鹿野です。今回はご参加ありがとうございました。

2017年、全主要ブラウザが対応したCSS Grid。その概要、コーディング方法、IE 11の対応方法、floatやFlexboxとの使い分けまでを解説しました。

• すごくわかりやすかった、実践で使えそうなことがわかった
• FlexboxやGridとの使い分けがわかりやすかった
• 基本的な使い方がイメージできて、ハードルが低くなったような気がする

など、想像よりも多くの反響があり嬉しく思います。私自身がGridについて深く学びたかったこともあり、皆さんと一緒にGridの魅力を体験できる時間だったと感じます。

アンケートやTwitterでいただいた質問と答え

フォローアップとして、アンケートやTwitterでお寄せいただいた質問をいくつかピックアップして回答します。

入れ子にできますか？

可能です。

セッション中に紹介したデモ「Rodchenko Poster Layout - CSS Grid」では、.backgroundの要素にGrid指定、その中の#cardに対して更にGrid指定となっています。

<table>のcolspan属性（セルを横に繋げる指定）は可能ですか？

spanという単位が使えます。

grid-row-start: 1;grid-row-end: span 2;

と指定すると、「行の一つ目のラインから、2つ分伸ばしください」という意味になります。

プロパティの楽な書き方はありますか？

行と列の定義についてまとめることが可能です。

行の開始と終了位置指定方法①

セッションで紹介した方法です。

.item {grid-row-start: 1;grid-row-end: 3;grid-column-start: 1;grid-column-end: 2;}

行の開始と終了位置指定方法②

行の開始・終了、列の開始・終了をまとめて指定する方法です。 / で区切ります。

.item {grid-row: 1 / 3;grid-column: 1 / 2;}

行の開始と終了位置指定方法③

行と列をまとめて指定する方法です。 /で区切り、次のように指定します。

grid-area: (行開始番号) / (列開始番号) / (行終了番号) / (列終了番号)

セッション中に紹介したメインビジュアルのアイテム位置定義は、次のように記述できます。

.main-visual {grid-area: 1 / 1 / 3 / 2;}

ポリフィルはありますか？

Grid未対応ブブラウザでもGridレイアウトが可能なポリフィルがあります。しかし、次のような課題があります（参考記事「CSS Grid Layoutをガッツリ使った所感 - Qiita」）。

• ID属性が多く付与される
• overflowの解釈・スクロールバーの発生有無が想定と異なった
• CSS Grid Layoutとはあまり関係ない部分のレイアウトが崩れる
• ライブラリの容量が大きい

ポリフィルを使う際は、これらの課題に注意してください。

複数行になる可能性があるものはGridにしておいた方がよいのでしょうか？

Gridにしておいたほうが管理しやすいケースが多いです。

例えば、今回のセッション内で紹介した「猫の3つのサムネイル画像横並び」を複数行にしたければ、display: flexの代わりにdisplay: gridを指定する方がよいでしょう。ただし、ページ全体のコンテナ .containerではなく、猫のサムネイルのコンテナ .other-photosに対してGridを指定し、 .other-photos内のみでGridレイアウトの影響が及ぶようにする方が全体のレイアウトへの影響が少なくてラクです。

frとは何の略ですか？

fractionです。（越智さん、フォローツイートありがとうございます！ https://twitter.com/o_ti/status/926724288610164736 ）

fr を使う場合、他の要素は可変にしない方がいいのでしょうか？

可変要素をいくつ並べても問題ありません。

frという単位は、「余白がある場合、その要素をどれだけ拡大するか」を指定しますが、複数の要素にfrを使うと要素の拡大率がfrの数によって変わります。いくつか例を見てみましょう。

次のCSSコードでは、2行のレイアウトになります。1行目のサイズが100px、２行目は残りの領域全てです。

.container {display: grid;grid-template-rows: 100px 1fr;}

frが一つだけの場合

次のCSSコードでは、3行のレイアウトになります。1行目のサイズが100px、2行目と3行目は、残りの領域を半分ずつに分解したサイズになります。

.container {display: grid;grid-template-rows: 100px 1fr 1fr;}

2frのように、frに2以上を指定すると余った領域をその数分だけ確保します。次のCSSコードでは、3行のレイアウトになります。

• 1行目のサイズ : 100px
• 2行目のサイズ : 残り領域を3分割したうちの1つ分
• 3行目のサイズ : 残り領域を3分割したうちの2つ分

.container {display: grid;grid-template-rows: 100px 1fr 2fr;}

FlexboxのGridを使ったことがある人であれば、 flex-grow プロパティと似たような挙動をすると覚えるとよいでしょう。記事「CSS Grid Layout を極める！（場面別編） - Qiita」にわかりやすい解説がありますので、合わせて参照ください。

レスポンシブ対応した時の状態がわかりませんでした

行列の構造を変える例

3行3列のGridを、画面サイズ500px以上のときは2行4列に変更しつつ、各セルのサイズを変更してみましょう。

.container {display: grid;grid-template-rows: 1fr 220px 30px;grid-template-columns: 50% 160px 1fr;}@media (min-width: 500px) {.container {grid-template-rows: 1fr 500px;grid-template-columns: 400px 300px 1fr 200px;}}

アイテムの配置位置を変える例

行1から3まで、列1から2まで配置したmain-visualを、画面サイズ500px以上のときは列1から4まで配置するように変更してみましょう。

.main-visual {grid-row-start: 1;grid-row-end: 3;grid-column-start: 1;grid-column-end: 2;}@media (min-width: 500px) {.main-visual {grid-column-start: 1;grid-column-end: 4;}}

いずれの場合も、HTMLコードの構造を一切変えることなくCSSのみで柔軟にレイアウトを変更できるのがポイントです。

ブラウザがGridに対応した正確なバージョン番号を知りたいです

各ブラウザは、次のバージョンにてGridに対応しました。

• Edge : 16より対応
• Safari : 10.1より対応
• Chrome : 57より対応
• Firefox : 52より対応
• iOS Safari : 10.3より対応
• Android版Chrome : 57より対応
• Android System WebView : 57より対応

いずれも2017年にリリースされたバージョンで、一番遅かったのがEdge 16（2017/10/17リリース）です。

古いiOS Safari、古いAndroidブラウザ、Grid未対応のブラウザ対応が必要な場合は？

方法1. ポリフィルを使う

「ポリフィル」を使うと、Grid未対応ブラウザでもGridのレイアウトが実現できます。副作用もあるので、詳しくは前述の「ポリフィルはありますか？」を参照ください。

方法2. デフォルトを1カラムレイアウトにする

デザイン次第ではありますが、デフォルトをGridを使わない1カラムレイアウトにするという方法もあります。

• スマートフォンまたはGrid未対応ブラウザ : 1カラム
• Grid対応ブラウザ : Gridによるレイアウト

とすることで、Grid対応、未対応ブラウザに対して情報を伝える方法です。私が個人案件で仕事をする際は、この手法を用いています。

@supports規則を使うことで「グリッドに対応しているブラウザのみ、をを付加することができます。

/* グリッド対応ブラウザで、500px以上のデバイス幅のときのみグリッドを適用する */@supports (display: grid) {@media (min-width: 500px) {.contaner {display: grid;}}}

メリットばかりではなく、Gridのデメリットとその対応策について聞きたいです

一番のデメリットは未対応ブラウザがあることです。しかし、昨今のブラウザは自動アップデートが主流になっていますし、IE 11でも対策次第でGridが使えることを考えると、今後Gridが利用できる環境は広がるでしょう。前述の「古いiOS Safari、古いAndroidブラウザ、Grid未対応のブラウザ対応が必要な場合は？」のような対応をしつつ、ブラウザのサポート拡大を待ちましょう。

また、行列の数を増やしすぎると管理が煩雑になるというデメリットもあります。Excelでも行列を多く増やしてセルの結合を多用すると見辛くなるのと同じです。Gridによるレイアウトは大枠部分に留め、細かい部分についてはFlexboxで代用できないか、Gridの入れ子ができないか、等を検討しながらレイアウトしていくのがよいでしょう。

感想

いただいた感想の中から、特に印象深かった感想をいくつかピックアップします。Gridの便利さが伝わったようで何よりです。

• レイアウトに自由度が増して面白い
• 利用できるとコードが短くなりそう
• 使えるのは少し先になりそうだけど、使えるようになったら常用しそう
• セルに名前を使えるところがデザイナーに愛され、昔のテーブルレイアウトのようなところがディレクターに愛されると思った
• Flexboxの複数行のズレが起きていたので役に立った
• JavaScriptで対応していたようなレイアウトを、CSSで実現できるのは嬉しい
• エクセルのように扱えますの言葉で一気に理解が深まりました
• 入れ子の指定がなしでGridのレイアウトができるのがすごい
• div山脈を築き上げなくてよいのが素敵
• 役所や教育機関ゆえに、日本のIE 11のシェアが16%だと思う。しかし、対応を余儀なくされるのも事実

Gridの学習に役立つサイトについて

CSS Gridの学習には、次のようなサイトが役立ちます。

• CSS Grid Layout入門。対応ブラウザが出揃った新しいレイアウト仕様 - ICS MEDIA
• これからのレイアウトはGrid Layoutで決まり？特徴で使い分けたいCSSレイアウト手法 - ICS MEDIA
• これからのグリッドレイアウト | CodeGrid
• CSS Grid Layout を極める！（基礎編） - Qiita
• CSS Grid Layout を極める！（場面別編） - Qiita
• CSS Grid Layoutをガッツリ使った所感 - Qiita
• CSS Grid Layout Module Level 1

もしGridの学習をしていて不明な点があれば、Twitter等で気軽にご相談くださいませ。

告知

次の媒体でWebデザインやフロントエンドの情報について発信しています。こちらも是非ご覧ください！

• ICS MEDIA - Webデザイナー/デベロッパーの必読メディア
• tonkotsuboy_com - Qiita
• Gulp入門 - Schoo
• Flexbox 入門 - Lynda.com
• WebデザイナーのためのiOSアプリ開発入門 - WPJ

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、久保 知己さん（まぼろし）+伊藤 由暁さん（まぼろし）の『CSSをちゃんと書くためには？』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

p>「CSSをちゃんと書くためには？」のCSSを担当した久保です。
CSSでは重要な仕様だけど、なかなか触れられない「視覚整形モデル」について、ご紹介しました。
ちゃんと理解するのは難しい内容ですが、これを理解しておくと不思議なCSSの挙動も理解しやすくなります。
視覚整形モデルには、位置決定スキームというものあり、通常の要素の流れから逸脱すると、marginの動きに違いが出ます。プロパティの働きなどを調べる際に、視覚整形モデルがわかっていると、より理解が進むでしょう。

またセッションでは、CSSの宣言を紹介した継承の特性やwidthプロパティを使った例を2つご紹介しました。
CSS設計というと、命名規則やコンポーネントの分け方などに注視されがちがですが、宣言もCSS設計の重要な要素のひとつというこをお伝えしました。宣言の行い方は、それぞれのプロパティの特性などを理解する必要があり、習得が難しいポイントです。
しかし宣言もCSS設計のひとつと意識することで、宣言の行い方も上達していくことでしょう。
再現したデザインとCSSの振る舞いがスマートに一致したCSSを目指すことが大切です。

「CSSをちゃんと書くためには？」のSassを担当した伊藤です。ご参加ありがとうございました。

CSSは命名規則や構造化だけでなく宣言そのものも重要であり、その宣言記述に注力するために効率的で意味のあるSassを構築しましょうという話でした。

セッション後の質問の補足

無駄なCSSやSassを書いていないかチェックしてくれるルールはありますか？

完全ではありませんが、Style Validatorというブラウザの拡張機能があります。

http://style-validator.io/

display: inlineが指定されたセレクタにwidth指定やheight指定があると「No effect（効果なし）」というエラーを表示してくれます。

アンケートへの回答

今回の授業だけなく何か情報を発信しているなら教えて欲しい

書籍やAdobeの公式ブログでも執筆を行なっています。また個人ブログでも、定期的に情報を発信しています。

久保

• Amazon.co.jp: 久保知己:作品一覧、著者略歴
• 久保 知己 | Adobe Creative Station
• Web Design KOJIKA17

伊藤

• いちばんよくわかるWebデザインの基本きちんと入門
• dskd

詳細度を高めている案件がある場合のリファクタリングが悩みである

詳細度が高くなっているとリファクタリングがしにくいのは私も感じます。
どの程度リファクタリングするのかわからないのですが、もし全てのCSSを書き換えていいのであれば、私はセレクタの命名規則を変えてリファクタリングすることをおすすめします。
命名規則を変えることによって、古いCSSとリファクタリングのCSSが混同していても、セレクタ名のバッティングを防ぐことができます。

ただしこの方法は、全て書き換えるのでコストがかかります。既存の状態を残してリファクタリングするのであれば、ボタンなどの小さく影響範囲の小さい箇所から、リファクタリングするしかないと思います。

メディアクエリの書き方ですが、(min-width: *) and (max-width: *) ってかくのと、1つだけ指定して上書きしていくのと、どちらがおすすめですか？

デザインによります。PCとスマートフォンで見た目が異なる箇所が多いのであれば、限定的に指定できるandを使って指定が有効です。
ただ見た目で似た部分が多く、CSSの宣言の差が少ないようであれば、1つだけ指定して上書きする方法をとっています。

CSSのプロパティでは仕様書と一般的な認識と違うようなものがあれば聞いてみたいです。

一般的な認識が難しいですが、例えばwidthとmarginプロパティとの関係性は、10の状態によって変化します。
幅とマージンの計算 | 視覚整形モデル詳細

また別の例をあげると、displayプロパティの最初値はinlineです。ではなぜ、ブラウザで見たときは、divやul要素などはdisplay: block;の挙動を行うのか。それはブラウザのスタイルシート「User Agent Stylesheet」が効いているからです。そのためブラウザが対応していなかったり、未知のHTMl要素は、すべてdisplay: inline;として表示されます。

CSSフレームワークとCSS設計の組み合わせってやりますか？

はい、弊社でCSSフレームワークを利用する場合はBootstrapを利用しています。CSSフレームワークとは別のCSSを追加するときは、命名規則が重複しないようにMindBEMなどを使う場合が多いです。

widthを9xxpxにしてmargin: autoにしちゃってるんですが、ダメでしょうか？

もちろん、ダメではありません。
レスポンシブなどで、もし段階的に幅の指定を変えなければならないのであれば、widthプロパティをメディアクエリで操作しなければなりません。
CSSで実現したい振る舞いによって、宣言の解は変わってきます。

どの段階で無駄を省いていくか？

サイトの規模にもよりますが、ある程度のコンポーネントが揃った時に、行なっています。

命名規則ではどういうルールで書いているか教えて欲しい

案件によって指定される場合もありますが、弊社では下記が多いです。

• MindBEM
• FLOCSS

&記号を使うとgrep検索しづらくなる

なりますね。目的のセレクタがあるSCSSファイルをすぐgrepするために、伊藤はセレクタの上にフルのセレクタをSCSSコメントで書いておくなどしています。

.box {// .boxheader&header {}// .boxbody&body {}// .boxfooter&footer {}}

エディタによっては追跡可能です。

WebStorm 2017.3 EAP にて。 https://t.co/1vKCCEqZhG"

あるいは&記号でセレクタを分断せずに、

.box {@at-root {& {color: navy}.boxheader {color: gold}.boxbody {color: tomato}.boxfooter {color: skyblue}}}

と書いています。@at-rootもSassの機能の一つで、中身がトップレベルのスコープで解釈されます。それでいて&記号もちゃんと親ブロックのセレクタを取得してコンパイルされます。

.box {color: navy}.boxheader {color: gold}.boxbody {color: tomato}.boxfooter {color: skyblue}

&を使う際、一つのSCSSファイルの中で違うの文脈の&が出てしまうと混乱しますので、BEMで言うところのブロック単位（SMACSSではっモジュール単位）でSCSSファイルを分けると良いです。

.header {&logo {}&lede {}}.header-nav {&list {}&item {}}

前述のような形ですと、&が.headerだったり.header-navだったりしてしまうので、header.scssとheader-nav.scssのように別ファイルに分けてください。

ネストは何段階まで許容している？

本当に必要であればいくらでもネスティングしていく、程度の気持ちです。BEMならブロックの子要素は全て&_Element {}のようにSCSS上で並列して書けますので、そもそも深くなりません。BEMエレメントから3階層程度が個人的な許容範囲です。@at-rootを使うとそのぶんインデントが増えますがそれすら気になるならネスティングは使わないとプロジェクトで決めてしまった方が気が楽かと思います。

&の問題点？

&はgrepしづらい、セレクタが分かりづらくなるという意見をいくつかいただきました。伊藤としてはブロック / モジュール単位でSCSSファイルを分割しているので、&は常にそのブロックであるという認識で書いています。よって&で分かりづらくなったことはありません。

このセクションでは、漫然としたネスティングで詳細度を高めるのはやめましょうというニュアンスをお伝えしたかったのですが、&記号の方に意識が注がれてしまう説明だったと反省しています。

改めてまとめますと「ネスティングは主従関係が可視化されるので便利だが、不必要なネスティングで詳細度が高くなると、保守・運用フェーズでメンテナンス性が下がる。必要な場合は&記号を活用して詳細度を下げましょう」ということです。

CSSの管理・設計を行うにあたり、プロダクトマネージャーやデザイナーにどうアプローチすれば良いか

HTMLとCSSもプロダクトを構成するに欠かせないものの一つであり、「誰がやっても同じもの」ではないことは啓蒙が必要です。無秩序に作ったCSSではスケジュールやクオリティーは保証できません。CSSにも相応の作業時間と専門知識が欠かせないからです。単にデザインを再現しているだけと思われないよう、プロダクトにとって保守性・可搬性の高いCSSを書き、それをアピールしていくと良いでしょう。

@functionを使ったz-indexの管理方法がためになった

ありがとうございます。z-indexの管理が必要ではないプロジェクトでは無用の長物ですので、このセクションが響かなかった方もいるかと思います。

CSSではマジックナンバーはやめようというTIPSは有名ですね。とりあえず一番上に出したいからz-index: 9999というような指定はCSSではよくないとされています。大規模なウェブサイトや施策が入り乱れるサービスですと、z-indexの値は混沌を極めます。@functionで重なり順だけ管理すれば、数字の大きさは気にしなくて済みます。

数字が大きい方が上に来るのだから管理しなくても別にいいのでは、という意見もあるかもしれません。しかし、z-indexは数字が大きい方が前面に表示されるとは限りません。スタック文脈と呼ばれる概念があり、単純な数字の大小だけでは説明できないのがz-indexなのです。

時間の関係でスライドに入れられませんでしたが、z-indexのスタック文脈問題に対応すべく、久保がカスタムした関数があります。二階層以上や逆順での管理が可能になっていますのでぜひチェックしてみてください。

Sassを使ったz-indexの管理 - Qiita

@functionの他の活用法

Sassの組み込み関数のuniqueid()と組み合わせてキャッシュバスターを付与することができます。

@function cache-buster($path) {@return #{$path + "?" + uniqueid()};}.kv {background-image: url(cache-buster("/assets/images/kv.png"));}

.kv {background-image: url(/assets/images/kv.png?u278e85ca);}

作成したcache-buster関数に画像パスを引数に入れると、コンパイル時にパスの後ろに?u278e85caというパラメータが付与されます。uniqueid関数はコンパイルの度に新しい文字列を出力するので、キャッシュバスターに利用できるというわけです。

Generated by SassMeister.com.

@importで変数を使う方法はありますか？

残念ながらないです。Sassの@importはurl()型か文字列しか受け取れず、インターポレーションやquote()を挟むことができません。

汎用性の高い変数がうまく作れない

用途が限定されすぎてる値を変数化するのはあまり意味がありません。かといって、$base: 10px;などを作りあらゆるところで演算して使えばいいというわけでもありません。

汎用性に必要な観点は「粒度」です。変数がpx系か%系といった粒度ではなく「.boxに使うサイズバリエーション」「ブレークポイントのサイズバリエーション」という具合に主に何に使われるかでカテゴリ分けしています。

まずは変数を使わずにベタ書きでコーディングを進め、変数でまとめた方がいいと感じたものを変数化すれば良いでしょう。変数を使うか使わないかでコンパイル結果が変わることはないので、定期的に変数を見直すのも良いです。

SCSS記法とSass記法の違い

SCSS記法は素のCSSと同じように {} や ;を使いますが、Sass記法はスペースとインデントと改行で書く、とセッションでは説明しました。Sass記法は

• {}を使わない
• 次のプロパティーは必ず改行して記述
• :のうしろに必ずスペースが必要
• ;が不要
• インデントが宣言ブロックを表す
• mixinはショートハンドがある

といった特徴があります。

// SCSS記法@mixin ir {display: block;overflow: hidden;text-indent: 101%;white-space: nowrap;}.nav {color: blue;font-size: 0.3em;a {width: 50px;@include ir;&:hover {background-color: #eee;}}}

// Sass記法=irdisplay: blockoverflow: hiddentext-indent: 101%white-space: nowrap.navcolor: bluefont-size: 0.3ema+irwidth: 50px&:hoverbackground-color: #eee

前述の2つのコンパイル結果は同じですが、Sass記法の方が記述が少なくて済むので好きという人は少なくありません。

社内でCSSを書くスタッフにレベル差があってSassが導入しづらいがどうしたらよいか

組織の規模に関わらず個人向けでも大勢向けでも同じで、「繰り返し啓蒙していく」のが一番です。仲のいい社員をイベントに誘って一緒に参加したり、社内勉強会を開いたり、啓蒙活動にも色々方法があります。Slackなどの分報でブログ記事などを共有するのも良いですね。まずは業務で関わった人から巻き込んでいってはどうでしょうか。

2017年11月4日（土）ベルサール半蔵門 イベントホールで開催したCSS Nite LP54「Coder's High 2017」のフォローアップとして、中村 勇希さん（トゥーアール）『テンプレートエンジンPugを使った、みんなでやるウェブ制作』セッションのスライドなどを公開します。

• スライド（PDF）
• 動画

フォローアップメッセージは、イベント開催直後（2017年11月）の時点のものです。

フォローアップメッセージ（補足など）

「テンプレートエンジンPugを使った、みんなでやるウェブ制作」のセッションを担当した中村です。セッションをご覧いただきましてありがとうございました。

今回のお話は「ツールの紹介」といった側面と「コーディングをデザインの一環として捉える」といった側面がありました。アンケートやTwitterをコメントをみていると、コーディングがデザインを言語化することであることについて共感・実践してみたいというコメントを頂けているようで幸いです。

一方で、運用の面で課題が多いのも事実です。特に、新規案件や、個人的には取り入れていきたいものの、実務で役立てられるかどうかという点では厳しそうというコメントも多くいただきましたので、こちらで回答いたします。

ツール

ejsはどうなの？

できることについては、Pugとそんなに変わりません。決定的にこれができないので採用できないということはなく、私もejsを使うことはあります。

• HTMLをそのまま書くことができる
  • Sassにおける「scss記法」的なもの

こちらは「Pugさすがにキモいもののコンポーネント指向で考えたい」という人はこちらの導入をおすすめします。こちらも中にJavaScriptを埋め込むことができます。Pugのように-と書くだけでJavaScriptにはならず<%%>のようにする必要があり、PHPのような見た目になります。

ejsとPugの混在はできるか

中間成果物としてのHTMLを生成し、それらをどちらかで読み込むという形になるかと思います。そうすれば、混在させることは可能です。ですが、オススメはしません。記法が混在し、コンパイルも二重に必要で、結局どちらつかずになってしまうでしょう。

現状ejsで動いているものをPugで扱いたい場合、一旦EJSをHTMLにコンパイルし、HTML2Pugなどを用いてPugに直してしまうという手もあります。

izolate/html2pug: Converts HTML to Pug

ブラウザ版もあります。

html2pug - convert your html code to jade

運用

エンジニアがいないと難しいか

環境面でいうと、何か問題があったときにメンバー全員が「黒い画面怖い」みたいな状態だと立ち往生してしまうかもしれません。最低でも一人は「少しわかる」みたいな人がいるのが理想です。

しかし、その状態ではSassも満足に導入できないという悩みもあるかと思います。少しセッション後にお話しましたが、現在その辺を含めた「デザイナー・新米コーダーでもフロントエンド怖くなくなる」ような書籍を執筆しておりますので、そちらをお待ちいただければと思います。

[宣伝]gulpに関しては、こちらの書籍をご参考いただければと思います。

ゼロからはじめるgulp入門書 - nayucolony - BOOTH（同人誌通販・ダウンロード）

コンパイル後のHTMLを触られてしまう

解決しようとする場合、社内外のコミュニケーションの部分から始まりますが、それが行き届かない範囲も関与する形になってしまうと、運用までPugでやるのは難しいです。

ツールで無理やり解決しようとするならば、HTML2Pugを使って差分をとって……という手段もなくはないのですが、あずかり知らないところで改変されているという場合は先祖返りしてしまうので有効ではないでしょう。そういう体制の場合、Pug云々のまえにまずはGitの導入からはじめることをおすすめします。Gitはセーブポイントです。

Pugを使いたい場合、初期開発だけPug、運用体制に入ったらHTML、というのが妥当なところです。初期開発だけでも、共通化などでPugは役立つ部分が多いので、ぜひ活用してみてください。

また、例えばトップページのメッセージを変えるなどで、あらかじめ他者によるHTMLの修正があることがわかっているのであれば、その部分だけをコンポーネントとして区切っておき「このファイルのテキストだけを変えてください」という取り決めをしておくと良いのではないかと思います。コンパイル作業は、コンパイル用のコマンドをバッチファイル化しておけばワンクリックでOKです（前川さんのセッションを参考にしてください）。

ファイル管理が大変そう

コンポーネントと呼べるものが増えれば増えるほどファイルが増えていきます。これらは、セッション中でもお話した通り、CSSと同じ粒度で同じように管理していくのが理想です（こうなってくると、CSS設計論的な話になっちゃうのですが）。Pug側で好き勝手にファイル管理の方法を生み出したところで、CSSとの関係性がわかりにくくなってしまっては、プロジェクト全体において「ファイル管理が大変」であることが解決できません。

一つのアプローチとして、CSSフレームワークのファイル管理方法を眺めて見ることをオススメします。案件全てに同じ考えは通用しなくても、どのくらいの粒度、どのくらいのカテゴリ感で管理しているかの参考になりますよ。

bulma/sass at master ? jgthms/bulma

bootstrap/scss at v4-dev ? twbs/bootstrap

スキルレベルによっては共有が難しそう

Pug記法がわからない、という点では、今まで見たことがない新しいものである以上仕方ない部分があります。

また、Pugで使うプログラミング的表現は「if」「else」「case/when」「include」などで、プログラムを書いているというよりは英語でコメントをしているというものに近いです。ですので、すでにJavaScriptの知識がないと使えないというものではありません。「言語化」という目的を忘れずに、なるべくシンプルを心がけましょう。

どうしてもシンプルにできない場合、そもそもデザインが複雑すぎるという可能性もあります。言語化をしているときに、もっと妥当なデザインアプローチが見つかるかもしれません。デザイナーと相談してみることも一つの解決方法です。

他人の書いたPugがわからない問題

なまじプログラミングができちゃう人ががっつりプログラミングしてしまうということはあります。それが必要なものであればいいのですが……

今回のセッションは、プログラムを書いてカッコよくやろうという話ではありません。例えば二つパターンがあったときに、ただ単に二つのファイルを渡すよりも、一つのファイル内で「こういうときはA、こういうときはB」と書いた方が、よりコードに「意味」が出てきていいよね、というお話でした。ですので、書くときは「プログラミング」というよりは「言語化」という部分を意識してほしいと思います。

PHPを中にかけるか

YesかNoかでいうと、Yesです。PHPを「プレーンテキストとして書き出させる」ことでHTML内にPHPを書き出すことができます。PHPで分割したファイルの挿入も繰り返しもできてしまうので、PHPが使える環境でPugで頑張る必要はないかと思います。

Plain Text ? Pug

pugでPHPを無理やり使うための4つの技 | q-Az

コンパイルの短縮

gulpをお使いでしたら、gulp-changedやgulp-cachedを用いることで一部改善できます。

sindresorhus/gulp-changed: Only pass through changed files

contra/gulp-cached: A simple in-memory file cache for gulp

全ページに挿入されているファイルの変更を行なった場合はやはりページの数だけコンパイルする必要があります。こればかりはコンパイラの処理速度に依存してしまうためです。しかし、素のHTMLで同じことをしようとした場合に人力でそれよりも早く処理を終えることができるのか？検索置換を行なった場合、正確に完了できるのか？ということも加味すると、割り切ってもいいのではないかというのが個人的な意見です。

jsonでデータを連携させる際のうまいやりかたが知りたい

Pug及びNode.jsはサーバサイドの技術です。テンプレートとデータに分けて考えるやり方は独自性のある考え方ではなく、サーバサイドですでに行われている手法です。ですので、データベースやAPIの設計論を参考にしてみてください。オープンソースなWordPressテーマの作りを眺めて見るのもよさそうです。いろいろなデザイン（＝設計パターン）が見えてきますよ。

また、デザインでいうと、インフォメーションアーキテクチャの考え方が流用できる部分もあります。いろいろな世界の「情報の取り扱い方」を組み合わせて、プロジェクトに適切なデータ設計を行なってみてください。

その他

div使いすぎ

ごめんなさい、アンチパターンでした。私はインブラウザデザインでのワイヤーフレーム作成を行うことが多く、その際にCSSフレームワークの「Bulma」を使っています（全ソースコードを写経した経験もあります）。プロトタイピング目的ではdivで十分なので、ついあの場で手癖が出てしまいました。もちろん、実装ではちゃんとやってますよ！

Bulma: a modern CSS framework based on Flexbox

[宣伝]古いバージョンですが、コードリーディング本もあります。

Bulma Code Reading ~ フレームワークから学ぶCSSテクニック - nayucolony - BOOTH

Butjon

Microsoftの「Fabric」の紹介で触れた「Butjon」

Home - Office UI Fabric

よくよく考えると、Microsoftのプロジェクトでそんなことあるか？と思い、あの後、GitHubで次のようなプルリクエストを投げつけてみました。

replace butjon / button by nayucolony ? Pull Request #3309 ? OfficeDev/office-ui-fabric-react

返ってきた回答は「ディセンダーを含めて見た目をチェックをするために意図的にいれています」というような内容でした。ディセンダーとは、文字のベースラインを下側にはみ出す部分です。「j」「g」なんかがそうですね。知りませんでした。

これをみて、また一つ知識が増えました。皆さんも「ディセンダー」を意識してみてください。