[HTML] Wie bepaalt eigenlijk wat goed en fout is?

[PaulZ]

Regelmatig kom ik hier opmerkingen tegen in de trant van 'tables mag je niet gebruiken voor lay-out', 'frames gebruiken is een doodzonde' etc.

Wie bepaalt nu eigenlijk wat goed en fout gebruik is in HTML-design?

Mij lijkt het dat de ontwerper, mits goed doordacht natuurlijk, zelf moet besluiten hoe hij/zij de pagina's opbouwt en moeten de bovenstaande voorbeelden als aanbevelingen worden gezien. Of zit ik er naast?

[equationunequal]

W3C

[PaulZ]

Volgens mij doen die toch alleen aanbevelingen?

[paragon]

Je kan er natuurlijk zelf eigenlijk simpel over nadenken. Waar is een tabel voor bedoelt?

[Not Pingu]

Hankey schreef op dinsdag 22 maart 2005 @ 17:43:
W3C

Het W3C is niet heilig. Het zal niet de eerste keer zijn dat het W3C behoeften over het hoofd zit die later gecorrigeerd moeten worden, of dat het W3C dingen overneemt die door anderen ontwikkeld zijn (zo is CSS2.1 gedeeltelijk gebaseerd op de Microsoft implementatie van CSS).

Uiteindelijk is het de markt die bepaalt wat goed en fout is. En dan heb ik het niet alleen over webdesigners, maar over browsers en eindgebruikers. Neem nou zoiets als semantiek. Dat is nooit zo sterk door het W3C uitgedragen, en werd pas een issue nadat Google pagina's kwam doorzoeken.

[ Voor 12% gewijzigd door Not Pingu op 22-03-2005 17:48 ]

[Verwijderd]

PaulZ schreef op dinsdag 22 maart 2005 @ 17:44:
Volgens mij doen die toch alleen aanbevelingen?

ja, maar als iedereen die aan z'n laars lapt weet toch helemaal niemand meer hoe ie een webpagina moet bouwen cq weergeven cq indexeren.

Het is handig als een p voor een alinea blijft en niet in een keer een link kan zijn ofzo

[ Voor 27% gewijzigd door Verwijderd op 22-03-2005 17:47 ]

[HyperioN]

PaulZ schreef op dinsdag 22 maart 2005 @ 17:44:
Volgens mij doen die toch alleen aanbevelingen?

Het W3C bepaalt toch ook de doctypes..wat er wel en niet mag in XHTML. Dus volgens mij bepalen die dat zeker wel..dus niet alleen aanbevelingen.

[PaulZ]

Ik ben er ook niet voor om tags te wijzigen, maar volgens mij zijn er meerdere wegen die naar Rome leiden en kan de W3C niet verplicht een route voorschrijven...

[equationunequal]

Gunp01nt schreef op dinsdag 22 maart 2005 @ 17:46:
[...]


Het W3C is niet heilig. Het zal niet de eerste keer zijn dat het W3C behoeften over het hoofd zit die later gecorrigeerd moeten worden, of dat het W3C dingen overneemt die door anderen ontwikkeld zijn (zo is CSS2.1 gedeeltelijk gebaseerd op de Microsoft implementatie van CSS).

Uiteindelijk is het de markt die bepaalt wat goed en fout is. En dan heb ik het niet alleen over webdesigners, maar over browsers en eindgebruikers. Neem nou zoiets als semantiek. Dat is nooit zo sterk door het W3C uitgedragen, en werd pas een issue nadat Google pagina's kwam doorzoeken.

Uiteindelijk is het wel het W3C dat bepaald of je code valide is of niet...

PaulZ schreef op dinsdag 22 maart 2005 @ 17:51:
Ik ben er ook niet voor om tags te wijzigen, maar volgens mij zijn er meerdere wegen die naar Rome leiden en kan de W3C niet verplicht een route voorschrijven...

True, maar die aanbevelingen doen ze niet voor niets. Er zijn genoeg redenen om tables niet voor lay-out te gebruiken. Natuurlijk kan je dan gewoon lekker stug je eigen gang gaan en je site opmaken met tables, alleen ben je dan dus zelf 100% verantwoordelijk voor de problemen die dat met zich mee kan brengen...

"hate to say I told you so" idee zeg maar...

[ Voor 33% gewijzigd door equationunequal op 22-03-2005 17:55 ]

[Verwijderd]

Het W3C is niet heilig. Het zal niet de eerste keer zijn dat het W3C behoeften over het hoofd zit die later gecorrigeerd moeten worden, of dat het W3C dingen overneemt die door anderen ontwikkeld zijn (zo is CSS2.1 gedeeltelijk gebaseerd op de Microsoft implementatie van CSS).

En gedeeltelijk op de van andere browsers. CSS2 zit theoretisch nog in CR fase waar de schrijvers wachten op feedback van diegene die de specificatie implementeren zodat deze verbeterd kan worden. CSS2.1 is daar het resultaat van.

[Verwijderd]

Het is handig als een p voor een alinea blijft en niet in een keer een link kan zijn ofzo

Het is dat Mozilla XLink niet volledig ondersteund, maar anders zou dat goed mogelijk zijn.

(Dat maakt het theoretisch uiteraard nog steeds mogelijk, maar minder overtuigend.)

[ Voor 19% gewijzigd door Verwijderd op 22-03-2005 17:56 ]

[Not Pingu]

Hankey schreef op dinsdag 22 maart 2005 @ 17:52:
Uiteindelijk is het wel het W3C dat bepaald of je code valide is of niet...

Correctie: het W3C bepaalt of je code valide is volgens het W3C. Maar ik denk niet dat dat het punt is in dit topic. Het gaat er niet om of je tags goed afsluit of bijv. geen <p> tags tussen <select /> hebt, het gaat erom waarvoor je bepaalde elementen gebruikt. Daar kan de W3C validator je sowieso niks over zeggen, omdat ie nou eenmaal niet je inhoud kan beoordelen en dus niet kan zien waarvoor je elk element gebruikt.

[Verwijderd]

Maar het ging hier niet om de validator. Het ging hier om het correct volgen van de specificaties zodat je document valide wordt.

[equationunequal]

Gunp01nt schreef op dinsdag 22 maart 2005 @ 17:57:
[...]


Correctie: het W3C bepaalt of je code valide is volgens het W3C. Maar ik denk niet dat dat het punt is in dit topic. Het gaat er niet om of je tags goed afsluit of bijv. geen <p> tags tussen <select /> hebt, het gaat erom waarvoor je bepaalde elementen gebruikt. Daar kan de W3C validator je sowieso niks over zeggen, omdat ie nou eenmaal niet je inhoud kan beoordelen en dus niet kan zien waarvoor je elk element gebruikt.

Ik zou ook best een validator in elkaar kunnen schroeven en dan code volgens mijn manier kunnen controleren en valideren, alleen heb ik totaal geen authoriteit op dat gebied en het W3C wel...

Maargoed, /off-topic

[Verwijderd]

HTML is uitgevonden om van stukken van je document te zeggen wat het is, zodat het in principe door elke interpreter te begrijpen valt.

als jij niet goed aangeeft wat bepaalde stukken zijn (een hele pagina is gewoon geen tabel), dan vallen bepaalde interpreters daarover. Iemand die je website op een normale browser bekijkt misschien niet, omdat het er hetzelfde uitziet, maar een speechsyntesizer begint bijvoorbeeld de tabelcellen op te reutelen (waar vervolgens geen hout van te begrijpen valt)

ook indexers als google snappen dat een h1 belangrijker is dan een <p><b><font size="18">lala</font></b></p> constructie en indexeren het daardoor. Als jij geen hx voor kopjes gebruikt hebben bepaalde interpreters daar gewoon last van

jouw keuze of je dat erg vind of niet

[Alex)]

De CSS van de W3C-site is anders niet valid, de XHTML wel:
http://jigsaw.w3.org/css-...i=http%3A%2F%2Fwww.w3.org
http://validator.w3.org/check?uri=http://www.w3.org

[Verwijderd]

De CSS van de W3C-site is anders niet valid, ...

Dus als het W3C in de sloot springt..? (Doorgegeven overigens.)

[Clay]

Als je een spijker in de muur slaat zijn er een paar "best practices" die je kan volgen om dat een beetje handig te doen; houd het handvat bv laag vast om goeie krachtige slagen te kunnen maken. Met pianospelen is er voor elk stuk een bepaalde vingerzetting die het beste uitkomt; gebruik die dan dus ook. En als je leert autorijden haal je het ook niet in je hoofd om zelf even te bepalen hoe je dat gaat doen. Zo bestaan er bij het developen van software ook ontelbare van deze best practices die zich door de jaren heen bewezen hebben als "goed", of iig beter dan alle andere opties en HTML is hierbij geen uitzondering.

Er zijn al zo veel mensen die eerder hun hoofd aan diezelfde steen gestoten hebben. Zij hebben toen door schade en schande voor jou en alle anderen bepaald (of liever "ontdekt") wat goed is en je kan dan inderdaad eigenwijs zijn en toch je eigen manier proberen, maar vaak zal het dan logischerwijs tegenvallen.

Soms is daar dan die "stroke of genius" en word je een held. Experimenteren is prima, maar je zou pas moeten gaan spelen met je feiten als je ze allemaal op een rijtje hebt, en juist dan levert experimenteren ook meer op. Misschien moeten ze dat eens uitleggen op scholen, waar je naar mijn mening dus terecht nog niets op je eigen manier mag doen.

[Blauw]

Ik wil hier nog wel even een verhaaltje aan toevoegen.

Ik zit nu in het tweede jaar van een HBOcommunicatie opleiding waar ze (niet ik, want vrijstelling) nu met dreamweaver een website gaan ontwikkelen. Maar dat mag volgens de leraar dan weer niet met tabellen maar kan (volgens hem) veel beter met frames. Gevolg: iedereen zit te knoeien met framesets, met het feit dat je moet begrijpen dat 1 frameset de hele boel bij elkaar houdt en snapt niet dat er nu ineens 4 pagina's nodig zijn voor het vormen van 1 pagina. Dan denk ik: dat is dus jammer, want hadden we in de zeven beschikbare weken nou tijd gestoken in het logisch opbouwen van pagina's mbv. css dan was iedereen nu een stuk verder geweest. Niet alleen omdat het 'hipper' is om alles te doen met CSS, maar imo ook veel logischer.

