Jeśli chodzi o renderowanie na cudzym modelu DOM, nie można naiwnie pisać HTML i CSS tak jak dla własnej, niezależnej aplikacji internetowej. Musisz dokładnie przemyśleć, jak istniejący kod CSS i JavaScript może wpłynąć na twoją aplikację.

Zanim zaczniesz pisać dowolny kod HTML lub CSS, musisz podjąć ważną decyzję dotyczącą wyglądu i sposobu działania aplikacji. Czy chcesz, aby aplikacja wyglądała wszędzie tak samo? A może chcesz, aby aplikacja dziedziczyła natywny wygląd strony, na której jest hostowana? Twoja odpowiedź będzie miała głęboki wpływ na twoją strategię renderowania Twojej aplikacji.

Jedna rzecz jest stała: na pewnym poziomie będziesz ćwiczyć to, co nazywamy renderowaniem defensywnym. Przez defensywne rozumiemy podjęcie kroków w celu uzyskania HTML i CSS, które minimalizują wpływ strony nadrzędnej na twoją aplikację. Im mniej zależy od tego, czy widget ma wpływ na stronę nadrzędną, tym więcej kroków trzeba będzie wykonać. Kroki te mogą być tak małe, jak nazywanie kodu HTML i CSS w celu zmniejszenia konfliktów nazw lub nadmiernego spreparowania reguł CSS, aby miały pierwszeństwo przed regułami ze strony nadrzędnej. W przypadku widżetów, które wymagają pełnej odporności od strony nadrzędnej, może to również oznaczać serwowanie widżetu na całkowicie oddzielnym DOM, osadzonym w elemencie iframe.

Skoncentrujemy się na renderowaniu kodu HTML i CSS, które znajdują się w tym samym DOM, co strona wydawcy. W przypadku widżetów, które mają na celu zaoferować pewien poziom personalizacji, może to być najbardziej elastyczne rozwiązanie dla wydawców, ponieważ wydawca może łatwo kierować elementy i dopasowywać je do swoich preferencji.

Niestety jest to również wadą. Wydawca może nieświadomie posiadać reguły CSS i / lub kod JavaScript, które przypadkowo trafią w twój widget i siać spustoszenie.

Przyjrzymy się wielu sposobom ochrony kodu HTML i CSS Twojej aplikacji przed kodem wydawcy. Najpierw poznasz przestrzenie nazw HTML i CSS. Następnie dowiesz się o specyfice CSS i o tym, jak style strony nadrzędnej mogą nadpisywać własne.

Na koniec nauczysz się technik zastępowania stylów rodzicielskich strony, poprzez nadpisywanie swojego CSS i nadużywanie ważnego słowa kluczowego! Po pierwsze, przestrzenie nazw.

Przestrzenie nazw

Wszystkie identyfikatory DOM, klasy, atrybuty danych * i pasujące selektory CSS zostały poprzedzone bocianem. Cel? Aby zmniejszyć prawdopodobieństwo konfliktu tych atrybutów ze stroną nadrzędną.

Rozważ poniższą sytuację. Twój widget ma najwyższy poziom

element, który działa jak pojemnik. Czyni to, ustawiając wyraźną szerokość i wysokość, skutecznie ograniczając obszar zajmowany przez widget. Dałeś to
prosta nazwa klasy, kontener, który pasuje do reguły stylu w twoim towarzyszącym CSS:

...

Może to być idealne dla zwykłej aplikacji "zostań w domu", ale w przypadku aplikacji innej firmy jest to kompletne nie-nie. Powód? Taka ogólna nazwa klasy ma duże szanse na wykorzystanie jej przez stronę nadrzędną. Jeśli wprowadzisz tę regułę stylu, możesz zastąpić istniejącą regułę stylu wprowadzoną przez wydawcę i zrujnować jej układ strony. Albo, z drugiej strony, ich reguła może zastąpić twoją i nieumyślnie zmienić jej rozmiar.

