Zrobiłem trochę testów dla bety najnowszej przeglądarki Microsoftu pod względem jej wykrywania i ustalania stosownych trybów na podstawie nagłówka HTTP. Efekty są nawet ciekawe.
Jak zapewne część osób się zorientowała, wspomniana beta ma guzik do przełączenia się w tryb IE7. Jeśli będzie on aktywny, string UA zostanie ustawiony na IE7, podobnie będą też reagować komentarze warunkowe. Przełącznik nagłówkowy będzie jednak działał, więc będzie możliwość aktywowania trybu IE8.
Oczywiście, jeśli przeglądarka będzie pracowała w trybie standardowym, stringi UA będą wyświetlane poprawnie, podobnie jak komentarze warunkowe. Ciekawe wydaje mi się też zachowanie dla nagłówków dla IE 6, jest chyba takie samo, jak dla IE5. Nowa metoda ustawiania zachowania przeglądarki nadpisuje przełączanie na podstawie doctype.
Zastanawiam się, jak duży procent ludzi będzie używało IE w tryb zgodności z IE 7. Część producentów komputerów może bowiem domyślnie taką opcję ustawiać. Swoją drogą kliknięcie jednego guzika jest dużo łatwiejsze od instalacji całej przeglądarki, jaką jest Firefox. A niestety takie zachowanie będzie poprawiało działanie znacznej części stron w Internecie.
Cóż, będzie można trochę manipulować statystykami, a właściwie będzie trzeba. Ponadto będzie trzeba uważać, aby nie popsuć strony w jednym z trybów IE8, a jednocześnie nie zapomnieć o jego poprzednikach.
Zasadniczo są dwie drogi do wyboru: 1.Sprowadzić IE8 do poziomu IE7. 2.Respektować wewnętrzny przełącznik IE8 na IE7.
Pobawiłem się znowu trochę w osadzanie SVG na stronach. Wniosek? Cóż, nie dziwię się, że ów standard zdobywa tak wolno swoją popularność. Na razie zamieszczam link do strony z testem. http://www.michas.eu/mc_lab/svg-test/
Czas mija, niedawno usłyszałem, że Flash wzbogaci się o wsparcie MPEG-4 AVC/h.264. A przeglądarki z natywną obsługą Ogg Theora, jak nie było, tak nie ma. Cóż, są jednak też pewne pozytywne ruchy na scenie. Microsoft postanowił stworzyć własne, międzyplatformowe środowisko programistyczne do osadzania w przeglądarkach WWW, nazywać się ma chyba Silverlight. Owe środowisko ma posiadać wsparcie dla kodeku VC-1, którego jakość jest porównywalna z wyżej wymienionym, nowym kodekiem video we Flashu. Oczywiście plugin dla X Linuksa musi poczekać. Niemniej jednak jest to zawsze zwiększenie konkurencji na rynku. Dzisiaj zdecydowanie zbyt wiele ludzi błędnie myśli, że Flash jest integralną częścią przeglądarki. Nowy gracz może sprawić, że ludzie odpowiedzialni za tworzenie serwisów internetowych zwrócą większą uwagę na wszystkie, dostępne technologie, w tym natywną obsługę video, kiedy ta się tylko pojawi. Kolejnym, pozytywnie mnie napawającym aspektem jest Snow. Jest to mało znany kodek, w dość wczesnej fazie rozwoju i o dużych wymaganiach podczas odtwarzania. Niemniej jednak jest, a jego stosunek kompresji jest lepszy, niż w przypadku Ogg Theory. Zawsze to jeden kodek więcej, o obsługę którego można wzbogacić przeglądarkę. Zastanawiam się jeszcze, czemu QuickTime i standardowy plugin Microsoftu nie zrobiły takiej kariery. Oferowały przecież zdecydowanie lepszą kompresję, niż Flash 7. Były mniej popularne? Fakt, ale to była tylko nieznacznie mniejsza popularność. Może koszt licencji? Może brak możliwości wpływu na wygląd interface'u? Może gorsze narzędzia do kodowania video? Cóż, oby coś się na tym rynku pozytywnego dla mnie stało. Niestety z dnia na dzień tracę na to nadzieję...
Człowiek ma ograniczenia i może wygodnie czytać tekst o pewnej, ograniczonej szerokości. Ekran monitorów komputerowych takich ograniczeń nie ma i przy obecnej wielkości zrobił się zaś zdecydowanie zbyt szeroki. Cóż, twórcy stron WWW musieli jakoś temu problemowi zaradzić.
Najczęściej chyba decydowano się na zastosowanie układu wielołamowego. Problem w tym, że główna treść zmieściła się w jednym łamie. Pozostałe mogły być więc wykorzystane na różne, mało istotne informacje. Zastanawiam się jednak, czemu zaśmiecać nimi ekran? Czemu nie zastosować rozwiązania minimalistycznego i wysłać tylko te informacje, o które zostaliśmy poproszeni?
Cóż. Co więc zrobić z pozostałym miejscem? W sumie czemu nie wyświetlić w nim innej strony? Mamy systmy okienkowe, więc można wyświetlić dwa okna przeglądarek. W dodatku od dawna na rynku są aplikacje, które w jednym oknie potrafią wyświetlić na raz kilka stron. Jeśli ktoś by nie chciał wyświetlać kilku stron na raz, może obok odpalić inną aplikację. Małe okienko telewizji internetowej, względnie małe okienko chatu, czy jakiegoś komunikatora. Możliwości jest bardzo dużo. Na dzień dzisiejszy nikt prawie tego nie robi, bo same strony niepotrzebnie wymagają dużych powierzchni ekranu.
A co zrobić w sytuacji, kiedy ktoś otworzy taką wąską stronę w zmaksymalizowanym oknie przeglądarki? Rozciągnięcie treści na cały ekran jest bardzo złym pomysłem. Najlepiej wyświetlić po bokach dwa czarne pasy. Dla znacznej części monitorów będzie to ulga. Zmęczony student w środku nocy też będzie wdzięczny.
Redukcja szerokości strony i ograniczenie się do minimum, jeśli chodzi o wyświetlane informacje, zasugerowało mi stworzenie też zminimalizowanego menu. Z tymi wytycznymi postanowiłem przystąpić do tworzenia serwisu informacyjnego. Na razie istnieją dwie implementacje: http://info.komikslandia.pl/ - Serwis komiksowy http://michas.eu/info/ - Moja strona
Cóż, w dzisiejszych czasach technologia Flash jest tak popularna, że teraz to użytkownik, a nie webmaster, musi się o jej obsługę martwić.
Cóż, z faktami się nie dyskutuje. Można jednak się zastanawiać, jak pozbyć się tego problemu. W informatyce zazwyczaj rozbija się duży problem na mniejsze i dopiero owe mniejsze problemiki rozwiązuje. Nie widzę powdów, aby i nadmierną popularności Flasha rozwiązać tą metodą. Czyli na czym stoimi?
Reklamy Flash To chyba jedyna dziedzina, która ulegnie samorozwiązaniu, jak rozwiąże się wszystkie pozostałe. W dodatku akurat użytkownikom nie zależy, aby reklamy działały, więc ten dział można pominąć.
Gierki Flash Cóż, tworzenie gierek opartych na standardowych możliwościach przeglądarek to raczej ciekawostka, niż cokolwiek innego. W dodatku zagwarantowanie ich działania w konkurencyjnych produktach często jest bardzo kłopotliwe. W najbliższej przyszłości do tego zastosowania Flash będzie się zdecydowanie lepiej nadawał. Na szczęście owe gierki są sprawą dość marginalną i można je pominąć.
Filmy Tutaj rozwiązanie na szczęście jest. Można zaimplementować w przeglądarce wsparcie dla Ogg Theora. Jeśli dać użytkownikom narzędzia do ręcznej, precyzyjnej konwersji ich filmów na ten format, oraz narzędzia do tworzenia własnych interface'ów do odtwarzacza, co w przypadku konkurencyjnych technologii jest zbyt kosztowne, mamy chyba rozwiązane systemy społecznościowe.
Koejną zaletą jest to, że dzięki całkowitej otwartości kodeka, przy odrobinie dobrej woli ze strony producentów sprzętu i przeglądarki WWW, będzie można zapewnić płynne odtwarzenie Theory przy minimalnym zapotrzebowaniu na moc sprzętu. W przypadku technologii Flash, bez otwierania jej źródeł, nie da się tego zrealizować.
Jeszcze tylko zrobić stosowny plugin dla przeglądarek Microsoftu i (może) Apple. W każdym razie, im szybciej dostaniemy stosownie udoskonalone przeglądarki, tym lepiej. Uczciwie trzeba jednak przyznać, że na chwilę obecną Ogg Theora nie prezentuje najwyższej wydajności kompresji.
Audio Skoro jest rozwiązanie dla video, automatycznie jest też rozwiązanie dla audio. Jeśli jednak kodek Ogg Theora nie należy do czołówki, o tyle kodek Ogg Vorbis jest już jednym z najlepszych. Cóż, tylko czekać na stosowne przeglądarki i pluginy.
Wykresy Cóż, wykresy to grafika wektorowa. Powiedziałbym nawet, że esencja grafiki wektorowej. Technologia SVG chyba już w tej chwili jest w stanie przejąć na siebie ten ciężar. Tym bardziej, że bez większych problemów, w dowolnym języku można stworzyć stosowne skrypty je generujące. Tylko ten nieszczęsny plugin dla przeglądarki Microsoftu... Inna sprawa, że Flash się (chyba) nie zadomowił na tym polu dostatecznie.
Inna grafika wektorowa Jakoś tak większość schematów, która idealnie pasuje do zostania grafiką wektorową, jest robiona jako grafika rastrowa. Jakoś nie mogę sobie przypomnieć przypadku, aby było inaczej. No, czasami są robione jako pliki pdf, co jednak też nie jest zbyt dobrym rozwiązaniem. W każdym razie, im na tym polu SVG wcześniej się pojawi, tym lepiej. Czyli znowu ten brak pluginów dla przeglądarki Microsoftu...
Animowane ozdobniki Animacje Flash są czasami stosowane jako różnego rodzaju ozdobniki na stronach. Drobny element, który coś się tam rusza. Cóż, SVG jest już w tej chwili w stanie przejąć te zadanie. Pozostaje tylko problem z pluginami do przeglądarki Microsoftu. Aczkolwiek w tym wypadku nie ma specjalnie argumentów za zmianami. Poza tym wspomniane zastosowanie jest dość marginalne.
Całe serwisy w technologii Flash Chyba najgorsze zastosowanie technologii Flash w Sieci. W przypadku filmów niestety to chyba już standard, że cały, oficjalny serwis jest tak zrobiony. Cóz, może to i ładnie wygląda, może nie trzeba się martwić się o zgodność z różnymi przeglądarkami, wygodne w nawigacji i czytaniu to to jednak nie jest. Może, jak zostaną rozwiązane problemy z audio i video na stronach www, ktoś zacznie jednak tworzyć takie serwisy w konwencjonalnych technologiach. Ten problem będzie trzeba chyba zostawić sobie na sam koniec.
Podsumowanie Trzeba jak najszybciej wprowadzić obsługę Ogg Theora i Ogg Vorbis do przeglądarek. Trzeba też zrobić stosowne pluginy dla zacofanej przeglądarki Microsoftu. W sumie może to zrobić zarówno Opera, jak i Mozilla. Zawsze to dodatkowa reklama dla tych przeglądarek. Do tego czasu, jedyną rzeczą, jaką mogą robic webmasterzy, to stosować SVG, gdzie się tylko da.
Trochę wcześniej napisałem o koncepcji, aby odnośnie reklam zastąpić obiekty Flash przez obiekty Html. Cóż, trafiła mi się okazja, aby zrealizować to w praktyce. Oczywiście na małą skalę. Właściwie zrobiłem tylko obrazek, który jest co pewien czas zakrywany przez napis. Obrazek i tekst są oczywiście linkami. Bardzo prosty kod JS. I tutaj pojawił się problem.
Oczywiście ową stronkę umieściłem za pomocą tagu object. Co się stało po kliknięciu na link w takim obiekcie, łatwo się domyślić. Nowa strona faktycznie otworzyła się, ale tylko wewnątrz obiektu. Takie zachowanie nie było akceptowalne, więc trzeba było coś z tym zrobić.
Rozwiązanie 1. Można zastosować owczywiście wersję html/xhtml frameset. W tej wersji jest atrybut target, który może sprawić, że linki będą działały dla całego okna strony. Niestety uparłem się, że będę stosował tylko wersję strict. Ostatecznie więc nie testowałem.
Rozwiązanie 2. Można pobawić się w Java Script. Do wszystkich linków można przypisać specjalną funkcję na kliknięcie. Funkcja ta będzie pobierała wartość parametru href i aplikowała ją do adresu dokumentu nadrzędnego. Kilka linijek więcej i dostałem kod, który powinien teoretycznie działać. Niestety Opera i Firefox upierały się przy stosowaniu standardowego linku html. Jedna linijka kodu więcej i usunięcie atrybutu href skutecznie zniechęciło obie przeglądarki.
Niestety Internet Explorer okazał się znacznie bardziej problematyczny. Podmiana adresu w dokumencie macierzystym skutkowała podmianą adresu w dokumencie, z którego skrypt był wywoływany. Czytanie adresów jakoś tej przeglądarce jednak dobrze wychodziło. Niestety nie miałem pomysłu, jaką właściwość można sprawdzić, aby wykryć ten błąd. Pozostała mi więc ostateczność, czyli wykrycie po user.agent...
Rozwiązanie 2.1. Dodałem wykrycie, czy w UA nie ma przypadkiem siągu MSIE. Sprawdziłem też, czy nie jest to przypadkiem Opera (window.opera). W takim wypadku, zamiast owego, specjalnego kodu otwierającego adres w stronie macierzystej i kasującego atrybut href, dodaję tylko atrybut target="_blank" do samego linku ("_top" nie działał). W sumie efekt jest akceptowalny: otwiera się w nowym oknie, ale to Internet Explorer.
Rozwiązanie 2.2. Przypomniałem sobie o przypisywaniu zdarzeń pod różne elementy. Microsoft wymyślił sobie własny sposób, który postanowiłem zastosować do wykrycia tej przeglądarki. Jest to pewniejsze od wykrywania po UA, a nawet łatwiejsze w implementacji. Poza tym bez zmian w stosunku do 2.1.
Podsumowanie. Ostatecznie kod Java Script zrobił się trochę złożony. Za to można na takiej reklamie klikać normalnie i środkowym klawiszem myszy. W dodatku roboty, jeśli wczytają obiekt html, nie będą miały problemów z zaindeksowaniem strony, na którą wskazuje. Ponadto taka reklama działa w Operze Mini. Pozostał tylko mały problem. Co się stanie, jak ktoś wyłączy Java Script i nie kliknie środkowym klawiszem?
Adobe ma teraz swój plugin Flash. Microsoft postanowił też zmajstrować własną wtyczkę. Oba rozwiązania mają tą bardzo poważną wadę, że są bardzo zależne od pojedynczych producentów. Jak ktoś posiada jakiegoś Linuksa albo coś jeszcze mniej popularnego, to zaczyna go taki stan rzeczy boleć.
Można jednak siebie zapytać, czego brakuje standardom, które są blisko związane z WWW, że dorzuca się do nich te pluginy. Paradoksalnie brakuje im wsparcia ze strony producentów przeglądarek. Ciągle są jakieś problemy z niestandardową (błędną) obsługą czegoś tam, dodawaniem własnych rozwiązań albo notorycznym zwlekaniem z implementacją rzeczy potrzebnych na kilka lat temu. Dużo łatwiej jest teraz zrobić obiekt multimedialny w jednorodnym, scentralizowanym środowisku, a potem wyświetlić go na stronie jakimś pluginem, niźli męczyć się z rozwiązywaniem niezgodności między różnymi przeglądarkami.
Nie zmienia to jednak faktu, że znaczna część rzeczy wyświetlanych przez plugin Flash, może być wyświetlona z powodzeniem przez silnik Presto. W sumie największy problem na chwilę obecną jest związany z filmami i dźwiękiem, ale to jest właśnie w trakcie rozwiązywania. Kiedy to nastąpi...
W sumie to bardzo głupie, że stworzenie pluginu do przeglądania stron WWW w przeglądarce WWW jest sensowne.
Jakiś czas temu spotkałem się ze zdaniem pracowników Opery, że nie ma sensu dzielić WWW dla telefonów komórkowych i większych maszyn. Kiedy jednak kupiłem sobie telefon, na którym mogłem uruchomić Operę Mini, okazało się, że strona przeciętnego serwisu robi się zdecydowanie zbyt toporna dla małego telefoniku.
Cóż. Na ekranie przeciętnego komputera bez problemu można zmieścić trzy, dość szerokie łamy. Na ekranie telefonu ledwie mieści się jeden, a i tak wąski. Jakby tego było mało, jeśli strona jest zbyt duża, zostanie podzielona na kilka fragmentów, czyli kilka stronek.
W sumie więc najlepiej dla telefonów komórkowych zrobić tak, aby na jednej stronie była nawigacja, a na drugiej treść właściwa, takie standardowe, zbędne dodatki można by wrzucić na trzecią, jakby ktoś się uparł. Dzięki temu nawet, jakby strona została podzielona na mniejsze stronki, zachowany by został podział logiczny. Liczbę i formę reklam należałoby też dostosować do możliwości małych ekranów, najlepiej zrobić je całkowicie tekstowe.
Z drugiej strony zastanawiam się, czy taki podział standardowych, wielkich stron na mniejsze nie sprawdziłby się w przypadku pełnowymiarowych przeglądarek. (Kiedyś zrealizuję w praktyce.) W każdym razie to, co mamy obecnie, dla komórek jest zbyt ciężkostrawne.
Jeśli mówić o problemach z zagospodarowaniem całego okna przeglądarki na stronę WWW, niezależnie od rozmiarów tego okna, można wspomnieć o łamach. Zasadniczo w teorii pozwalają owe łamy zrobić dwie rzeczy. Można je ułożyć obok siebie w poziomie, tak aby mieć tylko poziome przewijanie. Można je też umieścić tak, aby zajmowały całą szerokość viewportu, ale ich kolejne zestawy znajdowały się poniżej, tak aby mieć tylko przewijanie pionowe. Brzmi to tak niezrozumiale, że zrobiłem ilustrację.
Istnieje projekt wprowadzenia stosownych atrybutów w CSS 3, niestety na chwilę obecną nie przewidziano możliwości robienia takich efektów. Pierwszy z nich można chyba osiągnąć posiłkując się autorską składnią zastosowaną w Gecko. Osobiście nie testowałem. Drugi jest niemożliwy. Cóż. Na razie nie ma oficjalnej specyfikacji, nie ma obsługi łamów w Presto i KHTML, więc na razie nie będę się tym zajmował.
Ciekawostka. Pierwsze podejście do wyświetlania wielołamowego zostało poczynione w przeglądarce Netscape Navigator, chyba wersji 4. Rozwiązanie nie doczekało się standaryzacji, więc nie zostało już zaimplementowane w silniku Gecko.
Kilka lat temu na świecie dominowały monitory CRT. Technologia ta miała tą cechę, że najtaniej było wyprodukować monitor o kształcie koła. Koło jednak nie pasowało do naszego, prostokątnego świata. Trzeba było więc je przyciąć. Najmniejsze straty byłyby w przypadku przycięcia do kwadratu, ale człowiek widzi świat panoramicznie. Ostatecznie zdecydowano się więc na proporcje 4:3 i tak było przez długi czas.
Kilka lat temu pojawiły się monitory LCD. W przeciwieństwie do monitorów CRT, ich ulubionym kształtem były prostokąty. W dodatku nie przywiązywały większej wagi do proporcji obrazu. Dzięki temu możliwe stało się wytwarzanie monitorów panoramicznych o proporcjach 16:9. Dodatkową zaletą monitorów LCD okazała się możliwość przekręcania ich o 90°.
Przejdźmy może na chwilę do różnego typu publikacji papierowych. Szerokość tekstu, aby można było ów tekst łatwo odczytać, musi być ograniczona. Z tego też powodu książki mają dość wąskie kartki, a w przypadku czasopism na jednej kartce umieszcza się obok siebie wiele łamów.
Jeśli chodzi o publikacje elektroniczne, to właściwie ciągle bazują na zasadach dotyczących kartek papieru. W publikacjach elektronicznych nie ma ustalonej wielkości liter, ani też ustalonych wymiarów kolumny/strony. To znaczy nie powinno być.
Wróćmy znowu do monitorów. Obecnie standardem są monitory o rozdzielczości 1024:768. Powoli kolejnym standardem robią się wyświetlacze o rozdzielczości 1280:1024, które po obróceniu o 90° dają rozdzielczość 1024:1280. Czyli wydawałoby się, że szerokość się nie zmieni. Niestety pojawiają się też monitory panoramiczne. Standardy HDTV mówią o rozdzielczościach 1280:720 i 1920:1080, należałoby się spodziewać, że podobne rozdzielczości zawitają też w najbliższym czasie do komputerów. Już dzisiaj znaczna część notebooków ma rozdzielczość 1280:800, a kilka razy spotkałem się z rodzielczością 1440:900 dla komputerów stacjonarnych. Do tego należy dodać, że nie wszyscy posiadacze monitorów LCD obracają je o 90°. Jakby tego było mało, należy jeszcze uwzględnić, że można sobie włączyć okno przeglądarki tylko na części ekranu.
Rozwiązaniem tego problemu byłby układ o zmiennej liczbie łamów. Niestety jest to obecnie technicznie prawie niewykonalne. Jakiś czas temu bawiłem się i udało mi się coś w rodzaju tego efektu uzyskać na przeglądarkach z dobrą obsługą CSS. Niestety z dość poważnymi ograniczeniami: tekst, który ma być umieszczany w zmiennej liczbie łamów musi mieć stałą, określoną wysokość.
Tak naprawdę są tylko dwa, międzyplatformowe silniki dla przeglądarek WWW: Presto i Gecko. Strony WWW powinny się jednak wyświetlać w jak największej liczbie przeglądarek. Najlepszym rozwiązaniem jest więc serwis, który automatycznie zrobi zrzuty wybranych stron pod stosownymi przeglądarkami.
Nie zawsze pracuje z pełną mocą, czasami zrzuty z kilku przeglądarek są niedostępne, ale i tak jest dobrze. Przy okazji można w ten sposób rozwiązać częściowo problem różnych, zainstalowanych zestawów fontów.
Tak sobie analizowałem fonty, jakie zostały automatycznie zainstalowane wraz z moim Linuksem. Zauważyłem dwie, ciekawe sprawy. Pierwsza to taka, że znaczna część z tych fontów jest optymalizowana do 12px. Tak właśnie zachowują się DejaVu Serif i DejaVu Sans, podobnie też Nimbus Sans L.W innych wielkościach zaczynają te czcionki wyglądać gorzej. W sumie jest to nawet i logiczne, na wielu stronach WWW ustawia się bowiem czcionki na tą wielkość. Sęk w tym, że w mojej ocenie to trochę zbyt mało i osobiście preferuję większe wartości. Poza tym znalazłem ciekawy font o nazwie URW Bookman L, który wygląda bardzo ładnie na ekranie przy małych rozdzielczościach. Została zaprojektowana na 16px, ale i przy mniejszych wartościach wygląda nieźle. Jeśli chodzi o pisanie tekstów w edytorze, preferuję font URW Palladio L. W edytorze mam znacznie większe literki. W sumie w ostateczności można go też stosować na stronach WWW, ale ja bym nie proponował do innych celów, niż nagłówki albo sekcje tekstu pisane dużą czcionką.
Dodane. Na chwilę obecną zrobiłem proste demo. Robiłem je dla siebie, ale planuję je rozbudować, aby lepiej prezentowało różne fonty na różnych systemach. http://michas.eu/test_fontow.html
Przez kilka miesięcy analizowałem możliwości CSS. Porównywałem zalecenia, z którymi się spotkałem, ze smutną rzeczywistością. W międzyczasie pojawiła się kolejna wersja MSIE, w której poprawiono bardzo wiele. Testy innych przeglądarek i systemów operacyjnych też doprowadziły mnie do ciekawych wniosków.
W efekcie postanowiłem trochę przebudować arkusz CSS sklepu internetowego, którym się zajmuję. Przy okazji musiałem wprowadzić kilka modyfikacji do samego kodu xhtml. (Powinien się walidować.) Jako, że mam bardzo dużo rzeczy do zrobienia, zmiany idą bardzo wolno. Niemniej jednak istnieje już strona rozwojowa.
Starałem się, aby to był jak najbardziej logiczny, czysty i czytelny CSS. I chyba nawet mi się udało. Niestety z przyczyn technicznych mam w kodzie xhtml liczne, nadmiarowe obiekty.
Od pewnego czasu eksperymentuję z półprzezroczystościami w obrazkach png. Zauważyłem niestety ostatnio dość poważny problem. Jeśli dla danego obiektu dobierze się kolor tła i obrazek png z półprzezroczystościami to ów kolor tła będzie widoczny. W sumie sensowne zachowanie, aczkolwiek teraz szukam, jak je wyłączyć.
Ostatnio zastanawiałem się trochę nad elementami, jakie wpływają na wizualny aspekt strony WWW, oraz z możliwościami ustalania ich wyglądu. Zasadniczo mamy do czynienia z pięcioma kategoriami:
1. Tekst 2. Grafika rastrowa 3. Grafika SVG 4. Proste obiekty CSS 5. Osadzone obiekty multimedialne.
Kolor można przypisać właściwie wszystkim elementom. (W przypakdu obiektów multimedialnych występują dodatkowę komplikację, o których jeszcze wspomnę.) Największym problemem jest jednak ustalanie wymiarów.
Ustalenie wielkości samego tekstu powinno być proste. Najelpiej jest bowiem zdać sie na indywidualne preferencje danej osoby. Dla jednej osoby mały font będzie wyglądał tak samo dobrze, jak duży font dla innej.
Problem pojawia się jednak, gdy do gry wchodzi grafika rastrowa. Niestety, jeśli ta grafika ma spełniać dekoracyjne funkcje, jej wielkość musi być dobrana do wielkości tekstu. Zasadniczo można ją przeskalować, ale ten typ grafiki bardzo nie lubi owego skalowania. Aby wykluczyć skalowanie i zapewnić dobranie jej wielkości do tekstu należy grafikę rastrową i tekst określić w jednostkach px. Czyli rezygnujemy ze spersonalizowanych ustawień odbiorców końcowych. W pewnych okolicznościach można zapewnić dobry wygląd grafiki rastrowej dla dość szerokiego zakresu wielkości tekstu i nie odwoływać się do procesu skalowania, ale tylko w pewnych okolicznościach.
Teoretycznie grafika SVG powinna rozwiązać problem. Jest to grafika wektorowa, więc nie ma problemów ze skalowaniem. Niestety najnowsze przeglądarki mogą ją stosować w dość ograniczonym zakresie. W przypadku przeglądarki Microsoftu pojawia się jeszcze kilka innych problemów. Można jednak postarać się wymyślić jakieś rozwiązanie.
Część efektów graficznych można jednak uzyskać za pomocą czystego CSS. Zasadniczo można bawić się różnokolorowymi, prostokątnymi pudełkami. Owe pudełka są obiektami wektorowymi, więc można je sobie swobodnie skalować. Pewnym problemem może być bardzo cienkie obramowanie pudełka, które należy wykonać w px, ale nie stanowi to większego problemu. Niestety bardziej atrakcyjne możliwości CSS są w bardzo wstępnej fazie implementacji i w wielu przeglądarkach nie działają, więc pozostają tylko ciekawostkami.
Na koniec zostawiłem osadzone obiekty multimedialne. (Dla części przeglądarek do owych obiektów zalicza się też grafika SVG.) Pierwszym problemem są pluginy, które muszą być zainstalowane i aktywne, aby dany obiekt został wyświetlony. Wypadałoby więc ograniczyć ich stosowanie tylko do skrajnych wypadków. Jeśli zaś chodzi o ustalanie wymiarów, zależy to od konkretnej treści, jaka została osadzona. Obiekty Flash, podobnie jak SVG, są wektorowe, więc mogą być określane swobodnie. Ogólnie rzecz biorąc, może być z tym bardzo różnie.
Czyli w podsumowaniu mogę napisać, że albo stosuje się dość ascetyczną grafikę, albo określa się wszystko na sztywno i ignoruje spersonalizowane ustawienia. W ostateczności można dorobić dodatkowe ustawienia obecne na samej stronie (skórkę). Wypada też pamiętać, że mały tekst czyta się mało wygodnie. Jeśli już określać jego rozmiar, dopiero 16px powinno być akceptowalne.
No to postanowiłem dostosować mój sklep. Wszystkie linki, jeśli odwołują się do różnych zasobów, mają być zgodnie z tymi zasadami różne. No to trzeba było pozmieniać wszystkie Kup na Kup %tytuł%. Oczywiście w pełnoekranowym css ukrywam ten tytuł, aby zwiększyć czytelność strony.
Przy okazji dodałem trochę titli i labeli do pól formularzy. Porozdzielałem też wszystke sąsiadujące linki niebiałymi znakami. Oczywiście poukrywałem te znaki, kiedy w css robiłem je w nowych wierszach. Czytelność i funkcjonalność zwiększyła się zauważalnie. Czemu to zrobiłem tak późno?
Na razie tylko główna strona, ale pozostałe też się poprawi.
Teraz jednak zaczynają się pewne problemy: 1. Stosuję dużo ukrytego tekstu na stronie, który zawiera potencjalne słowa kluczowe, czyli nazwy produktów. 2. Część owego tekstu zaczyna na stronie występować w zbyt dużym zagęszczeniu, więc jeszcze mnie wyszukiwarki wrzucą na czarną listę.
Po co w sumie robić takie strony, które są zgodne z tymi zaleceniami dostępności, a nie są przeznaczone dla osób, które takiej dostępności potrzebują. Jest kapitalizm, nikt za to nie zapłaci. Dostosowywanie strony do robotów indeksujących jest niezbędne, ale tutaj zrobiłem chyba trochę zbyt wiele.
Chyba chciałem się tylko dowartościować, że potrafię zrobić coś takiego.
Systemy szablonów są ponoć fajne. Są z nimi tylko dwa problemy.
Pierwszym z nich jest to, że w standardowym HTML (i XHTML) są właściwie zbędne. Teoretycznie oddzielają od kodu php warstwę HTML odpowiedzialną za wygląd dokumentu. Problem w tym, że ta warstwa jest w kodzie css. Może ja jestem zbyt głupi i czegoś tutaj nie rozumiem?
W każdym razie drugim problemem jest to, że zasadniczo nie pozwalają zacząć wysyłać dokumentu przed skończeniem jego generowania. Czyli, jak dokument generuje się 10s, co jest już bardzo długim czasem, dokument zaczyna być wysyłany dopiero po tych 10s. Zamiast tego można by zacząć wysyłanie po 5s, kiedy gdzieś połowa dokumentu byłaby wygenerowana. Dzięki temu proces wysyłania zakończyłby się wcześniej.
Ponadto nie trzeba buforować w pamięci serwera całego dokumentu do wysłania. Wystarczy buforować tylko małe fragmenty i wysyłać je sukcesywnie. Dzięki temu serwer powinien trochę szybciej działać.
A do czego zmierzam? Cóż, właśnie przepisuję mój kod sklepu w taki sposób, aby był mniej szablonopodobny. Pierwotnie cała treść była najpierw generowana, a dopiero potem wysyłana, co uznałem po pewnym czasie za poważny błąd.
Postanowiłem zrobić bardzo proste, rozwijane menu. Wyszedłem bowiem ze słusznego założenia, że jeśli czegoś w świecie WWW nie da się w zgrabny sposób stworzyć, należy z tego zrezygnować.
HTML zawiera zwyklą, zagnieżdżoną listę nienumerowaną. Główny element listy posiada ID. Pozostałe elementy nie zawierają.
JavaScript przypisuje odpowiednie klasy do elementów listy w zależności, czy kursor myszy znajduje się nad daną gałęzią.
Działa bardzo topornie. Muszę mocno przebudować CSS. Muszę też wymyślić, jak zgrabnie ustawić opóźnienie w ukrywaniu gałęzi. Pod przeglądarką Microsoftu działa jeszcze gorzej.
Rozważam też wersję z dynamicznie generowaną listą, a nie tylko stylowaną. Oczywiście owa dynamicznie generowana lista byłaby umieszczona w dokumencie html, a dopiero potem JavaScript odcinałaby zbędne gałęzie, a w razie potrzeby doczepiała na nowo. Cóż, to by chyba rozwiązało problem z brakiem opóźnień, ale spowodowałoby problem z ich nadmiarem.
Wyłączyłem sobie domyślne podkreślanie linków w Operze. Zaskoczyło mnie, jak bardzo zwiększyła się czytelność wielu stron. Jakoś na razie kolor, względnie umieszczenie w odpowiednim miejscu, wystarcza mi w zupełności jako oznaczenie linku. Polecam.
Jako, że nie znalazłem kursu html, który by mi odpowiadał, czyli był całkowicie zgodny z moimi oczekiwaniami, postanowiłem sam naskrobać coś takiego. Okazało się to dość skomplikowane. Napisałem jedną stronę i już teraz wiem, że muszę ją mocno przeredagować...
