Author Archives: ake_nyanko

【HTML5.1勧告】セクション要素内見出しレベル仕様の変更について

html5.1

2016年11月1日付でW3CがHTML5.1を勧告しました。
HTML5からの変更差分はこちらにまとめられていますので、詳細はこちらを見ていただくとして、
今回はその中で「removed」つまり削除された仕様の一覧の中にあった次の項目に注目したいと思います。

・The use of nested section elements each with an h1 to create an outline.
(・アウトラインを生成するためにそれぞれh1を持つネストされたセクションを使用すること)

HTML5でのアウトラインと見出しのルール

2014年勧告のHTML5では、「セクショニング・コンテンツの入れ子によって正しく階層構造がマークアップされている場合、その中で使用される見出しレベルは問わない」という仕様がありました。
このことはHTML4.01からHTML5になったときの大きな仕様変更のひとつであり、HTML5が登場した初期には盛んに紹介された項目であったため、ご存知の方も多いかと思います。
W3CのHTML5仕様では以下の2つのマークアップはいずれも同じアウトラインを生成するとして事例紹介されています。

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Color</h2>
  <p>Apples come in various colors.</p>
 </section>
</body>

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h1>Taste</h1>
  <p>They taste lovely.</p>
  <section>
   <h1>Sweet</h1>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>
</body>

HTML5.1でのアウトラインと見出しレベルのルール

ところが、HTML5.1では上記のうち「各セクションの見出しレベルを全てh1にする」事例が削除され、

Authors should use headings of the appropriate rank for the section’s nesting level.
(著者は、セクションのネストレベルに応じて適切なランクの見出しを使用する必要があります。)

◎出典:https://www.w3.org/TR/2016/REC-html51-20161101/sections.html#headings-and-sections

との記載がなされています。
著者は、セクションのネストレベルに応じて適切なランクの見出しを使用する必要があります。
つまり、HTML5.1の仕様ではセクショニング・コンテンツによって正しく情報構造をマークアップしていても、それだけで正しくアウトラインを生成することはないということになります。
文書のアウトライン=情報の階層構造はあくまで見出しレベルによって判定される以前の仕様に戻ったという風に解釈して良いと思われます。

仕様変更によって何か影響はあるのか?

この仕様変更によって何か実務的に影響はあるのか? という点ですが、
実質的には特に何もないと思われます。
理由は、そもそもネストされたセクション要素の見出しを全てh1にしてマークアップしているケースはほとんど無いと思われるからです。

仮に全てのセクションの見出しをh1にしてしまっていたとしても、それで「今まで正しくアウトライン判定されていたものが急に判定されなくなる」ということはありません。
なぜなら今までもそのマークアップでは正しくアウトライン判定されていなかったはずだからです。

今回削除されたアウトライン判定の仕様は、当初から「at risk(今後削除される可能性がある仕様)」扱いであり、W3C仕様でも「スクリーンリーダー等の支援技術やブラウザでこの仕様をサポートしている環境はまだ無い」と注意を促していました。
そして仕様としては残しながらも「制作者は正しくアウトラインを伝える必要がある場合、セクションのネストレベルに応じた見出しレベルを使用することを推奨」していました。

もともと仕様だけはあったけれども実質的には機能していなかったものを、今回正式に削除しただけのものであるので、仕様変更に伴う実質的な影響は「何もない」ということになります。

ではセクションを入れ子にして階層構造をマークアップすることは意味が無いのか?

アウトラインが見出しレベルによってのみ判断されるということであれば、「セクション要素なんか使わなくても良いのではないか?」と思う方もおられるかと思います。
個人的には、「使っても使わなくても結果は全く同じ」なのであれば別に好きにすればいいと思います。
ただ、見出しレベルによる暗黙のアウトラインはあくまで「見出しから次の見出しまでをひとつのセクションとしてみなす」というものであるため、確実に意図した範囲がひとつのセクションとしてみなされているとは限りません。

