Hoofdcategorieën
Topicacties

[HTML] Discussie <div> .vs. <table>

Pagina: 1 2 3 4 last

Nieuw Topic
Berichten: 1.631
Reg. datum: 14 januari 2000

Het correct toepassen van semantische HTML levert wel degelijk pluspunten op bij o.a. Google. Dat wit-op-wit, display:none en andere shittrucjes er uit gefilterd worden doet daar niets aan af. Ga er van uit dat Google je pagina ziet zoals een oude browser hem rendert. Alles wat meer in het oog springt doet dat min of meer ook bij Google.

Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.

Echte chocomel eerst!

quote:
Ik geloof dat Steve Pugh daar een concept van on-line heeft...

Why is everything here completely pointless?

Berichten: 1.631
Reg. datum: 14 januari 2000

quote:
T-MOB schreef op woensdag 12 september 2007 @ 15:40:
[...]
Ik geloof dat Steve Pugh daar een concept van on-line heeft...
Maak #nav bvb eens rood en #content blauw voor de grap.

Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.

De keuze tussen wil je een 100% hoogte en geeft dat inhoudelijk wat extras toevoegt.

Er zijn bij tabellen randvoorwaarden voor ontwerp, en vice versa met semantische html. Gebruik wat je wilt en gebruik wat werkt voor je.

disjfa - disj·fa (meneer)
disjfa.nl
Speel mee: schuifpuzzle | indiegamer.nl

www.clikk.nl
Berichten: 9.289
Reg. datum: 28 oktober 2000

quote:
Soultaker schreef op woensdag 12 september 2007 @ 15:10:
[...]

Ok:
HTML:
1
2
3
4
5
6
7
8
9
<html>
<head><title>Foo</title></head>
<body>
<table height="100%">
<tr height="100%"><td valign="top">Content</td></tr>
<tr height="50"><td>Footer</td></tr>
</table>
</body>
</html>

Hoe doe ik dit met CSS? Ik weet dat er officieel geen "height" attribuut is, maar browsers ondersteunen die wel, en terecht, want hij is nuttig. Als de W3C in plaats van drie CSS standaarden verzinnen die praktisch geen browser volledig kan ondersteunen de "height" attribuut had toegevoegd, waren ze zinniger bezig geweest.

Maar als CSS zo geweldig is, hoe doe je dit dan in CSS? (En ja, het is een subtiele vraag, maar ik wil dus dat de footer de content niet overlapt, dat ik een scrollbar krijg als content+footer niet past, en als er niet gescrolled wordt de footer onderaan staat.)
Zoiets?

Trouwens, ik vind dat het W3C zeker wel nuttig bezig is. Dat Microsoft het niet nodig vindt hun standaard te ondersteunen, waardoor we waarschijnlijk nooit bij CSS3 ondersteuning zullen belanden, vind ik erger.
quote:
Google is juist succesvol omdat ze alle metadata negeren en uitgaan van welke informatie daadwerkelijk gerenderd wordt. Als jij <h1 style="display:none">Nep Titel Hier</h1> neerzet heb je mooie semantische HTML maar zal een publieke zoekmachine die titel juist willen negeren. In klassieke HTML zonder CSS flauwekul kon je ook wel dit soort trucs verzinnen (met font-tags) maar dan was een <h1>-element tenminste een echte heading.
Semantiek heeft op de manier die je hier beschrijft, niets met rendering temaken. Dat Google display:none; negeert is goed. Maar het gaat er om, dat een H1 element belangrijker is als een H2 of H3. Dat een computer/applicatie weet dat alles binnen UL een lijst is. Dat iets binnen STRONG belangrijker (of iig de nadruk heeft) boven de omringende tekst.
quote:
Voor het daadwerkelijke WWW (buiten de belevingswereld van de waanzinnigen die in het semantische web geloven) is semantische HTML dus zinloos. Het enige wat belangrijk is aan HTML is dat je pagina's handig kan aanpassen aan je medium (audio, printer, verschillende beeldresoluties, enzovoorts) niet dat een machine er betekenis aan kan toekennen.
Semaniek is dus zeker niet zinloos. Dat jij net nut er niet van inziet, of de voordelen die het bied niet benut, wil niet zeggen dat ze er niet zijn. Voorbeeldje: een Screen Reader spreekt tekst binnen een STRONG element anders uit; legt er de nadruk op. Wat - mits goed gebruikt - heel handig kan zijn.
quote:
Dat is dus bezopen. Ze zijn dus 10 jaar bezig met een standaard voor lay-out die oude "amateuristische" technieken moet vervangen, en ze zijn feitelijk nog nergens, want niemand gebruikt een HTML5/CSS3 compatible browser.
Dat er nog geen browsers gebruikt worden die CSS3 ondersteunen (of uberhaupt zijn, die het ondersteunen...) is niet de fout van het W3C. Ik vind het goed dat ze een standaard bedenken, die in mijn ogen, beter is als table-tag-soup. :)

Partyagenda:
...

Berichten: 1.631
Reg. datum: 14 januari 2000

