Poprawnie – najwyższy priorytet ma tzw. styl lokalny, czyli deklaracje CSS zapisane bezpośrednio w atrybucie style danego elementu HTML, np. <p style="color:red; font-weight:bold;">. W kaskadowości CSS (Cascade) przeglądarka ustala, które reguły zastosować, biorąc pod uwagę kilka czynników: ważność (normal vs !important), specyficzność selektora, kolejność wystąpienia oraz właśnie źródło stylu. Zgodnie ze specyfikacją CSS (m.in. CSS Cascade Level 4) style inline są traktowane jako bardzo specyficzne, bo dotyczą jednego, konkretnego elementu. Dlatego, jeżeli nie używamy !important, to reguła z atrybutu style nadpisze reguły zewnętrznego, wewnętrznego arkusza, a także style importowane. W praktyce: jeśli w pliku style.css ustawisz p { color: blue; }, w sekcji <style> w <head> dasz p { color: green; }, a na elemencie napiszesz <p style="color:red;">, to tekst będzie czerwony, właśnie dlatego, że styl lokalny wygrywa w kaskadzie. W projektach komercyjnych styl inline stosuje się raczej oszczędnie, bo utrudnia utrzymanie kodu i psuje rozdzielenie warstw (HTML – struktura, CSS – wygląd). Czasem jednak jest bardzo przydatny: generowane maile HTML, szybkie testy, dynamiczna zmiana wyglądu przez JavaScript (np. element.style.display = "none"). Dobrą praktyką jest opieranie się głównie na zewnętrznych arkuszach stylów i selektorach o odpowiedniej specyficzności, a styl lokalny traktować jako wyjątek albo narzędzie „ostatniej szansy”, gdy naprawdę trzeba coś nadpisać na pojedynczym elemencie.
W tym zagadnieniu kluczowe jest zrozumienie, jak działa kaskada CSS i co faktycznie oznacza „priorytet ważności”. Wiele osób intuicyjnie zakłada, że skoro zewnętrzny arkusz stylów jest głównym źródłem stylowania projektu, to właśnie on ma największą moc. Inni z kolei myślą, że wewnętrzny arkusz w <style> w dokumencie HTML jest ważniejszy, bo jest bliżej elementu. Spotyka się też przekonanie, że style importowane przez @import do wewnętrznego arkusza są traktowane jako coś „bardziej aktualnego”. Wszystkie te intuicje mijają się z tym, jak faktycznie działa specyfikacja CSS. Z perspektywy przeglądarki istnieją trzy główne źródła stylów autora strony: zewnętrzne pliki .css, wewnętrzne style w sekcji <style> oraz style lokalne w atrybucie style na konkretnym elemencie. Do tego dochodzą jeszcze style domyślne przeglądarki i ewentualne style użytkownika, ale w typowym projektowaniu stron WWW skupiamy się na stylach autora. Kaskada bierze pod uwagę kilka kroków: najpierw ważność (czy jest !important), potem pochodzenie, następnie specyficzność selektora, a na końcu kolejność deklaracji. Jeśli porównujemy odpowiedzi w tym pytaniu, wszystkie dotyczą stylów autora bez !important, więc decyduje właśnie źródło i specyficzność. Zewnętrzny arkusz stylów i wewnętrzny arkusz w <style> mają w praktyce ten sam poziom „źródła”, różnią się tylko kolejnością ładowania i tym, że reguły z <style> zwykle nadpisują wcześniejsze z plików .css, jeśli mają taką samą specyficzność. Style importowane przez @import traktowane są jakby były wczytane wcześniej, więc często mają nawet mniejszy wpływ, bo są nadpisywane przez późniejsze reguły. Natomiast styl lokalny, czyli atrybut style na elemencie, ma znacznie wyższą specyficzność i to on wygrywa, o ile nie pojawiają się reguły z !important. Typowy błąd myślowy polega na mieszaniu „miejsca zapisania” z „ważnością w kaskadzie”: to, że plik zewnętrzny jest głównym nośnikiem stylów w projekcie, nie oznacza, że ma największy priorytet. Dobra praktyka front-endowa wręcz odradza nadużywanie stylu lokalnego, ale to, że coś jest niezalecane, nie zmienia faktu, że technicznie ma najwyższy priorytet spośród podanych opcji. Warto o tym pamiętać, zwłaszcza przy debugowaniu sytuacji, w których styl „nie działa” – bardzo często blokuje go właśnie jakiś inline style, który został dodany ręcznie lub przez JavaScript.