What's New Qiita

20200317のHTMLに関する記事は8件です。

  • 投稿日：2020-03-17T19:29:35+09:00

HTML/CSSの基礎知識

HTML/CSSについて

1.HTMLとは
・ハイパーテキスト・マークアップ・ランゲージ（ HyperText Markup Language）の略。
・ウェブページを作成する為の言語。
・ハイパーテキストに目印をつける言語。

①ハイパーテキストとは？
・ハイパーリンクを埋め込むことができる高性能なテキスト。

②ハイパーリンクとは？
ウェブページで下線の付いたテキストなどをクリックすると別のリンクへ移動するリンクのこと。

③マークアップとは？
・文書の各部分がどのような役割を持っているか分かるように示すこと。
（各部分→elementと呼ぶ。）

<メリット>
・マークアップにより、その部分がどのような役割なのかを明確にすることで、コンピューターがその文書構造を理解できるようになる。

2.CSSとは？　
・カスケーティング・スタイル・シートの略。
・ウェブページのスタイルを指定する為の言語でHTMLと組み合わせて使用する。
・スクリーンに表示される際の色、サイズ、レイアウトなどの表示、プリンタで印刷される際の出力スタイル、音声で読みあげられる際の再生スタイルなど、どのようなスタイルで表示、出力、再生するかについて指定することができる。

①スタイルシートとは？
・文書のスタイルを指定する技術全般のこと。

②スタイルシートが必要な理由は？
・HTMLでもCSSのようにウェブページをスタイリングできないことはないが、それだと文書構造がでたらめになってしまう。
・HTMLの要素をどのように表示するかはブラウザによって異なるので、HTMLタグを駆使してある閲覧環境では綺麗にレイアウトされたとしても、他の閲覧環境では全く意図しないレイアウトになってしまうことがある。

<メリット>
・文書の構築とスタイルを分離して管理できるようになる。
・文書の構造に影響を与えずにスタイルを制御できるようになる。
・スタイル指定のせいで文書構造が分からなくなることがなくなる。
・スタイルを一括管理できる。
・複数の文書でスタイルを共有できる為、メンテナンス性が向上する。
・検索エンジンに正しく解釈されるウェブページになる。
・文書から余分なマークアップを排除して、スタイルに関する記述を一箇所にまとめる事でウェブページを軽量化できる。
・様々なメディアごとに適用するスタイルを指定し分けることができる。
・将来的に特定のメディアに依存することなく、それぞれのメディアに合ったスタイルでウェブページを表示、再生、出力させることができる。

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

HTMLのリアルタイムプレビュー環境を雑に整える

はじめに

HTMLファイルを書くとき、以前は一回一回VSCodeをターミナルで起動し、ファイルを編集してからChromeで確認するという面倒な方法を取っていました。しかも、普段はVimを使ってるのでVSCodeを使う機会はそうありません。しかし先日、N予備校のプログラミング学習コースが無料で提供されているということで、Webを一回しっかりと触ってみたいと思うようになりました。そういうわけで、快適にHTMLファイルのブラウザ表示の確認をするためにVSCodeの設定をしたいと思います。

HTML Previewのインストール

といっても、やることは至極簡単です。VSCode左側のScreenshot from 2020-03-17 16-16-14.pngマークを選択して、「html preview」と検索すれば簡単にVSCodeの拡張機能がヒットします
Screenshot from 2020-03-17 16-19-10.png
Installをクリックです
Screenshot from 2020-03-17 16-20-27.png
This extension is enabled globally「この拡張機能はグローバルに使用可能です」と表示されましたので、早速使ってみましょう！Screenshot from 2020-03-17 16-42-29.png

VSCode内でHTMLファイルを選択します。

この状態でctrlを押しながらk、その後ctrlとkを離して単体でvを叩きます。

gif.gif

ブラウザ表示できました！画面は「うまれた歳からの秒数を表示するページ」です。このHTML Previewですが、JavaScriptで付けた動きも表示してくれるみたいですね！（Texファイルなどにも対応しているPreview拡張を入れても、JavaScriptの動作を確認できませんでした。）Webページを作る時にかなり効く機能ではないでしょうか。

※僕、レポート類全部Texファイルで書いてGit管理したいと考えているんですが、Tex対応してる拡張の方を入れてもHTML Previewはちゃんと動きました。複数刀流が良さげですね。

