Gå til innhold

Enveisargumentasjonen får en motstander


Anbefalte innlegg

To ting:

 

1. Jeg sa at tabeller er LETTERE å skjønne enn CSS. Det betyr at jeg sa at tabeller er LETTERE. (altså ikke noe mer, ok?)

2. Hva har ditt eksempel med tabeller å gjøre?

OK: nevn EN ting som er lettare med tabeller?

 

1. En tabelllayout er grunnleggande bygd opp slik:

En hoved-tabell, med masse undertabeller, der mange av tabellrutene er der hovedsaklig for å lage mellomrom. Du bruker altså bokser i ett sett for å lage mellomrom. I en strukturbasert layout berre forteller du at "du er der og du er der", istede for å sei at "du er der, slik at han havner der" som det blir i en tabell-layout.

 

Posisjonering med tabeller er mye lettere enn posisjonering med CSS, men er også mye mer begrenset og låst.

 

Nei, posisjonering med tabeller er rett og slett idiotisk og dumt. Enkel men kreativ sammenligning:

 

Tabellmåten

Du ankommer en parkeringsplass med din bil, og skal parkere. Du kan _kun_ parkere på plass nummer 10, fordi alle plassane fra og med 1 til og med 9 har blitt tatt. Du _kan_ ikkje parkere på plass 11, fordi da ville plass 10 vere ledig.

 

Den ordentlige måten

Du ankommer parkeringsplassen, og parkerer akkurat der du vil, sett at det er ledig på plassen. Dersom du har en stor bil så kan du parkere oppå dei andre, om du vil. (absolutt posisjonering)

 

======================

 

Det er blitt bevist fleire ganger før, på forskjellige plasser at en tabellbasert layout har overhodet ingen fordeler foran strukturbaserte sider. Til og med skrive om det sjøl.

 

Man kan vel ikke si at CSS er vanskelig? Tar vel kun et par timer å sette seg inn i det også gjenstår det jo kun å lære seg kodene...

 

Ja, og når man kan syntaksen i HTML så er man utlært. Ganske enkle språk, detta.

Lenke til kommentar
Videoannonse
Annonse

anderlin: Slik jeg ser det, er tabeller likestilt funksjonsmessig med absolutt posisjonering i CSS, bortsett fra at det er mye, mye mer komplisert. Greit nok, det er kanskje ikke værre å kode, men når noen kommer etter deg for å fikse opp i layouten eller noe sånt, går alt i dass.

 

Et lite eksempel fra en helt annen gren av webutvikling er at man alltid skal skrive ren kode. Hvorfor er det mulig med kommentarer i de fleste programmeringsspråk? Hvorfor bør man bruke de til å kommentere der det er nødvendig? Hvorfor bruke linjeskift for å gjøre ting mer lesbart i koden? Jo, nettopp fordi andre kan komme etter å ha behov for å endre det uten å kode alt på nytt.

 

Tenk deg om du lager en webside for noen folk, kodet med tabeller. Siden er litt spesiell i utformingen, så du har ganske rotete kode. Du gidder ikke å fikse i koden, og når du tre måneder senere må redigere en side for dem (du har jo ikke lagt inn et CMS for dem) har du ikke snøring på hva du tenkte den dagen du kodet dette. Du har ingen peiling på hvorfor du bruker en spacer-gif akkurat der, og hvorfor ditt og datt er slik og ikke slik.

 

...men kan være enig i at det er bra ikke alle tenker som forfatteren, som enten har fått seg et solid kakk i hodet, eller bare er potte sur på at han ikke lenger kan slippe unna med å ta 20 000 for en side laget i frontpage på 45 minutter.

 

Skjønner også ikke hvorfor han mener at "full" CSS betyr å bytte ut hver eneste <table> med en <div>. Han har i så fall fullstendig misforstått, og gått på en veldig typisk nybegynnerfelle.

 

No. There is no real benefit when you start to replace

each-and-every-single <table> tag with <DIV> tags and attempt to use full CSS to display your webpages properly across popular browsers.

 

Hvorfor sier han at CSS er noenlunde greit til fonter, og driter i å nevne hvordan CSS kan brukes til å gi en side som er oppmerket på en helt enkel måte et fullstendig flott design _uten_ kodesuppe.

 

And FULL CSS has tons and tons of hacks and so-called work around just to get it to work right even in the latest browsers IE 6 and Netscape 7. And that's not even mentioning the Mac browser versions.

 

Hmm. Jeg som nettopp kodet en side som funket 110% i både IE, Opera og Firefox uten å svette en tåre. Ingen CSS-hacks ble brukt (jeg pleier å prøve å løse ting uten dem), og macIE har faktisk bedre CSS-støtte enn winIE, så den bør vise siden skikkelig.

 

