Walidacja kodu jest istotna. Nieważne czy powodem jest chęć wyszlifowania w sobie dobrych nawyków, czy po prostu zwykła i naturalna potrzeba poprawienia napisanego przez siebie kodu. Co jednak jeżeli tworzysz stronę wg. przyjętych w specyfikacji zasad, z dumą chcesz umieścić na niej odnośnik potwierdzający poprawność kodu zawierającego animację Flash i nagle spotka Cię niemiła niespodzianka? I wszystko poprzez krążące po zaułkach Internetu niepoprawne konstrukcje osadzania wcześniej wymienionej technologii...

W jaki sposób poprawnie implementować Flash? Jakich zastępczych metod można używać? Co jest sprawcą tego, że z reguły nasz kod jest nieprawidłowy? Ten artykuł odpowie Ci na wszystkie powyższe pytania...

Internet źródłem nieprawidłowego rozwiązania...

Pomimo tego, że treści dostępne w kanonach sieci są podatne na "proces edukacji" i powoli zmieniają swoją zawartość na coraz to bardziej prawidłową, to nadal można znaleźć wiele wyników wyszukiwań które są rozwiązaniami błędnymi. Tak jest także z tematyką poruszaną w tym wpisie.

Oto przykład jednej z nieprawidłowych solucji. Problemem jest tu znacznik embed który nie jest, ani częścią specyfikacji HTML4, ani XHTML1.x, a jedynie naleciałością wprowadzoną kiedyś przez programistów Netscape Navigatora. Ponieważ jednak jest on wspomagany także przez przeglądarki takie jak Opera, Firefox, Safari, czy Internet Explorer przyjęło się pospolicie użytkowanie powyższego, nieprawidłowego rozwiązania (a wszystko za sprawą nieszczęsnego, kapitalistycznego marketingu w postaci bezmyślnego kopiowania danego artykułu ze strony na stronę i czerpania z tego korzyści). Niekiedy można napotkać także poradę w której embed znajduje się w tagu object, które w takim połączeniu jest także błędne.

Ciut teorii: embed - jest znacznikiem wykorzystywanym do wstawiania obiektów typu plugin do kodu strony. Niezgodny z specyfikacją HTML4 i XHTML1. Obsługiwany jednak przez Firefoksa 1.0+, Mozille 0.6+, Operę 3.0+, Safari, Netscape Navigatora 1.0+ i Internet Explorera 3.0+. Obsługuje atrybuty class, dir, hidden, hspace, id, lang, name, pluginpage, src i style. Używany często wraz z noembed (także niezgodnym z w.w. specyfikacjami) którego zawartość wyświetlana jest w momencie kiedy przeglądarka nie obsługuje embed.

Przykład:

W wyniku, po wykonaniu walidacji otrzymamy kilka błędów związanych z użyciem właśnie tego, nieprawidłowego tagu.

Osadźmy więc poprawnie...

Jeżeli chcemy kierować się zaleceniami specyfikacji to musimy skupić się jedynie na znacznikach object z zaaplikowanymi wewnątrz sparametryzowanymi tagami param (metoda nazwana Flash Satay). Od tego momentu embed przechodzi w niepamięć, bo tak naprawdę wszystko co dzięki niemu mogliśmy osiągnąć, będziemy mogli stworzyć także poprzez naszą nową formułę.

Kilka słów wyjaśnienia o głównym obiekcie naszych zainteresowań: object - pozwala na wstawienie do dokumentu obiektu multimedialnego. Zaimplementowany w przeglądarkach Firefox 0.1+, Opera 4.0+, Mozilla 0.6+, Safari, Netscape Navigator 6.0+ i Internet Explorer 3.0+. Służy za zamiennik m.in. dla niepoprawnych bgsound, czy embed. Znacznik ten jest częścią specyfikacji HTML 4.01 Strict/Transitional/Frameset, XHTML 1.0 Strict/Transitional/Frameset oraz XHTML 1.1. Obsługuje atrybuty takie jak: accesskey, archive, class, classid, codebase, codetype, data, dir, id, lang / xml:lang, name, style, title, type i xmlns.