参考

Visual Studio Codeでhtmlコーディングはリアルタイムプレビューがすごく良い
https://rui-log.com/vscode-html-cording/#VScodeMarkdown

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

GoogleDriveにアップロードした画像から、外部参照可能なURLを生成しimgタグ化するコードを書いてみた

概要

Codepenを最近よく使うようになって、画像使いたいなーでも有料会員になるほどでもないなーって思って、
コードペン上で画像を扱う方法をググってみたら、ゆんつ様の下記記事に遭遇！

▼こんぷれ / ゆんつ様
CodePenの無料会員で画像を使うには
※詳細はゆんつ様の記事をご参照ください！

要約すると、GoogleDriveやDropBoxにアップロードされた画像から共有リンクを生成し、
共有リンクの一部を書き換えて画像参照できるようにするといった内容です。

この記事はゆんつ様の記事を参考に、JavaScriptを使って、
GoogleDriveにアップロードした画像リンクを1回の作業で終わるようコードを書いてみたという話です。

作ろうと思ったきっかけ

私はGoogleDriveでアイコンや画像とかをまとめてるので、
GoogleDirveでの手順を参照して、さっそくやってみたわけですが

使ってみたい画像の共有を押して、
共有リンクコピーして、
imgタグのsrcに貼り付けて、
URL書き換えて…
…以下画像分繰り返し…

だあああああああめんどくさい！
想像以上にめんどくさい！

10分ほど気の遠くなるちまい作業を続けながら、考えました。
このめんどくさい作業を一回で終わらせたいと…
↓
考えた結果
画像はアップロードした時点で固有IDが与えられるなら、
フォルダ内のアイコン、画像の分だけ繰り返し処理でURLを加工してimgタグ化してしまえば、
この作業しなくて済むんでは？と、思いついたわけですね

出来上がったコード

ソース
// removeSize関数：url の末尾に指定されている画像サイズを取り除く処理
const removeSize = (url) => {
        if (url.match('=w300-k-iv165')) {
            return url.repalce('=w300-k-iv165', '');
        } 
        else if (url.match('=w300-k-iv1')) {
            return url.replace('=w300-k-iv1', '');
        }
        else if (url.match('=w300-k-iv5')) {
            return url.replace('=w300-k-iv5', '');
        }
        else if (url.match('=w300-k-iv2')) {
            return url.replace('=w300-k-iv2', '');
        }
        else if (url.match('=w300-k-iv3')) {
            return url.replace('=w300-k-iv3', '');
        }
        else if (url.match('=w200-h190-p-k-nu-iv1')) {
            return url.replace('=w200-h190-p-k-nu-iv1', '');
        }
        else if (url.match('=w200-h190-p-k-nu-iv165')) {
            return url.replace('=w200-h190-p-k-nu-iv165', '');
        }
}

// フォルダ内の画像を全て取得
let picture = document.getElementsByClassName('l-u-Ab-zb-Ua');

// 取得した画像の数だけ、加工処理を繰り返す
for (let i = 0; i < picture.length; i++ ) {

　　// 画像の名前を取得して変数labelに代入
    const label = picture[i].closest('.jGNTYb').getAttribute('aria-label'); // ※1

　　//  取得した画像のimgタグからsrcを取得し、取得したソースの一部を外部参照URLのフォーマットに置き換える処理  
　　const url = picture[i].getAttribute('src').replace('https://lh3.google.com/u/0/d/', 'https://drive.google.com/uc?export=view&id=');

　　//　removeSizeでURL末尾のサイズ指定を取り除いたURLを取得し、imgタグのsrcにぶち込んだものをconsoleに出力
    console.log(`${label}\n<img src="${removeSize(url)}" alt="">`);
}

Image from Gyazo

使い方

1.基本的には、GoogleDriveで適当なフォルダを作成します。

2.フォルダにアイコンや画像をアップロードします。

3.Chromeデベロッパーツール（F12 / Ctrl + Shift + I）を起動して、consoleタブから、上記コードをペーストし実行します。

4.出力されたimgタグをテキストファイルなどにコピペします。

あとは、使いたい時に生成したimgタグをそのままコピペして貼るだけで、使えます。
もしも画像を追加した場合は、再生成する必要がありますが、手作業でURLを加工するよりが楽かなと思います！

