Perfection or Vanity

Project: Terminated

Blog nie jest już dalej prowadzony ani aktualizowany. Mimo tego, wpisy i komentarze są dalej dostępne. Możesz przeczytać pożegnalny wpis albo przejść do archiwum.

Głównym argumentem osób nie stosujących standardów w projektowaniu jest twierdzenie, jakoby nie wszystkie układy tabelaryczne dało się przenieść do CSS. Dzisiaj chcę pokazać jeden z nich. Zadaniem kodera jest umieścić dwa tła rozciągające się do szerokości przęglądarki – jeden z lewej, drugi z prawej. Przykładowo taki nagłówek:

Pod nagłówkiem zwykle ciągnie się dalsza część strony, ograniczona w poziomie kontenerem.

Istnieje rozwiązanie opierające się na wyśrodkowaniu długiego na kilka tysięcy pikseli obrazka sklejonego z dwóch gradientów, ale jest ono bardzo nieeleganckie.

  1. Jesteśmy uzależnieni od rozdzielczości.
  2. Zwiększamy niepotrzebnie wagę pliku wydłużając szerokość.

Nie będziemy z niego korzystać – zwłaszcza, że problem nie tylko dotyczy mojego przykładu, ale też bogatych graficznie nagłowków. Jak widać w podlinkowanej stronie (screen), mimo użycia CSS do opisania wyglądu całej strony, Interia oparła szkielet strony na tabeli.

Jakie rozwiązanie jest więc najlepsze? Rozciągnąć dwa elementy na 50% okna przeglądarki, ułożyć obok siebie, umieścić gradienty w tle i przykryć w miejscu łączenia trzecim tłem.

Potrzebny HTML:

  1. <div id="masthead">
  2. <div class="primary"></div>
  3. <div class="secondary"></div>
  4. <div class="wrap">
  5. <h1><a href=""></a></h1>
  6. </div>
  7. </div>

Element #masthead rozciąga się na 100% szerokości okna. Divy .primary i .secondary mają ustawione wymiary i są wypozycjonowane względem niego.

  1. #masthead {
  2. position: relative;
  3. }
  4. #masthead .primary,
  5. #masthead .secondary {
  6. position: absolute;
  7. top: 0;
  8. height: 125px;
  9. width: 50%;
  10. background-repeat: repeat-x;
  11. }

Pozostaje dodać tło (wyciąć je należy z zaznaczonych na ciemno części layoutu) i pozycję.

  1. #masthead .primary {
  2. left: 0;
  3. background-image: url(left.png);
  4. }
  5. #masthead .secondary {
  6. left: 50%;
  7. background-image: url(right.png);
  8. }

I możemy oglądać już pierwszy efekt naszych starań. Z powodu braku ustalonej wysokości dla #masthead, tekst głównej zawartości strony wchodzi pod nagłówek – pozbędziemy się tego problemu już za moment.

Aby połączyć gradienty w naturalny sposób, należy teraz przykryć je w środku ostatnim obrazkiem:

W moim przykładzie potrzeba dodatkowej przestrzeni, aby zamknąć biały obszar z nagłowkiem, ale zasada jest jedna – musimy wyciąć obrazek dokładnie ze środka. Jeśli nie chcemy powtarzać gradientów (wypozycjonowanych pod), możemy je wyciąć zostawiając przezroczyste miejsce w pliku.

Korzystamy z elementu .wrap i pozycjonujemy go na środku całego nagłowka:

  1. #masthead .wrap {
  2. position: absolute;
  3. top: 0;
  4. left: 50%;
  5. height: 125px;
  6. width: 770px;
  7. margin-left: -385px;
  8. background: url(center.png) 50% 0 no-repeat;
  9. }

I dodajemy odstęp dla zawartości:

  1. #masthead {
  2. position: relative;
  3. margin: 40px 0 15px 0;
  4. padding-bottom: 125px;
  5. }

Rezultat jest już prawie wystarczający. Parę dodatkowych reguł dla tytułu oraz zawartości i skończone.

Sposób, który pokazałem jest uniwersalny i zniesie dużo modyfikacji, niezależnie od efektu jaki chcemy uzyskać (i niekoniecznie musi to być nagłówek). Aby to udowodnić, przepisałem szablon podlinkowanej na początku wpisu Interii na wersję beztabelkową.

Dlatego korzystając z możliwośći pragnę przypomnieć, że tabele nie służą do budowania layoutu. Nie spotkałem się na razie z układem, którego nie dałoby się zrobić semantycznie i przy pomocy CSS. Wymaga to czasami trochę pracy, ale profesjonalne podejście zawsze się zwróci.

Piszmy HTML myśląc o zawartości, a nie prezentacji.

Informacje i hiperłącza

Blog o projektowaniu zgodnych ze standardami stron internetowych.

Praktyczne przykłady, sztuczki CSS, sposoby obchodzenia błędów przeglądarek, lekki i nieinwazyjny JavaScript, użyteczny design, dostępność i skrypty użytkownika.

RSS

Informacje o wpisie

Napisał riddle 03 listopada 2007 o 22:42

Kategorie: CSS, HTML & Semantyka

Dodaj do:

Wpisy archiwalne

Archiwum miesięczne

Dzięki!