CSS still (after all these years) can't even get the most basic font sizes to display consistently even in the latest browsers like IE 6 and Netscape 7. Do you honestly believe it can start doing tables?

 

Så det er forskjell på <font size="16px">Font</font> og <p style="font-size:16px;">Font</font> ? Ikke etter min erfaring.

 

What happens if Microsoft introduces a few new features to IE 7 that Mozilla doesn't have OR won't support OR that W3C won't call a standard?

 

Ja, da er det kun Frontpage-brukere som får nytte av den. Det har da vært kjent at SAMTLIGE browsere har sine egne features som ikke W3C har trykket til sitt bryst enda. -moz-border-radius er en greie som Firefox og Mozilla har hatt en god stund, og enda har ikke folk slått håret ut med det.

 

Is AOL's browser compatible with other browsers? NO, NO, NO.

 

Etter det jeg har hørt, er AOL's nye browser basert på firefox, og skal være temmelig W3C-kompatibel.

 

Furthermore, CSS zealots have been predicting the future of CSS since the year 2000. And guess what, it's now 2004 and we are not a single step closer to CSS browser compliance than we were in 2000 with even the latest browsers Mozilla 1.x and IE 6.

 

Det er bare latterlig. Hva med Opera? Hva med Firefox? Og HVORFOR I HULESTE trekker han frem IE, som ikke har fått en overhaling siden -98? Det er forresten bare bull å hevde at CSS-støtten i Mozilla 1.x ikke har blitt hevet siden 2000.

 

So that's why you should use CSS for only really repetitive items that are really straightforward and easy to understand. Accordingly, you can and should use the good old "Search and Replace" feature for global site wide changes.

 

Så forfatteren mener at hvis jeg vil endre fontstørrelse på samtlige <h1>-tags (som sikkert heller er skrevet som <font>-tags), bør jeg bruke Search&Replace i DW heller enn å endre én verdi i ett stilark. Lurt. Regner med det er temmelig mye raskere å manuelt gå gjennom 195 sider med S&R enn å åpne én fil og gjøre én endring. Riiiight.

 

Neste, takk:

 

# Using FULL CSS makes surfing FASTER 

 

MYTH. FALSE. UNPROVEN. (and if not a myth, how much faster?) Has this actually been proven on a variety of websites? Has there actually been a true performance test done? As far as I can tell, I cannot see, or notice, a bit of difference between a full CSS website and nested tables website. What about the size of that initial .css file? That's going to be bigger; and then if you have one main .css file, who says they are going to visit enough pages on your website anyway to really enjoy the benefits of having that extra large .css file download initially. Don't you want that first page to be fast?

 

Jasså? Så det er faktisk bare tull at en side med 125kb tabeller er større enn en 25kb side med pur HTML pluss et stilark på 5kb? Enkel matte er visstnok ikke forfatterens sterke side. En annen ting som kan være verdt å huske på, er at nettleserne cacher stilarket, så på alle undersider som lastes vil man ikke laste inn alle ekstra <font>-tags og <table>-tags. Hvis man er så sløv at man laster inn absolutt all CSS for f.eks. en kjempestor businesside på én gang, kan det i noen tilfeller være lurere med tables, men hvorfor ikke bare inline styles? Kan ikke tenke meg at inline styles kan være noe tregere enn tabeller utifra det forfatteren skriver her.

 

So, what's the savings? Half the bandwidth on 5-10% of the total bandwidth is 2.5 - 5% savings...MAX!!! Wow, lots of savings there!!! That's, TWO-POINT-FIVE to FIVE percent, not 50%...that's not a misprint.

 

2.5 - 5% er usannsynlig mye data hvis man er en stor side. ESPN og microsoft.com har vel et par milliarder sidevisninger etterhvert, og har man en daglig overføring på 20GB, vil nok 5% være etterlengtet. Betaler man per GB/MB kan det fort spare deg masse penger.

 

CSS-P = "Workaround Hack City" = Pain in the neck

 

So let's see. You have more JavaScript to write and now you double or triple the number of CSS pages you have to support. Great! That will increase performance. That is, for the person who has to maintain a full CSS site will have to INCREASE their PERFORMANCE to keep it up and running.

 

Det er meget fullt mulig å lage ett enkelt stilark som fungerer i samtlige nettlesere, UTEN noe tullete JS som skal kontrolle nettleser.

 

But wait, one more thing, you should forget about Netscape 4.x browsers of which people STILL use. And what about accessibility? Ha! How about getting it to look decent on the Apple Macintosh first? Double Ha ha!

 