注意

フォルダを作らずに、マイドライブ上で上記コードを実行すると、
変数labelのgetAttributeがnullだよ！と怒られます。

これは、フォルダ内とマイドライブ上で祖先要素のclassが異なるため、指定したclassを持つ祖先要素が見つからずに発生するエラーです。
マイドライブ上で使いたい！という方は、変数labelのclosest('.Ccie2c')とする事で、リンクを生成する事が出来ます。

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

高輪ゲートウェイでズンドコキヨシ！

2020年3月14日

半世紀ぶりに山手線に新駅開業！

おめでとうございます。

というわけで、本題に入ります。

何をするの？

今回は...

「Javascriptでズンドコキヨシみたいな高輪ゲートウェイを作成！」

です！

この時点では意味がわからないと思います。

では、実際の画像です。

image.png

こんな感じで、「高輪」「ゲート」「ウェイ」がランダムに配列から取り出されて、

高輪ゲートウェイが出たら成功！みたいなゲームです！

完全にズンドコキヨシですね！

では、ソースコードです

ソースコード

index.html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>高輪ゲートウェイ</title>
    <link rel="stylesheet" href="style.css">
    </style>
</head>
<body>
    <div class="takanawa">
        <p id="text"></p>
    </div>
    <script type="text/javascript" src="script.js"></script>
</body>
</html>
style.css
body{
    font-family:serif;
    background-color:#dddddd;
    color:#ffffff;
    margin:0;

}
.takanawa {
    position: relative;
    height: 40vh;
    background-color: #008000;
    text-align:center;
    font-size:20vh;
}
.takanawa p {
    width: 100%;
    text-align: center;
}
script.js
        const takanawa=["高輪","ゲート","ウェイ"] ///ズンドコ風配列
        for(let i=1;i<4;i++){
            let random = Math.floor( Math.random() * takanawa.length );///ランダム
            document.getElementById("text").innerHTML+=takanawa[random]///innerHTMLで挿入
        }

工夫した点

  • 実際のフォント（明朝体）に似せた
  • 色合いも似せた
  • ゲームとして成立させた
  • オリジナリティ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-17T12:50:08+09:00

高輪ゲートウェイでズンドコキヨシを作ってみよう！

2020年3月14日

半世紀ぶりに山手線に新駅開業！

おめでとうございます。

というわけで、本題に入ります。

何をするの？

今回は...

「Javascriptでズンドコキヨシみたいな高輪ゲートウェイを作成！」

です！

この時点では意味がわからないと思います。

では、実際の画像です。

image.png

こんな感じで、「高輪」「ゲート」「ウェイ」がランダムに配列から取り出されて、

高輪ゲートウェイが出たら成功！みたいなゲームです！

完全にズンドコキヨシですね！

実際にプレイしたい方はこちら

では、ソースコードです

ソースコード

index.html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>高輪ゲートウェイ</title>
    <link rel="stylesheet" href="style.css">
    </style>
</head>
<body>
    <div class="takanawa">
        <p id="text"></p>
    </div>
    <script type="text/javascript" src="script.js"></script>
</body>
</html>
style.css
body{
    font-family:serif;
    background-color:#dddddd;
    color:#ffffff;
    margin:0;

}
.takanawa {
    position: relative;
    height: 40vh;
    background-color: #008000;
    text-align:center;
    font-size:20vh;
}
.takanawa p {
    width: 100%;
    text-align: center;
}
script.js
        const takanawa=["高輪","ゲート","ウェイ"] ///ズンドコ風配列
        for(let i=0;i<3;i++){
            let random = Math.floor( Math.random() * takanawa.length );///ランダム
            document.getElementById("text").innerHTML+=takanawa[random]///innerHTMLで挿入
        }

工夫した点

  • 実際のフォント（明朝体）に似せた
  • 色合いも似せた
  • ゲームとして成立させた
  • オリジナリティ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-17T05:42:27+09:00

CSS設計・Sassディレクトリ管理の標準化（CROCSS）

はじめに

HTML+CSSコーディングにおいて、Sass管理ディレクトリを標準化する方法を紹介します。
CSS設計は、サイト種別やプロジェクト規模、分業の有無や人数によっても最適解が異なります。
この仕組みは、様々な設計を同じロジックで受け入れることによって、CSSコードの管理効率を画一的に最大化する狙いのものです。
コーポレート・ポータル・ブログ・EC・LP・管理画面…など、様々な種別のサイトのCSSを、同じ仕組みで設計して管理できるようになります。