Przykład:

Tak więc, aby wkomponować w naszą stronę obiekt Flash musimy określić co najmniej typ tego obiektu (type), plik źródłowy (data) i ostylować jego wymiary (style). Z podanej listy typów MIME dostrzegamy, że pożądanym przez nas jest application/x-shockwave-flash. Należy zwrócić uwagę na fakt, że nie korzystamy w ostatnim przypadku bezpośrednio z parametrów height oraz width, a idąc z duchem czasu wykorzystujemy po prostu możliwości wewnętrznego arkusza stylów.

Teoretycznie o parametryzacji: param - pozwala na wprowadzenie parametrów do obiektów (object) i apletów (przestarzale za pomocą applet, bądź aktualnie także za pomocą object). Każdy z takowych parametrów musi być ustawiony w osobnym znaczniku param. Jest zgodny z dokumentacją HTML 4.01 Strict/Transitional/Frameset, XHTML 1.0 Strict/Transitional/Frameset oraz XHTML 1.1, a także obsługiwany w przeglądarkach Firefox 0.1+, Opera 4.0+, Mozilla 0.6+, Netscape Navigator 6.0+ i Internet Explorer 3.0+. Obsługuje atrybuty takie jak: id, name, value oraz xmlns (tylko dla XHTML).

Przykład dla XHTML 1.0:

Przykład HTML:

Aby mieć pewność, że każda nowoczesna przeglądarka będzie poprawnie egzekwować tą metodą powinniśmy użyć dodatkowo kilku nazw parametrów. W naszym przypadku będą to kolejno ścieżka wraz z nazwą pliku animacji Flash (movie), a także jakość (quality). Nie są to oczywiście wszystkie dostępne własności. Przede wszystkim wśród nich możemy wyróżnić:

• play przyjmujące wartość true (domyślne) / false określające, czy animacja ma być odtwarzana wraz z załadowaniem strony.
• loop przyjmujące także wartość true (domyślne) / false określające, czy animacja ma być wyświetlana ponownie w pętli po zakończeniu poprzedniego odtwarzania.
• bgcolor przyjmujące wartość #rrggbb i określające (szesnastkowo) kolor tła.
• menu przyjmujące wartości true (menu z dodatkowymi funkcjami) / false.
• quality przyjmujące wartości best (najlepsza jakość wraz z Anti-Aliasingiem dla wszystkich elementów), high (występuje Anti-Aliasing, ale wygładzanie jest tylko w przypadku statyczności elementów), autohigh (w przypadku spadku wydajności usuwa Anti-Aliasing w celu zachowania poziomu szybkości animacji), medium (podobnie jak w poprzednim przypadku, ale bez wygładzania), low (najsłabsza jakość bez A-A) i autolow (Anti-Aliasing włączany jest dopiero w przypadku kiedy pozwalają na to zasoby w takim stopniu, aby nie pojawił się znaczy spadek poziomu prędkości działania animacji).
• scale przyjmujące wartości exactfit (klip dopasowany jest do podanych wymiarów), noborder (dopasowuje proporcjonalnie skalując animację do obszaru) i showall (wyświetla w podanym obszarze bez zmian w proporcjach).
• allowscriptaccess nadaje prawa do wykonywania skryptów od szóstej wersji Flasha. Mianowicie: always zezwala na wykonywanie wszystkich skryptów, never nie zezwala, a samedomain pozwala tylko na te dostępne w obrębie poruszanej się domeny.

Ponieważ, jak już pewnie zauważyliście wewnątrz najbardziej zagnieżdżonego znacznika object można (lecz oczywiście nie trzeba!) umieścić po jego parametrach alternatywnie wyświetlany kod to w naszym przykładzie wyświetlimy w takim wypadku grafikę o takich samych rozmiarach.

