Witam,

Temat może troche teoretyczny nie mniej nie daje mi spać od dłuższego czasu.
Moja praca związana z PHP polega przede wszystkim na trzech rzeczach:
W pracy:
-Wdrażamy serwisy oparte o naszego firmowego CMS-a, często jednak sięgając po rozwiązania z zewnatrz zwłaszcza jeśli chodzi o rozwiązania JavaScript-owe tj biblioteka JQuery albo edytory do admin panelów.

W domu:
- Od czasu do czasu sięgam po frameworka, jeśli zadanie tego wymaga i "spłodziłem już mini CMS-y na CakePHP, ZF a ostatnio na Code Igniter.
-Piszę z pasji może z myślą włąsny skrypt po to by móc łatwiej poradzić sobie z pewnymi rzeczami przy wdrażaniu stron dla klientów, bez potrzeby rozgrzebywania API różnych gotowców często na czynniki pierwsze.
- Obecnie posiłkuje się jednak gotowymi platformami blogowymi,nieczęsto LifeTypem, często Wordpressem, galeriami gallery2 oraz Pixelpost no i CMS-em Drupal.

Nie pisze o tym, żeby powiedzieć, że jestem wielce doświadczony, bo często zacinam się na podstawowym błędzie a wzorców projektowych we własnym kodzie uzywam nie więcej niż czterech. Niemniej miałem przez ten czas możliwość poznania różnych podejść i nie o PHP chciałem pisać.

Interesuje mnie przede wszystkim opinia na temat właśnie zgodności bibliotek JavaScriptowych a standardów zarówno W3C ale też specyfikacji ECMA 262.
Osobiście mimo pierwszego wrażenia sprzed paru lat przestałem być fanem LightBox-a, dlatego, że jest niesamowicie popularny a czasem "fajnie" jest zrobić prezentację grafiki inną niż na wielu stronach. Druga rzecz to to, że na moim sprzęcie w domu PCU 1.7, RAM 256, spowalnia system podobnie do mojego drugiego komputera PCU: dwa rdzenie 2.2, RAM 2 GB (na obydwu jest Debian Etch). Edytory + ich możliwość wklejania treści z MS Word, dewastują, każdy napisany i walidujący się kod XHTML.
Niemniej wiem, że każda bibliotekę można uzyc z głową i choćby prosta walidacja formularzy na froncie okazuje się o niebo prostrza niż pisanie samemu.

