marcoos.techblog

Za DI:

Naszym celem jest 100 procentowa zgodność Onetu z Operą i standardami. - zapewnił redakcję Dziennika Internautów Michał Hobot.

Tak, oczywiście. Onetowi gratulujemy standardów. :)

Apple uważa, że ma prawa „własności intelektualnej” do <canvas>. Faktem jest, że  zaimplementowali to jako pierwsi w Mac OS X (widgety, Safari).  Jednocześnie to ich pracownicy wprowadzili canvas do specyfikacji WhatWG HTML 5. WhatWG ulepszyła i rozbudowała pierwotną specyfikację tego elementu.

Departament patentów Apple Computer napisał do WhatWG:

Apple reserves all rights in its IP Rights and makes no representations as to Apple’s willingness or unwillingness to license these IP Rights.

Canvas został zaimplementowany w Gecko i w Operze. Ciekawe, co będzie dalej…

(via Virtuelvis)

Tak, to naprawdę możliwe - w przeglądarkach opartych na Gecko, jak Firefox. Jeśli ktoś z Was używał rozwijanego menu w Google Video, to nawet już się z tym zetknął.

Zatem, jak oni to zrobili? Przeanalizowałem kod i odpowiedź jest prosta: wstawili pływającą ramkę między Flasha a div używając z-index. Co, próbowałeś/-aś i nie wyszło? Nie wyszło, bo potrzebna jest pewna sztuczka. Własność CSS “display”tej ramki musi być najpierw ustawiona na “none” w arkuszu stylów, a następnie przełączon na “block” z poziomu JavaScriptu po wyrenderowaniu przez przeglądarkę elementu <embed>.

Poniżej link do przykładu. Dla Waszej wygody i zdrowia serwerów, umieściłem go w trzech miejscach:

• serwer 1 (pertus.com.pl, Legnica)
• serwer 2 (studencki serwer Wydziału Elektrotechniki, Automatyki i Informatyki Politechniki Opolskiej)
• serwer 3 (serwer zespołu AviaryPL Team’s w szczecińskiej Akademii Rolniczej)

PS. zanim ktoś z Was zechce to “wykopać”, mała prośba: linkujcie do notki, a nie bezpośrednio do przykładów.

(To jest polskie tłumaczenie poprzedniej notki)

Yes, it is really possible if only you’re using a Gecko-based browser like Firefox. If you used the pull-down menu on Google Video, you have already even seen it in action.

So, how did Google do it? Well, I analyzed their code and the answer is simple: they put an iframe between the Flash and the div using z-index. Hey, you tried it and it didn’t work? That’s because it needs a little hack: the iframe’s CSS “display” property must be set to “none” at first (style=”display: none”) and be changed to “block” via JavaScript after the <embed> element is rendered. With this hack - it works!

So, take a look at the example. For your convinience, I’ve mirrored it on three servers:

• server 1 (pertus.com.pl, Legnica, Poland)
• server 2 (students’ server at the Opole University of Technology, Opole, Poland)
• server 3 (AviaryPL Team’s server at the Szczecin University of Agriculture, Szczecin, Poland)

OK, before you slashdot or digg this, please don’t link to the examples directly. Link to this post only.

Wielu z Was czytając mój poprzedni tekst o mikropodsumowaniach zapewne zastanawiało się, czy nie można ich tworzyć prościej niż poprzez XSLT. Otóż można. :)

Oparte o XSLT generatory mikropodsumowań przydają się najbardziej do stron, których… nie jesteśmy autorami i nie mamy na ich zawartość wpływu. Natomiast, jeśli chcemy przygotować mikropodsumowanie dla własnej witryny, wystarczy nam zwykły plik tekstowy.

Wystarczy go podpiąć do naszej strony przez znacznik <link>:

<link rel="microsummary"
type="text/plain" href="micro.txt" />

i już. Musimy tylko zadbać, żeby plik micro.txt zawierał interesujący użytkownika i odpowiednio aktualizowany tekst.

Przykład jest na głównej stronie www.firefox.pl - domyślnie dołączone mikropodsumowanie nowo dodanej do Bon Echo zakładki do tej strony zawiera numer najnowszej stabilnej wersji Firefoksa. ;-)

Riddle napisał ostatnio o tzw. “spoiler space” przy użyciu pseudoklasy :focus. Dla niezorientowanych: “spoiler space” (w polskim slangu grup usenetowych czasem także “spojler”) to fragment tekstu, którego nie chciałbyś przeczytać przed obejrzeniem filmu czy przeczytaniem książki, bo np. zdradza zakończenie albo istotne szczegóły fabuły.

W metodzie Riddle’a “spojlery” wyświetla się, ustawiając fokus na linku, który zawiera treść “spojlera”. Rozwiązanie to ma tę zaletę, że działa w IE, a wady to: niedziałanie w Operze i niemożność zawarcia w treści spojlera innych odnośników. Innym problemem - dla maniaków standardów, rzecz jasna - jest niesemantyczność takiego rozwiązania: używamy do czegoś, co nie jest odnośnikiem.

Istnieje inne rozwiązanie: selektor :target z CSS 3. Ukrywanemu przez nas tekstowi nadajemy jakiś identyfikator (np. “spoiler”), a w CSS tworzymy dwie regułki:

#spoiler { visibility: hidden; }
#spoiler:target { visibility: visible; }

Zamiast ustawiać “visibilty” na “hidden” i “visible”, możemy użyć oczywiście “display”, odpowiednio “none” i “block”. Możemy też, podobnie jak Riddle, zmieniać po prostu kolory tekstu danych elementów.

Zapis “#id_elementu:target” oznacza: “element o id=’id_elementu’ gdy jest on elementem docelowym”, co jest równoważne z tym, że adres URL w przeglądarce kończy się na “#id_elementu”. Tak więc, jeśli użytkownik otworzy naszą stronę “normalnie”, nie zobaczy ukrytego tekstu, a kiedy przejdzie do kotwicy (”#id_elementu”) - element ten zostanie wyświetlony.

Rozwiązujemy w ten sposób problemy semantyczności (nasz “spoiler” nie musi być linkiem) oraz zawartości (nie ma żadnych ograniczeń co do “spoilerowej” zawartości, może to być tekst z linkami, tabelka, formularz, aplet, animacja Flash itd.), ale pojawia się problem nowy: jedynym silnikiem, który obsługuje selektor “:target” jest Gecko, tak więc nasz “spoiler” stworzy problemy użytkownikom Opery, IE i przeglądarek opartych na KHTML. Chyba że ich twórcy w końcu dodadzą obsługę selektorów CSS 3.

Przykłady (niezbyt ładne wizualnie, za to bardzo proste w zrozumieniu):

• wersja z visibility
• wersja z display