「投資信託による資産運用のイロハ: 毎月分配型を中心に」(Kindle版を発売しました)

技術書とは違う系統の本ですが、本日、「投資信託による資産運用のイロハ: 毎月分配型を中心に」のKindle版をリリースしました。

アマゾンKDPの紹介ページ

ボリュームは紙の本にして30ページ弱ということで少ないため、まだ、POD版は出していません。POD版ページ数がもう少し多くないと割高感がぬぐえません。

本当は、もう少し過激な内容にしていろいろ新しい指針を出したいところだったのですが、今のところ本書で紹介する理論の実績が少ないので過激な部分は見送ってしまいました。

本書の理論では、毎月分配型投資信託を10年経過すると必ず利益がでるように選択して運用せよ、ということなんですが。まだこの理論を運用し始めてから5年ほど経過しただけなため、実績としてでていないのです。

あと5年経過すると実績をもって有効性を主張できるはずなんですが。ということで本書をPOD版の出版まで最長で5年ほどお待ちください。

アンテナハウスのWebサイトが全面的にレスポンシブになりました

アンテナハウスのWebサイト(https://www.antenna.co.jp/)は、7月10日より全面的にレスポンシブ化してモバイルでも読み易いようになりました。

例えば、「PDF資料室」は、従来はモバイルでは次のように表示されていました。

これでは、狭いモバイル画面で表示するとき、左のナビゲーションメニューのため本文の表示幅がさらに狭くなってしまって大変読みにくい状態です。そこで、新たにモバイルで次のように表示されるようにレイアウトを追加したものです。

CSSとメニュー表示用のJavaScriptの機能を追加して、画面幅が狭いときはモバイル用のレイアウトで表示するようにしたものです。PCファーストのレスポンシブデザインと言えるかもしれません。

アンテナハウスのWebサイトは、2011年に全面的にリニューアルしたものです。当時はモバイルWebはまだマイナーな存在でしたので、WebページはPCの画面を想定してデザインされています。

その後、スマホの隆盛により、Webサイトのデザインの流行もだいぶ変っています。デザインの流行はともかく、PC向けのデザインのままではスマホの画面ではとても読みにくいものとなってしまいます。そこで、とりあえず、レスポンシブデザインの考え方を取り入れて、スマホでもできるだけ読み易いようにすることにしました。

レスポンシブデザインは、表示する画面の幅に応じてレイアウトを最適化するものです。具体的にはCSSのメディアクエリーの機能を使って画面幅に応じたCSSデザインを適用するものと考えます[1]。市販されているレスポンシブデザインの本を読みますと、デザインパターンなどが紹介されており、それらはほとんど、Webをデザインし直して、ゼロから作り直すことを想定しています。考え方としてはモバイルファーストが良いとされているようです。

しかし、アンテナハウスの現在のWebサイトのように(会社の規模にしては)膨大な情報量を用意しているページを、モバイルファーストでゼロから作り直す、というのは無理があります。不可能とまでは言いませんが、工数が大きくなりすぎてとても短時間では実行できません。そこで、今回はPCのときは従来のデザインはそのままとし、狭い画面でのみ新しいデザインとするという、一般の本に書かれているのとは逆の方法でレスポンシブ化してみました。

これにより、ほとんどのWebページでCSSとJavaScriptを入れ替えるだけでレスポンシブ化ができています。

[1]幾つかの本をチェックしてみますと、この考え方は、少し単純化しすぎかもしれません。デザイナーの理想とすることは分からないでもないですが、膨大な(?)Webページをゼロから作り直しは無理があると思います。

FormatterClubセミナーでの、CAS-UBのスライドと動画を公開しました。

7月7日七夕の日のFormatterClubセミナーは、40数名のご参加いただき、大変盛況でした。大変暑い日でしたが、お集まりいただきました皆様に感謝申し上げます。

早速ですが、セミナーのCAS-UBプレゼン資料を下記に公開いたしました。参考にしていただければと存じます。

1. CAS-UBのスライド
「デジタル出版物制作Webサービス「CAS-UB」 ワンソースマルチユースのポイント AH FormatterによるPDF作成を中心に(スライドシェア)

2. 動画
CAS-UB操作の流れ(MP4形式動画)(CAS-UB Webページにて)

本はWeb化するか その3 J-STAGEの新バージョン評価版をみて考えたこと

6月2日開催された「学術情報の流通を考える-ORCIDとJ-STAGE新バージョン評価版をめぐって-」セミナーに参加しました[1]

ORCIDの話も面白かったのですが、小倉 辰徳氏によるJ-STAGEの新バージョンの紹介が、いま考え中の課題「本はWeb化するか」の観点から大変参考になりました。セミナーのスライドはこちらです[2]

J-STAGEは、「見やすく,使いやすいジャーナルサイト構築のため,海外のジャーナルプラットフォームを参考にしつつ,デザインを一新する.」(スライド[2]p5より)として開発中です。機械学会、薬学会より3誌をモデル誌として選択して、1年ほど前からベータ版の運用試験を行っており、2017年度中に全雑誌に適用する予定とのことです。

画面の説明など、詳しくはスライドで紹介されていますのでご参照ください。

早速、J-STAGEの評価版Webページを見ました。機械学会の「Mechanical Engineering Letters」は全文HTMLではなく、PDFダウンロードです。それに対して薬学会の「Chemical and Pharmaceutical Bulletin」「Biological and Pharmaceutical Bulletin」は全文HTMLを見ることができます。

例えば、Chemical and Pharmaceutical Bulletin[3]は、画面切り替えタブで、ジャーナルのホームページ、発行前の原稿が確定した版(Advance online publication)、各号(Journal issue)、主要論文(Featured articles)、ジャーナルについて(About the journal)に切り替わります。そして各論文の内容はPDFダウンロードに加えて全文HTMLを見ることができます。

ちなみに、Palladium(0)-Catalyzed Benzylic C(sp3)–H Functionalization for the Concise Synthesis of Heterocycles and Its Applications(Volume 65 (2017) Issue 5 Pages 409-425)の全文HTMLのWebページを見てみます[4]

Webページ全体のデザインは次のようになっています。

このHTMLページは、Window幅を狭くすると2段階のブレークポイントで表示が切り替わります。第1段階ではジャーナル上位のダウンロードメニューが右からジャーナル概要の下に切り替わります。第2段階でArticle overviewのメニューがボタンに縮退します。スマホで見ると次のようになります。

こうしてみますと、まさに現代風のレスポンシブデザインになっています。

そこで、気になるのが、このWebページがどのように作られているかです。ソースファイルを見ますと、Webページは次のような構成になっています。

HTML5で1953行であり、3行目~35行目がhead要素。9個の外部CSSをリンクしています。
36行目~1952行がbodyで、bodyの最後部1378行目~1952行にJavaScriptがあります。かなり直書きされており、全体の行の29%がJavaScriptです。

bodyは次のように分かれています。
・header要素:39~148行
・ジャーナル専用部
・footer要素:1311~1362行目
・フィードバックボタンなど1363~1377行目

header、footerはJ-STAGEシステム全体のメニューなどがあり、ジャーナル専用の部分は149行目~1310行目です。

ジャーナル専用部は次のように分かれています。
・ジャーナル紹介:151~163行目
・画面切り替えのタブ:166~180行目
・パンクズリスト:180~194行目
・記事毎のタイトルと概要・右メニュー:195~306行目
・ジャーナル記事本文:309~1304行目

全体としては記事本文が半分でそれ以外がタイトルやナビゲーションメニュー部となります。

こうしてみますと、Webページは、コンテンツが半分でそれ以外がリンクやナビゲーションのHTMLとCSSとJavaScriptから構成されている、一種のプログラムとデータの集合体と言えます。

Web誕生の頃は、HTMLだけで書いていたのですが、その後HTMLとCSSが分離し、現在のWebページは、HTML+CSS+JavaScriptとなっていますが、このJ-STAGEページはその典型例です。

こうしたWebページはもはや人手でHTMLをコーディングするものではなくなり、CMSに登録したデータからCMSの機能を使って生成しているはずです。そういう意味でCMSに完全依存となっています。

出版物のコンテンツがプログラムと組み合わさってWeb上のアプリケーション化しています。学術情報誌のページとなりますと、こうしたページが何万、何百万個と作られます。そこで、私として一番気になるのは保守コストです。保守は3つに分かれます。

(1)まず、障害対応です。Webページに直書きされているJavaScriptページは一番問題で、ここにバグがあるとWebページそのものを作り直しとなります。

(2)次は改良です。CSSとJavaScriptが膨大になっていますので、これらを改良したとき今までのWebページに問題が起きないかどうか? 

(3)次に抜本的な作り直しです。今回のJ-STAGEのユーザーインターフェイスの作り直しは2015年から開始しているとのことですので、既に2年掛かっています。これを2017年度内に全雑誌に適用するということですが、膨大な費用が掛かっているのは間違いありません。

WebのコンテンツをHTMLで作り、CSSでレイアウトし、JavaScriptでインターフェイスを操作する、という流れ。さらにスマホの登場でレスポンシブにするという流れが加わり、Webページのメンテナンスコストがどんどん大きくなっていく傾向にあるように感じます。

ここでもう一度、コンテンツとアプリケーションを分離したEPUB3の良さを見直してみる必要がありそうです。特に、学術論文のようにタイトル数が膨大なものをWebにするとき、プログラムを組み込んでアプリケーション化すると、将来の保守コストが大きな問題になるのは間違いないところです。

[1] XSPAセミナー「学術情報の流通を考える-ORCIDとJ-STAGE新バージョン評価版をめぐって-」のご案内
[2] J-STAGEの評価版について(スライドシェア)
[3] Chemical and Pharmaceutical Bulletin
[4] Palladium(0)-Catalyzed Benzylic C(sp3)–H Functionalization for the Concise Synthesis of Heterocycles and Its Applications(Volume 65 (2017) Issue 5 Pages 409-425)

参考
ワンソースマルチユースで拓く、ブック型Webページの未来 (ブログ記事2回分を整理したHTMLページ)

本はWeb化するか? (続き)Webアプリケーション化したオンライン版の本 vs シンプルなHTML+CSSの本

先日、姉妹ブログサイトに「本はWeb化するか? PDFとブック型WebページとEPUBを考える」で、本の中には技術や考え方の啓蒙・普及を目指すタイプがあり、こうしたタイプの本はWebページで提供すると大変便利と述べました。CAS-UBの次バージョンでは、本のWebページ版生成機能をより強化したいと考えています。今日は前回のブログの続きとして本のWeb化について考えてみます。

購読モデルのオンライン本
一冊の本の内容を全部そのままWebページとして提供する例を幾つか示します。まだあまり一般的ではないようですが、探せばもっとたくさん見つかるでしょう。

米国のO’Reilly MediaのSafari Books Onlineは2001年創業で、2014年にO’Reilly Mediaの傘下にはいりました。Webページとして提供する本の草分けといえるでしょう[1]

『Chicago Manual of Style』は100年以上の歴史をもつ、編集者のための制作ガイドです。最新は2010年発行の16版です。15版と16版はオンライン化されています[1]

それから同じ版元の『Science Style and Format』[3]も全文がオンラインで提供されています。

こうしたオンライン本は無料公開ではなく、購読制のビジネスモデルを取っています。ここで紹介したような本を作るのは非常に大きな時間と労力がかかりますし、内容をアップデートする作業も大変です。購読制にしないと維持できないということはよく理解できます。

無料モデルのオンライン本
一方、Webページ版を無償で公開している本もあります。『Web Style Guide』は、プリント版は第4版ですが、第3版以前は全文がWebページとして無料で公開されています[5]。第4版も作業中ということですので、いずれは全文がWebページとして公開されるのでしょう。

第4版を紙で出版したのは、2016年夏です。まだ作業中って随分のんびりですね。CAS-UBを使えば紙版と当時に(ボタンを押すだけで)Webページ版もできるのですが。それとも全文公開すると紙が売れなくなるので、わざとのんびりしているんでしょうか? 

本のWebアプリケーション化
購読制・有償・無償というビジネスモデルとは別の側面として、本のWebアプリケーション化という観点があります。

現在のWebプラットフォームは、JavScriptを使って対話的な操作を付けるのが流行です。「2012年8月時点で、上位100万件のWebサイトのほぼ半数でjQueryが使われているとの推計があります」[6]とのことですから、現時点では恐らく上位Webページの大多数にjQueryが組み込まれていると思われます。これによりメニューのプルダウンやアコーディオン表示などを行います。特にレスポンシブなWebページをモバイルで表示するときはメニューを畳んでおいてタップで開くという対話的表示が有効です。

オンライン版の本については、特に目次のアコーディオン表示が典型的な応用です。大きな本では、章と節の2段階目次でも100項目を超えることもありますから[7]、アコーディオン表示が便利です。但し、階層が深いと操作の繰り返し回数が多くなりますので注意が必要です。

さらに、『Chicago Manual of Style』と『Science Style and Format』のオンライン版(CMSO・SSFO)は、コメントの記入やしおり設定ができるようになっています。

ナビゲーション機能・目次機能も含め、全体としてみますと、CMSO・SSFOは、それ自体が、EPUBリーダーやKindleなどの電子書籍アプリ並の機能をもっています。CMSO・SSFOのWebページはホスト型Webアプリケーションになっているとも言えます。

シンプルなHTML+CSSによるオンライン本
一方で『Web Style Guide』のオンライン版は、HTML+CSSで作られた静的なWebページです。また、本ではないですが、米国で2008年から続いているXMLカンファレンスである「Balisage」の講演録のシリーズは、HTML+CSSのみで記述されたトラディショナルかつ静的なWebページです。こうした静的なWebページは現時点では非常にレガシーな印象を受けます。

未来の本
本のWebページ化は、ここで紹介したようなガイドブックなどの実用的なものが先行しながら、今後着実に進んでいくことでしょう。

では、本をWebページとして作るとき、jQueryを初めとするJavaScriptを多用することについてどういう方針とするべきでしょうか? これは大きな問題です。本をWebアプリケーション的に作ろうとすれば、必然的に制作コストは大きくなります。もっと大きな問題はメンテナンスコストです。何百点、何千点もの本をアプリケーション的にしてしまうと、そのメンテナンスコストが膨大になることは避けられないでしょう。

JavaScriptがWebサイトで多用されるようになってから経過した年月と、その間の変化の激しさを見ますと、本のような多品種ジャンルでアプリケーション化を推進するのは躊躇したくなります。一方で、現在のWebプラットフォームは、HTML+CSS+JavaScriptが基本となり、ますますリッチな表現と便利な機能を備える方向に向かっています。そうしますとレガシーなWebページとして表現された本には魅力がなくなる可能性があります。

このあたりは思案しどころです。

[1] Safari Books Online
[2] Chicago Manual of Style Online
[3] Science Style and Format Online
[5] Web Style Guide
[6]『モダンWeb』(Peter Gasston著・牧野聡訳、オライリー・ジャパン、2014年発行)
[7] 例えば、『PDFインフラストラクチャ解説』は章・節を目次に掲載しており、目次項目は延べ122です。
[8] BalisageのProceedingsページ

■関連記事
「ワンソースマルチユースで拓く、ブック型Webページの未来」(2回のブログをまとめて整理し直しました)

【お詫びと訂正】
最初に公開した文章に下記の記述がありましたが間違いでした。訂正致します。
「米国の大学で使われる研究レポートの書き方についてのガイドとして有名な『AMA Manual of Style』も全文オンライン化しています[4]

[4] AMA Manual of Style
正しくは、
「米国の大学で使われる研究レポートの書き方についてのガイドとして有名なのは、『MLA Handbook』(Modern Language Association刊行)です。こちらは、紙版の他にKindle、Apple、等で電子版を販売していますが、Web版はありません。」

申し訳ございません。

Microsoft EdgeのEPUB表示機能はなかなか良い。これからはEdgeだと言いたいところですが、しかし、残念な点もあります。

4月11日にリリースされたWindows 10のアップデート(バージョン1703)でEdgeのEPUBリーダーが一般に使えるようになったとのことですので、早速、Windows 10をアップデートしてEdgeを使ってみました。

EPUB3のサンプルとしては、先日発売しました『XSL-FOの基礎 第2版』を使いました。こちらで公開していますので、ぜひ、ご一読ください。

「XSL-FO の基礎 XML を組版するためのレイアウト仕様」第2版【新発売】

Webに公開してEPUBをWebページと同じようにリンクで開けます。

図1 EdgeでEPUBをWebと同じように開く

まず、Edgeでは、Windowの幅により2段組と1段組で表示されます。表示Windowの幅が広いと2段組で、表示Windowの幅を狭くすると1段組となります。

図2 2段組みの表示

図3 1段組みの表示

ページの下部に柱が出ています。左が本のタイトル、右が章または節の見出しです。これはなかなか良いです。

Windowの上部をタップするとメニューが表示されます。

図4 メニューを表示

メニューは左側に「ナビゲーション目次」「ブックマーク(一覧)」「検索」、右側に「文字など表示設定」「音声読み上げ」「ブックマーク追加」です。次の画面はナビゲーション目次を表示したところです。

図5 ナビゲーション目次を表示

音声読み上げはなかなか秀逸です。EPUBには音声同期を設定していないのに、読み上げている文節をハイライト表示します。もうメディアオーバレイによる設定は要らなくなります。

図6 音声読み上げ(ハイライト表示)

このEPUBは、章毎にファイルを分けていますので、新しい章の開始位置で改ページまたは改段します。それは普通です。

図7 章の開始で改段

さらに、節の見出しと次の本文や見出しが同じ段に入らないとき、泣き別れしないように節の前で改段できます[2]

図8 節の前で改段

表のテキストだけをポップアップして表示できます。

図9 表のテキストをポップアップで表示

画像は幅または高さに合わせて縮小します。ラスターイメージ(このサンプルではPNG)を縮小すると少し汚くなりますが、図だけ拡大表示もできますので問題はないでしょう。なお、図をSVG形式としたEPUB3版も試して見ました(PDF作成用の図をそのまま使ったもの)。SVGも問題なく表示できるようです。いままで、EPUBを作るときはラスターイメージにしていたのですが、これからは公開するEPUBはSVG画像でも良いかもしれません[1]

気になりましたのは整形済み(pre)のレイアウトです。Edgeではpre要素の前で改ページまたは改段します。これは必要ありません。そしてpreの中では改ページ/改段しません。このためpreの部分が見切れてしまいます。技術系の文書では多くの場合、preの内容はサンプルのコードなのでpreの内容を1段に収める必要はないのです。特に、見切れてしまうのは致命的です。評価用ではなく正式なEPUB3ではpreは使えないということになってしまいます。困りましたね。

図10 preの前で改段してしまう。preの内容が見切れてしまう

[1] 『XSL-FOの基礎』画像制作のこと。Word経由でインポートした画像は印刷品質の劣化が激しいため、第2版ではできるだけSVG形式に変更した件。
[2] ちなみにiBooksでは次のように見出しと本文が泣き別れしてしまいます(iBooks 4.1.1)。

■関連
『XSL-FOの基礎 第2版』は全文をWebでも公開。CAS-UBでプリントオンデマンド用PDFを作り、Web生成機能でWebページもワンタッチで完成。

英語、ラテン語の辞書にみる「ページ」の語源、使用例

『オックスフォード英単語由来大辞典』[1]には「ページ」という言葉の由来が次のように説明されています。

・pageは16世紀後半から
・pages of a book「本のページ」の意味のページは、ラテン語のpãginaから派生したフランス語による。pãginaの元になっているのは、pangere(留める)である。
・pagination「ページつけ」「ページ数」はpaginate(本にページつけをする)という行為の名詞形として19世紀半ばに現われた。ラテン語pãginaから派生したフランス語paginerによる。

ということですので、英語のpageという言葉の歴史は比較的新しいようです。『紙二千年の歴史』[2]によると紙がイギリスに伝わったのは1494年(同書p.61)とあり、『紙の世界史』[3]では、イギリスの初めての印刷業者はウィリアム・キャクストンが1476年にウエストミンスターに開いた印刷工房、初めての製紙工場は1495年とあります(同書p.254)。

そうしますと、15世紀後半に紙と印刷がイギリスに伝わってから英語のpageという言葉が生まれるまで100年ほど掛かっていることになります。紙や印刷はヨーロッパからイギリスに伝わったものですので、「ページ」がラテン語からフランス語へ、そして英語へと伝わったのはわかります。

『古典ラテン語辞典』[4]では、pãginaの意味は次のようになっています。

1.紙(パピルス)の1枚、1頁
2.頁の内容、書きもの、文書、誌、作品

古典ラテン語ではパピルスの髄を並べて紙を作ったことから留めるという言葉からページという言葉が派生したようです。

『新編 英和活用大辞典』[5]には、英語のpageの用例が大量に出ています。ページという言葉は、単に紙の1ぺージという意味だけではなく、歴史の1ぺージというような、比喩的な意味にも使われています。本書は1995年発行ですので、当然、インターネットのWebページに関連する使い方は一つも出てきません。

『三省堂 英語イディオム・句動詞大辞典』[6]では、pageの使い方として、

・page up/page downとして「コンピュータで次/前のページを出す」

とあります。2011年ですので、もうインターネットがかなり普及している時代ですが、まだ、1画面を1ページと見立てた説明になっています。

でも、この説明は英語の元の意味(使い方)と違うような気もします。つまり英語のpage upは縦につながっている巻物全体を1ぺージとして、巻物を上にスクロールする意味なのに、page upを次の「ページを出す」としてしまうと、いかにもページが区切られているように受け取られてしまいませんか?

現在、ページというとWebページという意味で使うことが増えていますが、英語の(紙の)辞書でWebページを説明しているものをまだ見かけていません(Webの辞書における説明は初回のブログにあります。)。次回、図書館で探してみましょう。

[1]『オックスフォード英単語由来大辞典』(グリニス・チャントレル編、株式会社柊風舎、2015年12月25日発行)
[2]『紙二千年の歴史』(ニコラス・A・バスベインズ著、原書房、2016年5月30日発行)
[3]『紙の世界史』(マーク・カーランスキー著、川副 智子訳、徳間書店、2016年11月発行)
[4]『古典ラテン語辞典 改訂増補版』(國原 吉之助著、大学書院、2016年12月30日発行)
[5]『新編 英和活用大辞典』(市川 繁治郎他編、研究社、1995年発行)
[6]『三省堂 英語イディオム・句動詞大辞典』(安藤 貞雄編集、三省堂、2011年7月10日発行)

★ページに関連する過去ブログ記事の一覧
[1] ページってどういう意味? 紙のページ、Webページ (memo)
[2] ページってどういう意味? 続編 Kindleの紙の本の長さと、KENPについて
[3] Kindle Unlimited問題とKENPの関係について(続き)
[4] Amazonでは本のページの数え方が三つある。Kindle Unlimitedは第三のKENPで著者への支払いが行われ、KENP相場が基準になる。
[5] ページっていったい、どういう意味なんだろう? ――Webページ
[6] ページって何? 「ページ」と本のかたちとの関係、「ページ」と「頁」の関係、ブラウザと電子書籍の未来

★「ページ」についてまとめたWebページ
本のかたちを考える ― その2ページって何?「ページ」と本のかたちとの関係

CAS記法によるWebページの作成:Webページ内の参考資料へのID設定と、本文から内部リンクを設定する方法

CAS-UBで次のようなWebのリンクを設定する方法を紹介します。

(1) Webページの末尾に参考資料のリストを作る。
(2) Webページの本文から、参考資料へのページ内リンクを設定する。

出来上がったWebページはこんな感じです。


図1 リンク元


図2 リンク先

HTMLで、このようなページ内部のリンクを作るには、リンク先の要素にid=id値を設定し、リンク元のアンカータグ(aタグ)のhref属性に#id値を設定します。

CAS記法では次のようにします。リンク先の要素にはユーザー独自idのマークアップを使います[1]。CAS-UBでユーザー独自のidを付けるには、二つの方法があります。難しい方法と簡単な方法があります。利用ガイドでは難しい方法のみを詳しく解説しています。(難しい方法には、自動化処理のための用途があるのですが)ここでは単にリンクを設定するだけの簡単な方法をご紹介します。

次のようにすれば良いです。

1.リンク先に:id=id値 という属性名と属性値を設定する
2.リンク元に[[#id値|アンカーテキスト]] というマークアップをする。

上の例では次のようになります。

1.リンク先
CAS記法のマークアップ:
*::nolabel:id=s1 [1] [[http://stackoverflow.com/questions/42618628/how-to-convert-office-file-to-image/43161134|How to convert office file to image]]
HTMLでは右のようになります:
<ul class=”nolabel”><li id=”s1″>[1] <a href=”http://stackoverflow.com/questions/42618628/how-to-convert-office-file-to-image/43161134″ >How to convert office file to image</li>

2.リンク元
CAS記法のマークアップ:
StackOverflow の質問(英語)[[#s1|[1~]]]より引用
HTMLでは右のようになります:
StackOverflow の質問(英語)<a href=”#s1″ >[1]より引用

::nolabelはリンクとは関係なく、CSSで箇条書きのラベルを付けないようにするためのクラス属性の設定です。
:id=s1 が箇条書きの項目(li)のid属性になります。

参考資料
[1] CAS-UBでは見出しや図・表のキャプションには自動的にidを設定します。ユーザーがCAS記法で設定するidについては、自動設定のidと区別するためにユーザー独自idという表現をしています。これは、HTMLでは通常のid属性にあたります。
[2]第9章 CAS記法の属性マークアップリファレンス
[3] ここでCAS-UBで作ったHTMLを埋め込んだWebのページ: Microsoft Office(マイクロソフト オフィス)のファイルを、プログラム開発者が自力でPDFや画像に変換するには、どうしたら良い?

HTMLを簡単に作る方法:h1要素の話(3) WHATWGのHTML5にみるセクションの深さと見出しランク

前回[1]は、W3CのHTML5.1では、セクションの階層の深さと見出しのランクが一致するように変更になったことを説明しました。HTML5についてはWHATWGでも仕様を公開しています[2]。この最新版(Last Updated 12 April 2017)で、セクション階層と見出しのランクについてどのように記述されているかを調べてみました。

WHATWGの仕様説明

4.3.3 The section elementの最初の例では、トップレベルの見出し(A)、第二階層(sectionで囲まれている)の見出し(B、C)はh1です。

<article>
 <hgroup>
  <h1>A</h1>
  <h2>…</h2>
 </hgroup>
 <p>…</p>
 <section>
  <h1>B</h1>
  <p>…</p>
 </section>
 <section>
  <h1>C</h1>
  <p>…</p>
 </section>
</article>

この例説明には、セクションがトップレベルか、第二階層か、第三階層かを気にすることなく、h1タグを使うことができるとなっています。前回調べたW3CのHTML5.1とは考え方が相反しています。

4.3.6 The h1, h2, h3, h4, h5, and h6 elements
h1~h6が見出しのランクを意味すると説明されています(W3Cと同じです)。アウトラインについては、見出しランクによる暗黙の階層のレベルとセクションによる階層と両者を混用したものが同じである、ということです。

<body>
 <h1>A</h1>
  <h2>B</h2>
  <h2>C</h2>
  <h2>D</h2>
   <h3>E</h3>
  <h2>F</h2>
</body>

<body>
 <h1>A</h1>
 <section>
  <h1>B</h1>
 </section>
 <section>
  <h1>C</h1>
 </section>
 <section>
  <h1>D</h1>
  <section>
   <h1>E</h1>
  </section>
 </section>
 <section>
  <h1>F</h1>
 </section>
</body>

<body>
 <h1>A</h1>
 <section>
  <h2>B</h2>
 </section>
 <section>
  <h2>C</h2>
 </section>
 <section>
  <h2>D</h2>
  <section>
   <h3>E</h3>
  </section>
 </section>
 <section>
  <h2>F</h2>
 </section>
</body>

このあたりは、W3CのHTML5のままになっていると言えます。

4.3.11 Headings and sections には次のような記述があります。

“The first element of heading content in an element of sectioning content represents the heading for that section. Subsequent headings of equal or higher rank start new (implied) sections, headings of lower rank start implied subsections that are part of the previous one.”

(日本語訳)[3]より引用
「セクショニングコンテンツの要素においてヘディングコンテンツの最初の要素は、そのセクションの見出しを表す。同等以上のランクに属する後続の見出しは、新しい(暗黙の)セクションを開始し、低いランクの見出しは、前のセクションの一部である暗黙のサブセクションを開始する。どちらの場合も、要素は暗黙のセクションの見出しを表す。」

問題点
この説明によれば、単純に考えるとsection要素の先頭に一番ランクの高い見出しを置かなければならないという制約を生み、body(セクションルート)やsection要素の先頭の見出しはh1にリセットされるということを意味します。

つまり、HTML5では

セクション開始
h2中見出し
テキスト
h1大見出し
テキスト
セクション終了

というような見出しの付け方はできないということになりそうです。このような見出しの付け方をすると、HTML5の解釈によるアウトラインは、中見出しが最上位階層、大見出しがその下の階層となります。

う~ん。このような考え方では本のコンテンツを記述するのは難しいかもしれません。それとも、セクション開始の先頭には省略されたh1タグがあって、その次のh2中見出しはh1のサブセクションである。そしてその次のh1はh2の作るサブセクションの親である、という解釈はできるのでしょうか? それができるなら、アウトラインの階層と見出しの階層が一致します。さて、ちょっとやっかいです…

[1] HTMLを簡単に作る方法:h1要素の話(2) HTML5.1 (W3C)では、セクションの深さと見出しのランクは同じとなった
[2] HTML Living Standard
[3] 4.3.11 見出しとセクション

■連載
(1) ワンソースマルチユースの課題:HTMLソースのオーサリング問題を改めて考えてみようと。
(2) HTMLを手軽に作る方法を再検討します。手軽といえば、まずWordでHTMLを作ることが思いつきます。
(3) Word2013のWord文書をHTML形式で保存を試してみる。その問題点は?
(4) HTMLを簡単に作る方法:h1要素の話(1)
(5) HTMLを簡単に作る方法:h1要素の話(2) HTML5.1 (W3C)では、セクションの深さと見出しのランクは同じとなった(前回)
(6) HTMLを簡単に作る方法:h1要素の話(3) WHATWGのHTML5にみるセクションの深さと見出しランク(前回)

HTMLを簡単に作る方法:h1要素の話(2) HTML5.1 (W3C)では、セクションの深さと見出しのランクは同じとなった

前回のブログでは、主にHTMLの見出し要素h1~h6について、W3CのHTML5を対象に見ました。2016年11月勧告のHTML5.1ではこのあたりがかなり変更となっています。今回は、W3CのHTML5.1について見てみます[1]

その前にもう一度用語を整理します。
セクションルート:独自のアウトラインを持つことができる。そして、セクションルートのアウトラインはその祖先のアウトラインには寄与しない。セクションルートには次の要素があります。

・body, blockquote, details, fieldset, figure, td

セクション内容
見出しとフッターの範囲を示します。セクション内容の要素には次があります。

・section, article, aside, nav

h1~h6の見出し要素は、(暗黙またはセクション内容でマークアップされているかに関わらず)セクションの見出しを示します。h1~h6は見出しのランクを示します。ランクによって文書のアウトラインを作ります。section要素はアウトラインを明示化します。次図の左と右では文書のアウトラインは同じです。

アウトラインは、アクセシビリティのための支援ツールなどで見出しの重要度を示すのに使うことができます。

4.3.10. Headings and sections[2]に、セクションと見出しについての詳しい説明があります。この部分がHTML5.1では次のようになりました。

「セクションには、セクションのネストレベルと同じランクの見出しを含むことができる。著者はセクションのネストレベルからみて適切な見出しを付けるべきである。ひとつのセクション内容に複数の見出しを付けて、暗黙のセクション生成に頼るのではなく、明示的にセクションを包むことを推奨する。」

HTML5では、各section要素の最初に<h1>で見出しを置くと分かりやすいという説明がありました。この他の幾つかのサンプルと共に、敢えなく沈没してしまいました。

そうすると、最初の話に戻りますが、Wordの見出しレベル1の扱いが問題になります。Wordのスタイル機能「見出し1」を使って文書を作成して、HTMLで保存すると、HTMLの構造は次の図の右のようになります。

これは、そのままではHTML5.1の4.3.10. Headings and sectionsに書かれた内容に準拠とはならないかもしれません。

例えば、次の図のようなケースはどうなるのでしょうか?

左と右が同じであることは分かります。h1の次にh2が出てくれば、新しいサブセクションが開始されるからです。では、h1の次にh1がでてきたとき、h2の次にh1が出てきたときはどうなるんでしょうか? 4.3.10. Headings and sectionsによれば、いずれのケースでも新しいセクションが始まることになります。新しいセクションはbodyと同ランクですので、bodyが暗黙に分割されると考えられます。HTML5ではこのことが、サンプルとともに文章として書かれていました[3]。しかし、HTML5.1でこのサンプルは削除されてしまいました。

セクション化の闇は深い?

次は、WHATWAGの仕様をチェックしてみたいと思います[4]

[1] HTML 5.1 W3C Recommendation, 1 November 2016
[2] 4.3.10. Headings and sections
[3] HTML5.0 4.3.10.2 Sample outlines
[4] HTML Living Standard — Last Updated 31 March 2017

■連載
(1) ワンソースマルチユースの課題:HTMLソースのオーサリング問題を改めて考えてみようと。
(2) HTMLを手軽に作る方法を再検討します。手軽といえば、まずWordでHTMLを作ることが思いつきます。
(3) Word2013のWord文書をHTML形式で保存を試してみる。その問題点は?
(4) HTMLを簡単に作る方法:h1要素の話(1)(前回)
(5) HTMLを簡単に作る方法:h1要素の話(2) HTML5.1 (W3C)では、セクションの深さと見出しのランクは同じとなった(今回)