Allegro.pl

Powiązane (1)

  pokaż (1) 
Pokaż: ustaw jako domyślne
pokaż obrazki

Komentarze (82)

  • Reklamy Google

  • thorga +1  

    Jeśli ktoś w HTML robi syf na tabelkach, z niedomkniętymi, źle zagnieżdżonymi lub wyrzuconym już ze standardu znacznikami, nie oddziela wyglądu na CSS to oznacza to tylko i jedynie to, że jest "webmajstrem" produkujących strony typu "o mnie" w notatniku, zatrzymanym na poziomie "wstępu do HTML" z Chipa z 1998 roku ;)

    Ale to nie mój segment rynku - jeżeli ktoś chce stronę za max 300 zł, to mnie taki klient nie interesuje i tak - a że ktoś będzie miał badziewną stronę, to wizytówka jego firmy i tyle.

    Dobry webmaster tworzy witryny oparte na CSS, dbając o poprawność kodu i jego czytelność. Jeśli robi się to zawodowo, to nie jest to żadnym problemem - robi się to po prostu mechanicznie. Od jakiegoś czasu nie mam problemu nawet z IE - znając na pamięć jego bugi - np. z padding), od razu tworzę strony, które nie będą się rozjeżdżać. Praktycznie nie zdarza mi się po napisaniu kodu odpalić stronę w IE i stwierdzić, że coś się rozjechało (aczkolwiek nadal mnie zawsze ten fakt dziwi).

    pokaż komentarz
    thorga
  • no-name 0  

    Jeśli ktoś robi witryny zawodowo, to zazwyczaj zdaje się na CMF pracujący po stronie serwera, który serwuje mu kod w postaci "AS IS". I jeśli nic się nie sypie w sposób zauwazalny to naprawdę nie ma o o kruszyć kopii.

    pokaż komentarz
    no-name
  • Sh1eldeR 0  

    @no-name:
    ???
    Przecież w dobrych frameworkach/CMS-ach kod HTML jest generowany w oddzielnej warstwie -- widokach (czasem jest tam jawny podział MVC, czasem niejawny, ale przeważnie oddzielenie występuje). Mogą to być szablony takie jak popularne Smarty, czy nawet czyste PHP. Ale założenie jest takie, by było to łatwe w edycji dla webdeveloperów zajmujących się kodem po stronie klienta. Dzięki temu nie ma problemów z edycją kodu HTML, a CSS czy JavaScript tym łatwiej można zmienić, bo one są wydzielone w osobnych, statycznych (zwykle) plikach.

    pokaż komentarz
    Sh1eldeR
  • thorga 0  

    Nie mam na myśli robienia stron opartych o gotowe darmowe rozwiązania, tylko od podstaw (korzystam z własnych klas PHP, które modyfikuję w zależności od potrzeb). Raczej każdy klient chce stronę wyglądającą inaczej (albo wynika to z tego, że ma mieć inne funkcjonalności) więc zawsze szablony HTML (smarty) przygotowuję od początku, to szybsze niż przerabianie, nawet własnego kodu.

    pokaż komentarz
    thorga
  • Cubes +7  

    Informacja ciekawa i nawet bym wykopał, ale 3 linijki tekstu to chyba trochę za mało, aby uznać to za interesujący artykuł.

    pokaż komentarz
    Cubes
  • nea +3  

    Jak jesteś tak chłonny wiedzy to pod artykułem jest całkiem sporo komentarzy :).

    pokaż komentarz
    nea
  • leshniak +7  

    Informacja na blogu W3C ( http://www.w3.org/News/2009#item119 ) jest nawet mniej obszerna.

    pokaż komentarz
    leshniak
  • chinesebox +5  

    Lepsze 3 linijki konkretnego tekstu niż kilka stron lania wody z taką samą ilością informacji :)

    pokaż komentarz
    chinesebox
  • Anatejms 0  

    Jak dla mnie to na razie nic ciekawego sie nie dzieje w zwiazku z html5 miałem juz nadzieje ze coś wyjdzie z audio i video ale oczywiscie ktos stracił by na tym pare dolarow i wszystko poszło w błoto.

    pokaż komentarz
    Anatejms
  • Sh1eldeR 0  

    @Anatejms:
    A co powiesz na nowe semantyczne elementy? nav, header, footer, article itp.? Albo na takie, dzięki którym nie trzeba będzie oskryptowywać niektórych rzeczy? Np. details, czy cały moduł formularzy? Albo na dobrze zdefiniowaną obsługę błędów, czy choćby prostszy DOCTYPE?

    pokaż komentarz
    Sh1eldeR
  • leshniak +1  

    Właśnie, doctype HTML 5 to jest dla mnie strzał w dziesiątkę, nareszcie będę mógł z pamięci napisać.

    pokaż komentarz
    leshniak
  • BoskiApollo +2  

    a mi się marzy (x)HTML, który się posypie i po prostu zatrzyma, jeśli nie będzie poprawnie napisany. i CSS też. i żeby nie można było jawnie podejrzeć, skopiować źródła.
    skończy się wtedy era znafcuff HTMLa i gimnazjanych webmasterów, którzy stawiają strony za piwo, bo podj$%ali komuś kod, albo nasrali 430970987 tabelek i się przy tym pałują, bo nie ważne jak napisane - ważne że działa.
    może ludzie wtedy zaczną poważnie traktować webmasterów/koderów, i przestaną szukać frajerów.
    ktoś szuka pracy? http://praca.money.pl/oferta/pracownik;biurowy,opis,2054404.html ;)

    pokaż komentarz
    BoskiApollo
  • nea +1  

    I żeby od razu blue screen w Windowsie wywalało, AWESOME!

    pokaż komentarz
    nea
  • leshniak +1  

    Przecież w prawdziwym XHTML-u (application/xhtml+xml) tak jest. Zaserwujesz HTML 5 jako XML i myślę, że będzie podobnie. Podglądanie źródła ograniczysz przez blokowanie menu JSem (w małym stopniu, bo można zapisać stronę do pliku lub wyłączyć JS/blokowanie menu, ale zawsze). Poza tym kompresując pliki HTML/CSS, czyli pozbywając się zbędnych spacji i przejść do nowej linii stworzysz mniejszy objętościowo, nieczytelny, zniechęcający do podglądania kod. Niestety również dla Ciebie.

    pokaż komentarz
    leshniak
  • BoskiApollo +2  

    nea - no i co w tym złego? zj#$ałeś kod, to masz błąd i go popraw, chyba normalne?

    leshniak - pomijając fakt, że blokowanie menu jest gejowskie, to już nawet nie pamiętam jak się podgląda źródło za pomocą myszy. ludzkie przeglądarki mają np taki fajny skrót jak ctrl+f3 ;)

    pokaż komentarz
    BoskiApollo
  • leshniak 0  

    Nieprawda, bo CTRL+U (Fox) :P

    Mówimy o dzieciach neo, czy webmasterach? Logiczne, że webmasterów się tak nie powstrzyma.

    pokaż komentarz
    leshniak
  • nea -1  

    BoskiApollo: a co informacja o tym że kod jest zj!$any daje userowi, poza tym że go wk!##ia i nie pozwala używać aplikacji? Developer powinien mieć informacje o błędach, ale powinien ją mieć w konsoli / trybie developerskim / validatorze do tego stworzonym. Programiści to też ludzie i nawet najlepszym czasami zdarza się walnąć babola, wyświetlenie userowi strony z informacją o błędzie XML'a w linii numer 425 jest nie do zaakceptowania.

    pokaż komentarz
    nea
  • BoskiApollo +1  

    nea, ale ja mówię właśnie o developerze, a nie użytkowniku... żeby nie było tak jak jest dzisiaj - obojętnie co nie nasrasz w htmlu, i tak będzie działać, tylko będzie niezgodne z w3c czy innymi. chodzi o to, żeby na rynek (w sieć) nie zostały wypuszczane tandetne babole robione przez głąbów, którzy umieją napisać [table] (reszta strony) [/table] i mają się za mega giga webmasterów.

    pokaż komentarz
    BoskiApollo
  • leshniak 0  

    BoskiApollo: validator prawdę Ci powie przecież. Polecam rozszerzenie Web Developer do Firefox'a lub zrobienie sobie bookmarkletu do walidacji.

    pokaż komentarz
    leshniak
  • BoskiApollo 0  

    leshniak, ale o czym prawdę ma mi mówić walidator? że jest niepoprawnie napisana? tyle to ja sobie mogę powiedzieć przeglądając pobieżnie źródło. mam wrażenie, że się nie rozumiemy ;)
    a webdevelopera mam, ale firefoxa nie znoszę (400mb ramu zjedzone przy 2 zakładkach? kpina), w związku z czym nie używam.

    pokaż komentarz
    BoskiApollo
  • xorock 0  

    Oj ludzie, jak developer dupa to mu nic nie pomoże. Porządne systemy szablonów informują o błędzie w składni (rzucając wyjątkiem a nie YSOD), a gdy dane pochodzą z zewnątrz jest choćby tidy czy dowolny filtrator treści który potrafi zaemulować działanie tidy. Nie w xhtmlu trzeba szukać przyczyny.

    pokaż komentarz
    xorock
  • no-name 0  

    Szczytny cel, ale bzdurny. Widziałeś kiedyś jakiś duży system/portal wypluwający kod od A do Z zgodny ze standardami? Ja nie. Dążenie do doskonałości to domena pryszczatych webmajstrów, którzy nadziubali swoją pierwszą stronę w XHTML Strict/Srict i czują się z tego powodu hardkorami. W realnym świacie i w prawdziwych projektach są rzeczy znacznie ważniejsze niż bezwzgędna zgodność z wytycznymi W3C.

    pokaż komentarz
    no-name
  • leshniak +1  

    @BoskiApollo, no nie zrozumieliśmy się :). Moim zdaniem każda przeglądarka powinna sygnalizować błędy tak, jak to robi WebDeveloper. Zawartość strony można by zawsze bez problemu obejrzeć, ale jak się pojawią 3 iksy od HTML, CSS i JS, to wiadomo, że kodował to jakiś pajac. I tyle wiadomości dla przeciętnego usera/zleceniodawcy. A jak developer będzie potrzebował konkretnych informacji, to zajrzy do konsoli.
    Lub domyślnie zaznaczony ptaszek w opcjach: "używaj restrykcyjnego parsowania".

    Chociaż nie rozwiązuje to do końca problemu, no bo "przecież działa". Jakoś.

    A jeśli jakiś zleceniodawca będzie wolał stronę od gimnazjalisty, niż od profesjonalnego webmastera, bo jest tańsza, to już jego sprawa i świadczy to o nim. Prezencja taką stroną nie będzie dla niego zbyt korzystna.

    Edit: oczywiście są też młodzi pasjonaci, którzy potrafią zrobić dobrą stronę. Nie można uśredniać.

    pokaż komentarz
    leshniak
  • entrop 0  

    @no-name
    czyjś brak umiejętności napisania strony zgodnej ze standardami nie jest żadnym wytłumaczniem. Poza tym tu chodzi o coś zupelnie innego - wielkie serwisy nie powstały wczoraj, tylko dawno dawno temu zostały zrobione przez anonimowych ludzi, po których kolejne "pokolenia" webdevów poprawiały, dopisywały i nakladały - z większą lub mniejszą wprawą. Widziałem kiedyś cssa jednego z takich "dużych" portali i gadałem z jednym z jego aktualnych webdevów. Tego się nie da przeglądać, każdy się boi coś zmienić bo nie wiadomo co się stanie, co drugą linijkę jest !important, nikt się nie podejmnie przepisania tego na nowo, bo to by była mordercza praca na kilka lat.
    Tak, takie strony nigdy nie będą zgodne ze standardami.

    pokaż komentarz
    entrop
  • nea 0  

    entrop: stare portale powiadasz. Google maps - 149 błędów w validatorze, nie jest to bynajmniej stary jakiś portal i nie jest bynajmniej stworzony przez jakiś nieudolnych programistów, wręcz przeciwnie.

    pokaż komentarz
    nea
  • leshniak 0  

    @nea, Google jest wyjęte spod prawa. Ich kod jest źródłem chaosu na świecie :P. Nie definiują nawet doctype.

    pokaż komentarz
    leshniak
  • xorock 0  

    @nea: tu nie chodzi o to że oni mają genialnych programistów, G jest zaraz po MS najmocniejszym członkiem w3c i mogą zrobić wszystko. Nie działa gmail - nie ma sprawy, szast prast - specyfikacja css zmieniona, już działa jak trzeba. A z drugiej strony skoro są tak boscy dlaczego przez lata używają font i inne śmieci na google.com (mimo że nawet ludzi za nich zrobili robotę przepisując im ładnie stronę)? Dlaczego adsense i ich wszystkie projekty korzystają z document.write()? Albo projekt prettify (kolorujący składnię na code.google.com, dostępny do pobrania): "Add onload="prettyPrint() to your document's body tag." 2009 rok a ci o onload piszą.

    pokaż komentarz
    xorock
  • nea 0  

    Microsoft i Google członkami W3C? Pewnie dlatego Google dołączyło do grupy WHATWG, by mogli sami sobie (tzn. W3C) narzucić HTML'a 5. Ktoś ci tam panie jakiś bajek naopowiadał.

    A onload sam stosuję, czasami potrzeba jednak poczekać na załadowanie całego contentu i domready nie wchodzi w grę.

    pokaż komentarz
    nea
  • xorock 0  

    http://www.w3.org/Consortium/Member/List Co w tym niby dziwnego? WHATWG to taka grupka własnych interesów bardziej, gdzie liczy się jakby tu kaski więcej zarobić. Nie zgadzają się z idealistycznym podejściem TBL.

    2) a o addEventListener/attachEvent to słyszał? Wnioskuję że nie.

    pokaż komentarz
    xorock
  • nea 0  

    To raczej ludzie piszący standardy w W3C są jakimiś kosmitami w koszulach w kratkę, którzy nie mają pojęcia o realnym świecie i problemach z jakimi borykają się developerzy. Są w standardach W3C momentami takie bzdury, że za głowę można się złapać.

    I nie, nie słyszałem o eventach, a domready to sobie podpinam do stron na plastelinę. Jeśli używasz jakiegokolwiek frameworka na stronie, to sobie podepniesz tą funkcyjkę googlową do eventu, jeśli jesteś raczkującym copy pasterem to zrobisz jak google radzi i wpiszesz sobie ładnie w html'u onload i też będzie działać. Unobstrusive JavaScript jest fajny, ale nie zawsze jest konieczny.

    pokaż komentarz
    nea
  • feuerfest +1  

    i bardzo dobrze, bo nad xhtml nie ma sie co spuszczac, prawie nikt go nie wykorzystywal do tego d oczego on byl stworzony, ludzie przyjeli go jako nastepce HTML a gowno prawda. mnie osobiscie porzucenie xhtml i skupienie sie na html cieszy

    pokaż komentarz
    feuerfest
  • pies_harry +3  

    Prawdą jest, że wielu ludzi korzystało z XHTML serwując dokumenty XHTML jako text/html zamiast application/xhtml+xml. Dzięki temu przeglądarki akceptowały każdą sieczkę na wejściu.

    Dlaczego wysyłali jako zły typ? Dlatego, bo "wiodąca" przeglądarka nie akceptowała w ogóle typu application/xhtml+xml. I tak to panom z Microsoftu udało się zatrzymać w rozwoju sieć na kilka lat i ostatecznie zatańczyć na grobie jednego z najlepszych pomysłów W3C.

    Pogrzebowo, przypomnijmy sobie do czego XHTML w ogóle był:

    1. Prostsza składnia maksymalnie rozdzielająca styl od treści ( vide http://www.csszengarden.com/ )
    2. Kompatybilność z XML dzięki czemu do przetwarzania dokumentów można było użyć tych samych narzędzi i metod
    3. Dokument XHTML może być traktowany jako znormalizowana struktura drzewa - z której stosunkowo łatwo, szybko, jednoznacznie i skutecznie można wyciągnąć dowolny element i treść
    4. Struktura drzewa XHTML jest też łatwa do modyfikacji - i po stronie serwera (modyfikacja gotowego szablonu) i po stronie przeglądarki (przez JavaScript)

    Brak wymuszania poprawności dokumentu HTML powoduje, że program przetwarzający, operujący na takim dokumencie nie może nic z góry zakładać. W zasadzie każdą operację którą w XHTML po prostu się wykonywało - bez sprawdzania poprawności trzeba najpierw poprzedzić serią sprawdzeń. Teraz kod przetwarzający musi więcej zgadywać, co też autor mógł mieć na myśli, i gdzie też nasz geniusz mógł ukryć dane.

    Z drugiej strony, nie ma co płakać nad rozlanym mlekiem. HTML5 ma podobnie jak kiedyś XHTML uprościć budowę dokumentu przy utrzymaniu istniejącego rozgraniczenia pomiędzy stylem i treścią. HTML5 wystarczy. Tym bardziej, że można go w bardzo prosty sposób przetworzyć na XML.

    pokaż komentarz
    pies_harry
  • feuerfest +2  

    http://pornel.net/xhtml

    pokaż komentarz
    feuerfest
  • jk1700 0  

    pies:

    1. a to w HTMLu nie ma rozdzielenia wygladu od tresci??
    3, 4. w HTMLu rowniez dobrze dzialaja metody na DOMie, mozesz wydlubywac elementy, dodawac itp, nie ma jedynie obslugi przestrzeni nazw

    pokaż komentarz
    jk1700
  • BoskiApollo 0  

    pies, akurat poza tym, że każdy tag musi być zamknięty i wszystko piszemy małymi literami, xhtml od htmla niewiele się różni. tak samo możesz się odwoływać do czego chcesz (chociażby przez javascipt), robić z tym co chcesz. xhtml jest nieco bardziej restrykcyjny i ma z pięć nowych tagów (które nie działają z tego co pamiętam pod IE). zresztą - chociażby cała agora (gazeta.pl i reszta serwisów) stoi na html i jakoś żyją.

    pokaż komentarz
    BoskiApollo
  • pies_harry +1  

    @nea:

    Uff, całe szczęście :) Te wynalazki to tylko oszczędzacze czasu. Jeśli wybór jest HTML5 vs XHTML1 - głosuję na HTML5. Ale HTML3/4, z tagami "font", atrybutami "border" - dziękuję. Czytałem kiedyś o Forms 2.0. To dopiero będzie wypas - walidacja w standardzie. Z drugiej strony, pewnie miną jeszcze ze 2 lata zanim przeglądarki zaczną to obsługiwać. Na dzień dzisiejszy większość przeglądarek nie obsługuje poprawnie CSS2.1. Znając życie pierwsza zacznie obsługiwać HTML5 pewnie Opera. A Firefoxowcy dalej będą krzyczeć, żeby olać Operę, bo przecież jest taka niszowa i mało kto używa. Do FF pewnie powstanie plugin który będzie obsługiwał 2/3 HTML5 :) I plugin rozszerzający funkcjonalność tego plugina :)

    pokaż komentarz
    pies_harry
  • Sh1eldeR 0  

    @pies_harry:
    W aktualnym HTML-u, 4.01 Strict, nie ma w ogóle elementów font. A właśnie tego DTD powinieneś używać w większości przypadków.

    pokaż komentarz
    Sh1eldeR
  • cypherq -1  

    Planowana data ukończenia: 2022. Świat zdąży pójść do przodu (o ile się w tym czasie nie cofniemy), że WWW w formie którą mamy do dyspozycji dzisiaj, stanie się przeżytkiem.

    Negatywnym skutkiem zamknięcia XHTML1 / 1.1 i zaprzestanie rozwijania XHTML2 będzie spowolnienie implementacji tego standardu w przeglądarkach. Pół roku, rok i pogrążymy się w jeszcze większym chaosie niż ten który mamy obecnie.

    pokaż komentarz
    cypherq
  • kkll 0  

    http://pornel.net/html5#seca0

    pokaż komentarz
    kkll
  • RudeBoy 0  

    Bardzo dobra wiadomość. HTML 5.0 - na to czekamy. Ci co psioczą, że się cofamy wstecz nie mają zielonego pojęcia czym będzie HTML 5. Szkoda tylko, że jeszcze XHTML porządnie nie został zaimplementowany w niektórych browserach więc takie posunięcie W3C pewno tego nie poprawi.

    pokaż komentarz
    RudeBoy
  • entrop 0  

    No kurcze, a ja akurat próbuję napisać pierwszą stronę w xhtmlu Strict'cie 1.1. W sumie uważam to za daremny trud, bo wszytsko robię bo staremu, tylko pojednyncze tagi inaczej się kończą i wc3 wywala kilka nowych błędów.
    Nie wiem o co tyle zamieszania, html pozostanie html'em w którym będzie można wpisać byle co i się wyświetli. Przynajmniej dopóki strony typu "najlepiej oglądać w ie i rozdzielczości 1024" będą miały rację bytu.
    Po prostu uważam, że jest zbyt prosty na rewolucyjne zmiany.

    pokaż komentarz
    entrop
  • leshniak +1  

    Na XHTML 1.1 na pewno nie ma sensu się wysilać. Lepiej napisać w XHTML 1.0 Strict (to prawie to samo, a bardziej kompatybilne), bądź w HTML 5 zgodnie ze składnią XML (ostatni raz się powtarzam).

    P.S. rozumiem tę radość jak skomplikowana strona przejdzie walidację :D

    pokaż komentarz
    leshniak
  • Sh1eldeR +1  

    @leshniak:
    Walidator to (przeważnie) dobry przyjaciel, a nie wróg. Zauważ, że napisanie poprawnego kodu znaczników HTML 4.01 lub XHTML jest stosunkowo proste. Mimo to stworzenie złożonej strony tak, żeby nie zawierała błędów, rzadko się udaje tak od razu. Błędy wynikają jednak przeważnie z naszej nieuwagi, literówek, czy zapominalstwa.

    No bo co jest takie skomplikowane, gdy świadomie pisze się kod HTML? Że nie można wstawiać ul bezpośrednio w ul, tylko trzeba drugą listę wstawić w li? To takie trudne lub nielogiczne? Nie. A może że w formularz nie można luzem wrzucać pól, tylko trzeba je czymś otoczyć? Albo że w head trzeba koniecznie wstawić title?

    Najczęściej nie ma tu wielkich trudności. Niektóre rzeczy są jednak upierdliwe -- konieczność kodowania ampersandów, czy to, że listy nie mogą być puste. Nie jest to jednak budowa rakiety kosmicznej. (problematyczne bywa to, że linki nie mogą zawierać elementów blokowych, ale to akurat HTML 5 obchodzi).

    pokaż komentarz
    Sh1eldeR
  • pies_harry -4  

    @feuerfest:

    Artykuł Pornela jest sprzed kilku lat, i jakieś 2 lata temu go czytałem - już wtedy przewidując, że mocno się myli. W czasach kiedy pisał ten artykuł sieć wyglądała inaczej. XHTML był nowinką. Serwisy internetowe były zdominowane przez produkty kompletnych amatorów i nie bójmy się tego słowa, dzieciaków.

    Sieć się zmieniła. Dzięki tzw Web2.0 młodzież porzuciła radosną twórczość w dziedzinie HTML na rzecz serwisów społecznościowych, względnie gotowych CMS-ów typu WordPress. Małe firmy zamiast zlecać tworzenie serwisów synowi kumpla zlecają to zawodowcom. A zawodowiec, ze względu na swoją praktykę, wiedzę odnośnie pracochłonności wdrażania poszczególnych technologii wie jakich standardów warto się trzymać.

    Robię w XHTML, bo dzięki temu jestem w stanie tworzyć aplikacje obsługujące dziesiątki formularzy, odnośnie których klienci (czyli zleceniodawcy) stale mają jakieś uwagi, stale życzą sobie jakiś zmian, a zmiany w samej grafice czy layoutach są w standardzie.

    Mój framework operuje na drzewie DOM, dzięki temu jest w stanie przetwarzać HTML na wszelkie możliwe sposoby, co ważne - w sposób całkiem automatyczny - np generować złożoną treść (rich content) używając bazy danych lub innych dynamicznych źródeł.

    Weźmy sobie taki CMS. Mamy część admina, część klienta, możliwość zamieszczania przez klientów własnych sformatowanych dokumentów HTML. Jedną z potrzebnych rzeczy jest np automatyczne wypełnianie formularzy. Podręcznikowy przykład - edycja rekordu w bazie danych. Jeśli potraktujesz HTML jako tekst, kod który to realizuje będzie zagmatwany, rozbudowany i skomplikowany. Co za tym idzie zawodny i podatny na błędy. Moja funkcja która to załatwia ma kilka linii kodu (bardziej dla czytelności niż z innych względów). Jest prosta do bólu, jeśli dostanie na wejściu poprawny formularz XHTML i rekord danych - nie ma możliwości błędu - na wyjściu utworzy poprawny wypełniony formularz.

    Dalej, spróbuj napisać metodą przetwarzania tekstu funkcję, która przepuszcza tylko ograniczony podzbiór elementów HTML - tak żeby HTML klienta nie miał możliwości uszkodzenia layoutu Twojej strony, żeby wyglądał, pomimo formatowania - dokładnie tak, jak zaprojektował to grafik serwisu. Życzę powodzenia. Przechodziłem przez to. Funkcja miała ponad 1000 linii kodu, była zabójczo wolna, i co jakiś czas specyficzny HTML klienta rozwalał layout i tak. Nowa, używająca przetwarzania DOM - ma 10 linii kodu i jest zabójczo skuteczna. Zabójczo szybka też - demon PHP nie interpretuje setek linii kodu, złożone operacje na drzewie DOM wykonuje zoptymalizowany kod napisany w C.

    Co ciekawe, do napisania mojego frameworka zainspirował mnie ten sam krytyczny wobec XHTML Pornel. Zrobił coś podobnego, tyle że jego framework wydawał mi się trochę zbyt ezoteryczny i kłopotliwy w użyciu, potrzebowałem coś, co zrobi mi "hello world" w góra 3 liniach kodu, a wyświetlenie gotowego layoutu w 5.

    XHTML był bardzo pomocny. Chociażby nauczył mnie widzieć dokument HTML jako drzewo DOM. Od tego chyba z resztą nie ma już odwrotu. Dzisiejsze przeglądarki właśnie w ten sposób przetwarzają layouty - bez tego JavaScript byłby bezużyteczny. Z XHTML1.1 wyleciała metoda document.write(). Bardzo dobrze. Niech nie wraca.

    pokaż komentarz
    pies_harry
  • nea +1  

    Skoro już się tak napracowałeś to wiedz, że HTML'a 5 możesz bez problemu serwować przeglądarce jako XML i wszystkie twoje wspaniałe wynalazki będą działać dalej.

    pokaż komentarz
    nea
  • michuk +3  

    Najmniej fajna w tym wszystkim wydaje mi się jednak rezygnacja W3C z tagó audio i wideo i natywnej obsługi multimediów w przeglądarkach z użyciem otwartych standardów Ogg/Theora
    I to wszystko dzięki lobbyngowi Apple i Nokii, mimo wydania przez Mozillę 100 tysięcy USD na lobbyng za tymi tagami: http://osnews.pl/mozilla-wyda-100-tysiecy-usd-zeby-przeforsowac-theore/

    pokaż komentarz
    michuk
  • nea +2  

    Nie wiem czy wiesz, ale np. gmail używa HTML'a 4.

    edit: michuk - tagi audio i video zostają. Standard nie będzie po prostu opisywać z jakich kodeków muszą te tegi korzystać, tak jak się to miało z img.

    pokaż komentarz
    nea
  • leshniak +1  

    Wstecz? HTML5 ( http://pl.wikipedia.org/wiki/HTML_5 ) będziesz mógł również wysyłać jako XML, jeśli będziesz chciał.

    pokaż komentarz
    leshniak
  • michuk +2  

    @nea racja, tagi audio/video pozostaną, ale właściwie stracą sens, jeśli domyślnym odtwarzaczem nie zostanie wolny format.

    pokaż komentarz
    michuk
  • nea +1  

    IMHO domyślnym formatem zostanie to, czego zaczną używać ludzie, a jest bardzo duża szansa że zaczną używać ogg, bo to już działa :). Producenci przeglądarek wbrew pozorom często dbają o kompatybilność nawet wbrew standardom (tak powstał Ajax).

    pokaż komentarz
    nea
  • Sh1eldeR +3  

    @Wuerzet:
    Wrócić do HTML 4? A jak daleko od niego odszedłeś? Domyślam się, że stosowałeś XHTML 1 lub 1.1. Co on Ci umożliwiał, na co nie pozwala HTML 4.01?

    Zbyt wiele osób do tej pory nie kuma, że w (przytłaczającej) większości przypadków używany przez nich XHTML nie jest lepszy od HTML-a 4.01. Zresztą... oni nawet nie tworzą poprawnych dokumentów XHTML 1.0 (lub 1.1) Strict/Transitional, więc w ogóle nie powinni do XHTML-a podchodzić. Takie strony istnieją tylko dlatego, że przeglądarki są tak pobłażliwe i nie traktują XHTML-a jak XML-a. Bo XML (a więc i "prawdziwy" XHTML) nie wybacza błędów.

    pokaż komentarz
    Sh1eldeR
  • otello +3  

    to pomyśl jak będą musiały być pobłażliwe wobec html'a 5. Kolejne nowe elementy a to oznacza kolejne interpretacje może już nie tak duże odstępujące od standardów jak kiedyś ale jednak znowu się pojawią

    pokaż komentarz
    otello
  • nea 0  

    A co ma się niby złego dziać? HTML5 jest HTML'em, jeśli starsza przeglądarka dostanie tagi których nie rozumie to... ich nie obsłuży i poleci dalej.

    pokaż komentarz
    nea
  • otello -1  

    jesteś pewny jak się zachowa stary IE? kóry zawsze jakimś dziwnym trafem miał problemy z interpreacją standardów

    pokaż komentarz
    otello
  • leshniak -1  

    Jeśli IE robiłby za duży cyrk, w ostateczności można użyć < !--[if IE] >
    < ![endif]-- > etc.

    pokaż komentarz
    leshniak
  • nea +1  

    Problemy z XHTMLem na starych IE wynikały z tego, że XHTML wprowadza nową składnię, dlatego między innymi w XHTML'u piszemy [br /] a nie [br/] - dzięki tej dodatkowej spacji stare HTML'owe parsery traktują ukośnik jako dodatkowy argument i go ignorują. W czystym XHTML'u spacja nie jest tam do niczego potrzebna, ale bez niej stary parser może zinterpretować taki tag jako "br/" zamiast "br" i się wyłożyć.

    pokaż komentarz
    nea
  • Sh1eldeR +2  

    @nea:
    @otello:
    IE6 przy HTML-u 5 się wykrzaczy. Nie pozwoli na ostylowanie nieznanych elementów -- samo to już jest wystarczającym przypałem, póki ta przeglądarka żyje. Można to obejść stosując sposób, który podałem -- zamiast nowych elementów dorabiać klasy do już istniejących. Potem teoretycznie łatwo to można zmienić.

    Co do komentarzy warunkowych to nie wiem... Wątpię. Chyba żeby ktoś używał tylko kilku elementów z HTML 5 w najbardziej newralgicznych miejscach. Np. jakby koniecznie chciał użyć nav. Bo tak to otaczanie tagów komentarzami warunkowymi jest... nieefektywne i niepraktyczne. Można ewentualnie dawać IE uproszczoną wersję HTML-a. To jednak oczywiście oznacza prawie zawsze zwrot kosztów (chyba że ktoś napisze CMS/system szablonów, który dba o to automatycznie).

    pokaż komentarz
    Sh1eldeR
  • leshniak 0  

    @Sh1eldeR: Tak więc zaznaczyłem, gdyby IE robiło za duży cyrk, w pojedynczym przypadku przy ręcznym pisaniu strony. Większa ilość do zniesienia w przypadku stron generowanych, jak już wspomniałeś. Myślę, że po zadomowieniu się Windows 7, będziemy mogli już olać IE6, a nawet IE7. Szczególnie, jeśli Microsoft zdecydowałby się na wypuszczenie IE8 jako obowiązkową, automatyczną aktualizację dla XP i Visty. Bynajmniej mam taką nadzieję...

    pokaż komentarz
    leshniak
  • nea 0  

    @Sh1eldeR: długo nie pożyje, zanim html5 rozwinie się do jakiegoś w miarę sensownego poziomu IE6 będzie takim samym zabytkiem przeszłości jak IE5.5 jest teraz. Statystyki na W3schools (link: http://www.w3schools.com/browsers/browsers_stats.asp ) dają IE6 "aż" 14.5% na maj 2009, tendencja spadkowa około 1% / miesiąc, jeszcze rok i mamy tego babola z głowy.

    Statystyki z moich stronek nie są specjalnie reprezentatywne, ale z 8.44% userów używających IE tylko 7.69% używa IE6 (co daje mi ładne ~0.65% userów z IE6, więc ja już zdecydowanie olewam IE6).

    pokaż komentarz
    nea
  • jk1700 +2  

    @Sh1eldeR : da sie ostylowac, trzeba jedynie dodac na poczatku np createElement('header') i wszystko bedzie cacy
    Niestety problem jest przy Fx 2.0 i wczesniejszych, bo tam to juz w ogole nie ma sposobu na ostylowanie takich rzeczy, a caly czas dosyc sporo ludzi uzywa tej wersji

    pokaż komentarz
    jk1700
  • Sh1eldeR 0  

    @jk1700:
    To z kolei wymaga włączonego JavaScriptu, więc każdy musi sobie samodzielnie rozpatrzyć taką możliwość.

    Ja na razie boję się używać nowych elementów (może w niektórych wypadkach niesłusznie), ale jestem za promowaniem HTML-a 5 choćby poprzez tworzenie w nim dokumentów maksymalnie zgodnych z HTML-em 4.01 (Strict). Nowe elementy semantyczne są super. Zresztą nawet gdy po prostu dołączam klasy do ogólnych, już istniejących elementów, to co mi szkodzi używać nazw klas zgodnych z nowymi elementami. Dzięki temu w każdym projekcie .nav to będzie nawigacja, a .footer -- stopka. To dobre, strukturalne nazwy, a stosowanie się właśnie do nich (choćby w atrybutach class) zwiększa spójność Twojego kodu.

    pokaż komentarz
    Sh1eldeR
  • nnernner 0  

    Chcesz powiedzieć, że specyfikacja z 2009 roku jest starsza od specyfikacji z 1999 i 1997?

    http://pornel.net/html5/#sec90 - tu to jest ładnie wyjaśnione.

    pokaż komentarz
    nnernner
  • azotyp -1  

    Bardzo dobrze smaż się w piekle formacie xhtml . Ty do którego musiałem sobie doinstalowywać kiedyś plugina do starego worda, Niech żyje doc !!!! :)

    pokaż komentarz
    azotyp
  • leshniak 0  

    a fuj.

    Co Ty chciałeś robić w Wordzie z XHTML-em :D?

    pokaż komentarz
    leshniak
  • maxbmx -4  

    wtf?

    pokaż komentarz
    maxbmx
  • leshniak +5  

    Idź na BMX-a pojeździć.

    pokaż komentarz
    leshniak
  • spooky -8  

    1. informacja nieprawdziwa - prace nad xhtml zostały zawieszone i prawdopodobnie zostaną reaktywowane po ukończeniu html5
    2. nie nadaje się, ponieważ to żadna rewolucyjna zmiana. xhtml poczeka sobie na lepsze czasy, gdy będzie mieć wsparcie ze strony IE lub IE przestanie być dominującą przeglądarką.

    pokaż komentarz
    spooky
  • nea +7  

    1. W notce na stronie W3C czytamy:

    Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed.

    Pozatym po ukończeniu html5 (przypominam, planowana data rok 2022) pewnie już nikt nie będzie pamiętać że coś takiego jak xhtml istniało (i dobrze).

    2. To niech sobie czeka, a ja w tym czasie będę rozwiązywać prawdziwe problemy w prawdziwych aplikacjach webowych.

    pokaż komentarz
    nea
  • leshniak 0  

    @nea
    planowana data rok 2022) pewnie już nikt nie będzie pamiętać że coś takiego jak xhtml istniało
    a na czym mają do tego czasu powstawać strony, jeśli nie na HTML4/XHTML ?

    Zgodność z XML w przypadku XHTML ma swoje plusy, ale HTML też ma mieć opcję dokumentu zgodnego z tym standardem, więc jak komuś będzie to potrzebne do jakiś przekształceń na dokumentach XML (co rzadko się zdarza), to sobie skorzysta.

    pokaż komentarz
    leshniak
  • nea +2  

    Rozumiem że to pierwsze pytanie było retoryczne, ale skoro już się na google powoływałem, to powołam się jeszcze raz - mapy google już przedstawiają się z doctype'em html'a 5. Pomijając oczywiście dodatkowe tagi i ficzery można zacząć pisać zgodnie z html'em 5 już dziś. Producenci przeglądarek dla tego już teraz implementują audio i video, by można było korzystać z dobrodziejstw 5ki jeszcze przed zamknięciem standardu (co niczym nadzwyczajnym nie jest, nie pierwszy raz standard zostaje ukończony po fakcie cough ECMAScript cough).

    Zgodność z XML'em ma swoje plusy, parsowanie dokumentu jako XML ma też jednak swoje minusy, ostatnią rzeczą którą user chce zobaczyć jest yellow-screen-of-death. To dobrze że XHTML wymusza poprawność składni, jednak robi to w najgorszy z możliwych sposobów.

    Dziwi mnie, że jakoś nikt nie bierze pod uwagę tego, że w samym html'u da się zrobić nowoczesną, elegancką, zgodną ze standardami stronę tak samo, jak w xhtmlu da się zrobić stronę na tabelkach której kod będzie "zupą tagów". To tak jakby sam fakt używania xhtml'a w jakiś magiczny sposób oddziaływał na developerów i skłaniał ich do pisania poprawnie.

    pokaż komentarz
    nea
  • Sh1eldeR +6  

    @spooky:
    XHTML musiałby sobie poczekać przede wszystkim na to, aż webdeveloperzy będą się zachowywali jak programiści i przestaną popełniać błędy na każdym kroku.

    @leshniak:
    HTML 5 jest tak napisany, że można tworzyć w nim strony już teraz. Rodzi to pewne problemy, ale nie aż takie duże. Nieoficjalnym standardem jest używanie atrybutów class zamiast wstawiania nowych elementów. Zamiast elementu nav wstawiasz zwykły div, któremu dajesz klasę nav. Ja tak robię już od dawna. Podobnie możesz stosować inne strukturalne tagi -- klasy article, header, czy footer.

    Jeśli ktoś nie chce mieć ŻADNYCH skutków ubocznych, to niech tworzy w ten sposób dokumenty HTML 4.01 lub XHTML 1.0/1.1 z odpowiednim DOCTYPE-em. Jeśli zaś chce troszkę powalczyć, to może zmienić DOCTYPE na ten pasujący do HTML-a 5. Problemów nie jest aż tak dużo, a rozwiązania są dostępne w Sieci.

    @nea:
    Ja bym się nie obraził, jak przeforsowaliby prawdziwy XHTML -- czyli ten z yellow screenem :). Składnia PHP, Perla, czy Pythona po stronie serwera musi być poprawna, bo jak nie, to kod się wysypuje. Składnia zapytań do bazy danych -- tak samo. Albo jest w 100% poprawna, albo jest "syntax error" i na razie. JavaScript -- to samo. Jeden błąd składni przerywa wykonywanie całego pliku. A HTML? Hulaj dusza, chata wolna! IMO skoro i tak w innych warstwach jest normalnie (bo tak to już jest w programowaniu -- błędy składni są czymś poważnym), to w HTML-u też by tak mogło być.

    CSS jest pod tym względem gdzieś pośrodku -- przeglądarka nie naprawia błędu, ale dotyczy on zwykle tylko jednej deklaracji, czy reguły (ew. dwóch). HTML 5 przynajmniej definiuje jasno reguły postępowania w wypadku napotkania błędów przez przeglądarkę. To już coś. Ale mi pasowałoby również 100% restrykcji. Skoro programiści od backendu nie mogą sobie pozwolić na błędy składni, to ja też nie muszę mieć taryfy ulgowej.

    To oczywiście nie oznacza, że kod musiałby być idealny. Chodzi tylko o błędy składniowe, czy leksykalne. Ich brak to jest podstawa. Nie gwarantuje to jeszcze, że strona będzie dobrze napisana (z dobrą strukturą), czy że będzie wyświetlana zgodnie z intencjami.

    pokaż komentarz
    Sh1eldeR
  • nea -3  

    Sh1eldeR: nie do końca masz racje. W PHP można sobie wyłączyć błędy bez problemu - na maszynie developera errory i notice'y powinny być włączone, na maszynie na której chodzi aplikacja już nie - powinny się zapisywać w logach. Błędy JavaScriptu lądują w konsoli JavaScriptu, nie wywalają się wielkimi oczoj$#nymi kolorami userowi w twarz. W XHTML'u nie jest to takie proste, bo jak sam napisałeś - XML po prostu nie toleruje błędów, nigdy.

    pokaż komentarz
    nea
  • Sh1eldeR +5  

    @nea:
    PHP jest w stanie przełknąć błędy składni? Nie wiedziałem. Co do JavaScriptu, to błędy składni powodują, że plik (skrypt, bo błąd teoretycznie może sobie siedzieć w eval) w ogóle nie jest wykonywany. Jeśli chodzi o pokazanie raportu użytkownikowi, to to zależy od przeglądarki. W starszych, ale wciąż powszechnie używanych IE błędy wywalały się właśnie w twarz -- okienkami dialogowymi.

    Abstrah%#ąc od języków skryptowych, twórcy aplikacji w językach kompilowanych jakoś sobie dają radę i nie popełniają błędów składni (a jak popełniają, to je poprawiają -- bo muszą). Nie jest to dla nich wielkim kłopotem. Nie bardzo rozumiem, czemu w językach interpretowanych ma być inaczej. C++ ma bogatą (i skomplikowaną) składnię, a jakoś programiści w nim piszą.

    pokaż komentarz
    Sh1eldeR
  • nea 0  

    Sęk w tym że "yellow screen of death" łapie nie tylko błędy składni, ale też całą masę błędów które można zignorować.

    A dlaczego języki interpretowane mają być traktowane inaczej? Może chociażby dla tego, że nigdy nie wiesz jaki interpreter będzie je obsługiwać. Prosty przykład: var a = [1,2,3,]; w IE będzie błędem składni, w Firefoxie już nie.

    pokaż komentarz
    nea
  • leshniak 0  

    @Sh1eldeR, to takie naciągane HTML5. Zresztą dobra, póki co mnie to nie interesuje, mam strony poprawnie napisane w XHTML 1.0 i tak przez najbliższy czas zostanie.

    Zostawcie już PHP i C++ w spokoju, zaraz przejdziecie do assemblera :P

    Co się tyczy raportowania błędów, podoba mi się rozwiązanie zastosowane w rozszerzeniu Web Developer dla Firefox'a ( http://tnij.org/dqcv ). Na pasku po prawej stronie widoczne są trzy ikony odpowiadające za HTML/XHTML, CSS i JavaScript. Po kliknięciu na nie można otworzyć konsolę i sprawdzić gdzie są błędy czy ostrzeżenia. Moim zdaniem tak to powinno być sygnalizowane, we wszystkich przypadkach, włącznie z XHTML, a nie wyrzucając yellow-screen-of-death.

    pokaż komentarz
    leshniak
  • nea +2  

    @leshniak: nie bardziej naciągane niż wysyłanie xhtml'a jako text/html.

    pokaż komentarz
    nea
  • leshniak +1  

    @nea: Osobiście stosuję content-negotiation, ze względu na IE, które nie trawi application/xhtml+xml.

    pokaż komentarz
    leshniak
  • nea +1  

    Chciałem napisać przydługiego posta odnośnie content negotiation, i w trakcie produkcji swej zawiłej argumentacji wszedłem na stronę samego W3C i sprawdziłem content-type oraz doctype: XHTML 1.0 Strict wysłany jako text/html. W tym momencie skasowałem całego swojego posta i napisałem to co właśnie napisałem, wydaje mi się że nic więcej nie trzeba dodawać :).

    pokaż komentarz
    nea
  • leshniak 0  

    Masz rację, że wysyłanie XHTML jako text/html jest naciągane, przyznało to samo W3C. To ustępstwo jest związane z kompatybilnością wstecz. Choć wysyłanie XHTML 1.0 jako text/html jest poprawne, to W3C rekomenduje wysyłanie content-type: application/xhtml+xml (w sumie rekomenduje text/html, ale wolałby xml), tak więc po to korzysta się z content-negotiation, by wysyłać poprawniej, kiedy tylko się da. Ustępstwo to znosi XHTML 1.1, dlatego prawie nikt z niego nie korzysta, chyba, że wysyła jako text/html, co już niestety jest błędem.

    Zawiły komentarz wyszedł :]

    pokaż komentarz
    leshniak
  • nea 0  

    Ja to wszystko leshniaku rozumiem, i właśnie dlatego przestaję używać xhtmla :). Są na świecie ludzie którzy lubią sobie komplikować życie, ja do nich niestety nie należę.

    pokaż komentarz
    nea
  • leshniak 0  

    Raczej stety :)
    Dopóki nie zrobiło się głośno o HTML5, komplikowanie sobie życia wydawało się konieczne. Lubię nowości, więc chyba też skorzystam.

    pokaż komentarz
    leshniak
pokaż 

Wykopali i zakopali (201 / 9)