What's New Qiita

20200219のHTMLに関する記事は11件です。

  • 投稿日：2020-02-19T21:39:23+09:00

【jQuery】要素をn個ずつ表示するtoggleボタン【ぬるっと】

経緯

なが〜〜いリストをn個ずつ段階的に表示させたかった

クリックすると要素をぬるっと表示する「もっと見る」ボタンは
toggle系メソッドで簡単に出来るのですが、
そのまま使うと表示/非表示の切り替えだけだったのでアレンジ。

※今回は、要素をすべて表示しきったら「もっと見る」ボタンを消すようにしています。

間違っているところがあればご指摘下さい。

参考にさせていただいた記事

大変参考になりました。神です。

n件ずつ表示する「もっと見る」ボタンのシンプル実装

デモ

こんな感じです。

https://codepen.io/kotottt/pen/vYOKqxm

HTML/CSS

最初にいくつか表示した状態からスタートします。

HTMLはこちら
細かいところは、伝家の宝刀『割愛』です。

qiita.html
<body>
  <div class="container">
    <div class="p-tags">
      <a class="p-tag">初期表示</a>
      <a class="p-tag">初期表示</a>
      <a class="p-tag none">ぬるっと後から表示</a>
      <a class="p-tag none">ぬるっと後から表示</a>
      <a class="p-tag none">ぬるっと後から表示</a>
      <a class="p-tag none">ぬるっと後から表示</a>
      <a class="p-tag none">ぬるっと後から表示</a>
      <a class="p-tag none">ぬるっと後から表示</a>
    </div>
    <div class="p-more__tags"><a href="#">もっと見る</a></div>
  </div>
</body>

CSSはこちら

style.css
.p-tags{
  display: -webkit-box;
  display: -ms-flexbox;
  display: flex;
  -ms-flex-wrap: wrap;
  flex-wrap: wrap;
  width: 100%;
  margin:10px 0;
}

.p-tag{
  display: block;
  width: 100%;
  background: #333;
  color: #fff;
  padding: 3px;
  margin-bottom: 3px; 
}

.p-more__tags{
  width: 100%;
  background: #ff69b4;
  text-align: center;
  color: #fff;
  padding: 5px 0;
}

.p-more__tags a{
  display: block;
  color: #fff;
}

.none{
  display:none; /* 見せたくない要素は見えないように */
}

jQuery

nurutto.js
var num = 2;//何個ずつ表示させていくか指定

$('.p-more__tags').on('click', function() { 
  const hiddenTags = $('.p-tags a.none');
  //noneクラスがついてる要素を指定

  var hiddenTagsNum = hiddenTags.length; 
  //noneクラスがついてる要素の個数を取得 

    if(num > hiddenTagsNum){
    //noneクラスがついてる要素の個数より最初に指定した表示させる数が多かった時
      num = hiddenTagsNum;
      //表示させる数を残りの要素数に変更
    }

  hiddenTags.slice(0, num).slideToggle();
  //noneクラスがついている要素のうち、最初からnum個目まで表示
  hiddenTags.slice(0, num).removeClass('none');
  //表示させた要素はnoneクラスを削除

  if (num == hiddenTagsNum) {
  //表示させるものがなくなったら、ボタンをフェードアウト
      $('.p-more__tags').fadeOut();
  }
});

解説

順番前後しますが、まずToggle部分から

nurruto.js
hiddenTags.slice(0, num).slideToggle();
//noneクラスがついている要素のうち、最初からnum個目まで表示

hiddenTags.slice(0, num).removeClass('none');
//表示させた要素はnoneクラスを削除

イメージで言うと、工場のベルトコンベアですね。

流れてくる非表示状態の要素を前から2個取って、slideToggleで表示。
取った要素はnoneクラスを外してあげて、ベルトコンベアから降ろす。

そうすると、さっきは３、４番目でベルトコンベアから降ろされなかった要素が前に流れてきて事実上１、２個目に。

これを取って・表示して・降ろしてを要素が無くなるまで繰り返します。

nurruto.js
if(num > hiddenTagsNum){
//noneクラスがついてる要素の個数より最初に指定した表示させる数が多かった時
  num = hiddenTagsNum;
  //表示させる数を残りの要素数に変更
}

この処理を挟んでいるのは、上の処理をして最後に残った非表示の要素が
必ずしも２個とは限らないからですね。(割り切れない可能性がある)

もし余りが１の時、numをそのまま2にすると.slice(0, num)がエラーになってしまいます。

懸念点

display: none;を最初に見せたくない要素に指定していると、
グーグル先生いわく要素が隠しコンテンツ的な扱いになるとかならないとか。

SEOへの影響を考えると、opacity: 0;からopacity: 1;への変化がいいのかなぁ。

知見のある方いらっしゃいましたらコメント下さい。。

まとめ

ざっくりまとめると、
display: none;が指定されているクラスを付けたり外したりしてるだけです。
それならaddClassやremoveClassでいいじゃないか、
と最初は思ったのですが、
それだと、ぬるっと表示できなかったのと、
cssでアニメーションをつけるにしてもdisplay: none;と相性が悪い。
そしてめんどくさい(本音)

なのでjQuery頼みでtoggle系メソッドを使いました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T21:36:47+09:00

TECH::EXPERTはカレーづくり教室だった話

はじめに

TECH::EXPERTというプログラミング教室に3日ほど通った添野です。
ProgateでHTML&CSSを2か月ほど独学したのち、通学してます。
プログラミング教室でカレーを作ってきたので記事を書きます。

Railsについて

皆さんはRuby→Railsの学習を初めて、突然、大海原にぶち込まれたような感覚になりましたか？

私は、なりました。
謎のコードの羅列、謎の黒い画面に大量に表示される謎の白い文字たち。魔術書かよ...！？
しかし、私は考えるのをやめました。そして、TECH::EXPERTがカレーづくり教室であることを悟りました。

Twitterはカレーライス

TECH::EXPERTの最初の10日間はTwitter作りをします。

