![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[view]](images/icons/view.gif "Bekijk bericht"){kind=icon}
Door: 
Berichten: 1.623
Reg. datum: 14 januari 2000
Reg. datum: 14 januari 2000
Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.
Why is everything here completely pointless?
Berichten: 1.623
Reg. datum: 14 januari 2000
Reg. datum: 14 januari 2000
Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.
disjfa - disj·fa (meneer)
disjfa.nl
Speel mee: schuifpuzzle | indiegamer.nl
Zoiets?quote:
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.
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:
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 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.quote:
Partyagenda:
12/12 TimeWarp (Maassilo)
Berichten: 1.623
Reg. datum: 14 januari 2000
Reg. datum: 14 januari 2000
Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.
Partyagenda:
12/12 TimeWarp (Maassilo)
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.quote:
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
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:
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.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.
Soultaker wijzigde dit bericht 12-09-2007 16:54 (12%)
Partyagenda:
12/12 TimeWarp (Maassilo)
Berichten: 1.623
Reg. datum: 14 januari 2000
Reg. datum: 14 januari 2000
quote:
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.quote:
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.
Berichten: 587
Reg. datum: 05 januari 2005
Reg. datum: 05 januari 2005
ProMoozz.org - XHTML is for pussies!
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 
) 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.
) 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.
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.quote:
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
Berichten: 14
Reg. datum: 04 september 2007
Reg. datum: 04 september 2007
Edit: Grr, de heer Soultaker was me voor... En heeft me meteen gelijk maar de woorden uit mijn mond genomen )
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.
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 uiteraardquote:
)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.quote:
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.
Berichten: 14
Reg. datum: 04 september 2007
Reg. datum: 04 september 2007
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.quote::
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
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
.
Nog nooit van media-stylesheets gehoord?quote::
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
Pak eens een willekeurig nieuwsartikel op onze frontpage en doe voor de gein eens een print preview?
Dat is de powerrr van CSS
Even meer ontopic
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), maar ook daar kan je jezelf de truukjes en workarounds voor aanleren.
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...quote:
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
), maar ook daar kan je jezelf de truukjes en workarounds voor aanleren.Berichten: 1.623
Reg. datum: 14 januari 2000
Reg. datum: 14 januari 2000
Ik fix problemen die volgens de vorige ontwikkelaar in werkelijkheid toch nooit zouden voorkomen.
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:
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:
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:
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:
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:
Mij staat de houding "tabellen zijn prima voor opmaak" me niet zo aan, dat vind ik een beetje de Microsoft houding, NOFI.quote::
[...] Sorry voor de lange post, maar het semantiek-regime dat sommige mensen erop nahouden, staat me gewoon niet zo aan
Ik heb eigenlijk nooit concessies hoeven doen aan een layout om hem printbaar te maken...quote:
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.quote:
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.
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::
[...] 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
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.quote:
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.
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.quote:
Partyagenda:
12/12 TimeWarp (Maassilo)
If YouTube MySpace then i Google your Yahoo.....
Berichten: 96
Reg. datum: 27 juni 2007
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.. 
Dit topic is gesloten.
