Komentarz to, czy może skrypt?

Przenosząc się na Joggera straciłem sporo czasu na dochodzenie czemu skrypty, które zamieszczałem nie działały tak jak powinny (tzn. nie działały w ogóle). Okazało się, że zależnie od typu MIME strony skrypty są różnie interpretowane. A dokładniej mechanizmy ochrony skryptów.

Ze względu na przeglądarki nie rozumiejące tagu script przyjęło się kod skryptu umieszczać w komentarzu. Przeglądarki wspierające skrypty domyślały się, że to tak naprawdę kod skryptu i jakoś sobie z tym radziły. Ku memu lekkiemu zdziwieniu odkryłem, że Opera i Firefox przestają wykonywać kod skryptu, gdy strona jest dostarczona jako application/xhtml+xml. Aby sprawę zbadać bardziej szczegółowo stworzyłem taką oto stronę testową:

<?php
$type = isset($_GET['xml']) ? 'application/xhtml+xml' : 'text/html';
header('content-type: ' . $type . '; charset=iso-8859-2');
?>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
          "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Test</title>
  </head>
  <body>
    <p>Wysłany nagłówek Content-Type: <tt><?php echo($type); ?>;
        charser=iso-8859-2</tt>.</p>

    <script type="text/javascript"><!--
       alert('Skrypt "chroniony" komentarzem.');
    //--></script>
    <script type="text/javascript">alert('"Goły" skrypt.');</script>
    <script type="text/javascript"><![CDATA[
      alert('Skrypt "chroniony" przez CDATA.');
    ]]></script>
  </body>
</html>

Okazuje się, że wysyłając stronę jako text/html wykonują się dwa pierwsze, a jako application/xhtml+xml dwa ostatnie skrypty. Co to oznacza w praktyce? Otóż, mamy do wyboru:

wysyłanie typu text/html i wówczas naszemu dokumentowi XHTML będą towarzyszyły niepoprawne nagłówki,
wysłanie typu application/xhtml+xml i wówczas niektóre przeglądarki (np. IE) będą miały kłopoty z wyświetleniem strony,
zastosowanie negocjacji typu MIME i pozostawienie gołych skryptów ~~powodując tym samym, że strona przestanie się walidować (chyba, że w kodzie skryptu nie będzie używany znak mniejszości, większości ani etka)~~(update: okazuje się, że coś mi się pomyliło z tym, że walidator W3C odrzuca takie dokumenty),
zastosowanie negocjacji i sprytnego mechanizmu po stronie serwera, który będzie stosował odpowiednie sekwencje otwierające i zamykające skrypt albo
zastosowanie negocjacji i trzymanie wszystkich skryptów w plikach, dołączanych do strony za pomocą elementu script z atrybutem src.

Cóż rzec... takie uroki XHTML-a.

Dodano:2008/02/12, 22:45
trackback

W kategoriach:

Słowa kluczowe:

Komentarze

Powrót do „Skocz do”

»» Michał Górny

Dodano:2008/02/12, 23:03

Jeszcze była jakaś metoda z zastosowaniem jednocześnie CDATA i komentarza. O ile dobrze pamiętam, to chyba otwarcie i zamknięcie komentarza się pakowało w CDATA ( ;.

»» brtk

Dodano:2008/02/13, 07:36

Zapomniałeś o jednym: skrypt można dołączyć w oddzielnym pliku.

Poza tym chyba nie ma już przeglądarek, które nie wiedzą co to <script>, więc te komentarze ochronne można olać.

»» mina86

Dodano:2008/02/13, 14:37

O… rzeczywiście. Wydawało mi się, że walidator się burzył, a okazuje się, że nie.

Co do plików zewnętrznych to nie zapomniałem--ostatni punkt.

»» D4rky

Dodano:2008/02/13, 20:55

i ostatni punkt jest jako jedyny semantyczny. inline-script jest ble i nie powinno sie go stosowac, po to bozia dala zewnetrzne pliki ;]

»» mina86

Dodano:2008/02/13, 20:58

To znaczy, jeżeli chce umieścić jakiś skrypt na jednej tylko stronie i skrypt ten jest bardzo króciutki (kilka linijek, kilkaset bajtów) to mam dla niego tworzyć nowy plik i zmuszać przeglądarkę, aby bezsensownie wysyłała kolejne zapytania do serwera? Moim zdaniem po to bozia dała inline-script, żeby jest stosować tam gdzie ma to sens.

»» D4rky

Dodano:2008/02/13, 20:59

mina86 – tak, po to masz zmuszac przegladarke, aby bezsensownie wysylala kolejne zapytania do serwera. Tak samo powinenes CSS trzymac w osobnym pliku i to nie ma znaczenia czy plik ma 1, 2 czy 50 KB. Rules are rules ;)

»» mina86

Dodano:2008/02/13, 21:04

CSS trzymam w osobnym pliku, gdyż jest on wspólny dla wielu stron. Gdybym tworzył pojedynczy plik XHTML i miał do niego tworzyć style to zapisałbym je wewnątrz tego pliku zamaist bawić się w kolejne. Nie znam zasady, która nakzuje trzymanie skryptów i styli w osobnych plikach, robię tak gdy ma to sens.

»» Michał Górny

Dodano:2008/02/13, 21:06

D4rky: Patrz: MTU.

»» mcv

Dodano:2008/02/19, 20:47

Przeglądarki poprawnie interpretują kod, wycinając to co jest w komentarzu XML <!— … —>, czyli skrypt. ;-)

Poprawne rozwiązanie to:
<script …> // <![CDATA[ …
// ]]></script>

Przeglądarki nie rozumiejące XHTML-a (XML-a) zignorują tagi sekcji CDATA, bo są one zakomentowane (a raczej zinterpretują jako kod JS, który jest… zakomentowany). Te rozumiejące najpierw przepuszczą stronę przez parser XML, który już zadba o to by sekcje CDATA były zrozumiane jako tekst.

»» BLACK CAT

Dodano:2009/02/26, 16:31

Zastosowanie wprowadzenia w pierwszym wpisie pisanej (pierwszej linijce kodu) strony html czy htm oznaczenia skryptu php i jego forma jest zalezna od specyfikacji DTD, do której się odwołujesz za pomocą <DOCTYPE ......> w następnej lini kodu i do ich przeczytania odsyłam. Ogólnie jeżeli skrypt pojawia się jako załączony plik zewnętrzny to tylko strony xhtml wymagaja wpisu, którego użyłeś w przykładowej stronie testowej i dlatego jest to częściej stosowana metoda. Jeżeli wprowadzasz kod za pomocą pliku zewnętrznego, to większość przeglądarek świetnie sobie z tym poradzi bez wspomnianej pierwszej linijki – parser „przeskoczy” na obsługę php bezproblemowo. Warto pamiętać, że jeżeli chodzi o instrukcję przetwarzania kodu <script></script> to w przypadku php nawala na maxa i lepiej tego nie stosować. Nadmienię jedynie, że w przyszłości XHTML/XML całkowicie ma zostać wyłączona wspomniana tu instrukcja przetwarzania kodu <script> oraz jakakolwiek możliwość załączania skryptów bezpośrednio do kodu html czy htm. Więc już polecam zewnętrzne pliki i jeszcze raz odsyłam do specyfikacji.

Treść (markdown)

Nick		URL
Kod:

mina86.com