Heb ik al die tijd ergens overheen gelezen of wat is nou het fantastische aan HTML5 en CSS3 in deze context? Of ben ik gewoon een cynisch mens?

Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.

www.clikk.nl
Berichten: 9.289
Reg. datum: 28 oktober 2000

Het "fantastische" aan HTML5 en CSS3 is dat het nog meer semantiek toevoegd aan HTML en nog meer opmaak-mogelijkheden met zich mee brengt.

Opzich heeft dat niet veel met de orginele discussie te maken, maar wel als verlengde van de uitleg over waarom "divs" (wat ik liever semantisch bouwen noem) "beter" zijn/is als table-layout.

Partyagenda:
...

Berichten: 9.513
Reg. datum: 13 september 2000

quote:
Prachtig. Ik open good_example_short in Konqueror (mijn standaardbrowser) en hij doet het niet goed: als ik een venster kleiner maak en dan weer groter, gaat de footer niet omlaag.

Maar zelf als er een werkende mogelijkheid is:
- er zijn een heleboel mensen die serieus geprobeerd hebben dit op te lossen en die het niet lukte (deze auteur valt daar ook onder); waarom moet zoiets simpels zo moeilijk zijn?
- de CSS source is veel langer en ingewikkelder dan de table declaratie en dan nog werkt het niet
- de CSS source is veel minder intuïtief; ik schreef mijn table-voorbeeld zonder een browser erbij te hebben, maar ik betwijfel of je deze CSS code kunt schrijven zonder uitgebreid te testen op allerlei browsers (want het gaat om een hele subtiele mix van de juiste attributen met de juiste waarden in de juiste hiërarchie) en dan nog werkt het niet
- er is toch nog een browser-specifieke hack nodig (geldt niet voor de table) en dan nog werkt het niet
quote:
Semantiek heeft op de manier die je hier beschrijft, niets met rendering temaken. Dat Google display:none; negeert is goed. Maar het gaat er om, dat een H1 element belangrijker is als een H2 of H3. Dat een computer/applicatie weet dat alles binnen UL een lijst is. Dat iets binnen STRONG belangrijker (of iig de nadruk heeft) boven de omringende tekst.
Accoord, maar laten we de semantiek-discussie er dan even buiten houden. Ik ben het hier namelijk helemaal mee eens. (Een aantal uitspraken die je me toedicht staan ook lijnrecht tegenover wat ik probeerde over te brengen, dus daar is iets misgegaan in de communicatie.)
quote:
Dat er nog geen browsers gebruikt worden die CSS3 ondersteunen (of uberhaupt zijn, die het ondersteunen...) is niet de fout van het W3C. Ik vind het goed dat ze een standaard bedenken, die in mijn ogen, beter is als table-tag-soup. :)
Er zitten ook wel zinnige dingen in CSS, maar het is veel te beperkt. Het erge is dat allerlei bewezen technieken (die op zichzelf heel zinnig zijn; grid based lay-outs zijn gewoon logisch) opeens deprecated genoemd worden, terwijl ze ook zouden kunnen onderkennen dat CSS op een aantal punten niet voldoet. Verder hebben ze CSS wel zo complex gemaakt dat praktisch niemand (ook KHTML en Gecko voor lange tijd) het niet 100% goed konden doen. Dat is gewoon debiel.

Soultaker wijzigde dit bericht 12-09-2007 16:54 (12%)

www.clikk.nl
Berichten: 9.289
Reg. datum: 28 oktober 2000

quote:
Soultaker schreef op woensdag 12 september 2007 @ 16:52:
[...] en dan nog werkt het niet [...]
Ik geef toe dat het voorbeeld van de footer altijd onderaan, lastig te maken is in CSS. Waarom dat niet makkelijker kan, is mij ook niet geheel duidelijk. Dit is zeker iets waar verbetering kan plaatsvinden.
quote:
Er zitten ook wel zinnige dingen in CSS, maar het is veel te beperkt. Het erge is dat allerlei bewezen technieken (die op zichzelf heel zinnig zijn; grid based lay-outs zijn gewoon logisch) opeens deprecated genoemd worden, terwijl ze ook zouden kunnen onderkennen dat CSS op een aantal punten niet voldoet. Verder hebben ze CSS wel zo complex gemaakt dat praktisch niemand (ook KHTML en Gecko voor lange tijd) het niet 100% goed konden doen. Dat is gewoon debiel.
CSS is zeker nog geen volgroeide techiek, waar nog een hoop aan verbeterd kan worden. En dat CSS complex is, is zeker waar. En dat browsers er zo lang over gedaan hebben om het goed te ondersteunen, ik denk dat het voor een deel ook prioriteiten stellen is: toen die browsers/engines ontwikkeld werden, werd CSS2.1 nog vrij weinig gebruikt.

---

We zijn trouwens best een eindje van de orginele discussie afgedwaald. Ik blijf er namelijk bij, dat het alleen maar voordelen heeft, wanneer je een website geheel met symantische HTML en CSS voor opmaak, maakt. Dat het soms (erg) lastig is, dat geef ik direct toe.