Powyższy przykład będzie poprawny dla kodu XHTML. Dla czystego HTML-a należy formę zminimalizowaną parametrów oraz opcjonalnej grafiki ( />) zamienić na tradycyjną, bądź w ogóle tych znaczników nie zamykać.

Zapraszam do przejrzenia przykładu implementacji metody.

Rozwiązanie problemów z ładowaniem dużych plików

W wypadku klipów o sporej wadze powyższa metoda ma jeden mankament. Dopóki plik nie zostanie w całości załadowany animacja nie zostanie odtworzona.

Można temu zapobiec tworząc prosty loader, także korzystając z Flasha. Tworząc nowy dokument (rozmiary mogą być minimalne, np. 10x10px) wystarczy w jego pierwszej klatce dodać następujący kod ActionScript:

Przy eksporcie do pliku wymagane jest, aby dokonywać go korzystając z ActionScript 1.0 (AS), a w opcji Local playback security: należy wybrać Access local files only. Archiwum z plikiem źródłowym i wynikowym znajduje się tutaj.

Dla nowszych AS, na przykład trójki powyższy przykład nie zadziała. Należy posłużyć się za to klasą Loader.

Na koniec zostaje jeszcze jedna zmiana do wykonania. W znaczniku object oraz w jego parametrach należy zmienić ścieżki do pliku na loader.swf?path=skompilowany_flash (bez rozszerzenia). Oczywiście w tym wypadku obydwa pliki muszą znajdować się w jednym i tym samym katalogu.

Zastępcze sposoby oparte na JavaScriptcie i komentarzach warunkowych...

Jeżeli Twoim audytorium mają być osoby korzystające z czytników ekranowych (JAWS) to cały mój wywód poszedł na marne, bo po prostu nie zadziała. Nie zostawię Was jednak na lodzie. Wystarczy skorzystać z jednego z poniższych rozwiązań.

Pierwsze, SWFObject 2.1 ogranicza się do pobrania pliku klasy, wprowadzenia opcjonalnych zmiennych i wywołania metody wraz z argumentami która przypisze wynik do elementu o odpowiednim ID. Niestety wymaga włączonej obsługi JavaScript w przeglądarce użytkownika. Pełnej dokumentacji można zasięgnąć tutaj.

Na podobnej zasadzie działa Unobtrusive Flash Objects. Została ona jednak oficjalnie uznana za przestarzałą na rzecz wcześniej opisanego rozwiązania.

Drugi sposób zagnieżdżania oparty jest na ukrytych komentarzach warunkowych. Nested Objects, bo o nim mowa pozwala na określenie jakie przeglądarki nie powinny korzystać z kluczowego w tym wpisie sposobu. W przykładzie przeglądarki IE nie będą mogły używać rozwiązania opartego na Flash Satay.

Oczywiście odpowiednio modyfikując ujęte w kodzie komentarze warunkowe możemy manipulować tym która przeglądarka, które rozwiązanie będzie mogła stosować.

Podsumowując...

Na pewno buszując po otchłaniach Internetu spotkalibyście jeszcze kilka innych, mniej lub bardziej profesjonalnych rozwiązań. Pomimo, że te które tym razem zaprezentowałem działały bez większego zająknięcia na Operze 9.62, Firefoksie 3.0.4, Safari 3.2, a nawet na diabelnie niepokornym Internet Explorerze 7 to chociażby dla pogłębienia swojej wiedzy warto się zainteresować pozostałymi metodami.

Oczywiście wykorzystanie object i param nie musi tylko i wyłącznie służyć do obsługi Flasha. Operowanie na filmach, muzyce, czy grafice to tylko przykłady możliwości tych znaczników. Wystarczy poeksperymentować i zapamiętać jedną rzecz... embed od dziś odchodzi w niepamięć...

copyright © 2008, m1chu

udostępnione na licencji CC dla vivee.info i m1chu.eu