Boogaloo-Regular.ttfのコメントアウト

ハイライトでも分かりますね 笑
現バージョンで使っていないのであれば消してもよさそうですが…
(容量もすこしだけ減らせますし 笑)

ちなみに修正版

/*@font-face{
  //for IE
  font-family: Boogaloo;
  src:url('webfonts/boogaloo/Boogaloo-Regular.ttf');
}

@font-face {
  //for non IE
  font-family: Boogaloo;
  src: url('webfonts/boogaloo/Boogaloo-Regular.ttf') format("truetype");
}*/

ついでに、narrow.cssの47行目に「/」が浮いてます。
extention.css、キーボードのスタイルでpaddinが重複してます。

style.cssで、box-sizingのベンダープレフィックスはもういりません。
同様に、transitionもベンダープレフィックスはいりません。
backgroundに使われてる、linear-gradientも同様です。

シェアバーで、#sharebarのpositionが重複してます。動作は問題なし。

0pxというのは特に問題はありませんが、0で。

例えば、
.pagination li.first spanと言う場合、paginationの最初のli以外に.firstがついているなら別ですが、たいていは.firstは1つだけなのでli.firstというのは間違いではありませんが子テーマで上書きする際に同じようにliを付ける必要があり、.pagination .first spanで問題ないのではなかろうかと。

他にも、htmlタグ+クラス(ID)というのがありますが、カスタマイズのことを考えると余程の事情がない限り、クラス(ID)単体、場所が不明瞭であれば、親要素 クラス(ID)のようにして、なるべくhtmlタグを使わない方が優先度の問題で上書きできないというのを軽減できるかと思います。

あとどこかに、数値のみで単位のついていないプロパティがあったように記憶してますが、修正されているかも知れません(パッとは見つけられず)。

line-heightに単位を付けると、親要素で計算されたline-height値が子要素、孫要素に継承されます。何かしら縦センターに寄せる場合や、目的があるもの以外は単位はいらないかと思います。
特に、これらはul,olなどの元からliと親子関係を持っているもので正しくサイズ計算できません。

単位がない場合は、指定されたfont-sizeに対する倍率で計算されるためfont-sizeにあわせた高さになります。
親要素が仮にfont-size:30pxで子要素が12pxだとした場合、line-height:150%なら、親は45pxで、font-size:30pxの45pxの行間はおかしくないですが、12pxで45pxの行間は3.75倍ですからおかしいですよね？
単位なしにした場合、30pxの45pxは変わらず(30 * 1.5)、子要素の12pxは18pxの行間となり、体裁が正しく保たれます。

と、言われると思って2.5.3のcssを修正した(全部ではないですが)ものをcodepenに入れておきました。

サンプル: 親テーマ2.5.3 style.scss | codepen

サンプル: 親テーマ2.5.3 style.css | codepen

より多くの人に確認してもらった上で、修正する点やこうした方が良いというのを議論できればと。
見出しのpaddingは、敢えてとってます。というのは、見出しのカスタマイズができないという人が未だにいるということで、おそらくカスタマイズしにくいのではなかろうかということもあり、余白やマージンは後でも良いかなと言うことで、まずは全体の確認と言う感じです。

もう少ししたら、レスポンシブで確認できるようにもします。
細々とした部分は後々に。

あ、見出しについてはわいひらさんだけに言っているのではなく、ここを見た人に対して書いてます。

前にも言いましたが、直すのは僕で、それを採用するかどうかの判断はわいひらさんがしてもらえれば良いですし、全部でなくても、良いと思うことは部分的に使っても良いわけですしね。
親テーマとしてではなく、スキンとして導入すれば、親テーマ丸ごと上書きできるようにもできますし、それを更にカスタマイズするなら子テーマで修正すればよいだけです。

どこを直したかは全部、手元のファイルにはプロパティに追記してあるのと、部分ごとにファイル分けしてあるので、修正は容易です。codepenは誰でも見れるので、何とかのブラウザでは動作しなかったというのもわかります。
※ 修正・追記部分はcodepen上は結合されたファイルなのでそれらは自動で省略されてます。

