Sass 3.3 の計画変更

2013年12月20日、Natalie Weizenbaum 投稿

これはもともとgistとして公開されたものです。

Sass 3.3 が間もなくリリースされます。それに伴い、いくつかの主要な新機能が追加されます。ソースマップ、SassScriptマップ、およびSassScriptでの&の使用をサポートします。リリースに向けて、すべてが設定され準備ができていることを確認するために、いくつかのリリース候補を公開しました。残念ながら、そうではありませんでした。

リリース候補では、新しい機能に小さなバグや矛盾が見つかることはよくありますが、本当に致命的なものが見つかることはまれです。しかし今回の場合、複数のユーザーがSassScriptで&を使用する際に問題があることに気づき、3.3のそのセクションに関する計画のかなりの部分が機能しなくなりました。致命的な問題ではなく、対処するための良い計画があると考えていますが（後ほど説明します）、問題ではあります。

背景背景へのパーマリンク

何が問題なのかを理解するには、まず、なぜ最初にSassScriptで&をアクセス可能にすることにしたのかを理解する必要があります。ユーザーが頻繁に行いたいことの1つは、クラスにサフィックスを追加することです。これはセレクターのネストの代わりになることもあれば、単に古いクラスに基づいて新しいクラスを作成することもあります。その理由は、この議論ではあまり重要ではありません。人々がこれを試みると、.foo { &-suffix { ... } }のように記述しますが、うまくいきませんでした。その理由は、&が型セレクター（例：h1）やユニバーサルセレクター（*）と同じ構文機能を持っているため、それらのいずれかで置き換えることができるからです。セレクターで*-suffixと書くのは意味がないため、&-suffixも許可されていませんでした。

しかし、これは人々がそれを行いたいという欲求を止めることはありませんでした。そこで、「わかりました。セレクターにテキストを挿入するためにすでに補間（#{}）を使用しています。それを使用しましょう」と決定しました。現在のセレクターの解析表現を含む、SassScript内の特別な変数として&を追加することにしました。その後、@at-root #{&}-suffixを実行することで、&-suffixを模倣できます[1]。問題が発見されるまでは万事うまく行きました。

問題点問題点へのパーマリンク

問題を説明するSCSSの小さなスニペットを次に示します。それが何か理解できるか試してください。

.foo, .bar {
  @at-root #{&}-suffix {
    color: blue;
  }
}

わかりましたか？そのとおりです。この例の&は.foo, .barであるため、セレクターは.foo, .bar-suffixにコンパイルされます。#{}はプレーンテキストを挿入するため、Sassがセレクターをどのように分割する必要があるかを判断する機会はありません。

Chrisと私は、これを修正する方法について何度も話し合いました。サフィックスを追加する関数を追加することを検討しましたが、冗長すぎました。&のセレクターごとに単一のセレクターを持ついくつかの並列ルールにCSSルールのコンパイルを分割することを検討しましたが、複雑すぎて多くのエッジケースで失敗しました。最終的に、SassScriptの&が、設計したユースケースをきちんとサポートする方法はないと結論付けました。

解決策解決策へのパーマリンク

&-suffixのユースケースをサポートしたいと考えており、そのための巧妙な計画は失敗しました。私たちは集まって話し合った結果、それをサポートする最善の方法は最も簡単な方法であると判断しました。つまり、&-suffixを許可します。結局のところ、これはほとんどの人がこの動作を望んだときに最初に試したことであり、セレクターに直接埋め込まれた&を使用すると、セレクターリストを簡単に処理できます。

つまり、&-suffixは、#{}や@at-rootを必要とせずに、Sass 3.3 でサポートされます。それを追跡するために、issue 1055を作成しました。これらのセレクターをコンパイルするときに、親セレクターが無効なセレクター（例：*-suffixまたは:nth-child(1)-suffix）になる場合、そのセレクターが生成された理由を説明するエラーがスローされます。

人々が、特定の親セレクターでは機能しない&-suffixを使用してmixinを作成する場合についても懸念していますが、この場合は、利用可能なすべての選択肢の中で最も害が少ないと判断しました。

SassScriptでの&の将来SassScriptでの&の将来へのパーマリンク

&-suffixのサポートに加えて、SassScriptの&を3.3リリースから取り下げることにしました。他の優れたユースケースがあることを認識しており、次の大きなリリース（おそらく3.4）で復活させる予定ですので、ご安心ください。さらに、利用可能にするセレクターを操作するための関数群が付属するため、これまで以上に強力になります。

現時点でSassScriptで&を使用するのを控えたい理由は2つあります。1つ目は、それに伴う関数を作成し、それらを試す時間を設けたいからです。これには、さまざまな方法で動作を変更する必要がある場合があり、それを行うために後方互換性のない変更を行う必要は避けたいと考えています。

2つ目の理由は、&-suffixの問題の解決策として#{&}についてかなり熱心に話し合ってきたからです。これは明らかに私たち自身の責任ですが、事実であり、対処する必要があることです。&-suffixを機能させることは素晴らしいことですが、数か月前に話したように、誰もがとにかく#{&}を使用している場合、できることをすべて実行しているわけではありません。&-suffixは機能するが#{&}は機能しないリリースがあれば、より高度な機能が利用可能になる前に、ユーザーが問題を解決するための最良の方法に導くのに役立ちます。

@at-rootは引き続きSass 3.3に含まれます。

3.3のリリース3.3のリリースへのパーマリンク

残念ながら、この変更により3.3のリリースが遅れますが、おそらくそれほど遅れないでしょう。これは実装が比較的簡単になると予想しています。大きなハードルは、それについてどうするかを理解することでしたが、その部分は完了しました。冬休みから戻った後、3.3をリリースすることに多くの時間を費やすつもりですので、うまくいけば（約束はできませんが）、1月中にリリースされるでしょう。

  1. Sassは、&が#{}なしで使用されている場合のように、セレクターで&が使用されたかどうかを確実に判断できないため、@at-rootが必要です。 ↩︎