[alienfruit]

CSS en XHTML kost alleen maar geld, kost meer tijd dan wanneer een website opbouwt met tabellen. Vooral omdat er altijd verschillen zit tussen de browsers zoals IE/Mac of Firefox en Opera. Ik ben gestopt met die XHTML+CSS onzin, als de klant ervoor wil betalen okay, maar anders mooi de oude manier.

[JHS]

De specificaties zijn misschien wel net zoiets als het ABN. Ook gedefinieerd door een instantie, en er staat nergens dat je niet in een (evt. zelf verzonnen) dialect mag gaan praten. ABN praten heeft echter zijn voordelen. Iedereen begrijpt wat je bedoelt, en dan in een hele brede zin, in een ideale wereld, het kan vertaalt worden naar andere talen, etcetera.

Maar natuurlijk is het wel zo dat "als het werkt, dan werkt het". Je moet je alleen afvragen of je door je layout in tables op de bouwen (bijvoorbeeld) het wel werkt. Zie de bekende problemen met screenreaders, indexing, etcetera, mensen uit de grote stad begrijpen niet waar je het over hebt als je in je dialectje praat. Soms is het echter best je eigen dialect te praten, in je eigen dorp waar iedereen in dat dialect praat bijvoorbeeld, of als je een boek schrijft wat helemaal niet interressant is voor mensen uit andere dorpen.

Je hebt echter om het ABN mogelijk te maken gewoon een instantie nodig die op een gegeven moment bepaald hoe het "moet", anders blijft iedereen "aanmodderen".

[Erkens]

alienfruit schreef op dinsdag 22 maart 2005 @ 19:19:
CSS en XHTML kost alleen maar geld, kost meer tijd dan wanneer een website opbouwt met tabellen. Vooral omdat er altijd verschillen zit tussen de browsers zoals IE/Mac of Firefox en Opera. Ik ben gestopt met die XHTML+CSS onzin, als de klant ervoor wil betalen okay, maar anders mooi de oude manier.

komt eerder door een gebrek aan kennis dat het meer geld/tijd kost

[equationunequal]

alienfruit schreef op dinsdag 22 maart 2005 @ 19:19:
CSS en XHTML kost alleen maar geld, kost meer tijd dan wanneer een website opbouwt met tabellen. Vooral omdat er altijd verschillen zit tussen de browsers zoals IE/Mac of Firefox en Opera. Ik ben gestopt met die XHTML+CSS onzin, als de klant ervoor wil betalen okay, maar anders mooi de oude manier.

Als je het goed doet kost het minder tijd & geld en is de website als resultaat een stuk toegankelijker ...

_{spuit 11 voortaan eerst refreshen...}

[ Voor 6% gewijzigd door equationunequal op 22-03-2005 19:35 ]

[JHS]

alienfruit schreef op dinsdag 22 maart 2005 @ 19:19:
CSS en XHTML kost alleen maar geld, kost meer tijd dan wanneer een website opbouwt met tabellen. Vooral omdat er altijd verschillen zit tussen de browsers zoals IE/Mac of Firefox en Opera. Ik ben gestopt met die XHTML+CSS onzin, als de klant ervoor wil betalen okay, maar anders mooi de oude manier.

Dat is dus niet zo. IE/Max is inderdaad niet helemaal optimaal, om het zo maar te noemen, maar het brengt wel degelijk tijds- en andere besparingen met zich mee. Zeker CSS. Of je nu één bestand moet aanpassen, of tientallen. En of je een layoutwijziging aanbrengt door in één bestand bijvoorbeeld een element te laten floaten, of dat je in tientallen bestanden tabellen moet gaan nesten. En CSS en valide HTML (4) gaan nu eenmaal goed samen. Het brengt bovendien de andere voordelen van toegankelijkheid en vindbaarheid met zich mee. Ik ben misschien wel met je eens dat perfecte validatie leuk is, maar niet echt essentieel, een balans moet altijd aanwezig zijn. Maar om het af te schrijven als onzin is veel te straf, m.i.

[PaulZ]

Gunp01nt schreef op dinsdag 22 maart 2005 @ 17:57:
[...]
... Het gaat er niet om of je tags goed afsluit of bijv. geen <p> tags tussen <select /> hebt, het gaat erom waarvoor je bepaalde elementen gebruikt.

Dank je: dat was dus mijn gedachte.

Verwijderd schreef op dinsdag 22 maart 2005 @ 18:03:
HTML is uitgevonden om van stukken van je document te zeggen wat het is, zodat het in principe door elke interpreter te begrijpen valt...een speechsyntesizer begint bijvoorbeeld de tabelcellen op te reutelen (waar vervolgens geen hout van te begrijpen valt)
jouw keuze of je dat erg vind of niet

Goede opmerking.

Misschien dat we met z'n allen nog eens naar dit topic kunnen verwijzen als er weer eens (beginnende) bouwers worden afgez*ken door 'profi's'...
Ik ben het er mee eens dat pagina's op zoveel mogelijk platformen moeten draaien, maar realiseer me ook dat dit niet door iedereen haalbaar is. Moet je mensen dan maar verplichten om te stoppen met bouwen? Denk 't niet. Helpen en aanwijzingen geven: jazeker! Dit was ook één van de redenen om dit topic te starten: Ik erger me aan die 'in-de grond-trap' en 'ik-weet-het-beter' houding van posters in diverse fora.

[rapture]

Blauw schreef op dinsdag 22 maart 2005 @ 18:51:
Ik zit nu in het tweede jaar van een HBOcommunicatie opleiding waar ze (niet ik, want vrijstelling) nu met dreamweaver een website gaan ontwikkelen. Maar dat mag volgens de leraar dan weer niet met tabellen maar kan (volgens hem) veel beter met frames. Gevolg: iedereen zit te knoeien met framesets, met het feit dat je moet begrijpen dat 1 frameset de hele boel bij elkaar houdt en snapt niet dat er nu ineens 4 pagina's nodig zijn voor het vormen van 1 pagina. Dan denk ik: dat is dus jammer, want hadden we in de zeven beschikbare weken nou tijd gestoken in het logisch opbouwen van pagina's mbv. css dan was iedereen nu een stuk verder geweest. Niet alleen omdat het 'hipper' is om alles te doen met CSS, maar imo ook veel logischer.

Ik herken dat, ik heb het geluk om Graduaat MCT in Kortrijk (beste admin- en webmasteropleiding in België) te studeren. Bij Graduaat informatica in Antwerpen moeten ze, framesets en andere html 4.0 brolcode (inclusief <FONT COLOR=RED> toestanden) typen. En ze mogen geen CSS gebruiken, want dat wordt pas in de volgende semester gegeven .

Lang geleden was de eerste grafische browser "Mosaic" voor het grote publiek, hiervan is Netscape afgeleid. MS geloofde toen in hun MS Network ipv Internet, ze waren bezig met hun eigen "Internet" aan het uitvinden. Na een tijdje hebben ze door dat de wereld voor Internet koos en MS steekt IE in hun Windows 95 zodat iedereen standaard IE op hun computer krijgt. In deze tijdperk was er een "browseroorlog", Netscape en MS brachten steeds nieuwe eigen features uit met als gevolg dat er Netscape-HTML en MS-HTML ontstaat. Zodat webmasters moeilijkheden krijgen om sites te maken die met de beide browsers werken.

Tim Berners-Lee (uitvinder van het WWW en HTML) zag dat het niet goed was en richt het W3C om de standaard-HTML te maken. W3C kan alleen aanbevelingen doen, want ze kunnen niemand dwingen om valid HTML te coden. Dankzij een standaard-HTML zou het mogelijk zijn om 1 site te maken die met alle valid browsers werken. In praktijk blijft IE het minst valid te zijn.

Lay-out moet volgens xhtml 1.0 met div-positioneren met CSS gebeuren. Tabellen werden vroeger misbruikt om een lay-out op te bouwen. Frameset is een oerlelijke oplossing, je ziet altijd de scheidingslijnen tussen de frames (dankzij bug-abusing in IE kon je deze lelijke lijnen verstoppen, maar in Mozilla-achtigen zie je het direct).

Het grote voordeel van CSS is dat je op 1 plaats iets moet veranderen en heel je site wordt aangepast. Als je in CSS de positie van bv een banner verandert, dan is het voor alle pagina's aangepast. Terwijl je bij tabellen in elke pagina de tabellen kan gaan aanpassen.

[ Voor 6% gewijzigd door rapture op 22-03-2005 20:44 ]

[AtleX]

alienfruit schreef op dinsdag 22 maart 2005 @ 19:19:
CSS en XHTML kost alleen maar geld, kost meer tijd dan wanneer een website opbouwt met tabellen. Vooral omdat er altijd verschillen zit tussen de browsers zoals IE/Mac of Firefox en Opera. Ik ben gestopt met die XHTML+CSS onzin, als de klant ervoor wil betalen okay, maar anders mooi de oude manier.

Ik geef meteen toe dat het meer tijd kost, maar dat ligt voor een gedeelte aan de ranzige bugs in een aantal UA die gewoon overblijfselen zijn van de browserwar van een aantal jaren geleden. Als je goed nadenkt en van het begin af aan je code goed opbouwt kom je er wel uit. Voor mijn website (niet het moeilijkste design, dat geef ik meteen toe) had ik binnen 9 uur een nieuw design gemaakt, inclusief schetsen en wat gepruts. Het langste werk had ik aan weer zo'n klote lijntje dat nergens in verscheen (en niet mocht verschijnen) behalve in IE. Nu wil ik niet meteen zeggen dat de overige browsers heilig zijn, maar het feit is gewoon dat je het meeste rekening moet houden met de soms onvoorspelbare acties van Internet Explorer.