前提事項など

  • SassなどのCSSプリプロセッサの使用を前提とします。
  • 本記事の一部は、後で見られるよう別記事として切り出しています。（?のマークのもの）
  • この記事は標準化ノウハウ公開の一環として書いています。
    仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。

セクション一覧

  1. 全体の把握
  2. 仕組みの概要
  3. CROCSSの標準分類
  4. 物理化と実例
  5. 実用にあたって
  6. 使用感や設計・実例
  7. その他・考え方など
  8. さいごに

1・ 全体の把握

まずは全体像の説明です。
今回の仕組み（CROCSS / クロックス）は、過去に公開したHCDCモデルとHTML Partsを実務利用するための具体的なノウハウとなります。HCDCモデルとHTML Partsは、以下の図のように制作行動の "要所" において、設計の在り方を示すガイドとして働きます。

コーディング全体の流れと対応する手法
そして今回紹介するCROCSSは、これらの概念をSassファイルの管理ディレクトリに変換し、概念と実務をスムーズに連動させる役割を担います。

過去記事は先にお読み頂いても良いですし、この記事からのリンクで局所的にお読み頂いても問題ありません。
もっと詳しく全体を把握したい場合は、記事内の「よりよい把握のための図解」や「著名な設計手法10個との概念比較」をご覧ください。

過去の記事

直接関連するもの

論拠や背景

2・ 仕組みの概要

基本ロジック

この仕組みの基幹にあるのは「分類の乗算」です。
以下のように2つの分類を掛け合わせることで、Sassディレクトリの主たる構造をつくります。分類-1,2は、CROCSS標準のものがあります。この記事ではそれらを中心に説明します。
基本ロジック図解
また、このロジックは思考の幅を広げ、構造の幹をつくるためのものです。隅々にまで適用しなければならないような「強制力」はありません。設計の枝葉の部分においては管理効率を最優先してください。

物理化メソッド

つぎに、実際にSassディレクトリを構築するまでの流れを図説します。
以下は、前述の「基本ロジック」にCROCSSの標準分類をセットして全体の流れを把握しやすくしたものです。
分類-1には、制作者が自然と判断できる分類を使い、分類-2には、HCDCモデルのデータ分類を使います。
Sassファイルを作成するまでのステップ
そして、分類-1の中に分類-2を平等に設置することで概念上の「型枠」をつくり、その中から必要なものを物理化（ディレクトリ化）します。
サイト種別ごとのガイドや、ディレクトリ構造の実例、使用感は後のセクションにて記載します。

このアプローチにより、以下の3つの効果・特徴を得ます。
※リストをクリック or タップで展開できます


1 ・ 拡張しやすさの確保
この物量を見ると、反射的に「こんなに沢山のディレクトリは制御しきれない」とか、「もっと少ない方がよいに決まっている」と感じるかもしれません。
しかし、人は物量や階層の深さによって混乱するのではありません。人が混乱するのは「情報の捻れ」や「曖昧さ」「不整合」などが発生している時です。
　
最終的に物理化するものは絞られます。最大枠を概念側に置いておく事で、役割が欲しくなった時にすぐに拡張できるようにしておきます。


2 ・ カスタマイズ性
2種類の分類は、中身を変えることで設計を大きく変更・拡張できます。
例えば図中の「分類-1」を、FLOCSSの第一階層に変更しても同じように乗算できます。
　
この場合、当然FLOCSSではなくなりますし、CROCSS標準でも無くなりますが、新たな設計を試せます。
また同様に、標準として定める全ての文言や役割は追加・変更・削除しても問題ありません。


3 ・ 雛形作成と設計切り替え
この仕組みは雛形化しやすくなっています。特定のサイト種別のために作ったディレクトリ構造でも、概念枠によっていつでも拡張・縮小して多種別対応できます。
　
毎回最初から同じような構成を作る必要はありません。雛形を作成し、ブラッシュアップしていけばそれだけで業務標準化・効率化になります。

対応範囲

記事作成時点での実務利用実績（実際に対応した種別）は以下の通りです。

コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト / ECサイト（オンラインショップ） / ランディングページ（LP） / イントラサイト

上記以外の実績はありませんが、おおよそいずれかに似た属性となるため問題なく使えるでしょう。

3・ CROCSSの標準分類

CROCSS標準の分類について説明します。
標準となるのは以下の2つです。

  • 【分類-1】：スコープ分類　…　4つの対象範囲による分類
  • 【分類-2】：データ分類　…　4つのデータ属性による分類

【分類-1】 スコープ分類

分類の1つ目は、多くの制作者にとってすぐに判断できるものを使います。
以下の2つの事柄によって、4つの項目を定義します。

  1. 一般的な制作ステップ
  2. ページ内での所属区域

1. は、「下地を整えてから枠組みをつくり、中にコンテンツを入れていき、各ページの固有の上書きをおこなう」といった、初期制作時における一般的な制作フローです。
2. は、対象が「ページの主たる情報」なのか「サイトの枠組み」に使うものなのか。といった判定で、制作者であれば恐らく誰もがすぐに特定できます。

この2つを組み合わせると、下地（Base）、共通の枠組み（Frame）、コンテンツ（Contents）、ページ（Pages）という4種になります。物理化した時に、それぞれのディレクトリ内部に格納したものは、その分類の役割が果たす範囲（スコープ）でしか使いません。

スコープ分類とレイヤーの図

また、これら4つのスコープは、概念によるレイヤー構造を持ちます。これらの関係は「下にあるものは上で使える」「上にあるものは下を上書きできる」というシンプルなものです。
このルールによってCSS管理に法則と秩序を与え、まずは大きな区分けでの影響分離をおこないます。

1・スコープ分類の詳細説明

詳細については長くなるため別記事に記載しています。
※まずは全容を把握したい場合には、後からご覧頂いても問題ありません。

? スコープ分類について

2・ディレクトリ化

スコープ分類による、最終的なディレクトリの構成は以下のようになります。

  • base/ 　…　サイトの下地・土台・基底
  • frame/ 　…　サイト全域で共通利用するような枠組み部分
  • contents/ 　…　ページの主たる情報や機能、入力操作のための領域
  • pages/ 　…　全てを包括する最も大きな概念

3・カスタマイズ

何かが足りない場合や、他の英単語の方が馴染みが良い場合は、自由に追加・変更してください。例えば、theme/やskin/、templates/などの追加、contents/をobject/にした方がプロジェクトに馴染む。といった事が考えられます。

【分類-2】 データ分類

分類の2つ目は、「HCDCモデル図」の4つのデータ分類を使用します。
HCDCモデル図
このうち、左半分（Block , Parts）は「HTML Parts」による粒度分類・定義をそのまま使います。右半分（Structure , Utility）はCROCSS側でガイドを定めます。

1・データ分類の詳細説明

詳細については長くなるため別記事に記載しています。
※まずは全容を把握したい場合には、後からご覧頂いても問題ありません。

? データ分類について

2・ディレクトリ

これらのデータ分類を全て展開すると、以下のような構造になります。

  • block/
    • ※下層は適宜設置
  • parts/ （HTML Partsにより粒度分類）
    • module/
    • component/
    • element/
  • structure/
    • ※下層は適宜設置
  • utility/
    • ※下層は適宜設置

この構造は、最終的に「分類-1」の4つのスコープ（Base・Frame・Contents・Pages）内部に平等に設置でき、実際に物理化して利用する時にはそれぞれのスコープにおいて統治します。

3・カスタマイズ

何かが足りない場合や、他の英単語の方が馴染みが良い場合は、自由に追加・変更してください。
例えばwidget/やvender/などの追加。小規模なサイトであればparts/が丸ごと不要。といったケースも考えられます。逆に、今回不要だったものが、次のプロジェクトでは必要になる。という事もあるでしょう。

4・ 物理化と実例

CROCSS標準の分類2つが把握できれば、あとは物理化するだけです。
方法は概要に記載した通り、まずは「スコープ分類」と「データ分類」の2つの概念を掛け合わせて「物理化のための型枠」を用意します。
物理化のための
作成した「型枠」は概念的なものであるため、一旦資料に残しておきます。テキストファイルやMarkDownでの箇条書き、Excelによる資料などで充分です。
何か問題があれば分類を見直し、常に概念と物理がスムーズに繋がるよう再設計します。