Sist jeg sjekket, klarte ikke Apple Macintosh å rendre tabeller skikkelig. Hva er da bedre? Tabellkode som bare ødelegger alt, OG øker lastetiden, eller et stilark som bare vises som vanlig ustylet HTML? Go figure.

 

Så det jeg fant ut var noenlunde godt nok bevis for at fyren har ABSOLUTT INGEN PEILING på hva han snakker om:

 

# HEY Stupid! I have taken this very page your are reading, stripped it of the <table> tags and replaced them with <div> tags and it went from 51kB to 31kB. 

 

 

First, they forget that this particular page isn't really a page connected to a DATABASE, hence it doesn't use tabular data.

 

Nevertheless, if you take a close look at their resulting CSS only page of their page, it doesn't include all those CSS workarounds, and those additional workarounds for those workarounds to get it all the buttons to be in the right position or the border or lines. And that just for a single browser IE. They forget that this page using tables looks pretty much the same in Mozilla, Netscape, Safari, Opera.

 

They also forget to add in the additional CSS page weight to their 31k, and that's not including the original CSS page they have to add. This can jump easily to 41k and that's without the workarounds that need to added for it to look the same.

 

So by the time they got everything to look exactly like this page it will end up being about the same size anyway!

 

Yep, let's do the R.O.I. and see if one can really pay less for bandwidth. ISP's give you so much bandwidth per month anyway. Very few sites use more than 10-20% of the maximum monthly bandwidth allocation. And most of these CSS elitist webdesigner's websites hardly get any web traffic anyway! Plus, they don't even have a lot pages to view in the first place

 

This is possibly because they don't have anything worth storing and organizing in a database, nor the skills or desire to work with a database. How ironic isn't it? These same CSS elitists find the time to criticize those who don't use pure CSS for their web pages as those unwilling to learn a new tool, yet come right back around and are not willing to learn the database and programming stuff that makes the most treasured and valued content of high traffic websites.

 

Greit:

 

First, they forget that this particular page isn't really a page connected to a DATABASE, hence it doesn't use tabular data.

 

Så hvorfor bruke tabeller da? Det virker som om denne fyren prøver å argumentere med baklengs logikk; "tabeller er kun for tabulærdata, og det skjønner jeg, men siden denne siden ikke bruker tabulærdata har du dretet på draget, din sopp". Hva er logikken i det?

 

 

Nevertheless, if you take a close look at their resulting CSS only page of their page, it doesn't include all those CSS workarounds, and those additional workarounds for those workarounds to get it all the buttons to be in the right position or the border or lines. And that just for a single browser IE. They forget that this page using tables looks pretty much the same in Mozilla, Netscape, Safari, Opera.

 

Hvis man gjør det skikkelig, og ikke bare bytter ut hver eneste <table> med <div>, og tenker seg litt om når man koder, kan man LETT bygge om siden til 31kb MED støtte for samtlige nettlesere uten CSS-hacks. Det er bare bull å si at det er umulig. Forfatteren har åpenbart aldri prøvd.

 

Yep, let's do the R.O.I. and see if one can really pay less for bandwidth. ISP's give you so much bandwidth per month anyway. Very few sites use more than 10-20% of the maximum monthly bandwidth allocation. And most of these CSS elitist webdesigner's websites hardly get any web traffic anyway! Plus, they don't even have a lot pages to view in the first place

 

Så det skal være et argument? Jaja, vi svir av 20% mer bensin enn vi trenger, men jeg bruker nå ikke så mye likevel. Hva med de større sidene, hvor driftsutgifter faktisk har mye å si?

 

This is possibly because they don't have anything worth storing and organizing in a database, nor the skills or desire to work with a database. How ironic isn't it? These same CSS elitists find the time to criticize those who don't use pure CSS for their web pages as those unwilling to learn a new tool, yet come right back around and are not willing to learn the database and programming stuff that makes the most treasured and valued content of high traffic websites.

 

Her blir jeg mektig provosert. Hvem sier at jeg ikke ikke har peiling eller ønske til å jobbe mot en database? Tvert imot virker det som om forfatteren aldri har virkelig skjønt hva en database er, og for å få det rett en gang for alle kvalifiserer ikke en tabell-layout som en database. ALT av data som ligger på f.eks. www.jorgis.com er lagret i en database. De aller fleste sider til folk her i WDS er basert på at innhold lagres i database, enten SQL eller flatfil. Å snakke så nedsettende om en gruppe uten å ha et fnugg av peiling på hva man snakker om og å sette alle i samme bås er utrolig provoserende.

 

