Wszyscy wiemy doskonale, że strony powinny być tworzone zgodnie ze standardami, użyteczne, dostępne i tak dalej. Lecz czasem by osiągnąć wymagany efekt musimy nagiąć zasady. Zatem moje pytanie brzmi: na jakie błędy (ostrzeżenia) w walidacji stron jesteście w stanie przymknąć oko, zakładając, że strona działa poprawnie w liczących się przeglądarkach?
Nazywam się Tomasz Staniak, zajmuję się prowadzeniem/tworzeniem projektów internetowych. Na blogu przeczytasz o tym, co mnie interesuje a także z czym jestem związany zawodowo.
35 Responses for "Walidacja, błędy a rzeczywistość"
Na brak "alt", jeśli obrazek nie ma znaczenia dla treści strony. Na razie więcej nie przychodzi mi do głowy, jak przyjdzie to uzupełnię zeznania.
ponieważ na razie korzystam z ramek (taki sam efekt można uzyskać za pomocą warstw lub pozycjonowania ale obciąża to strasznie przeglądarki i tym samym procesor) muszę naginać specyfikację do firefoxa, który bez parametru frameborder lub border w frameset pokazuje biały pasek, mimo zastosowania paremtrów w frame wg. specyfikacji :-|, i mimo, że reszta strony jest ok to nie mogę powiedzieć, że cały serwis jest zgodny :-/.
alt to w sumie pryszcz, lepiej dodać alt="" i mieć spokój ;-), w sumie to nic nie kosztuje, ale są inne wkurzające parametry, jak np. wspomniałem wyżej, ale także cellspacing i cellpadding których nie można zastąpić w pełni css :-/ (co prawda to nie dotyczy zadanego przez Ciebie pytania ale
)
Użycie atrybutów -moz-* w stylach CSS
-moz-* tak, tak :-] tylko właśnie to też nie jest zgodne ze standardem
i tak w kółko, czasami to wkurzające i to ostro.
Cellspacing to relikt HTMLa obecny w tabelkach. Przy XHTML i div-ach go nie potrzebujesz
wiem ale tabelki są czasami szybsze w dostowaniu, poza tym zachowują dobry układ dla starszych przeglądarek :), a jeśli o to chodzi to praktycznie z każdego standardowego znacznika można zrezygnować zastępując go css, no może z wyjątkiem kilku niezbędnych i takich których nie da się zdefiniować przy pomocy żadnej kombinacji parametrów CSS. Najgorsze jest to, że obecne przeglądarki mają problemy tak ze starymi standardami jak i z tymi nowymi
to zaczyna czasami być śmieszne, chociaż jak trzeba coś zrobić to wtedy przestaje 
Trace swoje trzy grosze - & zamiast & w urlach
MatiSz: akurat to jest IMHO niewybaczalne. Używanie & zamiast & w URLach wynika jedynie z nieuctwa lub lenistwa. Raczej nic dobrego nie daje, a może spowodować problemy.
To akurat tak, tym bardziej że & jest zastrzeżonym znakiem, właśnie dla sekwencji znaków specjalnych :-), a pozatym to nie jest naginanie do konkretnej przeglądarki, to jest ogólnie przyjęty standard :-D.
PS. Sam do nie dawna popełniałem ten błąd dopóki mi validator tego nie wywalił
I w sumie o takie błędy chodzi. Każdy błąd wynika albo z nieuctwa albo z lenistwa (czasem to pośpiech i przeoczenie - jak np u Moose nie działające niektóre podstrony w CSS Destroy). W końcu przez wiele lat było stosowane & zamiast &. To działało i wciąż działa. Podobnie jest z alt tagami, niedomkniętymi znacznikami itd..
Stąd moje pytanie - na co potrafimy przymknąć oko. Jeśli autor się zna i traktuje swoją pracę poważnie, to z pewnością, z czasem, poprawi błędy tego typu.
akurat niedomknięte znaczniki w xhtml mogą na niektórych przeglądarkach spowodować nie wyświetlenie ich zawartości (taka własność wyniesiona z xml
)
Zwłaszcza, jeżeli zgodnie z zaleceniami wyślesz im application/xml+xhtml
Ja czasem nie podaję doctype w trosce o zdrowie IE6 (bo strony robimy w trybie zgodności z IE5.5) ;]
Tak, można podać 4.01 transitional i nie podać urla i efekt jest ten sam, ale czasem doklejam to dopiero na samym końcu pracy przy sajcie.
Błędy semantyczne (jak niewyencjowany ampersand) są nie do wybaczenia, wyszukuję i tępię, nawet po kolegach z biura. Wybaczyć mogę niektóre niezamknięte elementy, standard transitional nie wymaga zamykania paragrafów - tag <p> działa tam jak encja czy element <br/> (który powinien być encją w ogóle, ale z nieznanych mi przyczyn jest elementem).
Jajcuś jeśli obrazek nie ma znaczenie dla strony to znaczy, że powinnien tkwić w cssie
bela:
Niekoniecznie, co z systemami CMS, gdzie użytkownik uploaduje grafikę?
Patrys:
to przy uploadzie powinnien być input w którym należy wpisać opis, a cms jeśli pole będzie puste to i tak da alt=""
No alt="" jest zawsze, ale nie zmuszę klienta, żeby coś wpisywał w pole przy uploadzie każdego obrazka. Słyszę tylko "a po co mi to pole". Nie robimy stron bez CMS. Stąd duża część grafik na serwisach ma pustego alta.
Ja jestem nieczuły na plucie się walidatora, jak w <a> wsadzam inny blok, a sam a ma display: block; Semantyka leży, ale to zmusza IE to obsługiwania :hover bez żadnych htc czy jakoś tak.
UTF-8 serwuję z BOM.
sebas86: Cellpadding można.
Ja używam cellspacing do tabelki i div'a z background-color pod nim do bardzo prostego efektu grid'a.
Od UTF w sieci nie jest BOM tylko nagłówek HTTP.
Cellspacing zerowy uzyskuje się przez border-collapse: collapse;
Moje trzy grosze…
Jajcus: To nie zawsze jest lenistwo (moze nieuctwo…;) )
W PHP, gdy sesja leci nie ciastkami, tylko przez GET'a, to SESSID dokleja sie do adresow ze zwyklym ampersandem.
Od razu ze strictowego kodu dostajemy setke bledow.
Wszystko dobrze dziala, ALE…:/
Możesz albo wychwycić taki tekst przez output buffering i regexp'em zmodyfikować, albo gdzieś tam w php.ini są ustawienia dot. znaku dodawanego przy doklejaniu.
Przeglądarka powinna zamienić & w linkach na sam &, i ustawienia php raczej do tego nic nie mają. Wywoływałem takim linkiem ze strony i działał a z paska adresu nie (z & zamiast &)
@seba86, jemu chodziło o to, iż w kodzie pojawia się &SESID= nie jako & tylko jako &, co oczywiście nie zostanie przepuszczone przez walidator. Ja zaś wspomniałem, jak soie z tym poradzić .
aha, mój błąd
rzeczywiście w takim przypadku
student_2004: to dalej jest nieuctwo/niedbalstwo/głupota, tyle że nie autora aplikacji w PHP, ale autorów samego PHP… co mnie tylko utwierdza w moim zdaniu na temat tego języka…
Może i głupi w tym miejscu, ale jak dla mnie na tyle mądry aby zrobić tak wygodne narzędzie do tworzenia serwisów internetowych, generowanych dynamicznie.
@Jajcus, twórcy PHP udostępnili konfigurację dla tego w php.ini, tak jak wyżej pisałem. arg_separator.output = "&" i wszystko jest poprawnie. Inna sprawa, iż domyślnie jest arg_separator.output = "&"
Zmiany w php.ini zazwyczaj nie wchodza w gre, a zmiana tresci bufora…
Pogrzebalem na php.net i znalazlem funkcje
string ob_get_contents ( void )
ale ona tylko zwraca tresc z bufora. Po zmianie tej tresci sam bufor chyba pozostanie niezmieniony. Jeszcze pozostaje kwestia tego, na ktorym etapie parser dokleja zmienne do adresow.
No chyba, ze mozna przechwycic (zmienic) bufor w jakis inny sposob?
ob_get_clean() - zwraca, a następnie czyśći bufor
ob_get_clean() - zwraca, a następnie czyści bufor
Sorki za zdublowanie
Dzieki za pomoc. Warto bylo sprobowac.
Bufor jednak nic nie daje. Zmienne doklejane sa za pozno.
Napisalem taki kod:
session_start(); ob_start();
echo '<a href="sessid.php?var=1">Test</a>';
echo str_replace('&PHPSESSID','&PHPSESSID',ob_get_clean()).' '.SID;
Efekt jest caly czas taki sam. Probowalem nawet "recznie" dopisywac SID'a, albo wstawiac na koniec & i nic.
Chyba jednak pozostaje tylko list do admina w sprawie php.ini, albo - jak w temacie… przymknac na ten blad oko.
Powinno działać w ten sposób. Spróbuj jeszcze może ustawić ze skryptu & przez ini_set("arg_separator.output","&")
No to problem z glowy:)
Samo ini_set() zalatwia sprawe i nawet nie trzeba meczyc serwera buforowaniem wyjscia.
Musze teraz "wystrictowac" pare stronek…;)
Leave a reply