例えば次のようなケース。

<body>
  <h1>第一階層の見出し</h1>
  <p>(1)hogehogehoge</p>
  <h2>第二階層の見出し</h2>
  <p>(2)hagehagehage</p>
  <p>(3)fugafugafuga</p>
</body>

この場合、①は第一階層に所属、②と③は第二階層に所属するコンテンツであると自動的に認識され、それ以外の解釈はありえません。
しかしセクション要素によって各見出しに所属するセクションの範囲を明示して次のようにマークアップすれば、

<body>
  <h1>第一階層の見出し</h1>
  <p>(1)hogehogehoge</p>
  <section>
    <h2>第二階層の見出し</h2>
    <p>(2)hagehagehage</p>
  </section>
  <p>(3)fugafugafuga</p>
</body>

③のコンテンツは第一階層に所属するコンテンツであることを明確に表現することができるのです。
ひとつのセクションに含まれるコンテンツの範囲を明確に定義できるのはやはりセクション要素であるので、セクション要素によって各セクションの範囲と階層を正しくマークアップした上で、各階層の見出しレベルはセクションのネストレベルに応じて適切に設定するというのがやはり理想的なマークアップであると思います。

Node.jsインストール攻略法【非エンジニア向け】

node

先日、遅ればせながらNode.jsをインストールすることにしました。
一番の理由は、タスクランナーのgulpを使いたいから。
「gulpとはなんぞや?」とかいう話は別のブログを参照してもらうとして、
これを使うにはまず何はなくともNode.jsが必要だということで、どうやってインストールするのかグーグル先生にお伺いしてみました。すると、出るわ出るわ。情報の嵐。
さすが昨今のWeb制作でもはや必須と言われるNode.js。いろんな人がいろんな方法を紹介してくれており、基本的に情報には事欠きません。