現在のcssは、機能ごとにまとめられていないので、飛び飛びで各スタイルがしてあって(見当違いの場所にかいてあるわけではないですが)、それのせいで同じことが書いてあるんだろうと予測される所もありました。
これらは前にも話していたので、その分は直っているだろうと思ってたんですが、まだ少し残っているという感じです。

前に報告した分もあってcss上では特別プロパティがおかしな部分はなかったですが、まだ重複しているものやそれは必要なの？というのはいくつかありました。
が、別にそれらがあったとしても現状は動いているわけですからひとまず問題はないと言える程度のものですので、報告はしてません。

前はそのプロパティがスキップされているものとかありましたが、それらは修正されていました。

ついでに書いておくと、なぜ見出しからpaddingをとっているかは、例えばh2から始まる記事もあれば記事の途中でh2が入る場合もあります。あるいは、h2の後、すぐにh3が来る場合があります。これらの時にどれぐらいのマージンが美しいか等の意見を聞きたいからです。

僕はh2をあんまり使わないので、アレなんですが見出しにこだわる人が多いのはフォーラムを見ててもわかります。しかしそれは、そこぐらいからしかカスタマイズができないということでもあると思うんですよ。もしくは、カスタマイズはそこから始める人が多いというべきかも知れません。

もっと簡単に何とかできないものかは色々と考えてるんですが、これは親テーマに含めるべき内容ではないので個人で勝手にやってもらう話なんですけれども、見かけはclassを付け替えるだけでできても(色とかボーダーのスタイルとか)、h2のネガティブマージンで、モバイルテストで不合格とかは何とかしたいなと。

基本のスタイルがあって、それをパズルみたいに組み合わせるといくつかの見かけができる、それに色を付けたり独自に変更したりは子テーマでやれるということで、素の見出しの状態で美しいデザインを実現したいなぁと。

見出しだけじゃなくて、記事の本文や、ウィジェット、ブログカードなどもですけどね。

けどまぁアレですよ、今のSimplicityの親テーマと、codepenのcssを見比べてみて下さい。プロパティの値云々ではなく、機能ごとにまとめると見やすくなる、プロパティの並びをある程度整えると間違いに気づく、間違いや重複の防止に、そこらを確認して欲しいだけです。ベンダープレフィクス等は特に。

サンプルは(自動で付けてるものですが)-webkit-だけじゃなく、-ms-が必要なものがありました。
もうIE10のサポートは終わったのでIE11のみで良いわけなんですが、edgeも含めサンプルには必要最低限のはついてるはずなので。
※ だいたいオリジナルと同じように並べてるつもりですが、並べられてない部分もあるかも知れません。

値は子テーマで好きに改変されるわけですが、カスタマイズする時に、

.test {
  border: 1px solid #ccc;
  bottom: 10px;
  position: relative;
  color: #ccc;
  font-weight: bold;
  background-color: #000;
  border: 1px solid #ccc;
  opacity: 1;
  right: 10px;
  line-height: 120%;
  position: absolute;
}

そりゃこんな感じになってたら、positionやborderの重複には気が付きませんよ(笑)
で、重複しているからと言って問題なく動くから余計に気が付きません。カスタマイズする時は、何がどうなっているかをまず確認する必要があります。
それがわかりにくいと、まずやりにくさを感じてしまいますし、そもそもそこはどうなっているのが正しいのかをいちいち確認する必要があります。

パッと見て、何を修正すべきかがわかるのは何も僕らだけではなく、わいひらさんにもメリットがあることなんですよ。それを別に強要するわけではないですが、利用者のことを考えるなら直せる所は徐々にでも良い方向に向かって欲しいということです。

#site-descriptionのpadding、単位なしです。
やっと見つけた。
どこかにあったはずとずっと思いながら見つからなかったのが見つかった。

これまた前と同じことの堂々巡りになりますが、僕が言ってるのは親テーマに問題がはらんでるということです。
全部を一気に変えるとか採用してくれと言ってるわけではなく、僕が修正したものを現在のcssと比較した時に問題が出ているとすれば、その部分には何かしら書き方に不備があってズレを起こしていたりしていると言う問題定義です。