Twitterを作るにあたり、最初はデータベースをつくります。
カレーライスを作るときは、お皿にライスを盛りますよね。
あとは色んな機能をRailsで実装していく。ルーを作るんです。
最後に一緒に盛り合わせるとカレーライスになる。そんな感じです。
TECH::EXPERTのRailsのレッスンは、これをひたすら繰り返すだけだったりします。

Railsはルー

Railsは語感からしてルーっぽいですね。
一見、かなりゴチャゴチャした呪文の塊に見えますが、
学校で教え込まれているのはあくまでカレーライスの作り方です。
Railsを呪文の塊として見ていると、魔法使いにはなれますが、カレー職人にはなれません。
(たまに魔法でカレーを生成する職人も見かけますが、できるのは一部の天才だけです。)
下記の図を見てください。RailsでTwitterを作るまでの一連の流れです。
ファイル名
Railsのレッスンはでこれを繰り返してるだけであり、
誰でも絶対に理解できます。大丈夫です。

簡単に説明していきます。

壱、データベースを構築する

ライスを盛ります。
インスタ映えを狙ってパンケーキを盛る人が多いです。

弐、ルーティンを設定する

7種類の具材から使うものを選び、鍋に投入します
スパイスとか、人参とか、じゃがいもとか、水とか塩とか色々。

実際に使う具材:index,new,create,show,edit,update,destroy

全部入れなくても、一応カレーライスになります。

参、コントローラを設定する

コンロに点火。グツグツ煮たり、コトコト煮たりします。

肆、ビューを設定する

ルーを皿に盛る。ライスがカレーライスにメガ進化。

まとめ

最初に1をやったら、基本的に、2~4の繰り返しです。
めちゃくちゃ簡単ですね。完成したらPCに食わせます。ちなみに途中で食わせようとすると「こんなもん食えるか！」と罵詈雑言(エラー)を浴びせられます。PCはかなりの美食家です。

Railsは一見すると難解に見えますが、本質はめっちゃ簡単です。安心してください。
TECH::EXPERTに魔術を学びに来るのはやめて、明日からは楽しくカレー作りをしましょう。

それでは。

添野又吉(@enjoy_omame)
https://twitter.com/enjoy_omame

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T19:02:52+09:00

Javascriptでhtml要素の順番を入れ替える。

はじめに

ちゃんとした説明を一度書いてみようと思った。

実際の動き

Jsのコマンドに、appendChild、insertBeforeというヤツらが存在する。
この２つは、特定の要素を最後尾、または要素の前に挿入する関数なのだが……

さて、問題である。既に存在する要素を再び追加すると何が起きるのだろうか。

ちなみに、初期状態は以下の通り。

1582104043515.jpg

HTMLそのもののソースはこちら。

html
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="utf-8">
    <title>無題</title>
</head>
<body>

<style>
#pipimi{
    border: 2px solid black;
    padding: 10px 20px;
    margin: 0;
    max-width: 200px;
}
#pipimi p{
    font-family: serif;
    margin: 0 0 0.5em 0;
}
</style>

<div id="pipimi">
    <p>なんとも低い</p>
    <p>クオリティ</p>
    <p>まあひどい</p>
</div>

<script type="text/javascript">
var tag = document.getElementById('pipimi');
var taglist = tag.getElementsByTagName('p');

var p01 = taglist[0]; // なんとも低い
var p02 = taglist[1]; // クオリティ
var p03 = taglist[2]; // まあひどい

</script>
</body>
</html>

scriptを以下のように変えてやると……

html
<script type="text/javascript">
var tag = document.getElementById('pipimi');
var taglist = tag.getElementsByTagName('p');

var p01 = taglist[0]; // なんとも低い
var p02 = taglist[1]; // クオリティ
var p03 = taglist[2]; // まあひどい

tag.appendChild(p02);

</script>

こうなる。

1582104656370.jpg

そう、既に存在する要素を「追加」すると、元の位置からは消えて、新しい位置に追加される。つまり移動するのだ。
同じ要領で、insertBeforeのほうもためしてみよう。

html
<script type="text/javascript">
var tag = document.getElementById('pipimi');
var taglist = tag.getElementsByTagName('p');

var p01 = taglist[0]; // なんとも低い
var p02 = taglist[1]; // クオリティ
var p03 = taglist[2]; // まあひどい

tag.appendChild(p02);

tag.insertBefore(p03, p01);

</script>

結果はこのとおり。完成である。
1582105232515.jpg

おわりに

不明な点などありましたら編集リクエストおねがいします。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T17:27:45+09:00

VSCodeでサーバー建ててファイル一式で納品の案

HTML/JSをサーバー動作でスタンドアロン納品したいときにVSCodeでLiveServerして簡易サーバーするメモ
XAMMPとかApache入れるなど結構大変なので。
他にいい方法あるとうれしい

VSCodeをZip形式でダウンロード

https://code.visualstudio.com/download
NoName_2020-2-19_10-12-35_No-00.png

拡張機能をダウンロード

右下の方にダウンロードできるところあり

Live Server

https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer
NoName_2020-2-19_17-20-17_No-00.png

Japanese Language Pack for Visual Studio Code

https://marketplace.visualstudio.com/items?itemName=MS-CEINTL.vscode-language-pack-ja
NoName_2020-2-19_17-20-37_No-00.png

VSCodeに拡張機能をインストール

日本語化してLiveサーバーな状態
dataフォルダつくるとPCにインストしたVSCodeの設定を読み込まなくなるので便利でした
NoName_2020-2-19_17-23-44_No-00.png

参考サイト

Visual Studio CodeをオフラインPCで使用する
https://qiita.com/mekemeke421/items/98d5a3e2f2cc7517a6ab

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T17:23:35+09:00

HCDCによる分析と考察／CSS設計のモデル図が出来るまで

はじめに

この情報は、別の記事で紹介している「HCDCモデル図」がどのように作られたか。という背景説明に該当するものです。情報の最初からご覧になりたい場合は以下を先にご覧ください。
1段上のCSS設計・コーディングの概念図（HCDCモデル図）

HCDCとは、Human Centered Data Categorize の頭文字を取ったもので、制作者（人間）中心にコーディングを捉え、汎用性を意識した「分類」のことです。

HCDCモデルの説明

この「分類」をもとに図化したものが「HCDCモデル図」となります。
この記事では分類の方を中心に説明します。