Ook zit je natuurlijk een beetje met de ondersteuning van oudere UA's, ik heb voor mijn eigen website gewoon ondersteuning van IE6 en FF1 aangehouden, dat het in Opera werk is mooi meegenomen. Dat kan ik voor mezelf wel aanhouden, maar bij een klant hoef ik niet te zeggen "schitterende website meneer, met de nieuwste technieken gemaakt. Alleen kan 60% van uw bezoekers 'm niet meer fatsoenlijk bezoeken". Dan wordt ik met een keiharde schop terug naar mijn PC gestuurd om die problemen op te lossen.

[crisp]

alienfruit schreef op dinsdag 22 maart 2005 @ 19:19:
CSS en XHTML kost alleen maar geld, kost meer tijd dan wanneer een website opbouwt met tabellen. Vooral omdat er altijd verschillen zit tussen de browsers zoals IE/Mac of Firefox en Opera. Ik ben gestopt met die XHTML+CSS onzin, als de klant ervoor wil betalen okay, maar anders mooi de oude manier.

Voor het eenmalig opzetten van een site kost het je wellicht minder tijd; zeker als je WYSIWYAG programma's gebruikt. Je hoeft inderdaad minder met browser-quirks/bugs/tekortkomingen rekening te houden.
Maar als je achteraf eens iets wilt gaan wijzigen ben je in eens weer 10 keer zo lang bezig om in de (gegenereerde) spaghetti-code dat ene kleine dingetje aan te passen zonder dat je hele structuur ineens van geen kant meer klopt. Daarnaast zijn table-layouts star.

Goed gebruik van CSS is een kwestie van veel oefening, en oefening kost tijd maar baart ook kunst. Ik denk dat ik tegenwoordig net zo snel een layout met goed gebruik van elementen en CSS in elkaar zet als 5 jaar geleden dezelfde layout met tabellen. Daarbij moet ik wel zeggen dat ik me weinig moeite meer getroost om de echte oeroude browsers nog te ondersteunen (en dan bedoel ik ook browsers als IE 5.0 en Mac/IE).

[PaulZ]

crisp schreef op dinsdag 22 maart 2005 @ 20:31:
[...]
Maar als je achteraf eens iets wilt gaan wijzigen ben je in eens weer 10 keer zo lang bezig om in de (gegenereerde) spaghetti-code dat ene kleine dingetje aan te passen zonder dat je hele structuur ineens van geen kant meer klopt.

Maar als iemand dat voor lief neemt (en die moeite dan maar moet doen) wie zegt dan dat dat zijn/haar aanpak fout is?

[Verwijderd]

PaulZ schreef op dinsdag 22 maart 2005 @ 20:35:

Maar als iemand dat voor lief neemt (en die moeite dan maar moet doen) wie zegt dan dat dat zijn/haar aanpak fout is?

Als iemand dat voor lief neemt, waarom opent die iemand dan een topic in W&G?

[Verwijderd]

Lay-out moet volgens xhtml 1.0 met div-positioneren met CSS gebeuren.

Of XHTML zo'n goed is idee valt nog te bezien. (Voor gebruik van de user interface dan.)

[crisp]

PaulZ schreef op dinsdag 22 maart 2005 @ 20:35:
[...]

Maar als iemand dat voor lief neemt (en die moeite dan maar moet doen) wie zegt dan dat dat zijn/haar aanpak fout is?

Wanneer noem je iets goed of fout? Bepaalde technieken, zoals CSS, worden uitgevonden met een doel. Natuurlijk kan je 20 jaar na de uitvinding van de freesmachine nog prima met hamer en bijtel je decoraties op een stuk paneel maken, maar of dat ook het handigst is... zeker als je een freesmachine tot je beschikking hebt.

[PaulZ]

Cheatah: 'Die iemand' (en ik neem aan dat je mij persoonlijk bedoelt ) opende dit topic zoals eerder aangegeven mede gezien het feit dat ik me af en toe erger "aan die 'in-de grond-trap' en 'ik-weet-het-beter' houding van posters in diverse fora". Ik vroeg me af: "Wie heeft deze wijsheid in pacht?" That's all.....

[ Voor 40% gewijzigd door PaulZ op 23-03-2005 15:45 ]

[alienfruit]

Maar als je achteraf eens iets wilt gaan wijzigen ben je in eens weer 10 keer zo lang bezig om in de (gegenereerde) spaghetti-code dat ene kleine dingetje aan te passen zonder dat je hele structuur ineens van geen kant meer klopt. Daarnaast zijn table-layouts star.

Nee hoor, als je gebruik maakt van een template engine zoals preHTML is dat met een druk op de knop gebeurd

[Verwijderd]

PaulZ schreef op dinsdag 22 maart 2005 @ 20:46:
(en ik neem aan dat je mij persoonlijk bedoelt )

Als je topics opent met tabel-layout gerelateerde vragen wel ja.

Creator Failure: 'Die iemand' opende dit topic zoals eerder aangegeven mede gezien het feit dat ik me af en toe erger "aan die 'in-de grond-trap' en 'ik-weet-het-beter' houding van posters in diverse fora". Ik vroeg me af: "Wie heeft deze wijsheid in pacht?" That's all.....

Er zijn wel meer mensen die zich daaraan ergeren, volgens mj zijn dat voornamelijk mensen die zelf die technieken niet goed beheersen. Als je je ergert aan stellingen van anderen moet je met tegenargumenten komen, om die anderen op hun plek te zetten.

offtopic:
Sommige argumenten zijn echter al zo vaak gegeven, dat niemand nog veel zin heeft om dat naar boven te halen.

Discussies voeren doe je nu eenmaal met argumenten, daartoe kan je desnoods de kennis of ervaring van de anderen ter discussie stellen, en dat gebeurt hier dan ook regelmatig.

[Clay]

Om er nog maar een paar "uit de hoogte" omlaag te gooien;
Met CSS developen is sneller dan met tables developen en is beter te onderhouden. Alleen je mate van kennis is hierop van invloed. Als ik ga php'en duurt dat ook lang, ik kan het namelijk niet. Template systemen die tables uitpoepen (zoals preHTML blijkbaar) doen ook niets meer dan een foute aanpak automatiseren. Al is het nog zo mooi, het blijft fout.

Clientside developen is zoals zoveel vaardigheden iets wat tijd kost om onder de knie te krijgen, en dat strookt natuurlijk niet met de ongeduldige aard van de mens. Dat het zo'n toegankelijke verzameling van technieken is - die er stuk voor stuk best makkelijk uitzien - trekt een heleboel eigenwijze mensen aan die het na 1 dag al beter denken te weten dan de specialisten die zich jarenlang in alle aspecten ervan verdiept hebben.

Voor deze specialisten kan het dan wat frustrerend zijn om mensen te zien zitten met problemen die je niet zou hebben als je wist waar je mee bezig was, en die vervolgens ook nog het vakgebied moeten verdedigen tegen vooroordelen die erover onstaan uit a) dat soort onwetendheid en b) de bugrijke implementaties die hieruit voortkomen. Mensen geven namelijk alles liever de schuld dan henzelf.

Het bovenstaande verhaal gebruik ik natuurlijk niet als ik mensen ergens van probeer te overtuigen, aangezien je hiermee mensen eerder tegen je in het harnas jaagt. Ik geloof in een discussie met argumenten (die dan niet zoals hierboven aanstoot geven), en in het enthousiasmeren van mensen door uit te leggen waarom iets op een bepaalde manier zou moeten werken. Ik vind niet dat je je als specialist schuldig hoeft te voelen om je kennis, als een beginner vindt dat je daarmee "uit de hoogte doet". Tenzij je dat echt aan het doen bent - en dat valt in voorkomend geval echt wel op - zijn dat onzinnige beschuldigingen die geen waarde toevoegen en enkel bedoeld zijn om de discussie dood te slaan; zoals de D66 die mensen achterlijk en ouderwets noemt als ze tegen de verkozen burgermeester zijn, of amerikanen die euthanasie met de holocaust vergelijken.

[Verwijderd]

Die smiley doet het hem ...

[Verwijderd]

Een vrachtwagenchauffeur stapt voor de gein eens in een straaljager. Hij zit in de cockpit maar begrijpt het niet zo goed... Waar is het gaspedaal? En het stuur?

Na veel geploeter krijgt hij beweging in het ding en taxiet een half uurtje over het vliegveld.

Als hij uitstapt zegt hij: "Het ziet er wel leuk uit, zo'n straaljager, maar m'n vrachtwagen is sneller".

[PaulZ]

Cheatah: dank voor jouw reacties. Ik voel me hierdoor wederom enigszins in een hoekje gezet. Ik ga er maar van uit dat ik het anders opvat dan jouw bedoeling is.
Clay: een zinnig betoog voor een mooie afsluiting! Daar kan ik me bij aansluiten.

Misschien moeten we langzamerhand maar een einde breien aan dit topic voordat 't verzand in minder terzake doende reacties. Dank allen

[ Voor 8% gewijzigd door PaulZ op 23-03-2005 15:45 ]

[Erkens]

Verwijderd schreef op woensdag 23 maart 2005 @ 12:48:
Een vrachtwagenchauffeur stapt voor de gein eens in een straaljager. Hij zit in de cockpit maar begrijpt het niet zo goed... Waar is het gaspedaal? En het stuur?

Na veel geploeter krijgt hij beweging in het ding en taxiet een half uurtje over het vliegveld.

Als hij uitstapt zegt hij: "Het ziet er wel leuk uit, zo'n straaljager, maar m'n vrachtwagen is sneller".

Beetje een rare vergelijking, want dat zijn twee totaal verschillende dingen, met tevens allebei een ander doel

[raptorix]

Hankey schreef op dinsdag 22 maart 2005 @ 17:52:
[...]


Uiteindelijk is het wel het W3C dat bepaald of je code valide is of niet...

En als vervolgens je browser die code niet goed interpreteerd kan je weer een discussie hebben over of de browser het fout doet, of W3C. Het hele punt is dat er niet echt een "officieele standaard" is, zoals je bijvoorbeeld voor SQL wel officieele standaarden hebt waar je aan kan toetsen.

[Verwijderd]

Verwijderd schreef op woensdag 23 maart 2005 @ 12:48:

Dit soort vergelijkingen horen thuis in de lunch ..

[Verwijderd]

