CSS Nite LP54「Coder's High 2017」

すべてのフォローアップコンテンツが出揃いました。

公開ポリシー

このページは、本イベントの参加者（およびフォローアップ参加者）限定のコンテンツです。 ただし、90日を目安に一般公開する予定です。

ブログ

「こんなセミナーに行った」「ここが印象に残った」等、ブログなどで取り上げていただければ嬉しいです。

こちらのバナーはご自由にお使いください。Facebookにてイベントでの写真アルバムを公開しています。ブログ等に転用くださっても結構です。

次のブログで取り上げていただきました。ありがとうございます。 　

Facebookイベントページ

告知ページへの追記事項などはFacebookイベントページにて随時お知らせしていきます。

Facebookイベントページ

次回のコーディング系の開催についてのお知らせする予定です。

コーダーの前仕事、後仕事
前川 昌幸（イー・ネットワークス）

「コーダーの前仕事、後仕事」のセッションを行った前川です。ありがとうございました。

内容はTipsやツールの紹介でしたが、何かひとつでも明日から使えるものがあれば嬉しいです。
また、セッション中からTwitterで、みなさんが利用しているツールやTipsをツイートしてくれました。ありがとうございます。
全てを拾ってはいませんが、いくつか紹介します。

今日の他のみなさんのセッションのように、ひとくちに「コードを書く」といってもさまざまな方法論やツールがあるように、その前後の作業でも同様にさまざまな方法論やツールがあります。

私のセッションがきっかけになって、自身の作業の棚卸しや周りの人たちとの共有などしてみてください。

【告知：書籍】

Webサイト、これからどうなるの? キーワードから探るWeb制作の未来像
こもりまさあき、栄前田 勝太郎、坂上 北斗、塚口 祐司、前川 昌幸、松田 直樹 共著
エムディエヌコーポレーション (2017/9/20 発売)
価格（本体2,000円＋税）

Amazonでの購入

告知：イベント

WCK Meeting Vol.56「キーワードから探るWeb制作の未来像」
高知で上記の書籍出版に関連したイベントを行います。
開催日時 2017年12月2日（土）13:30 開場
会場 高知市文化プラザ　かるぽーと　9F 第1学習室

「コーダーの前仕事、後仕事」のセッションを行った前川です。

アンケートでのコメント、質問

アンケートでのコメント、質問についてまとめます。

Local by Flywheel

Local by Flywheelについて、「使ってみます」というコメントが多かったです。導入の際には以下のエントリーが参考になります。

WordPressのローカル環境のためのGUIツールLocal by Flywheelが便利 - Capital P

Windowsでは、batファイルではなくcmdファイルが最近の流れ?

というコメントがありました。ざっと調べてみたところ、大きな違いは無いようですが、もしこのあたりアップデートするようであれば、どこかでアウトプットします。

Windowsのアプリも紹介してほしい

今回紹介したうちで、VirtualHostXとFluid BrowserはMacのアプリでした。すいません。
Local by FlywheelやGenymotionなど他のアプリやツールは全てWindowsでも使えるものですので、活用してください。

Photoshopの書き出し形式の「すべてのスケール」使うのキライですか？

defaultレイヤーでの作業に慣れきっているので、ほぼ使っていないです（キライではないです）。
結果同じ書き出しになるので、性に合う方を使うのが良いと思います。

乗算でパーセント指定された時に困っています。解決方法はありますか？

すいません、そのケースは遭遇した経験がなく。なにか見つかれば共有します。

会社では gyazo.com を使っています。便利です。

これでフィードバックの指示を作成されているデザイン会社さんと仕事しています。確かに便利ですね。ありがとうございます。

Gyazo

WindowsでPC、モバイル一通り利用できるエミュレーターを知りたい

クラウド型のエミュレーターのBrowserstackがカバー範囲も広いので良いかもしれません。

デフォルトで利用できるApacheで良いのでは？

私もその意見には同意する部分も多く、以前はMacに搭載されているApacheを利用していました。
ただ、並行した案件が多くなると管理が煩雑になってきたので、VirtualhostXなどを利用するようになったので、状況によってはツールに頼るのも選択肢のひとつと考えています。

XAMPPを使っていて、Browsersyncを使うことはできるのでしょうか？