HCDCは恣意的にならないよう複数の制作者の意見を聞きながら分類していますが、何かを定めている以上、偏りが無いとは言えません。もしこの記事の内容が「根本的に違う」と感じたなら、そこから作られたHCDCモデル図もマッチしない事になり、逆に、HCDCモデル図はマッチしそうだが詳細が知りたい。といった場合は、こちらの記事で何か繋がるかもしれません。
また、以前投稿した「HTML+CSSコーディングの言語化」を背景としていますが、これよりも狭い範囲、切り口において分析・分類しています。

※この記事は標準化ノウハウ公開の一環として書いています。仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。

4つの分析・考察内容

HCDCによる分類内容は以下の通りです。
それぞれのセクションにて詳しく説明します。

  1. 作業ステップ
    …　作業着手から実装までの制作ステップ
  2. データの役割
    …　コーディング時のデータ取り回しに必要となる役割
  3. 情報粒度
    …　部品の使い方や粒度についての分類
  4. 堅牢性と再利用
    …　グローバルな影響を回避するための策と、再利用の要望をふまえた分類

1・ 作業ステップ

まず最初は、作業ステップについての分解・分類です。
制作者が完成予想図や全体の構成表などの資料を受け取り、全体ボリュームの把握や確認が終ったその後、どのような行動をおこなうのかをリスト化しました。

これらは、ほぼ同時におこなっているものになりますが、やっている事を疎結合で分解していくとこのようなステップになる。というものです。
以下のようになります。

6つのステップ

  1. 情報分解
  2. 粒度考案
  3. 命名考案
  4. 堅牢性と再利用の考案
  5. 制作管理・考案
  6. 実装

ステップの説明

1・情報分解
デザインやワイヤーフレームといった完成予想図をコードで再現するために、まずは大きな情報の区分を確認しながら分解しているはずです。そうでなければ、効率的にコードに起こせないためです。
例えば、ヘッダーやメインエリア、フッターなどの大きな区域。そして、ブランディングエリアやナビゲーション。コンテンツエリアはどこからどこまでが１つの区域になっているか。など、ページ間の共通性も踏まえながら、視覚情報を情報の属性によって分解します。
2・粒度考案
近年のコーディングではWebページの視覚情報を部品やパーツとして捉えて管理する方法が主流となっています。このため、情報属性による分解とほぼ同時か、区分が終わった後に、どの粒度で部品化するのか（≒どの区切りでSassファイルに切り出すか）を考えるはずです。
大きな塊で影響を閉じてしまうのか、小さなパーツをグローバルに再利用するのかも考えるでしょう
3・命名考案
どの粒度で部品化するかが決まれば、HTMLの記述を想定しながら、どの部品にどういった名前を与えて管理していくかを考案します。この時、次に記載する堅牢性と再利用設計も同時におこなうかもしれません。
4・堅牢性と再利用の考案
セレクタの使い方とグローバルな再利用、HTMLの記述など、前ステップの2、3とも絡んだ複雑な設計ポイントになります。これについては別項にて考察・分類します。
5・制作管理・考案
コードを記述するためのファイル名とそのファイルを管理するための方法を考案します。概念と設計が予測しやすくなるようにファイル構造を考える必要があります。
6・実装
上記を設計した後、もしくは同時に進めながらコードを記述します。 文書構造、見た目、働きという3種類を一つのWebページの中に融合していく作業といえます。

これらは、モデル図に直接影響するというよりも、何が必要かを行動ベースで把握するためのものです。
作業時の基本ステップであると同時に、後の手法構築のときに「何を定めておけば、制作者同士の意識を一致させられるのか」のマップにもなります。

2・ データの役割

つぎに、視覚情報や働きをコードに置き換えていく中で、「必要になる役割」を分類します。最小数で分けると以下のようにまとまります。

3つの分類

  • A・視覚情報や働きをつくりたい
    …　視覚情報や働きをレンダリングするためのもの。実体。
  • B・部品を「塊」で制御したい
    …　中身に部品を配置して位置決めやカラム落ちの制御をおこなうもの。入れ物。
  • C・コーディング用に便利に使える働きが欲しい
    …　AとBを便利に拡張するためのもの。利便性。

分類の説明

A ・ 視覚情報や働きをつくりたい

デザインを再現するための部品で、基本となる役割です。写真や見出し、テキスト、リスト、表、ロゴやナビゲーションなどの視覚情報が該当し、部品に付帯する動きなども含まれます。
CSS視点では「意匠用のスタイルを与えるもの全般」と言えます。少々強引ですが、もし、同じ視点でHTML側を見た時には、imgやp、h1～6、ul tableといったタグがこの要求にマッチするでしょう。

B ・ 部品を「塊」で制御したい

「A」の部品をコード上でひとまとめにして位置を制御したり、レスポンシブ時に便利に動かすための「枠」です。中に入る部品の大小は関係ありません。
コンテンツセクションに対するヘッダーやフッター、グリッドシステムのような透明な箱、サイドカラムを制御するための大きな仕切り、部品のラッパーやインナーなど、いくつか欲しくなる役割があります。
同じ視点でHTML側を見れば、divやsection、header footer main articleなどの範囲に意味付けするようなタグがこの要求にマッチするでしょう。

C ・ コーディング用に便利に使える働きが欲しい

後付けで加えられるような便利な役割のものです。具体的な例で言えば、ステートのclassであったり、単一プロパティで色やサイズを変えるなどのヘルパー系class等です。
マルチクラスで加える事もあれば、BEMのように変化も命名の一部とするパターンもあるでしょう。同じ視点でHTML側を見れば、i b u mark brやrubyなどが該当しそうです。

※上記、3種類の説明の中にHTML視点の説明がありますが、この例は半ば強引に区分けした例です。仕組み全体には影響しませんが、ものの見かたを変えればこうなる。程度の情報として捉えてください。

3・ 情報粒度

3つめは部品の粒度に関する考察です。
近年の一般的なコーディング方法としては、完成予想図などの視覚情報をコードに起こすために、情報をグルーピングして塊として切り出します。
なぜ切り出すかというと、その塊に名前を与え、部品と捉えてスタイリングするためです。この流れの中で「主となる情報の塊」と「構成する部品」という考え方が出てきます。例えば以下のようなイメージです。