5・ 実用にあたって

部品（Sassファイル）の保存方法

Sassファイルには部品と同じ名前を与えます。
大抵の場合はHTML要素のclass属性の値で与えた名前になりますが、id属性によるスタイリングを許可する場合はidの値も対象になります。ファイルを作成する時は、全てのディレクトリを通して同一名のファイルは作成しないよう注意します。
Sassファイルを作成したら、対象に関連する部品や効果は、そのファイルの内で影響が収まるようにスタイリングします。

スタイリングは、グローバルに再利用する場合はスタイリングのパターンAになり、関連部品を自身の所属物とするなら、パターンBか、パターンCのどちらかになります。

プレフィックスやサフィックス

接頭辞（プレフィックス）や接尾辞（サフィックス）に関しては、制作レギュレーションや実務用のコーディングガイドなどで自由に定めて下さい。
Layoutに関しては「命名重複回避」を主たる理由として、l-などのプレフィックス付与することを推奨していますが、強制力を持つルールではありません。

ページの識別・特定方法の問題

部品主体のコーディングをおこなう場合は、常に「ページ識別」の問題がつきまといます。
ディレクトリ名やファイル名などを、識別子としてbodyのclassに記述すると判定しやすくなりますが、全て手動でテキスト入力するのは面倒です。
そこで、こういったclassを自動出力する「bodyclass.js」を同グループで作成しています。
現在のところjQuery依存ではありますが、必要に応じてご自由にお使い下さい。

6・ 使用感や設計・実例

コーディング時の使用感

実際にコーディングする時の使用感は以下のようなものになります。
※リストをクリック or タップで展開できます


ファイル管理
「スコープ分類×データ分類」によるディレクトリ構造は、いわば「部品の片付け先」をあらかじめ用意するようなものです。いざという時に引き出しがあればすぐに収納できますが、なければ引き出しを作るところからはじめなくてはなりません。
　
少し考えれば置き場所が見つかる・すぐに増やせる。そして、Sassファイルの置き場所で設計内容をある程度伝達・把握できるようになります。


CSS設計
CSS設計を柔軟に切り替えて使えます。部品は、グローバルに再利用するかどうかで別途部品化（＝新規Sassファイル化）するかが決まります。
　
命名や単語連結手法（いわゆる命名規則やBEMのような手法）は普段慣れたものを使えます。また、プロジェクトごとに最適なものに入れ替えて使用することも可能です。


マークアップとスタイリング
Structureをうまく使うと「弁当箱を間仕切りして具材を詰めるように」コーディングできます。
　
Block内部のホワイトスペースはStructure側で制御できるため、主要な情報の部品（Component等）に余計な余白や位置決め用のスタイルを与えることなく、それぞれの責任範囲を分離してコード管理できます。
また、レスポンシブの制御もキャンセルを多用しなくても済むようになるでしょう。


レギュレーション
業務を標準化するには、最終的にHTMLの書き方や、部品ごとのマークアップ方針・レギュレーションが必要になります。これについては、また別の機会に紹介します。


命名の雛形化
こういったSassディレクトリ構築の取り組みをおこなう中で、その現場やチームで使用する「概念の型枠」は最適化され、次第に独自の型が定まっていきます。
この時、よく使う部品に固定の命名を与えて雛形化しておくと、デザインの後入れ（Design Injection）によるコーディングがおこなえます。
　
このような考え方にご興味があれば、「DI-CODING」のページをご覧ください。（1枚物の簡単なページで、もう少しだけ詳しく説明しています）

サイト種別ごとの管理設計

サイトの種別ごとに、どのように管理できるのかの概要を記載します。
※リストをクリック or タップで展開できます


1 ・ 情報発信系サイト
多くの情報発信系サイトにおいて一般的な使い方は、BaseでHTML要素のデフォルトスタイルを整え、ContentsとFrameにてそれぞれの専用部品を管理。条件的な上書きをPagesで一元管理する。といったものです。
　
コーポレート系やブランディング系など、一般的な情報発信系サイトであればこの方式で対応できます。
小さい規模のサイトであれば、Blockの粒度のみでサイトが完成するでしょう。