Rozwiązanie? Prefixowanie wszystkich nazw klas (i innych atrybutów) z identyfikatorem unikalnym dla aplikacji - przestrzenią nazw. W przypadku widżetu Bocian poprzedni znacznik powinien zostać zmieniony, aby wyglądał tak:

...

Chodzi o to, abyś nazwał swój kod JavaScript tak, aby nie zadeklarować globalnych obiektów, które kolidują z kodem uruchomionym na stronie nadrzędnej. Rozciąga się na każdy fragment HTML wstawiony do strony: identyfikatory, klasy, dane- * atrybuty, nazwy formularzy i tak dalej.

Odwzorowywanie nazw HTML i CSS jest koniecznością dla dowolnej aplikacji zewnętrznej, która wyświetla się bezpośrednio na stronie wydawcy. Jest to nie tylko konieczne do zapobiegania sprzecznym regułom CSS; możliwe jest również, że strona nadrzędna zawiera JavaScript, który wysyła zapytanie do DOM dla elementów, których właściwości identyfikujące mogą być zgodne z twoimi. Bądź rygorystyczny w nazwach, umieszczając wszystko, co umieścisz w DOM.

Specyfika CSS

Ważne jest, aby pamiętać, że chociaż pomocna, nazwanie kodu HTML i CSS zapobiega tylko przypadkom, w których wydawca używa stylów lub zapytań, które odwołują się do atrybutów o tej samej nazwie co twoje. Niestety Twój widżet może nadal kolidować ze stylami zdefiniowanymi przez stronę nadrzędną, nawet jeśli ich CSS używa identyfikatorów, nazw klas i atrybutów, które nie odnoszą się bezpośrednio do twoich elementów. Dzieje się tak dlatego, że niektóre reguły CSS są ważone przez przeglądarkę i mogą mieć pierwszeństwo przed pozornie niepowiązanymi regułami, które możesz zdefiniować. Zjawisko to jest określane jako specyfika CSS i musisz go najpierw zrozumieć, aby móc bezpiecznie renderować elementy na stronie wydawcy.

Wróćmy do przykładu kontenera z poprzedniej sekcji przestrzeni nazw. Załóżmy, że kod HTML wydawcy zawiera DIV najwyższego poziomu, który otacza całą jego zawartość, z identyfikatorem strony:

...
...

Dodatkowo załóżmy, że strona ma następujący kod CSS, gdzie pierwsza reguła jest zdefiniowana przez wydawcę, a druga reguła, kierująca do kontenera bociana, jest dodawana przez twój zewnętrzny skrypt:

/* Publisher */#page div {background-color: green;}/* Camera Stork */.stork-container {background-color: blue;}