できます。BrowsersyncのProxyオプションを利用すれば、Browsesync越しにXAMPPの出力を表示することができます。
（このやり方は弊社でも行っています）

Windows/Macが混在する環境の場合、違いをうまく埋める方法はありますか？

node.jsなどを利用するツールの場合は、ほぼほぼどちらでも動作するので特に気にする必要はないと考えています。
ツール類は確かにいろいろ変わってきますが、環境よりも成果物に差が出ないようにフォーカスして考えていくとよいのでは、と考えています。
なので、あくまでも弊社の場合はエディターなど利用するものは結構違っていますが、その違いを埋めることについてはあまり気を使っていません。

画像をきれいに軽量化して書き出すおすすめの方法はありますか？

私は書き出した後にImageOptimを利用して最適化しています。WindowsだとFileOptimizerなど似たようなツールがありますので、そちらを活用してみてください。

アイコンフォントやCSSスプライトの生成、更新時の管理方法が知りたい

アイコンフォントについては、生成するgulpを作成したことがあります。

https://github.com/enetworks/iconfontcreation。

このあたりが参考になれば。

CSSスプライトに関してはあまり最近使っていないので、すいません。目新しい管理方法などは持っていません。

対象ブラウザの決定はどのようにしていますか？提案していますか？言いなりですか？

提案できる案件であれば提案するのですが、そうでない状況の場合は、ほぼ抵抗せず、言いなりでやっています。

最近Sketchを使うことが多いですが、制作会社ではどうなのでしょうか？

個人的にSketchは所有していて、利用することはありますが、案件では弊社のばあいは無いです。商流など環境的要因が大きいので、制作会社でも積極的に採用されているところはあると思います。

nodebrewは利用しませんか？

以前は利用していましたが、今年に入ってからnodenvに変わりました。

ルートパスってなんですか？

href="/hoge.html"という形で、「/」から書くファイルの指定です。説明不足失礼しました。

Photoshopでレイヤーマスクだとサイズの変更や確認がやりづらい、なにか良い対応方法はないか？

いまはこれと言った対応方法は持っていないので、なにかないか探してみます。

ダウンロード

多様なユーザーニーズに応えるフロントエンドデザインパターン：ベーシック編
伊原 力也（freee）+太田 良典

ご挨拶

ご参加ありがとうございました！マークアップが体験に大きく影響するということをお伝えできたなら嬉しく思います。少し手を掛けるだけでも対象ユーザーの範囲を飛躍的に増やせる可能性があるのが、Webフロントエンドの醍醐味です。それこそ、divをbuttonにするだけでも。ぜひ「規則を守る」という考え方から、「コードで体験をデザインする」という考え方にスイッチしてみましょう！またお会いできる日を楽しみにしております。

スライド

告知

書籍　

イベント登壇

あのTシャツ

質問へのご回答

アンケートやTwitterでお寄せいただいた質問や感想に回答します。

インクルーシブデザインという言葉について

質問・感想
回答

「インクルーシブデザイン」という言葉の一般的な意味はその通りで、極端な立場に置かれたユーザー (リードユーザー) と一緒にデザインをしていくようなことです。とはいえ本書ではもう少し広い意味で使っています。 このあたりの話はAccSellポッドキャスト第122回でお話ししていますので、興味がありましたらお聞きください。

また、原著者のヘイドンさんが、なぜわざわざインクルーシブデザインという言葉を選んだのかを説明しているブログ記事もあります（英語です）。なぜアクセシビリティではなく、UXではなく、バリアフリー的な話ではなく、ユニバーサルデザインではなく、インクルーシブデザインという言葉を選んだのか。より詳しく知りたい方はこちらを読んでみると面白いかもしれません。

グラフィックデザイナーの定義

質問・感想
回答

すみません。><
本書では「グラフィックデザイナー」を「コードが書けるデザイナー」の反対概念として言っていますが、もちろん、グラフィックデザイナーと呼ばれる人の全てが実装のことを全く考えていない、というわけではありません。ビジュアルデザイン専門であっても、実装のことやアクセシビリティのことを考慮したデザインができる人はいますし、そうであることが望ましいです。

マークアップ以外の職種

質問・感想
回答

高津戸さんのCSSのセッションで、マークアップの現場に降りてきたときに手遅れになっているという例が紹介されていましたが、これはアクセシビリティにも良くあてはまる話です。上流からアクセシビリティに配慮しておくことが重要です。