2 ・ システム管理画面系サイト
システム管理画面などにおいて、サイト全域で小さな部品を再利用する場合はbase/にて部品を管理します。
これにより、Frame領域とContents領域とで同じ部品を利用できます。
CSSフレームワークやテーマなどの「既製部品」を利用する場合も同様です。もし、こういったものを使う場合は、vender/などで丸ごと一元管理すればよいでしょう。
　
逆に、Contents部分のみに「既製部品」を使いたい場合（Frameでは一切使わないと明示したい場合）は、contents/のvender/などで管理します。


3 ・ ECサイト
カタログタイプのECサイトの場合、多くの中規模部品を再利用する事になります。
例えば、カテゴリ別の商品一覧や、おすすめ商品、ランキングなど、同じものを異なるページで再利用することが多くなるでしょう。
この時、部分的な機能や表示の塊をmodule/粒度のものとして管理できます。


4 ・ ランディングページ
ランディングページ（LP）は、プロジェクトによってはFrameそのものが不要かもしれません。
この場合、全てをContentsとして作ることになるでしょう。将来的に顧客の要望によってページが追加されれば、最初は不要と思っていたFrameが必要になる（簡易なヘッダーとフッターを追加する）事もあり得ます。


5 ・ その他のサイト
その他のサイトは、上記のいずれかに近いか、折衷した管理になるでしょう。
スタイリングのアプローチは部品単位で切り替えられるため、より良い管理を模索できます。

ディレクトリ構成の実例

ディレクトリ構成の実例を紹介します。
以下は、コーポレート系のサイト制作を対象にしつつも、念のため他の種別にもすぐに対応・拡張できるように構成したディレクトリの例です。

ディレクトリ構成・第一階層

※リストをクリック or タップで展開できます


base/ の下層展開
成果物全域に関わるCSSを管理します。
vender/ ディレクトリを追加する事で、独自作成のものと外部のCSSを影響分離しています。
base/ の下層展開 ディレクトリ図


contents/ の下層展開
Contents領域のみで使うCSSを管理します。
block/の内部は、共通利用するものを_commonに収め、サイトのページ名やカテゴリ名でディレクトリを設置すると分業がおこないやすくなります。
contents/ の下層展開 ディレクトリ図


frame/ の下層展開
Frame領域のみで使うCSSを管理します。
Frameのblock/の内部は、部位や機能によってディレクトリを設置しておくと、何かあったときに拡張しやすくなります。
frame/ の下層展開 ディレクトリ図


pages/ の下層展開
コーポレート系サイトを想定した場合、Pagesのサブディレクトリは必要ないと判断し、単一階層でSassファイルを管理しています。
pages/ の下層展開 ディレクトリ図

上記は実務利用しているものと近く、実際には「DI-CODING」によってSassファイルの命名雛形も含めてスターターキット化しています。作る手間より削除する手間の方が楽であるため、雛形化するときには少し広げて作っておいたほうが後々楽に使えます。
目視でファイルを追いかける場合、平置きの大量のファイルをアルファベット順で探すより、格納場所が分かっている適量のディレクトリを下った方が遥かに楽に探せます。

これらにより、コーポレートを中心としながらも、どんな種別の案件でも対応できるようにしています。

7・ その他・考え方など

よりよい把握のための図解

「1 - 全体の把握」の図を再掲載した上で、仕組みについてもう少し詳しく図解します。
コーディング全体の流れと対応する手法

上記の詳細が以下の図です。これにより概念がどのように使われ、物理化されるのかが把握できます。
一見すると複雑に見えるかもしれませんが、1つづつは単純です。
仕組みの図解／実務と概念の流れ
青文字と矢印が「制作における行動」で、オレンジの文字と矢印が「概念の流れ」です。
制作の流れとしては(1)～(4)を繰り返しおこない、概念はそれをサポートする形で関与しています。

著名な設計手法10個との概念比較

この仕組みの定義と、著名な10種類のCSS設計や思想との比較・対応表です。
こうしてまとめてみると、それぞれ言い方が違うだけで、やりたい事の本質は似ていたのでは？という事が見てとれます。特に、ComponentとUtilityのあたりは顕著です。
逆を言えば、この度の一連の仕組みはこれらの特徴を併せ持っていると言えます。

概念比較表

各公式サイトへのリンク

