Sass とブラウザの 互換性

Sass の主な設計原則の 1 つは常にCSS を可能な限り理解しないことでした。CSS のプリアンブルとして、CSS 構文は理解する必要がありますが、できるだけスタイルの意味を気にせず、セマンティクス (意味論) は無視するようにします。つまり、Sass はどのプロパティが有効か、HTML 要素が実際に存在するかどうか、さらにほとんどの @-rules 構文でさえも、ほとんどの場合で把握しません。

このことにより、多くの利点が得られます。Sass が組み込みで CSS に深く精通していないほど、新しい CSS 機能との相性が悪くなる可能性は低くなります。新しい CSS プロパティを使用するたびに機能リクエストを提出する必要があるとしたら、それは苦痛です。その代わりに、Sass の古いバージョンでは、実際の構文が変更されない限り、引き続き正常に動作します。これはより 珍しいことです。

この分離により、ブラウザの互換性をあまり心配する必要がなくなりました。Sass は、渡された CSS をそのまま受け流すだけです。どこで何を使用するかを判断するのはユーザー次第です。これにより柔軟性が高まり、デザイナーは面倒な判断を 下さなくてすみます。

しかし、この一般的な方針にもかかわらず、CSS の知識が必要な場合は常に発生します。CSS の意味論を十分に理解する必要がある @extend が 1 つの大きな例です。これを適切に統一して重複を除外するにはセレクターの意味について多く理解する必要があります。プロパティ値にも時にはセマンティック知識が必要です。例えば、色を解釈する方法を理解する必要があります。

そんな例が 1 つ、致命傷として帰ってきました。昔、常に透過色をキーワード transparent として出力することにしました。これは IE6 から 8 まででサポートされており、別の rgba() 構文はサポートされていなかったからです。しかし、最新バージョンではその逆であることがわかりました。IE10 では、:hover スタイルは background-color: transparent の要素ではトリガーされませんが、background-color: rgba(0, 0, 0, 0) ではトリガーされます。ありがとう IE。

そこで、ジレンマが生じました。今や時代遅れで誰も使っていない古いブラウザと互換性のある既存の動作を維持するか、最新のブラウザでより適切に動作する新しい動作を選択するか。選択は明らかでした。常に rgba(0, 0, 0, 0) を出力することにしました。

さらに、時代遅れであると考えるブラウザを特定し、サポートを継続するブラウザを決定するための一般的なルールを策定しました (問題の動作に対して何を意味するかによらず)。StatCounter GlobalStats によると、変更がブラウザのグローバル市場シェアの 2% 未満に悪影響を与える場合、変更できます。

この制限は絶対的なものではありません。将来変更する権利、およびより多くのブラウザに影響を与える可能性のある個別の決定を下す権利を留保します。しかし、これが私たちが注意を払っている一般的なガイドラインです。皆様に 知っていただきたく思います。