PowerCMS X ブログ

2021-10-28

テーマ / ビューの開発で CSS PreProcessorを利用する

PowerCMS X ver.3.0で新しく追加された CSSPreprocessor プラグインはテーマやビューを CSS PreProcessor ( Sass / SCSS、Less、Stylus ) を利用してコンパイルできるようにするプラグインです。新しくなったテーマの機能、ファイルへのリンク、GitHubとの連携などをとあわせてフロントエンド開発を支援します。

CSS preprocessor (CSS プリプロセッサー) - MDN Web Docs 別ウィンドウで開きます

CSS プリプロセッサー は、プリプロセッサー独自の 構文 で CSS を生成するプログラムです。 CSS プリプロセッサーには多くの種類がありますが、ほとんどの CSS プリプロセッサーは、純粋な CSS には無い、ミックスイン、セレクターの入れ子、セレクターの継承などの機能を追加しています。これらの機能によって、 CSS の可読性や保守性が向上します。

CSSPreprocessor プラグインを利用した CSSへのコンパイルは  1. CSSファイルをパブリッシュする時にビュー全体を自動でビルドする方法と、2. ブロックタグで囲った部分をビルドする方法との二通りがあります。

CSSファイルのパブリッシュ時にビューを自動でビルドする

CSSPreprocessor プラグインが有効な時にスコープのプラグイン設定で「自動コンパイル」にチェックを入れます。「CSSをコード圧縮する」にチェックを入れると、コンパイル後のCSSをMinifyして圧縮(プレビュー時を除く)します。

CSSPreprocessorの設定画面

自動で圧縮される条件は以下の通りです(ファイルへのリンクが必要となります)。

  • ファイルへのリンクが指定されており、リンクするファイルの拡張子が「.sass」「.scss」「.styl」「.less」のいずれかであること
  • URLマップの出力ファイル名の拡張子が「.css」であること

この2つが揃った時、静的ファイルのパブリッシュ時に CSS PreProcessor がビューをコンパイルします。

テーマを利用してソースを管理する

テーマを利用することでGitHubとの連携ができるようになり便利です。開発環境で作成したコードをそのまま管理画面からGitHubを介してステージングや本番に適用することができます。

以下に例を上げます。PowerCMS X ver.3.0からテーマにサブディレクトリが作成できるようになりましたので、「テーマID/views/scss/」ディレクトリを作成して、そこに SCSSのファイルを集約します。

この時、「basic.scss」以外の ( インクルード用の ) ファイルは管理画面で編集しないのであればテーマ( theme.json の views ) に含めなくても構いません。単にテーマディレクトリにファイルとして置いておくことで @use などを使ってコンパイル時に展開することができます。「単に置いておく」のがポイントです。

theme-test (root)
 ├ theme.json (定義ファイル)
 └ views/ (ビューのソーステキスト)
    ├ index.html
    └ scss/
        ├ basic.scss
        ├ _base.scss
        ├ _modules.scss
        └ core/
            └ _utility.scss

テーマを適用します。ビュー「basic.scss」のファイルへのリンクは「%t/scss/basic.scss」となります。

ビューに対するURLマップは「css/basic.css」とします。ファイルへのリンクが「.scss」URLマップが「.css」と拡張子が異なるので注意してください。

css/basic.cssのビュー

@use "base";
@use "modules";

この例では _base.scss と _modules.scss を @use するだけのビューとなります。_base.scss と _modules.scss をビューに含めれば管理画面から更新することができます。そうでない場合は、エディタなどでテーマフォルダの中のファイルを編集します。

プレビューやパブリッシュすると、コンパイルされたものが画面出力・ファイル出力されます。コード圧縮設定をしている時でも、プレビュー画面では Minifyされず、ファイル出力時にのみコード圧縮されます。

尚、利用される Sassのエンジンはサーバーにインストールされているものが利用されます。Dart Sass (推奨) の場合は @use が利用でき、Ruby Sass の時は @import となります。

プレビュー画面ではコンパイル済みのソースが確認できる

ブロックタグを指定してブロック内をビルドする

もっと手軽に利用するには、ブロックタグ mt:csspreprocessor を利用できます。ブロックで囲った部分をビルドできます。