粒度のイメージ図

何かの部品は、より大きな何かの構成部品です。オレンジ枠のように、「これ以上は他と同じに出来ない区画・塊」があり、それらの集まりで「Webページ」となっています。
これらの分類（分解）において、欲しくなる区分はおおよそ以下のようになります。

2種類の区分と4つの分類

A ・ 情報属性による自立性の高い領域・区画

  • 1 ・ 独立した情報の塊　…　オレンジ枠

B ・ 何かの一部として構成される部品

  • 2 ・ 中程度の部品　…　緑枠
  • 3 ・ 小程度の部品　…　赤枠
  • 4 ・ 最小の部品　…　水色枠

捕捉説明

これらの分類は「粒度」という言葉で表すのが一般的になっています。粒度とは、元は「粒の大きさ」という意味の言葉ですが、コーディングにおける粒度とはレンダリング時の面積だけに依存せず、また、コード量だけでも判断できない抽象的な意味で使われます。粒度に言及した有名な仕組みはAtomicDesignですが、上記はAtomicDesignとは似て非なるものとお考え下さい。

4・ 堅牢性と再利用

最後は、スタイリングのアプローチに関する分類です。

誰もが「破綻しにくく、効率の良い状態でデータを管理したい」と考えることでしょう。
スタイリングのアプローチは、分解していくと堅牢性を高める方向と、コード再利用による効率化という二つの軸がありますが、どちらも必要になるケースもあります。

言語仕様の側面と、著名なCSS設計手法の本質部分を抜き出し、根本が異なる3つのパターンに分類しました。

3つのパターン

  1. 汎用部品の再利用
    …　スタイリング済の完成品を、グローバルに再利用するアプローチ
  2. HTML上の包括要素へのセレクタ
    …　先祖要素の名前から、包括した部品へのセレクタを使ってスタイリングするアプローチ
  3. 要素命名の工夫
    …　命名の工夫による重複リスク低減と、詳細度を低く保つためのアプローチ

パターンの説明

※ 仮に、「text＝短いセンテンスのテキストデータ」と定め、これをもとに説明します。

1・汎用部品の再利用

HTMLとCSSの仕様上、class属性で名前を与えれば全てが再利用可能な部品となります。しかし、制作者中心に考えると、「再利用出来る状態にある」のと、「再利用したいかどうか」は全く別の次元の話です。
「1・汎用部品の再利用」の例は、制作者が部品を完成状態で再利用したいと望むパターンです。この場合、どこに置いてもスタイルが有効になるよう、命名を第一セレクタで指定してプロパティを記述するでしょう。

HTML
<span class="text">一行の短いテキスト</span>
<span class="text text-accent">一行の短いテキスト</span>
CSS
.text {
    font-size: 0.75rem;
    line-height: normal;
}
.text-accent {
    color: orange;
}

つまりは、OOCSSが提唱する方向にあるアプローチという事になります。

2・HTML上の包括要素へのセレクタ

子孫(子)セレクタを用いて、HTMLコードで包括した内部要素をスタイリングする方法です。
.blockNameという部品の中に.textの要素を記述し、.blockNameからの子孫セレクタでスタイリングしています。

HTML
<div class="blockName">
    <span class="text">一行の短いテキスト</span>
    <span class="text text-accent">一行の短いアクセントテキスト</span>
</div>
CSS
.blockName {
    padding: 1em 2em;
    background-color: gray;
}
.blockName .text {
    font-size: 0.75rem;
    line-height: normal;
}
.blockName .text-accent {
    color: orange;
}
.text {
    /*グローバルなスタイルは与えない*/
}

これにより、子孫セレクタの条件に当てはまらない場所に.textを設置しても同じスタイルは適用されません。言い方を変えると、.textはグローバルに再利用できない（制作者はグローバルな再利用を望んでいないためこのようにしている）とも言えます。

この方法は、ともすれば様々な「意図しない影響」を生む原因となりえますが、古くから使われてきた一般的かつ有用なアプローチです。※なぜ意図しない影響が出るのかについては、書籍やWebなどで沢山の情報が見られるため、ここでは割愛します。

3・要素命名の工夫

要素命名を工夫することによって、堅牢性を高めながら詳細度を低く抑える試みです。有名なものはBEM記法です。「名前空間(親の部品名)＋内部構成パーツ名」でサイトの中で命名を一意化し、重複のリスクを回避します。
以下のような記述になります。

HTML
<div class="blockName">
    <p class="blockName__text">一行の短いテキスト</p>
    <p class="blockName__text--accent">一行の短いアクセントテキスト</p>
</div>
CSS
.blockName {
    padding: 1em 2em;
    background-color: gray;
}
.blockName__text {
    font-size: 0.75rem;
    line-height: normal;
}
.blockName__text--accent {
    font-size: 0.75rem;
    line-height: normal;
    color: orange;
}

textの意味は、「短いセンテンスのテキストデータ」と定めましたが、上記の例ではBEM記法により単語が連結され、別の文字列blockName__textになっています。
機械であればこの二つを別の文字列として捉えますが、制作者はtextの意味を理解・認識したままです。つまり、「textという命名と、その名前が持つ意味を再利用して、別の要素の専用部品にした」 と言えます。（この例では、利便系にあたる.accentも同様です）

また、上記とは感覚が異なるものになりますが、プレフィックスを付与することでも、同じ名前を再利用できます。例えばtext → .c-textといった具合にです。textと.c-textは、機械から見れば別のものですが、人はその役割を予測・理解できます。

組み合わせや利用方法

このように、3つのアプローチはそれぞれ異なる特性を持ちます。いずれにしても「命名」を中心に考えるとそれぞれのアプローチに辻褄の合う説明ができます。
細かく考えれば他にも沢山のアプローチは思いつきますが、いずれも3種類からの派生として収まるのではないでしょうか。
どれを主とするのかは、サイト種別やデータ物量、同一部品の流用や類似部品の多さなどによって判断しなくてはならないでしょう。例えばページ数の少ないコーポレート系のサイトと、大規模なシステム管理画面では、理想の設計は異なるものになるはずです。