Webサイト制作の全工程でアクセシビリティを考えてほしい、ということで書いたのが「デザイニングWebアクセシビリティ」という本です。これをデザイナーやディレクターの方に読んでいただけると嬉しいです。

組織にWebアクセシビリティの考え方を浸透させる取り組みについては、サイボウズの小林さんのお話（あなたの言葉で伝えるWebアクセシビリティ）が参考になります。

アクセシビリティとコスト

質問・感想
回答

今回のセッションでは、divで実装された「賛成」ボタンに対して、アクセシビリティを担保しようとしてあとからさまざまな機能を付け加えようとする例をご紹介しました。このように、望ましくない実装に対して後からアクセシビリティを担保しようとすると、大きなコストがかかることがあります。

それに対し、最初からbutton要素を使えば、それだけでもうキーボードアクセスやスクリーンリーダーへの対応ができているということになります。この場合、追加の作業は何も必要ありません。

このように、後から対応しようとすると大きなコストがかかりますので、最初から考えておくことが重要です。

ただし、動画やPDFなど、明らかにコストがかかるコンテンツも存在しますし、試験を実施すればその分はコストがかかります。このあたりの話は、書籍「デザイニングWebアクセシビリティ」の1章で触れていますので、興味ありましたら参照していただければと思います。

アクセシビリティをやらせてもらえないという悩み

質問・感想
回答

アクセシビリティへの取り組みが必要な案件は近年増加している印象です。特に大規模案件や公共系の案件については、現在ではRFPにアクセシビリティ要件が含まれていないことのほうが珍しいように思います。

小規模案件では求められないことも多いと思いますが、そのような場合は要件定義でこちらから「今回はこのレベルまでの対応をします」と提案してしまうのもありです。逆に、要件定義で「アクセシビリティ対応は行わない」と明確に決めることもあります。決めておかないと後で問題が起きた際に費用内での追加対応を求められ、トラブルになることがあるからです。

このあたりの話も、書籍「デザイニングWebアクセシビリティ」の2章で触れていますので、参照していただければと思います。

おすすめのサイトは?

質問・感想
回答

サイトによっては「ウェブアクセシビリティ方針」を掲げて、自らの取り組みをアピールしていることがあります。方針を掲げているサイトはアクセシブルであることが多いので、それを見ると参考になるでしょう。(ただ、自治体系のサイトは方針を掲げていても正直それほど良くないことが多い印象です。民間企業のサイトを見たほうが良いと思います。)

また、私たちが所属しているウェブアクセシビリティ基盤委員会では、公的機関や一般企業における、ウェブアクセシビリティ方針策定と試験結果表示の実態調査を定期的に行っています。こちらも合わせてご覧ください。

その他、私の周りでアクセシビリティ文脈でよく話題に上がる企業や団体のウェブサイトをご紹介します。これらの企業や団体はアクセシビリティに取り組んでいくことを明言しており、そのサイトやプロダクトの状況にも注目していきたいと思っています。

現場が大変

質問・感想
回答

現場の方にお勧めなのは、実際にスクリーンリーダーで一度アクセスしてみることです。そこまで時間はかかりませんし、これだけで多くの問題に気づくことができます。WindowsならNVDAが無料で利用できますし、iOSやOS XであればOS標準のVoiceOverが利用できますので、費用もかかりません。

最近はコンポーネント単位で実装することが多くなっていると思いますが、コンポーネントを実装するたびに、一度スクリーンリーダーでアクセスしてみると良いと思います。

スクリーンリーダーとその他の支援技術

質問・感想
回答

さまざまな状況の方がWebを利用するために使うツールを「支援技術」と呼びます。支援技術の代表格はスクリーンリーダーですが、それだけではありません。画面を拡大するツール、点字ディスプレイ、マウス操作を支援するツールなど、さまざまなものがあります（ちなみに、茗荷谷にある東京都障害者IT地域支援センターというところでは、こういったさまざまな支援技術の常設展示を行っているそうです）。

スクリーンリーダーの利用率をサイト側で調査するのは難しいです。スクリーンリーダーはブラウザの表示結果を読み上げるため、サイト側のログには通常のブラウザのUser-Agentが記録され、スクリーンリーダーを使っているかどうかはわかりません。

SVG

質問・感想
回答