Erkens schreef op woensdag 23 maart 2005 @ 13:04:
Beetje een rare vergelijking, want dat zijn twee totaal verschillende dingen, met tevens allebei een ander doel

Wie bepaalt dat doel, dat is toch de bestuurder van het geval? Nu, de chauffeur wilde rijden, ... doel bereikt toch?

[BtM909]

PaulZ schreef op woensdag 23 maart 2005 @ 13:03:
Creator Failure: dank voor jouw reacties. Ik voel me hierdoor wederom enigszins in een hoekje gezet. Ik ga er maar van uit dat ik het anders opvat dan jouw bedoeling is.

Die beste man heet geen Creator Failure hoor.

[alienfruit]

Wie zegt dat preHTML gebruikt maakt van tabellen? Het is gewoon makkelijk om snel iets aan te passen om een site bijv. een header. Je hoeft dan alleen een Rebuild te doen en uploaden maar klaar is kees

[Erkens]

Verwijderd schreef op woensdag 23 maart 2005 @ 13:46:
[...]


Wie bepaalt dat doel, dat is toch de bestuurder van het geval? Nu, de chauffeur wilde rijden, ... doel bereikt toch?

een vliegtuig is niet gemaakt om alleen maar wat te rijden, dacht dat dat toch wel algemeen bekend was, maar blijkbaar bij sommige personen nog niet

[BtM909]

Erkens schreef op woensdag 23 maart 2005 @ 14:15:
[...]

een vliegtuig is niet gemaakt om alleen maar wat te rijden, dacht dat dat toch wel algemeen bekend was, maar blijkbaar bij sommige personen nog niet

Als we de analogie maar even down-to-web-earth brengen... Jij denkt dat Tables wel voor layout nodig zijn

[Erkens]

BtM909 schreef op woensdag 23 maart 2005 @ 14:21:
[...]

Als we de analogie maar even down-to-web-earth brengen... Jij denkt dat Tables wel voor layout nodig zijn

nee, maar HTML is HTML, vergelijk dan een auto en een vrachtwagen, met allebei kan je rijden en spullen vervoeren, alleen wel een ander doel Met de een kan je eenvoudig (grote) spullen mee nemen dan de ander

[BtM909]

Erkens schreef op woensdag 23 maart 2005 @ 14:24:
[...]

nee, maar HTML is HTML, vergelijk dan een auto en een vrachtwagen, met allebei kan je rijden en spullen vervoeren, alleen wel een ander doel Met de een kan je eenvoudig (grote) spullen mee nemen dan de ander

eehhh, een vrachtwagen en een vliegtuig zijn beide voertuigen hoor . Maar laten we maar geen discussie beginnen over vliegtuigen, aangezien we nog steeds in WG zitten

Ik vind alleen die vergelijking wel treffend, want je kan beide methoden gebruiken om een doel te bereiken. De vraag is (en dat antwoord geef je stiekem zelf ook al ) of de methode wel zaligmakend voor je doel is

[Erkens]

BtM909 schreef op woensdag 23 maart 2005 @ 14:27:
[...]

eehhh, een vrachtwagen en een vliegtuig zijn beide voertuigen hoor . Maar laten we maar geen discussie beginnen over vliegtuigen, aangezien we nog steeds in WG zitten

ehm, een vliegtuig is, ja een vliegtuig en geen voertuig.

voer·tuig (het ~)
1 vervoermiddel met wielen of glijvlakken voor het vervoer over land van personen en goederen => vehikel

vervoer over land dus, een vliegtuig is daar niet voor gemaakt.
net zoiets als appels met peren vergelijken als je een appelsmaak wilt hebben
[/offtopic]

Ik vind alleen die vergelijking wel treffend, want je kan beide methoden gebruiken om een doel te bereiken. De vraag is (en dat antwoord geef je stiekem zelf ook al ) of de methode wel zaligmakend voor je doel is

nou opzich klopt de vergeljiking wel in dat opzicht dat je moet gebruiken waar het voor is gemaakt, maar dit topic gaat over correctheid van HTML, niet over een HTML of een Flash site

[BtM909]

Erkens schreef op woensdag 23 maart 2005 @ 14:32:
[...]

ehm, een vliegtuig is, ja een vliegtuig en geen voertuig.
vervoer over land dus, een vliegtuig is daar niet voor gemaakt.
net zoiets als appels met peren vergelijken als je een appelsmaak wilt hebben
[/offtopic]

offtopic:
Ik bedoelde ook een vervoersmiddel Verkeerd getypt

[PaulZ]

BtM909 schreef op woensdag 23 maart 2005 @ 13:48:
[...]
Die beste man heet geen Creator Failure hoor.

Is gewijzigd.

[rapture]

BtM909 schreef op woensdag 23 maart 2005 @ 14:27:
[...]

eehhh, een vrachtwagen en een vliegtuig zijn beide voertuigen hoor . Maar laten we maar geen discussie beginnen over vliegtuigen, aangezien we nog steeds in WG zitten

Ik vind alleen die vergelijking wel treffend, want je kan beide methoden gebruiken om een doel te bereiken. De vraag is (en dat antwoord geef je stiekem zelf ook al ) of de methode wel zaligmakend voor je doel is

Een vliegtuig is gemaakt om te vliegen en een vrachtwagen om te rijden. Het is idd mogelijk om een vliegtuig te misbruiken om mee te rijden, maar iedereen is eens dat een vliegtuig dient om mee te vliegen.

Tabellen zijn gemaakt om gegevens in te steken, terwijl CSS gemaakt is voor de layout en opmaak. Dus geen tabellen misbruiken om layout van een site te maken.

[Erkens]

rapture schreef op woensdag 23 maart 2005 @ 18:34:
Tabellen zijn gemaakt om gegevens in te steken, terwijl CSS gemaakt is voor de layout en opmaak. Dus geen tabellen misbruiken om layout van een site te maken.

Je haalt hier wat door elkaar denk ik.
Tabellen zijn idd gemaakt om gegevens weer te geven, maar een stukje tekst is ook iets wat onder "gegevens" gestopt kan worden.
Tabellen zijn voor tabulaire data, bijvoorbeeld gegevens die je ook in een spreadsheet programma zal zetten. (nu maar hopen dat niet iedereen een spreadsheet programma gebruikt om tekst documenten mee te maken )
CSS is niet voor de layout van een document, CSS bepaald alleen hoe het eruit komt te zien, hoe de kopjes weergegeven worden, hoe de alinea's er uit zien, en zelfs hoe de gegevens in je tabellen op het scherm (of printer etc) moeten verschijnen

[equationunequal]

raptorix schreef op woensdag 23 maart 2005 @ 13:15:
[...]


En als vervolgens je browser die code niet goed interpreteerd kan je weer een discussie hebben over of de browser het fout doet, of W3C. Het hele punt is dat er niet echt een "officieele standaard" is, zoals je bijvoorbeeld voor SQL wel officieele standaarden hebt waar je aan kan toetsen.

Het W3C is echter wel een de facto standaard organisatie, dus algemeen geaccepteerd als standaard zonder dat het daadwerkelijk een officiele standaard is (net als bv. PDF een de facto standaard is voor drukwerk)... HTML is overigens weer wel een officiele (ISO) standaard...

_{HTML ISO}

Btw leuk dat je SQL als officiele standaard noemt, aangezien daar ook veel verschillende versies van zijn. De SQL die ik gebruik voor mijn MySQL db is iets anders dan de code voor bv. een Sybase db...

[ Voor 13% gewijzigd door equationunequal op 23-03-2005 19:51 ]

[BalusC]

Wat betreft het gebruik van tabellen voor tabulaire data: hier ben ik het volkomen mee eens. Maar de div's hebben ook zo hun beperkingen, zeker bij mijn website die gebruik maakt van een 3-koloms layout met een flexibele breedte van de middelste kolom. Wellicht ben ik op dat punt een mierenneuker, maar ik stel graag strenge eisen aan de basislayout van een website. Het hele verhaal omtrent de afweging tussen div's en een tabel als de basislayout van mijn website kun je hier teruglezen, compleet met online voorbeelden en een linkje naar een eerder WG-topic

[Verwijderd]

BalusC, wat je toevallig via Google vindt hoeft niet goed te zijn. Daarnaast is het natuurlijk zo dat het gewoon een mythe is dat het niet mogelijk is met CSS aangezien er een CSS Table module bestaat. Verder kun je ook dingen als 'min-width' e.d. gebruiken om problemen op te lossen die jij noemt op je pagina.

[BalusC]

Verwijderd schreef op woensdag 23 maart 2005 @ 22:04:
aangezien er een CSS Table module bestaat

Deze kende ik nog niet.

Verder kun je ook dingen als 'min-width' e.d. gebruiken om problemen op te lossen die jij noemt op je pagina.

Dat ga ik zeker ook doen wanneer 1024px zo'n beetje de standaard is qua minimum breedte

[Verwijderd]

CSS heeft zolang essentiele zaken als min-width nog niet worden ondersteund in IE, zijn eigenaardigheden. Bepaalde voorschriften maken het imo ook een stuk complexer dan nodig, bijvoorbeeld het boxmodel wat imo beter by default border-box had kunnen zijn dan content-box, ivm verticale handling van je canvas in geval van padding, en een betere acceptatie/overgang naar standards door de ontwikkelaars. Bij layouts met procentuele waarden in combinatie met padding in een wrap ontkom je niet aan wijzigingen in het box-model (padding-box) alvorens je de layout voor elkaar krijgt in standards compliant browsers.

Overal valt omheen te werken, het een wat onlogischer als het andere, en de ene keer kost het je inderdaad klauwen met tijd en de andere keer ben je in 5 minuten klaar. De enige manier waarmee je dit een beetje in de vingers krijgt is het gebruiken.

[Verwijderd]

De enige manier waarmee je dit een beetje in de vingers krijgt is het gebruiken.

Geld dat niet voor de meeste dingen?

[Verwijderd]

Dat klopt, voor CSS geld dit echter des te meer omdat men meent te kunnen werken volgens een standaard die niet wordt ondersteund, en waarbij er zoveel zaken in browsers naar voren komen mbt slechte implementaties en bugs dat hier veel werken belangrijker wordt dan het lezen van de standaarden. Het blijft niet alleen bij de standaarden, er zitten nog teveel verschillen tussen oa ook de standards ondersteunende browsers.