SMACSS / OOCSS / BEM / MCSS / RSCSS / ECSS / ITCSS / FLOCSS / PRECSS / Atomic Design

手法とレギュレーションの考え方

現場で制作者が準拠すべきものは、現場ごとに定められたルールやレギュレーション、ガイドライン(図の3)です。これがその制作現場における最高位の権限と強制力を持つと考えます。

概念や手法の実用ステップ図
(1)は、その環境における「特効薬」をつくるための参考資料・材料であり、制作者が「これを使う」「この仕組みに準拠する」と定めて初めて、効力を発揮します。これは、ひとりであってもチームであっても「業務の標準化」を目指すのであれば変わりません。

この仕組みも(1)に該当し、その他多くのCSS設計と同じく「誰かがその人の環境を最適化するために作ったもの」です。取扱業務も、商圏も、組織規模も異なる現場や環境において、全く同じ仕組みがそのままの状態でベストマッチすると捉える方が不自然です。

各所で自由に変更してもよい。と記載しているのは、こういった考え方のためです。そのまま使える方が効率的ではありますが、現場のルールを決定するのは制作者（設計者）です。
決して(1)を(3)と捉えないよう、また、"ねばならないの思考"にはまらないようご注意ください。

8・ さいごに

これまで「HTML+CSSコーディングの言語化」からはじまり、「HCDCモデル図」からなる一連の情報を公開してきました。今回で概念をどのように実務利用するのかをお伝えできたのではないかと思います。

この仕組みは、著名なCSS設計手法では業務が標準化できなかったために独自で構築したものです。
当時の環境は、取り扱うサイト種別が、企業サイトやブランディングサイト、EC、ポータル、LP、サービスサイト、ブログ、管理画面（システム開発も含む）…、という幅広い範囲であったにも関わらず、コーディングルールもなく、過去のサイトに手を入れる場合は一苦労でした。

このような多くの種別の制作方法を統一したくても、当時著名だった手法ではCSSは溢れかえり、何かに寄せればどれかの種別で設計破綻する。といった状況でした。
こういった環境の中で、全てに通用するコーディングの本質は無いものかと求め続け、案件で叩き上げたのが今回の仕組みになります。

合う、合わないは必ずありますし、本当に使いやすい「特効薬」は現場ごとに作ることになりますが、その時のレシピや材料・参考資料になれば幸いです。

今後の情報公開

あと2つの手法の公開が残っていますが、これらは「命名規則」に関する話になります。
HCDCモデル図を実務利用するための4つの標準化手法
しかし、実はもうこの段階で実用できます。
命名に関する標準化は、一連の仕組みとは疎結合の関係にあるためです。どのような単語と連結記法を使おうと、仕組みの本質が変容することはありません。
もし今現在でCSSが氾濫する。設計手法の解釈が人によって違って困っている。といった悩みをお抱えの場合は、是非お試し下さい。

※単語連結手法については、もしご興味があれば、先行してREMMのサイト（http://remm.work/）をご覧ください。BEMの亜流・改良版で、この仕組みの利点を生かしやすくなっています。

次の記事を公開次第、以下の関連記事にリンクを追加します。

関連記事

詳細記事

クレジット・その他

Ultimate Coding
概要・前提事項

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

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

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

100日チャレンジの264日目

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

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

【ajax】JqueryでJSONを一件ずつ取得する【なるほど】

入れ子になっているjsonを一件ずつ取り出すのに苦労したのでまとめてみました。

入れ子になっているjson

ajaxでjsonを取得すると、多分こういう形になってる

{ 
  "lists": [
        {
            "text": "aaa",
            "name": "a",
            "created_at": "2020-03-16 09:02"
        },
        {
            "text": "bbb",
            "name": "b",
            "created_at": "2020-03-16 09:06"
        },
        {
            "text": "ccc",
            "name": "c",
            "created_at": "2020-03-16 09:06"
        }
    ]
}

これを一件ずつ取り出す

$(function(){
            $.ajax({
                url: 'http://localhost',
                type:'GET',
            }).done(function(data){
                    for(var i in data['lists']){
                        //textをひとずつ出力
                        console.log(data['lists'][n].text);
                        console.log(data['lists'][n].name);
                        console.log(data['lists'][n].created_at);
                    }
               });
            });

data['lists'][n].textここの部分すごく苦労した、、、

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

日付別

タグ一覧