SVGにすればアクセシブル、という単純な話でもありません。基本的には、テキストだけで必要な情報が伝わるようにする必要があります。そのテキストをSVGの中に入れるか、HTML側に入れるかという話になりますが、これは実際のブラウザやスクリーンリーダーの実装状況に照らして判断する必要があります。基本的に、img要素でSVG画像を参照しても、SVG内のテキストは読まれません。インラインのSVGであれば読まれることが多いですが、ブラウザやスクリーンリーダーによって処理が異なります。

表であれば、基本的にはHTMLのtable要素を使ったほうが良いでしょう。tableはアクセシブルでないという印象があるかもしれませんが、スクリーンリーダーは表を読むための専用のモードを実装していることが多く、行見出しや列見出しを読んでくれるなど、さまざまな支援があります。

SVGスプライトの運用は、アイコンの数が少ないときは良いのでしょうが、増えてくると管理がとても大変になります。illustratorのファイルを管理する必要もありますし、このあたりはみなさんそれぞれ工夫されているのではないかと思いますので、私も皆さんのノウハウをお聞きしたいところです。

参照される側のSVGスプライトにdisplay:noneを指定すると、Android4系の環境でグラデーションが反映されないという問題があるようです (他にも問題が起きる環境があるかもしれません)。ここで紹介したものは著者がおすすめする実装方法のひとつにすぎませんので、状況によっては別の方法を選択するほうが良いこともあります。

今回ご紹介した中には、VoiceOverでうまく読まれない事例もありましたね。さまざまな実装方法があり、どれかひとつが「正解」というわけではありませんので、状況によって適切なものを選ぶようにしていただくと良いと思います。

アイコンの実装

質問・感想
回答

i要素が支援技術で特別扱いされることはありません。つまり、divやspanと同じ扱いだと考えてください。i要素にテキストを入れればふつうに読まれますし、中身が空でもaria-labelをつけて読ませることもできます。CSSのcontentプロパティでテキストを追加した場合も読まれます。

アイコンをどのように実装するかがポイントで、さまざまな実装方法があり、それぞれにメリットとデメリットがあるのは今回お話しした通りです。i要素を使う場合、contentプロパティを使ってアイコンフォントを入れる実装になっていることが多いように思いますが、その場合もやはり、今回ご紹介した豆腐の問題が起きることがあります。

ボタンとフォーム

質問・感想
回答

実は、button要素はform要素のないところでも使えます。今回ご紹介した本の前著にあたる「コーディングWebアクセシビリティ」の2章で説明されていますので、興味がありましたらご覧いただければと思います。

buttonのtypeの初期値はsubmitです。フォーム送信をしない場合は、type=buttonを明示的に指定したほうが良いですね。

buttonとinput要素

質問・感想
回答

button要素はHTML4で登場した比較的新しい要素です (といっても、20年の歴史がありますが……)。

昔はbutton要素がなく、<input type=button>を使っていましたが、ボタンの見た目が制御しにくいという問題がありました。ボタンの見た目を変えたい場合には<input type=image>を使って画像をボタンにするということも行われていました。button要素であれば、中にさまざまな要素を入れることもでき、スタイルの制御も自由が利きますので、最近はbutton要素を使うことが多いかと思います。

ただ、バックエンド側のフレームワークを使っている場合、リンクやフォームコントロールをフレームワークの機能で動的に生成しなければならない場合があります。この際、フレームワークの機能がbutton要素に対応していないと、aかinputにせざるをえないことがあります。これはシステム側の制約ですね。

このような場合には、<input type=button>や<input type=submit>を使っても問題ありません。これらもれっきとしたボタンですので、キーボードでフォーカスが当たる、スクリーンリーダーで「ボタン」と読まれる、といったbutton要素と同じ特徴を備えています。

buttonとa

質問・感想
回答

今回はご紹介できませんでしたが、実は本書にはこの議論もあります（9章が該当します）。a要素はキーボードフォーカスが当たりますが、あくまでリンクですので、スクリーンリーダーにはリンクとして扱われます。見た目がボタンでも、機能がリンク（つまり別ページに遷移するもの）であればa要素を使ったほうが良いでしょう。なお、ボタンにマウスカーソルを載せた際にポインター（指）にすべきかどうか、という議論も同じ章で語られていますので、ご参考ください。

その他マークアップの質問

