OSSと突発deck開発者会議
はい、ということで、趣味でOSSをやっている者だなんですけど、今回特別編ということで、突発deck開発者会議っていうのをやってみようと思います。
まあこれは単に、なんか今ちょっと大流、僕が送りまくってて、ちょっと困ってるプルリクエストみたいなやつについての相談をする場なんですけど、
まあなんかそういうのをザックバランに話して、まあなんかそれが出せそうな内容になったらポッドキャストとして出すし、
まあダメだったらこのまま相談して終わるという感じになります。ということでよろしくお願いします。
よろしくお願いします。本当に本編の方で早めにすぐに反応してリリースするって言ってたんですけど、
ちょっとなかなか自分のスケジュールでうまくいかなかったので、申し訳ないなと思いながら見てました。
いや全然そんなことなくて、多分なんかめちゃくちゃすぐ迅速に出してくれてるから、いやありがたいなーっていうのを思っております。
はい。なんかいくつかあって、まずそのパラグラフ問題、というか僕全然気づいてなかったっていうか、
分かってなかったこととして、結局マークダウンの内容をGoogleスライドに反映できればいいわけではなくて、
Googleスライドの内容をまた抽象化して元に戻せるかっていうのとか、ちゃんと比較できるかみたいなのも担保しないといけないっていうところに難しさがあるっていうのに気づくのにすごいやっぱ時間がかかりました。
そうなんですよね、今それが必要なんですよね。それをしないといけない理由というのが、もともとデックは1から10まで全部適用するみたいなことを、
スライドを1から作り直すみたいな実装、マークダウンとGoogleスライドと同じような実装だったんですけど、それだと遅いというお話を戻って、
確かに遅いよねって話で、そこからだんだん、いかに少なく反映するかという戦いが始まった結果、
Googleスライドの情報とマークダウンの情報をいかに比較するかという問題に帰着するようになってしまっているというのは今ここです。
そうなんですよね。たぶん5秒で1ページぐらい更新できるぐらいの感じですよね。たぶん今の感覚だと、なのかなって思ってたので。
そうですね。遅い。結構遅いと思います。
なので100枚とか、僕最初に作ったスライドは100枚越えみたいなやつを作ってしまったんで、残音に10何分もかかるみたいになって。
でもそれはそうだよなと思って、こんなにバンバンAPI叩かせてくれるGoogleさんありがてえなみたいな、そういう気持ちにもなってます。
しかも無料だしな、いいのかなみたいな感じになりますよね。
結構、そうです。レートリミット引っかかってるんですよね。たぶん5枚か6枚かに1回とか、新規だと結構引っかかる。引っかかると数十秒ペナルティですね。
そうですよね。だからリトライ可能なクライアント使ってたりとか、そういうのもしてるから。
たぶんGoogleのライブラリの方でそういうのをケアしてくれるようになってるみたいな感じですよね。
なので、サブの取り方みたいなのを考えたときに、今のパラグラフの扱いみたいなのがどうなってるのかっていうのをちょっと確認をしたくて、どれから行こうかな。
今、パラグラフが連続するときにうまく段落分けしてくれないみたいなのがあるんですけど、
会場の扱いみたいなのをどういうふうに考えてるのかっていうのが、まず今は気になってるっていうのがあるんですよね。
そうですね。今、現時点においてはかなりレイジーというか、実際にAPIを叩いて、意図したものが出て、その意図したものが変換できそうなものかみたいなところに結構重きを置いていたので、
表現できればいいというふうに倒してるって言ったりですかね。
例えば、マークダウンの構造が正しくGoogleスライドに出ていることではなくて、マークダウンの表現力を使ってGoogleスライドに意図した情報が意図した形になること、
かつ、元に戻せる、比較できそうになることっていうような実装になってます。
そうですよね。で、たぶんこのissueって読みました?あげたばっかで頂戴なんで読んでないくて全然構わないんですけど。
読みました、読みました。分類をどうするかっていう話だと思ってます。
そうですね、そうですね。一般的に開業って3つぐらい、3つっていうか、マークダウンと開業みたいなのが3つぐらいあって、3つぐらい分類したんですけど、
ソフトラインブレークっていうのと、ハードラインブレークってやつと、ブロック要素、パラグラフ区切りっていうのの3つがあるっていうふうに思ってるんですけど、
たぶんこれについて、マークダウンとGoogleスライド間で、ちゃんとインピーダンスミスマッチみたいなのを解消していく必要があるっていうのを思っていますと。
どこまで厳密にマークダウンに従うかっていう話があると思ってるんですけど、今、ハードラインブレークを使ってないっていうのが気になっているっていうのがあって、
すごく厳密に言うと、ソフトラインブレークっていうやつは使われてるんですけど、ソフトラインブレークって、もともとはHTML文書内での開業と同じ扱いなので、
開業はされないじゃないですか。A文の折り返しみたいなのと同じで、一行になるけどスペースが挿入されるっていう、そういうのがありますと。
それとは別にハードラインブレークっていうのがあって、これはパラグラフ内のインラインの開業みたいな、明示的な開業がハードラインブレークで、
これはHTMLで言うBRタグに相当するものですと。ここの扱いみたいなものが今、どうなってるのかなっていうのが気になって。
これが多分、これ結構僕今日調べてて衝撃だったんですけど、Googleスライドとかだと文章とかを入れるときに、普通のエンターの開業とシフトエンターでの開業っていうのがあって。
普通のエンターでの開業がいわゆるパラグラフ区切りと同じ開業で、シフトエンターでの開業がBRに相当するインライン開業なんですけど。
これをこういうスライドを手動で作ったときにAPIを叩いて返ってくるレスポンスを確認したとこ、このインライン開業は垂直タブにバーティカルタブに変換されてるっていう衝撃の事実が今日わかったんですよ。
ちなみに私は知らないです。存じ上げなかったんですけど。
なので、多分これなんかスタックオーバーフローとか見ても、なんかどうもそうらしいっていう。でもドキュメントはされてない仕様なんですよねっていう。
だから多分、インピーダースマッチ的にはBRとかは垂直タブにマッピングすべきで、かつ垂直タブがあったらそれをインライン開業として見出すっていう風にするのが正しいんじゃないのかなっていう風に思ってますっていうのが。
ここまでの話で言うと、まず今現時点のデックはヒューリスティックな形で作ってますっていう話と、見た目しか重視してなかったっていう経緯があるので、ソフトラインブレイクもハードラインブレイクも基本的にただのブレイクみたいな形で何とか同じような見た目にするということを重視して作ってますと。
ブロッククオートの実装
じゃあ、このソフトラインブレイクとハードラインブレイクを今後どうするかっていう意味で言うと、私個人としては、ブレイキングチェンジは十分に許容できる。してもいいと思ってるんですよね。
ただ、やっぱり先ほどの比較の部分にどれだけ寄与できるかっていうのが結構ポイントだと思って、今のと同レベルの比較レベル、今でもですね、パラグラフの比較ってあまりうまくいけてないんですけど、
例えばそれが改善するならば、当然ブレイキングチェンジはウェルカムですし、改善されなくてもほぼ同等であれば、多分こっちの方が正しい実装だと思うので、するべきだろうなと思うというのが、今現時点の私の感想です。
おだしょー ありがとうございます。多分、より厳密な比較はできるようになるんじゃないかなっていうのは思ってますし、表現上も多分ちゃんとしたインライン開業とパラグラフ開業みたいなのの区別ができるようになると思うので、
内部状態としてちゃんとパラグラフはパラグラフとして持って、その中にフラグメンツって多分テックの中だと言われてると思うんですけど、それの情報を正しく持たせることができるのであれば、うまくできると思うし、
多分その今のパラグラフ区切りとのロジックと、今のVRの処理でちょっと多分おかしくなってる部分があるんで、多分うまくできるんじゃないかという気はしています。
おだしょー この謎の仕様を調査してくれていただいただけで、かなりヒューリスティックにやってたものが改善されるっていう気がしてます。
たぶんそうなんですよね。本当にこのエレメントの中に、エレメンツの並びもすごい謎だったんですけど、だいぶAPIを解析して理解をしました、たぶん。なので、たぶんパラグラフ区切りもちゃんと出せるようにできるんじゃないかなという気はしています。
おだしょー これ、パラグラフ勝手につなげたりするんですよね。
たぶんパラグラフ区切りをちゃんと送らないと勝手につながっちゃうみたいなのがあるので、パラグラフ区切りの送り方も結構いけてない。いけてないというか、面白いというか、開業文字を1文字ポーンって送るとパラグラフ区切りになるみたいな感じですよね、確か。
おだしょー そうです。そうなんですね。
たぶんそれ、コード見たとき意図がわからなかったんですけど、APIの仕様と挙動を見て理解して、お、なるほどなみたいな気持ちになりました。
おだしょー はい。つらいですよ、なかなか。
なるほど。でもたぶんマッチのさせ方としては、普通にちゃんとハードラインブレイクって言われるインライン開業はShift Enterの開業とかBRの開業は垂直タブに合わせればよくて、そういうブロック要素とかリストとかパラグラフの開業みたいなものは、ちゃんとブロック要素が次のブロックに遷移するときにパラグラフマーカーを入れてやればいいという形になるので、
たぶんこれで逆に精度が上げられるんじゃないかなっていうのは思いました。
おだしょー なんか特殊なんですよね、これ。まずパラグラフを作って、そこにスタイルを当てた後にバレットっていう呼ばれているアイテム、リストアイテムへの変換をしていくという形を取らないといろんなところが破綻するっていう謎な形なのでそういう実装にしてるんですけど、
その時にいわゆる先ほどのパラグラフなのか、ハードラインブレイクなのかソフトラインブレイクなのかみたいな話が全部なかなか私が思ってたときとは全然できなかったので、結構ヒューリスティックな開業とかが入っているっていうのは今なので、そこが改善できるとかなり熱いと思いますね。
おだしょー じゃあ良かった、多分大丈夫かなと思います。だからそう、結構そのハードラインブレイクサポートしないのって言ったのは多分そういったところにあって、この辺ちゃんとインピーダースミスマッチを合わせらればうまくいくかもしれないっていうこのパラグラフ問題を解決できるんじゃないかっていう気はしています。
おだしょー なので多分今インテグレーションテストも基本的にはその画像の見た目で判定しているので、なのである程度ちゃんとアイテムっぽいとかリストっぽいとかがリストになっている、開業されるべきところと思われているところが開業されているっていうことができれば全然ありだと思いますし、そこにブレイキングチェンジがあるのは全く問題がないと思ってますね。
おだしょー 良かった、良かったです。じゃあちょっとなんか時間があるときに試行錯誤してみようかなと思っています。あとはなんだろうな、ブロッククオートかな。ブロッククオート今なんかすごい頑張って作られてますよね。
おだしょー はい、ブロッククオートはちょっとゆっくりめに作ってるだけですけど、そうです今一生懸命作ってます。
おだしょー 今ってブロッククオートってレンダリングされないですよね。
おだしょー されないです。
おだしょー されなくなったっていう感じですよね。
おだしょー もともとされなかった、当時はされてなかった、あとコードブロックもされてなかったです。
おだしょー コードブロックは拾い上げるようにした、ブロッククオートも実は今使ってるマークダウンのパーサーだとブロッククオートはボディと全くパラパラとまた別のところに分けられるので、それを拾い上げるようにしたっていう認識ですね、多分。
おだしょー そうだったっけ、そうだったかな。
おだしょー いや、もしかしたら途中で、ソムさんもここを改善してくれたじゃないですか、Hタグ、エンディングとか、そこのタイミングでもしかしたら読み込まれるようになったかもしれないです。
ただそれはさらにブロックオートだけ特別化、使い捨てるような実装に変えようとしてます、今。
おだしょー なるほど、なんかもともと普通に字の文として出てきてた気がするけど、最近は出なくなってるなっていうふうに。
おだしょー 最近、それで言うと、このプルリクエスト、ブロックオートのプルリクエストを入れない限りは、あれ、どこかでやっちゃったかもしれないな、ブロックオート。
途中で一部やったかもしれない。あ、わかった、そうですね、消えてしまったかもしれないです。
ブロッククオートの特別扱い
マークダウン側でブロッククオートを特別扱いしたっていうところまでで一旦マージしてしまってるので。
おだしょー そうですよね、この一周ですよね。
マークダウン なので早めに実装してないか。
おだしょー なので僕は今一旦ブロックオートを使わないで資料を作ったりしました。
マークダウン すいません、急ぎます。
おだしょー いや、大丈夫です。
マークダウン 一応、方針とかは全部できていて、後はちまちまやっていくのと、あとは多少のリファクタリングが必要だったので、それをやってますっていう話ですね。
おだしょー なるほど、これってどういう感じになるんですか?
画像にあるブロックじゃなくて、そういう独立したブロックになるみたいな感じ。
マークダウン Googleスライドの中の言葉で言うと、シェイプと呼ばれているものに変わって、そのシェイプのタイプはテキストボックスになります。
なので、Googleスライドで言うとテキストボックスの追加っていうのが多分あると思うんですけど、それが現れますと。
そこまでで、まずブロッククオートが特別扱いされましたので、一つ。
それプラス、スタイルの設定ができると思います。
そっちの方で、シェイプのスタイルを引っ張ってこれるようにして、ブロッククオートにそのスタイルを適用できるようにするっていうのが、もう一つ目の次のプロジェクトになるはずです。
だから、ボディの中に突然ブロッククオートがあったら、ボディのパラグラフの間にブロッククオートがあったら、そのブロッククオートだけ突然別のシェイプとしてはみ出してしまって、
パラグラフA、ブロッククオート、パラグラフBだったらパラグラフABってなってしまって、ブロッククオートだけ外出しされるような形になる想定です。
理由はスタイルのためですね。
ちゃんとブロックごとのスタイルを当てたいからっていう感じですかね。ブロックっていうか、そういうシェイプの中のっていう感じか。
おそらくブロッククオートは、私だったらデザイン的なバックグラウンド背景を灰色にしたいなとかになるんじゃないのかなと思って、この方針にしてるんですけど、
総務省さん的にはどう思いますかね。
僕、それでいいかなって最初は思ったんですけど、やっぱ悩ましいなって思うのは、文の流れのところでブロッククオートを入れたいみたいなのもあるから、それが結構崩れちゃうなっていうのがあって、
ただ今って画像とかも抜き出されて別のシェイプとして置かれるから、それの位置は自由に調整してくださいみたいな、そういうスタンスだと思うので、そこが保たれれば一旦それでいいのかなって思うし、
ただそれでまた差分の計算とかが難しくなる可能性はあるのかなっていうのはそうなんですよ。
ブロッククオートの中で、Googleサイドのテキストボックスのシェイプって普通のプレスフォルダのテキストボックスと一緒なので、
ネストもできるし、インディネートもめっちゃできるし、リストも書けるしっていう状態なので、マークダウンより表現力が高い状態なので、
あまりにも複雑なブロッククオートを書くと、それなりに大変になる、比較が大変になるっていう感じですね。
でもそんな疲れ方しないからいいんじゃないのかなとは思ってますが、
ブロッククオートが別シェイプにならないとした場合、ブロッククオートにまともなスタイルを当てることができないんですよ。
それどう思われますかっていうところがあって、まともなスタイルを当てたいんじゃないのかなと思ったんですよ。
そうですよね。でも一応文字色とか文字幅とか、そういう一般的なインラインスタイルは当てられますよね。
当てられます。
ただそこまでだっていう話ですね。
そうです。だから背景色を灰色にしたらできなくて、文字のバックグラウンドだけが灰色になるのでシマシマになるんですよ。
そうですね、そのラインだけが。
ではないんじゃないのかなと受け取ってね。
それでも言っちゃいいという説もある。
なるほど。
それでイタリックにするぐらいでも言っちゃいいという説はある。
そこなんですよね。そこがまだ私読み切れてなくて、私の感覚だと灰色にしたいとか、ごそっとなんか違うものにしたいみたいな感覚があるから、
配置は別にいいやみたいな感覚の人なのでなんですけど。
なるほど。それで十分な人もいるのか。
十分な説もあるし、流れとして。
陰陽って2種類あると思ってて、たぶんそういうスライドの中の補足的にやる陰陽と、
陰陽だけでバーンて置くスライドみたいなのがあると思ってて、
でも陰陽だけバーンて置くスライドだったら逆にそれはそれでそれ用のスタイルが1個あればいいという説もあるかなっていうのを今。
なるほど。難しいなあ。
ブロッククオートって、インラインクオートってあるんすけ?
インラインクオートが旧要素ですね。旧要素。
なるほどなあ。
だから僕旧要素とサイトが欲しいって言ってるんですよ。
旧要素があったらブロッククオートはブロックで外出しするべきなんですかね。
でも別にそれは、パラグラフと同等のたぶん、HTMLなりセマンティックス上はそういう存在なので、
今その一つのボディの中に、ボディっていうのは概念的なボディっていうかシェイプの中に複数のパラグラフを持つことはできるわけなので、
そのデックの考え方として、そういう意味では別に、
なんていうか、そのボディ、デックボディの中に複数、一つのパラグラフとして表現されてても不自然ではないかなとは思いますね。
文章構造的には当然書かれた順番なんですけど、どうしてもやっぱデザイン上で言うと、
なんかブロッククオートは結構分かれる、インラインではないから、コードブロックと同等かなと思ってるんですよね。
今のところだから、シェイプとして吐き出される形を今のところ想定していていますね。
まあそれで配置を調整してくれって感じで考えてるって感じですね。
そうですね、今のところそうです。
わかりました。まあちょっとそれで作ってみて、作っていただいて、なんか動作をさせるのを楽しみにしています。
オートマティックレイアウトの議論
じゃあ、そんなとこかな。一番重いやつの話をしますか。一番重いやつ。
つまり一番重いやつの話をしますか。
オートマティックレイアウト。
そう、オートマティックレイアウトアサインメント。
これはある程度スライドの内の情報構造をもとにレイアウトが自動導出されてほしいっていう、僕の強い要望でやってるやつなんですけど、
まあなんかそこの、まあそういうのをやってもいいかもねって話にはなりつつあるんですが、
じゃあどういう設定をさせるのがいいかっていうので結構議論が紛糾してるっていう感じですね。
そうですね。難しいかなっていうところで、
今の私がいろいろこの議論の中で、結構私の中の考えは2点ぐらいしてるんですけど、
今現時点においては、もともと桑本さんにも言われたテックのキーコンセプトであるコンテンツとデザインを分離するっていう風に考えたときに、
デザインはGoogleスライド側かなっていうスタンスがありますと。
それができればできたに越したことがないっていう意味ですね。
それと別で、じゃあ今回の自動レイアウトっていうのはどういう位置づけなのかなって考えたときには、
レイアウトは何なのかっていうと、私の中ではCSSのクラス設定でそれにデザインが当たってるみたいなイメージを持っていますと。
今回のレイアウトの自動設定は言ってみればCSSのクラスを自動で設定できる仕組みみたいなイメージで考えているので、
さっきも言ったように、デザインはGoogleスライド側に設定があった方がいいと思っています。
その心はなんですけど、オートマティックなレイアウトの設定はデザインテンプレートの領域にあるべきじゃないかなと思ったときに、
マークダウンを新しく作成して、スライドのテンプレートっていうかテーマを当てたら、
オートマティックの設定もこっきり言わずにそのまま動くべきかなと思っているので、
今のところGoogleスライド側にあればいいなっていうところで頭が止まっている感じです。
それをどう作るかっていうのはまた別の話ですけど、今のところそこまでっていう感じで考えています。
ということはあれか、今あるレイアウトスタイルスライドみたいなやつをGoogleスライドの方に持てると良いんじゃないかっていう、そういう感じですか。
そうです。例えばここでまたもう一つ難しい話が、Googleスライドとマークダウンの間にバーチャルスライド的なもので、
ソムさんと私で分かる言葉で言うとスライド構造体がありますと。
スライド構造体とマークダウンの間で失われる情報、今のところ失われる情報としては、
ヘディングのレベルが失われますと、今のところですね。
なのでソムさんがやりたいことは、もしかしたら今のソムさんがやりたいことっていうのは簡単に説明すると、
ヘディングレベル1から始まるもののレイアウト、ページのレイアウトと2から始まるもののレイアウトと3から始まるもののレイアウトみたいなのを
カジュアルに変えられる設定があると良いなっていう話だと思っているんですけど、
そこの、例えばですけど、その要素を失わせずにGoogleスライドに持っていくことができたら、
Googleスライドのテーマの中のレイアウトの名前に、例えばH1スタートみたいなのが付いていれば、みたいな形で自動設定ができるのではないか。
それがミニマムとして作れるのではないかっていうのが、Googleスライド側に置くという設定の一例ですかね。
そうですよね。それは思います。
ただなんかそれすごく複雑になっちゃうよなっていうのと、もう既にスタイルをスライド内に書かせるっていうことをしているので、
それをいちいち書くよりかは、多分ちゃんとある程度統合的に設定できた方が、スライド全体のデザインの一貫性みたいなのは保たれるから、
余計そういう文章、マークダウンを作る上では文章構造みたいなのを意識してデータをしっかり作っておけば、
自然といい感じにデザインが当たるっていう感じにはできるよなっていうのはそう思ってはいるんですよね。
あとなんかその上で、多分あんまり設定できるものを増やしすぎない方がいいっていうふうに思っていて、
多分、H1で本文があるものとか本文がないものとか、そういう話になってくると結局掛け算で組み合わせ爆発しちゃうんで、
多分そういう情報構造を決める上でのいくつかのディメンション、次元があって、それがページの位置であるとか、あとはヘッディングレベルだったりとか、
サブタイトルがいくつあるかとか、パラグラフがいくつあるかとか、画像があるかコードブロックがあるかクオートがあるかみたいな、
そういういくつかの次元があって、例えばH2だけの要素だったらヘッディングレベルがH2でサブタイトルがなくて、ボディがないものっていうふうに表現ができるし、
みたいになるんですけど、多分そういう任意の組み合わせみたいなのを表現するキーみたいなのを作ってしまうと、
多分組み合わせ爆発が起きちゃうし、これとこれとこれもやりたいみたいな話が出てきちゃうから、
僕としてはこの中で一番大事なディメンションっていうのはヘッディングレベルだから、それに応じたスライドが設定できればよくて、
それに加えた細かいカスタマイズは今ちゃんとインラインで指定できるんだから、それでやってくれっていうふうにするのがいいんじゃないのって思ってるっていうのがあるっていう感じですね。
ヘッディングレベルの重要性
今までの話で多分2つのお話があって、設定はマークダウンのフロントマッターに書くべきか、
Googleスライドであるべきかっていう話がこのプロジェクトの中ではあって、もう一つが設定キーみたいなものはヘッディングレベルで止めるべきか、
プラスカスタムかヘッディングレベルでは止めないべきなのかみたいな話があるのかなと思うんですけど、
あってますかね、ここまでは。
あってますね、あってます。
で、難しいポイントとしては、一番重要なのがヘッディングレベルなのかっていうのに、多分まだ私とソムさんで差異がある気がしてる。
ここを解決できないと、私は今思っている。なぜなら、私のスタイルとソムさんのスタイルが違うから。
スライド作りのスタイルが違うから。
そうですね、スライド作りのそうですね。別の第三者が出てきたら、その人も違うはず。
となってくると、ソムさんはちょっとDSLどうかなと、良くないかなと思ってるって話もあったんですけど、私DSL好きなので、
いっそのことそれなのかとか思ってしまうことがあると。
つまり誰も優遇しない。
もしくは、ソムさんの主張しているヘッディングレベルのみが重要だ、を折れてもらう。
で、他のレベルのキーをある程度つける。
DSLの複雑さ
っていうところで、たださっき言ったように、紛糾するでしょって話がある。それはその通りだと思ってるので、
そうすると今のところ私はこのDSL好きの私としては、もう全部DSLに倒してしまえば誰も文句はないっていう気持ちになってるっていうのが今ここですね。
いやーDSLむずいんじゃないかなーって、複雑すぎて使われないっていう。
あーそうですねそうですね。それは思いますね。
しかも、コピペをするんじゃないかなと思います。
コピペはね、あとそのなんだろうな、
例えばH1をボディだけにしたい。
むしろスライドの作り方によって。
例えばH1はボディがない。H2はパラグラフが1個である。
ボディが1個である。
例えばH3はパラグラフ、ボディが2つであるみたいな。
そういうのってもうスライドのスタイルで決まってくると思うんですよ。
むしろそこって色数を増やすみたいなことは普通はすると思うんだけど、
基本的にはH1だったらこういうスタイル。H2だったら本文はある。
例えば僕の場合だとH1は本文がなくて、H2は本文があって、H3は本文があるみたいな。
そういうスライドの作り方、一貫性を持たせるために、
別にH2だけのスライドとH2とボディがあるスライドみたいなのを同時に欲しいとは思わないんですよね。
そういうのが欲しいときは個別に設定すればいいじゃんっていうふうに思うっていう。
たぶんスタイルの違いの話なんですけど、
普通にこういうちゃんと構造化されたスライドってよく見るし、
こういうふうにちゃんとなってるほうが気持ちがいいと思うんですよねっていう。
わかるんですよね。わかるんですが、例えばですけどH2タグのみのセクションの部分とH2とボディがあるところ。
あと一方でもっと大きいセクションだからH1だけのスライドとH1とボディのスライドみたいなことが、
例えば私のスタイルだとないとは言えないので、そこのスタイルの差の吸収が難しいときにどうしたもんかなっていうところですね。
だからネームスペースとしてもH1というものを作ってしまうと、それは一体何を表すのかっていうのは人によると思ってて、
私だったらH1だけがあるページになってしまうんですよね。
なるほどね。
なので、そこをどうしたものかなっていう感じで、でも一人が来たら、違うスタイルのもう一人が来たら、もっとヤバいことになるのかなって思ってるっていう。
そうですね。もっとヤバいことにはなるから、すごい綺麗なDSLをバチって作るか、
やっぱどっかの次元に区切って、そういうヘッディングレベルにして、
ヘッディングレベル、僕の主張はずっとゴリ押しみたいで一貫してるんですけど、
ヘッディングレベルにして、その中でスタイルを変えたいんだったら、じゃあ個別にスタイルを当てることが有利にできるからそれでいいじゃんっていうレイアウトっていう、そういう主張になってるっていう感じですね。
そうですね。で、私が、そのDSLは置いて、DSLですね。ちなみにDSLどう作ろうかと思ってるかっていうと、
私が好んで使っている内部言語であるEXPRラングっていう、乱Nとかオクトコブとかテープとか全部組み込んでるあの言語を組み込めば、
多分破綻は一切なくできる。プラス、もしくはセル言語ですね。SESLライン語どっちかを採用しようかなと思ってました。
で、今回は面白いからという理由で、Googleだからという理由でセル言語を突っ込んでみようかなとか思ってたんですね。
なるほどね。なるほど。
だから言語を突っ込むレベルなので、絶対に多分破綻はないです。
セルを突っ込むのは面白そうですね。
ただ書きにくいというか、書く人が少なくなる可能性っていうのはある。
で、プラス、さっきの話なんですけど、難しいんですけど、H1、今のソムさんの言葉でいうH1、H1タグから始まるページ。
から始まるっていうか、H1がプライマリーヘッダーである。
H1がプライマリーヘッダーである。
そうそう、別にH2、H1ってなることもあるかもしれないけど、ページ内では。
でもそのスライド内で一番のトップレベルの浅いレベルのヘッダーってことですね。
で、それをセル言語で組み込めるんですよ、実は。変数として。
つまり、よく使うキーは変数としても、アタイ、トゥルーかフォルスを入れてしまって、突っ込むことができます。
で、ここからが難しくて、それここまでは面白いと思っていただけたと思うとして、
で、ここでH1という名前をH1プライマリーに渡すのが難しいなと思ってるっていうのは今ここでまた別の話で、
別の名前にできんかなっていう、もう少し詳細度を上げる名前にしてもらえたら、
スライドスタイルの議論
例えばですけど、さっきのH1プライマリーとH1オンリーっていう2つが作れるなっていう感じで思ってたっていう感じ。
なるほど、なるほどね。確かに。
でも、スライドには多分タイトルのヘッディングレベルっていうものが今すでにあって、
それが多分H1かH2かH3かみたいな感じになっているので、
そうだね。それをなんて表現するかっていう、そこが解決すれば良いっていうのと、
たぶんセルを入れるのは面白そうなので、やるといいんじゃないかなっていうのは今聞いてて思いました。
はい。
今ってタイトルっていう言葉もちょっと紛らわしいんですよね。
でも、それは良いんだけど、トップページとしてのタイトルっていうのと、
スライド内の文章要素としてのタイトルとサブタイトルっていうのがあって、
今は文章要素としてのタイトルの話をしてるんだけど。
そうですよね。
そうですよね。ただ、そのタイトル要素が今はそのスライドの中で一番浅いヘッディングレベルのものが採用されるようになっているので、
そのタイトルのヘッディングレベルを何て呼ぶか、同じ話をしてるんですけどっていうのがあるってことですね。
まあまあ、そこがそうなんすよね。
そう、あれですよね。浅い深いで言えばいいらしいっていうのがわかったんですけど、ヘッディングレベルって。
てか、それで言う言い方もあるらしいけど、
ハイとローむずいっすよね、そのヘッディングレベル。
わかる。フライオンより高いが、それよりは低い。
1の方が6よりハイヤーなんですよね。
どうも英語圏ではそうらしいっていう。難しい。
でもそこはシャローとディープでも表せられるっていうので、
ネストが浅いっていうのと多分同じ話だと思うんですけど、ちょっと余談で。
H1がタイトルプレイスホルダーに入るっていう話ですよね。
H2がタイトルプレイスホルダーに入るって話ですよねっていうのも、
一つの要素の表現の仕方のものにもなりそうだなとは今思いました。
プライマリーとかスタートとか考えてましたけど。
僕はもうそこだけで、まずそこが一番大事だなっていうのを思っているっていう感じですね。
そうなんですよね。だからそうむんさんは、プライマリーがH2の時にはH2のタイトル入れて、
タイトルプレイスホルダーにH2のその要素、情報を入れた上でレイアウトも変えたいんですよね。
そう、そうですそうです。
そうなんですよ。だからそこの名前をタイトルH2だけっていうのと、
デザインを変えたい時にどうすればいいのか問題の解決をしたいんですよね。
そこのキー名はH1だと何を表しているのかが、
多分そうむんさんスタイルの人とそうじゃないスタイルの人で意味が違ってくるので、そこだけちょっと気にしてますね。
そうですね。長く言うとやっぱりタイトルヘッディングレベルだと思うんですよね。
そう、そこが1である、2である、3である、4である、5である、6であるっていう。
なるほど、なるほど。タイトルヘッディングレベル。
例えば変数名1つにするとして、めちゃくちゃ長くするとしたらタイトルヘッディングレベル1みたいな感じですよね。
そうそうですね。
それが許容できるかどうかの課題ですかね。
それでもいいとは思いますけどね。
H1っていうのはさすがにちょっと難しいかもな、無理があるかもなと思ってたんで。
あとはその変数は要望に応じて増やすのは全然ありかなと思ってたので、それでいいとして、
例えばそれが仮に決まったとしても問題なのは、その設定どこに書くのよって話なんですよね。
私はGoogleスライドにどこか書ければいいなと思ってたんですけど、どこか書けるのかっていうのが今ここですね。
唯一ですね、今書けそうなところがですね、レイアウトの各タイトルです。
テーマのレイアウトの、テーマの編集をした後に各レイアウトがバーって出てくるんですけど、
レイアウトにタイトル名を付けることができて、そこのタイトルの末尾の方にある記法で書けば、
それはタイトル名として解釈されず、セルとして解釈するみたいな実装はできるんですけど、
果たしてそれが良いのか悪いのかっていうのにまだ悩んでいる。
これはソムンさんがいなければ多分私それで言ってます。
ただやっぱりちゃんと頭が2つ今あるので。
なんか、例えば今のスライドのやり方も結構賢いなとは思ったんですよ。
思ったんですけど、スライドの方に細々したものを散りばめるレイアウトの方になってくると、
結構辛いなっていう感じがあるんですよね。
今の多分、かなりレイアウト名を変えるぐらいのところが、結構ギリギリのライン。
あとは一つスタイルっていうのを使って、インラインスタイルを当てられるようにするっていうのは、
むしろそれは視覚情報とも、ウィジウィグな作りをする上でもすごくわかりやすいと思うんですけど。
あとはもう、どっか宣言的にできることなわけだから、目で確かめてやることではないっていうのはあるから、
やっぱりコード管理したい。本当それはコード管理したい部分になるよなっていうのは思うんですよね。
そうなんですよね。ただ一個で、毎回コピーしても良くないよねってなるかもしれない。
もう一つ思うのが、毎回コピペも良くないんですけど、
今やっぱりGoogleスライドを結局コピペすることになるじゃないですかっていうのと、
デザインがあると。
デザインがあると、そうですね。
割と別のテンプレートとかを使いたいってなった時に、
じゃあそこにちまちまと設定を入れていくのが結構だるそうだなっていうのを思っているので、
あんまりGoogleスライドの方をいじりたくない。
むしろそこをコード管理させてくれよって話に結局なっちゃう気がするんですよね。
もうここは、私はマークダウンに毎回設定こっちは良くないんじゃないのかと思って、
今でスライドもその通りだと思ってるんですよね。
もうそろそろ設定ファイルなのかって気持ちになってきます。
でもやっぱりデッキを使ってもらう上で、
ケイジロウさんもちゃんと今回のスクリーンショットのスナップショットでも作ったと思うんですけど、
割とこれが典型的なスライドテンプレートじゃないや。
何だっけ。レイアウト。
テーマ、レイアウト、で、テンプレートはまた。
そうそうですよね。テーマだ。テーマね。テンプレートは違うんだよね。
テーマの中にレイアウトがある。テーマが言うべき多数言語なんですけど。
これが理想のテーマだっていうのをちゃんと示した方がいいよなっていうのは思っているし、
そういう意味では多分そこはコピペしてもらった方がいいと思うんですよね。
つまりある程度その理想的なスライドネーム一覧みたいなのをちゃんと定義して、
そうすれば、結局今困るのってテーマごとに命名規則がないから、
自分で使う分にはいいけど、仮にそれを他の人が使ってもらうってなった時に、
命名規則が揃ってた方がすごく使いやすいっていうのはあって、
デザイン的にはちゃんとスタイル用のレイアウトがあるっていうのはめっちゃいいんですけど、
そこにやっぱロジックとか組み込み始めちゃうと、そこは結構バラバラになっちゃうよなっていう。
設定管理の問題
ということで、私の方のレイアウトに行動格は却下で。
今ちょっと思ったんですけど、設定を毎回コピーするのは変じゃないですかという話はあったんですが、
2つあったらいいんじゃないかなと思ったんですよ。
私の要望とソムさんの要望の両方を満たす方法の一つとして、私は毎回スライドのテンプレートは一緒、
スライドのテンプレートのレイアウト設定ロジックも一緒なので、毎回マークダウンに書きたくないので、
定ファイルに置くこともできる。ソムさんは、私はコードでそのまま管理したいし、
ソムさんならマークダウンに毎回コピーしても全然いいんだよっていう話なので、フロントマターにも書くことができる。
優先はフロントマター。という形で設定を組んでいくっていうのはどうですかね。
そうできるのであれば、もうすごく僕は嬉しいですね。
僕は設定ファイルあんまなくてもいいなって思うんですけど、あっても別に困るものではないと思うし、
僕は結構フロントマターに書ければ明確じゃないですか。
暗黙的にこのデザインどこからどう適応されてるのかわかんないなみたいなのとか、
それこそ客観になって僕はよかったと思ってるんですけど、
レイアウトの方にコマコマ書いて読み解くみたいなのよりかは、なんかここに呪文が書かれてるけど、
フロントマターに書かれてる呪文を読むと、
なんとなくこれがスライドのレイアウトを一括して決めてくれる君っぽいっていうのはわかるから、
僕はそれができればそれでいい。
H2のタイトルレベルのところに毎回JSONをコピペしなくていいので嬉しいなって感じです。
やっぱりコードで管理スタイルが効いたな。
DSLにするならなおさらね。
どうしてもなかったんですよ。なんかいい場所ないかなと思ったんですよね、場所が。
確かに微塵部で欲しいのでスタイルは確かにまだありだけど、
設定のロジックは微塵部すらいらないよねっていうのはその通りだな。
なるほど、よかった。
本当ですか。
いやいや、それそうだなと思いました。納得がすごくいったし、
さっきの別に設定ファイルを誕生させれば両者の要望を満たすこともできるし、
絶対設定ファイルはいらないぞ派と、設定ファイルで一生楽したい派となっていてできるので、
そこかな落としどころは。
プロジェクトの進行と展望
お、めっちゃいいじゃん。それならいいと思います。
そうですね、あとはソムさんが欲しいって言ってるヘディングレベルのキー名だけ、
いい感じのソムさんの気がしてもらえれば。まず私多分DSLの方作り始めると思うので、
DSLに多分プラスの変数っていうのは多分いくらか作ってもいいはずなんですけど、
組み込みの何かっていう。
そうですね、そこら辺ですかね。
お、なんか楽しみになってきました。
一旦そこまでなんですけど、多分ですね、もう一声話をすると、
おそらくソムさんのタイトルH1、ヘディングレベル1という変数名を特別扱いしないで、
ただのDSLの変数として捉えた場合、193の一周の中の、
多分途中で私が書いた、この間それですね、それみたいなDSLになりそうなんですよ。
はいはいはい。
ifなのかcondなのかは全くわからないですけど、少なくともどうしても配列になりそうなんですよ。
まっぷりできなさそうで。
そうだと思います。僕もなんか基本的には配列になるだろうなって思ってました。
僕はDSLにするなら絶対配列になるだろうなっていうふうに思ってました。
だって優先順とかがすごくだるいから、ちゃんと先勝ちなのか後勝ちなのかっていう話はあると思うんですけど、
そうしないと絶対配列になるだろうなって思ってます。なのでDSL。
ただですね、もう一つ実はまっぷりできそうな方法が一つあって、レイアウトの名前がキーで、
条件がバリューの場合、しかも条件の方には多分このレイアウトはこういう条件の時とこういう条件の時とこういう条件の時が当てたいになるので、
多分ORがつくような条件で書けばマップで書けるんですよ。
まあでもその場合って優先度みたいな話になってきて、むずいかなっていう。
確かに。あ、そっかそっかそっかそっか。確かにおっしゃる通りだ。無理だ。
私結局そういうキー名を増やすことってDSL作ってるのと同じことだなっていう、多分主張を僕どっかでした気がするんですけど。
なるほど。了解です。理解しました。
じゃあ大体こんな感じでいくと思います。これ多分デフォルトじゃなくてレイアウトを多分採用すると思います。
レイアウトかな。
そうですね。別にフリーズとかは個別にやりたいことだと思うので、あくまでレイアウト設定に特化しちゃって良いのかなと思います。
そうですね。じゃあそんな感じで。
やったー嬉しいな。もうそこまでできればV1ですかね。そこまでいかなくてもV1でもいい気はするけど。
なんかもういい落とし所だった。納得できた。
私も確かにこっちがいいと思ったんですね。
良かった。嬉しい。
でも本当ちょっと早くね、どこまでやって一段落するかっていうのもあるし、別に今の時点で僕がデックはいいぞっていう話をブログに書けばいい気がするな。
V1待って出そうってなるとちょっとまだ一月ぐらいかかりそうだから。今の時点でもめっちゃ便利だからな。みたいに思いました。
ありがとうございます。本当にV1もっと前だと思ったのに、こんだけ良くなるとは思わなかったです。
これからでもね、もしかしたらパラグラフの考え方がかなりストリクトな形になったりするかもしれないし。
そうですね。パラグラフは結構良くできそうだなと思ってるので、これは僕の方でやろうかなと思っております。
地道にやることかもしれないですけど、はい。
ありがとうございました。
じゃあ、いや僕も良かった。すごい綺麗になった気がする。
じゃあ、はい。頑張りましょう。やっていきましょう。ということで、ありがとうございました。
ありがとうございました。