Dodaj bloga do Technorati Favorites Dodaj bloga do Del.icio.us Blog należy do sieci 10przykazań.com

  1. Czy puste divy są myślą o zawartości czy o prezentacji? ;–)

  2. Możesz skorzystać z ::before i ::after, jedyny problem to wsparcie przeglądarek. Poza tym pusty div nie niesie żadnej informacji o treści, a tabelka tak.

  3. Pomysłowe, nie powiem :) Ale czy w tym wypadku tabelkami nie byłoby prościej? :)

  4. Dzięki.

    Tabele nie mogą zostać użyte, tak samo jak nie wpakujesz w link diva, bo chcesz żeby cały dawał się kliknąć.

  5. Całkiem ciekawe, tylko rzadko się to wykorzystuje.

    BTW, nie wiem czemu, ale zalogowany do panelu joggera, na twoim blogu muszę wpisywać captche i inne pola.

  6. Pomysłowe, brawo!
    Mnie się też nie podobają te dwa divy. Na szybko udało mi się zrobić prawie tak samo wyglądający przykład – w Fx jest o kilka pikseli bliżej logo i środkowy obrazek – bez tych primary i secondary. Tylko pewnie w bardziej złożonym projekcie nie byłoby tak różowo, ale kto wie? Trzeci obrazek podrzuciłem w h1 i wtedy tylko ten wrap wychodzi nadmiarowo, bo masthead wydziela logicznie fragment – nagłówek.

  7. Istnieje sposób aby te dwa divy usunąć – przy pomocy generowanej treści. IE dostałby expression(), a Firefox XBL (post1, 2).

    Gdybym to dodał do wpisu, pewnie każdy by machnął ręką, że za trudne (vide komentarze do menu z max/min width)

  8. Dlatego ja osobiście nie lubię jak ktoś mi pierdzieli, że czegoś nie da się zrobić. Twoje dzieło jest dowodem, że w webdesignie można bez tabel żyć :D (nie licząc rzeczy do których powinny one służyć).

  9. No i writers block minął :D. Ładne i useful, ale czy puste divy nie są nie semantyczne? ::Before i ::after były by rozwiązaniem optymalnym, a dla złych przeglądarek zawsze można zrobić oddzielny kawałek CSSa ;).

  10. W Safari wersja tabelkowa się rozjeżdża a CSS nie:)

  11. A czemu, zamiast dodawać te nieszczęsne dwa divy, nie wykorzystać #masthead i h1? Na przykład jakoś tak: ZOMG

  12. h1 FTW :D + jeszcze można by „ZOMG, gradient!” zrobić jako normalny tekst :P.

  13. Ładnie, ale przykład miał być uniwersalny – zwykle do #masthead się jeszcze coś wrzuca; nawigację, linki pomocnicze, wybór języka.

    Tytuł można jako tekst, ale przecież to tylko design, nie?

  14. @riddle: No ba :)

    Ogólnie: dobrze, że Joggerowcy ładnie komentują, bo z tego co jest w komentarzach można wziąć drugie tyle co jest w poście :D.

  15. (Komentarz zmodyfikowany 04.11.2007 o 02:18)

    @riddle http://img231.imageshack.us/img231/8256/riddleqi7.jpg najnowszy FF, Ubuntu.

    Skasuj i followuj mnie na Twitterze, bym mógł ci directy puszczać :).

    EDIT:
    lol już wiem, suwak poziomy się przesuwał xD. Sry za spam.

  16. Zacny efekt panie Riddle :) .

  17. Kurcze, przez chwilę zastanawiałem się w jaki sposób robi się to na tabelkach… :)

  18. Hm, nie wiem czy zauważyłeś Riddle, ale kod interii jest teraz inny :-)

  19. Czy naprawdę rozwiązanie z wieloma divami jeden w drugim jest semantyczne? Wydaje mi się że nie i chociaż nie jest to tak bezczelne pogwałcenie semantyki jak tabelki, to i tak semantyczna taka strona jeszcze nie jest. No chyba że się mylę, to byłbym wdzięczny za wyproawdzenie z błędu.

  20. Coldpeer, nie zauważyłem, dalej mają tabele.

    ...: Masz rację, puste divy nie są semantyczne, ale jak już napisałem wyżej nie wnoszą nic do znaczenia dokumentu, podczas gdy tabela tak. Jak udowodnił także Taeril wyżej, można w szczególnych przypadkach wykorzystać inne elementy i się ich pozbyć. Przeczytaj także komentarze mówiące o generowanej treści proszę.

    Więc – masz trochę racji, ale wolę dodać 2 puste pojemniki niż korzystać z tabeli. Gdyby CSS był zaimplementowany jak należy, nie musiałbym. :)

  21. Riddle, hmm, mi Ctrl+F „table” w źródle nie wykazał żadnych wyników.

  22. Nie masz racji, sprawdź ponownie; EOT.

  23. oO, mea culpa ;-)

  24. @...: Jeśli Ci się nie podoba to rozwiązanie, a tabelki jeszcze gorsze, to używaj expression dla IE i XBLa dla FF. Co wybierasz? ;)

    Ja sam już wielokrotnie używałem podobnego rozwiązania jak tutaj Riddle przedstawiłeś i zawsze denerwuje mnie w nim jedna rzecz – przy za małej szerokości okna przeglądarki wszystko się rozpada.

    I jeszcze taka uwaga. IMO lepiej by było wyśrodkować wrappera za pomocą marginesów. Wtedy przy za małej szerokości okna przynajmniej by div.wrap nie wyjeżdżał poza okno przeglądarki. Tylko nie za bardzo chce mi się sprawdzać czy na pewno zadziała w tym przypadku, więc mogę się mylić ;)

  25. „Piszmy HTML myśląc o zawartości, a nie prezentacji.”. Amen! :-)

  26. No to mogę wywalić jeden z draftów sprzed 2 lat ze swojego Wordpressa, w imieniu koderów – dzięki za art Rid :)

  27. Czyżby niesemantyczny stawał się takim „uniwersalnym” zwrotem jak AJAX na cokolwiek w JS na stronie? No ale to jest… ten tego… no niesemantyczne :D

    Sam div nie ma znaczenia – jest semantycznie obojętny. A że z innych względów nie jest to rozwiązanie ładne, to inna kwestia tyle, że jak Riddle powiedział tam może być coś jeszcze i te divy nie będą puste. Ten przykład też jest szczególnym przypadkiem :)

  28. Bardzo fajne.

  29. Może nieco zboczę z tematu, ale ciekawi mnie, jak nazywa się ten krój pisma, który wykorzystałeś do `ZOMG, gradient’. ;)

  30. Fontin.

    Następnym razem nie zbaczaj z tematu, offtopik to choroba wirusowa. ;-)

  31. ładnie, tyle że przy mocnym zmniejszeniu szerokości okna, logo/header ucieka w lewo, poza ramkę okna…

  32. Michał Krupa 32 04 listopada 2007, 19:36

    Odrobinę poprawiona wersja (logo nie ucieka przy mniejszych szerokościach okna):

    #masthead {
    position: relative;
    margin: 40px 0 15px 0;
    height: 125px;
    }
    #masthead .primary,
    #masthead .secondary {
    position: absolute;
    top: 0;
    height: 125px;
    }
    #masthead .primary,
    #masthead .secondary {
    width: 50%;
    background-repeat: repeat-x;
    }
    #masthead .primary {
    left: 0;
    background-image: url(../left.png);
    }
    #masthead .secondary {
    left: 50%;
    background-image: url(../right.png);
    }
    #masthead .wrap {
    position: relative;
    width: 770px;
    height: 125px;
    margin: 0 auto;
    background: url(../center.png) 50% 0 no-repeat;
    }
    
  33. Dzięki, bardzo pomocny artykuł.
    Zastosowałeś sposób który mnie nie udawało się wymyślić. Dzięki.

  34. Dzięki Michał, zastanawiałem się czy by to działało i okazuje się że tak. :-)

  35. Świetny art, biorąc pod uwagę że często jest mi to potrzebny, z nieba mi spadł :)

  36. Wszystko super, dodaj jeszcze tylko alt-y do obrazkow :)

  37. (Komentarz zmodyfikowany 05.11.2007 o 13:53)

    „Zadaniem kodera jest umieścić dwa tła rozciągające się do szerokości przęglądarki – jeden z lewej, drugi z prawej. Przykładowo taki nagłówek:” – ani mru mru, nie ogarniam co chcesz tu osiągnąć? Jakie dwa tła? Tła czego? Skoro tła, to dlaczego „jeden z lewej, drugi z prawej”? Jeden tła? Drugi.. „teł”?

    Wydaje mi się, że wstęp przydałoby się przepisać bardziej po polsku.

  38. Świetnie opisane, rewelacja ;)

    Dlatego korzystając z możliwośći pragnę przypomnieć, że tabele nie służą do budowania layoutu. Nie spotkałem się na razie z układem, którego nie dałoby się zrobić semantycznie i przy pomocy CSS. Wymaga to czasami trochę pracy, ale profesjonalne podejście zawsze się zwróci.

    Święta racja ;) ja też się z takimi rzeczami nie spotkałem, bo – jak wiadomo, nie ma rzeczy niemożliwych ;)

  39. Dominik Porada 39 05 listopada 2007, 17:44
    <div class="wrap">
    <h1><a href="#">Tytuł</a></h1>
    </div>
    

    .wrap h1 { text-indent: -1000em; } – to trochę psuje dostępność, bo przy wyłączonych obrazkach i włączonym CSSie treść <h1/> jest niewidoczna. Można by zastosować h1::before z tłem-grafiką i wypozycjonować go ponad sam nagłówek – podobnie, jak zrobił to Dave Shea, tylko, że bez brzydkiego pustego znacznika.

    No tak, ale jakbyś się babrał tym, zamiast samymi gradientami, to bardziej przykułbyś uwagę do expressions, aniżeli do zamierzonego efektu końcowego. :)

  40. A ludzie twierdzili, że już dorosłeś.

    Przepraszam, że ośmieliłem się mieć uwagi.

  41. Ukrywam komentarze, które nie są związane z tematyką wpisu. Takie rzeczy pisze się na maila, nie zgadzasz się z moją polityką – nie komentuj, a przede wszystkim nie jęcz, że Ci komentarz zmoderowałem. EOT.

  42. Tak z ciekawości, jakie są realne praktyczne korzyści z wykorzystania divów zamiast tabelki (np. jak na tej Interii)?

  43. Teoretycznie dodanie dodanie divów tylko po to, żeby móc dodać kolejny obrazek tła jest łamaniem zasady odzielania treści od prezentacji. Teoretycznie! W praktyce we wszystkim trzeba zachować zdrowy rozsądek.

    Na przykład zwiększenie ilości divów jest najrozsądniejeszym sposobem na pozbycie się problemów z boxmodelem (zamiast robić padding, robi się margines dla wewnętrznego diva, tak?) Wszyscy tak robią, łącznie z masterami pokroju Douglasa Bowmana, który nota bene używa tabel przy formularzach (teoretycznie tego też można by się czepiać).

    Przykłady mozna mnożyć... Generalnie od nadmiarowych divów się nie da uciec i tyle. Zresztą niech mi ktoś poda jeden poważny argument, czemu dodatkowe divy są szkodliwe (chodzi mi o praktyczne kwestie).

  44. Hmm. Może…
    Każdy dodatkowy element może zmniejszyć (i na ogół zmniejsza) czytelność kodu?

    A div-y są chyba szczególnie nieczytelne, bo często służą tylko jako punkt zaczepienia dla regułek CSS, więc bez prześledzenia CSS może być trudno zrozumieć po jaką cholerę ten element w ogóle jest w kodzie (a gdy regułki idą prawdziwie kaskadowo i się łączy różne klasy razem, to w ogóle masakra).

    PS: jako programista mam zboczenie na punkcie czytelności, ale być może webmasterzy widząc np. kod:

    
    <div id="masthead">
    <div class="primary"></div>
    <div class="secondary"></div>
    <div class="wrap">
    

    nie czują się zagubieni. W każdym razie – podziwiam. Jakbym miał z tak nieczytelnymi danymi pracować, to bym miał dosyć po roku. Webmasterzy muszą być twardzi…

  45. Hoppke: Nie wiedziałem, że strony się robi po to, żeby programiści nie czuli się zagubieni czytając kod :( Dotąd myślałem, że strony się robi dla ludzi i wyszukiwarek.

  46. A programista to nie człowiek? :)

    Prosty, lokalny przykład – jak ktoś robi i udostępnia szablon joggera, to czy jest obojętne na ile czytelny będzie ten kod html/css/js?

  47. @Hoppke, przeczytaj sobie ostatnie zdanie notki Riddla.

  48. „Piszmy HTML myśląc o zawartości, a nie prezentacji.”? O to zdanie chodzi?

  49. Dominik Porada 49 06 listopada 2007, 17:50

    Jeżeli te divy nie gryzą się z semantyką dokumentu, to w czym problem, jeżeli zostały użyte?

  50. Nie gryzą się z semantyką, bo w ogóle nie mają znaczenia. Należą w 100% do warstwy prezentacji.

    Nie pytaj mnie czy to problem, bo to nie moja broszka. Ja się tylko pytam jaką mają praktyczną przewagę nad tabelką (bo mnie to naprawdę interesuje), no i czy pakowanie w HTML kodu bez żadnej semantyki (jak zacytowany przeze mnie szereg pustych div-ów) nie zaciemnia konstrukcji dokumentu.

    Swoją drogą ostatnie zdanie wpisu jest błędne. Widząc ile wysiłku Riddle wkłada w prezentację trudno uwierzyć, że nie myśli o niej. Ba, cały ten wpis jest o prezentacji. Większość wpisów tu jest o prezentacji, praktycznie nigdy nie ma niczego o TREŚCI.

    IMO prawdziwe byłoby „myśl o oddzieleniu treści od prezentacji”.

    Ale tutaj wracam do oryginalnego pytania – jaka jest konkretna korzyść, choćby na przykładzie tej Interii, z wywalenia tabelki i wrzucenia paru pustych div-ów z css-ami? Tak po webmastersku – co po takiej zmianie się zrobi łatwiejsze, co trudniejsze, a co będzie wymagało nadal tyle samo pracy?

    Na ile jest to dążenie do perfekcji, a na ile próżność bez realnej korzyści?
    (nie każdy jest webmasterem i wie takie rzeczy!)

  51. Korzyść: prawidłowe rozszyfrowanie kodu przez wyszukiarki i programy dla osób niepełnosprawnych.

  52. Umieszczając tam tabelę odcinasz sobie ten kawałek ekranu. Umieszczając diva, możesz innym na niego wjechać albo zrobić inne czary mary z CSS-em, zależnie od projektu.

    Dodajesz cztery zagnieżdżenia więcej do struktury + ewentualne przekształcenia DOM czy animacje DHTML są prostsze i efektywniejsze (efektowniejsze też) na divach.

    Dostępność też leży na tabelach, czytniki ekranu mają z nimi problemy, ale nie jestem w stanie Ci powiedzieć jak jest w tym przypadku, bo nie mam do czytnika dostępu.

    No i wreszcie – wkładasz przecier z jabłek do plastikowego kubka celem przechowywania ich przez parę lat. Tabele powinny zawierać dane tabelaryczne, a nie elementy layoutu strony.

  53. OK, to ma sens (chociaż w przypadki Interii chyba i tak są większe błędy do usunięcia? czy ich serwis jest w ogóle w jakikolwiek sposób przystosowany do czytników dla niewidomych?)

  54. Czy na tabelę nie da się wjechać innymi elementami, albo aplikować CSS-ów? Wydawało mi się do tej pory, że div i table to z punktu widzenia przeglądarki i tak tylko takie bloczki, może z ciut innymi defaultami…

  55. Ten wpis nie jest wpisem o poprawianiu Interii. Riddle przywołując przykład Interii pokazał jedynie, że bardziej skomplikowane elementy niż pojedynczy gradient RÓWNIEŻ da się pozbawić tabelkowej struktury. Nic więcej.

    Co do nachodzenia tabelek na inne elementy – to chyba przesadzony argument, aczkolwiek nie da się ukryć, że z DIVami robi się to o wiele prościej. Ma to i swoje wady i zalety. A że też są bloczkami – ano są, ale bloczkami z charakterystycznymi dla tabel display – jeśli ich pozbawisz, by uzyskać efekty, które da się uzyskać na divach, to odpada Ci układ tabelaryczny.

  56. Cześć,

    efekt rzeczywiście bardzo ciekawy i stosunkowo lekki. Zapewne przy mniej skomplikowanym gradiencie dało by się tu jeszcze trochę całość uprościć.

    Inna sprawa dotycząca prezentacji i tabelek. Riddle co zrobić jak mam baaaardzo długą tabelę, załóżmy 30 kolumn (mały raport finansowy), i menu po lewej stronie? Tabela musi być na górze, a przy floatowaniu jej pod IE spada poniżej menu. Czy jedynym rozwiązaniem jest pozycjonowanie absolutne? problem opisałem tu:
    http://forum.webhelp.pl/viewtopic.php?t=179920

    Zadanie jest, moim zadaniem, ciekawe ponieważ nie można użyć div‘ów, bo spowoduje to rozsypanie się tabeli (zawijanie wierszy).

  57. Niekoniecznie pisze się razem ;]

  58. Jakiś czas temu na swoim blogu opisałem podobną sztuczkę ;)
    http://blog.shpyo.net/?newsID=32
    Efekt dość podobny, jednak przypadek trochę inny.

  59. @topic
    Zgodzę się z przedmówcami: przydatny i lekki efekt :)

    @Hoppke
    Gdy masz stronę, której układ jest zbudowany na tabelach jest ona niżej pozycjonowana w wyszukiwarkach. Takie moje .5 grosza, jeśli chodzi o zalety używania divków ;)

    Peace out,
    mORWo.

  60. Ale gradient to chyba jeszcze nie modny ostatnio „content”? Tzn. niech sobie googiel przykłada niższą wagę do tabelki – jeśli zawiera tylko gradient czy inny „background image”, to chyba żadna strata?

  61. Jak to żadna? Przecież ta tabelka jest częścią twojej strony i obniża jej wartość. ‘Googiel’ indeksuje strony w całości przecie :)

    Dorzucę swoje ‘za’ dla divów, w większości już wypowiedziane:
    1. bardziej czytelne i to nie tylko dla czytnikow czy przegladarek, ale mimo wszystko takze dla webmastera/programisty,
    2. mniej kodu co sie laczy z punktem 1. przyklad powyzej mamy prosty, ale to tylko przyklad. nie trudno sobie wyobrazic sytuacje gdy roznica w ilosci kodu zaczelaby byc znaczaca,
    3. divy to nic nie mowiace pudelka, a tabela to tabela i tak ja przegladarki traktuja co jest najbardziej oczywistym argumentem za tym ze lepiej sie w takiej sytuacji tabel wyzbyc.

    A co do samych div‘ów i wątpliwości co do ich pustości, to:
    1. przyklad jest prosty wiec zakladamy ze w innych przypadkach cos sie w tych divach bedzie miescic jeszcze,
    2. jak juz maja byc puste to mozna je zastapic span’ami ktore juz nic o sobie nie mowia i sluza jedynie do tego by rozciagac na nich css.

    pozdro.

  62. Czy Google obniża punktację po prostu za użycie tabelki? Czy to znaczy, że np. strona z cennikiem towarów jakiejś firmy automatycznie leci w dół?

    BTW, rozmowa znowu idzie w kierunku HTML == Internet, pagerank etc. A świat się nie kończy na blogach/sklepach internetowych/serwisach web2.0.
    Tak jak programowanie nie kończy się na php_mod i RoR, tak pozycjonowanie nie jest każdemu niezbędne.

    „bardziej czytelne i to nie tylko dla czytnikow czy przegladarek, ale mimo wszystko takze dla webmastera/programisty,”

    De gustibus, bo ja np. wolę tabelkę od listy pustych div-ów. Wiersz tabelki przynajmniej sugeruje, że ułoży elementy poziomo. DIV-y są nieczytelne bez przeanalizowania CSS-a, a ten może być naprawdę kaskadowo zbudowany.

    „mniej kodu co sie laczy z punktem 1.”
    Mi się wydawało, że z całym CSS-em i dodatkami potrzebnymi by działało ładnie w różnych przeglądarkach rozwiązanie „koszerne” jest bardziej rozwlekłe.

    „divy to nic nie mowiace pudelka, a tabela to tabela i tak ja przegladarki traktuja co jest najbardziej oczywistym argumentem za tym ze lepiej sie w takiej sytuacji tabel wyzbyc.”

    IMO wpychanie elementów pozbawionych semantyki nie jest wcale słuszniejsze od naciągania znaczenia tabeli. Pewnie dlatego, że jestem językoznawcą i „semantykę” rozumiem trochę inaczej niż webmasterzy.

    Ale rozumiem, że w tym środowisku tak jest słuszniej – po prostu webmasterzy dążą do semantycznej sieci, chociaż technologia której używają się do tego za bardzo nie nadaje (vide dolepiane wynalazki typu RDF).

    Rozwiązania proponowane przez Riddle są słuszne, tyle że jak się patrzy na to z boku ciężko nie zauważyć, że to nadal tylko proteza. Takimi narzędziami niczego prawdziwie semantycznego nie zbudujesz, tak samo jak nie oddzielisz tak naprawdę treści od prezentacji.

    Jak słyszę „sieć semantyczna” to mi się scyzoryk otwiera, bo to ma tyle wspólnego z semantyką co MS IE z referencyjną platformą CSS :)

  63. Hoppke, obserwując Twoje komentarze dochodzę do wniosku, że pracujesz w bardzo specyficznym środowisku i każdy komentarz / wpis, który jasno określa co mamy robić odbierasz bardzo personalnie. Boję się także, że odbierzesz personalnie ten komentarz – więc proszę Cię od razu, take it easy.

    Nie wiem co robisz, ale z tego co przeczytałem wynika IMHO, że jest to typowy biznes. Postępowanie wg. I Zasady zatytułowanej „firma ma przynosić pieniądze, w innych przypadkach patrz Zasada I”.

    I nie mówię, że nie zarabiasz. Nie mówię że firma nie prowadzi dobrego biznesu. Good for you. Tylko, że ty wychodzisz krok dalej – twierdzisz, że aktualny stan determinuje stan za pół roku, parę lat, kilkanaście. Mówisz, że słuchasz się ludzi bardziej wykwalifikowanych od Ciebie. Ja Ci mówię bullshit sir, bo sieć jest pięknym przykładem gdzie ludzie sterują wirtualnymi imperiami nie mając żadnego pojęcia o tym co powinni robić i na jakich technologiach się opierać. Aby nie przynosić strat za x lat z powodu obecnych błędów.

    Standardy są po to, abyś nie musiał gryźć palców. W tym momencie gryzienie palców nie jest Ci pisane, bo masz firmę która zamaszystym ruchem pióra odcina wsparcie dla Opery, dostępność czytników ekranu i fakt braku JavaScriptu. Na przykład.

    Lecz ten stan nie będzie trwał wiecznie. Pewnego dnia nie będzie można już wypuścić strony, która nie nadaje się dla niewidomych. Prawo – w USA i Holandii już tak po części mają. Nie będzie można zrobić witryny na tabelkach, bo ogólnie dostępne urządzenia przenośne będą dławiły się na nadmiarowych tagach i renderingu całego układu w monolitycznych komórkach.

    I uwierz mi, nie mówię tego z zawiścią, ale liczę że firmy takie jak Twoja zmienią kurs, albo upadną. Z tego co widać na świecie, z tego co słychać od mądrych ludzi i wizjonerów, nie będzie miejsca w sieci jeśli nie przestrzegasz standardów. Tak samo jak nie możesz jeździć samochodem bez znania przepisów, tak samo nie możesz wypuścić beznadziejnie napisanej strony.

    Ten blog, opinie tutaj zamieszczane i osóby tutaj się wypowiadające podchodzą do standardów poważnie. Nie chcemy obudzić się za 5 lat z myślą o przekwalifikowaniu, bo przestaliśmy być potrzebni w branży. Chcemy dalej zarabiać pieniądze, ale mając w myślach większe spektrum niż mijający za 2 tygodnie deadline.

    Dlatego mając na względzie to podejście, komentuj tak, abyśmy nie musieli wytykać Ci (i Tobie podobnym, bo nie jest to akcja pt. Atakujemy Hoppke) nieznajomości tematyki w której siedzimy.

    Po prostu. :)

  64. Riddle, nie traktuję blogów jak „prawdziwego życia” i jeśli wyglądam tu na osobiście dotkniętego czymkolwiek, to jest to tylko częścią zabawy (trollowania?). No, przynajmniej z mojego punktu widzenia to tylko zabawa.
    Webówka tak naprawdę mnie nawet specjalnie nie interesuje – jestem zwykłym programistą, a nie grafiko-artysto-cssowcem.

    Nie pracuję w specyficznym miejscu – myślę, że to firma całkowicie przeciętna, jak 80% firm wśród IT. Ma może wyjątkową pozycję na rynku, ale jako firma jest bardzo zwyczajna.

    „Mówisz, że słuchasz się ludzi bardziej wykwalifikowanych od Ciebie.”

    Tak. W IT korzystanie z doświadczeń innych jest bardzo mile widziane (znam np. architektów aplikacji, którzy podejmowali czasem dziwne dla mnie decyzje – sens dostrzegałem dopiero po pół roku). Nie ma sensu powtarzać samemu wszystkich możliwych błędów.

    „Ja Ci mówię bullshit sir, bo sieć jest pięknym przykładem gdzie ludzie sterują wirtualnymi imperiami nie mając żadnego pojęcia o tym co powinni robić i na jakich technologiach się opierać.”

    Może gdyby ci ludzie wiedzieli co powinni robić i jakich technologii użyć to ich imperia byłyby dziś większe albo prostsze w zarządzaniu? nasza-klasa.pl jest na przykład sukcesem (IMO oczywiście), ale gdyby wziął się za nią swego czasu ktoś z większymi kompetencjami to może nie mieliby teraz tylu problemów? Allegro jest sukcesem, ale gdyby mieli kogoś z lepszą wizją przyszłości, to nie musieliby teraz bulić tyle za przechodzenie z mysql na oracle. To że sam coś umiesz zrobić nie znaczy, że ktoś inny nie umiałby tego zrobić lepiej. To chyba nie bullshit?

    „Z tego co widać na świecie, z tego co słychać od mądrych ludzi i wizjonerów, nie będzie miejsca w sieci jeśli nie przestrzegasz standardów.”

    O, to jednak słuchasz jakichś ludzi „bardziej wykwalifikowanych od Ciebie”. I dobrze, słuchaj ich. Ode mnie nie usłyszysz tu „bullshit, sir”.

    BTW, ja też poważnie podchodzę do standardów. W pracy korzystam z dziesiątek rozwiązań opartych o standardy, praktyki i wzorce. Staram się tylko pamiętać, że nie ma czegoś takiego jak „perfect solution”. Tak naprawdę wszystko sprowadza się do „good enough”. Nawet tacy potentaci jak Microsoft czy Google stosują się do tej zasady. Dlatego np. Google Calendar nie działa mi za bardzo w Operze. To, że jestem sceptykiem jeśli idzie o „idealne” i „uniwersalne” rozwiązania nie znaczy, że nie jestem za standardami.

    „liczę że firmy takie jak Twoja zmienią kurs, albo upadną”

    Nie upadną. Takie firmy były w stanie przeżyć bańkę dotcomów, właśnie przez swój realizm i pragmatyzm. Reagują i dostosowują się. Powodzenie w biznesie od dawna uzależnione było od zdolności adaptacyjnych. Jeśli jakieś standardy stają się niezbędne, to się je zaczyna wspierać. Jeśli nie są koniecznie wymagane a łatwiej (z uwzględnieniem jakiejś perspektywy czasowej, supportu itp.) jest zrobić coś niestandardowo, to się tak robi. W czym problem?

    Nie zawsze trzeba dokręcać śrubę „w imię perfekcji”. W wielu projektach front-end nie jest aż tak krytyczny. Widziałem projekt, w którym analityk mówił „1,5 sekundy na przygotowanie strony? Katastrofa, musimy to przyspieszyć!”. Ale widziałem też taki, w którym mówił „Nieważne, że będzie to (walidacja danych) długo trwało – klient z radością zaakceptuje nawet pół minuty, bo ich obecny system potrzebuje 20 minut na przetworzenie takiego zlecenia”.
    I tylko tyle. Rozumiem, że dla ludzi odpowiedzialnych za front-end html, css i js to oczko w głowie, ale w praktyce w naprawdę niewielu projektach się wymaga od front-endowców takiego wypruwania sobie flaków w imię standardów. Oczywiście miło spotkać UI-owca który jest perfekcjonistą, ale każdy pracownik IT powinien umieć wrzucić na luz i zrobić jakiegoś obrzydliwego szybkiego hacka zamiast tracić czas na ideał – gdy projekt tego wymaga.

    „Nie chcemy obudzić się za 5 lat z myślą o przekwalifikowaniu, bo przestaliśmy być potrzebni w branży. „

    W branży programistycznej technologie zmieniają się chyba o wiele częściej, i jest też o wiele więcej paradygmatów niż w webówce, a programiści jakoś sobie z tym radzą (łącznie z przesiadaniem się między językami), więc nie sądzę byście musieli się czegokolwiek obawiać. No, chyba że jako „branżę” traktujesz jakiś wąski wycinek, np. serwisy web2.0 czy agencje interaktywne czy cuś. BTW, nie planujesz żadnych przekwalifikowań, chcesz za 5 lat nadal robić to samo co w tej chwili?

    „Dlatego mając na względzie to podejście, komentuj tak, abyśmy nie musieli wytykać Ci (i Tobie podobnym, bo nie jest to akcja pt. Atakujemy Hoppke) nieznajomości tematyki w której siedzimy.”

    Dobrze :)

    To ja też dam małą poradę – gdy piszesz o czymś, to podchodź do sprawy bardziej deskryptywnie, a mniej preskryptywnie. Niektórzy ludzie (jak np. ja) robią się sceptyczni gdy próbuje się im sprzedać swoją „jedyną słuszną” wizję profesjonalizmu. I nie odwołuj się tak często do mądrych ludzi, wizjonerów czy innych blogerów ze Stanów. Spróbuj wyraźniej przedstawić swoje zdanie, na zasadzie „uważam, że … bo gdy robiłem to i to …”, a nie „bo tak przeczytałem na blogu pana X, a pan Y też się z tym zgadza”. Ludzie mogą się mylić, wizjonerzy w IT już nie raz się przejechali na swoich wizjach, a „internetowe imperia” okazywały się nie mieć realnej wartości. Riddle który nie odwołuje się tak często do zagranicznych „wyroczni” i „wizjonerów” byłby w moich oczach wiarygodniejszy, bo byłoby bardziej widać, że myśli samodzielnie :)

    I proszę, nie deprecjonuj polskiego IT, naprawdę mamy masę fachowców i dobrych firm (kiedyś skomentowałeś mnie mówiąc coś o wydźwięku „nie zrozumiesz o czym mówię, bo jestem zbyt postępowy a Ty pracujesz w zacofanej polskiej firmie”). Nasi ludzie z powodzeniem pracują w najróżniejszych zagranicznych firmach. To, że mają czasem inne zdanie i punkt widzenia niż Ty nie znaczy, że są głupsi czy zacofani technologicznie :)

  65. Dzięki za komentarz, przeczytam sobie jeszcze go z dwa razy i postaram się coś wynieść, bo wydaje się być przemyślany. Stąd na razie powiem, że możesz mieć rację co do tego perfekcjonizmu – staram się jednak robić tip-top, bo moje dzieła przechodzą później przez x rąk, które obniżają jego wartość… a boli mnie jak coś ładnego i dobrze przemyślanego ląduje na półce „średnie”. Nienawidzę być średni. ;)

  66. Riddle,

    Z całym szacunkiem, to szukałem wytrwale i nie udało mi się jeszcze znaleźć designe-u opartego na div-ach, który wyglądał by tak: – header – content 3 kolumny (np lewa 20% środkowa 60% prawa 20%) – footer
    Przy czym dla mnie taki design: – powinien mieć kolumny w środkowej części ładnie wyrównane i o równych przy różnych rozdzielczościach – layout nie używa JS do pozycjonowania – layout nie „rozjeżdża się” przy różnych rozdzielczościach (np. poprzez dziwne przesunięcia elementów, wydłużanie jednych a skracanie drugich itp) – layout wyświetla się podobnie i poprawnie w głównych przeglądarkach.

    W necie znalazłem określenie na ten layout holy grail faktycznie jest on najbardziej popularnym układem. Niestety wszelkie jego implementacje w CSS mają denerwującą cechę: brakuje im czegoś z warunków, które wymieniłem.
    Patrz chociaż tutaj:
    http://www.glish.com/css/7.asp
    ten ma różne (pionowe) długości sekcji. Poza tym nie ma footera.
    Jakieś pomysły?:)

  67. Kiepsko szukałeś, bo to czego potrzebujesz trzeba rozszerzyć o Faux Columns. Sam o tym pisałem parę razy, poszukaj.

  68. To że można lepiej sam już stwierdziłeś, ale po kolei.
    bq. Piszmy HTML myśląc o zawartości, a nie prezentacji.
    Tu się zgodze, ale kiedy patrze na html to odnosze wrażenie, że co innego miałes na myśli, a co innego napisałeś. Podany przykład jest bardzo akademicki i wiele będzie zależeć od reszty projektu graficznego, ale ładowanie conajmniej dwóch nadmiarowych divów, to moim zdaniem ewidentne kodowanie pod kątem prezentacji. Jeśli implementacja ma brać pod uwagę tylko i wyłącznie treść, to z całego kodu pozostaje tylko <h1/> i o tym, moim zdaniem, mówi powyższa sentencja. Zaś cała reszta będzie uwzględniać potrzeby projektu graficznego, a sposób implementacji te czy inne przesłanki, ale od tego momentu treść nie jest już czynnikiem w 100% warunkującym kod. I (generalnie! rzecz biorąc) nikt mnie nie przekona, że przesadnie nadmiarowa ilość zbędnych elementów, jest w zgodzie z semantyką, nawet ja sam kiedy popełniam taki kod (;

    Od dawna cenie sobie Twoje posty i wiedzę, którą się dzielisz. Niejednokrotnie podsunąłeś mi pomysł na lepsze rozwiązanie czy wyjście z problemu. Tym bardziej (żebyś miał świadomość) nie pije do Ciebie, a do rozwiązania, które przedstawiłeś, a te niestety uważam za małą fuszerkę. Semantyka semnatyką, jestem jednak przekonany, że minimalizm to drugi fundament dobrego kodu html. Bo cóż mi po nagłówkach, cytatach i paragrafach, skoro to wszystko będzie źle zoptymalizowane, czyt. zbędne.
    Być może Tearil mnie uprzedził, nie wiem – dostaje 403.
    bg-gradient.png – jasna część
    bg-gradient-1.png – ciemna część
    bg-gradient-2.png – nagłówek wraz z przejściem (waga ~4kb)

    <div id="a">
    <h1>Nagłówek<span></span></h1>
    </div>
    
    body { background: url(bg-gradient-1.png) repeat-x 0 0; } /* IE 6 */
    
    div#a { 
    position: relative; /* IE 7 */
    min-width: 770px; 
    overflow: hidden; 
    background: url(bg-gradient.png) repeat-x 0 0; 
    }
    h1 { 
    position: relative; 
    left: 50%; 
    height: 115px; 
    margin: 0 0 0 -375px; 
    padding: 0; 
    background: url(bg-gradient-1.png) repeat-x 0 0; 
    }
    h1 span { 
    position: absolute; 
    left: 0; top 0; 
    width: 400px; 
    height: 100%; 
    background: url(bg-gradient-2.png) no-repeat 0 0 
    }
    

    Tak, ten przykład jest odrobine mniej uniwersalny, ale idea jest identyczna. Praktyka ma niestety ma to do siebie, że wszystko co uniwersalne rzadko kiedy bywa również ładne, fakt. Uważam jednak, że zaadoptowanie tego rozwiązania jest nie wiele bardziej skomplikowane od Twojego, ale ma jeden plus, w html/css zawsze łatwiej jest dodać niż ująć (;

  69. I super, dzięki. Właśnie za to lubię blogi, można się czegoś nauczyć w dwie strony.

    Mój przykład może i był fuszerką, ale jak sam zauważyłeś – uniwersalną i akademicką. Dodatkowo często tła na body nie możemy użyć, bo już jest do czegoś wykorzystane (ech… kiedy ten CSS3 będzie powszechny).

  70. akurat kwestia tła dla body, jest próbą obronnego wyjścia z sytuacji (IE6), kiedy okno przeglądarki jest węższe od zawartości – na ogół sytuacje marginalne, dlatego posłużyłem się body, ale prawdopodobnie w innych okolicznościach zostałoby to zignorowane lub przypisane do rodzica, choćby i sztucznego (:

    Tak się teraz zastanawiam, jakby to uprościć z wykorzystaniem multiple backgrounds (;

  71. Zastanawiam się nad innym rozwiązanie, bo obecnie muszę zrobić coś podobnego.
    Jeden z gradientów krańcowych jako tło dla body,
    potem warstwa z drugim gradientem krańcowym zajmująca 50% body i mająca wysokość paska z gradientem(body ma text-align: right – specjalnie na użytek tej warstwy)
    pod nią warstwa o powiedzmy width: 950px z fragmentem gradientu łączącego te dwa krańcowe – warstwa ta miałaby position: absolute, podniesionom o wysokość paska gradientu i byłaby wyśrodkowana, będę do tego dopiero siadał, ale myslę, że wypali ;)
    plusem wydaje mi się to, że nie rozjedzie się przy b. dużym zmniejszeniu okna, co przy wielu stronach opartych o css mnie osobiście drażni

Dodaj komentarz

Do formatowania komentarzy używaj Textile (HTML nie działa). Szczególnie jeśli wklejasz większe fragmenty kodu. W razie niepewności użyj podglądu komentarza.

Wypowiedzi obraźliwe, infantylne oraz nie na temat będą moderowane – pisząc postaraj się zwiększyć wartość dyskusji.

Komentarze nie służą do wysyłania wiadomości albo informowania o błędach, itd. Chcesz coś mi napisać – skontaktuj się.