Partyagenda:
...

Berichten: 1.631
Reg. datum: 14 januari 2000

quote:
OkkE schreef op woensdag 12 september 2007 @ 17:08:
CSS is zeker nog geen volgroeide techiek, waar nog een hoop aan verbeterd kan worden. En dat CSS complex is, is zeker waar. En dat browsers er zo lang over gedaan hebben om het goed te ondersteunen, ik denk dat het voor een deel ook prioriteiten stellen is: toen die browsers/engines ontwikkeld werden, werd CSS2.1 nog vrij weinig gebruikt.
quote:
OkkE schreef op woensdag 12 september 2007 @ 16:34:
Het "fantastische" aan HTML5 en CSS3 is dat het nog meer semantiek toevoegd aan HTML en nog meer opmaak-mogelijkheden met zich mee brengt.

Opzich heeft dat niet veel met de orginele discussie te maken, maar wel als verlengde van de uitleg over waarom "divs" (wat ik liever semantisch bouwen noem) "beter" zijn/is als table-layout.
Nou ik heb niet het gevoel dat HTML5 en CSS3 heel snel geimplementeerd worden. En HTML5 en CSS3 zijn geenszins de structurele verbeteringen waar we sinds 1995 op zitten te wachten (!!!!!!). En je weet hoe lang het geduurd heeft voordat HTML4 en CSS1,5 een beetje wijd verbreid geadopteerd waren door browsers en webdesigners.

Ik hoef niet nog eens vijf jaar van mijn leven te verspillen met wachten op de volgende standaard die dan misschien weer incrementeel iets minder hard zuigt. En als ik tot die tijd een of twee tabelletjes moet gebruiken om een bepaalde layout mogelijk te maken en het verder netjes houd, schaam ik me helemaal nergens om. Ik ben niet degene die zich moet schamen IMHO :(

BikkelZ wijzigde dit bericht 12-09-2007 17:30 (7%)

Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.

Het is helemaal geen kwestie van kennis, maar voornamelijk van ondersteuning.
Niet voor alle toepassingen die je met tabellen kunt bereiken zijn nette XHTML+CSS oplossingen die in alle a-grade browsers correct ondersteunt worden. Je bent nu eenmaal meer tijd kwijt omdat je werk dubbel moet gaan zitten doen, om elke browser het juiste resultaat te laten weergeven.

Bedrijven kiezen nog vaak voor tables omdat dit in 99% van de gevallen goedkoper is.
Onderhoud is misschien wel omslachtiger, maar dat wordt toch gefactureerd.
 
Even opmerken dat "tabellensoep" niet gelijk staat aan "niet-werken met CSS". Persoonlijk pleit ik voor de meest pragmatische oplossing (hier reeds aangegeven) :
  • Kies altijd divs zolang je kan werken zonder hacks.
  • Kies tabellen als het een typische tabellen layout is of wanneer het een div-soup dreigt te worden
Overigens moeten designers (als in grafici) maar eens rekening houden met de mogelijkheden van HTML en CSS. Het is immers een ander medium dan print (ook al gezegd hier). Vaak willen zij er een online videogame van maken lijkt het wel :^P...

Tot slot: In principe kan je veel oplossen met cond. statements. Een groot voordeel van div-layout is dat je relatief goede controle hebt op de "print"-versie van je project. Met tabellen lijkt me dat minder evident, maar ik moet toegeven... nooit gelet op print-versies toen ik tables gebruikte :^)
quote:
OkkE schreef op woensdag 12 september 2007 @ 17:08:
.... alleen maar voordelen heeft .... Dat het soms (erg) lastig is, dat geef ik direct toe.
Dat het erg lastig kan zijn is meteen een zeer sterk nadeel lijkt me of je moet blind zijn voor nadelen.

moozzuzz wijzigde dit bericht 12-09-2007 18:16 (14%)

ProMoozz.org - XHTML is for pussies!

Berichten: 9.513
Reg. datum: 13 september 2000