タグ属性「type」にSass、SCSS、Less、Stylus(大文字小文字は吸収されます)のいずれかを指定し、Minifyする場合は compress属性を指定します。

<mt:csspreprocessor type="sass" compress>
$blue: #3bbfce
.border
    border-color: $blue
</mt:csspreprocessor>
<mt:csspreprocessor type="scss" compress>
$blue: #3bbfce;
.border {
    border-color: $blue;
}
</mt:csspreprocessor>
<mt:csspreprocessor type="less" compress>
@border-color: #3bbfce;
.border {
  border-color: @border-color;
}
</mt:csspreprocessor>
<mt:csspreprocessor type="stylus" compress>
base-color = #3bbfce
.border
  border-color base-color 
</mt:csspreprocessor>

変数にはもちろん テンプレート・タグを使うこともできますが、見通しを良くするためには CSS Preprocessor の作法や各々の会社やプロジェクトのガイドラインに沿った記述を行うのが良いかと思います。

カテゴリー:技術情報 | テンプレート作成Tips | プラグイン | サイト制作全般

投稿者:Junnama Noda

2021-10-22

やさにちウォッチのルビ(ruby - ふりがな)のスタイル

ここ数日「ルビ」に関するいくつかのニュースが出ていました。私たちは「やさにちウォッチ 別ウィンドウで開きます」というやさしい日本語についてのオウンドメディアを運営していて、PowerCMS X / PowerCMSにはエディタにルビを振る機能を付けていて、Webサイトに自動でルビをつける Webサービス「伝えるウェブ 別ウィンドウで開きます」を運営しています。ということもあり、では、やさにちウォッチのルビの実装はどうなっているのかを確認しつつ、今日の午前中に CSSを少し調整してみました。

※ 画面下部 (ソースの末尾) のセレクタからこのページにルビを付けることができます。

セミナーでも取り上げられていたいくつかの課題について、すべて現状で解決できるわけではありませんが、ある程度のことは解決できます(この記事についてはEPUBではなく、Webの話です)。

やさにちウォッチの画面

課題と解決したい問題

  • 親文字(rb要素)とルビ(rt要素)が近すぎて読みにくい問題
  • ルビが小さすぎて読みにくい問題
  • 行を折り返した時にルビが上の行と近すぎるとどちらに対するルビなのかがわかりにくい問題
  • スクリーンリーダーなどでの読み上げが不自然になる問題

親文字(rb要素)とルビ(rt要素)が近すぎて読みにくい問題

最初の課題はこれです。基本的には、行間を開けることで適度な距離が空き、読みさすさが向上します。

ruby {
    line-height: 2.8em;
}

ところが、Chromeなどのブラウザでは相変わらず近いままです。CSSで位置調整をしようとしてもブラウザによってCSSの適用結果が異なり、一部のブラウザでは位置調整のための指定をしても効いてくれません。Firefoxでは適度な距離が開くのですが、Chrome / Edge / Safariなどでは近いままです。

CSSのプロパティtransformを利用する

Chrome / Edge / Safariでは rt 要素に transformプロパティを指定することでルビの位置を変えることができます。ルビが小さすぎて読めない問題もあわせて解決するために、以下のようにしました。ただし、Chrome / Edgeと Safari では、距離の空き方が微妙に違います(Chrome / Edgeのほうが距離が近い)。

rt {
    transform: translateY(-.06rem);
    font-size: 70%;
}

行を折り返した時にルビが上の行と近すぎるとどちらに対するルビなのかがわかりにくい問題

どういうことかというと、transformプロパティで距離を開けすぎると、行間が足りなければ上の行と被ってしまったり、被らないまでも上の行に極端に近くなって、いったいどちらのテキストに対するルビなのかがわかりにくくなってしまうのです。

前の行のテキストのほうが近く、わかりにくい

この件についてやっかいなのは、iOSのSafari (どちらが正しいかは別として) などで、行間を開けたバランスと、ルビの距離のバランスが悪く、距離を開けすぎると上の行と近くなってしまい、その対策で行間を開けすぎると他のブラウザで行間が空きすぎてしまいます。

この問題に対しては(本当はやりたくなかったのですが)「transformプロパティはSafariにあわせて指定、Chrome / Edge は jQueryで調整」としました。

var userAgent = window.navigator.userAgent;
if ( userAgent.indexOf('Chrome') != -1 ) {
  $('rt').css('transform', 'translateY(-.4rem)');
}

