Allegro.pl
Pokaż: ustaw jako domyślne
pokaż obrazki

Komentarze (30)

  • Reklamy Google

  • Reinmar +2  

    @czajnicki: Ludzkość już na to wpadła. Wyślij stronę do przeglądarki z mime ustawionym na application/xhtml+xml, a zobaczysz co w Fxie dostaniesz w razie błędu.

    pokaż komentarz
    Reinmar
  • eXcore +1  

    Zauwaz tylko ilu ludzi wysyla prawidlowy naglowek application/xhtml+xml uzywajac jednoczesnie doctype xhtmlowego. Jest to maly procent, ostatnio sam z tego zrezygnowalem poniewaz nieporównywalnie zwiększa to koszt tworzenia skrypt js w tym. Jquery się wykłada i inne podobne frameworki, trzeba samemu się za to brać a to długie godziny nad jedną funkcja dla DOM XML'a, nie zawsze jest czas na to. Szkoda

    pokaż komentarz
    eXcore
  • Reinmar 0  

    Prawie nikt nie wysyła, bo nie ma to żadnych plusów. Przeglądarki (może się to zmieniło, bo dawno temu mnie to interesowało) i tak wysłanego xhtmla z poprawnym dla niego typem mime obsługują jak htmla, więc nie ma mowy o żadnym przyspieszeniu. Pod IE6/7 i tak trzeba serwować normalny typ mime, więc trzeba rozpoznawać przeglądarkę (albo akceptowane typy mime), co może powodować problemy i blokadę strony. Do tego nie okłamujmy się - XHTML nie jest kompilowalny, tworzony jest dynamicznie, często przez wiele osób, a jeszcze częściej przez osoby nic o nim nie wiedzące, boćgeneratory WYSWYG. Z własnego doświadczenia wiem, że ja może i błędu podczas cięcia żadnego nie popełnię, może podpinający do pod PHP/Ruby/itd też nie, ale już tworzący treść na bank. I po stronie.

    pokaż komentarz
    Reinmar
  • czajnick +2  

    A ja jestem za tym, żeby nie robić żadnego "ujednolicenia sposobu, w jaki na dany błąd – na przykład niedomknięcie tagu – zareagują przeglądarki internetowe". Powinno być tak: masz błąd - wypad, strona się nie wyświetla i tyle (dostajesz tylko komunikat w której linii jest błąd). Dzięki temu przeglądarki by działały o wiele szybciej (bo ich kod byłby mniejszy), strony renderowałyby się szybciej i łatwiej by było parsować je przez skrypty. Zapobiegłoby to rozleniwianiu twórców - niemożliwe by było podejście "wiem, że mam błąd, ale strona się wyświetla, więc olewam". A wszyscy nowi twórcy (np. dzieciaki z gimnazjum) szybko nauczyłyby się zasad prawidłowego tworzenia stron www.

    pokaż komentarz
    czajnick
  • pariah 0  

    wiesz że to nawet nie jest zły pomysł? Strony by były robione przez ludzi którym naprawdę zależy, chociaż reszta by wtedy korzystała z cmsów i tyle. Tylko że ms się na takie coś nie zgodzi i kilka firm też i zrobią dużo żeby coś takiego nie przeszło. Czemu? Frontpage, dreamweaver i inne.

    pokaż komentarz
    pariah
  • nalej_mi_zupy +1  

    Ale zauważ, że czasami treść (w tym znaczniki) są generowane automatycznie lub, przez użytkowników strony. Jedben błąd skryptu (np. przywieszenie serwera) i strona już by poszła w p#%!u.

    pokaż komentarz
    nalej_mi_zupy
  • pariah 0  

    no dobra, ale strony nie generuje się 'na pałę' tylko projektuje się cały proces żeby jedno nie nachodziło w drugie. Jeśli coś się ze sobą gryzie to nie powinno być dopuszczane do użytku, na bublach się nie pracuje. Co do skryptów, których działanie uwarunkowane jest różnymi czynnikami z zewnątrz, np. dane są pobierane z zewnętrznych serwerów, to tutaj nas tylko obsługa błędów uratuje i nic więcej. Wszystko da się ładnie wykończyć o ile ktoś nie pisze dużych rzeczy na hura.

    Co do znaczników wpisywanych przez userów, wystarczy zrobić parser wprowadzanego tekstu trochę bardziej ambitny od nl2br i stripTags, ostatnio robiłem takie coś co analizuje treść znak po znaku, linia po linii i między innymi pilnuje poprawnego wpisywania tagów. Pewnie od razu ktoś pomyśli że to żre mi nie wiadomo ile proca a tu bzdura, zarówno na darmowych hostingach jak i u siebie w domu (athlon xp 1.666ghz) czasy generacji przy krótkich notkach (do 4 paragrafów, coś koło 500 znaków może więcej) nie przekraczały 0.002s. Ktoś chętny to źródło mogę udostępnić

    pokaż komentarz
    pariah
  • Kartofelek +1  

    Standardy... Wszystko było by cacy, gdyby ludzie nie używali IE. Niby są nowe wersje tego "czegoś", ale spora liczba osób wciąż używa 6, a pewnie (nie patrzyłem w statystyki) znajdzie się spora liczba z versją 5. Więc mimo że jakieś standardy są (i to bardzo dobrze) to i tak często gęsto musimy tworzyć różnie beznadziejne sztuczki.
    Przydało by się więcej stron ze staroswieckim tekstem "niestety twoja przeglądarka to < IE6 - nie możesz oglądać tej strony". Może to by ludzi oświeciło ^^

    Co do daty. Jak kazdy z was zauwazyl webdesign wciaz ewouluje. I to bez zadnej 100% specyfikacji. I jakoś ludzie sobie radzą. Pytanie tylko czy HTML w 2022 bedzie jeszcze uzywany do tworzenia stron. Bo niewykluczone przeciez ze nagle wejdzie inna technologia i tak jak Flash bedzie pozyskiwac rynek itp. Bla bla bla.

    pokaż komentarz
    Kartofelek
  • eXcore +8  

    Dobrze, że rozwijane są standardy i "idziemy do przodu". Niestety obawiam się, że nawet jeżeli natychmiast zacząłby obowiązywać html 5 to nauczyciele w szkołach nadal uczyliby wykonywania dokumentów html w MS Wordzie (o zgrozo) a zdecydowana większość twórców jak do tej pory nie zastanawiałaby się w jakim standardzie tworza - "przecież się wyświetla więc o co chodzi ?" :)

    pokaż komentarz
    eXcore
  • lastof +3  

    Nie do końca. Większość stron ma poprawnie zadeklarowany DOCTYPE, choć z drugiej strony większość ma błędy. Wynika z tego, że większość autorów stron jest entuzjastami standardów, jest świadoma konieczności ich stosowania,. ale strony muszą działać pod IE, a być może nie bardzo potrafią ze standardów skorzystać.

    pokaż komentarz
    lastof
  • pstradomski 0  

    Akurat HTML 5 usuwa z DOCTYPE numer wersji - zostaje po prostu DOCTYPE HTML, więc rozpoznanie wersji HTML-a nie będzie już możliwe. WHAT WG uzasadnia to faktem, że przeglądarki i tak wszystkie dokumenty parsują tak samo, bez względu na wersję (pomijając kwestię wyboru quirks mode/standard mode).

    pokaż komentarz
    pstradomski
  • AltumVidetur -1  

    w tej chwili mamy za wielki burdel przeglądarkowy, żeby można było w 100% stosować sie do standardów, póki nie ma jednolitej interpretacji nie ma sensu siedzieć i dostosowywać. Standardy mają zapewnić jednolite wyświetlanie stron we wszystkich przeglądarkach, a narazie długa droga do tego( i nie mówie tylko o IE, wszystkie maja jakieś niezgodności ).

    pokaż komentarz
    AltumVidetur
  • Sh1eldeR 0  

    @lastof:

    Ja się z Tobą do końca nie mogę zgodzić. Nie pierwszy raz słyszę wymówkę "bo ma działać w IE" na usprawiedliwienie błędów w kodzie.

    OK, a jakież to błędy w HTML-u pomagają IE? Może brak prologu XML w XHTML-u (powoduje on wejście w quirksmode w IE), ale to jest dopuszczalne i błędem nie jest.

    Niepozamykane, źle zagnieżdżone tagi? Źle zakodowane znaki, niezrozumiane odwołania znakowe? Użycie Microsoftowych tagów (marquee, bleh!)? Nic z tego nie pomaga IE. Marquee to nie pomoc dla IE, bo czegoś takiego po prostu nie ma w HTML-u, więc użycie marquee (itp.) w IE nie jest rozwiązaniem żadnego problemu z tą przeglądarką.

    A co pomaga IE? Komentarze warunkowe, ale one nie powodują błędów walidacji, są poprawnymi komentarzami (X)HTML. Specjalne własności CSS? Tak, ale one nie są HTML-em, poza tym można je odseparować od poprawnego CSS dzięki komentarzom warunkowym.

    IMO to, że ma działać w IE, to tylko pusta wymówka, nie usprawiedliwiająca pisania niepoprawnego kodu. Jeśli masz jakieś (rzeczywiste) kontrprzykłady, bardzo chętnie je zobaczę -- na pewno z nich nie skorzystam, ale po prostu mnie to ciekawi.

    pokaż komentarz
    Sh1eldeR
  • nalej_mi_zupy -2  

    Wprowadzenie nowego standardu powinno być poprzedzone akcją kasowania wszystkich kReJzolSkich bLoDżżasków gorących szesnastek i definitywtego odcięcia im dostępu do kreowania czegokolwiek w Internecie. A z semantyki Internetu powinny być prowadzone powszechen kursy wśród blogerów.

    pokaż komentarz
    nalej_mi_zupy
  • Piw_Benzyna +6  

    Generalnie i mam wrażenie że szerokpasmowy internet powinien być dostępny dopiero po przejściu określonych testów psychologicznych, a jakby wszyscy twórcy słitaśnych blogasków musieli stukać je spod 56k to odechcialo by im się głupot ;]

    pokaż komentarz
    Piw_Benzyna
  • noiprox 0  

    Takie testy należałoby robić conajmniej raz do roku ;\

    pokaż komentarz
    noiprox
  • anath0r +2  

    myślicie o pokemonach a pomyślcie o sobie, o amatorach którzy wypowiedzą się w każdej sprawie i są pewni że mają rację, odsyłam do lektury książek Keena czy Lessiga ;)
    tak, dostanę minusy, ocenicie mnie, jest to jeden z problemów poruszanych w ww. literaturze ;]

    pokaż komentarz
    anath0r
  • pariah -1  

    osobiście najbardziej w htmlu brakuje mi znaczników do precyzyjnego określania kształu tekstu, np. dialog. Poza tym denerwuje mnie że nie można wykorzystywać grafik wektorowych z poziomu img, pomyślcie jakie layouty by się na tym trzaskało i jak wiele można by było w nich zmieniać samymi stylami!

    pokaż komentarz
    pariah
  • pstradomski +2  

    HTML nie określa kształtu, tylko znaczenie tekstu. Do wyglądu jest CSS.

    A swoją drogą dialog jest w HTML 5.
    Do grafik wektorowych - Opera i FF obsługują SVG (IE chyba nie obsługuje).

    pokaż komentarz
    pstradomski
  • liviopl 0  

    Oczywiście, że IE nie obsługuje SVG. Ale za to głównie dla IE, tworzony jest SilVerliGht. Ciekawy zbieg okoliczności, nie :> ?

    pokaż komentarz
    liviopl
  • jaj +1  

    canvas canvas - ten element jest twoim przyjacielem. Przecież z canvas można robić proste gierki 3D bez Flasha ani temu podobnych. Zobacz: http://labs.mininova.org/canvas/

    pokaż komentarz
    jaj
  • pariah -1  

    nenene, nie o to mi chodziło. Canvas canvasem, silverlight silverlightem ale ja bym był uradowany z czegoś takiego jak tło css które jest svg, tak samo fajnie by było jakby sobie wstawić svg img/object i w zależności od stylu zmieniać jego kolory. Co do fx to on ma dziki silnik renderujący svg, przynajmniej mi się gryzł z grafikami wygenerowanymi inkscapem (zwłaszcza pozycje i rozmiary tekstu). Po co mi to? Ano po to żeby robić ładne, skalowalne na bieżąco strony bez postrzępionych grafik, które czasem ciężko wykonać bez tony phpa który by skalował źródłowe dziadostwo w zależności od rozdziałki usera.

    A do kształtu tekstu to właśnie miałem na myśli semantykę, źle się wyraziłem, chodziło o kształt merytoryczny, stąd też dialog. Wiem że właśnie jest w html5 dlatego na niego czekam.

    pokaż komentarz
    pariah
  • lastof 0  

    Wszystkie czynności, które mogą być wykonane po stronie klienta, powinny być tam wykonane.

    pokaż komentarz
    lastof
  • pariah +2  

    Przecież takie svg będzie się skalować po stronie klienta, a bierz pod uwagę że taki js i wszystkie inne rzeczy do wykonywania czynności po stronie klienta są o wiele wolniejsze od czystego kodu maszynowego, w tym przypadku obsługi svg jako img wbudowanej w przeglądarkę.

    Poza tym nie wiem kto Ci powiedział że wszystko powinien wykonywać klient- to powinno być rozkładane pół na pół. Czemu? Przechylając ciężar na tylko jedną stronę zmuszasz ten sektor na dodatkowe wydatki i zaopatrzenie w lepszy sprzęt, równy rozkład sił jest najmniej szkodliwy dla obu stron i mniej zmusza do wydatków.

    Przy rzucaniu tez proszę następnym razem o konkretne argumenty.

    pokaż komentarz
    pariah
  • eXcore +3  

    @pariah: wedlug mnie nie masz racji z tym rozkladem fifty fifty. Wszystko zależy od wielu czynników.

    Po pierwsze bezpieczenstwo - nie nad wszystkim mozna pozwolic pracowac przegladarce uzytkownika
    Po drugie - czesto w obecnych czasach komputery użytkowników maja mocniejsze CPU niż te obsługujące serwis web po stronie serwera. I w przypadku, gdy użytkownik musi obsłuzyć tylko dane dla samego siebie, to serwer nie zajmuje się tylko jednym wywołaniem tylko często ruch jest znacznie większy.

    Według mnie wszystko co można i nie pogarsza przejrzystości i funkcjonalności i jest ogolnie mowiąc dobrze zrobione powinno być przekazane na barki użytkownika.

    pokaż komentarz
    eXcore
  • pariah 0  

    w sumie tak, tylko teraz patrz że dawanie userowi dużej papki w js raz że przy nierobieniu noscriptowej wersji zrobi sieczkę ze strony bez wykonania skryptów, dwa, że js jest powolny, bardzo powolny, zwłaszcza na starych maszynach. js jest od zmiany parametrów w locie, wszystko co ma być policzone raz a porządnie dla klienta liczę phpem na serwerze o ile na to zagadnienie pozwala bo tak jest po prostu szybciej. I po to mi właśnie obsługa svg jako img, wtedy odejdzie problem skalowania czy to phpem czy jsem.

    pokaż komentarz
    pariah
  • patryk_t 0  

    Czy ja dobrze widzę? 2022?... Przecież do tego czasu przeglądanie i tworzenie stron zmieni się 10 000 razy ;)

    pokaż komentarz
    patryk_t
  • soczysty 0  

    2022 to całkiem rozsądna data, html 4 ma swoje lata, trochę ewoluował, ale rewolucji w przeciągu tych lat nie będzie.. dalej jest to ten sam poczciwy html z lat 90tych - tylko trochę bardziej ostylowany .

    pokaż komentarz
    soczysty
  • Reinmar 0  

    A moim zdaniem data 2022 dyskwalifikuje HTMLa 5 w przedbiegach.
    Otóż główną ideą przyświecającą HTMLowi 5 jest dostosowanie kodu do realiów współczesnej sieci (czyli dynamicznych stron, różnorakich mediów itp). Skoro przez ostatnie 10 lat tak dużo się zmieniło, że HTML4 do niczego się już nie nadaje, to jak oni chcą przewidzieć, co się zmieni przez następne 14 lat?!

    Moim zdaniem jedyna sensowna droga, to opublikowanie w miarę szybko pełnej specyfikacji HTMLa 5, nawet nie koniecznie tak dopieszczonej pod wzg. obsługi tych błędów, czy co oni chcą tam dołechtać. I... czekać aż twórcy przeglądarek zbudują nowe silniki w pełni radzące sobie z nową specyfikacją.
    W zasadzie to można by nawet w obowiązującej specyfikacji na bieżąco robić zmiany, bo akurat trafiliśmy na taki okres kiedy wszyscy liczący się gracze dynamicznie rozbudowują swoje przeglądarki.

    Ale nie... my do 2022 roku nie będziemy mieli specyfikacji i kij wie, czy MS, Mozilla, Opera, Apple będą implementowały jeszcze niepełną specyfikację.

    pokaż komentarz
    Reinmar
  • pstradomski +4  

    Widzisz... WHAT WG dąży do tego, by w 2022 mieć HTML 5 jako standard zatwierdzony przez W3C. A to wymaga, by istniały dwie pełne implementacje standardu.

    Inaczej mówiąc wcale nie jest tak, że do 2022 nie zostanie wydane HTML 5. To oznacza, że dopiero wtedy będzie uznane jako standard - a zaimplementowane będzie już wcześniej (FF, WebKit i Opera obsługują już sporo nowinek z HTML-a 5).

    pokaż komentarz
    pstradomski
pokaż 

Wykopali i zakopali (104 / 5)