@winerfresh:
A co z debugowaniem arkuszy napisanych w takim Sassie/Compassie? Załóżmy, że coś jest na stronie zwalone, np. jakiś element przesunięty o kilka pikseli.
Normalnie inspektujesz go Firebugiem (lub czymś podobnym), czasem od razu w Firebugu bawisz się przypisanymi do danego elementu regułami, a czasem od razu zapamiętujesz numer linii, przy którym zaczyna się dana reguła, otwierasz plik w normalnym edytorze CSS, znajdujesz regułę po numerze linii i edytujesz.
Jeśli zastosuje się "kompilator" (preprocesor) rozszerzonej składni CSS do normalnego CSS, to numery linii oczywiście kompletnie nie będą się zgadzać, więc ten sposób będzie bezużyteczny.
Czy jest inny, równie wygodny sposób?
Szukanie po selektorze i tak byłoby mniej wygodne, bo łatwiej i szybciej można zapamiętać i skoczyć do danego numeru linii. Poza tym, w tych preprocesorach CSS można także stosować nieco inną składnię selektorów np. dla zagnieżdżonych sekcji elementów, więc i to odpada.
Można korzystać z markerów w komentarzach np. w stylu /* =nav */ i wtedy wystarczy wyszukać w edytorze ciąg "=nav", ale przecież nie umieści się tego przy KAŻDEJ regule.
Podobne problemy występują, gdy używa się scalania i minifikowania arkuszy stylów, tyle że to łatwo ominąć: wystarczy włączyć to tylko na środowisku produkcyjnym, a na testowym pracować i debugować normalne, nieskompresowane i podzielone na pliki style. W tym środowisku testowym używamy więc kodu źródłowego i widzi go również przeglądarka wraz z Firebugiem.
W przypadku preprocesorów nigdy tak nie będzie, bo przeglądarka nigdy nie będzie potrafiła odczytać naszego rozszerzonego kodu źródłowego.