Ik gebruik zelf ook altijd css voor allerlei dingen; het feit dat je een class kunt toekennen en dan een gemeenschappelijk set attributen hebt is al erg handig (in de jaren '90 moest je overal dezelfde tags copy pasten als je bijvoorbeeld op verschillende plekken een bepaald font wilde gebruiken) en dat je binnen een stylesheet kunt erven (cascaden :P) is ook handig.

Dus ik vind css ook wel handig, maar het model is beperkt en steekt slecht in elkaar, waardoor webdesigners niet goed weten hoe ze iets moeten doen in css en browsermakers niet goed weten hoe ze het moeten implementeren.
No rest for the tweaked
Berichten: 250
Reg. datum: 27 juni 2007

quote:
CSS is zeker nog geen volgroeide techiek, waar nog een hoop aan verbeterd kan worden. En dat CSS complex is, is zeker waar.
En dan alsnog voorstander zijn van CSS, dat is een beetje krom. Windows Vista is in de ogen van velen ook nog 'geen volgroeid OS', en dat is voor veel van die mensen een reden om bij XP te blijven. Ik dat opzicht zou het juist een wijze keuze zijn voorlopig nog de 'geteste methode' van tabellen te gebruiken.

Persoonlijk gebruik ik vaak tables en DIV's in combinatie met elkaar. Tables zijn erg praktisch om de globale indeling op te zetten (headertje boven, footertje onder, menuutje links en content in het midden), en is CSS de perfecte manier om de opmaak van de losse elementen, en daarmee de pagina/site in zijn geheel, te bepalen.

In deze zienswijze word dus duidelijk een onderscheid gemaakt tussen indeling (een hele simpele, in dit voorbeeld, maar het volstaat) en opmaak. Wanneer men een pagina wilt printen, zijn menu's vaak ongewenst, en veel sites hanteren een simpel scriptje om middels een pop-up een pagina te openen die geschikt is voor print. Het argument dat 'semantische' HTML d.m.v. divs voor dit doel effectiever zou zijn, gaat dus nauwelijks op. Websites zijn gewoon (nog) niet bedoeld om te printen, dus de gebruikte workarounds zullen in deze gevallen toch vaak de voorkeur genieten.

Verder is het ontwerpen van een website, zoals al vaker aangekaart is in dit forum, niet alleen afhankelijk van de mogelijkheden van CSS, maar ook de interpretatie hiervan. Ook in mijn ogen heeft een div-je met CSS opmaak veel voordelen, maar totdat browsers deze ook naar alle tevredenheid ondersteunen, zal men andere mogelijkheden toe moeten passen. Tenslotte is het onmogelijk een stenen huis te bouwen met slechts spijkers en een zaag, ook al is een stenen huis heel wat steviger dan het houten huis waar je nu voor zult moeten gaan.

Als laatste vind ik het argument 'omdat het daar niet voor bedoeld is' één van de slechtste argumenten die je in deze discussie naar voren kunt brengen. Om maar een simpel voorbeeld te noemen; computers zijn nooit bedoeld om te gamen. Toch zullen er hier onder de tweakers heel wat fervente PC- / console-gamers zijn. Voel je je dan schuldig, door een PC op zo'n manier te 'misbruiken'? Speel je elke avond nog trouw een spelletje mens-erger-je-niet met je ouders onder het genot van een kopje thee?

Als er niet ooit, ergens, iemand was geweest die iets gebruikte op een manier waar het niet voor bedoeld was, had er nooit zoiets als een technologische vooruitgang bestaan. Ontwikkeling betekent nieuwe oplossingen vinden voor bestaande problemen, ook al gebruik je oude methoden/instrumenten op een compleet andere manier. Zolang je je doel bereikt, kan het argument 'omdat het er niet voor bedoeld is' IMO absoluut niet gebruikt worden ter rechtvaardiging.

Sorry voor de lange post, maar het semantiek-regime dat sommige mensen erop nahouden, staat me gewoon niet zo aan ;)
 
quote:
Duroth schreef op woensdag 12 september 2007 @ 21:03:
Websites zijn gewoon (nog) niet bedoeld om te printen, dus de gebruikte workarounds zullen in deze gevallen toch vaak de voorkeur genieten.
CSS is dan juist een zegen. Als je je website logisch opbouwt, heb je in tien minuten een print-stylesheet geschreve. De workarounds omvatten doorgaans aparte PHP-scripts. Ook die zijn in tien minuten gemaakt, maar al het onderhoud moet je dubbel doen. Met CSS pak je het probleem generieker aan: je verandert de presentatie in plaats van de data.
quote:
Als laatste vind ik het argument 'omdat het daar niet voor bedoeld is' één van de slechtste argumenten die je in deze discussie naar voren kunt brengen.[...]
Daar ben ik het mee eens. Dat argument wordt ook zelden gebruikt. De meeste mensen brengen ingewikkeld onderhoud en ontoegankelijkheid aan als argumenten tegen het gebruik van tabellen voor layout-doeleinden.
 
Berichten: 9.513
Reg. datum: 13 september 2000

quote:
Niels Sijm schreef op woensdag 12 september 2007 @ 22:30:
CSS is dan juist een zegen. Als je je website logisch opbouwt, heb je in tien minuten een print-stylesheet geschreven. De workarounds omvatten doorgaans aparte PHP-scripts. Ook die zijn in tien minuten gemaakt, maar al het onderhoud moet je dubbel doen. Met CSS pak je het probleem generieker aan: je verandert de presentatie in plaats van de data.
Het punt is dat je met CSS dus niet de goede lay-out kunt maken. Dan moet je dus concessies doen aan je primaire medium alleen om te kunnen printen. Dat vind ik moeilijk te verteren, zeker als PHP standaard gebruikt wordt en je zoals je zelf ook zegt daarmee hetzelfde effect kunt bereiken, zónder in je mogelijkheden beperkt te worden.