質問・感想
回答

今回はご紹介できませんでしたが、本書では解説されていますので、ぜひご覧ください。個人的には、可能であれば純粋に日付を見出しの後ろに置く (マークアップだけでなく、見た目上も後ろに置く) のが良いと思っています。

質問・感想
回答

aria-hiddenはWAI-ARIAの属性、hiddenはHTML5の属性です。似ていますが意味合いは異なり、aria-hiddenが見た目に影響しないのに対し、hiddenは見た目上も非表示になります (display:noneを指定した時と同じような挙動です)。

質問・感想
回答

今回はご紹介しませんでしたが、本書で著者のヘイドンさんは以下のようなことをおっしゃっています。

HTMLの構造は、自然言語の構造と同じように、ニュアンスで判断するべきです。役立つのか、じゃまなのか、少なすぎるのか、多すぎるのかといった観点です。

あることを表現する言葉が一つでないように、ある構造をマークアップする方法も一つではなく、どれが正しい、どれが間違っている、ということはないというのが著者の考えです。ただし、わかりにくい、伝わりにくいということはあります。マークアップの方法によって、伝わりやすくなったり、より多くの人に伝わるようになったりするわけです。この点も言葉と同じですね。

その他

質問・感想
回答

ありがとうございます。勉強になります。占いには詳しくなく、八卦と言われても良くわからないというのが正直なところでした。よろしければ詳しく解説していただけると嬉しいです!

ダウンロード

テンプレートエンジンPugを使った、みんなでやるウェブ制作
中村 勇希（トゥーアール）

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

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

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

ツール

ejsはどうなの？

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

# メリット

こちらは「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」なんかがそうですね。知りませんでした。

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

ダウンロード

CSSをちゃんと書くためには？
久保 知己（まぼろし）+伊藤 由暁（まぼろし）

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

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

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

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

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

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

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

https://style-validator.io/

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

アンケートへの回答

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

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

久保

伊藤

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

詳細度が高くなっているとリファクタリングがしにくいのは私も感じます。
どの程度リファクタリングするのかわからないのですが、もし全ての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で実現したい振る舞いによって、宣言の解は変わってきます。

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

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

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

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

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

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

.box {
  // .box__header
  &__header {}

  // .box__body
  &__body {}

  // .box__footer
  &__footer {}
}

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

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

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

.box {
  @at-root {
    & {color: navy}
    .box__header {color: gold}
    .box__body {color: tomato}
    .box__footer {color: skyblue}
  }
}

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

.box {color: navy}
.box__header {color: gold}
.box__body {color: tomato}
.box__footer {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の組み込み関数のunique_id()と組み合わせてキャッシュバスターを付与することができます。

@function cache-buster($path) {
  @return #{$path + "?" + unique_id()};
}

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

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

Generated by SassMeister.com.

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

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

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

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

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

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

SCSS記法とSass記法の違い

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

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

// 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記法
=ir
  display: block
  overflow: hidden
  text-indent: 101%
  white-space: nowrap

.nav
  color: blue
  font-size: 0.3em

  a
    +ir
    width: 50px
    &:hover
      background-color: #eee

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

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

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

ダウンロード

Grid Layoutがやってきた！ Flexboxやfloatとの適切な使い分け方法
鹿野 壮（ICS）

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

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

など、想像よりも多くの反響があり嬉しく思います。私自身が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」）。

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

複数行になる可能性があるものは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行のレイアウトになります。

.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に対応しました。

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

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

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

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

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

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

とすることで、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の便利さが伝わったようで何よりです。

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

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

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

告知

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

ダウンロード

ここまでのJavaScriptスタンダードと、これからのJavaScript ES6について
阿部 正幸（KDDIウェブコミュニケーションズ）

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@等でつぶやておりますので、是非フォローいただけると幸いです。

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

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

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

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

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

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

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

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

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

ダウンロード

Gitの入門とGitを利用した共同制作方法
大串 肇（mgn）

補足

こんにちわ。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ページを御覧ください。

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

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

ダウンロード

CSS設計方法論とその先
高津戸 壮（ピクセルグリッド）

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

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

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

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

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

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

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

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

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

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

ダウンロード

お問い合わせ

ご不明点やお気づきの点がありましたら、フォームからご連絡ください。

お問い合わせ

このページの上部に戻る