[Verwijderd]

Een ander probleem is echter dat een groot aantal mensen meent het te kunnen gebruiken zonder het lezen van de standaarden en daardoor bij de verkeerde browsers "bugs" gaat rapporteren.

[Clay]

* Clay helemaal eensch

Op zich maakt het natuurlijk niet uit wat de default boxmodel is, mits je het aan kan passen, en zo zijn er idd nog wel een rits dingen op te noemen.

Margin:auto; bijvoorbeeld centreert een block element met een opgegeven breedte die minder is dan de breedte van zijn parent. De naam "margin" impliceert dit maar minimaal, en bovendien werkt het alleen horizontaal, niet vertikaal. En wat is er logischer? Dat een element dit voor zichzelf regelt? Of dat je voor een parent aangeeft dat alles wat erin zit gecentreerd moet zijn? En wat dan als je daar 1 uitzondering op nodig hebt?

Horizontale controle is redelijk goed uitgewerkt, aan vertikale controle schort het nogal. Maar stel dat jij de specs gaat schijven. Een document loopt van boven naar beneden en kan ontzettend lang worden, je hebt dus wel een "flow" nodig waarin dingen automatisch vertikaal gestapeld worden. Je moet daar ook uit kunnen stappen om bv dingen naast elkaar te zetten of te kunnen laten zweven boven iets anders, en tada, positioning is geboren. Ook leuk; Was het logischer geweest als er een vertical-align en horizontal-align hadden bestaan die - wanneer aan een element toegekend - dat element respectievelijk vertikaal en horizontaal alignen? en zoja, wat gebeurt er dan met de lege ruimte rondom zo'n element? moet je er dan nog steeds dingen naast floaten/positionen, en zoja wat is dan het verschil met een margin gebruiken...

Eigenlijk denk ik dat die specs heel zo slecht niet bedacht zijn. Natuurlijk zitten er eigenaardigheden in en hoef je het niet overal mee eens te zijn, maar de meeste problemen liggen puur bij de implementaties van de browsers, en/of het gebrek daaraan

[Verwijderd]

Het werkt wel verticaal eigenlijk:

Cascading Stylesheet:

foo{
 position:absolute;
 top:0;
 bottom:0;
 margin:auto 0;
 height:200px;
}

[Clay]

Ja, met position:absolute, top, bottom, en niet in IE

[rapture]

Clay schreef op donderdag 24 maart 2005 @ 10:12:
Ja, met position:absolute, top, bottom, en niet in IE

idd, als ik netjes codeer zoals ik het geleerd heb met xhtml 1.0, dan werkt het goed met Firefox en Opera. Terwijl in IE de positionering verkeerd zit, dan moet ik "zwaar prutsen" aan de code om het in IE correct te laten weergeven. Er zijn idd ook webmasters die hard aan de IE ergeren.

[BtM909]

rapture schreef op donderdag 24 maart 2005 @ 10:25:
[...]

idd, als ik netjes codeer zoals ik het geleerd heb met xhtml 1.0, dan werkt het goed met Firefox en Opera. Terwijl in IE de positionering verkeerd zit, dan moet ik "zwaar prutsen" aan de code om het in IE correct te laten weergeven. Er zijn idd ook webmasters die hard aan de IE ergeren.

Mwa, het is maar wat je zwaar prutsen noemt

Ik denk dat het voor velen lastiger is om IE rendered-code om te zetten naar correcte HTML (vergeet die x in de praktijk nog maar ff ) dan andersom

[Verwijderd]

En dan hebben we het pas over markup, dan komen daar bijv. nog de bugs bij in Opera mbt zIndexering op iframes. Heb de laatste versie niet meer getest, dus wellicht zijn ze opgelost.

[Genoil]

Ik vind de 3-koloms CSS-based DIV vs. TABLE layout discussie eerlijk gezegd een beetje een irritant stokpaardje aan het worden van de semantiek-ridders. Ik begrijp de argumenten allemaal wel en heb de meeste voorbeelden van hoe het allemaal eigenlijk moet al zovaak gezien, maar als puntje bij paaltje komt is een 3 koloms * 1 rij TABLE veel simpeler, efficienter en stabieler dan het geklooi met CSS kolommen layout. En natuurlijk komt het allemaal goed met CSS3, IE8.0 etcetera, maar daar gaat het niet altijd om. 90% van mijn klanten heeft schijt aan semantiek, en ik heb zelf helemaal geen tijd om krom te liggen voor een correcte layout in, pak em beet, MacIE5.0.

De originele afkeer van TABLEs is ontstaan uit de tijd dat zelfs margins en paddings met TABLEs nagebootst werden, en dat je van die HTML met Droste effect (TABLE in TABLE in TABLE etc), vooral met veel spacer.gifs, kreeg. Maar dat betekent dus niet dat iets gelijk fout is als je een keer een "master-table" voor je 3 kolommetjes gebruikt, omdat je in korte tijd een stabiele pagina wilt maken die op zoveel mogelijk clients er uitziet zoals bedoeld.

Kortom, het zijn niet alleen standaarden-organisaties en hun aanhangers die bepalen wat en goed/fout is, vaak speelt tijd/geld ook een rol.

[Verwijderd]

Genoil schreef op donderdag 24 maart 2005 @ 11:36:
Ik vind de 3-koloms CSS-based DIV vs. TABLE layout discussie eerlijk gezegd een beetje een irritant stokpaardje aan het worden van de semantiek-ridders. Ik begrijp de argumenten allemaal wel en heb de meeste voorbeelden van hoe het allemaal eigenlijk moet al zovaak gezien, maar als puntje bij paaltje komt is een 3 koloms * 1 rij TABLE veel simpeler, efficienter en stabieler dan het geklooi met CSS kolommen layout. En natuurlijk komt het allemaal goed met CSS3, IE8.0 etcetera, maar daar gaat het niet altijd om. 90% van mijn klanten heeft schijt aan semantiek, en ik heb zelf helemaal geen tijd om krom te liggen voor een correcte layout in, pak em beet, MacIE5.0.

De originele afkeer van TABLEs is ontstaan uit de tijd dat zelfs margins en paddings met TABLEs nagebootst werden, en dat je van die HTML met Droste effect (TABLE in TABLE in TABLE etc), vooral met veel spacer.gifs, kreeg. Maar dat betekent dus niet dat iets gelijk fout is als je een keer een "master-table" voor je 3 kolommetjes gebruikt, omdat je in korte tijd een stabiele pagina wilt maken die op zoveel mogelijk clients er uitziet zoals bedoeld.

Kortom, het zijn niet alleen standaarden-organisaties en hun aanhangers die bepalen wat en goed/fout is, vaak speelt tijd/geld ook een rol.

Je haalt wat door elkaar. Uiteindelijk zijn het *wel* de standaarden-organisaties die bepalen wat goed of fout is. Het gebruik van een "master-tabel" voor een 3 kolommen design is even fout als tien tabellen in elkaar nesten; tabellen zijn daar namelijk niet voor bedoeld.
In een tabel zet je - zoals zo vaak gezegd - tabulaire data. Omdat jij te weinig kennis hebt van CSS veroordeel je de standaarden maar tot de dood. Niet het bedrijfsleven bepaalt wat goed of fout is. Bovendien is er al vaak naar boven gekomen dat de css goeroes een site evensnel bouwen. Misschien is de leercurve groot, maar het is niet onmogelijk.

[raptorix]

Sinds enige tijd werk ik met Macromedia Flex, hoewel het niet te vergelijk is met HTML (Flex genereert Flash) is het visuele Data Model super fijn om mee te werken. Zo heeft het Boxmodel een width, min width, max width en iets van optimal width. Wat ook een groot nadeel van HTML/CSS is dat bepaalde zaken niet ondersteunt worden, zo is het stylen van Dropdowns nog steeds een ramp. Een ander groot probleem met HTML is dat de interface set nog steeds vrij beperkt is. Als ontwikkelaar/designer moet je toch vaak allerlei kunstgrepen uithalen om zaken voor elkaar te krijgen.

[Verwijderd]

Verwijderd schreef op donderdag 24 maart 2005 @ 12:41:

Er zijn bepaalde zaken momenteel niet mogelijk in CSS die wel mogelijk zijn met tables, puur door het ontbreken van bijv. display:table-cell; of missende support van auto margins in IE.

Zoals het centreren van meerdere inline element achter elkaar in een relative wrapper. Met tables een fluitje van een cent, met de huidige support van css nog niet mogelijk. Css guru of niet, het is nog niet mogelijk Vanuit zulke zaken kies je dan gewoon voor een table, dan ga je inderdaad niet moeilijk doen. Zodra de support er wel is ga je refactoren.

[edwinistrator]

wie bepaalt eigelijk wat goed en fout is?

my point of view:

Dat zijn volgens mij meerdere factoren:
1. idd het w3c, zij bepalen de regeletjes
2. jij zelf bepaalt wat je wel of niet goed vind (met in gedachte de regetjes van w3c)
3. de gebruiker, als je code perfect xhtml-strict is, maar het werkt niet in ie5.0 browser van de gebruiker zal hij zeggen dat het niet goed is.

Dus volgens mij is het een mix van deze 3.

[Buffy]

Verwijderd schreef op donderdag 24 maart 2005 @ 12:41:
[...]


Je haalt wat door elkaar. Uiteindelijk zijn het *wel* de standaarden-organisaties die bepalen wat goed of fout is. Het gebruik van een "master-tabel" voor een 3 kolommen design is even fout als tien tabellen in elkaar nesten; tabellen zijn daar namelijk niet voor bedoeld.
In een tabel zet je - zoals zo vaak gezegd - tabulaire data. Omdat jij te weinig kennis hebt van CSS veroordeel je de standaarden maar tot de dood. Niet het bedrijfsleven bepaalt wat goed of fout is. Bovendien is er al vaak naar boven gekomen dat de css goeroes een site evensnel bouwen. Misschien is de leercurve groot, maar het is niet onmogelijk.