Verder ervaar ik zelf het dubbele onderhoud niet zo; vaak bouw je een pagina min of meer op uit een template gecombineerd met wat dingen uit een database, en kun je gewoon bepaalde delen weglaten uit je pagina (navigatie bv) als je een print-variable meegeeft. Net zoals je vaak bepaalde dingen weglaat als iemand niet ingelogd is bijvoorbeeld. Het nadeel blijft natuurlijk dat je een aparte print link nodig hebt. Maar overigens kun je vaak ook wel een print-css gebruiken in combinaties met een table-layout. (Verder valt er ook wel wat voor te zeggen om een aparte link te hebben; als een pagina er geprint heel anders uitziet is dat ook weer verwarrend voor de gebruiker.)
quote:
Dat argument wordt ook zelden gebruikt. De meeste mensen brengen ingewikkeld onderhoud en ontoegankelijkheid aan als argumenten tegen het gebruik van tabellen voor layout-doeleinden.
Overigens grappig dat zowel Jaaap als ik een voorbeeld gegeven van iets wat makkelijk met tables kan maar niet met css, en hoewel er genoeg proponenten van css verklaard hebben dat alles best wel kan met css, heeft nog niemand uitgelegd hóé dan. Kan ik daaruit concluderen dat er consensus bestaat over de gebrekkigheid van css?
No rest for the tweaked
Berichten: 250
Reg. datum: 27 juni 2007

Edit: Grr, de heer Soultaker was me voor... En heeft me meteen gelijk maar de woorden uit mijn mond genomen :P
quote:
Niels Sijm schreef op woensdag 12 september 2007 @ 22:30:
CSS is dan juist een zegen. Als je je website logisch opbouwt, heb je in tien minuten een print-stylesheet geschreve. De workarounds omvatten doorgaans aparte PHP-scripts. Ook die zijn in tien minuten gemaakt, maar al het onderhoud moet je dubbel doen. Met CSS pak je het probleem generieker aan: je verandert de presentatie in plaats van de data.
Helaas helpt CSS niet tegen hetgene dat mensen het meest irriteert bij het printen van een website: De menu's die aan de linkerkant staan, het grote opzichtige logo erboven, en eventueel een kleiner menu onder in de footer. Om deze redenen gebruikt men workarounds, niet om het feit dat de tekstkleur op de website wit is, en deze op papier er in het zwart veel beter uitziet. Pas als CSS ook aan kan geven welke elementen niet geprint mogen worden, kan dit argument standhouden (en alle elementen visibility: hidden meegeven is evengoed een workaround uiteraard ;) )
quote:
Daar ben ik het mee eens. Dat argument wordt ook zelden gebruikt. De meeste mensen brengen ingewikkeld onderhoud en ontoegankelijkheid aan als argumenten tegen het gebruik van tabellen voor layout-doeleinden.
Helaas komt het argument maar veel te vaak voorbij. Ook op GoT betrap ik men er nog wel eens op. Dat tables vaak moeilijker te onderhouden zijn is ook niet altijd van toepassing, aangezien div's, zeker als ze absoluut of relatief gepositioneerd zijn, een complete handleiding vereisen om aan een derde partij aan te geven waar wat nu precies voor staat. En de kwestie ontoegankelijkheid gaat ook niet altijd meer op, zeker niet als de website ontworpen is voor een specifieke doelgroep. Dat ook slechtzienden makkelijk toegang krijgen tot de informatie is heel leuk (om maar een voorbeeld te noemen), maar een fotograaf die zijn werk in een online portfolio zet, zal er zeer weinig boodschap aan hebben.

Om de conclusie van mijn vorige post nog maar even samen te vatten: CSS is in sommige gevallen inderdaad een verbetering, maar in sommige gevallen heb je er niks aan. Gebruik gewoon wat in de situatie het efficiëntst is, zonder je zorgen te maken om de semantiek. wat 'correct' is en wat niet is altijd een mening, wat 'werkt' en wat niet, daar kunnen mensen wat mee.
 
quote:
Duroth schreef op woensdag 12 september 2007 @ 22:51:
Pas als CSS ook aan kan geven welke elementen niet geprint mogen worden, kan dit argument standhouden (en alle elementen visibility: hidden meegeven is evengoed een workaround uiteraard ;) )
Waarom is "visibility: hidden" een workaround? Ik geef zelf altijd een "display: none", maar het idee is hetzelfde. Waar zijn beide properties anders voor gemaakt? Je wilt de presentatie aanpassen, dus gebruik je CSS.

Steeds meer komt de ware aard van het HTML (en daarmee het www) naar boven: het is nooit bedoeld om gedetailleerd te worden vormgegeven. Het kan wel, maar vanwege zijn platformonafhankelijke aard zal je altijd beperkingen blijven houden. CSS lost een deel op, maar niet alles. Ik ben me erbij aan het neerleggen dat een grafische presentatie van HTML altijd een benadering zal zijn. Ben ik even blij dat ik me vooral focus op de techniek erachter; die heb je veel meer in de hand ;).
 

Acties:


Door: crisp
Devver / Moderator WEB
Papa van Jeremy \o/
Berichten: 34.059
Reg. datum: 24 februari 2000

quote:
Duroth schreef op woensdag 12 september 2007 @ 22:51:

Helaas helpt CSS niet tegen hetgene dat mensen het meest irriteert bij het printen van een website: De menu's die aan de linkerkant staan, het grote opzichtige logo erboven, en eventueel een kleiner menu onder in de footer. Om deze redenen gebruikt men workarounds, niet om het feit dat de tekstkleur op de website wit is, en deze op papier er in het zwart veel beter uitziet. Pas als CSS ook aan kan geven welke elementen niet geprint mogen worden, kan dit argument standhouden (en alle elementen visibility: hidden meegeven is evengoed een workaround uiteraard ;) )
Nog nooit van media-stylesheets gehoord?

Pak eens een willekeurig nieuwsartikel op onze frontpage en doe voor de gein eens een print preview? ;)

Dat is de powerrr van CSS :)

Crisp's blog

Heb jij al meegedaan aan de GoT verkiezingen?


Acties:


Door: crisp
Devver / Moderator WEB
Papa van Jeremy \o/
Berichten: 34.059
Reg. datum: 24 februari 2000

Even meer ontopic ;)
quote:
Soultaker schreef op woensdag 12 september 2007 @ 22:50:
[...]
Overigens grappig dat zowel Jaaap als ik een voorbeeld gegeven van iets wat makkelijk met tables kan maar niet met css, en hoewel er genoeg proponenten van css verklaard hebben dat alles best wel kan met css, heeft nog niemand uitgelegd hóé dan. Kan ik daaruit concluderen dat er consensus bestaat over de gebrekkigheid van cssZ
Ik wil het geen gebrekkigheid noemen maar immaturity, zowel van implementaties als van de specificaties. Er staat zoals gezegd echter wel veel op stapel, kijk anders eens op http://www.w3.org/Style/CSS/current-work - gridlayouts worden daarin ook voorzien als een uitbreiding op multi-column layouts. Dat soort dingen kosten echter tijd, en het kost nog meer tijd voordat er goede implementaties zijn en bugs en tekortkomingen kunnen worden geconstateerd en gerepareerd in revisies. Who's to blame? Well, misschien moeten we allemaal wel een beetje de hand in eigen boezem steken...

Bottom line is dat het gebruik van tables voor layout blijven goedpraten de situatie ook niet helpt, op die manier blijf je in cirkeltjes rennen. Persoonlijk vind ik het geen schande als je voor een basis opzet eens een table gebruikt omdat dat crossbrowser eenvoudiger is (of zelfs de enige mogelijkheid, hoewel ik dan toch eerder in conclaaf zou gaan met de designer), maar op het moment dat je vervalt in geneste tabellen en spacer.gifjes (omdat het table-layout model nu eenmaal per definitie niet pixelprecies is en er ook mbt table-rendering verschillen zijn tussen browsers (!)) zou je jezelf toch wel achter de oren moeten gaan krabben.

Front-end webdevelopment is mijn werk en daarmee ook mijn passie - als het dat niet zou zijn had ik wel een ander beroep gekozen - dus ik ben niet vies van wat experimenteren en kennis opdoen in mijn eigen tijd. Dat CSS ingewikkeld of complex is vind ik dus geen erg sterk argument; het is te leren en het is verdulleme je vak notabene!. Dat het onhandig is in gebruik ligt ook voor een groot deel aan de implementaties (nou ja, voornamelijk die van 1 vendor :P), maar ook daar kan je jezelf de truukjes en workarounds voor aanleren.

Crisp's blog

Heb jij al meegedaan aan de GoT verkiezingen?

Berichten: 1.631
Reg. datum: 14 januari 2000

http://www.w3.org/TR/2007/WD-css3-layout-20070809/

Een voorstel van augustus dit jaar. Wanneer zou dit gemeengoed worden?


(toen ik refereerde naar die hele spannende dingen in CSS3 had iemand dit best mogen aandragen trouwens....).

Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.

www.clikk.nl
Berichten: 9.289
Reg. datum: 28 oktober 2000