が、実に様々な方法の情報が入り乱れており、黒い画面系の知識も乏しいエンジニアでもない者がいざやろうと思うと逆に混乱し、トラップにハマりやすい状況にあります。
かくいう私も目についたものから適当に手を出してやってしまったため、結果的に何度もインストール/アンインストールしなおす羽目になり、その過程で何度も「ヽ(`Д´#)ノ ムキー!!」となるトラブルに見舞われましたので、後学のWebデザイナーさん達のためにNode.jsインストールの攻略法をまとめておきます。

今どきのWeb制作者はやっぱりMacだよね、という風潮があるので以下全てMac環境を前提としております。あしからず。

Nodeをインストールするには複数の方法がある。

まず、Node.jsをインストールする方法としては大体おおまかに次の4つの方法があると思ってください。

  1. 公式インストーラからインストール
  2. パッケージ管理ツールでインストール
  3. Nodeバージョン管理ツールでインストール
  4. パッケージ管理→バージョン管理ツール経由でインストール

どの方法でもインストール自体はできるのですが、
その後の管理等で使い勝手が変わってくるため、自分の目的と照らしあわせて最初からインストール方法を選んでおいたほうがよいと思います。以下、それぞれの方法の特長とそのメリット・デメリットを簡単にまとめます。
(※なお、各ツールの具体的な導入方法は参考サイトの方を参照してください)

1.公式インストーラ

◎Node.js公式(https://nodejs.org/
installer

GUIで操作できる唯一のインストール方法です。
通常のアプリケーションと同様、ダウンロード→ダブルクリック→OK連打のコンボであっという間にインストールは完了します。簡単・便利・楽ちん!
ただし、公式にはインストーラーは用意されていますが何故かアンインストーラーは用意されていないため、この方法でインストールしたNode.jsを関連ファイルも含めてキレイに削除するためには黒い画面を駆使する必要がでてきます。「私黒い画面とか分かんないし〜。インストーラーあるならポチればいいじゃん〜」的な感じで安易に使うと後で痛い目見ます。

【メリット】

  • とにかく簡単
  • インストールするだけなら黒い画面の知識不要!

<参考>「5分で終了。node.jsの環境構築が拍子抜けするほど簡単だったのでサンプルプログラム付きでまとめてみました【Mac編】」

【デメリット】

  • アンインストールが激しく面倒くさい
  • バージョン変えたくなった時に黒い画面使えないと軽く死ねる

<参考>「Mac OS X から Node.js をアンインストールする方法」

【おすすめタイプ】

  • とにかくできるだけターミナルとか使いたくない。
  • インストールしたらバージョンアップとかしない主義。
  • アンインストールする時のことなんか知らん。今さえよければそれで。

2.パッケージ管理ツールでインストール

「homebrew」というOS X 定番の「パッケージ管理ツール」経由で直接Node.jsをインストールする方法です。
◎homebrew(http://brew.sh/index_ja.html
homebrew

「パッケージ管理ツール」とは、Nodeに限らずUNIXの世界で流通する様々な言語やソフトウェアのインストール・更新情報を簡単に集中管理できるようにするためのツールです。イメージ的にはApp StoreのUNIX無料版みたいな感じでしょうか(※あくまでイメージです)。パッケージ管理ツール自体は複数あるのですが、Macの場合は「homebrew」というものが定番で、エンジニア初心者向けの解説書などを見ると、一番最初の開発環境構築のところで「とりあえずhomebrew入れろ。話はそれからだ。」と言われて問答無用で入れさせられるものになります。
まずは先にhomebrewをインストールし、homebrewを通してNode.jsをインストールする、という2段構えの作業となります。
homebrewさえインストールされていれば、nodeのインストールは以下の1行で終了です。

$ brew install node

ただ、ここで非エンジニアが初めてhomebrewを導入しようとした時、少々問題が発生します。
単純にhomebrew公式サイトに行って、インストール用のコマンドをコピペしただけではおそらくhomebrewは動かないのです。理由は、homebrewを動かすための前提条件があるから。

homebrewからNode.jsをインストールしたい、という場合、
非エンジニアなどが初めて挑戦する際には

1.Javaのインストール
2.Command Line Toolsのインストール
3.Homebrew 本体のインストール
4.Node.jsのインストール

というステップを順に経て、やっと目的を達成できるという状態になるので頑張ってください。
<参考>「パッケージ管理システム Homebrew

【メリット】

  • Nodeのインストール、アンインストール、アップデート、いずれも簡単なコマンドでサクッと処理できる。
  • 特に削除する時などは $brew uninstall node とするだけで関連ファイルも含めてサクッと消してくれる。楽過ぎる。

【デメリット】

  • homebrew自体を使えるようにするための事前の環境構築が激しく面倒くさい。(下手するとここで詰む)
  • 同時にインストールできるNodeは1バージョンのみ。複数バージョンの管理はできない。

【おすすめタイプ】

  • 今後のために定番のフロントエンド開発環境を整えたい。Nodeのインストールはその一環。
  • 複数バージョンのNodeを用意しておく必要はない。

3. Nodeバージョン管理ツールでインストール

homebrewを経由せず、Node専用のバージョン管理ツールからNode.jsをインストールする方法です。
Node専用のバージョン管理ツールを使うと、バージョン違いのNodeを複数インストールし、必要に応じて使用するバージョンを簡単に切り替えたりすることができるようになります。
特にNode.jsを前提とした各種開発をしていると、特定バージョンのNodeでないと動かないツールが出てきたりすることもあるため、頻繁にバージョンの入れ替えをする必要がある人には必須のツールとなっています。
Node専用のバージョン管理ツールも複数ありますが、今一番旬なおすすめは「nodebrew」というものだそうですので、これを使う前提とします。
◎nodebrew(https://github.com/hokaccha/nodebrew
nodebrew

nodebrewはバージョン管理ツールなので、基本的にバージョンを指定してNodeをインストールする形となります。

$nodebrew install-binary <バージョン>

また、インストールしただけではまだ利用できず、「このバージョンを使うよ」という宣言も必要になります。

$nodebrew use <バージョン>

homebrewでのインストールよりちょっぴり面倒ですね。
でもプロジェクトごとに使うNodeのバージョンを切り替えたいのであればとても便利な仕組みです。

【メリット】

  • 複数バージョンのNodeを簡単に使い分けできる。
  • 使い方も比較的シンプルで分かりやすい

<参考>「node.jsのversionを管理するためにnodebrewを利用する」

【デメリット】

  • nodebrewの設定で「パスを通す」作業が必須。UNIXの基礎知識が無いとキツイ。
  • 既にNode.jsが入っているとnodebrew自体がインストール出来ないので削除作業が必要。
  • nodebrew自体をアンインストールする必要が出た場合、どうしていいか分からない。。。(情報求む)

【おすすめタイプ】

  • 黒い画面の基礎知識がある。または勉強する気がある。
  • 複数バージョンのNodeを用意しておく必要がある。
  • Node王に、オレはなる!

4. homebrew→nodebrew経由でインストール

パッケージ管理ツールのhomebrewからまずnodebrewをインストールし、nodebrewからNode.jsをインストールする合わせ技の方法です。
この方法だとnodebrew自体も簡単にアップデート・アンインストール出来るので、3の方法で謎だった「nodebrew自体をアンインストールする方法」で頭を悩ませる必要がありません。
なので、「これでパッケージ管理もバージョン管理も両方出来て最高じゃない!?」

・・・・と思った方、残念賞!

この方法は、Yosemite以上の環境の方にはお勧めできません!なぜなら、
homebrewでインストールしたnodebrewではnodeを正常にインストールすることができないから!
何を隠そう、それを知らずにJava→Command Line Tools→homebrew→nodebrewと、環境構築フルコースを完走したあげく、最後のNodeのインストールでトラップにハマって詰んだのが私ですorz
もうね、ため息しか出ないですよ。ほんと。。。
ちなみに試してないですが、ネットの情報を見る限り、以前はそれでできていたようなので、
Mervericks以下なら大丈夫なのだと思います。

【おすすめタイプ】

・Mervericksから絶対にOSバージョンアップしないと誓う人

まとめ

というわけで、いろいろ試してみた結果、Node.jsをインストールする方法としては

  • 後のことはともかく、とにかく今すぐサクッと動かしたいなら「公式インストーラ」
  • ある程度後々のことも考えてバランスの良い環境を作りたいなら「nodebrew経由」

という感じがいいんじゃないかと思います。
homebrewは、少なくともWebデザイナー・コーダーがNode系のツールを使うだけならすぐには不要なのではないかと思いますね。将来的にバリバリ開発する方に回りたいならあらかじめ環境構築の一環として整備するのも良いですが、少なくともNode.jsのインストールとその管理のためだけなら無くても良いです。
時間は有限なので、活用する予定のない環境構築している暇があるなら、UNIXの基礎を勉強した方がいいです。

というわけで、非エンジニアの方はまずは「黒い画面恐怖症」を克服してみるといいと思います。
<参考>「Webデザイナーの為の「本当は怖くない」”黒い画面”入門」

フリーランスが抱くマイナンバー制度に対する漠然とした不安

mn_logo_b

いよいよ来年から「マイナンバー制度」が施行されます。
始まってしまうものは仕方ないので今更是非を問うつもりはないのですが、
原則生涯同じ番号を使い、今後様々な情報と紐付けられる可能性のあるマイナンバーをどう管理するのか、という点について
フリーランスの場合は会社員とは比較にならない大きなリスクが存在するのではないかと感じたのでまとめておきます。

▼マイナンバーの提出先が複数になる

会社員の場合、基本的に所属している会社は1つ、バイト掛け持ちのような場合でもせいぜい2〜3箇所がいいところでしょう。
しかしフリーランスの場合は、通常いくつもの取引先を持っているのが普通ですし、
新規開拓営業や紹介などによって取引先は基本的に増える傾向にあります。
(全く増えない、もしくは減り続けるのはマイナンバーとは別の意味で危機です;)

その取引先が「源泉徴収義務者」に該当した場合、フリーランスが請求した金額は相手先企業によって
源泉徴収された上で支払いが行われます。そして、来年度からは企業が源泉徴収した金額を税務署に通知する書類(支払調書)に
マイナンバーを記載する義務が発生します。

つまり、源泉徴収する取引先の数=マイナンバーの提出先の数 となるわけです。
10社あれば10箇所、20社あれば20箇所、100箇所あれば100箇所に、重要個人情報の塊であるマイナンバーを提出する必要が出てくるわけです。
新規の、1回ポッキリになるかもしれない相手であってもです。

一度提出したマイナンバーの管理は、相手に任せるしかありません。
渡した相手が法律にのっとって厳重に管理してくれる保証は、ありません。
もちろん多くの企業はちゃんと管理してくれるでしょう。
ですが、取引先の数が増えればその分、不手際をやらかす企業にあたってしまうリスクは当然上がります。

▼マイナンバー廃棄の基準が不明確

会社員やアルバイト等の場合、その企業を退職すればマイナンバーは廃棄されることが法律に明記されています。
しかし、外注先の個人事業主のマイナンバーについては、廃棄の基準が法律上はありません。
常識的に考えれば「取引がなくなった相手」のマイナンバーは保管する意味がありませんので廃棄対象になると思われますが、
「単にしばらく発注していない相手」と「今後も取引をしない相手」をどう区別するのでしょうか?
その基準は、法律上は何も明記されていないため、各企業が個別に判断するしかなく、
理論的には一度入手したマイナンバーを永久に保管(放置)し続けることも可能なわけです。
そういう企業はそもそも「ちゃんと管理しよう」という意識に欠ける可能性が高いため、
ずさんな管理により流出させてしまうリスクも高いと思わざるを得ません。

▼万が一流出してしまった場合の手続きを考えると頭が痛い

実際にはそうそう流出・悪用されるなどということは無いと思いたいですが、
上記の理由によりフリーランスの場合は会社員よりも格段に流出のリスクは高く、
フリーランスを続ける限り自衛の手段がほとんど無い状況です。
もし万が一流出したことが確定した場合、法律に基いてマイナンバーを再発行することはできます。
できますが、当然、これまで提出した各所へのマイナンバー書き換え手続きを全てやり直さなければなりません。
何十とある取引先も全てです。
杞憂にすぎないかもしれませんが、もし現実になったらクソとても面倒くさいです。

▼個人事業主への発注をためらう企業が出るのでは?

あとこれは憶測にすぎませんが、マイナンバーの管理は企業にとっても結構な負担なはずです。
従業員のマイナンバー管理は仕方ないとしても、外注先のマイナンバーまで管理するのは嫌だから、
という理由で、個人事業主への発注をためらう/とりやめる企業が出てきたりすると、商売上がったりです。
幸い今のところ私の周りの取引先からは「取引停止」も「法人成りの要求」も特に聞かれませんが、
ひそかに「フリーランスかぁ。マイナンバーめんどくせぇな」という理由で発注対象から外されたとしても
知る方法がないので分かりません。正直不安しかありません。

▼新規取引先を開拓しづらくなるのでは?

受注する側としても、これまで継続したお取引のある企業さんであれば性善説に基いて信頼することもできますが、
紹介ではない形で聞いたこともない企業からオファーがあった時、
マイナンバーのことが頭をよぎると心理的に請けづらくなるような気がしてなりません。
創業間もないベンチャー・中小零細企業、特に法人成りしたての元個人事業主あたりが
個人に発注しようとした際に「きちんと法律に基いて厳密に個人情報を管理します」ということを
相手に信用してもらわないと受注を断られる、なんてケースも出てきたりこなかったり。


そんなこんなで、フリーランスにとってマイナンバーはハイリスク・ローリターンな制度でしかないな、
という印象です。

そんなマイナンバーの取り扱いに関する不安を可能な限り払拭する方法については、また次回。

display:table-cell; の使い方まとめ

ff514934c8f52753b6f4d3600768f496

いつもコーディングセミナーを担当させていただいているサポタント株式会社のスキルアップコラムにて、
display:table-cell;を活用した「仮想テーブルレイアウト」の使い方を掲載させていただいております。
時代はそろそろflexboxだろ!!という声が聞こえてきますが、個人的にはまだまだtable-cell押しですw
(だってflexboxめんどk…)

何気に仮想テーブルレイアウトの使い方をちゃんとまとめたブログ記事とかあんまり無いような気がするのでよかったら参考にしてください!
意外とハマりがちなポイントや、ちょっとしたデザインTipsも紹介してますよ☆

詳しくはこちらへ!!!!

 ↓ ↓ ↓ ↓ ↓ ↓ ↓

コーディングセミナー開催してます

サポタント株式会社主催のコーディングセミナーで講師担当しています。
直近の開催セミナーはこちら。

Photoshop CC の画像書き出しを比較してみた。

スクリーンショット 2015-10-11 23.14.58

先日Photoshop CC 2015がリリースされ、画像の書き出し関連がまた変更になりましたね。
Webデザイナー&コーダーの皆さんは、普段画像の書き出しにどの機能を使っているでしょうか?

CS6・CC・CC2014・CC2015の各バージョンで少しずつ搭載されている機能に違いはありますが、現在PhotoshopからWeb用画像素材を書き出す方法としては下記の4つの方法が考えられるかと思います。

  1. スライス→Web用に保存(CS6〜)
  2. Generator機能→画像アセットの生成(CC〜)
  3. アセットの抽出(CC 2014)
  4. 「新」書き出し機能(CC 2015)

私は長らく1の「スライス→Web用に保存」を愛用してきましたが、昨年あたりからもっぱら2の「Generator機能による画像アセットの生成」を使うようになりました。

Generator機能を使った「画像アセット」をまだ利用したことがない方は、こちらの記事を参考にしてください。
【参考】この進化はズルイ!Generatorテクノロジーを使ったPhotoshop CCの「画像アセット」

▼「画像アセット」

まず「Web用に保存」と比較した場合の「画像アセット」のメリット・デメリットをザックリまとめるとこんな感じです。

【メリット】

  1. 一度生成のための設定をしておけば、Photoshopを修正更新するたびに画像アセットも自動更新されるので、書き出し手順が大幅に短縮される。
  2. レイヤー単位で書き出されるため、他のレイヤー画像と重なった状態の素材を出力する際に、いちいちレイヤーを非表示にしたり、スライスを調整したりしなくても済む。
  3. アルファ付きpng8の出力ができる
  4. レスポンシブ用に2倍・3倍などの解像度違いの素材を同時に自動出力できる。
  5. Web用に保存より圧縮率が高い

【デメリット】

  1. 任意のサイズで書き出したい場合にはレイヤーマスクを設定する必要があるため、サイズ変更にやや手間がかかる。
  2. 事前に元画像と圧縮画像の比較・確認ができない。
  3. 画像出力先フォルダを任意に指定できない(psdと同階層にできるアセット用フォルダに固定される)

個人的にはメリットの方がかなり大きいので、多少のデメリットはささいなものかと思います。

▼「アセットの抽出」

「アセットの抽出」は、Photoshop CC 2014にのみ搭載されている機能で、基本的に出来ることは上記「画像アセット」と同じです。generatorで画像アセットを生成する場合、細かい指定はレイヤー名に直接指定するのですが、その辺をパネルを使ってもう少し直感的に使えるようにしてくれたもの、と考えれば良いかと思います。

「アセットの抽出」をまだ利用したことがない方は、こちらの記事を参考にしてください。
【参考】[Photoshop]画像アセット生成でできること

「アセットの抽出」をgenerator機能で直接画像アセットを生成した場合と比較したメリット・デメリットをまとめるとこんな感じです。

【メリット】

  • JPEG画質やサイズ違いの出力設定で、レイヤーにいちいち自分で名前をつけなくてもいい。
    (パネルで設定すれば勝手にレイヤー名を変更してくれる)
  • 抽出画像の保存場所・フォルダ名を任意に設定できる

【デメリット】

  • サイズ違いの出力は全アセット一括なので、不要なサイズも出力されてしまう。
  • Photoshop CC 2014にしか搭載されていない(2015では廃止)

▼Photoshop CC 2015「新」書き出し機能

Photoshop CC 2015になると、画像の書き出し絡みがまた大きく変わっています。
主な変更点は以下のとおりです。

  1. 「Web用に保存」に代わる新たな画像書き出し機能が「書き出し」として搭載された。
  2. 「Web用に保存」が「ファイル>書き出し>Web用に保存(従来)…」に移動。(将来的には廃止されるらしい)
  3. 「アセットの抽出」機能は廃止され、従来の「画像アセット」のみに戻った。
「新」書き出し機能をまだ利用したことがない方は、こちらの記事を参考にしてください。
【参考】迷走しているPhotoshop CC 2015の書き出し
【参考】Web用保存は古い1? JPEG画質が改善したPhotoshop CC 2015の新方式の画像保存機能まとめ

「新」書き出し機能の特長をザックリまとめるとこんな感じです。

  • 書き出し先を任意に指定できる
  • 書き出し画像のファイル名は、デフォルトではレイヤー名を使用。書き出し時の変更もできるが名前の保持はできないので、画像アセット同様レイヤーに画像名を指定する必要がある。
  • 拡大・縮小機能でサイズ違いの出力が可能。(複数サイズの同時出力はできない)
  • png-8/gif形式でインデックスカラーの色数指定はできない。
  • スライスの書き出しには対応していない。(Web用に保存を利用)

個人的には、どのみちレイヤーに名前つけなきゃならないなら、画像アセット機能で生成した方が手間もかからないのでわざわざ個別に書き出しをする理由があまり見当たらないかな、という印象です。
まぁ画像アセットと違って出力先を任意に指定できるので、直接プロジェクトのimgフォルダに書き出しできるのはいいと思いますが正直メリットはそれだけかな。。。

▼まとめ

Photoshopからの画像書き出し機能としては、個人的にはCC 2014の「アセットの抽出」が最も使い勝手が良いという印象です。機能的には画像アセットでも同じですが、複数サイズ出力等の設定を自分でレイヤー名に記述しなくてもいいというのが個人的には楽ちんで良かったので。
復活してくれないかなぁ〜〜(;´Д`)

追記

「画像アセット(CC 2015も含む)」の場合は

  • 生成された画像は元PSDと同階層に出来る「xxxx-assets」フォルダに固定される(xxxxは元PSD名)
  • PSDが更新された場合、アセットフォルダの中身は一度削除され、再度画像が書き出される

という特徴がありますので、生成された画像を制作中のWebサイトのimgフォルダに手動で移動させる手間がかかるのですが、これが「アセットの抽出」だと、

  • 抽出した画像を任意のフォルダに書き出すことが可能
  • 複数のPSDからの抽出先を同じフォルダに設定した場合、同じ名前でない限り追加される(もともと存在していた画像を削除することは無い)

という形になるので、抽出画像を制作中のWebサイトのimgフォルダに直接書き出すことが可能です。
この1点だけでも、「画像アセット」よりも「アセットの抽出」の方が優れているといえます。
Adobeさんは何でこの機能を廃止してしまったんでしょうね・・・・。