どれを使っても言語仕様上の「不正解」ではありません。何を使って何を制限するのかは、CSS設計手法やガイド・レギュレーションによって制作者が定めることになります。

分類の整理と図化

ここまで、様々な行動や欲求について分類してきました。
情報を正規化して図に起こすと、以下のようになります。

分類による概念図

上記の4つのデータ分類にアルファベットで名前を与えたものが「HCDCモデル図」です。

関連情報

クレジット・その他

Ultimate Coding
概要・前提事項

この仕組みは、組織所属時に業務効率化のために構築したものであり、許可を得た上で設計者本人が個人活動として公開しています。商用の制作や開発には利用していただけますが、仕組みを販売したり媒体化するなどの、制作以外での商用利用はご遠慮下さい。質問その他、何かあれば@croco_worksまでお声かけください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T17:17:31+09:00

1段上のCSS設計・コーディングの概念図（HCDCモデル図）

はじめに

HTML＋CSSコーディングにおいて、「どのように要素を特定してスタイリングするのか」というCSS設計上の課題に対し、「ひとつ上の視点で思考できる概念図」を紹介します。

この図を用いることで、3種類の異なるスタイリングアプローチ（OOCSS方式 / 包括要素基点方式 / BEM方式）の本質を一度に俯瞰できるため、全てを同じ枠の中で捉えられます。そして、最終的には種別や規模の異なるサイトやプロジェクトに対し、同じメソッドを使ってそれぞれ最適な設計がおこなえるようになります。

※この記事は標準化ノウハウ公開の一環として書いています。仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。

経緯 / 制作者中心のデータ分類

そもそもですが、HTMLとCSSは目的も仕様も異なる言語です。
HTML+CSSコーディングを一般的な視点で見れば「異なるものをWebページ上で融合させる」という高度な事をおこなっているわけですが、2つの言語にはエラー出力機能が無い上に、全域への影響を簡単に作成できてしまいます。この"自由さ"が現代の複雑なWeb制作においては仇となり、管理上の様々な問題を引き起こしやすい状態となっています。

従来からあるこの問題を解決しながらも高度な標準化を目指すとすれば、片方の言語視点のルールだけでは材料不十分です。では、何を基準にするのか。ですが、出てきたアイデアが「制作者はどうしたかったのかを考える」ということでした。
制作者はHTMLとCSSで何をしてきたのか・どうしたかったのか

標準化のためにHTML+CSSコーディングについて 言語化 をおこない、いつくかの設計手法を交えた行動分析と考察を経て、先にCSS側のものとして作成したのが今回の概念図（モデル図）です。
図ができるまでの過程（分析・考察・分類・正規化）の情報は、別記事として「HCDCモデル図が出来るまで／行動分析と考察による分類」に記載しています。

HCDCモデル図

以下が完成した概念図（HCDCモデル図）です。

この図は、オブジェクトに求める4つのデータ分類「 Block / Parts / Structure / Utility 」と、既知のスタイリングパターン「 A / B / C 」の関連性を1枚の図に納めることによって、「どのように要素を特定してスタイリングするのか」という課題に対し、選択可能なパターンを秩序立てて示す計器のような役割を果たします。

HCDCモデル図

左半分はレンダリングに使われるような"物質的な"感覚に近い部品で、右半分はコーディングの都合によって欲しくなるような役割・部品です。
この図の中には業界を通して斬新と言えるような語句や概念は含まれていません。相関関係さえ把握してしまえばすぐに利用を開始できるでしょう。設計時にはアプローチを俯瞰した思考用ツールとなり、コーディングの最中にはいつでも立ち戻れるマスターの概念として働きます。

以下から、図の説明をおこないます。

モデル図の要素（データ分類）

まず、主要な4つのデータ分類、Block ・ Parts ・ Structure ・ Utility についての説明です。
これらは具体的な手法やディレクトリ名を示すものではありません。「コーディングの時に、こういうのってあるよね」という制作視点での、役割に対して与えた名称とお考え下さい。

1 ・ Block（ブロック）

Blockは、機能・役割・情報属性などの基準によって、制作者が「これ以上は他と同じにできない」と判断した範囲の区画・塊です。
Blockのイメージ
具体的には、ヘッダーやフッター、ブランディングエリア、ナビゲーション、コンテンツの1セクションなど、制作者が「この範囲を塊として扱う」と定めたものが該当します。
おおよそdivに対して名前が与えられ、HTML側はある程度まとまった行数のコードになるでしょう。
「ヘッダーのBlock」の中に「ナビゲーションのBlock」が配置される等、Blockは、Block同士のネストが恒常的に発生します。

2 ・ Parts（パーツ）

Partsは、再利用する可能性の高い、もしくは制作者が再利用したいと望む中規模～小規模の要素です。
Partsのイメージ
カード、詳細リストといった中型のリピート部品や、見出しやボタン、ラジオボタン一個、テキスト一行。といったもので、レンダリングに直接関わるものが該当します。これらは粒度の概念により細分類できます。（※ 粒度の分類はここでは定めません）
Partsは、A・B・Cの3種類のスタイリング方法によってBlockの構成部品になれます。また、同様に、自身よりも大きな粒度のPartsの構成部品になれます。

3 ・ Structure（ストラクチャ）

Structureは、Blockの中のPartsをまとめたり、Blockそのものを大きな範囲でレスポンシブ制御したり、ページのカラム分割や画面分断といったような、コーディングの都合で欲しくなる補助ボックス・構造です。
Structureのイメージ
インナー・アウターや、セクションごとのヘッダー・フッター、位置決め用のレイアウトボックスなど、用途により細分類できます。（※用途の分類はここでは定めません）
大きなカラム分割の中にグリッドが入る 等、Structure同士の入れ子も考えられますが、入れ物である以上Structureがデータ表示の「主役」になる事は少ないと言えます。A・B・Cの3種類のスタイリング方法によって、Blockもしくは、粒度の大きなPartsの構造になれます。

4 ・ Utility（ユーティリティ）