Det later altså til at forfatteren er enda en potte sur 45-åring som irriterer seg over at det ikke lenger er mulig å selge unna en Frontpage-side for 20 000 til en eller annen tomsing. Han/hun later til å være veldig irritert over alle "CSS-purister" som faktisk har funnet en bedre måte å lage websider på, på de aller fleste områder. De eneste argumentene han har, baserer seg på uvitenhet, fordommer og GROVE faktafeil. WYSIWYG og databaser er visstnok også noe han lever av, siden han selger plugins til Dreamweaver, samt plugins til SQL server. At han skulle profitere på at CSS går dunken, er vel ingen bombe. Ellers ville han aldri ha skrevet noe sånt. :roll:

Lenke til kommentar

Jeg er enig i at tabeller er mye værre å vedlikeholde, men jeg gir meg ikke på at det er lettere å bruke. Jeg er ikke så glad i sammenligninger med ting som ikke nødvendigvis har alt for mye til felles, men her kommer mine parkeringsplasser:

 

Tabell-plassen:

 

Du deler opp plassen i ruter, og plasserer bilene der du vil ha dem.

 

CSS-plassen:

 

Du lager en plass, parkerer en bil, og lar den flyte opp mot venstre. Så lager du en plass til, fyller den, og lar den flyte mot høyre. Så vil du at plassene skal være like store, uansett hvor store bilene er. Da er det ikke lenger intuitivt hva du skal gjøre ( i hvert fall ikke for meg)...

 

Nei, la oss slutte å snakke om biler, og holde oss til saken.

 

Poenget mitt er følgende: Tabbeller er semantisk feil, og en tungvindt (men i mange tilfeller lettere) og lite fleksibel måte å lage layout på. CSS er fremtiden, men inntil vi kommer dit synes jeg de fanatiske CSS-tilhengerne burde akseptere at noen bruker tabeller.

 

Et eksempel:

 

Jeg vil lage en del på siden min som ser slik ut:

 

------------------------------div-------------------------------------
-                   ---------------------------------------------------  -
-  -----------    -                           div                              -  -
-  -   bilde -    -                                                             -  -
-  -           -    -                                                             -  -
-  -----1-----    -                                                             -  -
-                    ------------------------2-------------------------  -
-                                                                                     -
----------------------------------------------------------------------

 

Linje 1 og 2 skal være på samme høyde.

 

Med tabeller er det rett frem, helt intuitivt. Men hvordan skal det gjøres med CSS?

Endret av anderlin
Lenke til kommentar
Poenget mitt er følgende: Tabbeller er semantisk feil, og en tungvindt (men i mange tilfeller lettere) og lite fleksibel måte å lage layout på.

Jeg tror ikke du får med mange folk her til å si at tabeller er lettere, men visst du selv synst at det er så mye enklere (merkelig nok) så kan du kanskje tenke på at når man gjør et sjikkelig arbeid så er det vanligvis ikke enkelt. Selv om jeg selv mener at å lage sider men css og divs er mye enklere enn å lage sider med tables og bare html.

Lenke til kommentar
Jeg sa at tabeller er LETTERE å skjønne enn CSS. Det betyr at jeg sa at tabeller er LETTERE. (altså ikke noe mer, ok?)

1: Selv om koden er stygg, så er det jo et veldig enkelt prinsipp som ligger bak. Mye lettere å skjønne enn CSS.

Prinsippet bak tabeller er langt fra lettere enn prinsippet bak CSS.

 

Tenk deg at du skal ha en side med en header og en meny horisontalt og to kolonner under. Da må du begynne med colspan, du må begynne å fargelegge table data-celler ved hjelp av fæl HTML 2.1-koding, hvis du skal begynne å pynte på lenker, tekst, bilder i forskjellige TD-er osv., da er prinsippet bak tabeller langt i fra lettere enn CSS.

 

 

Den som går ut og skriver noe slikt er en som har satt seg ned og prøvd å lære seg CSS, men som har gitt opp etter en time. Slike personer har ikke gjerne for HTML og CSS, de bør kjøpe seg nyeste Frontpage.

Lenke til kommentar
Tenk deg at du skal ha en side med en header og en meny horisontalt og to kolonner under. Da må du begynne med colspan, du må begynne å fargelegge table data-celler ved hjelp av fæl HTML 2.1-koding, hvis du skal begynne å pynte på lenker, tekst, bilder i forskjellige TD-er osv., da er prinsippet bak tabeller langt i fra lettere enn CSS.