I teraz p[rzechodząc do podsumowania mojego dylematu. Pokusiłem się pare razy o wysłąnie strony w MIME application/xhtml+xml i tu pojawiła się masa problemów.
innerHTML działać nie powinien, i nie działał pod Operą, pod FF tak bo wiem że deweloprze Mozilli poszli na swego rodzaju ugodę w tej kwestii. Według wspomnianej specyfikacji ECMA właściwość innerHTML nie istnieje. Dalej -> różnego rodzaju metody i włąściwości związane z oknem przeglądarki innerHeight( jeśli dobrze pamiętam nazwy) + setTimeout + setInterval() również w specyfikacji się nie znalazły.

Troche czasu temu spotkałem się z określeniem "produkt pełno wartościowy" i dotyczyło to stron, zrobionych jeśli chodzi o front zgodnie z obecymi standardami. XHTML przynajmniej Transitional, zrezygnowanie z formatowania typu <FONT>, zrezygnowania z tabel przy ustalaniu layoutu strony etc. I z całym tym znanym wszystkim divowym layoutem, popieranym przez szersze grono i promowanym na tysiącach stron w internecie, wychwalanym wielokrotnie (nie bez powodu) nagle "strzał" w postaci boomu na JavaScript całkowicie odbiegający od standardów.

A ja można powiedzieć chciałbym być webmasterem fundamentalistą, z bombą w plecaku do wysadzania stron na tabelach jeśli nie muszą byći jeśli przestrzegam zasad projektowania na divach, formatowania wyglądu w CSS to też chciałbym poznać opinie na temat słuszności wdrażania bibliotek JS dalece mijających się z opracowanym dla tego języka standardem.

Dzięki i pozdrawiam!!

Problemy zaobserwowałem tylko pod Fx-em. Aby osiągnąć tę samą funkcjonalność, musisz się bawić przez appendChild, itp. Niestety, wszystkie Lightboksy (AFAIK) nie korzystają z takiego dopisywania zawartości, dlatego nie działają pod Fx-em i XHTML+XML. Dlatego stosuje się content-negotiation.


Jak wyżej napisałem, naprawdę ciężko jest powiedzieć IMHO coś konkretnego - JS ma tę cechę, że nieraz przeglądarki interpretują, jak chcą. Ja zwykle wychodzę z założenia, że jeśli coś jest niepisanym standardem w JS - trzeba tego używać. Bo jeśli chodzi o JS, to naprawdę ciężko powiedzieć, co będzie zgodne, a co nie - ze standardami.

Najbardziej boli tu niejednoznaczna interpretacja przez przeglądarki, ale po potyczkach z CSS zdążyliśmy się już chyba do tego przyzwyczaić.

Póki co, staram się wysyłać application/xhtml+xml tym przeglądarkom, które na to zasługują i nie wysypią mi strony. Niestety, ma to tę wadę, że w przypadku, gdy użytkownik w CMS-ie może dopisywać własny kod XHTML, to przeglądarka potrafi wygenerować paskudny błąd o niepoprawnej składni... Tu masz rację - jest dylemat...

A jeśli chodzi o JS... włączam sobie konsolkę JS w Operze, poziom Notice i usuwam sugestie.

Hej,



JS jest naprawde fajny tylko w swoich projektach stawiałem na dwie rzeczy z góry: Walidacja i WAI jeśli chodzi o front. Więc np w przypadku formularza kontaktowego musiałbym napisać podwójnie kod do sprawdzania maila, po stronie klienta i po stronie serwera.



Z tym też miałem problem. Rozwiązuje go dość bezczelnie. Jeśli robie strone samemu (nie w firmie) to celowo do CMS-a (Drupal) nie dodaje edytora. I pierwszy problem z głowy.
Myślałem też o napisaniu porządnego walidatora treści wprowadzonej przez adminów systemu. Polegałoby to na tym że musiałbym mieć sporej wielkości tablicę z tagami XHTML-a i przypisaneymi do niej atrybutami typu: może występować w tagu <lala>, jest elementem blokowym, zamykamykamy go przez /> a nie </lala> etc. Nie chciało mi się pisać takiego parsera. Ale, jednak mówiąc o bezczelności wobec edytorów i wymuszania na nich wklepywania kodu HTML ręcznie przy formatowaniu zawartości dodam tylko, że moja mama prowadzi sporą stronę opartą na Drupalu. HTML-a nie znała prawie wcale i do tej pory (nic dziwnego, że hasło W3C nic jej nie mówi) nie zna go prawie nadal. Będoąc jednak dobrym synem udostępniełe,m jej możliwość edycji treści i "przeszkoliłem" ją pod kątem linkowania, formatowania czcionki, wstawiania tytułów, paragrafów etc.

Efekt: strona się waliduje a treść wprowadza osoba ze znikomą znajomościa HTML.

To mocno mnie podbudowało. I Teraz jeśli nie muszę, z góry przekreślam Tiny MC i podobne...

Pozdrawiam!!

Przecież jest już coś takiego... Nazywa się Tidy.


Zrób strony wg progressive enhancement, to wszystko będzie ok.

Cytat

A jak chciales inaczej??
Kazda weryfikacje nalezy pisac przede wszystkim po stronie serwera a potem zabierac sie za aspekt user usability i dodawac weryfikacje od strony klienta,ktora sie zaladuje albo i nie w zaleznosci do przegladarki uzytkownika, dupochron od strony serwera zawsze bedzie dzialac i to jest najwazniejsza linia obrony, strona klienta to dodatek

Chyba ze sie myle i ktos znalazl inny sposob na obrone prze mail injection tudziez innym paskudztwem to prosze o natychmiastowe oswiecenie