スクリーンリーダーなどでの読み上げが不自然になる問題

この問題については、このサイトの立ち上げ時から意識していて、画面の上部に「ふりがな」「わかちがき」ボタンを付けておき、Cookieをセットして状態を保てるようにしています。jQueryで body にhide--furiganaクラスを追加して、display :none しているだけです。VoiceOverで意図した読み上げにされることを確認しました。とはいえ、あくまでも rt要素を隠しているだけなので、rt要素に異なる読みを指定していても読み上げには反映されません。

ふりがなと分かち書きのON/OFFボタン

body.hide--furigana rt {
    display: none !important;
}
body.hide--furigana ruby {
   line-height: 1.5 !important;
}

※ ruby要素だけに line-height 指定をすると、ルビを含まない行の行間が不自然になるので、実際はルビが使われる部分を囲っているブロックに line-heightを設定しています。

最終的なルビのスタイルについては、サイトをぜひご覧ください。また、お気づきの点などがあればお気軽にご指摘・お問い合わせください 別ウィンドウで開きます

解決されていない問題

CSSやJavaScriptによる「ハック」のようなもので、将来のブラウザの実装や対応状況によって結果が変わってしまうといういわゆる「堅牢性・互換性」に問題があるのは別にして、解決されていない問題としては以下のようなものがあります。

  • ブラウザ内のテキスト検索 (ふりがなボタンでルビを削除しても検索されません)
  • 読み上げは不自然にはならないものの、指定したルビが読み上げに反映されない
  • モノルビ、グループルビ問題、熟語問題、改行問題

検索エンジン・SEO問題

その他に、Googleなどの検索エンジン問題があると思われます。ルビを付けることが SEOに悪影響があるかもしれないとなると、そもそも Webにおけるルビの普及を妨げる要因になりかねません。

Google検索結果ではルビを除外して文章を解釈しているようには見えない

余談 : Amazon Polly のSSML

「伝えるウェブ」で提供している、Webページ読み上げには Amazon Polly 別ウィンドウで開きます を利用しています。辞書に登録されている語が読み上げるテキストに含まれている時、SSMLで読み方を渡せるようにしています(設定でOn/Offを指定できる)。

Pollyは非常に自然なイントネーションで上手く日本語のテキストを読み上げてくれます。ただ、以下のような渡し方だと、登録した辞書と読み上げ方は完全に一致するものの、読み上げのイントネーションは非常に不自然になります(11月17日追記 : subではなく、phonemeを使うと不自然さは回避できます)。イントネーションをあわせて指定しなければならないのですが、Pollyが解釈したオリジナルの漢字の読み方とわたされたひらがなが一致する場合はオリジナルのテキストを利用するなどしてくれるようになると、指定も煩雑ではなくなり、品質も上がることが期待されます。

<speak xml:lang="ja-JP">
<prosody rate="default" pitch="default">
<sub alias="つたえるうぇぶ">伝えるウェブ</sub>は「やさしい<sub alias="にほんご">日本語</sub>」での<sub alias="じょうほう">情報</sub><sub alias="はっしん">発信</sub>を<sub alias="しえん">支援</sub>します。
</prosody></speak>

phonemeタグを利用して自然な読み上げを実現する例

<speak xml:lang="ja-JP">
<prosody rate="default" pitch="default">
<phoneme type="ruby" ph="なんば">難波</phoneme>の次の駅は<phoneme type="ruby" ph="にっぽんばし">日本橋</phoneme>です。
</prosody></speak>

カテゴリー:サイト制作全般

投稿者:Junnama Noda

2021-10-20

新しくなったテーマ管理とGitHub連携

ver.3.0からテーマをGitHub 別ウィンドウで開きます で管理し、管理画面から簡単に適用できるようになりました。以下の記事の続きです。

関連リンク

PowerCMS XからGitHubにテーマをプッシュする

「ThemeGitHub」プラグインを利用すると、開発環境などで更新したテーマをそのまま管理画面からGitHubにプッシュすることができるようになります。以下にテーマ管理の利用方法の例をご紹介します。

開発環境からGitHubを経由して本番へ適用するフロー

  • 開発環境と本番環境を別にしている
  • 開発環境でデザインなどのカスタマイズを行い、任意のタイミングでGitHubにプッシュ
  • 本番環境でGitHubからテーマを反映して適用する

