ウェブサイトは印刷できるべきだ
Websites Should Be Printable
印刷した文書に書き込みながら読むのが好きな著者が、自分のサイトをCTRL-Pで印刷したら文字が大きすぎ、ヘッダーも見苦しく、リンクは灰色で読めなかった経験から、@media printによるCSS調整を紹介する。印刷時のみ表示・非表示にするクラス、フォントサイズの調整、リンクを黒くする工夫などを共有しつつ、テキスト主体のサイトなら読者が好きな媒体で読めるようにする価値があると説く。
優れたソフトウェアへと続く道は、ソフトウェアエンジニアからユーザーへの親切心によって舗装されている。
HNでの議論
132- beej71
良いHTML構造で印刷もうまくいくようにすることには賛成だし、ナビゲーション要素などを隠すことにも賛成だけど、印刷版でデフォルトのフォントサイズやフォントを変えることにはあまり賛成できない。
どこにもフォントサイズを設定していないシンプルなサイトを作ったら、友人がモバイルでフォントが小さすぎると文句を言った。低解像度の画面を検出してフォントサイズを大きくすべきだろうか？
多くのサイトがまさにそうしているのは知っているが、それは間違っていると感じる。ユーザーは自分のプラットフォームでデフォルトのフォントサイズをコントロールしている。もしすでに大きくしていたら、私がさらに大きくしているだけになってしまう。
もしデフォルトの印刷フォントサイズを小さくしていたら、私がさらに縮小してしまう。
そういうのは完全にユーザーに任せるのが一番だと思う。
- pidgeon_lover
ウェブサイトは印刷できるべきだという意見に賛成だ。私はRSSとeInkディスプレイ（Kindle、そして買えるようになったらPCモニター）のファンで、印刷可能なウェブサイトは紙のようなディスプレイでの利用を容易にするだろう。
何年もPrintFriendly [1] ブラウザ拡張機能を使ってきた（そうでなければ印刷できないウェブサイトを印刷するため）が、悪化してきたので、代替を探し始めた。The Printliminator [2]（Haartija CSSフレームワーク [3] を使用）から始め、現在はCopyAsMarkdown [4]（Pandocと併用）とWebToEpub [5] を使うに至っている。
[1] https://www.printfriendly.com/
[2] https://github.com/CSS-Tricks/The-Printliminator
[3] https://github.com/vladocar/Hartija---CSS-Print-Framework
- armcat
失礼ながら反対だ。Tim Berners Leeの当初の意図 [1] は、文書や情報を見つけるためのナビゲート可能な方法を作ることであって、印刷可能にすることではなかった。今日の課題全体は、ナビゲート可能な概念と印刷可能な概念の両方を曖昧にしてしまったことにある。ウェブサイトは、意図した情報を簡単にナビゲートして伝えるためのシンプルでクリーンな空間であるべきだ。印刷にはlatexやその他のマークアップ手法があり、それらは印刷に完璧だ。
- swiftcoder
笑っちゃうのは、この特定のウェブサイトでCMD-Pを押すと、4ページになってしまうことだ。最初のページは80%空白、2ページ目はかなり良い、3ページ目はCSSコードサンプルだけが左側の細い帯として含まれ、最後のページはまたほとんど空白だ…
私も似たようなことを試したが、履歴書[1]をフォーマットするためだけだった。多くの雇用主がPDFで提出することを要求しているからだ。
- lopsotronic
ブラウザベンダーと話して、CSS L3 PMM[1]仕様を組み込んでもらうべきだ。この仕様はドラフトのままだ… ええと、ここを見てみよう… おや、なんと、20年だ。
CSS PMMがブラウザに入った瞬間、いやミリ秒で、PDFエコシステムは消滅する[2]と保証する。
それはさておき、核心に戻ると、HTMLをページベースのUXに制限するには遅すぎる。少なくとも10年前から、「ブラウザ」はかつてクライアントサーバーコンピューティングと呼んでいたもの、そして一種のジャストインタイムソフトウェア開発のための、ちょっとひどいサンドボックスになっている。しかしソフトウェア、ソフトウェアを書くということは、言語、自然言語、つまり文書で使うような言語とは正反対だ。だから一方を「形式」言語と呼び、もう一方を「自然」言語と呼ぶ。この二つのインターフェース、それらを同じものにしようとすることが、尽きることのない苦しみの宝庫なのだ。
これは、条件分岐やトランスクルード[3]のような複雑なマークアップ構造が自然言語、すなわち文書と刃を交えるところに見られる。これが、これまで作られたすべてのWYSIWYG「紙そっくり」XMLエディタがひどくダメな大きな理由だ。開発者がみんな馬鹿だからではない。多くの開発者を知っているが、彼らは私が知る中で最も賢く、最も狡猾な開発者たちだ。彼らが取り組んでいるのが、概念的に不可能な課題なのだ。
[1] Paged Media Module
[2] まあ、高級印刷生産、光沢印刷、役員向けホワイトペーパー以外のどこでも。しかしそこでも、私は[…]
- jillesvangurp
印刷に関連するCSSの問題をデバッグするのはちょっとしたPITAかもしれない。フルスタックページで動的コンテンツの印刷オプションを追加するのは技術的にはそれほど難しくない。しかし見栄えを良くするのは少し気難しい。印刷されたらどう見えるかを気にしなければ簡単だ。しかし気にするなら、少し考慮が必要だ。
CSSとJavaScriptだけでラベルプリンタ用のラベルを生成するアプリケーションで、いくつかカスタムなことをした。それほど難しくはない。しかし、ネイティブの印刷ダイアログとブラウザ固有の印刷ダイアログ（およびその印刷プレビュー）、ネイティブのプリンタ設定とそのスケーリングオプションとの機能の相互作用、ブラウザが印刷文書にフッターを追加すること、レイアウトの問題、ページサイズ、マージンなどに関する一般的な奇妙さに対処する必要がある。
これに対処しての一般的な感想は、印刷用のCSSはブラウザ開発者による通常のCSSよりもはるかに精査が少ないということだ。
できるハックの一つは、印刷専用のDOMツリーを生成することだ。DOMツリーのルートをそれに置き換え、印刷をトリガーし、その後古いDOMツリー（フルスタックアプリケーションなどすべて）を戻す。そうするのは非常にハッキーに思える。しかし、ある程度は機能し、十分にシンプルだ。そして利点は、アプリケーションの残り（おそらく印刷をまったく考慮していない）を方程式から外し、印刷レイアウトに干渉するのを防ぐことだ。概念的には、[…]
- bigblind
正直に言うと、これは優先順位のかなり低いもののように感じる。時間が限られているなら、オンスクリーンのUXとアクセシビリティにもっと焦点を当てたい。印刷可能にすることは特定の文脈では意味があると思うし、チケットや請求書などで行われるPDF生成の多くを実際に置き換えられると思う。
- pmlnr
おお、なんてナイーブなprint.cssなんだ。
メディアをリサイズしてすべてを占領しないようにすること、特定の要素が分割されないようにすること、必要に応じて折り返すこと、リンクを印刷すること（原文ママ）などが欠けている。
後者は、インラインリンクではなく脚注にリンクを移動した理由でもある。読書の流れを途切れさせないためでもある。
また、ページカウンターを追加するのは事実上不可能だ。
いずれにせよ、良いアイデアだと思うが、主にアーカイブ目的だ。本当にアーカイブコピーが欲しいなら、印刷する必要がある。