27

あなたの専門的な経験において、haml＆sassは有用であることが証明されましたか？どのように？

4

3 に答える 3

44

Hamlは素晴らしく、私はそれをよく使用しますが、特に複雑なスタイルシートを作成する必要がある場合は、Sassだけでも価値があります。たとえば、CSSの最悪のことの1つは、セレクターに名前を付けるときに実行する必要のある冗長性です。CSSでは、あなたはしなければなりません

#navbar ul 
#navbar ul li a
#navbar ul li a:hover

Sassを使用すると、これらの子孫を自然にネストすることができます。

#navbar

  ul
    margin: 0
    padding: 0
    list-style: none
    width: 100%

    li
      margin: 0
      float: left
      margin-right: 10px
      border: 1px solid #000

      a
        text-decoration: none

        &:hover
          color: red

変数を使用することもできます

!border_color = #333

.box
  border = 1px "solid" !border_color

そして、あなたは彼らと一緒に数学を使うことができます

!measure = 18px
!text_size = !measure / 1.5

body
  font-size = !text_size
  line-height = !measure

h1
  font-size = !measure
  margin-bottom = !measure

h2
  font-size = !measure + 2

#wrapper
  width = !measure * 50

コードを共有することもできます

=rounded
  -moz-border-radius: 4px
  -webkit-border-radius: 4px
  border-radius: 4px
  border: 1px solid #000

.box
 +rounded

これには非常に多くの力があるので、あなたはそれを学ぶことを自分自身に負っています。さらに、最終結果はプレーンCSSになるため、変換できます。

既存のcssをsassファイルに変換するcss2sassを忘れないでください！

必要に応じて、 http：//rendera.heroku.com/でいくつかの例を試すことができます。これは、人々がHTML5とCSS3を学ぶのを助けるために私が構築したサイトであり、そこでHAMLとSASSの両方をサポートしています。

また、静的WebサイトをHAMLおよびSASSで操作するためのすばらしい方法については、StaticMatic（staticmatic.rubyforge.org）を参照してください。静的ホストにアップロードできるWebサイトを生成し、RubyonRailsと同様のレイアウトとテンプレートシステムを備えています。

あなたが尋ねた直接の質問に答えるために、「それはそれだけの価値があるか」という方法で、答えはイエスです。変数を使用したり、セレクターで簡単にグループ化したり、モジュールを介してコードを共有したりできるため、複雑なスタイルシートがはるかに簡単になります。スタイルシートの作成にそれほど時間はかからず、優れたCompassフレームワークを使用してさらに先に進むことができます。たとえば、960.gsまたはBlueprintモジュールを使用して、これらのフレームワークを既存のスタイルシートに混在させることができます。このようにして、コードのマークアップを変更する必要はありません。960.gsとその"grid_12"および"container_12"クラスをすべてのマークアップに追加することは不可能かもしれませんが、CompassとSassを使用すれば簡単です。

Sassを使用すると、開発モード用に複数のスタイルシートを作成し、本番用に単一のスタイルシートを生成することも簡単になり、クライアント側のパフォーマンスが向上します（ページの読み込み時にサーバーへの呼び出しが少なくなります）。

HAMLには独自の利点がありますが、Sassほど目立ちません。HAMLを使用すると、要素をネストしてDIVSを宣言するのが非常に簡単になります...たとえば、通常の960.gsを使用する場合でも、HAMLを使用すると簡単です。

#header.container_12
  .grid_12
     %h1 Welcome!
#middle.container_12
  .grid_8
     %h2 Main content
  .grid_4
     %h3 Sidebar

タイピングがはるかに少なくなります。そして、何らかの理由でそのすべての周りにラッパーを追加する必要があると判断した場合は、新しいタグの下にすべてをインデントするだけです。

お役に立てば幸いです。I<3Sass。

于 2010-01-16T03:00:14.917 に答える
9

私の現在のWebサイトには800を超えるHamlファイルと150のSassファイルがあり、それが私の開発に非常に役立っていることをお伝えします。

最大のメリットは、迅速な開発です。Haml/ Sassファイルの作成に必要な入力ははるかに少ないため、erbテンプレートを使用する場合よりもはるかに少ないキーストロークでプレゼンテーションロジックを完成させることができます。

また、Hamlファイルははるかに読みやすく、エラーが発生しにくいと感じています。

YMMVですが、Hamlを使用しないのは雑用のように感じるようになりました。

于 2010-01-16T06:26:21.827 に答える
5

TL; DR-人気がありますが、HAMLやSASSは使いたくないのですが、SCSSは好きです。

HAMLに関する一般的なコンセンサスは圧倒的に賛成しているようですが、個人的には気にしません。

私の意図がHTMLを生成することである場合、私はテンプレート言語を可能な限りHTMLに近づけることを好みます。これにより、混乱やエラーの機会が増えるだけでなく、認知的オーバーヘッドが発生する間接参照の別のレイヤーを学習する必要がなくなります。

HAMLが読みやすさと行の折り返しのために空白を使用することを好むという制約は面倒であり、構文が読みづらくなることがよくあります。

最近、HAMLテンプレートで微妙なエラーが発生しました。これは、テンプレートがERBの場合、すぐにわかります。たとえば、次のようになります。

 .table
   .thead
   .tr
   .tr

テーブルの行はTHEADタグ内にありません。これは、完全に有効なHAMLですが、目的のHTML構造に関しては正しくありません。ページは正しくレンダリングされているように見えましたが、CSSセレクターが失敗し、一部のJavascriptコードがサイレントに失敗しました。

単独で示されているように、この種のエラーはほとんどのHAMLユーザーにとって明らかであると確信していますが、より大きなテンプレートのコンテキストでは、見つけるのが難しい場合があります。特にHAMLを初めて使用する開発者にとっては。

一方、これがERBまたはHTMLの場合：

 <table>
   <thead>
   <tr>...</tr>
   <tr>...</tr>

私の目には、ERBとHTMLがほとんど常にインデントされているため、構造のエラーを見つけるのがはるかに簡単です。

HTMLの作成に20年近く費やしてきた私は、整形式のHTMLを作成することに一定の誇りを持っていることを認めなければなりません。それを表現する別の方法を学び、エラーを見つけるために必要なすべての新しい視覚パターンを学ぶ理由はありません。

一方、SCSSは本質的にCSSのスーパーセットであるため、私は（SASSではなく）SCSSが非常に好きです。それは、私が精神的に翻訳する必要のある完全に新しい間接層を追加するものではありません。構文にわずかな変更を加えるだけで、CSSのより簡潔な（そしてDRY）表現を提供します。これは私が非常に読みやすく理解しやすいと思います。

実際、Pythonなど、コードをインデントまたは行ラップする方法に関して厳密な構文を強制する言語は使用しません。または、coffeescriptなどの基礎となる言語の上に間接層としてのみ機能する言語。

プログラミング言語では抽象化と間接参照が悪いと私が信じていると言っているのではありません。ここで説明する特定の言語に関しては、それらを使用したくないということだけです。

于 2013-06-09T06:03:39.260 に答える