Utilityは、コーディング用の便利な役割です。
Utilityのイメージ
状態変化を表すものとして利用したり、色や余白などの単一プロパティを後付けするために利用したり、要素の識別子に使うなど用途は様々です。（※用途の分類はここでは定めません）
単体で「主役」になることは少なく、コーディング都合の補助的な役割と言えます。

スタイリングのパターン

次に、A ・ B ・ C のスタイリングパターンについて説明します。
どのパターンも全て、命名を主役として考えます。（命名 ≒ 部品 と捉えます）

A ・ スタイル完成品を使う

パターンAは、完成させた部品をグローバルに再利用するアプローチです。
「Parts」を例にすると、ボタンを.btnと命名し、第一セレクタで完全なスタイルを与え、いたるところに同じものを配置できるようにします。
パターンA Partsの利用方法説明
「Structure」の場合も同様に、スタイルを完成させてからそのまま再利用します。
パターンA Structureの利用方法説明
「Utility」の場合は、スタイルを完成させてから、目的の対象にマルチクラスで付与する事になります。図の例では対象を「非表示」の状態にしますが、色やサイズの後付けを目的としたものもあるでしょう。
パターンA Utilityの利用方法説明
このように、グローバルに利用できる形で部品のスタイルを完成させておいて、HTMLに設置していくような使い方になるのが「パターンA」です。

B ・ スタイル無し、もしくはスタイル半完成品を使う

パターンBは、包括要素の命名を第一セレクタに指定してから対象をセレクトするアプローチです。
例えば「Parts」の場合、.btnというボタン用の命名を.boxの内部に配置して.box .btn{}といった子孫セレクタでスタイリングします。
パターンB Partsの利用方法説明
「Structure」の場合も同様に、命名（部品）を.boxの内部に配置してから、包括要素である親（先祖）要素を基点にセレクタを記述してスタイリングします。
パターンB Structureの利用方法説明
「Utility」をこのパターンで使う場合は、対象に命名をマルチクラスで付与してから、包括要素である親（先祖）要素を基点にスタイリングします。
パターンB Utilityの利用方法説明
この時の対象（例で言うと.btn、.l-width、.is-close、）は、第一セレクタによるグローバルなスタイルは一切与えないか、共通した最低限のスタイルのみを与えて半完成の状態で使うかのどちらかで利用します。HTML側の記述は、ネストすればパターンAと同じになるものの、CSSは異なる意味合いになっています。

このように"命名を設置"してから、先祖要素を基点にスタイリングする方法が「パターンB」です。

C ・ 命名を1つに結合して使う

パターンCは、命名の工夫（単語連結）によるアプローチです。 ※事例は全てBEMの記法で説明
例えば「Parts」の場合、.textという命名を、親となる.boxの命名と連結して、.box__textという新たな命名を作成した上で使用します。
パターンC Partsの利用方法説明
「Structure」の場合も同様に、親となる命名に連結します。
パターンC Structureの利用方法説明
「Utility」は、BEMの概念で置き換えると「Modifire」となるため以下のような連結方法になります。（※他の記法・ルールを使うのであれば、この限りではありません）
パターンC Utilityの利用方法説明
このように命名のみを連結し、親の名前による「名前空間」を作り、元の命名とは異なる部品としてスタイリングする方法が「パターンC」です。

ちなみに、BEMの概念「Block ＋ Element ＋ Modifire」は、HCDCモデル図の「Block ＋ Parts(or Structure) ＋ Utility」で再現できます（本質的な意味が同じになります）

総括

この概念図（HCDCモデル図）が全ての制作者や現場にとって適合するものとは言い切れませんが、少なくとも、ここで挙げたアプローチに関しては、整理されたパターンとして把握できるかと思います。

パターン化できれば「混沌としたもの」ではなくなり、検証もおこないやすくなります。検証がおこないやすくなれば、よりよい方法・スキームを蓄積し、独自の効率化ルールを作成しやすくなるのではないでしょうか。

既存の設計手法に意識を捕らわれることなく、制作者の意図を持って設計を自由に選択し、コードを安定的に制御するための手助けになれば幸いです。

以降の展望

この概念図は標準化された仕組みとして実用できます。
概念を実用するためには、概念と物理の間に"わだかまりのない"手法が必要となります。これは、ご自身で考案・構築することもできますし、今後紹介していく以下のような情報を利用することもできます。

標準化の方法（今後紹介する情報）

複数の制作者が認識を合わせ続けるには、ある程度の範囲の取り決め・指針となるものが必要です。以下の4つは「業務標準化」という意味において必要になると判断したガイド・手法です。

標準化のための4つの手法

上記4つは「HCDCモデル図が出来るまで」の「作業ステップ」の要所と対応する形になっており、簡単に言えば、以下のような流れを誰もが同じ精度と品質で実行するためのものです。

  1. まずは、デザインやワイヤーフレームなどの視覚情報を分解。粒度分類をおこなう
  2. つぎに、分解・分類した対象に対して一貫性のある単語で名前を検討する
  3. 単語連結規則に従ってコーディング用の正式な命名をおこなった上で
  4. 記述したCSSコード(Sassファイル)を、プロジェクトに最適なディレクトリ構造で管理する

実際のコード記述まで安定的に標準化するには、CSS側面だけではなく、HTML側の取り決めやルールも必要になりますが、これは手法よりも強い立場の「ルール・レギュレーション」で定義します。

これらは既に完成して運用中ですが、一度に記事作成できないため順次公開していく予定です。
一連の情報「Ultimate Coding」の方針や、標準化に関する考え方については「UltimateCoding 概要・前提事項」に記載していますので、ご興味があればご確認ください。

関連記事

クレジット・その他

Ultimate Coding
概要・前提事項

この仕組みは、組織所属時に業務効率化のために構築したものであり、許可を得た上で設計者本人が個人活動として公開しています。商用の制作や開発には利用していただけますが、仕組みを販売したり媒体化するなどの、制作以外での商用利用はご遠慮下さい。質問その他、何かあれば@croco_worksまでお声かけください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T15:43:46+09:00

Javascriptで改行したら下に伸びるテキストボックスをつくる

はじめに