Aner en liten misforståelse her: Jeg snakker om posisjonering ved hjelp av CSS vs posisjonering vha tabeller. Resten bør man selvfølgelig bruke CSS til. (jeg mener altså at man også bør bruke CSS til posisjoneringen, men at det er vanskeligere i mange vanlige tilfeller)

 

Men over til ditt eksempel. Følgende er jo et veldig vanlig oppsett for hjemmeside:

 

-------------------------------------------------------------------
-                                    header                                   -
-                                                                                 -
-------------------------------------------------------------------
-------------- ----------------------------------------------------
-               - -                                                               -
-    meny   - -                      innhold                               -
-               - -                                                               -
-               - -                                                               -
-------------- -----------------------------------------------------
-------------------------------------------------------------------
-                        footer                                                 -
-------------------------------------------------------------------

 

Dette kan gjøres på to måter med tabeller; enten colspan, eller ved nøstede tabeller (stygt). Du er da sikret at meny og innhold går helt ned til footer. Men er det like intuitivt hvordan man fikser dette med CSS?

Endret av anderlin
Lenke til kommentar
Dette kan gjøres på to måter med tabeller; enten colspan, eller ved nøstede tabeller (stygt). Du er da sikret at meny og innhold går helt ned til footer. Men er det like intuitivt hvordan man fikser dette med CSS?

Der er vi igjen inne på det med manglende CSS-støtte for visse nettlesere (les: IE); det er absolutt ikke noe problem å lage en footer med CSS, spør du meg er det enklere. Lag en div med 100% høyde og en div inni med position:absolute;bottom:0;. Dette skal fungere fint i de fleste nettlesere bortsett fra IE. Og jeg vil si at det er enklere med en div enn en kjempetabell med colspan og slikt styr.

Lenke til kommentar

med litt bilder er det 0 problem.

Finnes alltid lettere måter å gjøre ting på,

men hva har det egentlig å si når det er feil? :dontgetit:

 

Poenget er at det er semantisk(skrives sån?) ukorekt å bruke tabeller til layout.

Det er jo et faktum, da er det jo egentlig mer å krangle om.

 

*føler jeg kommer til å få svi på pungen for dette innlegget :!:

Lenke til kommentar
Poenget er at det er semantisk(skrives sån?) ukorekt å bruke tabeller til layout.

Det er jo et faktum, da er det jo egentlig mer å krangle om.

Men det er jo ikke dette vi diskuterer heller... Jeg diskuterer hvorvidt tabeller i mange vanlige tilfeller er lettere å bruke til posisjonering enn CSS, ikke semantikken i det hele.

Endret av anderlin
Lenke til kommentar

Et tabellayout er lettere å opprette - i en WYSIWYG-editor.

Det er uansett feil, som veldig, veldig mange har påpekt.

 

 

Anne ble mildt sagt forferdet da jeg viste ham linken også:

What a nonsense. He did not say a single thing about semantics, did

he? Because that is the most important argument imho. (Besides of

course, faster rendering, et cetera. And some other little extra's.

Lenke til kommentar
Jeg kan si meg enig i at tabeller kan løse mange problemer som vi knoter med rundt div's, men det rettferdiggjør ikke bruken av dem.

Semantikken må ikke overdrives, og er ikke noe mål i seg selv. Poenget med de fleste nettsider er å formidle informasjon og design, og det er de færreste som bryr seg med hvordan koden ser ut. Semantikk er viktig for den økende bruken av alternative måter å lese nettsider på (lesere for blinde etc).

 

På den andre siden er semantikk viktig for å lette vedlikehold, siden det letter forståelse av koden.

 

Mitt første poeng:

 

Hvis man er mest komfortabel med tabeller (slik mange nybegynnere er), selv skal vedlikeholde siden, og ikke har brukere med spesielle behov, så er det etter min mening helt greit å bruke tabeller.

 

Mitt andre poeng:

 

Jeg mener fremdeles at tabeller er et lettere (og mer begrenset) konsept enn posisjonering med CSS. Dette av følgende grunner:

 

- det er mindre å forholde seg til, og mindre å lære

- konseptet er kjent fra før (alle har sett en tabell, men ikke alle er vant med å tenke på flyt i et dokument)

- man slipper mange stygge kodesnutter pga IE

 

Mitt siste poeng:

 

La folk bruke tabeller så mye de vil frem til støtten for CSS er bedre (og CSS har mer funksjonalitet). Tenk heller på om nettsiden oppfyller det den skal, enn om den er korrekt etter diverse standarder. Noen vil kjempe for standardenes utbredelse, men det må da være frivillig.

 

EDIT: Hvis tabeller kan løse et problem uten å skape nye, synes jeg absolutt bruken er rettmessig.

Endret av anderlin
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...