Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

edjoに関するruedapのブックマーク (7)

  • 厚いレイヤー

    Sitepointに書かれたBEMやSMACSSを使っている開発者たちからのアドバイスを読んでいた。僕は今いかにして命名規則をなくすかといったことを考えている最中のため否定的に読んだが、それでもここに書かれたアドバイスは正しいとは感じた。BEMやSMACSSが概ね想定以上に機能することは確かだし、スケールするし、指揮もとりやすい。 僕が避けたいのは何かしらへの強い依存だ。薄いレイヤーならともかく、厚いレイヤーの場合は重度の依存をもたらす。その依存はこれからもそのまま通用するのかというと、不安が大きい。厚いレイヤーとは心中する覚悟が必要というのは正しいが、多くの場合心中する羽目になるのは導入した人ではなかったりもする。もっと薄いレイヤーでウェブ標準(など)に寄せた形の解があれば安心できるはずだ。 HTML 4.01に対するHTML5を始めとして、CSS 2.1に対するCSS 3、いわゆるJa

    厚いレイヤー
  • OOCSSとEDJO、もしくはHTMLとCSSにおける命名 - morishitter blog

    OOCSSの欠点とEvery Declaration Just Onceのもたらすもの hail2uさんのこの記事を読んで、EDJO (Every Declaration Just Once)というCSSの記述アプローチを知ったので、僕なりに考えたことをまとめてみる。 OOCSSとEDJO OOCSSとEDJOの違いは、 名前を付ける向きだと思う。OOCSSでは、CSSからHTMLに、つまりCSSで定義したルールセットの名前をHTMLで使用するということ。そしてEDJOでは、HTMLからCSSに、HTMLの構造に名前が付き、その名前に当てるスタイルを定義するという流れだ。 デザインの意図やコンポーネントの見た目に対して名前を付けるのがOOCSS的アプローチで、文書構造や文書の意味に対して名前を付けるのがEDJO的アプローチなのかなと思う。 OOCSS的アプローチを取ると、.btn-larg

    OOCSSとEDJO、もしくはHTMLとCSSにおける命名 - morishitter blog
  • EDJOなオブジェクトの妄想 - dskd

    公開日2015-01-24タグCSSながしまさんの Every Declaration Just Once アプローチについてのエントリー2つ(Every Declaration Just Once の例とOOCSS の欠点と Every Declaration Just Once のもたらすもの)を興味深く読んだ。 僕もかねてから、CSS プリプロセッサーは CSS を複雑にするだけして何も楽にならないのではないかと思っていた。変数や mixin は出力されるスタイル宣言郡を型のようなものに設定づけ、再利用が可能な便利なものにしてくれる。しかし書式の限られたスタイル宣言郡を使い回すのは柔軟と言えるだろうか。 僕がかつて見殺しにした CSSは、無限に続く断続的な変更になんとかついていこうとした結果死んだ。現実の CSS のメンテはそういった型の中では収まらないレベルの変更ばかりだと思ってい

  • EDJOの(デ)メリット

    Every Declaration Just Once (以下EDJO)アプローチの最大のメリットはなんだろうかということについて考えていた。情報設計と重なるところがまるでないため、設計思想としては完全に成立しない。つまりCSSを設計することを放棄し、設計されたHTMLに対してスタイルを割り当てていく手法としてのみ存在しうる。このことがすなわちメリットなのではないだろうか。 CSSの限られた文法が情報設計に基づく複雑な構造の表現に適さないことは明白だ。OOCSSではHTMLCSSを設計のもとに平等に扱っていたが、どうしてもCSSにおいては限界があり、複雑な命名規則CSSプリプロセッサーの登場となったのではないかと思う。CSSプリプロセッサーの高機能化により実現可能になりつつあるが、それと同時に高度に抽象化された複雑さも氾濫しつつある。 EDJOにおいてはその書かれ方を見ればわかる通り、

    EDJOの(デ)メリット
  • CSS記述規則「プロパティ別整理法」の提案 : akiyan.com

    2005-03-06 はじめに 2005-03-05 提案の目的 2005-03-07 必須ツール 2005-03-06 注意点 2005-03-11 多くのCSS図書館方式で整理されている 2005-03-06 図書館方式の例 2005-03-07 図書館方式の利点 2005-03-11 図書館方式の欠点 2005-03-04 図書館方式の何が不満か 2005-03-06 プロパティ別整理法とは 2005-03-04 絶対規則 2005-03-04 推奨規則 2005-03-06 プロパティ別整理法の例 2005-03-11 プロパティ別整理法の利点 2005-03-04 プロパティ別整理法の欠点 2005-03-04 プロパティ別整理法に近い例 2005-03-04 機械との親和性 2005-03-04 Grep検索を活用する 2005-03-04 機械が完全に理解できる 2005-

  • CSS: Using every declaration just once - Make the Web Faster — Google Developers

    OverviewPageSpeedAnalysisInsightsAboutMobile AnalysisInsights ExtensionInsights APIDocumentationGetting StartedPerformance TipsReferenceRelease NotesTerms of ServiceResourcesLibraries and SamplesAPIs ConsoleLibrariesRulesAvoid landing page redirectsAvoid pluginsConfigure the viewportEnable compressionImprove server response timeLeverage browser cachingMinify resourcesOptimize imagesOptimize CSS de

  • OOCSSの欠点とEvery Declaration Just Onceのもたらすもの

    昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕

    OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
    ruedap
    ruedap 2015/01/15
    面白い。シングルクラスのBEMが良いと思っていた時のゴールがEDJOにはある…かもしれない。
  • 1