例を上げて言えば、
グローバルメニューの「news」の部分(テストサイトのaboutもそうです)がなぜそれだけ高さが合わないのか、とか
block要素にvertical-alignが使ってあるのは何故なのか、とか、
検索ウィジェットのインプットフォームで何かしら長いキーワードを入れると虫眼鏡アイコンと入力文字が重なるとか、虫眼鏡アイコンのmargin-bottomが20pxも必要なのは何故なのか？とか、これはサンプルでは見れませんが。
他にも色々あります。

仮に現在の親テーマのline-heightを全部ではないにしても記事部分(テキスト部分)のline-heightを%から数値(倍率)だけにしたらどうなるかと言うのを確認した時、ほとんどが特別問題が出るわけではありません。行間が狭くなるか広くなるかだけですし。
ボタン類とかは縦中央に揃えるのにそうしてあるんでしょうから触ったらダメなところですけども、それがどこかを知っておくのも重要です。

しかしその変更した部分にulなどがあり入れ子になっていてem等でfont-sizeを指定した場合に、おかしくなるので直すべき所は直すほうが良いと言っているわけです。直さなければいけない部分ではありません。直した方が問題が出にくくなるという意味での、直したほうが良いです。

見た目に問題があるわけではないんです。その見た目にするために微調整していたり、古いブラウザに対応するために書いてある部分もあるでしょう。悪の根源であるIE10のサポートがvistaの終焉と共に終わりました。次のwordpressのバージョンからIE10はサポート外になります。そういう今だからこそ、修正できる点もあるんじゃないのだろうか？と言うことです。

まず散らかった部屋を想像して下さい。そこに漫画が溜まってきたからもう少し大きい本棚を変えようと思いました。本棚を変えるためには、まず本を全部出して、本棚を移動する必要がありますが、部屋が散らかっているので本を片付けるのも大変な状態なわけです。
あいにく買ってきた本棚が収納は随分と増えたけれども、10cm程度大きくなって今のスペースでは入らないとします。すると他の家具も片付けたり、ついでなので掃除もするでしょう。

その10cmを作るために横にあった家具を10cmどけて本棚は入りました。入ったは良いものの、10cmどけた事で他の家具との並びがなんだかおかしくなって他のものを結局置き直すことにしました。

こういうことです。

本棚から本を出す時に、部屋が散らかっているのがまず問題です。それがなければ散らかっているのを片付ける必要もなく、普段から掃除をしていれば掃除をする必要もないわけです。
本来の目的の本棚を入れようとして他をどけたことで、結局配置換えをすることになると言うのが更に問題です。
こうならないように、まず全体の整理をして、例えば本棚を変えるにしても、そこに入るサイズの大容量のものはないか、結局、本は出すわけですが、本棚を同じ位置に入れなくても最終的な配置に新しい本棚を設置してそこに本を入れ替え、古い本棚は処分しつつ、その開いた場所を別で活用するというような計画性が必要だと僕は言っているわけです。

よく掃除した後、ハンコはどこにいったとか、はさみがないとかはありますよね？
散らかっている状態でも、ここら辺にあるはずだとだいたいわかってはいますから見当は付きます。しかし最初から机の引き出しに必ずしまってあれば、机がどこに移動しても同じところにハサミも、はんこも見つけることができるのです。

誰かが掃除してくれたとしても、机の引き出しに目的のものがしまってあるなら、ハサミはどこ？と聞かれても机の引き出しにあると言えるわけです。

僕が言ってるのはこういうことですよ。見た目が正しいからよいと言うだけではなく、誰が使ってもわかりやすくなっているのが最良ということです。

わいひらさんが言う所の親テーマを全替えする面倒臭さとか検証が大変だというのは、「いきなりリフォームするのは大変だ」と僕には聞こえます。それは当たり前です。僕が言ってるのはそこではなく、前レスで言えばlign-heightなどの部分的なこと、部屋で例えれば、机の上からでもまず整理しませんか？と言ってるに過ぎないのです。
それらが重なり全体的に整理整頓ができていればよいだけで、バージョンが2になる頃にも言いましたがあれから見てわかるほど変わっていないと言うか、修正ができているのは確かですが、散らかっていることに変わりがないという感じでもあるわけです。言うなれば、床に散乱していた本を積んで整理した感じです。