quote:
Duroth schreef op woensdag 12 september 2007 @ 21:03:
En dan alsnog voorstander zijn van CSS, dat is een beetje krom. [...]
Dus omdat een techniek nog niet 100% voldoet, moeten we het daarom maar niet gebruiken? Ik geef toe dat CSS nog niet 100% goed is, maar ik zie persoonlijk meer voordelen aan semantisch webdesign (en dat is meer als alleen werken met CSS) in vergelijking met het (overvloedig) gebruik van tabellen.
quote:
Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] Wanneer men een pagina wilt printen, zijn menu's vaak ongewenst, en veel sites hanteren een simpel scriptje om middels een pop-up een pagina te openen die geschikt is voor print. Het argument dat 'semantische' HTML d.m.v. divs voor dit doel effectiever zou zijn, gaat dus nauwelijks op. [...]
Het gebruik van semantische HTML heeft als één van de voordelen, dat je geen apart print-script hoeft te maken. Je hoeft geen aparte versie voor print te maken (die je ook weer moet aanpassen indien er iets aan de pagina veranderd wordt). Daarnaast heeft semantische HTML nog veel meer voordelen; spiders hebben een beter idee wat met bepaalde content bedoelt wordt, door minder tabel-, tr- en td-elementen wordt je keyword density hoger, met een screen reader een tabel-website bekijken is gewoon geen pretje, etc..
quote:
Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] maar totdat browsers deze ook naar alle tevredenheid ondersteunen, zal men andere mogelijkheden toe moeten passen.
Zoals ik al eerder aan heb gegeven, ben ik nog maar weinig ontwerpen tegen gekomen die ik niet kon bouwen met HTML en CSS. Kan zijn omdat ik geluk heb met onze ontwerper, die (ongeveer) weet wat wel en niet kan, ik weet het niet.
quote:
Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] Als laatste vind ik het argument 'omdat het daar niet voor bedoeld is' één van de slechtste argumenten die je in deze discussie naar voren kunt brengen.
Ik geloof niet dat ik dit argument zelf ooit gebruikt heb, in deze discussie. Maar het is in mijn ogen wél een (goed) argument, namelijk om de volgende reden: elk element (op DIV en SPAN na) heeft een betekenis. Tabellen zijn bedoeld voor tabulaire data. Nu is het niet echt een heel zwaar wegend argument, maar computers zullen dus denken dat je website tabulaire data is, waarbij over het algemeen verbanden bestaan. Zoals ik zei; niet echt sterk, maar zeker ook niet helemaal onzin.
quote:
Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] Zolang je je doel bereikt, kan het argument 'omdat het er niet voor bedoeld is' IMO absoluut niet gebruikt worden ter rechtvaardiging. [...]
Ben ik opzich wel met je eens, maar alleen als er geen beter alternatief beschikbaar is. En dat is denk ik het punt, hier verschillen de meningen, maar ik denk dat er een beter alternatief is, boven het gebruik van tabellen voor opmaak. :)
quote:
Duroth schreef op woensdag 12 september 2007 @ 21:03:
[...] Sorry voor de lange post, maar het semantiek-regime dat sommige mensen erop nahouden, staat me gewoon niet zo aan ;)
Mij staat de houding "tabellen zijn prima voor opmaak" me niet zo aan, dat vind ik een beetje de Microsoft houding, NOFI.
quote:
Soultaker schreef op woensdag 12 september 2007 @ 22:50:
Het punt is dat je met CSS dus niet de goede lay-out kunt maken. Dan moet je dus concessies doen aan je primaire medium alleen om te kunnen printen. [...]
Ik heb eigenlijk nooit concessies hoeven doen aan een layout om hem printbaar te maken...
quote:
Soultaker schreef op woensdag 12 september 2007 @ 22:50:
[...] Kan ik daaruit concluderen dat er consensus bestaat over de gebrekkigheid van css?
Ik denk dat we het er wel over eens zijn, dat bepaalde layouts niet (of iedergeval niet zonder hacks) te maken zijn met CSS. En om in dat geval een tabel te gebruiken, kan dan best een oplossing zijn.

Ik wil ook niet zeggen dat er helemaal nooit meer een tabel voor layout gebruikt mag worden. Wel vind ik dat je tabellen voor layout [i]het liefst zo min mogelijk[i] moet gebruiken, en eigenlijk liever helemaal niet. Wat ik vooral wil bereiken is dat iedereen die het idee heeft "tabellen zijn prima voor layout" toch eens gaat nadenken over de voordelen van semantisch webdesign.
quote:
Duroth schreef op woensdag 12 september 2007 @ 22:51:
[...] Pas als CSS ook aan kan geven welke elementen niet geprint mogen worden, kan dit argument standhouden (en alle elementen visibility: hidden meegeven is evengoed een workaround uiteraard ;) )
Ik heb anders al meerdere malen content verborgen dmv 'display:none;' in een print-stylesheet. Dus tenzij we beide iets anders bedoelen, is het wel mogelijk om content te verbergen bij het printen. :)
quote:
Duroth schreef op woensdag 12 september 2007 @ 22:51:
Helaas komt het argument maar veel te vaak voorbij. Ook op GoT betrap ik men er nog wel eens op. Dat tables vaak moeilijker te onderhouden zijn is ook niet altijd van toepassing, aangezien div's, zeker als ze absoluut of relatief gepositioneerd zijn, een complete handleiding vereisen om aan een derde partij aan te geven waar wat nu precies voor staat. En de kwestie ontoegankelijkheid gaat ook niet altijd meer op, zeker niet als de website ontworpen is voor een specifieke doelgroep. Dat ook slechtzienden makkelijk toegang krijgen tot de informatie is heel leuk (om maar een voorbeeld te noemen), maar een fotograaf die zijn werk in een online portfolio zet, zal er zeer weinig boodschap aan hebben.
Tabellen zijn lastiger te onderhouden als een website met CSS, wanneer (delen van de) website gerestyled/gerepositioneerd moeten worden. Over het algemeen kun je sneller een DIV op een andere plaats zetten als een tabel-cel.