読んで字の通り、可変テキストボックスを実装する関数をつくってみました。
改行するごとに下へ下へと枠が伸びてゆくので、見栄えはよくなるかも。

コード

仕組みとしては、改行文字（\n）の数を数えて、改行文字 ✕ 一行分の高さ ＋ もともとの高さ　となるようにした感じ。
パソコンは改行そのものも「改行という名の文字」として認識しているので、そこを突いてやればいいのダダダダッ！というわけだ。

なお、CSSは適用されているスタイルをブラウザから自動取得してくる仕組みになっている。
わざわざJsを書き換えてやらずとも、使いまわすことができるというわけだ。

javascript
function afeed(element){
    if(element.tagName == 'TEXTAREA'){

        // 行の高さとpadding値を取得する。IEやSafariなど、ブラウザによって必要な関数が異なるので、or（||）で３パターン分取れるようにしてある。
        var stylelists = window.getComputedStyle(element, null) || element.currentStyle || document.defaultView.getComputedStyle(element, '');

        // １行あたりの高さ。
        var line_height = stylelists.getPropertyValue('line-height').replace(/px/g , "");

        // 高さの初期値。
        var firstheight = Number(element.offsetHeight) - stylelists.getPropertyValue('padding-top').replace(/px/g , "") - stylelists.getPropertyValue('padding-top').replace(/px/g , "");


        element.style.height = firstheight + 'px';
        element.style.resize = 'none';

        var line_length;
        var result_height;
        element.addEventListener('input', function(){

            // 改行文字の個数を取得
            if(element.value.match(/\n/g) === null){
                line_length = 0;
            }else{
                line_length = element.value.match(/\n/g).length;
            }

            // 見栄えの関係上、１つ以上改行があるときは文字のすぐ下に枠が来るようにする
            if(line_length === 0){
                result_height = firstheight;
            }else{
                result_height = ((line_length - 1) * line_height) + firstheight;
            }
            element.style.height = result_height + 'px';
        }, false);
    }else{
        console.log('Error: テキストエリアでないものに対して適用されています。');
    }
}

Codepenを用いたサンプル

See the Pen テキストエリア自動改行 by Yomogenium (@yomogenium) on CodePen.

おわりに

間違いやわかりにくい箇所ありましたら、編集リクエストをお願いいたします。

参考文献

https://amachang.hatenablog.com/entry/20070611/1181554170

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T14:46:08+09:00

フロントエンド周りの便利ツール

今回は何個かフロントエンド開発で使う便利ツールを紹介したいと思います。

1.chromeの拡張機能「Responsive Viewer」

まず最初に紹介するのはchromeの拡張機能のResponsive Viewerです。
こちらの拡張機能では任意のURLを叩けば各デバイスを一覧で一斉に表示してくれます。
なので、レスポンシブの開発の時に非常に役に立つと思います。(レスポンシブでなくても役立つ)

スクリーンショット_2020-02-19_14_18_06.png

使い方も簡単なのでおすすめです。

参考: https://chrome.google.com/webstore/detail/responsive-viewer/inmopeiepgfljkpkidclfgbgbmfcennb/related

2.chromeの拡張機能「PerfectPixel」

次に紹介するのはコーダーやフロントエンドの人には結構必須かもしれないです。
こちらもchromeの拡張機能のPerfectPixelです。
こちらはjpgかpngかを選択するとブラウザ上に指定した画像が出て
実際に作成している製作物に合わせることができます。

スクリーンショット_2020-02-19_14_34_37.png

上記の画像は適当なスクショを撮ってやっていますが、実際はデザイナーや自分で作ったjpgかpngのカンプなどを使ってください。

画像の透過率ももちろん変えられるし、ドラッグして画像の位置を移動、操作パネルから画像の位置を移動もできるので是非使ってみてください。

参考: https://chrome.google.com/webstore/detail/perfectpixel-by-welldonec/dkaagdgjmgdmbnecmcefdhjekcoceebi/related?hl=ja

3.vscodeの拡張機能「Live Server」

参考: https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer

3つ目はvscodeの拡張機能のLive Serverを紹介したいと思います。
こちらは環境構築をしなくても編集中、作成中のプロジェクトを確認できる優れものです！
nginx周りの設定とか結構時間取られたりするので軽いプロジェクトならこれでやってしまいます。

使い方も簡単でvscodeでLive Serverをインストールしてください。

スクリーンショット 2020-02-19 14.43.05.png
こんな感じで検索すれば出てくるはずなので、出てきたらinstallのボタンを押してください。
そうするとエディターの右下に
スクリーンショット 2020-02-19 14.44.37.png
Go Liveというとこが出てくるのでそれを押すと勝手にブラウザを開いて該当のファイルを確認できます。

まとめ

他にも便利ツールはたくさんあると思うのでみなさんよかったら教えてください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T05:48:52+09:00

HTMLのclassの中を CSSにて変化させるときの注意点

classを使用する際、ドットを必ず先頭に付ける

例

CSS
.h1 {
font: 20px;
}

こうしないと反応しません

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T05:34:12+09:00

CSSフレームワークから学ぶクラス名の付け方

この記事では、CSSのクラス名についてCSSフレームワークを参考に考える方法をお伝えします。

特に以下の3段階に分けて書いてみました。

  • 何から始めていいのかわからない。→ STEP1
  • クラスにバリエーションをつけるときの名称に迷う。→ STEP2
  • 構造が複雑なときのクラス名の付け方がわからない。→ STEP3

お急ぎの方は、気になる部分だけ読んでみてください！
そもそも「CSSフレームワークって何？初めて聞いた。」な人は STEP0 から...。

STEP0．CSSフレームワークって何？

簡単に言うとCSSフレームワークとは、Webページを作る際に使える「素材集」です。
Webページ作成時によく使うパーツやレイアウトをまとめて提供しており、フレームワークを読み込めば、クラス名を指定するだけで統一感のある画面を作成することができます。

フレームワークによって特徴やデザインも様々異なります。検索するとまとめサイトもたくさん出てくるのでぜひ色々調べてみてください。
ここでは、比較的有名な以下3つのフレームワークを参考にしていきます。
(私が初めに教えてもらったから有名だと思っているだけかもしれない...)