Maar als alleen Guru's een bepaalde opmaak kunnen realiseren met "goede" CSS/HTML dan moet je niet verbaasd zijn als de minder goden de foute maar eenvoudiger methoden gebruiken.

Uiteindelijk is het de praktijk die bepaalt welke "standaard" de juiste is.

Heb jij een Video 2000 recorder thuis staan?

[Verwijderd]

Je vergeet dat een hoop wat wordt toegepast op geen enkele standaard gebaseerd is.

[Verwijderd]

ik vind dat elke zichzelf respecterende devver de specs moet kennen, vervolgens komen ze er vanzelf achter welke browsers wat wel en niet ondersteunen, daar is niks guru achtigs aan

en vervolgens googlen naar een oplossing ook niet. Je doet er dan wel wat langer over dan mensen die dat traject al gehad hebben (guru's), maar ik denk dat iedereen de meeste problemen wel met css kan oplossen. Tuluk zijn er soms situaties waar het echt niet anders kan, zoals gordijnstok al aangeeft, maar als je zonder verder na te denken meteen naar tables grijpt, versta je imho je vak niet

edit: als je je per se altijd voor 100% aan de standaarden wilt houden (en daardoor waarschijnlijk bepaalde ontwerpen verwerpt die op een andere manier wel te realiseren zouden zijn) overigens ook niet

[ Voor 16% gewijzigd door Verwijderd op 24-03-2005 13:28 ]

[Genoil]

Verwijderd schreef op donderdag 24 maart 2005 @ 12:41:
[...]


Je haalt wat door elkaar. Uiteindelijk zijn het *wel* de standaarden-organisaties die bepalen wat goed of fout is. Het gebruik van een "master-tabel" voor een 3 kolommen design is even fout als tien tabellen in elkaar nesten; tabellen zijn daar namelijk niet voor bedoeld.
In een tabel zet je - zoals zo vaak gezegd - tabulaire data. Omdat jij te weinig kennis hebt van CSS veroordeel je de standaarden maar tot de dood. Niet het bedrijfsleven bepaalt wat goed of fout is. Bovendien is er al vaak naar boven gekomen dat de css goeroes een site evensnel bouwen. Misschien is de leercurve groot, maar het is niet onmogelijk.

Werkelijk verbazingwekkend dat je, ook al stel ik luid en duidelijk dat ik ook wel weet dat het eigenlijk bad-practise is, me wederom met dat semantisch correcte geouwehoer over de bedoeling van TABLEs om de oren moet slaan. Vervolgens meen je ondanks mijn waarschuwing ook nog een conclusie te kunnen trekken over het niveau van mijn CSS kennis en leg je me woorden in de mond, het moet niet veel gekker worden!

Ik weet genoeg van CSS om te weten dat CSS3 pas fatsoenlijke ondersteuning biedt voor layout in kolommen die op hetzelfde niveau is dan hetgeen TABLEs al jaren bieden. Dat fancy gepiel met CSS1/2 om toch maar vooral het TABLE element niet te gebruiken is imo gerommel in de marge, en blijft dat totdat er brede support is vanuit het bedrijfsleven voor echte CSS columns.

Laat ik het eens over een andere boeg gooien, heb je al eens nagedacht over de semantiek van CSS-properties? Zijn margin-left en margin-right ervoor gemaakt om links en rechts ruimte over te laten van je centrale kolom voor de overige 2, zodat je footer divje lekker met de flow van de middenkolom meegaat? Nee, het zijn truucjes, die vaak ook nog eens niet goed werken op de mindere browsers. Marges in de betekenis van het woord gaan over restwaarden, verschillen en dus niet over kolom-layouts.

Of zijn "faux columns" dan een "goede" methode? Het forum wordt hier (door de goeroe's) zowat gespammed met de link naar ALA's faux columns artikel, dus het zal wel "goed" zijn. Wel raar, een methode met het woord "fout" in de naam die dan zogenaamd goed is. Imo is het helemaal niet "goed", het is een truucje voor mensen met tabelangst.

[Verwijderd]

Genoil, ik wil niet flauw zijn, maar tabellen emuleren zit in CSS 2.1 en is ondersteund bij Opera, Safari en Mozilla. Dat IE het niet ondersteund is wat anders, maar "Ik weet genoeg van CSS om te weten dat CSS3 pas fatsoenlijke ondersteuning biedt voor layout in kolommen die op hetzelfde niveau is dan hetgeen TABLEs al jaren bieden" klopt dus niet.

[Verwijderd]

En over truucjes gesproken, hoe definieer je het gebruik van tabellen voor layout? Precies.

[Verwijderd]

Ik trek eigenlijk liever een css trukendoos (faux columns) open dan een HTML trukendoos (tabellen), zodat je HTML tenminste wel goed te lezen blijft. Als het dan nog echt niet gaat eventueel een JS trukendoos

wat wel en niet goed is: het is goed als er over nagedacht is denk ik, als je een weloverwogen beslissing hebt gemaakt (en kennis van zaken hebt om die beslissing te maken) is het goed

[Clay]

Faux columns was een artikel over een techniek die al lang bekend was; het stapelen / tilen van bg images met geneste elementen om zo je design toonbaar te maken in html/css. De image tag is niet geschik voor design elementen, logisch oa aangezien het er in een andere skin anders uit zou kunnen zien. Een groot deel van het gescheld op css komt voort uit mensen die net als bij tables nu de div met css op een bepaalde afmeting en plaats willen rammen, in de veronderstelling dat elk visueel "blok" waar een design uit bestaat ook een element vereist wat die afmetingen heeft; waanzin! Een visueel onderdeel zegt niets over de markup erachter.

Hoewel je een punt hebt dat een gebrek aan goeie ondersteuning in wezen leidt tot het misbruiken van margins om kolommen te genereren kan je daarmee niet stellen dat er wat mankeert aan het gebruiken van background images die niets meer doen dan een illusie opwekken. Vind je het nog steeds fout als de rand tussen 2 kolommen uit een golf bestaat? Een rechte lijn impliceert helemaal niets.

Verder volstaat de huidige ondersteuning al voldoende voor het bedrijfsleven om de techniek als geheel te adopteren. Al moet css nog voor een deel misbruikt worden om een layout voor elkaar te krijgen, ik heb zie dat liever op 1 plaats in afwachting van betere ondersteuning dan in de html van 10 documenten.

[RwD]

Soms heb je ook tijdsdruk en niet de tijd om iets goed te doen als je niet weet hoe...
(edit: hieronder wordt ook goed opgemerkt dat opdrachtgevers meestal alleen interesse hebebn in wat ze zien en hoe het zo goedkoop mogelijk geld opleverd. Althans, das mijn ervaring, misschien ken ik de verkeerde mensen )

De faux-columns methode vindt ik trouwens maar vies dan heb ik nog liever tabellen voor dat doel. 3 koloms layout waar 1 kolom optioneel is los ik trouwens op met 2 stylesheets, is 1 kolom niet nodig, include ik de stylesheet die de andere kolom breder maakt. Geen slechte oplossing dacht ik

Ik ben misschien niet een grote expert, maar ik weet wel wat logisch is. Als je echt niet anders kan moet je doen wat je wel kunt en anders loop je het alleen jezelf lastig te maken. Ik heb gewacht met het verbannen van tabellen totdat ik de css truukjes voor de meest voorkomende zaken beheerste en nu kost het me veel minder tijd om een site te maken/om te bouwen omdat ik door het gebrek aan tabellen meer overzocht heb gekregen. Maar waarom zou ik mezelf daar in 1998 mee lastig hebben gevallen? Ik kon nog maar net tabellen ineen zetten laat staan bijvoorbeeld 2 div elementen naast mekaar zetten. Ik stond er uberhaupt niet bij stil dat tabel een betekenis had voor de inhoud; ik zag een website als vierkantjes in tabelvorm, voor mij waren websites tabelgegevens en framesets waren gewoon aparte tabellen...

Er is 1 site van mij die ik graag in mijn cv durf te zetten die nog steeds 1 tabel (1 rij, 3 kolommen) gebruikt voor layout omdat ik die site een half jaar geleden niet voor mekaar kreeg met css. Inmiddels zou dat makkelijk lukken (heel veel geleerd/gelezen in de winter. Ik ben de site van het bedrijf opnieuw aan het doen met 3 kolommen) maar voorlopig heb ik er geen klacht over gehad

[ Voor 7% gewijzigd door RwD op 24-03-2005 14:05 ]

[Verwijderd]

Genoil schreef op donderdag 24 maart 2005 @ 13:44:
[...]


Werkelijk verbazingwekkend dat je, ook al stel ik luid en duidelijk dat ik ook wel weet dat het eigenlijk bad-practise is, me wederom met dat semantisch correcte geouwehoer over de bedoeling van TABLEs om de oren moet slaan.

Als je zelf al aangeeft dat iets bad-practise is, waarom vind je het dan niet fout. Volgens mij wordt deze discussie ook gevoerd door mensen die allemaal verschillende brillen op hebben en redeneren vanuit hun eigen paradigma. Dat gaat gewoon niet samen.

(1) Voor mij geldt dat ik markup superieur acht aan weergave. Ik pas liever een css truuk toe - faux column - dan dat ik m'n markup om zeep help.(2) Anderen redeneren vanuit economisch motief; klant boeit semantiek niet, ik heb maar acht uur per dag, ik flans sneller iets in elkaar in HTML, de klant kijkt niet onder de motorkap. Als ik een bedrijf zou hebben waar ik veel productie moet draaien in een korte tijd, dan zou ik ook voor een snellere methode gaan.



Ik leef alleen nog een paar jaar in Utopia. Laat me daar dan ook zitten . Goed of fout is zo moeilijk en het heeft zo iets negatiefs. Volgens de twee bovenstaande paradigma's is de ander de foute. Dit lijkt me dus een discussie waar geen eind aan zal komen.

disclaimer: Utopia (tm) by Clay.

[ Voor 6% gewijzigd door Verwijderd op 24-03-2005 14:33 ]

[equationunequal]

Genoil schreef op donderdag 24 maart 2005 @ 13:44:
Of zijn "faux columns" dan een "goede" methode? Het forum wordt hier (door de goeroe's) zowat gespammed met de link naar ALA's faux columns artikel, dus het zal wel "goed" zijn. Wel raar, een methode met het woord "fout" in de naam die dan zogenaamd goed is. Imo is het helemaal niet "goed", het is een truucje voor mensen met tabelangst.

Faux != fout

faux

adj : not genuine or real; being an imitation of the genuine article; "it isn't fake anything; it's real synthetic fur"; "faux pearls"; "false teeth"; "decorated with imitation palm leaves"; "a purse of simulated alligator hide"

De naam zegt het al: nep kolommen. Het is idd een trucje, maar wel eentje die een semantisch correcte oplossing biedt...

[Genoil]

Verwijderd schreef op donderdag 24 maart 2005 @ 13:50:
Genoil, ik wil niet flauw zijn, maar tabellen emuleren zit in CSS 2.1 en is ondersteund bij Opera, Safari en Mozilla. Dat IE het niet ondersteund is wat anders, maar "Ik weet genoeg van CSS om te weten dat CSS3 pas fatsoenlijke ondersteuning biedt voor layout in kolommen die op hetzelfde niveau is dan hetgeen TABLEs al jaren bieden" klopt dus niet.

Dang dat is flauw! Blijkbaar weet ik toch niet genoeg van CSS . Gelukkig dat de meest gebruikte browser het niet ondersteund, anders stond ik helemaal in m'n hemd.

Verwijderd schreef op donderdag 24 maart 2005 @ 13:52:
En over truucjes gesproken, hoe definieer je het gebruik van tabellen voor layout? Precies.

Dat is ook een truucje, maar wel een simpeler truucje dat beter werkt dan de bekende CSS truucjes

Verwijderd schreef op donderdag 24 maart 2005 @ 14:02:
[...]
Als je zelf al aangeeft dat iets bad-practise is, waarom vind je het dan niet fout. Volgens mij wordt deze discussie ook gevoerd door mensen die allemaal verschillende brillen op hebben en redeneren vanuit hun eigen paradigma. Dat gaat gewoon niet samen.

Ik had gisteren ook een reply klaar staan om te posten die exact hierover ging (vergeten te posten). 'goed' en 'fout' zijn moeilijk te vangen termen in een turbulent vakgebied dat voortdurend aan verandering onderhevig is, met vele verschillende invalshoeken.

Hankey schreef op donderdag 24 maart 2005 @ 14:03:
[...]
Faux != fout
[...]
De naam zegt het al: nep kolommen. Het is idd een trucje, maar wel eentje die een semantisch correcte oplossing biedt...

Hehe jammer, was ik er toch bijna mee weggekomen . Oneerlijke discussietechnieken op de pseudo-vrijdag, heerlijk. Ik ga in het park liggen

[JHS]

De vraag of iets goed of fout is doet eigenlijk helemaal niet ter zake, mijns inziens. Het enige wat relevant is wat de gebruiker en vooral de klant wil. Het is jouw taak als developer om de gebruiker / klant van goed, degelijk advies te dienen wat het best is, en bepaalde beslissingen te nemen. Maar het draait uiteindelijk om de gebruiker, ook voor de klant. Dus als jij voor jezelf een "fout" gebruik van elementens, CSS, etcetera kan verantwoorden moet je dat lijkt mij vooral doen. Maar persoonlijk denk ik dat het standards-georienteerd ontwikkelen om de (middel)lange termijn veel tijd, geld en moeite bespaard.

[ Voor 3% gewijzigd door JHS op 24-03-2005 17:08 ]

[raptorix]

JHS schreef op donderdag 24 maart 2005 @ 17:07:
De vraag of iets goed of fout is doet eigenlijk helemaal niet ter zake, mijns inziens. Het enige wat relevant is wat de gebruiker en vooral de klant wil. Het is jouw taak als developer om de gebruiker / klant van goed, degelijk advies te dienen wat het best is, en bepaalde beslissingen te nemen. Maar het draait uiteindelijk om de gebruiker, ook voor de klant. Dus als jij voor jezelf een "fout" gebruik van elementens, CSS, etcetera kan verantwoorden moet je dat lijkt mij vooral doen. Maar persoonlijk denk ik dat het standards-georienteerd ontwikkelen om de (middel)lange termijn veel tijd, geld en moeite bespaard.

Klopt, ik heb dit enorm vaak meegemaakt, heb een aantal grote sites ontwikkelt waarbij de klant zo een 2 a 3 jaar terug vooral riep: het moet werken op X,Y,Z. Nu zijn deze klanten eindelijk zover dat ze ook begrijpen dat er andere browsers zijn, dus nu moet het werken op V,W,X,Y,Z. De volgende stap is hopelijk dat de klant zegt dat we gewoon volgens een bepaalde Standaard/Aanbeveling kunnen werken.

[JHS]

raptorix: Alleen vind ik persoonlijk wel dat je als developer de verantwoordelijkheid hebt om de klant de eerste keer al te overtuigen dat het toch wel fijn is als het in V, W, X, Y, X en Q gaat werken. En dat zoekmachines de pagina goed kunnen indexeren. Etcetera. En dat het dus wel handig en goedkoper zou zijn om standaard-georienteerd te werken. Als je niet de luxe hebt dat je je klanten kan kiezen (wie wel?) én als ze écht niet overtuigd zijn van je punten, of gewoon een goed inhoudelijk (financieel) standpund hebben over waarom dat allemaal niet nodig is, is het pas tijd om voor, in mijn ogen, "mindere" oplossingen te kiezen.

edit:

Waar het me om ging is dat in deze hele discussie vaak en makkelijk vergeten wordt dat het om de gebruiker blijft en moet blijven draaien.

[ Voor 12% gewijzigd door JHS op 24-03-2005 17:27 ]

[raptorix]

JHS schreef op donderdag 24 maart 2005 @ 17:26:
raptorix: Alleen vind ik persoonlijk wel dat je als developer de verantwoordelijkheid hebt om de klant de eerste keer al te overtuigen dat het toch wel fijn is als het in V, W, X, Y, X en Q gaat werken. En dat zoekmachines de pagina goed kunnen indexeren. Etcetera. En dat het dus wel handig en goedkoper zou zijn om standaard-georienteerd te werken. Als je niet de luxe hebt dat je je klanten kan kiezen (wie wel?) én als ze écht niet overtuigd zijn van je punten, of gewoon een goed inhoudelijk (financieel) standpund hebben over waarom dat allemaal niet nodig is, is het pas tijd om voor, in mijn ogen, "mindere" oplossingen te kiezen.

edit:

Waar het me om ging is dat in deze hele discussie vaak en makkelijk vergeten wordt dat het om de gebruiker blijft en moet blijven draaien.

Tot je bij een organisatie werkt waarbij de developer niet direct contact heeft met de klant, en de gene die het moet overbrengen al blij is als de klant tevreden is.

[Rowanov]

JHS schreef op donderdag 24 maart 2005 @ 17:26:
raptorix: Alleen vind ik persoonlijk wel dat je als developer de verantwoordelijkheid hebt om de klant de eerste keer al te overtuigen dat het toch wel fijn is als het in V, W, X, Y, X en Q gaat werken. En dat zoekmachines de pagina goed kunnen indexeren. Etcetera. En dat het dus wel handig en goedkoper zou zijn om standaard-georienteerd te werken. Als je niet de luxe hebt dat je je klanten kan kiezen (wie wel?) én als ze écht niet overtuigd zijn van je punten, of gewoon een goed inhoudelijk (financieel) standpund hebben over waarom dat allemaal niet nodig is, is het pas tijd om voor, in mijn ogen, "mindere" oplossingen te kiezen.

edit:

Waar het me om ging is dat in deze hele discussie vaak en makkelijk vergeten wordt dat het om de gebruiker blijft en moet blijven draaien.

Voor veel bedrijven is juist de goede indexering in zoekmachines genoeg reden om overstag te gaan.

[Erkens]

raptorix schreef op donderdag 24 maart 2005 @ 18:58:
[...]

Tot je bij een organisatie werkt waarbij de developer niet direct contact heeft met de klant, en de gene die het moet overbrengen al blij is als de klant tevreden is.

in dat geval lijkt me dat er wat schort aan de interne communicatie

[Blauw]

Ik heb er nog eens over nagedacht

Wat mij mateloos stoort is dat we wel praten over een gezamelijke grondwet in de EU, maar dat we nog steeds verschillende stekkertjes, verschillende schroefjes hebben. Het feit dat er mensen zijn die liever tabellen gebruiken voor de layout is eigenlijk hetzelfde als engelsen die het vertikken om aan de 'goede' kant van de weg te gaan rijden: ze zijn het zo gewend. Kortom: er is niet een bepaalde stelregel te nemen over goed of fout, want het is maar net wat je gewend bent, en om maar eens op het eerste zinnetje terug te komen: ik zou het als klant wel behoorlijk storend vinden wanneer ik een website opgeleverd krijg waarvan ik de code niet meer kan reproduceren, en in die zin denk ik dat webstandaarden wel hun niet dienen als richtingaanwijzers.

[We Are Borg]

Verwijderd schreef op dinsdag 22 maart 2005 @ 18:10:
[...]
Dus als het W3C in de sloot springt..? (Doorgegeven overigens.)

Dan spring ik niet mee. Maar in een ander, minder extreem, geval misschien weer wel. De W3C geeft aanbevelingen en is (gedeeltelijk) verantwoordelijk voor de standaarden. Kortom, de aanbevelingen die ze geven hebben toch een enige waarde en ze functioneren dus ook in zekere mate als voorbeeld. Waarom geven ze dan het 'verkeerde' voorbeeld met het feit dat ze XHTML gebruiken, terwijl ze XHTML icm text/html niet aanraden (ik zeg niet verbieden)? Ook een beetje in de richting van jouw opmerking

[Verwijderd]

Erkens schreef op donderdag 24 maart 2005 @ 19:27:
in dat geval lijkt me dat er wat schort aan de interne communicatie

Ik kan me heel goed vinden in dit argument van Raptorix. Het is al een ramp om developers de voordelen en nadelen van het werken volgens deze methodiek uit te leggen. Als je zaken als deze aan management teams moet gaan uitleggen, of aan account managers, dan zien ze graag kostenbesparingen, en voordelen onderbouwd in de vorm van cijfers. Zij denken volgens een compleet ander stramien dan jij denkt. Je kunt ook niet als developer zomaar met een andere methodiek in een bedrijf beginnen.

In eerste instantie kost het je veel meer tijd bij de ontwikkeling. Het leerproces neemt een behoorlijke tijd in beslag, de fouten zijn in eerste instantie hoog, je loopt tegen compatibiliteitsproblemen aan, en tel daar dan nog de overhead van leren in teamverband bij op. Totdat er enige vorm van snelheid ontstaat in de projecten die je doet, zul je rekening moeten houden in de projecten dat je als bedrijf geld en uren moet gaan investeren in dat leertraject.

Ik moet zo'n leertraject verantwoorden aan het management team. Ik moet dat verantwoorden in termen als uren, kosten, tijden, voordelen en nadelen in een globale opzet over een termijn omdat je als onderneming niet per dag een productstrategie opzet. Die verantwoording met betrekking tot CSS is heel erg suggestief. Wat zijn de besparingen in termen als geld, uren? Daarbij moet er ook nog een management team zijn dat zich echt er voor inzet, en niet direct begint te pushen als projecten moeizaam op gang komen of in eerste instantie langer duren als normaal. Combineer dit ook nog even met de algehele trend in deze branch van "kun je dit even doen .. ", algehele problemen met effectief plannen (op 75% ipv 100% basis bijvoorbeeld), en krappe offreringen.

Daarbij komt ook dat er altijd mensen zijn die puur er voor kiezen om 8 uur per dag te werken, en daarna niet meer met werk bezig te zijn. Je zult dat leertraject dus in die 8 uur moeten invoegen.

Combineer dit met een late acceptatie van standards door Microsoft die voor veel bedrijven als leading geldt, en die pas sinds kort MSN en haar corporate site naar een enigzins standards based opzet hebben vertaald. Dan ook nog het gemis aan support in ASP.NET, de controls die nog bakken met tables uitspugen, en de volledige desinteresse van programmeurs tov webfronts.

Kortom, het is een hel om zoiets in een onderneming erdoor te krijgen. Laat staan, communicatie.

Voor veel bedrijven is juist de goede indexering in zoekmachines genoeg reden om overstag te gaan.

Daar bestaat specifieke dienstverlening voor. Een site als Wehkamp zal automatisch geindexeerd niet tot zijn volste recht komen. Dat wordt met specifieke tools gedaan. Bijna alle reissites in Nederland worden met behulp van dienstverlening in zoekmachines aangemeld, onderhouden en bewerkt. Idem voor de grootste sites op het gebied van GSM verkoop.

Het argument van zoekmachines is leuk voor tijdens de borrel en de nootjes, maar in de commerciele branche wordt er bij serieuze budgetten niet vertrouwd op automatische indexering. Dat wil je ook niet, je wilt in zoals ze dat zeggen "full control" zijn om je klanten aan te bieden wat jij wil. En als jij door eigen initiatief een kleine duw kunt geven aan rankings door middel van die dienstverlening, dan zijn commerciele instellingen daar erg blij mee.

[ Voor 7% gewijzigd door Verwijderd op 24-03-2005 21:25 ]

[Erkens]

Gordijnstok schreef op donderdag 24 maart 2005
dan zien ze graag kostenbesparingen, en voordelen onderbouwd in de vorm van cijfers.

minder tijd in onderhoud, en je weet het, onderhoud kost het meeste tijd

In eerste instantie kost het je veel meer tijd bij de ontwikkeling. Het leerproces neemt een behoorlijke tijd in beslag, de fouten zijn in eerste instantie hoog, je loopt tegen compatibiliteitsproblemen aan, en tel daar dan nog de overhead van leren in teamverband bij op. Totdat er enige vorm van snelheid ontstaat in de projecten die je doet, zul je rekening moeten houden in de projecten dat je als bedrijf geld en uren moet gaan investeren in dat leertraject.

Een leerproces heb je altijd, je moet met de tijd mee gaan, elk bedrijf dat serieus bezig denkt te zijn weet dat
maar ehm dat punt over teamverband is bullshit, want dat heb je nu ook al als het goed is...

Ik moet zo'n leertraject verantwoorden aan het management team. Ik moet dat verantwoorden in termen als uren, kosten, tijden, voordelen en nadelen in een globale opzet over een termijn omdat je als onderneming niet per dag een productstrategie opzet. Die verantwoording met betrekking tot CSS is heel erg suggestief. Wat zijn de besparingen in termen als geld, uren?

nogmaals, onderhoud aan code kost doorgaands meer tijd, op die tijd kan je flink besparen door goed opgezette code. owja, en tijd = geld
Het punt is volgens mij, dat veel (oude) developers bang zijn om over te stappen op betere methoden omdat het management er dan achterkomt dat ze altijd "prutswerk" (nofi) hebben afgeleverd. Uiteraard bedoel ik met dat prutswerk de huidge arbeidsintensieve code.

Daarbij komt ook dat er altijd mensen zijn die puur er voor kiezen om 8 uur per dag te werken, en daarna niet meer met werk bezig te zijn. Je zult dat leertraject dus in die 8 uur moeten invoegen.

cursussen worden ook vaak buiten werktijd gegeven

Dan ook nog het gemis aan support in ASP.NET, de controls die nog bakken met tables uitspugen, en de volledige desinteresse van programmeurs tov webfronts.

Onlangs voor het eerst gekeken naar dat ASP.NET, en dat viel me ook meteen op wat een bagger zooi Microsoft daar weer afgeleverd heeft
Maar de betere ASP.NET'er zal hier ongetwijveld wel de oorzaak/oplossing voor hebben

Kortom, het is een hel om zoiets in een onderneming erdoor te krijgen. Laat staan, communicatie.

Communicatie is het belangrijkste in het ontwikkel project, als een tussenpersoon tussen ontwikkelaar en klant niet correct communiceerd tussen die twee dan is er idd wat mis met die communicatie. Maar ook dan dient een ontwikkelaar er vanuit te gaan dat een nieuwe site/webapplicatie gewoon dient te werken met moderne browsers, dat hoeft als het goed niet meer tijd/geld te kosten.

[Verwijderd]

Erkens schreef op donderdag 24 maart 2005 @ 21:51:
minder tijd in onderhoud, en je weet het, onderhoud kost het meeste tijd

Verweg het grootste gedeelte aan commerciele projecten wordt eenmaal neergezet, en behoeft weinig tot geen onderhoud. Daarbij blijft mij argument qua tijd staan. Als jij dit op de manier waarop je dit tegen mij nu aanlegt, tegen mijn management zou aanleggen is de volgende vraag die je krijgt "hoeveel tijd, waar praten we over?".

Aan algemene termen als "het bespaart tijd" hechten ze 0,0 waarde totdat je met harde nummertjes komt.

Het verschil in cultuur tussen uitvoerend personeel en management is even groot als het verschil in cultuur tussen management teams en board members. Als jij iets wilt verkopen binnen het bedrijf, moet je met argumenten komen die investeringen rechtvaardigen. Als zoiets meetbaar moet zijn moet je meetwaardes hebben.

maar ehm dat punt over teamverband is bullshit, want dat heb je nu ook al als het goed is...

Tuurlijk werk je in teamverband, maar wat je dan krijgt is niet alleen elkaars hulp, maar ook dubbele kosten. Je kunt niet een enkele developer standards based laten werken aan een project en de andere door laten ploeteren in tables. Dat hele leertraject is hoe groter het team is, ook duurder.

Het punt is volgens mij, dat veel (oude) developers bang zijn om over te stappen op betere methoden omdat het management er dan achterkomt dat ze altijd "prutswerk" (nofi) hebben afgeleverd. Uiteraard bedoel ik met dat prutswerk de huidge arbeidsintensieve code.

Developers zijn bang om in een commerciele omgeving over te stappen omdat het ze enorm veel tijd kost het onder de knie te krijgen. Daartegenover staat ook dat er geen munitie is om deze tijd te rechtvaardigen in de baas zijn tijd.

Ik heb mijn kennis qua css, standards voor 95% in mijn vrije tijd opgedaan, puur omdat ik het leuk vind.

De voordelen zijn op voorhand lastig te definieren en hangen samen met een projecttype. Ze zijn al helemaal lastig neer te zetten in keiharde cijfers.

cursussen worden ook vaak buiten werktijd gegeven

Welke cursussen heb jij gevonden die hedendaagse web developers in staat stellen, om na zegge drie dagen cursus, hun layouts compleet standards based te ontwikkelen? Stel dat je een klein team van tien ontwikkelaars hebt, dat is dus 240 uur misgelopen omzet + de kosten van de cursus. Daar mag een hele hoop aan onderhoud tegenover staan om dat te rechtvaardigen. Daarnaast nog dat je met drie dagen er bijlange na niet bent.

Onlangs voor het eerst gekeken naar dat ASP.NET, en dat viel me ook meteen op wat een bagger zooi Microsoft daar weer afgeleverd heeft
Maar de betere ASP.NET'er zal hier ongetwijveld wel de oorzaak/oplossing voor hebben

Ja maatwerk, en maatwerk is algemeen gezien een duurdere aanpak dan gebruik van standaard componenten.

Communicatie is het belangrijkste in het ontwikkel project, als een tussenpersoon tussen ontwikkelaar en klant niet correct communiceerd tussen die twee dan is er idd wat mis met die communicatie. Maar ook dan dient een ontwikkelaar er vanuit te gaan dat een nieuwe site/webapplicatie gewoon dient te werken met moderne browsers, dat hoeft als het goed niet meer tijd/geld te kosten.

Projectdefinitie is het belangrijkste in een ontwikkel project. Zolang er geen context is valt er weinig te communiceren.

Betreft je laatste zin, .. hoe komen we tot dat punt, juist, met een leertraject Dus tot dat punt van kennis is bereikt betekend het voor bedrijven investeren, en grof ook.

[ Voor 12% gewijzigd door Verwijderd op 24-03-2005 22:42 ]