Verder vind ik niet dat CSS lastiger is, en daar al zeker geen handleiding voor nodig is. Indien een derde partij een handleiding nodig heeft om een DIV/CSS based website te onderhouden, is er imho of a) te weinig kennis in huis bij die partij, of b) de website niet goed genoeg opgezet. Als ik een website maak in DIVs en alle divs IDs als "text1", "text2", etc.. mee geef, ja dan is het lastig. Maar het id "nieuws_blok_homepage" geeft duidelijk aan wat het is.
quote:
Duroth schreef op woensdag 12 september 2007 @ 22:51:
Om de conclusie van mijn vorige post nog maar even samen te vatten: CSS is in sommige gevallen inderdaad een verbetering, maar in sommige gevallen heb je er niks aan. Gebruik gewoon wat in de situatie het efficiëntst is, zonder je zorgen te maken om de semantiek. wat 'correct' is en wat niet is altijd een mening, wat 'werkt' en wat niet, daar kunnen mensen wat mee.
Ben ik niet met je eens. Ik vind dat je je wel druk moet maken om semantiek. Dat je uiteindelijk besluit dat een tabel te gebruiken vind ik niet zo erg, als je die keuze maar wel overwogen gemaakt hebt. En dan hangt het vooral van kennis, browser-ondersteuning en tijd/geld af, of er gekozen wordt voor een tabel, denk ik.

Partyagenda:
...

Berichten: 4.121
Reg. datum: 11 juni 2005

quote:
imp4ct schreef op dinsdag 11 september 2007 @ 22:28:
Reden is vrij simpel, 't gaat gewoon een stuk sneller
Meuh. Zeker als je complexere layouts maakt, dan is CSS gebruik in mijn ogen sneller, maar dat kan ook zijn omdat ik alleen de eerste 3 jaar met tables heb gewerkt en nu alweer dik 3 jaar met CSS in de weer ben. Het moment waar je écht merkt wat de meest praktische kracht van CSS is, is als je je ingewikkelde layout moet veranderen. Dan ga je als tabledesigner zo ongelooflijk hard op je bek. Het makkelijke aan CSS is dat je alleen code hebt voor de dingen die je daadwerkelijk gebruikt, dus geen loze cellen, rijen, enz. Gewoon per onderdeel een <div> ofzo. Wil je die ergens anders hebben? Smijt hem gewoon daar neer. In de praktijk heb ik nauwelijks problemen met browsers en als ik die al heb, dan is het 99% van de keren Internet Explorer die de boel gruwelijk verneukt, maar die devvers in Redmond zijn gewoon zo kanzloß dat ze zelfs nog bruikbare bugs produceren, waardoor je de IE quirks ook weer makkelijk in toom kan krijgen.

Bottom line: tables envangelisten hebben 9 van de 10 keer niet verder gekeken dan hun neus lang is en vervloeken CSS al voordat ze de moeite hebben genomen zich erin te verdiepen.
 
Wandelende orgaanzak
Berichten: 2.770
Reg. datum: 12 september 2001

CSS gebruik is ook sneller, zeker als je met een complexe layout werkt, voornamelijk met veel verschillende type soorten.

Ik ben zelf iemand die veel met de basis werkt, dus div's EN tables. Deze mix ik ook graag, maar gebruik daarnaast ook een deel CSS. De projecten waar ik mee bezig geweest ben werken (voor alsnog) onder alle browser typen en ben eigenlijk nog maar weinig echt relevante bugs tegen gekomen.

Het werken met tables en div's in combinatie is dat het kwa broncode allemaal overzichtelijk blijft en dat je bepaalde zaken in 1 bestand houdt. Het werken met CSS vergt wat meer tijd in het begin, maar als je eenmaal een layout op "papier" hebt staan is de rest "a piece of cake".

Tja, met tables en div's ben je dan uiteindelijk (bij grote sites) stukken langer bezig. Daarentegen werken de CSS's je weer tegen als je "eventjes snel een website op moet zetten" .

Beide hebben zijn voordelen en nadelen, het is maar net waar je zelf vind dat je het lekkerste mee werkt. Ik ben dan zelf wel van mening dat je met CSS een flink verder kan komen dan de standaard tables of div's....ondanks dat ik alle 3 vaak gebruik....

If YouTube MySpace then i Google your Yahoo.....

Berichten: 96
Reg. datum: 27 juni 2007

Ik vind juist dat div's wel snel en gemakkelijk zijn. Gewoon divje hier divje daar! Bij tables moet je kolommen en rijen samenvoegen etc. Misschien wel makkelijk met dreamweaver, maar anders een gigantisch gedoe.. :/
 

Pagina: 1 2 3 4 last


Dit topic is gesloten.


VNU Media logo Hosted by True

© 1998 - 2010 Tweakers.net - Alle rechten voorbehouden - Uw Privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2009