(上のリンクは各CSSフレームワークのDocumentationに繋がっています。Documantationは、CSSフレームワークの説明書と考えるとよいかと思います。)

STEP1．何から始めていいのかわからない

とりあえずHTMLは書いたけど、どんなクラス名がいいか分からないというあなた。
まず作りたいコンポーネント(部品)の一般的な名称を考えてみましょう。
そして、CSSフレームワーク内に同じようなコンポーネントがないか探してみましょう。

CSSフレームワークはより多くの人に使いやすいように設計されているものなので、そこで使われている名前を付けることで他の人が見たときにもわかりやすい名前になることが多いです。

BootStrapでは、画面端にナビゲーションと検索ボックスが存在します。
ここに探したいキーワードを入力してみます。例えば「ボタン」を作りたい場合...
スクリーンショット (28).png

butまで打つだけで候補が出てきますね！出された候補をぽちっと押してみましょう。
表示されるButtonsページでExamplesの一番上に出てくるものがこのコンポーネントの基本となります。

迷ったときは、このクラス名を参考にしてみてください。

ちなみにFoundationは同じような検索ボックスがありますが、BULMAはありません。
検索ボックスがないからと焦らず画面端のナビゲーションを開いてみてください。ElementsやComponentsの中にお探しのコンポーネントが見つかるかもしれません。
BULMA_button.png

注意
調べて出てきたからそのまま名前を使う、だとよくないなと思う面もあります。
例えばボタンでもBootStrapだとbtnという略称が使われていますが、BULMAやFoundationだとbuttonという省略しない名称が使われています。これはコンポーネントごとにバラバラ...ではなくこのフレームワーク内で共通のルールがあるということ。色々なサイトを参考にバラバラにクラス名をつけていくと、自分の書くコード内のルールが統一されなくなってしまう可能性があるわけです。

自分のコード内でルールが統一できているか？も振り返りつつ、フレームワークを参考にしていきましょう。
(略称を使うか使わないか問題は、基本的には略称を使わない方が初めて見た人にも伝わりやすく親切です。)

STEP2．作ったクラスに変化をつけたいクラスにバリエーションをつけるときの名称に迷う

色を変える。サイズを変える。など、変化をつけたい場合の名称はどうすればよいのでしょう？
基本的にはバリエーションクラスと呼ばれるクラスを追加してこのような変化をつけていきます。

CSSフレームワークのドキュメントでは、コンポーネントの基本形の後にバリエーションの例が載っています。

buttonコンポーネントを参考に見ていきましょう。

BootStrap
//基本のクラス名
btn 
//色のバリエーションクラス
btn-primary, btn-secondary, btn-success, btn-danger, ...
//サイズのバリエーションクラス
btn-lg, btn-sm
//状態のバリエーションクラス
active, disabled
BULMA
//基本のクラス名
button 
//色のバリエーションクラス
is-primary, is-secondary, is-success, is-danger, ...
//サイズのバリエーションクラス
is-learge, is-medium, is-normal, is-small
//状態のバリエーションクラス
is-active, is-hovered,...
Foundation
//基本のクラス名
button 
//色のバリエーションクラス
primary, secondary, success, alert, ...
//サイズのバリエーションクラス
large, small, tiny, ...
//状態のバリエーションクラス
disabled

BootStrapは、btn-XXという形でバリエーションクラスを記述しているようです。
ただし状態を表すときはactive, disabledのように状態名のみを記述していますね。

BULMAでは、色・サイズ・状態のどのバリエーションでもis-XXという形でバリエーションクラスを記述しています。

Foundationは上2つと異なり、-で文字をつながず1単語でバリエーションクラスが作られています。

どれが正解ということはありませんが、フレームワークごとにルールが違うのでコンポーネントごとにルールを混ぜないよう注意が必要です。

（BootStrapはbtnだけでなくサイズもlg, smと省略しているところを見ると、フレームワーク全体として略称を積極的に使っていくルールがありそうですね。）

STEP3．構造が複雑なときのクラス名の付け方がわからない

要素が組み合わさったコンポーネントの名前の付け方がわからない場合は、クラス名に構造を持たせるとよいでしょう。

さっそくですが、cardというコンポーネントを参考に見ていきましょう。
各フレームワークのcardの構造を簡単に並べてみました。
【BootStrap】
BootStrap_card_only2.png

BootStrap
<div class="card">
  <img class="card-img-top">
  <div class="card-body">
    <h5 class="card-title"></h5>
    <p class="card-text"></p>
  </div>
</div>

【BULMA】
BULMA_card_only2.png

BULMA
<div class="card">
  <div class="card-image"></div>
  <div class="card-content">
    <div class="media"></div>
    <div class="content"></div>
  </div>
</div>

【Foundation】
Foundation_card_only2.png

Foundation
<div class="card">
  <div class="card-divider"></div>
  <img>
  <div class="card-section">
    <h4></h4>
    <p></p>
  </div>
</div>

各コンポーネント共にcardという親クラスの中にcard-bodyやcard-contentなどのcard-XXの形のクラスがあるのがわかると思います。これをサブコンポーネントとも呼びます。

cardの中の要素をすべて並列にするのでなく、card-contentなどで役割を分けた中にさらに細かい要素（タイトル、テキスト、画像や他のコンポーネントなど）を入れることで、構造を分かりやすくしているのです。

おわりに

フロントエンドに触れ始めた当初、私自身がクラス名の付け方全く分からん...と思っていたので、CSSフレームワークを参考にするという手があるんだよ（ただし、ルールを統一して使いましょう。）という記事を書いてみました。

考え方の根本みたいな部分には触れられていない(説明できなかった...)ので後々調べていただきたいところですが、はじめの一歩か何かの参考になると嬉しいです！

ここまで読んでいただきありがとうございました！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T05:02:10+09:00

初心者によるプログラミング学習ログ 243日目

100日チャレンジの243日目

twitterの100日チャレンジ#タグ、#100DaysOfCode実施中です。
すでに100日超えましたが、継続。
100日チャレンジは、ぱぺまぺの中ではプログラミングに限らず継続学習のために使っています。
243日目は、

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