もちろん、間にステージング環境を挟むなどの運用も可能です。

準備

環境変数「theme_paths」でテーマの保存場所を設定する

初期状態ではデフォルトのテーマディレクトリにはファイルを書き込むことができません。別に theme_paths を指定して、そこにテーマを設置するようにします。

"theme_paths" : ["/var/www/PowerCMSX/customized_files/themes"],

GitHubにリポジトリを作成し、theme.json にリポジトリを指定する

GitHubにリポジトリを作成し、そのURLをtheme.jsonの "repository"に指定します(theme.jsonはサブフォルダではなくリポジトリの直下に配置されるようにしてください)。publicリポジトリでもprivateリポジトリのどちらでも構いません。privateリポジトリの場合は管理画面から個人トークンを登録する必要があります。手順については以下の記事でも紹介しています。

テーマがすでにある場合はディレクトリに設置、テーマがない場合はビューの一覧からテーマをエクスポートして設置します(または、Skeltonテーマをコピーして一意の名前にリネームして設置してもよいでしょう。その場合は theme.json内のラベルやidもあわせて変更してください)。その後、対象のスコープでテーマを適用してください(本番、開発ともに適用してください)。その後、テーマの管理画面でブランチを選択し、個人トークンを登録してください。

ファイルへのリンクを設定する

テーマの更新は「ファイルへのリンク」機能を利用します。開発環境では環境変数「linked_file」を「1」に指定します。こうすることで、ファイルへのリンクは書き出しのみの一方向となります(開発環境で管理画面からファイルを更新すると、テーマファイルが自動的に更新されます)。

"linked_file" : 1,

ThemeGitHubプラグインを設定する

今回のケースでは、開発環境でのみプラグインを設定・有効化すればよく、本番環境では必要ありません。

knplabs/github-api をインストールします。パスは include_path の配下であればどこでも構いません(autoload.phpのパスを環境変数 composer_autoload に指定します)。

composer require knplabs/github-api:^3.0 guzzlehttp/guzzle:^7.0.1 http-interop/http-factory-guzzle:^1.0

プラグイン用の環境変数を指定します。config.jsonに記述する場合は、Web経由で config.jsonにアクセスできないように制限をかけてください。

  • composer_autoload : composerでインストールしたパスの autoload.phpのパスを指定します。
  • can_open_theme_dir : ローカル環境で PowerCMS Xを動かしている時、テーマの管理画面で現在のテーマディレクトリを開くボタンを追加します。

composer_autoloadのパスは他のプラグインと共通でなければなりません。

プラグイン設定とユーザーごとの設定

プラグインを有効化すると、userモデルに「GitHubアカウント」「GitHub個人トークン」が追加されます。 ユーザーにこれらの設定がある時、コミット時にはこのアカウント/トークンが利用されます。個人の設定がなければプラグイン設定が使われます。
両方ともに指定のない時、スコープのテーマの個人トークンが使われます。

プロフィール編集画面にGitHubアカウントと個人トークンの入力欄が追加されます

プラグイン設定
  • GitHubアカウント : GitHubアカウント名
  • GitHub個人トークン : GitHubの個人トークン(Personal access token)
  • .gitignore : 除外するファイル名のカンマ区切りテキスト
スペースプラグイン設定のみ
  • システム設定を利用する : スペース独自の設定をせずに、システム設定を継承する場合にチェックしてください。

テーマの管理画面からバージョンを変更してGitHubにコミットする

ここまでの設定を行うと、テーマの管理画面の現在選択中のテーマに GitHubにコミット ボタンが追加表示されます。バージョンを編集 アイコンをクリックすると、theme.jsonのバージョンを上げることができます。

テーマの管理画面

 GitHubにコミット ボタンをクリックすると、GitHubデスクトップアプリとよく似た画面が表示されます。対象のファイルを選択して、コミットメッセージを入力して、「'ブランチ名'へコミット」ボタンをクリックすると、テーマが選択中のブランチに対して適用されます。

GitHubデスクトップライクな管理画面

カテゴリー:プラグイン | 技術情報 | サイト制作全般

投稿者:Junnama Noda

ブログ内検索

アーカイブ