Jaki kolor będzie miał .stork-container? Odpowiedź może szokować i przerażać: zielony. W tym prostym przykładzie reguła wydawcy (#page div) ma pierwszeństwo przed regułą klasy aplikacji innej firmy (.stork-container). Dzieje się tak, ponieważ przeglądarka waży reguły zawierające identyfikatory wyższe niż te, które są celem klas lub atrybutów.

Priorytety reguł CSS

Specyfikacja W3C CSS określa, w jaki sposób przeglądarki mają priorytetyzować różne typy reguł. Oto lista typów reguł, uporządkowanych od najwyższego priorytetu do najniższego:

  1. Style śródliniowe (style = "...")
  2. ID
  3. Klasy, atrybuty i pseudoklasy (: focus,: hover)
  4. Elementy (div, span i tak dalej) i pseudoelementy (: before,: after)

Zgodnie z tym wykresem style inline są ważone nad wszystkimi następnymi typami reguł: identyfikatorami, klasami i elementami. To logicznie kontynuuje listę, a identyfikatory mają wyższy priorytet niż klasy i elementy, i tak dalej. Jest jeden wyjątek od tej listy: właściwości oznaczane słowem kluczowym!! Mają najwyższy priorytet. Należy jednak pamiętać, że ważne słowo kluczowe wpływa na pojedynczą właściwość w ramach reguły, a nie całą regułę.

Co się dzieje, gdy masz wiele reguł CSS o tej samej wadze, z których każda może mieć wpływ na ten sam element? Rzućmy okiem na przykład:

Eat your vegetables!

Jak myślisz, jaki jest kolor przęsła? Odpowiedź znowu może być zaskakująca: żółty. Mimo że reguły te są oparte głównie na klasach, druga reguła (.storkcontainer span) jest uważana za bardziej szczegółową niż pierwsza reguła, a trzecia reguła (.stork-container .stork-msg) jest bardziej szczegółowa niż druga. Jak to działa?

Style Inline są królem

Pod względem specyficzności CSS. Jeśli pamiętasz wcześniej w tym rozdziale, wspomnieliśmy, że style wbudowane mają tę zaletę, że rzadko powodują konflikt ze stroną nadrzędną. Teraz jest jasne, dlaczego: mają pierwszeństwo przed wszystkimi innymi typami zwykłej reguły CSS (z wyjątkiem tych z ważnym słowem kluczowym!). Jeśli piszesz szczególnie prosty widżet, używanie stylów wbudowanych może nie być złym pomysłem; unikniesz większości konfliktów specyficznych dla CSS.

Przeglądarka używa prostego systemu punktacji, aby określić, która reguła ma pierwszeństwo. Dla danej reguły każdy selektor komponujący tę regułę jest wart pewnej wartości. Wartości te sumuje się, aby uzyskać wynik specyficzności. Gdy wiele reguł wpływa na ten sam element, przeglądarka porównuje wyniki poszczególnych reguł, a reguła z najwyższym wynikiem ma pierwszeństwo. W przypadku remisu wygrywa reguła zdefiniowana jako ostatnia. Atrybuty stylu pośredniego: 1000; ID: 100; klasy, pseudoklasy i atrybuty: 10, elementy i pseudoelementy: 1.

Tak więc, patrząc wstecz na nasz poprzedni przykład, te reguły CSS zostałyby przypisane następującym wynikom, przy czym najwyższa punktacja jest priorytetowana przez przeglądarkę: szybko zauważysz, że nie są to zwykłe liczby. Wynik specyficzności jest w rzeczywistości krotką formy (a, b, c, d), z czym jest bardziej wartościowa niż b, b jest bardziej wartościowa niż c, i tak dalej. Oznacza to, że styl spowodowany przez pojedynczy atrybut stylu inline (1, 0, 0, 0) ma wyższą specyficzność niż reguła ze sto wybieraniem identyfikatorów (0, 100, 0, 0).

  • .stork-container (selektor klasy 0,0,1,0-jeden)
  • .stork-container span (0,0,1,1-jeden selektor klasy, selektor jednego elementu)
  • .stork-container .stork-msg (0,0,2,0-selektory dwóch klas)

W tym momencie powinieneś dobrze zrozumieć, jak działa specyfika CSS i dlaczego przeglądarka nadaje priorytet niektórym regułom. W dalszej kolejności wykorzystasz tę wiedzę, ponieważ badamy niektóre podejścia do pisania CSS, które są wysokie w obliczu sprzecznych stylów wydawców.

Zbyt szczegółowe CSS

Pierwszym i najprostszym podejściem do pisania CSS, które nie jest w konflikcie ze stroną wydawcy, jest nadmierne określenie swoich zasad. Oznacza to deklarowanie dodatkowych selektorów w celu zwiększenia specyfiki reguł, tak, że gdy przeglądarka porówna Twoje reguły z regułami ze strony nadrzędnej, prawdopodobnie uzyska wyższy wynik i uzyska priorytet.

Spójrzmy na to w praktyce. Rozważmy ten poprawiony przykład kontenera widżetów bocianów, teraz zawierający dwa elementy kontenera, każdy z unikalnym identyfikatorem:

Mikon E90 Digital SLR

"/>

599 USD

4.3 / 5.0 • 176 recenzji

Towarzyszący CSS dla tego kodu HTML może wyglądać następująco:

#stork-main #stork-container { ... }#stork-main #stork-container .stork-product { ... }#stork-main #stork-container .stork-price { ... }

Przez redundancyjne określanie obu identyfikatorów kontenerów jako nadrzędnych selektorów wszystkich reguł CSS, skutecznie przypisujesz każdemu z reguł CSS minimalny wynik specyficzności (0,2,0,0). Następnie ogólna reguła #page wydawcy nie będzie już powodować konfliktu z widżetem, ponieważ używa tylko jednego identyfikatora. Żadne zasady czysto klasowe lub oparte na elementach nie będą w konflikcie, ponieważ są to cała klasa wagowa CSS poniżej identyfikatorów. Mimo że dla celów selekcji zupełnie niepotrzebne jest podawanie drugiego identyfikatora dla reguł, tutaj działa on jako skuteczne urządzenie do zwiększania specyficzności.

Zachowaj zdrowy rozsądek dzięki preprocesorowi CSS

Pisanie zbyt sprecyzowanych arkuszy CSS może być prawdziwą przeszkodą: musisz ciągle przepisywać te same identyfikatory w kółko dla każdej z reguł CSS. Możesz temu zaradzić za pomocą preprocesora CSS, który rozszerza język CSS o dodatkowe funkcje, takie jak możliwość deklarowania zagnieżdżonych hierarchii reguł. Na przykład, używając preprocesora LESS CSS, możesz napisać poprzedni przykład w ten sposób:

#stork-main {#stork-container {.stork-product { ... }.stork-price { ... }}}

Obecnie dostępnych jest wiele popularnych preprocesorów CSS, z których wszystkie mają różne zestawy funkcji. Wśród najbardziej popularnych są MNIEJ,Sass, i Rysik.

Z drugiej strony ten przykład wymaga, aby widget korzystał z kontenerów najwyższego poziomu z identyfikatorami, co nie będzie praktyczne w przypadku widżetów, które mogą być renderowane wiele razy na tej samej stronie. Co więcej, nadal nie jest odporna na kulki: wydawca może śledzić Twoją przewagę i zawyżać własne reguły CSS, co prowadzi do tego samego problemu, co wcześniej.

Jest to jednak mało prawdopodobny scenariusz, zwłaszcza, że ​​w każdej z reguł redundantnie określono dwa identyfikatory. Można ewentualnie użyć jednego, ale to oczywiście będzie bardziej podatne na zagrożenia. W rzeczywistości większość wydawców korzysta ze zdrowych reguł CSS, a zbyt szczegółowe określenie zasad będzie zgodne z większością z nich.

Zbyt szczegółowe CSS nie mieszają się z narzędziami jakości kodu

Jeśli podejmiesz się nadmiernego spreparowania swojego CSS w ten sposób, możesz znaleźć mało prawdopodobnego wroga: narzędzia, które oceniają jakość twojego kodu CSS, takie jak CSS Lint, Google Page Speed ​​i YSlow Yahoo. Narzędzia te będą wskazywać, że tworzysz nadmiarowe selektory CSS, a oni doradzą ci usunięcie takich selektorów, aby zmniejszyć rozmiar pliku i poprawić wydajność CSS przeglądarki. Niestety narzędzia te nie są programowane z myślą o skryptach stron trzecich i nie oceniają rzetelnie przydatności nadmiernie sprecyzowanego CSS. Korzyści z overspecification dla aplikacji innych producentów będą większe niż dodatkowy rozmiar pliku i malejący wpływ na wydajność.

Nadużywanie! Ważne

Jeśli uważasz, że nadmierne spreparowanie kodu CSS za pomocą dodatkowego identyfikatora lub selektorów klas nie idzie wystarczająco daleko, możesz przerwać opcję jądrową: ważne słowo kluczowe! Właściwości w ramach reguły CSS, w której ważne jest słowo kluczowe! Są priorytetowo traktowane jako najwyższe ze wszystkich, nawet powyżej stylów śródliniowych. Dzieje się tak, ponieważ ważne słowo kluczowe zostało zaprojektowane tak, aby dać użytkownikom przeglądarki pewny sposób na zastąpienie stylów "autora" (wydawcy) w przypadku wtyczek do przeglądarek lub stylów site-specific. Możesz nadużywać! Ważne, używając go we wszystkich swoich właściwościach CSS, skutecznie ustalając priorytety nad wszystkimi innymi regułami.

Oto jak możesz użyć ważnego słowa kluczowego! Na jednej regule CSS:

.stork-price {font-size: 11px !important;color: #888 !important;text-decoration: none !important;display: block !important;}

Ponieważ jest to na właściwość, ważne słowo kluczowe musi być powtarzane w ten sposób, co może stać się przeciągnięciem po długim i złożonym arkuszu stylów. Ale w zamian dostajesz solidny zestaw arkuszy stylów, których resetowanie przez stronę wydawcy jest bardzo mało prawdopodobne.

Nadal można sobie wyobrazić, że wydawca może z kolei użyć !, aby celować w elementy i ustawić własne style, i wtedy prawdopodobnie celowo celują w elementy w celu dostosowania. Z jednej strony może to być frustrujące, jeśli chcesz zachować spójny wygląd i styl. Jeśli jednak zdecydujesz się zezwolić wydawcom na dostosowanie widgetu, jest to prawdopodobnie pożądane zachowanie.

Jedno powinno być jasne: dzielenie DOM z wydawcą może szczególnie utrudniać renderowanie spójnego widżetu. Mimo że możesz podjąć kroki, aby zawęzić reguły CSS w celu zmniejszenia prawdopodobieństwa konfliktów, wydawca może zawsze celowo i celowo kierować swoje elementy za pomocą reguł.

Ale jeśli dzielenie DOM z wydawcą jest przyczyną tak wielkiego smutku, czy możliwe jest wyrenderowanie widżetu z DOM? Dlaczego, tak, tak, możesz.

Podsumowanie

W przypadku aplikacji JavaScript innej firmy wstrzykiwanie kodu HTML i CSS na stronę wydawcy wymaga większej ostrożności niż w przypadku dodawania znaczników do "bezpiecznego" środowiska. Musisz upewnić się, że podczas wysyłania HTML do strony, nie spowalniasz strony z operacją blokowania. Musisz również wziąć pod uwagę, że twój skrypt może zostać dołączony wiele razy na tej samej stronie i powinien z wdzięcznością renderować wiele wystąpień. Dodatkowo powinieneś wybrać optymalną metodę wstrzykiwania CSS na stronę wydawcy - albo poprzez wstawianie wszystkich stylów, dołączanie elementów linków, albo osadzanie reguł CSS w JavaScript.

Ale samo pobranie kodu HTML i CSS na stronę nie wystarczy. Musisz wiedzieć, że elementy wprowadzone do DOM mogą być w konflikcie ze stroną nadrzędną. Musisz także zastanowić się, w jaki sposób Twoje style mogą kolidować z istniejącymi stylami zdefiniowanymi przez wydawcę. Możesz użyć wielu technik, aby zredukować wpływ stylów rodzicielskich na widżet: poprzez nadmierne spreparowanie reguł CSS lub zaprezentowanie zawartości za elementem iframe, bez ramek src-less lub takich, które zawierają zewnętrzny dokument HTML.

Jakich technik używasz przy tworzeniu CSS i HTML dla stron trzecich? Czy kiedykolwiek wróciłeś! Ważne? Daj nam znać w komentarzach.

Wyróżniony obraz / miniatura, obraz obronny przez Shutterstock.