けどその積んである下の本を出す時また崩れはしまいか、どこに何があるのはわかっているから片付けなくてよいというのは個人的にはそうでしょうが、その仕様を皆が使っているわけです。そこをわかりやすくしましょうよと言うことなんですよ。

> 一つ一つやってもある程度負担はかかるんです。
> これが、僕の能力が低いからといわれればそれまでなんですけど。

これは設計の問題でしょう？
わいひらさんがどうのというより、当初はIEにも対応させないといけなかったというのもあるでしょうし、あれがしたいこれがしたいというユーザーの機能追加のリクエストを本体に盛り込みすぎたという点でもあるだろうと思います。

逆に何もしなくてもテーマ単体で必要十分な動作ができるというのはウリであるんですけどね。

オールインワンはどんなものでも一つに問題が出たら他のも道連れになるものです。一つ直すことで全部を見直さなければならないのは複雑に機能が絡んでいるせいとも言えると思います。

何か問題が出た時に、それを自分で修正しないといけないというのもあったでしょう。人のせいにできないわけですから。プラグインの問題なら、プラグイン作者に聞いてくれと言える所を、Simplicityのことだからそれをわいひらさんが修正しないといけないと言う場面は何度かあったように記憶してます。

だったら、1からテーマを作ってしまいましょうよ。

これは大賛成ですね。
Simplicityの矯正が面倒なのは重々わかってます。Simplicityで培ったノウハウもあるでしょうし、そのほうが絶対楽です。

利用できる技術などは他所から流用するのがリスクを分散する上でも絶対的に楽になります。wordpressのものとは違う方法でも良いですが、その人に必要な機能は、その人が後から入れられるようにして本体には本当に必要なものだけしか含まないと言うが良いと思います。それこそ文字通りSimplicityです。

どうやってそれらを追加させるかの方法を考える必要があり、そこが難しい点でもありますが。

例えばcssフレームワークを入れれば大半のスタイルをそれらが持っているので独自に入れる必要もありません。ボタンやフォームパーツ、リスト表示にしてもそうでしょうし、グリッドシステムを持っているものもあるので、要素内を3分割や4分割もできます。レスポンシブもブレイクポイントがどこだとか考えなくても良くなります。

何よりモバイルファーストで作られているものが多いので、今の時代にはマッチしているかと思います。

これらは現在のSimplicityでも可能ですが、今更phpファイルの書き直しなんかはできないですから現実的ではないです。それでもそれらを利用して今のSimplicityのようなデザインにすることはできます。

どこまでの機能が必要で、どれは別にできるかの精査と、どのようにして機能を追加できてどこまでの使い方ができるか、それらでSimplicityを超えられるかが考えどころですかね。
速度面でもっと速くなれば更に良しですね。

> テーマの根幹だけをシンプルに固めて、機能は
> 最後の最後に必要なものだけつけるという感じで。
> レスポンシブ・モバイルファーストで
> 速度面ももちろん最初から考えて作ります。

テーマの仕様を決めるにしても1から作るのはアレなので、bonesなどの雛形になるテーマを利用するというのもアリかもしれませんね。cssフレームワークをそこに入れたら、子テーマで部分的に変更するようなものですから(日本語フォントの対応とかサイズ・色程度)、その仕組み(html)に専念できるとも思います。

> 名前はSimplicityとは別の無料テーマになると思います。
> あらためて、サイトを作ってドメインを取るので、
> 名前は僕が考えちゃって良いでしょうか？

おまかせします。
が、あまり事を急がず、じっくりとでいいんじゃないですかね。やったは良いが形にならないなんてことは、ままあるので(笑)

ただの報告から面白いことになっていますね 笑

名前を考えてみました。

「SimpleGreat」

そのままですが
シンプル&素晴らしいですね

シンプル、機能の多さ、CSSの重複等の修正などすごいことだらけなので
SimpleGreatとしてみました。

あと、トピックを作ったほうが良いのではないでしょうか
タイトル的に 笑

使い方があっているのかは分かりませんが 笑