[Disc.] Tabellen vs. semantisch design (anno 2009)* - Softwareontwikkeling

dinsdag 4 augustus 2009 18:14

Acties:

0 Henk 'm!

be

Anoniem: 312741 schreef op dinsdag 04 augustus 2009 @ 18:12:
[...]
En ik kan niet garanderen dat ik vanaf nu eeuwig tabelloos zal blijven, hoor

Dat word nooit meer tabulaire data op je scherm krijgen. Dat is wel wat zonde imho

disjfa - disj·fa (meneer)
disjfa.nl

dinsdag 4 augustus 2009 18:17

Acties:

0 Henk 'm!

MoietyMe

zij/haar

Soultaker: ik denk dat jij vanzelf wel achter de gebreken van tabellen komt als CSS3 straks een beetje ondersteunt wordt (door IE). Dingen als rounded corners makkelijk en goed gebruiken zal vrij lastig gaan in tabellen. Denk dat box-shadow ook lastig gaat worden, en zo zijn er nog wel meer dingen.

dinsdag 4 augustus 2009 18:27

Acties:

0 Henk 'm!

Anoniem: 312741

Topicstarter

disjfa schreef op dinsdag 04 augustus 2009 @ 18:14:
Dat word nooit meer tabulaire data op je scherm krijgen. Dat is wel wat zonde imho

Die is wel erg flauw, hoor

dinsdag 4 augustus 2009 19:15

Acties:

0 Henk 'm!

R4gnax

Soultaker wil full screen centrering van content met arbitraire dimensies? Dan krijgt 'ie dat toch:

HTML:

<!DOCTYPE html>
<html>
    <head>
        <style>
            body, html, div
            {
                margin: 0;
                padding: 0;
            }

            body, html
            {
                height: 100%;
            }

            div.outer
            {
                height: 100%;
                width:  100%;
                line-height: 1em;

                text-align: center;
            }

            div.helper
            {
                width: 0;
                height: 100%;

                vertical-align: middle;

                display: inline-block;
                zoom: 1;
                *display: inline;
            }

            div.inner{
                vertical-align: middle;

                display:inline-block;
                zoom: 1;
                *display: inline;
            }

        </style>
    </head>
    <body>
        <div class="outer">
            <div class="helper"></div>
            <div class="inner">
                <p>Hello world</p>
                <p>Hello world</p>
                <p>Hello world</p>
            </div>
        </div>
    </body>
</html>

Bovenstaande zou onder elke browser moeten werken die inline-block en vertical-align op inline-blocks snapt. Dat is inclusief de IE familie die met de proprietory zoom: 1 en daaropvolgende *display: inline de ietwat magische hasLayout eigenschap triggert op een naar inline geconverteerd element. Dat alles resullteert in hetzelfde gedrag als het renderen van inline-block.

Zoals het voorbeeld laat zien hoef je voor inner niet per sé dimensies op te geven, maar wordt dit allemaal netjes automatisch doorgerekend. Als er voor outer geen dimensies opgegeven worden zal outer verticaal precies groot genoeg groeien om inner te bevatten maar wel zoals elk block level element 100% v/d parent breedte in beslag nemen.

Een vaste grootte kan voor zowel de inner als de outer div arbitrair gekozen worden. (Zolang outer maar physiek groot genoeg is om inner te bevatten of meegroeit..)

Simpel, semantisch correct, en compacter dan tables.

offtopic:
Oh ja; voordat iemand zeurt over het feit dat er een onnodige extra div in gebruik is genomen: divs an sich hebben geen semantische betekenis. Hoewel de markup minder 'puur' wordt met een lege helper tag, wordt deze er niet minder semantisch correct om!

[ Voor 6% gewijzigd door R4gnax op 04-08-2009 19:21 ]

dinsdag 4 augustus 2009 19:25

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

R4gnax schreef op dinsdag 04 augustus 2009 @ 19:15:
Simpel

Sorry, maar noem je dit simpel? Alsjeblieft zeg, voor een beginner is het allesbehalve intuitief. Je voorbeeld geeft alleen maar aan dat HTML (danwel CSS) heel wat mist kwa fatsoenlijke formatting. Al die divs zouden eigenlijk niet eens nodig hoeven zijn om zoiets simpels als centreren toe te kunnen passen.

(Disclaimer: dit is op geen enkele manier een argument vóór het gebruik van tables, of tegen het gebruik van divs)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

dinsdag 4 augustus 2009 19:30

Acties:

0 Henk 'm!

MoietyMe

zij/haar

Dan vraag ik me alleen af waarom je überhaupt verticaal zou willen centreren.

dinsdag 4 augustus 2009 19:44

Acties:

0 Henk 'm!

TeeDee

CQB 241

offtopic:
Zogeheten mini-sites, een tagline, imagemap of wat dan ook. Er zijn genoeg redenen om verticaal te centreren. Of deze nog helemaal hip en vet cool zijn laat ik in het midden.

Heart..pumps blood.Has nothing to do with emotion! Bored

dinsdag 4 augustus 2009 19:52

Acties:

0 Henk 'm!

Herko_ter_Horst

"Soultaker's Challenge" wat korter en simpeler (want o.b.v. puur semantische content) geïmplementeerd; getest in Firefox 3.5, Internet Explorer 8.0, Chrome 2.0 en Opera 9.64:

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />

    <title>CSS Center demo</title>

    <link title="Basic" rel="stylesheet" type="text/css" href="all.css" media="all" />
</head>

<body>
    <p>Hello World!</p>
    <img src="http://www.tweakers.net/ext/i.dsp/1117631389.png" />
    <p>Oh my!</p>
</body>
</html>

Cascading Stylesheet: all.css

html {
    margin: 0;
    width: 100%;
    height: 100%;
    position: fixed;
    display: table;
}

body {
    margin: 0;
    display: table-cell;
    text-align: center;
    vertical-align: middle;
}

Hieruit blijkt trouwens tevens dat "het zich gedragen als tables in layout-opzicht" wel degelijk onderkend is: er zijn diverse CSS properties die "table" layout-eigenschappen toekennen aan content.

Mocht het stylen van het <html> element in een oudere browser niet ondersteund zijn: het werkt ook "een niveau lager" met een <div> die dezelfde style krijgt als nu de <body> en de body die dan de style krijgt die nu op de <html> wordt gezet.

[ Voor 25% gewijzigd door Herko_ter_Horst op 04-08-2009 22:47 ]

"Any sufficiently advanced technology is indistinguishable from magic."

dinsdag 4 augustus 2009 20:09

Acties:

0 Henk 'm!

R4gnax

Herko_ter_Horst schreef op dinsdag 04 augustus 2009 @ 19:52:Korter en simpeler, maar slechts getest in FF3.5 en IE8

Dit breekt dan ook op IE6 en IE7, die table en table-cell niet als geldige waarde accepteren voor display.
Dat strookt niet helemaal met het feit dat deze techniek volgens Soultaker breed ondersteund moest zijn.

.oisyn schreef op dinsdag 04 augustus 2009 @ 19:25:
[...]

Sorry, maar noem je dit simpel? Alsjeblieft zeg, voor een beginner is het allesbehalve intuitief. Je voorbeeld geeft alleen maar aan dat HTML (danwel CSS) heel wat mist kwa fatsoenlijke formatting. Al die divs zouden eigenlijk niet eens nodig hoeven zijn om zoiets simpels als centreren toe te kunnen passen.

Ja, dit noem ik simpel. Dit is gewoon het correct gebruik van de vertical-align eigenschap om inline gepositioneerde elementen te positioneren t.o.v. de tekstregel. Je gebruikt daarbij echter inline-block om één van die elementen de volledige hoogte van het blok waarin gecentreerd moet worden te geven. Zo forceer je de tekstregel naar het exacte midden van het blok en daarmee ook alle andere verticaal op de tekst regel gecentreerde elementen naar het midden van het blok. Inline-block elementen gedragen zich van buitenaf exact als inline elementen en om horizontaal te centreren kun je dus gewoon text-align: center gebruiken.

Iedereen zou dit op moeten kunnen zoeken en eenvoudig moeten kunnen herconstrueren zodra ze eenmaal het idee in hun hoofd hebben zitten om een ander stuk content de te centreren content weg te laten 'duwen'.

De pest is alleen dat bijna iedereen vastgerot zit in het denken aan: "oei, tables konden heel makkelijk centreren. Kan ik de browser niet trucen mijn content als table te renderen?" Of aan: "met absolute posities kan ik alles pixel perfect plaatsen waar ik wil, dus waarom kan ik daar niet mee centreren?" Simpel is in dit geval dus niet intuitief. Simpel is in dit geval wèl breed ondersteund, generiek toepasbaar, stabiel en met minieme middelen.

[ Voor 6% gewijzigd door R4gnax op 04-08-2009 20:14 ]

dinsdag 4 augustus 2009 20:16

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

R4gnax schreef op dinsdag 04 augustus 2009 @ 20:09:
Ja, dit noem ik simpel. Dit is gewoon het correct gebruik van de vertical-align eigenschap om inline gepositioneerde elementen te positioneren t.o.v. de tekstregel. Je gebruikt daarbij echter inline-block om één van die elementen de volledige hoogte van het blok waarin gecentreerd moet worden te geven. Zo forceer je de tekstregel naar het exacte midden van het blok en daarmee ook alle andere verticaal op de tekst regel gecentreerde elementen naar het midden van het blok.

Dat is een mooie beschrijving wat het doet. Maar nog een lange weg van "ik wil verticaal centreren".

Iedereen zou dit op moeten kunnen zoeken en eenvoudig moeten kunnen herconstrueren.

Je gaat compleet voorbij aan het punt. Natuurlijk moet iedereen het kunnen. Omdat er geen simpelere manier is, omdat HTML en CSS nogal scheef in elkaar zitten wat dat betreft! Het had net zo goed een property van een element kunnen zijn, waarbij al z'n inhoud automatisch verticaal gecentreerd werd in z'n box.

Dát is wat ik aanstip. Wat jij suggereert is niet simpel. Het is niet intuitief. Het is iets dat je moet leren, en wat daarná pas logisch is. Het is niet iets waar je aan denkt als je het trucje niet kent. Het hele trucje is nogal suf - je zou het niet nodig moeten hebben. Dat hoeft met tables immers ook niet.

De pest is alleen dat bijna iedereen vastgerot zit in het denken aan: "oei, tables konden heel makkelijk centreren.

Exact. Waarom kan dat niet net zo simpel zonder tables? Dat is een flaw in HTML/CSS

Kan ik de browser niet trucen mijn content als table te renderen?

Daarin zie ik op zich niet veel mis. De content van Herko's voorstel is semantisch gezien identiek aan die van jou. Maar die van Herko vind ik wel een stuk simpeler, zonder allemaal ogenschijnlijk nutteloze geneste divs.

[ Voor 11% gewijzigd door .oisyn op 04-08-2009 20:21 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

dinsdag 4 augustus 2009 20:22

Acties:

0 Henk 'm!

Herko_ter_Horst

Maar wacht even: het feit dat HTML tables "by default" hun content links-uitgelijnd en verticaal centreren is ook niet zomaar intuitief, het gebruik van tables om content te positioneren is óók een aangeleerd truukje.

(ben nog aan't broeden op een meer backwards-compatible oplossing, maar ik heb eigenlijk geen zin om IE6 en 7 te installeren

)

[ Voor 26% gewijzigd door Herko_ter_Horst op 04-08-2009 20:24 ]

"Any sufficiently advanced technology is indistinguishable from magic."

dinsdag 4 augustus 2009 20:43

Acties:

0 Henk 'm!

Soultaker

R4gnax schreef op dinsdag 04 augustus 2009 @ 19:15:
Soultaker wil full screen centrering van content met arbitraire dimensies? Dan krijgt 'ie dat toch:

Dit lijkt inderdaad overeen te komen met wat ik bedoelde, gefeliciteerd.

Maar het onderstreept wel m'n punt: dit is CSS code die ik zelf niet had verzonnen (en ik heb het in het verleden wel degelijk geprobeerd) terwijl ik toch wel basiskennis van CSS heb. Je hebt er ook wat IE6-hacks in zitten die zelf noch zou verzinnen, noch zou kunnen testen (zelfs onder Windows XP, waar ik niet vaak mee werk, heb ik IE6 niet meer geïnstalleerd). In dit soort gevallen wordt het er met CSS dus niet beter op!

edit:
Trouwens, de verticale centrering werkt niet in Opera! We zijn er dus nog niet. Opera (en elke andere browser die ik geprobeerd heb) heeft echter geen enkele moeite met de tabellayout.

Herko_ter_Horst schreef op dinsdag 04 augustus 2009 @ 19:52:
"Soultaker's Challenge" wat korter en simpeler (want o.b.v. puur semantische content) geïmplementeerd. [..] Hieruit blijkt trouwens tevens dat "het zich gedragen als tables in layout-opzicht" wel degelijk onderkend is: er zijn diverse CSS properties die "table" layout-eigenschappen toekennen aan content.

Dit is ook een interessante aanpak. Overigens haal je zo maar slechts gedeeltelijk de opmaak uit de HTML, want de volgorde van de elementen in de HTML is nog steeds van essentieel belang voor de structuur van de layout (twee kolommen omdraaien kan b.v. niet).

Herko_ter_Horst schreef op dinsdag 04 augustus 2009 @ 20:22:
Maar wacht even: het feit dat HTML tables "by default" hun content links-uitgelijnd en verticaal centreren is ook niet zomaar intuitief, het gebruik van tables om content te positioneren is óók een aangeleerd truukje.

Tot op zekere hoogte waar, maar ik vind het een stuk makkelijker om me voor te stellen hoe ik een ontwerp met tabellen in elkaar kan knutselen dan met wanneer ik dat met divjes moet doen. Ten eerste zijn er veel méér relevante CSS attributen die effect hebben op de positionering (position: absolute, fixed, static; float: left, right, none; display; inline, block..) en er zijn niet-intuïtieve interacties. Dat merk ik omdat ik elke keer als ik er mee aan het prutsen ben ik tegen allerlei rare bugs aanloop die ik niet kan plaatsen, of ontwerpen maak die in verschillende browsers er verschillend uitzien (wat aangeeft dat browsermakers er ook niet overeens zijn hoe sommige code geïnterpreteert moet worden!)

Ik zal toegeven dat ik enigzins bevooroordeeld ben, maar ik heb wel het gevoel dat table-gebaseerd layouten relatief simpel-maar-effectief is (vandaar ook dat allerlei GUI toolkits er gebruik van maken) en dat veel van de complexiteit van CSS niet behulpzaam is bij het maken van realworld layouts.

[ Voor 38% gewijzigd door Soultaker op 04-08-2009 20:49 ]

dinsdag 4 augustus 2009 20:50

Acties:

0 Henk 'm!

Booster

Superuser

Anoniem: 312741 schreef op dinsdag 04 augustus 2009 @ 18:12:
Ik ben al braaf aan het developen volgens jullie adviezen, tabelloos. Maar ik houd jullie op de hoogte van mijn vorderingen/bevindingen, het is wel lastig om erin te komen als je in tabellen denkt in je hoofd.

Mijn complimenten dat je toch besloten hebt eens een kijkje te nemen in de wereld van sematische HTML

Het kan soms erg moeilijk zijn om aan zoiets te beginnen, ondanks dat velen je vertellen dat het met tabellen werken passé is. Je hebt immers een besef opgebouwd van dat hetgeen je doet het juiste is, je hebt je werk er inmiddels omheen gebouwd. Het is dan lastig om te horen dat daar volgens een groep waarvan je dezelfde mening had verwacht, iets "verkeerd" aan is.

Hoe je ooit tot het gebruik van tabellen gekomen bent is duidelijk, en ik denk erg begrijpelijk. Toen browsers nog rotte stukken software waren

was het gewoon erg moeilijk om bepaalde veelgevraagde dingen met semantisch correcte code goed weer te geven. Het was toen "hot" en er werd over geschreven, vooraanstaande websites gebruikte het, niemand overzag toen dat we 15 jaar later heel veel last zouden hebben van deze hacks, en tot op de dag van vandaag vinden we dit soort verouderde info op teh interwebz.

Dat je niet eerder bent overgestapt is het resultaat van een reeks aan factoren die denk ik los van elkaar ook heel begrijpelijk zijn. Zo heb je een collega die jouw mening met je kan delen over tabellen en zich meer verdiept in nieuwe technologieen als ik je goed begrijp. Een bevestiging van dat hetgeen je geleerd hebt goed is en zo heb je een solide basis opgebouwd om te doen wat je altijd gedaan hebt.

Zelfs een beginneling kan anno 2009 net even een tekstje tegenkomen van een n00b in een heel officieel uitgedoste layout, waardoor hij denkt met een vooraanstaande bron te maken te hebben. En zo leert die persoon dat dat waarheid is, en bouwt hij/zij daarop door, totdat het tegendeel ter sprake komt.

Anoniem: 312741 schreef op dinsdag 04 augustus 2009 @ 14:37:
Hmmz, ik bezoek toevallig zojuist een site http://www.victorfeenstra.nl en die maakt bruut mooie dingen, dus kijk voor de grap eens in de source. Wat denk je? Tables.

Je hebt gelijk dat er tables in die website staan, maar Victor Feenstra is een kunstenaar, ontwerper. Hij heeft zijn site mogelijk wel ontworpen of daar de regie over gehad, maar hem niet technisch uitgewerkt.

Volgens de author meta-tag is de maker van de site Frank Groet, http://www.frankgroet.nl/pages/
In zijn portfoliosite komen we tabellen tegen, en ook divs, samen tot een enorme soep gedraait die uiteindelijk iets heel mooi's weergeeft. even los van of dat compatible is in alle browsers enzo

Het enige wat we hier uit kunnen concluderen is dat of het ontwerp van een website er mooi uit ziet niets te maken heeft met de onderliggende techniek.

Verder zie ik niet in waarom een site met tables niet goed te bezoeken is voor blinden, iemand een linkje?

Ik wil deze vraag gebruiken om in te springen op het hele idee rondom semantische HTML. Belangrijk daarvoor is het besef dat er in de huidige webbrowsers, zoekmachinespiders en andere online "dingen", nu én in de toekomst, voorzien zijn van een soort van intelligentie. Met die intelligentie tracht het te achterhalen wat jij bedoeld met de code die je schrijft. Een zoekmachinespider bekijkt een website immers niet grafisch, maar puur op basis van de geschreven code.

Zo kan een paragraaf (en dan bedoel ik letterlijk een <p>) met een groter lettertype voor een mens perfect op een krantenkop lijken, maar een computer ziet dit anders. Deze constateerd op basis van die code enkel en alleen dat jij een bepaald stuk tekst groter wilde weergeven, én niet dat het om de kop van het artikel gaat. Bij semantische HTML zou de kop van het artikel immers in een <h> tag staan en dan was het allemaal heel begrijpelijk geweest voor de computer.

In het geval van een visueel gehandicapt persoon kan dit grote verschillen geven in hoe hij de website voelt of hoort. Stel dat je drie artikelen onder elkaar hebt staan op één pagina, allemaal met een paragraaf met een wat groter lettertype als kop. Er bestaat een reeele kans dat de voorleessoftware met zijn intelligentie niet begrijpt dat er drie koppen op de site staan, en hij zal dus de hele pagina als een enkel artikel oplezen. Je snapt hoe dergelijke verwarringen het gebruik van een website veel moeilijker kunnen maken dan nodig.

Dergelijke problemen met semantiek zijn ook van toepassing op tabellen

Zoekmachines o.a. weten dat, bij gebruik van goede semantiek, een tabel enkel (of voornamelijk) tabeldata zou moeten bevatten. Maar als je een tabel "te pas en te onpas" gebruikt omdat het grafisch het gewenste effect bereikt, dan lever je in op de semantiek en op hoe goed huidige software jouw site begrijpen.

Stel je een scenario voor waarin Google een van je sites spidert die volledig uit tabellen bestaat. Om goede zoekresultaten weer te geven zal Google moeten begrijpen wat jij hem wil vertellen op basis van de code, dus is Google echt tering zijn best aan het doen om te begrijpen wat voor data er in al die tabellen staat, maar hij vind daar een plaatje, en dan een woord, en dan weer een cel met een hele tabel erin, en zijn intelligentie geeft het op een gegeven moment maar op: te onduidelijk, te complex om nog meer rekentijd aan te besteden.

Google besluit de tekst letterlijk van boven naar onder te lezen, alle woorden op een grote hoop bij elkaar te zetten en ja, dit zijn dan de woorden op de site, maar wat er nou bedoeld wordt

echt geen flauw idee.
De waarheid is dat jij niet bedoelde om Google een tabel te voeren. Het was goed bedoeld, dat wel, want het zag er immers prachtig uit in de browser.

Dus, de verandering van denkwijze die de meeste hier lang geleden hebben doorstaan is van:
- Hoe kan ik grafisch weergeven wat ik weer wil geven, wat ik ontworpen heb?
naar:
- Hoe kan ik een computer vertellen wat ik eigenlijk bedoel, en tegelijk een mens vertellen wat ik bedoel, terwijl het er uit ziet zoals ik/de klant het wil?

Technologie zal alleen maar complexer en slimmer worden, maar het zal een website die enkel bestaat uit tabellen nooit kunnen lezen zoals jij hem precies hebt bedoeld, omdat het daarvoor te weinig informatie heeft. Als intelligente software besluit om tabellen voortaan alleen nog maar te lezen als er (begrijpbare, volgens jaren geleden opgestelde richtlijnen) tabeldata in staat, dan is dit nadelig voor jouw websites en daarmee voor jouw klanten. Als bepaalde functies alleen werken op sematisch opgestelde code, dan kan dit nadelig zijn voor met tabellen opgebouwde websites en nadelig voor klanten.

Ik wil niet beweren dat ik de denkwijze achter semantiek nu volledig uitgediept heb, maar ik hoop wel dat je hiermee beter begrijpt waarom vele hier denken dat je voordeel hebt van kennis van semantiek - en daarmee dus ook goede keuzes en afwegingen kunt maken bij het gebruik van HTML, divs, etc.

Iedereen hier, hoe bot ook, wil op zijn eigen manier jou in de goede richting duwen

Want zij weten: werken met tabellen is een neerwaardse spiraal. De denkwijze is veranderd, er worden applicaties gebouwd die semantische HTML verwachten, vereisen, om goed te werken. Ik kan nu niet zien wat er over 2-3 jaar gebouwd wordt op dit vlak. Ik weet wel dat semantiek een belangrijke rol zal spelen.

[edit]
Om je vraag over het lezen van websites door blinden een beetje te beantwoorden:
Er zijn waarschijnlijk websites om te testen of je HTML en CSS voldoet aan bepaalde richtlijnen daarvoor en ik denk dat er ook websites zijn die letterlijk kunnen laten zien hoe spraaksoftware een site bekijkt bv. Je kunt eens googlen naar "accessibility test".

[ Voor 4% gewijzigd door Booster op 04-08-2009 22:11 ]

The cake is a lie | The Borealis awaits...

dinsdag 4 augustus 2009 20:53

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Anoniem: 312741 schreef op dinsdag 04 augustus 2009 @ 18:12:
[...]

En ik kan niet garanderen dat ik vanaf nu eeuwig tabelloos zal blijven, hoor

Dat moet je ook vooral niet doen - tabellen zijn eindeloos nuttig voor tabulaire data

En in alle eerlijkheid heb ik ook wel een keer wat definities van tabulaire data ietwat opgerekt omdat ik iets moest uitwerken wat stomweg onmogelijk was in CSS doordat een paar van de meestgebruikte kutbrowsers geen display:table-cell ondersteunen

Professionele website nodig?

dinsdag 4 augustus 2009 21:07

Acties:

0 Henk 'm!

Soultaker

Zo gebruik ik tabellen ook, hoor. Meestal begin ik enthousiast met CSS en semantische HTML, en dan loop ik vanzelf tegen iets aan wat niet goed werkt in CSS. Dan kan ik wel een half uur gaan zitten pielen maar er komt een moment waarop ik denk fuck it, als ik een tabel gebruik, had ik een half uur geleden al klaar kunnen zijn. Niet dat ik dus een fan ben van het gebruik/misbruik van tabellen, maar het werkt wel, wat je niet altijd van CSS kunt zeggen.

Overigens zijn er verbazend goede argumenten tegen CSS te vinden door simpelweg te Googlen op CSS sucks; dit is de eerste hit: Ten reasons why CSS sucks en beschrijft eigenlijk precies wat ik ook denk (alleen punt 8, performance, vind ik eigenlijk niet heel boeiend; d.w.z. als alle andere punten in orde waren zou ik het voor lief nemen).

dinsdag 4 augustus 2009 21:22

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Soultaker schreef op dinsdag 04 augustus 2009 @ 21:07:
Overigens zijn er verbazend goede argumenten tegen CSS te vinden door simpelweg te Googlen op CSS sucks; dit is de eerste hit: Ten reasons why CSS sucks en beschrijft eigenlijk precies wat ik ook denk (alleen punt 8, performance, vind ik eigenlijk niet heel boeiend; d.w.z. als alle andere punten in orde waren zou ik het voor lief nemen).

Nofi, maar wat een onzin kraamt die gast uit

Hij heeft het alleen maar over 'design dit en design dat', terwijl webdesigners gewoon moeten doen waar ze goed in zijn, namelijk websites designen, en het bouwen gewoon aan experts over moeten laten.

Wat hij wil is een soort photoshop-wysiwyg-editor die kant-en-klare websites uitspuugt geloof ik, met minder lijkt ie niet tevreden.

Gelukkig is dat artikel al 3 jaar oud en dus ook niet meer van deze tijd.

[ Voor 27% gewijzigd door Bosmonster op 04-08-2009 21:25 ]

dinsdag 4 augustus 2009 21:47

Acties:

0 Henk 'm!

Soultaker

Bosmonster schreef op dinsdag 04 augustus 2009 @ 21:22:
Hij heeft het alleen maar over 'design dit en design dat', terwijl webdesigners gewoon moeten doen waar ze goed in zijn, namelijk websites designen, en het bouwen gewoon aan experts over moeten laten.

Zo kun je alle problemen wel goedpraten. Software engineers moeten applicaties ontwerpen en de implementatie maar assembly programmeurs overlaten. High level languages? Overbodig!

Wat hij wil is een soort photoshop-wysiwyg-editor die kant-en-klare websites uitspuugt geloof ik, met minder lijkt ie niet tevreden.

Dat heb je verkeerd begrepen; hij pleit voor precies het tegenovergestelde, namelijk een opmaaktaal waarmee designwensen zoals "centreer dit verticaal" simpel uit te drukken zijn, in plaats van allerlei low-level hacks te moeten verzinnen om dat tot stand te brengen, die vervolgens nauwelijks te editen zijn en op allerlei browsers niet werken (omdat browservendors ook niet weten wat ze er mee aanmoeten, mijn Hello world! vraagstuk is nu nog niet opgelost!)

Gelukkig is dat artikel al 3 jaar oud en dus ook niet meer van deze tijd.

Ja, gelukkig is CSS in drie jaar tijd fundamenteel veranderd, zodat we alle kritiek van drie jaar geleden volledig naast ons neer kunnen leggen.

[ Voor 4% gewijzigd door Soultaker op 04-08-2009 21:48 ]

dinsdag 4 augustus 2009 21:55

Acties:

0 Henk 'm!

Booster

Superuser

Soultaker schreef op dinsdag 04 augustus 2009 @ 21:07:
Overigens zijn er verbazend goede argumenten tegen CSS te vinden door simpelweg te Googlen op CSS sucks; dit is de eerste hit: Ten reasons why CSS sucks en beschrijft eigenlijk precies wat ik ook denk.

Het verhaal gaat over tekortkomingen van CSS ten opzichte van zijn ideaal. Het heeft niet zozeer te maken met hoe CSS slecht is, maar wat hij denkt dat de lijn van ontwikkeling over de komende tientallen jaren zou moeten zijn.

Maar ik lees in dit verhaal ook geen enkele redenen waarom je NU geen CSS zou moeten gebruiken. We hebben momenteel gewoon niks beters om te doen wat we willen doen.

De ideale taal die hij voor ogen heeft zal denk ik in zeer zware mate semantiek afdwingen. Dit proberen wij nu reeds te doen in CSS. Het gebruik van tabellen waar dit semantisch niet verantwoord is, is iets dat jarenlang is misbruikt en ja - er wordt nogsteeds hetzelfde weergegeven voor een mens, maar niet voor een machine die in grote mate afhankelijk is van die semantiek.

[ Voor 5% gewijzigd door Booster op 04-08-2009 22:12 ]

The cake is a lie | The Borealis awaits...

dinsdag 4 augustus 2009 21:58

Acties:

0 Henk 'm!

Herko_ter_Horst

Soultaker schreef op dinsdag 04 augustus 2009 @ 20:43:
Dit is ook een interessante aanpak. Overigens haal je zo maar slechts gedeeltelijk de opmaak uit de HTML, want de volgorde van de elementen in de HTML is nog steeds van essentieel belang voor de structuur van de layout (twee kolommen omdraaien kan b.v. niet).

Ik zie anders geen layout meer in mijn code

En "kolommen" omdraaien (d.w.z. content-blokken in een andere volgorde weergeven dan de volgorde waarin ze in het HTML document staan) kan prima in CSS (hoef je met tables niet te proberen, overigens).

"Any sufficiently advanced technology is indistinguishable from magic."

dinsdag 4 augustus 2009 22:05

Acties:

0 Henk 'm!

R4gnax

Soultaker schreef op dinsdag 04 augustus 2009 @ 20:43:
Trouwens, de verticale centrering werkt niet in Opera! We zijn er dus nog niet.

Ergens verbaast me dat niet, gezien de geschiedenis die Opera heeft met aan vertical alignment gerelateerde bugs in de Presto engine.

dinsdag 4 augustus 2009 22:48

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Bosmonster schreef op dinsdag 04 augustus 2009 @ 21:22:
[...]

Nofi, maar wat een onzin kraamt die gast uit

Nogal ja

Die snapt echt de hele concepten erachter niet en vind CSS kut omdat het je dwingt na te denken over dingen. Hij beschrijft inderdaad een soort ideale vorm van CSS die je rechtstreeks uit PSD's zou kunnen converteren, en gaat daarmee fundamenteel voorbij aan de hele onderliggende filosofie dat CSS bedoelt is als technologie die een andere taal (HTML is slechts 1 van de opties!) visueel aankleedt. Maar ja dat layering concept wil er sowieso niet bij 'm in want volgens punt 3 is cascading ook useless

Wat een stapel bollocks op een rijtje.....

Professionele website nodig?

dinsdag 4 augustus 2009 23:07

Acties:

0 Henk 'm!

Erkens

Fotograaf

Soultaker schreef op dinsdag 04 augustus 2009 @ 21:47:
Ja, gelukkig is CSS in drie jaar tijd fundamenteel veranderd, zodat we alle kritiek van drie jaar geleden volledig naast ons neer kunnen leggen.

Browsers zijn inderdaad de afgelopen 3 jaar niet veranderd nee

Kritiek moet je nooit volledig naast je neer leggen, heb je helemaal gelijk in, alleen 3 jaar gelden was de "kritiek" die _daar_ gegeven wordt ook al niet gegrond imo.

dinsdag 4 augustus 2009 23:22

Acties:

0 Henk 'm!

Anoniem: 273091

Bosmonster schreef op maandag 03 augustus 2009 @ 17:12:
Wow..

* Bosmonster is verbaasd dat er mensen bestaan die weigeren met de tijd mee te gaan maar zichzelf toch goede ondernemers durven noemen

Ikzelf ben student (digitale communicatie @ utrecht). Ik ben al geruime tijd bezig met het ontwikkelen van websites. (Ja, ik ken de oldskool html). en op mijn opleiding wordt ook geleerd met divjes te werken.

Ik zelf werkt ook bijna altijd met divjes. Het was even wennen maar ik raakte er aan gewend. Toch heb ik soms mijn twijfels over het "verplichte divjes gebruik". Vaak geven divjes een hele hoop extra werk. En tot slot van rekening willen browsers nog wel eens moeilijk doen.

Ik ben bij ontwerpen uitgelopen waar ik gewoon helemaal gek van werd. De ene browser doet het goed de andere niet.

Ik kan mij prima voorstellen dat een voor hele lastige gevallen afhaakt van divjes en alles in een tabel zet. De klant wil misschien wel een moderne website. Maar zal wellicht ook zeggen dat het belangrijker is dat ie op korte termijn op alle browsers werkt en stabiel is.

Ik ga hier niet een reclamecampagne voor het gebruik van tabellen opzetten maar ik denk dat deze zich wel hebben bewezen als zeer effectieve manier van werken. Ik zeg alleen dat ik mij gevallen kan voorstellen waar dit beter/handiger/onvoorkomelijk (!) is

Nu heb ik hier niet uitgebreid research naar gedaan maar stel je ontwerpt een website, je gaat uit van 2 blokken in je website. Je wilt graag dat deze even hoog zijn maar je weet niet hoe hoog. Dit hangt namelijk af van je content. Nu wil je dat deze 2 blokken beide dezelfde achtergrondkleur hebben. Tot slot van rekening werkt je ook nog met liquid design. waardoor je breedte van je blokken afhankelijk is van je gebruiker. Je kunt dus geen faux-collumns gebruiken.

Nu vraag ik mij af hoe je in de bovenstaande case onder tabellen uit wil komen. Het kan zijn dat ik iets heel simpels over het hoofd zien in dat geval zeg maar.

Mijn conclusie is dat een webontwikkelaar zoveel mogelijk met divjes moet werken. Maar wel in zijn achterhoofd moet houden dat dit niet altijd de moeite waard is en het geen schande is om soms op oude tradities terug te vallen.

dinsdag 4 augustus 2009 23:24

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Soultaker schreef op dinsdag 04 augustus 2009 @ 21:07:
[...]

Ten reasons why CSS sucks

Even een korte samenvatting daarvan:

1. [...] but browsers aren’t consistent in how they use this technology [...]
2. [...] browser compatibility [...]
3. [...] why so many browsers screw up the standard [...]
4. [...] before browsers implement them with any consistency [...]
5. [...] compatible and consistent browsers [...]
[...]
8. [...] Secondly this interpretation is very prone to errors [...]
9. [...] Then after you get one browser working you need to double back and get the other browsers working. [...]
10. If you can’t get consistency across browsers then you can’t rely on CSS to accurately and properly design your site. [...]

Kortom, op punt 6 en 7 na gaat het voornamelijk om gebrek aan goede ondersteuning en correcte implementaties van CSS. Goh, die kenden we nog niet

6 is ook een zwak punt. Natuurlijk gaan mensen op zoek naar alternatieve manieren om bepaalde stilistische dingen op te lossen zolang een technologie daar nog geen eenvoudige en eenduidige manier voor biedt. Er zijn altijd wel hacky manieren te vinden om dingen voor elkaar te krijgen, de edge van de huidige staat van de techniek op te zoeken. Natuurlijk is dat niet optimaal, maar soms is het nodig om een oplossing te gebruiken die NU werkt in plaats van te wachten op de browsers en technologie van overmorgen. Grappig detail is dat bijna elke browser tegenwoordig wel enige vorm van support heeft voor border-radius

7 is een valide punt; positionering zou eenvoudiger kunnen zijn en meer 'grid-like' voor bepaalde use-cases. Ook dat is echter een punt waar al aan gewerkt wordt in CSS3. Note dat een grid heel iets anders is dan een table. Als je een table al als een soort grid wilt zien dan is het wel een heel starre grid, met nog een hoop uitdagingen om het pixel-perfect te krijgen...

Intentionally left blank

dinsdag 4 augustus 2009 23:41

Acties:

0 Henk 'm!

Herko_ter_Horst

Anoniem: 273091 schreef op dinsdag 04 augustus 2009 @ 23:22:Ik zelf werkt ook bijna altijd met divjes. Het was even wennen maar ik raakte er aan gewend. Toch heb ik soms mijn twijfels over het "verplichte divjes gebruik". Vaak geven divjes een hele hoop extra werk. En tot slot van rekening willen browsers nog wel eens moeilijk doen.

M.i. hebben mensen die alles met divjes doen het net zo min begrepen als mensen die alles in tables stoppen. Divs zijn er om logische groeperingen aan te geven voor content die niet op een andere, syntactisch rijkere manier gegroepeerd kan worden. Dus niet voor een menu (= lijst), header (= h1/h2/...). footer (= p), e.d.

Pak de meest semantisch rijke tag die je kunt vinden.

"Any sufficiently advanced technology is indistinguishable from magic."

dinsdag 4 augustus 2009 23:48

Acties:

0 Henk 'm!

Anoniem: 273091

Herko_ter_Horst schreef op dinsdag 04 augustus 2009 @ 23:41:
[...]

M.i. hebben mensen die alles met divjes doen het net zo min begrepen als mensen die alles in tables stoppen. Divs zijn er om logische groeperingen aan te geven voor content die niet op een andere, syntactisch rijkere manier gegroepeerd kan worden. Dus niet voor een menu (= lijst), header (= h1/h2/...). footer (= p), e.d.

Pak de meest semantisch rijke tag die je kunt vinden.

met divjes bedoel ik natuurlijk semantisch design (of hoe heet dat). Ik vind 'divjes nou net iets lekkerder "bekken"'.

Alles wat ik zeg is dat als de meest semantisch rijke tag <table> is ik vind dat je die mag gebruiken.

dinsdag 4 augustus 2009 23:48

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Soultaker schreef op dinsdag 04 augustus 2009 @ 23:17:
[...]

Dat is de status van CSS na 10 jaar. En dat is dus geen klap verbeterd sinds 2007 of 1997.

[...] omdat de W3C al 10 jaar bezig is met CSS erdoor te drukken wat grote moeite kost en allerlei fundamentele problemen onopgelost laat.

Als we het daar over eens kunnen zijn, ben ik tevreden.

Ik ben het deels met je eens dat de techniek an sich hier en daar nog te wensen overlaat. Gelukkig maar zou ik zeggen, anders zou het toch ook saai worden allemaal

Maar 10 jaar is op zich nog niet zo heel erg lang. Webdesign is nog steeds een technologie die in de kinderschoenen staat en dus ook gekampt gaat met kinderziektes. We zitten imo op de goede weg, met een nogal moeizame weg achter ons. Als browserbouwers zich tien jaar geleden meer hadden gefocussed op standaardisatie en verbetering van de technologie in plaats van elkaar het leven zuur proberen te maken en uit de markt proberen te drukken, en vervolgens na het verkrijgen van een bijna-monopolie alle voortgang laten stagneren totdat de concurrentie teruggekrabbelt was, dan waren we nu al een stuk verder geweest.

Laat onverlet dat CSS, ook voor layout, gewoon veel voordelen biedt zodra je een beetje de truukjes en kneepjes kent. Uiteraard zijn er gevallen te bedenken die in CSS lastig op te lossen zijn, maar andersom zijn er destemeer gevallen waarbij layout dmv markup (vnl tables dus) gewoon kut is...

Intentionally left blank

dinsdag 4 augustus 2009 23:50

Acties:

0 Henk 'm!

TeeDee

CQB 241

Anoniem: 273091 schreef op dinsdag 04 augustus 2009 @ 23:22:
[...]
divjes, divjes en nog eens divjes.

Werken met 'divjes' staat niet gelijk aan semantisch correcte html.

Verder wil ik heeuuul even gauw het 'Soultaker' voorbeeld aanstippen: dat dit niet makkelijk te doen is zonder tables ben ik met je eens. Neemt nog niet weg dat je met dat voorbeeld maar moet besluiten om alsnog volledig in tables te gaan werken. En ja, ik weet dat ik met deze opmerking ook reacties krijg maar toch

Ik hoop dat je het begrijpt.

Je zou bijna zeggen: the right tool for the job. Pragmatisch gezegd: jouw lastige voorbeeld los je blijkbaar het makkelijkst op met een table. Soit, laten we, (mag ik dat zeggen, ja dat mag ik zeggen </mart>) dat dan vooral doen. Maar in godsnaam, het begin punt moet zijn (in relatie tot de discussie): een table gebruiken om je layout snel in elkaar te zetten is het verkeerde startpunt.

Hetzelfde gaat ook op voor het hele validatie stuk. Je ziet vaak iets als

HTML:

1	<img src="melp.jpg" alt="" />

waarbij het alt attribuut expliciet leeg gelaten wordt om maar door die validator heen te komen. Men kan dan zeggen: Hey, het geeft 0 errors en 0 warning. FFS waar hebben we het dan over.

Ik ben op dit moment erg druk bezig met het releasen van een volledige business applicatie in silverlight. Als ik daar alle workarounds vanwege brakkigheden in het framework moet gaan opnoemen kom ik dik boven de 64K limiet van React heen. Deal with it! We zijn destijds begonnen met SL 1.1. SL3 geeft goede hoop dat alle voorheen geimplementeerde workarounds weg kunnen. Dat is k.u.t. en zonde van de tijd, maar inmiddels, doordat we alle andere zaken netjes ingebouwd hebben, is het weghalen van de workarounds minder ingrijpend en beter beheersbaar.

Heart..pumps blood.Has nothing to do with emotion! Bored

dinsdag 4 augustus 2009 23:58

Acties:

0 Henk 'm!

Anoniem: 273091

TeeDee schreef op dinsdag 04 augustus 2009 @ 23:50:
bladiebladiebla

maar je hebt designers en ontwikkelaars. en als een ontwikkelaar zegt "ontwerp maar iets anders, dit is moeilijk of niet correct" dan heeft de designer daar weinig boodschap aan. En als het dan uiteindelijk bij de ontwikkelaar uitkomt. Moet ie toch met tables gaan werken (ik kan geen andere manier verzinnen die niet idioot is).

Of moetie dan zeggen dat het hele design over moet gedaan omdat ie niet met een table tag wil werken?

woensdag 5 augustus 2009 00:02

Acties:

0 Henk 'm!

ValHallASW

Soultaker schreef op dinsdag 04 augustus 2009 @ 21:07:
Dan kan ik wel een half uur gaan zitten pielen maar er komt een moment waarop ik denk fuck it, als ik een tabel gebruik, had ik een half uur geleden al klaar kunnen zijn.

http://giveupandusetables.com/

Verder even een punt uit mijn ervaring: CSS is gewoon verdomd moeilijk om goed onder de knie te krijgen. De basis is simpel, maar helaas is dat ook waar de gemiddelde CSS-tutorial ophoudt. En dan? Proberen is in het algemeen vruchteloos, want je moet, zoals uit de post van R4gnax duidelijk blijkt, precies de goede code weten. Feest.

Wat dat betreft doet het een beetje aan LaTeX denken: de basis is helemaal niet moeilijk maar zogauw je iets wilt dat niet basaal is dan heb je opeens een enorm stijle leercurve.

woensdag 5 augustus 2009 00:02

Acties:

0 Henk 'm!

TeeDee

CQB 241

Anoniem: 273091 schreef op dinsdag 04 augustus 2009 @ 23:58:
[...]

maar je hebt designers en ontwikkelaars. en als een ontwikkelaar zegt "ontwerp maar iets anders, dit is moeilijk of niet correct" dan heeft de designer daar weinig boodschap aan. En als het dan uiteindelijk bij de ontwikkelaar uitkomt. Moet ie toch met tables gaan werken (ik kan geen andere manier verzinnen die niet idioot is).

Of moetie dan zeggen dat het hele design over moet gedaan omdat ie niet met een table tag wil werken?

Vind je het heel erg als ik je vraag/reactie/opmerking niet begrijp? Heb je trouwens mijn 'bladiebladiebla' wel goed gelezen?

Heart..pumps blood.Has nothing to do with emotion! Bored

woensdag 5 augustus 2009 00:04

Acties:

0 Henk 'm!

Herko_ter_Horst

Ok, alweer veel te lang mee bezig geweest, maar toch nog even een kleine uitbreiding van mijn eerdere oplossing, die nu óók werkt in IE 6 en 7, naast de al eerder getestte IE8, FF3.5, Chrome 2.0 en Opera 9.

De (validerende) code:

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />

    <title>CSS Center demo</title>

    <link title="Basic" rel="stylesheet" type="text/css" href="all.css" media="all" />
    <!--[if lt IE 8]>
    <link title="Basic" rel="stylesheet" type="text/css" href="ie-old.css" media="all" />
    <![endif]-->
</head>

<body>
    <div class="content">
        <div class="splash">
                <p>Hello World!</p>
                <img src="http://www.tweakers.net/ext/i.dsp/1117631389.png" alt="Gathering of Tweakers logo" />
                <p>Oh my!</p>
        </div>
    </div>

    <p class="footer">Copyright 2009 &copy; Herko ter Horst</p>
</body>

</html>

Cascading Stylesheet: all.css

html {
    display: table;

    margin: 0;
    width: 100%;
    height: 100%;
}

body {
    display: table-cell;

    margin: 0;

    text-align: center;
    vertical-align: middle;
}

.footer {
    position: absolute;
    left: 0;
    bottom: 0;

    width: 100%;

    text-align: center;

    color: #666;
    font-family: sans-serif;
    font-size: smaller;
}

Cascading Stylesheet: ie-old.css

.content {
    position: absolute;
    top: 50%;
    left: 0;

    width: 100%;
}

.splash {
    position: relative;
    top: -50%;
    left: 0px;
}

Om backwards-compatible te kunnen zijn, heb ik helaas (naast een IE6/7-specifieke stylesheet) één div teveel nodig, naar mijn smaak. De <div class="splash"> heb je al gauw nodig om bijv. het onderscheid te maken met de footer (de copyright notice), dus die vind ik semantisch verdedigbaar. De <div class="content"> wordt alleen gebruikt om IE 6/7 specifieke style aan op te hangen. Dat is jammer, maar voor dit specifieke geval m.i. onvermijdelijk.

Vertical alignment heeft niet het gemak van oldskool tables, dat is duidelijk. Grotendeels ligt dat aan slechte ondersteuning van bepaalde CSS features in browsers, want "display: table" blijkt prima te voldoen. Maar goed, je kan ook niet verwachten dat een spec uit 1997 nu al in alle browsers zit, natuurlijk

Overigens wordt vertical alignment een stuk simpeler als je op de een of andere manier de hoogte van de content weet (in procenten of pixels). Dan wordt het namelijk vrij eenvoudig om met een position top van 50% en een negatieve marge van de halve content-hoogte de boel op z'n plaats te zetten.

Dus ja, je moet weten wat je doet. Maar als ik als amateur dit in een avondje uitgezocht en getest heb, mag ik van professionals verwachten dat ze dit zeker ook kunnen. En als je even verder kijkt dan dit hele specifieke issue, kun je zeggen dat 95% van de layouts die je zou willen, prima binnen de mogelijkheden van de CSS ondersteuning in redelijk recente browsers past.

"Any sufficiently advanced technology is indistinguishable from magic."

woensdag 5 augustus 2009 00:04

Acties:

0 Henk 'm!

Cartman!

Goede designers weten ook wel wat wel en niet kan imo (iemand bij ons had het fantastische idee om een vogeltje door t scherm te laten vliegen

wat uiteraard gesneuveld is). En soms moet je inderdaad even meer je best doen dan bij andere projecten om toch dat lastige dingetje op te lossen.

woensdag 5 augustus 2009 00:08

Acties:

0 Henk 'm!

Herko_ter_Horst

Anoniem: 273091 schreef op dinsdag 04 augustus 2009 @ 23:48:
[...]

met divjes bedoel ik natuurlijk semantisch design (of hoe heet dat). Ik vind 'divjes nou net iets lekkerder "bekken"'.

Ik reageerde er even op, omdat je (te) vaak ziet dat mensen hun table gaan herbouwen met <div>s. Dat is dus pertinent niet de bedoeling.

Alles wat ik zeg is dat als de meest semantisch rijke tag <table> is ik vind dat je die mag gebruiken.

Uiteraard is table een prima instrument om tabulaire data mee weer te geven. Het is alleen niet het geeigende instrument om anderssoortige data in de vorm van een table mee te layouten.

"Any sufficiently advanced technology is indistinguishable from magic."

woensdag 5 augustus 2009 00:09

Acties:

0 Henk 'm!

Anoniem: 273091

Herko_ter_Horst schreef op woensdag 05 augustus 2009 @ 00:08:
[...]

Ik reageerde er even op, omdat je (te) vaak ziet dat mensen hun table gaan herbouwen met <div>s. Dat is dus pertinent niet de bedoeling.

[...]

Uiteraard is table een prima instrument om tabulaire data mee weer te geven. Het is alleen niet het geeigende instrument om anderssoortige data in de vorm van een table mee te layouten.

tenzij er eigenlijk geen andere manier, is dan mag je best op deze oude traditie terugvallen.

woensdag 5 augustus 2009 00:16

Acties:

0 Henk 'm!

Herko_ter_Horst

Anoniem: 273091 schreef op woensdag 05 augustus 2009 @ 00:09:
[...]

tenzij er eigenlijk geen andere manier, is dan mag je best op deze oude traditie terugvallen.

Ach ja, "mag"... van mij "mag" alles

. Ik zal er zelf alles aan doen om niet terug te vallen (en ik moet de situatie nog tegenkomen die echt pertinent niet oplosbaar is - uiteraard zonder al te grote hacks: ik vind conditional comments om IE-specifieke styling te doen nog aanvaardbaar, maar CSS parsing hacks gaan me te ver).

"Any sufficiently advanced technology is indistinguishable from magic."

woensdag 5 augustus 2009 00:24

Acties:

0 Henk 'm!

Booster

Superuser

Soultaker schreef op dinsdag 04 augustus 2009 @ 23:17:
Maar ik heb misshcien wel het simpelst mogelijke voorbeeld van een tabelgebaseerde voorbeeldpagina gegeven. Echt strontsimpel. En nog niemand heeft kunnen laten zien hoe die pagina met CSS geïmplementeerd had moeten worden zo dat 'ie werkt in alle major browsers. De beste benadering werkt niet in Opera 10 (geen oude browser dus) en is sowieso al behoorlijk vergezocht. Dat is de status van CSS na 10 jaar.

Ik ben hierin met crisp: we zitten op de goede weg. Als wij ons laten terugvallen tot technologie uit 1997 dan hebben browserontwikkelaars ook geen rede meer om te zorgen dat het gewoon in orde komt. De positie van de webdevvers nogal veranderd ten opzichte van 10 jaar terug.

Je kunt nu als webdevver een beetje een een-tweetje spelen met de software-ontwikkelaars. Als ze iets ontwikkelen zoals dat de bedoeling is dan ga je ervoor en tik je de bal terug met opbouwende kritiek, etc. Maar als zij de bal gewoon op een hopeloze manier spelen dan kunnen we nu makkelijker zeggen: stik er maar in, ik neem wel een speler die de bal wel fatsoenlijk speelt.

Als dat stukje code om de boel te centreren in alle browsers doet wat het zou moeten doen (en dat is niet persee datgene wat je wil zien

) behalve in Opera, dan stikt Opera er wat mij betreft maar in. Dan werkt het niet in Opera, gebruikers merken dat het niet werkt in Opera. Fix het maar en kom dan maar terug. 10 jaar geleden was dat een stuk lastiger.

Ik bestrijd dus twee dingen: ten eerste, dat CSS en sich zo geweldig is; het ontwerp is slecht, maakt allerlei dingen onmogelijk of nodeloos ingewikkeld

Dat de implementatie van CSS in browsers in sommige gevallen echt te wensen over laat kan ik met je eens zijn. Maar kun jij iets noemen dat in CSS -door het ontwerp van CSS- onmogelijk is terwijl hier in HTML goede oplossingen voor zijn?

Ten tweede, dat het gebruik van gridlayouts met spacing e.d. fundamenteel verkeerd is. Het is gewoon een zinnige aanpak.

Als je semantiek naast je neerlegt dan is het misschien een zinnige aanpak. De kans dat een machine er kaas van kan maken zonder semantiek is klein en semantiek is nou eenmaal iets dat steeds crucialer wordt.

The cake is a lie | The Borealis awaits...

woensdag 5 augustus 2009 01:11

Acties:

0 Henk 'm!

Gomez12

ValHallASW schreef op woensdag 05 augustus 2009 @ 00:02:
[...]
http://giveupandusetables.com/

Verder even een punt uit mijn ervaring: CSS is gewoon verdomd moeilijk om goed onder de knie te krijgen. De basis is simpel, maar helaas is dat ook waar de gemiddelde CSS-tutorial ophoudt. En dan? Proberen is in het algemeen vruchteloos, want je moet, zoals uit de post van R4gnax duidelijk blijkt, precies de goede code weten. Feest.

Good things are easy to learn, hard to master...

Serieuze vraag voor de table-fans hier. Kan ik voor een cel een max-width/max-height opgeven waar elke browser zich aan houdt? Want mijn grootste probleem met tables is altijd geweest dat als iemand een te lang woord in een cel gooide dat dan de layout om zeep ging.
Minimale breedte / hoogte is nooit een probleem, maar maximale leek IE altijd compleet te negeren...

woensdag 5 augustus 2009 01:13

Acties:

0 Henk 'm!

Herko_ter_Horst

Soultaker schreef op dinsdag 04 augustus 2009 @ 23:17:
Maar ik heb misshcien wel het simpelst mogelijke voorbeeld van een tabelgebaseerde voorbeeldpagina gegeven. Echt strontsimpel. En nog niemand heeft kunnen laten zien hoe die pagina met CSS geïmplementeerd had moeten worden zo dat 'ie werkt in alle major browsers. De beste benadering werkt niet in Opera 10 (geen oude browser dus) en is sowieso al behoorlijk vergezocht. Dat is de status van CSS na 10 jaar. En dat is dus geen klap verbeterd sinds 2007 of 1997.

Laten we wel wezen: tot zeg 2005 (de release van FireFox 1.5) was er simpelweg geen serieus alternatief voor Internet Explorer. Dus vroeg ook niemand (gebruikers noch developers) om iets anders dan dat het werkte in IE. Microsoft kon het zich dus veroorloven om standaarden naast zich neer te leggen, uit te breiden en er in het algemeen een potje van te maken. Pas nu andere browsers, met Firefox voorop, maar ook Safari en (vanuit Microsoft-oogpunt zeker niet onbelangrijk) Chrome, een goed, standards-compatibe alternatief vormen, komt Microsoft ineens in korte tijd eerst met IE7 en nu met IE8, waarin qua standaarden echt megastappen vooruit zijn gemaakt. Er is dus heel veel verbeterd.

Ik heb denk ik hierboven laten zien dat er een goede oplossing is voor verticaal centreren in compatible browsers en een "redelijke" work-around voor IE 6/7. Dit was 10 jaar geleden niet mogelijk geweest.

Bovendien focussen we nu wel heel erg op dat ene dingetje (verticaal centreren). Wat er allemaal veel makkelijk gaat met CSS (t.o.v. layout in je HTML stoppen) komt niet eens ter sprake, om nog maar te zwijgen van dingen die met CSS kunnen waar helemaal geen "traditioneel" alternatief voor is.

Standaarden winnen aan kracht met elke gebruiker ervan.

"Any sufficiently advanced technology is indistinguishable from magic."

woensdag 5 augustus 2009 01:23

Acties:

0 Henk 'm!

ValHallASW

Gomez12 schreef op woensdag 05 augustus 2009 @ 01:11:
Good things are easy to learn, hard to master...

Dus je wilt aangeven dat CSS eigenlijk veel tijd kost voor weinig resultaat? Het originele citaat is namelijk

quote: Nolan Bushnell
All the best games are easy to learn and difficult to master. They should reward the first quarter and the hundredth.

en het is niet voor niets dat dat citaat op spellen slaat. Spellen zijn namelijk bedoeld als tijdsverdrijf. Je zorgt ervoor dat mensen in het makkelijke gedeelte verslaafd raken maar niet het spel 1-2-3 uitspelen.
Dit is nogal iets anders dan wat CSS - in ieder geval wat mij betreft - zou moeten zijn. CSS is niet leuk namelijk: CSS is een middel om een doel te bereiken. Dan is het dus alleen maar strontvervelend dat je het niet 1-2-3 onder de knie hebt.

woensdag 5 augustus 2009 01:32

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Soultaker schreef op dinsdag 04 augustus 2009 @ 23:08:
[...]

Misschien niet verbazend, maar de tabelgebaseerde layout werk feilloos in die en alle andere genoemde browsers.

Wat wel verbazend is is dat jij merendeel van de genoemde argumenten tegen table-based layouts onder tafel veegt op basis van 1 onzinnig voorbeeld dat in de praktijk letterlijk nooit voor komt. Want je hebt met je, zeg eerlijk, onzinnige voorbeeld zo ongeveer de enige praktijkcase van een table-based layout geproduceerd die naar behoren print, bruikbaar is op handheld browsers met kleine schermen, semantisch net zo lekker door zoekmachines opgepikt wordt als CSS-based alternatieven, geen problemen heeft met skinning, custom templates of toekomstige layoutwijzigingen en goed functioneert in voorlees- of braillebrowsers. Dus okee, gebruik een table for all I care, in je supercentered Hello World is een table net zo verdedigbaar als 50 regels CSS. Ga nu even een grote established site nabouwen in tables zonder alle bovengenoemde nadelen er inherent in te bakken. Suc-ces.

Professionele website nodig?

woensdag 5 augustus 2009 02:18

Acties:

0 Henk 'm!

Gomez12

ValHallASW schreef op woensdag 05 augustus 2009 @ 01:23:
[...]

Dus je wilt aangeven dat CSS eigenlijk veel tijd kost voor weinig resultaat?

Op dit moment wel ja.
Op de lange termijn ga je er steeds meer voordeel uithalen ( qua onderhoud etc. ) maar op de korte termijn als je snel even een website op wil zetten en je bent er niet bekend mee, dan kost het gewoon te veel tijd tegenover te weinig resultaat

Totdat je klant een andere layout wil / een aparte print-wens heeft / een mobiele site etc wil kost het leren enkel extra tijd.

Imho is het gewoon een goede basis neerleggen voor de toekomst, en dit is gewoon een investering.

Qua SEO etc dat valt allemaal ook wel bijna 100% te bereiken binnen een table layout. Mits juist gebruikt levert een h1 etc. binnen cells gewoon net zoveel SEO op als buiten cells.

[...]
Dit is nogal iets anders dan wat CSS - in ieder geval wat mij betreft - zou moeten zijn. CSS is niet leuk namelijk: CSS is een middel om een doel te bereiken. Dan is het dus alleen maar strontvervelend dat je het niet 1-2-3 onder de knie hebt.

Tja, tables had je misschien wel 1-2-3 onder de knie, maar het helpt je niets verder. Tables vind ik juist strontvervelend, enkel repeterende dingen die 100% hetzelfde doen en als je net even een vierkantje van 4 cellen wat groter / kleiner wilt hebben dan kan je weer een nieuwe table erin douwen, nee geef me dan maar css waar ik gewoon 1 element onafhankelijk van de rest 1 pixel groter / kleiner kan maken...

Kijk, als je er nu nog mee moet beginnen dan kan ik me voorstellen dat het strontvervelend is ( het is heel veel in 1x af / aanleren ). Maar ja, dan had je imho maar eerder ermee moeten beginnen zodat je het in een rustiger tempo kon leren.

woensdag 5 augustus 2009 02:20

Acties:

0 Henk 'm!

Soultaker

curry684 schreef op woensdag 05 augustus 2009 @ 01:32:
Wat wel verbazend is is dat jij merendeel van de genoemde argumenten tegen table-based layouts onder tafel veegt op basis van 1 onzinnig voorbeeld dat in de praktijk letterlijk nooit voor komt. Want je hebt met je, zeg eerlijk, onzinnige voorbeeld [..]

Je kunt hard roepen dat het onzinnig is en niet voorkomt, maar niets is minder waar. Ik wil regelmatig dingen verticaal centreren en zelfs in dit topic hebben anderen ook die wens geuit. Ja, dit is maar één voorbeeld, maar het is exemplarisch voor de moeite die het kost om dingen die voorheen eenvoudig waren goed werkend te krijgen in CSS. Zelfs Herko_ter_Horst had een tweede poging nodig om een werkende oplossing te fabriceren, die vele malen ingewikkelder is en behoorlijk onintuïtief (naar mijn idee).

Het gaat me er helemaal niet om op basis van één voorbeeld CSS naar de prullenbak te verwijzen (wat sowieso niet het doel was) maar als je dit voorbeeld goed bekeken hebt en nog steeds denkt dat alles makkelijker en beter met CSS kan dan heb je een flink bord voor je kop (om je maar op gelijke toon van repliek te dienen).

[..] semantisch net zo lekker door zoekmachines opgepikt wordt als CSS-based alternatieven [..]

Is er ook enig bewijs dat Google tabellayouten niet zo makkelijk parset als semantische documenten? Als ik een crawler schreef zou ik beginnen met alle tags uit 't document te gooien en alleen de inhoud te indexeren, en die is natuurlijk gelijk.

... die naar behoren print, bruikbaar is op handheld browsers met kleine schermen ...

Dit zijn gevallen waarbij CSS (of eigenlijk de mogelijkheid om meerdere stylesheets aan een pagina te koppelen) een duidelijk voordeel bieden. Maar goed, dat voordeel heb je ook als je de tabellayout in je CSS verwerkt (met display:table-cell enzo). Overigens heeft minstens 90% van de pagina's op het internet maar één stylesheet, en de veel nieuws/review-achtige sites bieden ook printversies van pagina's zonder een aparte stylesheet te gebruiken, dus dit soort features lijken meer af te hangen van de moeite die de webontwikkelaar in z'n site wil steken dan wat de gebruikte layouttechniek was.

offtopic:
Overigens kan ik me behoorlijk ergeren aan mensen die het woord "letterlijk" gebruiken terwijl ze juist figuurlijk bedoelen, of wilde je serieus beweren dat nog nooit iemand in de historie van het internet een element verticaal heeft willen centreren op een website?

[ Voor 3% gewijzigd door Soultaker op 05-08-2009 02:23 ]

woensdag 5 augustus 2009 02:55

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Soultaker schreef op woensdag 05 augustus 2009 @ 02:20:
[...]

Je kunt hard roepen dat het onzinnig is en niet voorkomt, maar niets is minder waar. Ik wil regelmatig dingen verticaal centreren en zelfs in dit topic hebben anderen ook die wens geuit. Ja, dit is maar één voorbeeld, maar het is exemplarisch voor de moeite die het kost om dingen die voorheen eenvoudig waren goed werkend te krijgen in CSS.

Ik zie d'r weinig exemplarisch aan eigenlijk, nogal een verkeerd woord voor een van de weinige dingen die in tables handiger gaat dan in CSS, met name omdat het niet om een limitatie gaat van CSS maar van een aantal brakke browserengines die CSS slecht implementeren. De stelling dat CSS om die reden fout/slecht/brak/whatever zou zijn is net zo zot als stellen dat wetgeving tegen doodslag slecht is omdat er mensen zijn die zich er niet aan houden. De regels zijn goed, de browsers die het overtreden niet. Content verticaal centreren is simpelweg een gevalletje van display:table-cell;vertical-align:center op de container, indien de browser de display:table-cell property correct implementeert. Wat in alle gevallen werkt behalve in een bepaalde browser van een bepaald bedrijf uit Redmond, Washington.

een flink bord voor je kop (om je maar op gelijke toon van repliek te dienen).

Tsk speel ik eens niet op de man krijg ik het wel terug

Is er ook enig bewijs dat Google tabellayouten niet zo makkelijk parset als semantische documenten? Als ik een crawler schreef zou ik beginnen met alle tags uit 't document te gooien en alleen de inhoud te indexeren, en die is natuurlijk gelijk.

Ja fijn, zo werkten crawlers in 1996 toen Altavista nog gaaf was. Tegenwoordig snappen browsers wel dat headers (hX), titles e.d. belangrijker zijn dan random content van de pagina, waardoor ze contextueel beter kunnen adviseren dat een pagina die openlijk aankondigt over iets te praten relevanter is dan een pagina die je trefwoord toevallig ergens verstopt in een voetnoot heeft staan, en waar je merkbare Googlepluspunten krijgt als links naar je pagina in title of innerText keywords hebben staan die ook op je site terugkomen. Omdat Googlebot snapt wat een link is kan hij die contextuele waarde goed afleiden en toepassen.

Overigens klopt uberhaupt je basisstelling niet dat de content 'gelijk' is. In een tablebased layout is je HTML gevormd op basis van layout, in een CSS-based layout probeer je semantiek zo toe te passen dat de meest relevante content vooraan in het document staat. Dit omdat Googlebot en andere crawlers wel degelijk snappen dat er zoiets bestaat als F-shaped heatmap patterns en z'n crawling dus aanpast naar wat de uiteindelijke gebruikers interpreteren.

Dit zijn gevallen waarbij CSS (of eigenlijk de mogelijkheid om meerdere stylesheets aan een pagina te koppelen) een duidelijk voordeel bieden.

Typisch dat je de alternatieve non-screen browsers die ik noem compleet negeer. Omdat inderdaad juist die veel aanwijsbare baat hebben bij semantische content tegenover layoutbased content zoals je met tables per definitie hebt. Gelukkig hoeven blinden niet het internet op te kunnen, nergens voor nodig.

offtopic:
Overigens kan ik me behoorlijk ergeren aan mensen die het woord "letterlijk" gebruiken terwijl ze juist figuurlijk bedoelen, of wilde je serieus beweren dat nog nooit iemand in de historie van het internet een element verticaal heeft willen centreren op een website?

Neuj letterlijk was letterlijk bedoeld als zijnde relevant voor je voorbeeld: mensen die een website verticaal willen centreren snappen imnsho het medium 'web' niet. Webpages renderen topdown zodat ze flexibel met dingen kunnen omgaan, zoals gebruikers met afwijkende DPI-instellingen, of missende fonts, of dynamisch inzoomen op specifieke elementen ten behoeve van visueel gehandicapten etc. Verticaal willen centreren houdt automatisch in dat je aannames doet ten aanzien van het verticale formaat van de omliggende container, en die ga je overtreden als er dingen afwijken van wat een slechte webdesigner had verwacht. Namelijk dat bij iedereen een bepaald lettertype even groot is en er geen plugins zoals Skype zijn die actief content groter maken in IE etc. etc.

Webdesign is een kwestie van een site ontwerpen die in alle situaties acceptabel rendert. Verticaal centreren hoort daar door z'n hele natuur niet in thuis zolang wij horizontaal lezen.

[ Voor 9% gewijzigd door curry684 op 05-08-2009 03:00 ]

Professionele website nodig?

woensdag 5 augustus 2009 10:24

Acties:

0 Henk 'm!

moozzuzz

Heb het grootste deel van dit (afgesplitste) topic gelezen en moet zeggen dat het CSS/semantisch kamp soms toch de wereld iets te idealistisch voorstelt. Wat de reden ook moge zijn (slechte standaard of implementatie of mijn schoonmoeder) CSS had en heeft enkele tekortkomingen en kan niet alle trends volgen. Het is beter dit te erkennen en zich niet te verstoppen achter excuses. Het Table-kamp vergeet dan weer de ellende van het slicen waar we vroeger zo'n _plezier_ mee hadden...

curry684 schreef op woensdag 05 augustus 2009 @ 02:55:
Neuj letterlijk was letterlijk bedoeld als zijnde relevant voor je voorbeeld: mensen die een website verticaal willen centreren snappen imnsho het medium 'web' niet. Webpages renderen topdown zodat ze flexibel met dingen kunnen omgaan, zoals gebruikers met afwijkende DPI-instellingen, of missende fonts, of dynamisch inzoomen op specifieke elementen ten behoeve van visueel gehandicapten etc. Verticaal willen centreren houdt automatisch in dat je aannames doet ten aanzien van het verticale formaat van de omliggende container, en die ga je overtreden als er dingen afwijken van wat een slechte webdesigner had verwacht.

Mijn insziens ligt er inderdaad (het)een belangrijk(ste) probleem bij de mensen die websites ontwerpen. Veelal zijn het grafisch designers die fantastische exotisch-arty flyers kunnen maken en diezelfde stijl look willen zien op hun website. Ook de klant-kant, (die overigens niets te verwijten valt: zij hebben immers een eeuw aan een stuk flyers en affiches ingekocht en moeten nu ineens ook online actief worden) leeft nog teveel in de mijn-flyer-moet-online-wereld.

Als er dan zo'n design voor je neus komt kan je

... het terugsturen van waar het komt (niet zo realistisch medunkt)
... toch maar vlug een tabelletje gebruiken tot je een beter oplossing tegenkomt
... hacken en divven tot het toch werkt in IE6

Ik wil geenszins de oude table-only cultuur verdedigen maar mss moeten we een klein oogje dichtknijpen voor frontenders die opgescheept zitten met bovenvermelde ontwerpers

offtopic:
spacer.gif's dat is pas not-done (dat hoeft zelfs niet bij table-only-uitvoeringen)

woensdag 5 augustus 2009 11:55

Acties:

0 Henk 'm!

R4gnax

Booster schreef op woensdag 05 augustus 2009 @ 00:24:
Als dat stukje code om de boel te centreren in alle browsers doet wat het zou moeten doen (en dat is niet persee datgene wat je wil zien ) behalve in Opera, dan stikt Opera er wat mij betreft maar in. Dan werkt het niet in Opera, gebruikers merken dat het niet werkt in Opera. Fix het maar en kom dan maar terug. 10 jaar geleden was dat een stuk lastiger.

Precies mijn mening.

Mijn voorbeeld bevat de hasLayout hack voor IE, omdat dit standards-compliant inline-block gedrag naspeelt en verder niet met de standaard breekt. Je kunt deze ook netter triggeren via een conditional comment en aparte stylesheet, uiteraard. En deze makkelijk instelbaar maken voor versies van IE die inline-block wel gaan ondersteunen. Daarnaast verandert er in de feitelijke semantische markup niets om een IE hack te faciliteren en zal daar niets omgeschreven hoeven worden. Het is dus een oplossing die forward compatible is, omdat hij zich aan de standaarden houdt.

Herko_ter_Horst's aanpak voor IE voldoet daarentegen niet aan de standaarden, maar maakt expliciet misbruik van een bekende layout bug met betrek tot position: relative en procentuele offsets. Onder bepaalde omstandigheden zal IE deze procentuele offsets foutief interpreteren als een percentage van de dimensies van het element zelf i.p.v. de dimensies van de parent van het element, zoals de standaarden voor schrijven.

E.e.a. is heel wat minder forward compatible. Wat doe je wanneer deze positionerings bug in IE gefixed wordt? Kun je garanderen dat tegen die tijd display: table en display: table-cell ondersteund gaan worden? Zo niet, dan kun je toch echt je hele idee weg gaan gooien en iets nieuws gaan verzinnen...

Ik ben het met anderen eens dat dit wel illustratief is voor het feit dat CSS sommige zaken niet goed af dekt en af en toe echt kennis van zaken eist. (Zoals ik al eerder zei: simpel hoeft niet intuitief te zijn.) Wat we alleen niet moeten vergeten is dat het een opmaak taal is die verzonnen is om hypertekst op te maken. Niet om allerlei fancy verticaal-op-pagina gecentreerde oplossingen te bouwen, wat eigenlijk totaal geen plaats heeft in de notie van hypertekst.

HTML+CSS zijn eigenlijk van hun originele intentie razend snel uitgegroeid naar het de facto middel om content op het web aan te bieden. En ja; dan krijg je groei pijntjes...

[ Voor 6% gewijzigd door R4gnax op 05-08-2009 12:00 ]

woensdag 5 augustus 2009 11:58

Acties:

0 Henk 'm!

Booster

Superuser

Soultaker schreef op woensdag 05 augustus 2009 @ 02:20:
Als ik een crawler schreef zou ik beginnen met alle tags uit 't document te gooien en alleen de inhoud te indexeren, en die is natuurlijk gelijk.

Dan leg je dus echt het volledige voordeel van semantiek naast je neer? Dit is waar Google en anderen vele slimme dingen uit af kunnen leiden en gebruiken om prioriteiten te stellen. Dat zou je allemaal verliezen in jouw voorstel.

The cake is a lie | The Borealis awaits...

woensdag 5 augustus 2009 11:59

Acties:

0 Henk 'm!

curry684

left part of the evil twins

moozzuzz schreef op woensdag 05 augustus 2009 @ 10:24:
Mijn insziens ligt er inderdaad (het)een belangrijk(ste) probleem bij de mensen die websites ontwerpen. Veelal zijn het grafisch designers die fantastische exotisch-arty flyers kunnen maken en diezelfde stijl look willen zien op hun website. Ook de klant-kant, (die overigens niets te verwijten valt: zij hebben immers een eeuw aan een stuk flyers en affiches ingekocht en moeten nu ineens ook online actief worden) leeft nog teveel in de mijn-flyer-moet-online-wereld.

Als er dan zo'n design voor je neus komt kan je
... het terugsturen van waar het komt (niet zo realistisch medunkt)
... toch maar vlug een tabelletje gebruiken tot je een beter oplossing tegenkomt
... hacken en divven tot het toch werkt in IE6
Ik wil geenszins de oude table-only cultuur verdedigen maar mss moeten we een klein oogje dichtknijpen voor frontenders die opgescheept zitten met bovenvermelde ontwerpers

Oh dit kan ik alleen maar enorm hard onderschrijven... bij ons staat in de offertes waarbij wij niet het ontwerp verzorgen intussen enorm expliciet dat wij het recht voorbehouden om ieder extern aangeleverd ontwerp te weigeren. Dit nadat we echt meermaals walgelijke Illustrator-bestanden binnen hebben gehad die resolutietechnisch niet te corrigeren zijn, brak gelayerd zijn, alle good-practices van webdesign negeren ten faveure van 'klassiek flyerdesign', en to top it all off stijf staan van constructies die stomweg niet realistisch kunnen op een website anno 2009. Ik heb soms nog nachtmerries van contentblocks met een gradient en ronde hoekjes op een achtergrond met een andere gradient....

Wij weigeren dus gewoon slecht extern ontwerp met uitgebreide onderbouwing. Goed gelayerde PSD's die technisch haalbaar zijn of reply met 'werk nog maar even door'.

[ Voor 4% gewijzigd door curry684 op 05-08-2009 12:00 ]

Professionele website nodig?

woensdag 5 augustus 2009 14:46

Acties:

0 Henk 'm!

Yoozer

minimoog

trinite_t schreef op dinsdag 04 augustus 2009 @ 11:39:
Mochten er vragen zijn, DM gerust.

Heij!

* Yoozer schopt

Waar denk je dat een forum voor is? Juist, voor mensen die met hetzelfde probleem zitten ook nog te helpen omdat hun oplossing publiek gepubliceerd wordt. Er zijn hier een paar voorwaarden aan het starten van een topic, maar als je netjes neerzet "nou, ik werk al 7.5 jaar met tabellen en wil nu wel eens een goede set best practices" en zo lijkt het me toch dat 'ie niet op slot gemikt wordt.

DMs verstoppen dit soort informatie. DMs gebruik je voor het soort berichtjes waar de rest van het forum niks aan heeft.

Anoniem: 312741 schreef op dinsdag 04 augustus 2009 @ 11:44:
[...]
Helpen jullie me dan?

Tuurlijk, als de topicstart in orde is, waarom niet? Alleen moet je natuurlijk niet rekenen op een kant en klaar antwoord; waar je wel op kunt tellen zijn een hoop linkjes

.

Ik durf denk ik geen topic te openen bij probs, simpelweg omdat de meesten vinden dat ik 'achterloop' omdat ik 4 jaar geleden al had moeten beginnen met het structureren in divs. (Ik zeg bewust even geen 'semantische opbouw' meer, omdat ik weet dat ik mijn code altijd keurig netjes opzet volgens de richtlijnen, alleen tja, wél met tables...)

Nou, okee, een overtuigend argument.

Bij een tabel hebben de gegevens in een enkele rij iets met elkaar te maken. Een tabel voor een formulier gebruiken is in enkele toepassingen verdedigbaar; immers, het labeltje links heeft te maken met het tekstvakje rechts. Een tabel voor vertrektijden van een trein gebruiken is prima - de tijd, het perron en bestemming hebben allemaal met elkaar te maken.

Die relaties veranderen niet. Goed, we kunnen wellicht nieuwe tags krijgen, maar het idee dat tijd, perron en bestemming opeens niet meer bij elkaar horen - dat verandert niet. Om dat dan af te doen met "over 10 jaar lachen ze er om" zoals Pumbaa82 voorstelt is niet snappen waar het probleem ligt en niet begrijpen wat er met semantiek bedoeld wordt.

In een layout hebben de tabelcellen helemaal niks met elkaar te maken; de enige relatie is dat plaatje_links.gif naast plaatje_midden.gif staat. Verder renderen tabellen pas helemaal nadat ze volledig zijn ingeladen, en da's nogal een rotwerk als je een hoop data moet ophalen. Verder rekken tabellen te pas en te onpas uit; de oplossing is meer tabellen. Dus maak je eerst een setje met bijv. 6 cellen (3 breed, 2 hoog), doet een colspan op de bovenste om daar je header van te maken.

In de linker en rechtercel zet je ieder weer tabelletjes. En daar weer tabelletjes in, omdat je plaatjes en links wil laten zien, of een formuliertje. En zo stop je tabel in tabel in tabel.

Je bent het zo elke keer moelijker aan het maken - omdat je elke keer moet kijken of je niet die hoofd-tabel met 6 cellen uit z'n voegen rukt. Forums hebben daarom ook een aparte tabel per post, en niet een joekel van een tabel, want dan kun je met 1 rotplaatje van 10000 pixels breed het hele forum uit z'n voegen rossen, en kost het eeuwen om te laden bij een drukbezocht topic als je geen caching gebruikt en elke keer alles opnieuw uit de db moet halen - en het kost voor de gebruiker meer tijd omdat die joekelgrote tabel pas op het scherm verschijnt als alle cellen gevuld zijn.

Net zoals bovengenoemde trein met bestemming, tijd en perron hebben user, avatar, bericht en tijd van plaatsen ook met elkaar te maken, dus da's ook weer te verdedigen om tabellen te gebruiken.

Wat je plaatjes overigens betreft; je kunt met list elements een supernette galerij van afbeeldingen maken. Wat is er handig aan? Omdat je nooit hoeft na te denken over in welke rij iets zit of hoeft te tellen hoeveel cellen deze rij heeft kun je met jQuery of Mootools heel netjes sorteren in Javascript. Dat kun je bij tabellen alleen echt fatsoenlijk als je alleen maar een "domme" platte rij hebt. Zie ook http://www.alistapart.com/articles/practicalcss/

Serieus, idealiter wil je zoveel mogelijk geld voor je tijd. Dat betekent veel geld of weinig tijd. Dat laatste is makkelijker aan te passen dan het eerste.

Pumbaa82 schreef op dinsdag 04 augustus 2009 @ 11:45:
Behalve dan redenen in de richting van: Tabellen zijn tegenwoordig not done of dat het veel gemakkelijker en sneller is (maar daarvoor moet je wel eerst templates maken)

Dit klinkt als zeuren dat templates te moeilijk zijn. Bullshit - het idee achter een template is juist dat je niet elke keer alles opnieuw moet doen, en je server-side taal wil ook nog wel eens een handje helpen omdat templates netjes gecached kunnen worden. Je "not done" laat zien dat je het probleem niet snapt; het heeft niks met afzeiken van werkwijze te maken.

teveel zooi, te weinig tijd

woensdag 5 augustus 2009 14:53

Acties:

0 Henk 'm!

trinite_t

Yoozer schreef op woensdag 05 augustus 2009 @ 14:46:
[...]

Heij!

* Yoozer schopt

Waar denk je dat een forum voor is? Juist, voor mensen die met hetzelfde probleem zitten ook nog te helpen omdat hun oplossing publiek gepubliceerd wordt. Er zijn hier een paar voorwaarden aan het starten van een topic, maar als je netjes neerzet "nou, ik werk al 7.5 jaar met tabellen en wil nu wel eens een goede set best practices" en zo lijkt het me toch dat 'ie niet op slot gemikt wordt.

DMs verstoppen dit soort informatie. DMs gebruik je voor het soort berichtjes waar de rest van het forum niks aan heeft.

Iets met offtopic enzo...

Het gaat hier over html+css vs table layouts, niet over kleine probleempjes die mensen tegenkomen tijdens het overstappen van tables naar semantische html.

The easiest way to solve a problem is just to solve it.

woensdag 5 augustus 2009 14:54

Acties:

0 Henk 'm!

disjfa

be

trinite_t schreef op woensdag 05 augustus 2009 @ 14:53:
[...]
Iets met offtopic enzo... Het gaat hier over html+css vs table layouts, niet over kleine probleempjes die mensen tegenkomen tijdens het overstappen van tables naar semantische html.

Ken je het knopje "nieuw topic"

disjfa - disj·fa (meneer)
disjfa.nl

woensdag 5 augustus 2009 14:55

Acties:

0 Henk 'm!

Erkens

Fotograaf

trinite_t schreef op woensdag 05 augustus 2009 @ 14:53:
[...]

Iets met offtopic enzo... Het gaat hier over html+css vs table layouts, niet over kleine probleempjes die mensen tegenkomen tijdens het overstappen van tables naar semantische html.

Ik zie niet hoe dat offtopic zou zijn? Juist door het oplossen van dat soort "kleine probleempjes" kunnen ervoor zorgen dat meer mensen het licht gaan zien

woensdag 5 augustus 2009 14:56

Acties:

0 Henk 'm!

Yoozer

minimoog

trinite_t schreef op woensdag 05 augustus 2009 @ 14:53:
Iets met offtopic enzo...

Wat nou offtopic, da's hardstikke on-topic. Waarom niet gewoon hier in het topic zetten net zoals ik deed?

Het gaat hier over html+css vs table layouts, niet over kleine probleempjes die mensen tegenkomen tijdens het overstappen van tables naar semantische html.

Juist in dit soort discussies zijn die bijdragen van nut omdat hier iedereen op springt die graag nog z'n tabellen op ontoepasselijke plaatsen verdedigt en dan obscure CSS-perikelen aanhaalt waar al een hele tijd een oplossing voor is

[ Voor 0% gewijzigd door Yoozer op 05-08-2009 14:57 . Reden: zo Erkens, da's snel ]

teveel zooi, te weinig tijd

woensdag 5 augustus 2009 15:08

Acties:

0 Henk 'm!

Anoniem: 312741

Topicstarter

Booster schreef op dinsdag 04 augustus 2009 @ 20:50:
Mijn complimenten dat je toch besloten hebt eens een kijkje te nemen in de wereld van sematische HTML Het kan soms erg moeilijk zijn om aan zoiets te beginnen, [..]

...wat er over 2-3 jaar gebouwd wordt op dit vlak. Ik weet wel dat semantiek een belangrijke rol zal spelen.

Wow, wat een lang antwoord. Maar kijk, dit is duidelijk. Hier hebben mensen zoals ik wat aan. Ik vind dit verhaal ook overtuigend. Bedankt voor je bijdrage, Booster.

Yoozer schreef op woensdag 05 augustus 2009 @ 14:56:
Juist in dit soort discussies zijn die bijdragen van nut omdat hier iedereen op springt die graag nog z'n tabellen op ontoepasselijke plaatsen verdedigt en dan obscure CSS-perikelen aanhaalt waar al een hele tijd een oplossing voor is

Mee eens.... ik denk dat veel 'tabelvoorstanders' juist in een topic zoals deze gaan rondneuzen en dan is het wel belangrijk dat dat soort bijdragen hier te vinden zijn

[ Voor 32% gewijzigd door Anoniem: 312741 op 05-08-2009 15:13 ]

woensdag 5 augustus 2009 15:21

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Booster schreef op dinsdag 04 augustus 2009 @ 20:50:
Om je vraag over het lezen van websites door blinden een beetje te beantwoorden:
Er zijn waarschijnlijk websites om te testen of je HTML en CSS voldoet aan bepaalde richtlijnen daarvoor en ik denk dat er ook websites zijn die letterlijk kunnen laten zien hoe spraaksoftware een site bekijkt bv. Je kunt eens googlen naar "accessibility test".

Meest gangbare zijn Section 408 en WAI. Als je in Firefox de Web Developer toolbar installeert krijg je ze allebei 'one mouseclick away' in je Tools menu

[ Voor 7% gewijzigd door een moderator op 05-08-2009 16:03 ]

Professionele website nodig?

woensdag 5 augustus 2009 15:27

Acties:

0 Henk 'm!

Herko_ter_Horst

R4gnax schreef op woensdag 05 augustus 2009 @ 11:55:
[...]

Herko_ter_Horst's aanpak voor IE voldoet daarentegen niet aan de standaarden, maar maakt expliciet misbruik van een bekende layout bug met betrek tot position: relative en procentuele offsets. Onder bepaalde omstandigheden zal IE deze procentuele offsets foutief interpreteren als een percentage van de dimensies van het element zelf i.p.v. de dimensies van de parent van het element, zoals de standaarden voor schrijven.

E.e.a. is heel wat minder forward compatible. Wat doe je wanneer deze positionerings bug in IE gefixed wordt? Kun je garanderen dat tegen die tijd display: table en display: table-cell ondersteund gaan worden? Zo niet, dan kun je toch echt je hele idee weg gaan gooien en iets nieuws gaan verzinnen...

Niet dat ik nou mijn oplossing bij hoog en bij laag wil verdedigen (zoveel verstand heb ik nou ook weer niet van IE-specifieke hacks/work-arounds) maar toch even het volgende: display:table en display:table-cell worden prima ondersteund in IE 8. Vandaar de conditional comment om alleen voor versies lager dan 8 (eigenlijk alleen 6 en 7 want 5.5 en lager tel ik niet meer) de hack toe te passen die gebruik maakt van de position bug. Die gaat echt niet meer gefixed worden in een update van IE 6 of 7, dus dat is redelijk future-proof. Alle andere browsers zien geheel valide HTML en CSS die precies aangeeft wat eigenlijk de bedoeling is.

Maar goed, het blijft geklooi om non-compliant browsers tot te orde te roepen.

"Any sufficiently advanced technology is indistinguishable from magic."

woensdag 5 augustus 2009 15:44

Acties:

0 Henk 'm!

R4gnax

Herko_ter_Horst schreef op woensdag 05 augustus 2009 @ 15:27:
[...]

Niet dat ik nou mijn oplossing bij hoog en bij laag wil verdedigen (zoveel verstand heb ik nou ook weer niet van IE-specifieke hacks/work-arounds) maar toch even het volgende: display:table en display:table-cell worden prima ondersteund in IE 8. Vandaar de conditional comment om alleen voor versies lager dan 8 (eigenlijk alleen 6 en 7 want 5.5 en lager tel ik niet meer) de hack toe te passen die gebruik maakt van de position bug. Die gaat echt niet meer gefixed worden in een update van IE 6 of 7, dus dat is redelijk future-proof. Alle andere browsers zien geheel valide HTML en CSS die precies aangeeft wat eigenlijk de bedoeling is.

Maar goed, het blijft geklooi om non-compliant browsers tot te orde te roepen.

In dat geval vervalt mijn eerdere commentaar. Ik had even gemist dat IE8 inderdaad display: table en table-cell ondersteunt.

woensdag 5 augustus 2009 16:02

Acties:

0 Henk 'm!

Spinal

Yoozer schreef op woensdag 05 augustus 2009 @ 14:46:
[...]
Bij een tabel hebben de gegevens in een enkele rij iets met elkaar te maken. Een tabel voor een formulier gebruiken is in enkele toepassingen verdedigbaar; immers, het labeltje links heeft te maken met het tekstvakje rechts. Een tabel voor vertrektijden van een trein gebruiken is prima - de tijd, het perron en bestemming hebben allemaal met elkaar te maken.

Verdedigbaar: ja. Maar correct? De beste beschrijving voor een tabel die ik ben tegengekomen was iets van "data die zowel horizontale als verticale samenhang heeft" (kan best zijn dat het hier op GoT was)
Een tabel met vertrektijden heeft horizontale (bepaalde tijd met een perron en bestemming) en verticale (kolom met tijden, kolom met peronnen, kolom met bestemmingen) samenhang. Maar in een formulier heb je niet echt verticale samenhang als je het mij vraagt.
Neemt niet weg dat als je tekst en invoerveld naast elkaar wilt hebben, en je niet weet hoe breed te tekst is, het een stuk makkelijker te stylen is in een tabel dan in een definition list...

Full-stack webdeveloper in Groningen

woensdag 5 augustus 2009 16:18

Acties:

0 Henk 'm!

DexterDee

I doubt, therefore I might be

Ik herinner me de tijd nog goed dat ik zelf ook alles met tables oploste als webdesigner. Zonder een inhoudelijk waardeoordeel te hebben in deze topicdiscussie vond ik in mijn bookmarks een site die mij geholpen heeft om CSS beter in te zetten voor layout doeleinden. En dan vooral toegespitst op compatibiliteit met zowat alle denkbare browsers zonder gebruik van CSS hacks en javascript:

http://matthewjamestaylor.com/blog/perfect-3-column.htm

Er zijn nog een aantal truukjes die ik in dit topic niet voorbij heb zien komen om de compatibiliteit te vergroten tussen browserversies, zoals gebruik maken van een CSS reset script. Verder is er door velen al heel veel aandacht besteedt aan layout issues in CSS en zijn er best goede frameworks op de markt, zoals deze:

http://www.blueprintcss.org/

Er is buiten deze twee resources nog veel en veel meer informatie te vinden, waar persoonlijke smaak en stijl een duidelijke invloed op heeft. Ik wil dan ook niet zeggen dat dit de beste resources zijn voor dit onderwerp, maar vanuit mijn referentiekader lijkt het me een nuttige suggestie en een zinvolle bijdrage aan deze discussie.

Klik hier om mij een DM te sturen • 3245 WP op ZW

woensdag 5 augustus 2009 16:48

Acties:

0 Henk 'm!

Soultaker

Hmm, misschien dat ik iets als Blueprint wel wil gebruiken.

Als ik code moet schrijven zoals die van Herko, dan beschouw ik CSS toch echt als een soort Postscript: leuk dat 't werkt, maar niet bedoeld om handmatig te schrijven.

woensdag 5 augustus 2009 17:46

Acties:

0 Henk 'm!

Tom

Inmiddels loop ik al heel wat jaartjes mee als webdesigner. Ergens in 1997 begonnen. In die tijd was je als vormgever een stuk beperkter, aangezien er nog veel technisch beperkingen waren. Je moest voor sommige zaken je afbeeldingen slicen of met imagemaps werken. Positioneren ging met frames, tabellen en transparante gifjes. Daarna had je een periode dat er nogal wat verschillen zaten tussen browsers. Internet Explorer en Netscape Navigator hadden zo hun eigen kijk op zaken. Grafisch was alles mogelijk, maar vaak met een omweg of extra werk. Eigenlijk waren beide browsers 'een bitch'. Je was toen inderdaad wat meer tijd kwijt om zaken te positioneren met CSS in plaats van tabellen.

Sinds IE7 en Firefox is het leven een stuk gemakkelijker. Zo'n beetje alles is mogelijk. CSS ondersteuning bij beide browsers is heel behoorlijk (al heb je nog steeds verschillen natuurlijk). Javascript ligt vrijwel op één lijn (gewoon getElementById en geen document.all). En er zijn tegenwoordig genoeg Javascript libraries te verkrijgen om de minder technische webdesigner tijd en werk te besparen.

Als je een beetje de ins- en outs van CSS kent, en hoe browsers ermee om gaan, dan is het gewoon gemakkelijk om een goed werkende site te maken. Momenteel is alleen IE6 nog een bitch. En soms loop je wat te stoeien met paddings en margins. Maar voor iemand die z'n werk ervan gemaakt heeft kan het niet moeilijk zijn en hoor je zonder teveel problemen een layout onder meerdere browsers werkend te krijgen.

Mensen die in 2009 nog steeds met tabellen werken zijn gewoon prutsers. Een hobbybob op de zolderkamer komt er misschien mee weg, maar als bedrijf kun je zoiets niet verkopen aan je klanten. Misschien dat het die klant niet kan interesseren hoe het technisch is gemaakt (als het maar werkt), maar diezelfde klant vind het wel belangrijk dat zijn site (goed) in Google geindexeerd zal worden. Dat zijn site ook in de toekomst blijft werken. En bovendien het idee dat ze voor het geld een goed product hebben gekocht.

Tijdje terug had ik ook een klant waarvan ik zijn bestaande website moest aanpassen. Dat was ook zo'n oldskool website, vrij recent ook nog. Ik zei dat ik er niets mee kon (zonder gigantisch veel tijd in te stoppen) omdat het troep was. Verbaasde ze, na een uitleg van mijn kant. Ze dachten een goede website te hebben (tenslotte bij een "professioneel reclamebureau" laten maken).

Ik volg nieuwe ontwikkelingen in ieder geval graag. Zie HTML5 dan ook graag gemeengoed worden. Stilstand is achteruitgang

woensdag 5 augustus 2009 17:52

Acties:

0 Henk 'm!

Bosmonster

*zucht*

DexterDee schreef op woensdag 05 augustus 2009 @ 16:18:
Ik herinner me de tijd nog goed dat ik zelf ook alles met tables oploste als webdesigner. Zonder een inhoudelijk waardeoordeel te hebben in deze topicdiscussie vond ik in mijn bookmarks een site die mij geholpen heeft om CSS beter in te zetten voor layout doeleinden. En dan vooral toegespitst op compatibiliteit met zowat alle denkbare browsers zonder gebruik van CSS hacks en javascript:

http://matthewjamestaylor.com/blog/perfect-3-column.htm

Er zijn nog een aantal truukjes die ik in dit topic niet voorbij heb zien komen om de compatibiliteit te vergroten tussen browserversies, zoals gebruik maken van een CSS reset script. Verder is er door velen al heel veel aandacht besteedt aan layout issues in CSS en zijn er best goede frameworks op de markt, zoals deze:

http://www.blueprintcss.org/

Er is buiten deze twee resources nog veel en veel meer informatie te vinden, waar persoonlijke smaak en stijl een duidelijke invloed op heeft. Ik wil dan ook niet zeggen dat dit de beste resources zijn voor dit onderwerp, maar vanuit mijn referentiekader lijkt het me een nuttige suggestie en een zinvolle bijdrage aan deze discussie.

Als ik even op die 'tips' in mag gaan.. begin er alsjeblieft niet aan.

Reset-scripts zijn echt verschrikkelijk, zeker als je content uit een CMS komt. Want het komt er op neer dat je in veel gevallen alles wat je reset weer zelf terug mag gaan toveren, wat vaak meer xcrossbrowser issues oplevert dan het opgelost heeft (om over de extra code en tijdverspilling maar te zwijgen). Er is niks mis met elementen stylen waar nodig.

De CSS grids snap ik ook niet goed. Hoe moeilijk is het om zelf iets in kolommen en/of rijen in te delen in CSS

Daar heb ik echt geen compleet 'framework' voor nodig. Daarnaast zijn de classnames vaak zo enorm cryptisch dat niemand iets van je code gaat snappen. Niet heel prettig voor je collega's. We hebben hier intern er een aantal onderzocht, maar uiteindelijk maar geconcludeerd dat CSS grids de moeite niet waard zijn.

woensdag 5 augustus 2009 18:51

Acties:

0 Henk 'm!

DexterDee

I doubt, therefore I might be

Bosmonster schreef op woensdag 05 augustus 2009 @ 17:52:
[...]

Als ik even op die 'tips' in mag gaan.. begin er alsjeblieft niet aan.

Reset-scripts zijn echt verschrikkelijk

Zoals ik dus al zei, dat is afhankelijk van persoonlijke voorkeur. Ik gebruik CSS reset scripts zelf niet om eerst de boel te resetten en daarna opnieuw te definieren. Wat ik er wel mee doe is deze CSS aanpassen naar de stijl van de website in kwestie. Elementen stylen waar nodig, zoals je zelf ook zegt. Maar dan blijven er altijd elementen over die properties hebben die ik niet heb gezet maar toch gebruik. Je kunt dan wel zeggen dat je die ook had moeten zetten, maar daar vind ik het gebruik van een reset CSS script dan weer erg handig voor. Iemand heeft immers al tijd gestopt in het ontdekken waar er cross browser verschillen zijn in de default properties en heeft deze recht getrokken. Mijn eigen ervaring hiermee is dat ik hiermee op een simpele manier impliciet verschillen kan voorkomen die ik normaal alleen had gezien door de site in alle target browsers te testen. Minder rework dus en meer tijdswinst.

De CSS grids snap ik ook niet goed. Hoe moeilijk is het om zelf iets in kolommen en/of rijen in te delen in CSS Daar heb ik echt geen compleet 'framework' voor nodig. Daarnaast zijn de classnames vaak zo enorm cryptisch dat niemand iets van je code gaat snappen. Niet heel prettig voor je collega's. We hebben hier intern er een aantal onderzocht, maar uiteindelijk maar geconcludeerd dat CSS grids de moeite niet waard zijn.

Dat iets voor jullie niet de moeite waard was, wil natuurlijk niet zeggen dat het voor niemand de moeite waard is. Voor specifieke layout doeleinden kan ik me voorstellen dat een CSS grid een oplossing kan zijn. De eerste link die ik gaf gebruikt deze techniek niet. Het is een kwestie van keuzes maken en daarbij is er niet een enkele optie die goed is en per definitie alle andere opties fout.

Ik vind als ik eerlijk ben de toon van je bericht niet bijzonder prettig. Het feit dat je 'tips' in quotes schrijft, geeft mij het gevoel dat je verschilt van mening en je eigen mening hieraan superieur stelt. In plaats van de discussie gelijkwaardig te openen, begin je met de tip 'begin er alsjeblieft niet aan'. Verder presenteer je je eigen mening als feit door te zeggen: 'reset scripts zijn verschrikkelijk', in plaats van 'ik vind reset scripts verschrikkelijk'. Dat we hierover van mening verschillen wil nog niet zeggen dat jouw mening de universele waarheid is. Ik wil graag over de voor en nadelen discussieren, maar niet op basis van een reactie waaruit mensen bij voorbaat gewaarschuwd worden om weg te blijven van deze technieken. Net als jou ben ik ook professioneel met deze materie bezig en ik vind een dergelijke waarschuwing in dit geval niet echt gepast.

Klik hier om mij een DM te sturen • 3245 WP op ZW

woensdag 5 augustus 2009 18:52

Acties:

0 Henk 'm!

pedorus

Herko_ter_Horst schreef op woensdag 05 augustus 2009 @ 15:27:
Maar goed, het blijft geklooi om non-compliant browsers tot te orde te roepen.

Sterker nog, als je selecteert blijkt dat het nog steeds niet helemaal gelukt is. In IE6 kun je het niet zomaar selecteren, en als het lukt wordt het verkeerd getekend. In IE8 staat de accelerator op de verkeerde plek. Met tables gaat het gewoon wel goed... Tables for the win

Het probleem ligt volgens mij toch ook in de oorsprong van CSS, zeg maar reden 2 van die 10:

quote: http://www.w3.org/TR/REC-CSS1/#appendix-e
CSS1 does not offer:

* per pixel control: [...]
* a layout language: [...]

Gewoon eeuwig jammer dat ze niet vanuit het design zijn begonnen. Anno 2009, en een populaire website als Google gebruikt nog steeds tables en javascript om dingen op de juiste positie te krijgen... En ik denk nog dat dat de beste oplossing is in hun geval ook...

Tom schreef op woensdag 05 augustus 2009 @ 17:46:

[...] maar diezelfde klant vind het wel belangrijk dat zijn site (goed) in Google geindexeerd zal worden.

FUD; lijkt me sterk dat tables daarvan de oorzaak kunnen zijn. Google rendert sites, het maakt weinig uit of je daarvoor tables of css gebruikt.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

woensdag 5 augustus 2009 18:56

Acties:

0 Henk 'm!

Erkens

Fotograaf

pedorus schreef op woensdag 05 augustus 2009 @ 18:52:
FUD; lijkt me sterk dat tables daarvan de oorzaak kunnen zijn. Google rendert sites, het maakt weinig uit of je daarvoor tables of css gebruikt.

Wel de volgorde van je content maakt uit

Bij een op tabellen gebasseerde site zal je site in een andere volgorde gelezen kunnen worden dan dat het op het scherm staat. Content blokken die visueel naast elkaar staan kunnen dus in de code mijlen verder staan waardoor enige relevantie tussen die blokken min of meer verdwijnt.

woensdag 5 augustus 2009 19:27

Acties:

0 Henk 'm!

pedorus

Erkens schreef op woensdag 05 augustus 2009 @ 18:56:
Content blokken die visueel naast elkaar staan kunnen dus in de code mijlen verder staan waardoor enige relevantie tussen die blokken min of meer verdwijnt.

Hetzelfde geldt misschien nog wel meer voor CSS. Vandaar dat moderne zoekmachines de boel ook even renderen. Zelfs javascript wordt deels ondersteund, tenminste, bij Google dan.

Overigens blijven er meer dan genoeg redenen voor het gebruik van CSS over, maar dit is er volgens mij gewoon niet een.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

woensdag 5 augustus 2009 19:52

Acties:

0 Henk 'm!

Erkens

Fotograaf

pedorus schreef op woensdag 05 augustus 2009 @ 19:27:
[...]
Hetzelfde geldt misschien nog wel meer voor CSS. Vandaar dat moderne zoekmachines de boel ook even renderen. Zelfs javascript wordt deels ondersteund, tenminste, bij Google dan.
Overigens blijven er meer dan genoeg redenen voor het gebruik van CSS over, maar dit is er volgens mij gewoon niet een.

Natuurlijk kan je met CSS ook content blokken ver bij elkaar vandaan zetten, maar dan ben je nog steeds niet semantisch bezig, en daar ging het nu juist om

"Met CSS" is dus ook niet the way to go, ik dacht dat dit wel duidelijk was geworden in dit topic.

Overigens kan ik in mijn logfiles niet terugvinden dat Google CSS files binnenhaalt, dus "renderen" op dat niveau lijkt me dan best lastig

woensdag 5 augustus 2009 21:05

Acties:

0 Henk 'm!

Booster

Superuser

Is het overigens nogsteeds zo dat IE een table pas renderd als hij de inhoud van de cellen heeft kunnen renderen? Oftewel: bij pagina's met veel content kun je niet al de site bekijken als er nog content aangeleverd wordt door de server. En als content in de tabel niet helemaal lekker doorkomt, ziet een gebruiker nog niets.

http://nontroppo.org/timer/tabletest.html
IE8: Load:2591ms Table Start:2836ms Table End:2836ms
FF3.5: Table Start:12ms Table End:386ms Load:1294ms
Bij mij duurt het ook echt even voor de tabel uberhaubt in beeld komt in IE.

Dit kan een probleem zijn als je bv een tabel zou gebruiken om een groot gastenboek of forum weer te geven.

The cake is a lie | The Borealis awaits...

woensdag 5 augustus 2009 21:12

Acties:

0 Henk 'm!

MoietyMe

zij/haar

Erkens schreef op woensdag 05 augustus 2009 @ 18:56:
[...]

Wel de volgorde van je content maakt uit
Bij een op tabellen gebasseerde site zal je site in een andere volgorde gelezen kunnen worden dan dat het op het scherm staat. Content blokken die visueel naast elkaar staan kunnen dus in de code mijlen verder staan waardoor enige relevantie tussen die blokken min of meer verdwijnt.

Dan ben je gewoon slecht aan het opbouwen imo.

woensdag 5 augustus 2009 21:19

Acties:

0 Henk 'm!

Erkens

Fotograaf

Good Fella schreef op woensdag 05 augustus 2009 @ 21:12:
[...]

Dan ben je gewoon slecht aan het opbouwen imo.

Daar ging het toch ook om

woensdag 5 augustus 2009 21:20

Acties:

0 Henk 'm!

pedorus

Erkens schreef op woensdag 05 augustus 2009 @ 19:52:
Overigens kan ik in mijn logfiles niet terugvinden dat Google CSS files binnenhaalt, dus "renderen" op dat niveau lijkt me dan best lastig

Op een onpopulaire site gekeken

Hoe vaak en of dat gebeurd hangt af van nogal wat factoren. Algemeen gezien: Googlebot haalt de CSS af en toe binnen, Yahoo slurp doet dit (te) vaak en met referer, en msnbot/Bing is brak en doet dit nauwelijks/als er een linkje naartoe is. Maar goed, wie gebruikt Bing dan ook

En tsja, ook met een perfect semantische paginaopbouw kun je niet direct aan de source zien welke blokken redelijk bovenaan een pagina komen. En hoe iets geprint moet worden, zie je zonder de CSS al snel niet, maar toch zul je daar vaak een andere paginaopbouw zien. Tweakers zelf is daar een mooi voorbeeld van. Dat is trouwens wel een groot nadeel van tabellen: vaak geen printinformatie.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

woensdag 5 augustus 2009 22:54

Acties:

0 Henk 'm!

XWB

Devver

Anoniem: 312741 schreef op maandag 03 augustus 2009 @ 17:31:
Ik werk al 7,5 jaar als professioneel front-end (en back-end) developer en ik kan je met zekerheid zeggen dat div-jes meer probs opleveren dan een paar schone, nested tables. Als je het maar goed opzet. En dat kan ook op een hele mooie, moderne manier hoor.

Problemen bestaan niet, enkel uitdagingen.

March of the Eagles

woensdag 5 augustus 2009 23:04

Acties:

0 Henk 'm!

Erkens

Fotograaf

pedorus schreef op woensdag 05 augustus 2009 @ 21:20:
Op een onpopulaire site gekeken Hoe vaak en of dat gebeurd hangt af van nogal wat factoren. Algemeen gezien: Googlebot haalt de CSS af en toe binnen, Yahoo slurp doet dit (te) vaak en met referer, en msnbot/Bing is brak en doet dit nauwelijks/als er een linkje naartoe is. Maar goed, wie gebruikt Bing dan ook

Google komt een paar keer per week langs zo te zien en in ieder geval hebben ze de afgelopen 30 dagen geen enkele CSS en/of JavaScript file geleeched.

En tsja, ook met een perfect semantische paginaopbouw kun je niet direct aan de source zien welke blokken redelijk bovenaan een pagina komen.

Maar er is wel structuur in de pagina waardoor het in principe niet uitmaakt in welke volgorde het staat, want alles wat relevant is staat bij elkaar, _dat_ is wat ik bedoelde. Zodra je tabellen gebruikt is de kans gewoon groot dat het niet bij elkaar in de buurt staat omdat je te maken hebt met diverse tabelcellen, maargoed, ik kan me best indenken dat dit niet een super groot probleem is, echter het is niet iets wat je simpel mag negeren imo.

woensdag 5 augustus 2009 23:19

Acties:

0 Henk 'm!

Zakkenwasser

Ik geef toe, vroeger maakte ik mijn layouts met tabellen, ik weet nog wel dat ik alle plaatjes moest uitsnijden en iedere pagina opnieuw moest maken met Dreamweaver.

Maar ik heb er veel van opgestoken door mijn website met sematisch correcte code in elkaar te zetten.
Ik heb na veel keer vallen en opstaan toch de overstap gemaakt om mezelf open te stellen voor <div> layouts en extern CSS.

WOW.
Als je dat ook nog eens combineerd met PHP includes dan heb je je website veel sneller in elkaar gezet dan de varianten compleet opgebouwd uit tabellen.

Het hielp me overigens ook door veel boeken te lezen van o.a. Friends of Ed.

Ik snap nog steeds niet waarom mensen moeilijk doen met Tabel Hell / Div Hell layouts en inline CSS, terwijl als je openstaat om wat kennis optedoen voor een passie die je graag uitoefent je nog veel sneller en betere websites in elkaar zet.

Zo zie ik het tenminste.
Ik gun iedereen met een passie voor het maken van websites een hoop leermomenten toe.

Iedereen maakt inschattings fouten, en daarvoor zijn we nu hier, verbeter jezelf en doe er je voordeel mee

Cybie schreef op maandag 03 augustus 2009 @ 17:31:
Ik werk al 7,5 jaar als professioneel front-end (en back-end) developer en ik kan je met zekerheid zeggen dat div-jes meer probs opleveren dan een paar schone, nested tables. Als je het maar goed opzet. En dat kan ook op een hele mooie, moderne manier hoor.

Wat voor problemen geeft een goed gecomfigureerde div-layout volgends jou dan?

Ik werk zelf al vanaf mijn 17de aan websites op de verkeerde manier, en zo kan ik me dan ook wel een pro noemen, alleen doe ik het pas 1,5jaar op de juiste manier... athans dat maak ik me soms wijs

Bosmonster schreef op woensdag 05 augustus 2009 @ 17:52:
[...]

Als ik even op die 'tips' in mag gaan.. begin er alsjeblieft niet aan.

De CSS grids snap ik ook niet goed. Hoe moeilijk is het om zelf iets in kolommen en/of rijen in te delen in CSS Daar heb ik echt geen compleet 'framework' voor nodig. Daarnaast zijn de classnames vaak zo enorm cryptisch dat niemand iets van je code gaat snappen. Niet heel prettig voor je collega's. We hebben hier intern er een aantal onderzocht, maar uiteindelijk maar geconcludeerd dat CSS grids de moeite niet waard zijn.

Amen,
Ik haakte ook al af na het zien van die cryptische classes, ik twijfelde nog wel of ik op het juiste tempo mijn CSS kon verbeteren.
Floats FTW!

[ Voor 39% gewijzigd door Zakkenwasser op 05-08-2009 23:34 ]

PSP 1000 @ 6.60 Pro C2 [+256GB]
PSVita @ Henkaku Enso [+256GB]
3DS @ Luma (B9S) [+160GB]
Nintendo Switch 3.0.1 [+256GB]

woensdag 5 augustus 2009 23:22

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Erkens schreef op woensdag 05 augustus 2009 @ 19:52:
[...]

Overigens kan ik in mijn logfiles niet terugvinden dat Google CSS files binnenhaalt, dus "renderen" op dat niveau lijkt me dan best lastig

Even voor je gecontroleerd en op een aardig drukke site fietst Googlebot wel degelijk ruwweg eens per dag de CSS binnen. Moet ook wel, daar ze dingen als 'witte tekst op witte achtergrond' wel degelijk detecteren en penalizen.

Professionele website nodig?

woensdag 5 augustus 2009 23:46

Acties:

0 Henk 'm!

Erkens

Fotograaf

curry684 schreef op woensdag 05 augustus 2009 @ 23:22:
[...]

Even voor je gecontroleerd en op een aardig drukke site fietst Googlebot wel degelijk ruwweg eens per dag de CSS binnen. Moet ook wel, daar ze dingen als 'witte tekst op witte achtergrond' wel degelijk detecteren en penalizen.

* Erkens slaat zichzelf voor zijn kop

Die files worden via een ander domein gehost en staan dus ook in een andere logfile

donderdag 6 augustus 2009 00:02

Acties:

0 Henk 'm!

XWB

Devver

Pumbaa82 schreef op dinsdag 04 augustus 2009 @ 11:45:
En ik vraag me af wie er hier nu echt een plank voor z'n kop houdt.
Want degene die hier nu zo fanatiek het semantisch design aan het verdedigen zijn, zullen dezelfde zijn die dat over pakweg 10 jaar nog doen. En dan door de jongere generatie worden belaagd vanwege hun oude denkwijze.

Onzin; wanneer er over vijf jaar een nieuwe way-to-go is zullen de meeste mensen dat ook gaan volgen.

Matis schreef op dinsdag 04 augustus 2009 @ 12:22:
[...]

iPhone, slecht voorbeeld

Ontopic:
Het enige voordeel van tables is dat je data mooi kunt uitlijnen. (neem bijvoorbeeld de kalender van hyves). Dit is niet te doen in css/div. (je het is te doen....)

Een kalender plaats ik dan ook onder tabular data.

Anoniem: 312741 schreef op dinsdag 04 augustus 2009 @ 14:39:
Oja, en ff voor de duidelijkheid

Ik ben *nu* bezig met een website opzetten zonder tables, goed hè? Alleen het bevalt me (nog) niet echt, wat een gepiel is dat zeg! De hele boel verspringt als je 1 foutje maakt...daarnet zette ik even een border om een div aan en hop, hele div stond ineens 500 pixels versprongen. Lekker dan...of is daar een logische verklaring voor?

Schoonheid, het vraagt wel wat ervaring als je hiermee nog nooit gewerkt hebt.

RobertMe schreef op dinsdag 04 augustus 2009 @ 14:58:
http://robert.aenv-ict.nl/css.html
http://robert.aenv-ict.nl/tabel.html

Maak je keuze, voor mij was de opzet met tabellen in ieder geval meer werk (meer html = meer tikwerk, en die cellspacing wist ik niet (meer))

Zowel Opera, als FF als IE8 laten precies hetzelfde zien.

Edit:
Beide door de W3C validator gehaald en daarop aangepast

Nah, tabellen zou me ook meer werk gekost hebben.

Je ontwijkt de vraag. Waarom zou iedereen iPhones moeten kopen om te telefoneren, als dat met een 10 jaar oude Nokia makkelijker en goedkoper kan?

Omdat ik tegenwoordig ook meer doe dan alleen bellen? Een smartphone kan super handig zijn, de hele zooi (= mails, afspraken etc.) met Outlook syncen, beetje surfen, mails ontvangen, foto's maken (digitale camera is weer een extra apparaat dat ik moet meesleuren ) e.d.

Ik heb drie pagina's geleden een hele simpele HTML-pagina gepost die correct werkt in álle browsers die ik ken met de uitnodiging om een equivalente pagina met CSS te maken. Niemand heeft de uitdaging aangenomen. Voor zover ik weet kan het ook niet in CSS, terwijl die taal ffs (en in tegenstelling tot HTML 1/2/3) ontworpen is met als enige doel om HTML te lay-outen!

Met display: table; kan het, maar dan kan je evengoed tabellen gebruiken.

Tenslotte de Tweakers.net website: ik geef toe dat dat een mooie site is die goed in elkaar zit. Ik denk ook dat er door bovengemiddelde ontwikkelaars aan gewerkt wordt. Toch is het typisch een toonbeeld van hoe onflexibel CSS is: de site kan maar op één manier gerenderd worden: als ik 'm op een lage resolutie bekijk valt de helft van de site buiten beeld, en als ik 'm op een hoge resolutie bekijk staan er grote zwarte balken links en rechts van m'n scherm. Oude web 1.0 pagina's scoren qua usability heel wat hoger.

@ dat laatste, omdat ze meeschalen bedoel je? Je wil echt geen nieuwsbericht op 1600px breed lezen denk ik.

Er zijn in de Tweakers.net CSS ook allerlei browserspecifieke hacks om langs bugs en quirks te werken. Er is absoluut geen enkele kans dat je een website zoals die van Tweakers.net kunt ontwikkelen zonder uitgebreid te testen op de browsers die je wil ondersteunen.

Klopt, maar wat dan? Denk je dat een ervaring css guru daar problemen mee heeft? Die werkt daar zo omheen.

Soultaker schreef op dinsdag 04 augustus 2009 @ 21:07:
Overigens zijn er verbazend goede argumenten tegen CSS te vinden door simpelweg te Googlen op CSS sucks; dit is de eerste hit: Ten reasons why CSS sucks en beschrijft eigenlijk precies wat ik ook denk (alleen punt 8, performance, vind ik eigenlijk niet heel boeiend; d.w.z. als alle andere punten in orde waren zou ik het voor lief nemen).

En waar is het lijstje met voordelen?

Sowieso, als ik zaken als "CSS is a pain to work with" tegenkom hoef ik niet verder te lezen: je bent developer, geen mietje die ervandoor rent wanneer je voor een uitdaging staat.

March of the Eagles

donderdag 6 augustus 2009 00:09

Acties:

0 Henk 'm!

pedorus

pedorus schreef op woensdag 05 augustus 2009 @ 18:52:
FUD; lijkt me sterk dat tables daarvan de oorzaak kunnen zijn. Google rendert sites, het maakt weinig uit of je daarvoor tables of css gebruikt.

Ter ondersteuning: er is ook een filmpje van:

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

donderdag 6 augustus 2009 00:17

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Hacku schreef op donderdag 06 augustus 2009 @ 00:02:
Met display: table; kan het, maar dan kan je evengoed tabellen gebruiken.

Ho, stop, deze uitspraak moet ik toch even pertinent tegen in het geweer schieten. Een semantisch correct non-table element dat zich rendertechnisch toevallig dient te gedragen als table kun je nooit evengoed vervangen door een table. In het eerste geval kies je ervoor een div, paragraph, header, blockquote, whatever te gebruiken, en die los in het CSS-bestand dat tenslotte over rendering besluit een specifieke vorm van renderinggedrag te geven, in het tweede geval verneuk je de semantiek van je HTML-document. Dat is me nogal geen verschil, en juist het hele fundamentele punt van deze discussie

[ Voor 3% gewijzigd door curry684 op 06-08-2009 00:18 ]

Professionele website nodig?

donderdag 6 augustus 2009 00:22

Acties:

0 Henk 'm!

Yoozer

minimoog

Soultaker schreef op woensdag 05 augustus 2009 @ 16:48:
Als ik code moet schrijven zoals die van Herko, dan beschouw ik CSS toch echt als een soort Postscript: leuk dat 't werkt, maar niet bedoeld om handmatig te schrijven.

Volstrekt onzinnige vergelijking. "Leuk dat het werkt", kom nou.

CSS laat je toe om over opmaak in termen van unieke en wederkerende elementen te denken. Inline styles zijn volslagen zot als je ze zelf neerkalkt. Als je in je tekst quotes hebt van iemand is het toepassen van een setje stijlen op een blockquote tag, desnoods met nog een classname oneindig maal eenvoudiger dan een stel p's vernaggelen.

CSS niet zelf schrijven? Het is juist auto-generated CSS die er een zooi van maakt met spannende namen als .donkerBlauwVetGedrukt1, donkerBlauwVetGedrukt2 etc. Het zelf schrijven laat je nu juist toe om het zodanig toe te passen dat het nut heeft. Alleen al wat een beetje JS erbij kan doen.

Nee, je stelt je een beetje aan met die opmerking en doet jezelf zwaar tekort door niet eens een poging te wagen.

teveel zooi, te weinig tijd

donderdag 6 augustus 2009 00:47

Acties:

0 Henk 'm!

Cousin Boneless

Na alles wat er over CSS-layout versus table-layout is geschreven gelezen te hebben (mijn laatste reactie in dit topic) kan ik vaststellen dat de opbouw van de discussies altijd hetzelfde verloopt: het begint met geschreeuw over en weer en eindigt in een genuanceerder beeld.

Vaak krijg ik de indruk dat moderne websites er allemaal het zelfde uitzien en dat het gebruik van CSS daar debet aan is:
- Stel dat er makkelijk verticaal gecentreerd kon worden, dan werd dat vast veel vaker gedaan.
- Stel dat max-width en max-height goed werden ondersteund, dan zou ook het liquid layouten zo weer in zwang raken.

Wat dat betreft zijn we er niet op vooruit gegaan. Ook de doctypes hebben voornamelijk beperkingen opgelegd. Stel je wilt een site met een header en een footer en een overflow:auto op de container die er tussenin zit. Met een transitional doctype en table-layout niet moeilijk. Met CSS en/of strict doctype alleen te doen als de header en footer een fixed height hebben (wie? kom maar met de code)

Bij het gebruik van tables moet je volgens mij pragmatisch denken. Wil je dat bij dynamische content de cellen in een "row" een gelijke hoogte hebben en de cellen in een "kolom" dezelfde breedte, dan is een table de juiste tool. En dan kan ik me er misschien nog wel uitlullen dat dit semantisch gezien een tabel is. Toch leg ik het liever technisch uit: Het heeft de dynamische karakteristieken van een grid/tabel. En aan dat concept is niets mis.

Websites die ik in mijn vrije tijd maak zijn over het algemeen vrij complex (semi liquid). De oorzaak: artistieke aanleveringen in PhotoShop, waardoor de background de viewport bepaalt. Er zitten dan twee mannetjes op mijn schouder. De ene roept: "semantisch! state-of-the-art!" en de ander fluistert: "doe toch een tabelletje, dat is zoveel beter voor je nachtrust en bloeddruk".

Dat zoekmachines moeite hebben met het indexeren van een table-layout heb ik nog nooit gemerkt. En dat stipt volgens mij ook wel aan waarom de discussies altijd zo mank gaan: table-layout sluit semantiek niet uit. Okee, de table is verkracht, maar de overige tags die veel meer semantische lading hebben (h1, h2, strong) kun je nog steeds naar hartelust gebruiken. En we schreven de site bovendien voor mensen en niet voor zoekmachines? De semantiek kun je ook misbruiken om hoger te scoren. Het semantische web is zodoende een utopie. De "keywords" meta tag wordt niet voor niets genegeerd.

Ligt het aan mij of is display:table-cell een goedmakertje voor wat ons is afgeleerd? Opeens doet vertical-align zoals het nog in de oude vertrouwde td doet. Is het logisch?

donderdag 6 augustus 2009 00:57

Acties:

0 Henk 'm!

ValHallASW

Hacku schreef op donderdag 06 augustus 2009 @ 00:02:
[...]
Schoonheid, het vraagt wel wat ervaring als je hiermee nog nooit gewerkt hebt.

Dat is dus precies het probleem met CSS: het in contraintuitief en als je dat zegt dan krijg je te horen dat het komt doordat je er geen ervaring mee hebt. Nee, duh, als je ervaring opdoet met een auto die linksaf gaat als je rechts stuurt en rechtsaf als je links stuurt dan werkt dat op een gegeven moment óók wel, en het is dan óók 'logisch'. Handig en togankelijk is alleen iets heel anders. Tabellen, daarintegen, zijn beperkter, maar zijn in ieder geval intuitief

offtopic:
nog even los van het gebruik van termen als 'schoonheid' in zo'n topic...

Overigens: css-table layouts lossen niets op om de volgorde in je bestand logisch te houden: je moet dan nog steeds van links naar rechts werken...

Overigens II: waarom staat het menu op GoT bovenaan? Is dat een bewuste ontwerpkeuze (in lynx is het namelijk nogal irritant: ik wil het topic, niet het menu, en ik moet (op 80x24) zeven pagina's naar beneden. Hoe zou dat zijn voor een braillelezer?) of is dat puur door zwakheden in css/css-implementaties?

[ Voor 2% gewijzigd door ValHallASW op 06-08-2009 01:07 . Reden: + opmerking over tabellen ]

donderdag 6 augustus 2009 01:03

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Yoozer schreef op donderdag 06 augustus 2009 @ 00:22:
[...]

Het is juist auto-generated CSS die er een zooi van maakt met spannende namen als .donkerBlauwVetGedrukt1, donkerBlauwVetGedrukt2 etc.

Nog afgezien van spanning maakt het inderdaad weer het hele punt van CSS overbodig doordat je weer opmaak in je HTML terug laat komen. Wat nu als die blauwe tekst morgen rood moet zijn, pas je dan de element classes aan of de CSS file?

Professionele website nodig?

donderdag 6 augustus 2009 01:14

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Denk dat het voor sommige mensen soms ook lastig te bevatten is dat html/css (en javascript, want die hoort er tegenwoordig ook volledig bij) meer is dan een een beetje opmaak alleen. Het is niet meer alleen een beetje design implementatie. Voor een goede synergie tussen die 3 is volledige controle en gedegen technische kennis benodigd. Daarom is frontend developer tegenwoordig ook een losse discipline en niet meer iets dat de webdesigner er even naast doet (sommige reclamebureau's buiten beschouwing gelaten *kuch*).

Het is een vak waarbij je analytisch en technisch sterk moet zijn en je continu op de hoogte moet blijven van de laatste ontwikkelingen. Waar kort geleden html4 strict nog de de facto standaard was, begint dat nu al te verschuiven naar de simpele html5 doctype bijvoorbeeld. Wat zijn de voor- en nadelen en wanneer stap je over? Of iets als font-embedding dat sinds Firefox 3.5 in alle browsers mogelijk is, wat ga je daarmee doen? Ga je het al toepassen? Etc.

Stilstand is achteruitgang.

[ Voor 32% gewijzigd door Bosmonster op 06-08-2009 01:18 ]

donderdag 6 augustus 2009 01:29

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Cousin Boneless schreef op donderdag 06 augustus 2009 @ 00:47:
[...]
Vaak krijg ik de indruk dat moderne websites er allemaal het zelfde uitzien en dat het gebruik van CSS daar debet aan is:
- Stel dat er makkelijk verticaal gecentreerd kon worden, dan werd dat vast veel vaker gedaan.

Dat betwijfel ik; voor normale websites zie ik geen reden om af te wijken van het principe dat content gewoon bovenin begint en doorloopt naar onder, eventueel bereikbaar met een scrollbar uiterst rechts over de volledige hoogte van het browserscherm. Daarvan afwijken is over het algemeen niet intuitief voor de gebruiker en zou dus enkel bij hoge uitzondering (als vorm boven functie gaat) gebruikt moeten worden.

- Stel dat max-width en max-height goed werden ondersteund, dan zou ook het liquid layouten zo weer in zwang raken.

Zelfs dan is liquid-within-margins nog erg lastig te doen met enkel CSS als hulpmiddel. Daarbij moet ook je content zich daar wel voor lenen...

[...]Met een transitional doctype en table-layout niet moeilijk. Met CSS en/of strict doctype alleen te doen als de header en footer een fixed height hebben

Er is wat browsers betreft geen verschil in rendering bij een transitional doctype of een strict doctype

Intentionally left blank

donderdag 6 augustus 2009 01:35

Acties:

0 Henk 'm!

Patriot

Fulltime #whatpulsert

Hacku schreef op donderdag 06 augustus 2009 @ 00:02:En waar is het lijstje met voordelen?

Daar ging het toch niet over? Als je bij de fietsenmaker komt om te vragen of hij je band wil plakken omdat die lek is vraagt hij toch ook niet om een lijstje met dingen die níet stuk zijn?

Sowieso, als ik zaken als "CSS is a pain to work with" tegenkom hoef ik niet verder te lezen: je bent developer, geen mietje die ervandoor rent wanneer je voor een uitdaging staat.

Oh kom op, je weet zelf ook wel dat dat onzin is. Als blijkt dat er dingen aan CSS zijn die onhandig zijn dan is het in iedereen's voordeel om daar wat aan te doen. Je moet ook weten wat die dingen zijn dus is het niet vreemd om het daar over te hebben.

donderdag 6 augustus 2009 08:57

Acties:

0 Henk 'm!

Bosmonster

*zucht*

crisp schreef op donderdag 06 augustus 2009 @ 01:29:
[...]
Er is wat browsers betreft geen verschil in rendering bij een transitional doctype of een strict doctype

Bedoel je dat voor een specifiek voorbeeld? Want in het algemeen is dit natuurlijk wel het geval, aangezien transitional doctypes in veel browsers quirksmode of almost-quirksmode activeren.

donderdag 6 augustus 2009 09:07

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Bosmonster schreef op donderdag 06 augustus 2009 @ 08:57:
[...]

Bedoel je dat voor een specifiek voorbeeld? Want in het algemeen is dit natuurlijk wel het geval, aangezien transitional doctypes in veel browsers quirksmode of almost-quirksmode activeren.

https://developer.mozilla...illa%27s_DOCTYPE_sniffing

Transitional doctypes (volledige, dus met system identifier) triggeren 'Almost Standards Mode' (wat natuurlijk iets anders is dan 'almost-quirksmode'

). Het verschil met standards mode is minimaal, en de kans is groot dat dat verschil ooit nog eens weggewerkt gaat worden (het gaat ironisch gezien om sliced images in table layouts

)

Intentionally left blank

donderdag 6 augustus 2009 09:08

Acties:

0 Henk 'm!

XWB

Devver

curry684 schreef op donderdag 06 augustus 2009 @ 00:17:
[...]

Ho, stop, deze uitspraak moet ik toch even pertinent tegen in het geweer schieten. Een semantisch correct non-table element dat zich rendertechnisch toevallig dient te gedragen als table kun je nooit evengoed vervangen door een table. In het eerste geval kies je ervoor een div, paragraph, header, blockquote, whatever te gebruiken, en die los in het CSS-bestand dat tenslotte over rendering besluit een specifieke vorm van renderinggedrag te geven, in het tweede geval verneuk je de semantiek van je HTML-document. Dat is me nogal geen verschil, en juist het hele fundamentele punt van deze discussie

Ho, stop, check het voorbeeld nog even waar het om ging.

Daar ging het toch niet over? Als je bij de fietsenmaker komt om te vragen of hij je band wil plakken omdat die lek is vraagt hij toch ook niet om een lijstje met dingen die níet stuk zijn?

Irrelevant, wat ik bedoel is dat iets afbreken veel makkelijker is dan de voordelen opsommen. En dat heb je overal, maar dat wil nog niet zeggen dat het ergens op slaat.

Oh kom op, je weet zelf ook wel dat dat onzin is. Als blijkt dat er dingen aan CSS zijn die onhandig zijn dan is het in iedereen's voordeel om daar wat aan te doen. Je moet ook weten wat die dingen zijn dus is het niet vreemd om het daar over te hebben.

Een paar zaken zijn inderdaad pain in the ass, maar niet het hele css gebeuren zoals hij dat wel laat overkomen.

Dat is dus precies het probleem met CSS: het in contraintuitief en als je dat zegt dan krijg je te horen dat het komt doordat je er geen ervaring mee hebt. Nee, duh, als je ervaring opdoet met een auto die linksaf gaat als je rechts stuurt en rechtsaf als je links stuurt dan werkt dat op een gegeven moment óók wel, en het is dan óók 'logisch'. Handig en togankelijk is alleen iets heel anders. Tabellen, daarintegen, zijn beperkter, maar zijn in ieder geval intuitief

Dat is toch geen correct voorbeeld? CSS vraagt ervaring, maar daarom hoeft het niet onhandig te zijn.

[ Voor 15% gewijzigd door XWB op 06-08-2009 09:23 ]

March of the Eagles

donderdag 6 augustus 2009 09:55

Acties:

0 Henk 'm!

Yoozer

minimoog

Cousin Boneless schreef op donderdag 06 augustus 2009 @ 00:47:
Vaak krijg ik de indruk dat moderne websites er allemaal het zelfde uitzien

Verrek. Zou het wellicht ook kunnen omdat het toevallig een goed ontwerp is? Zoekdoos midden of rechtsboven, titel links, want we lezen van links naar rechts, menu bovenin zodat er zoveel mogelijk content op een pagina kan, en eventuele features links of rechts in een smallere kolom.

Klagen over sites die er hetzelfde uitzien is klagen over het feit dat auto's de gaspedaal allemaal op ongeveer dezelfde plek hebben. Het is niet zo dat er geen experimenten meer mogelijk zijn, maar de interface van een site moet niet vreemd zijn maar vertrouwd; omdat je zo bezoekers kunt aanhouden in plaats van wegjagen. Als ik de zoekfunctie niet aantref op de plaats waar ik 'm verwacht betekent dat je niet genoeg inhoud hebt om te doorzoeken of wil je dat ik menu's ga doorjagen in Day Of The Tentacle-stijl.

Alle touchscreen telefoons zijn ook zo saai. Allemaal zwart (of wit) met een paar knoppen onderin of bovenin. Welkom bij het verschijnsel dat technologische convergentie heet.

en dat het gebruik van CSS daar debet aan is:

Daar heeft CSS geen moer mee te maken.

- Stel dat er makkelijk verticaal gecentreerd kon worden, dan werd dat vast veel vaker gedaan.

Stel dat er op mijn muis nou een scrollwiel zit dat van boven naar beneden gaat. Dan ben ik nogal getikt als ik horizontaal scrollen ga forceren.

Er zijn 5 plekken op je scherm die het makkelijkst bereikbaar zijn; de hoeken en waar je muis op dat moment zit. De browser maakt deze plekken al min of meer onbruikbaar door er chrome neer te zetten, en nou ga je met centreren deze plekken nog eens extra onbruikbaar maken omdat m'n muis niks doet als ik 'm er neer zet.

Op een mobiele telefoon met touchscreen heb je een paar grote, eenvoudige knoppen. Dat is omdat je lompe vingers niet goed zijn in mikken (die van mij overigens ook niet) en je tijdens lopen/eten/douchen/sex evengoed op "REJECT CALL" moet kunnen hengsten. Mensen zijn slecht in mikken.

Centreren is leuk. Betekent voor 1024 x 768 dat je een klein venstertje ergens in het midden van het scherm hebt waar je content in zit. Nou schrijf ik even 3 A4tjes vol. De scrollruimte is klein. De kans dat ik op het venster klik om het focus te geven is klein. Nu zit je hier op het forum, en je ziet maar 1 scrollbar en die zit rechts, en is bijna net zo groot als het hele scherm.

Waarom, in godesnaam, zou je die niet gebruiken?

- Stel dat max-width en max-height goed werden ondersteund, dan zou ook het liquid layouten zo weer in zwang raken.

Scrollen is goedkoop. Een boek heeft pagina's die dezelfde grootte zijn omdat je anders met losse lappen papier ligt te zeulen. Een website heeft die beperking niet en het is volstrekt achterlijk om real-world beperkingen toe te gaan passen op dingen die zich er niks van aan hoeven te trekken.

Websites die ik in mijn vrije tijd maak zijn over het algemeen vrij complex (semi liquid). De oorzaak: artistieke aanleveringen in PhotoShop, waardoor de background de viewport bepaalt.

Daarom laat je de klant zelf geen design doen, of ga je ze heel snel leren waarom hun ontwerp waardeloos is. Leer ze te ontwerpen voor het web, niet voor drukwerk, video of multimedia CD-roms.

[ Voor 10% gewijzigd door Yoozer op 06-08-2009 10:00 ]

teveel zooi, te weinig tijd

donderdag 6 augustus 2009 10:00

Acties:

0 Henk 'm!

Bosmonster

*zucht*

crisp schreef op donderdag 06 augustus 2009 @ 09:07:
[...]

https://developer.mozilla...illa%27s_DOCTYPE_sniffing

Transitional doctypes (volledige, dus met system identifier) triggeren 'Almost Standards Mode' (wat natuurlijk iets anders is dan 'almost-quirksmode' ). Het verschil met standards mode is minimaal, en de kans is groot dat dat verschil ooit nog eens weggewerkt gaat worden (het gaat ironisch gezien om sliced images in table layouts )

Ehm ja almost standards mode bedoelde ik natuurlijk, het was nog vroeg

Overigens verschilt het nogal per doctype wat het triggered. Veiligste keuze blijft gewoon een strict doctype of html 5 doctype. Ik zie geen reden om een transitional doctype te hanteren eerlijk gezegd anno 2009.

[ Voor 13% gewijzigd door Bosmonster op 06-08-2009 10:03 ]

donderdag 6 augustus 2009 10:09

Acties:

0 Henk 'm!

moozzuzz

Booster schreef op woensdag 05 augustus 2009 @ 21:05:
IE8: Load:2591ms Table Start:2836ms Table End:2836ms
FF3.5: Table Start:12ms Table End:386ms Load:1294ms
Bij mij duurt het ook echt even voor de tabel uberhaubt in beeld komt in IE.

Dit kan een probleem zijn als je bv een tabel zou gebruiken om een groot gastenboek of forum weer te geven.

Mijn ervaring met FF3 vs. IE6 geeft aan dat voor (erg) grote data-tables IE beter scoort dan FF. Namelijk na rendering is IE nog handelbaar en FF niet (als in: reageert niet meer)

donderdag 6 augustus 2009 10:22

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Bosmonster schreef op donderdag 06 augustus 2009 @ 10:00:
[...]

Ehm ja almost standards mode bedoelde ik natuurlijk, het was nog vroeg

Overigens is de "almost standards mode" behaviour van o.a. Gecko hetzelfde als de "standards mode" in IE7. IE8 lijkt wel de "almost standards mode" behaviour te hebben overgenomen. Jammer, want dat was een kans geweest om "almost standards mode" te droppen zoals al eens eerder is voorgesteld.

Overigens verschilt het nogal per doctype wat het triggered. Veiligste keuze blijft gewoon een strict doctype of html 5 doctype. Ik zie geen reden om een transitional doctype te hanteren eerlijk gezegd anno 2009.

Ik moest zelf zoeken naar de transitional DTD, die gebruik ik ook al jaren niet meer

Intentionally left blank

donderdag 6 augustus 2009 16:02

Acties:

0 Henk 'm!

donderklik

northing.nl

Leuk om te lezen wat de verschillen zijn tussen het gebruik van tables en divisions op technisch vlak.

Waarom semantic web (dus divisions) vooral zo belangrijk is, is dat deze wordt gebruikt door spraakbrowsers en screenreaders. Die hebben niets te doen met mooie opmaak en css, maar gebruiken de semantic web voor de 'spraak/voel'-opmaak van de pagina's.

W3C zegt hier het volgende over in Web Content Accessibility Guidelines 1.0 (Guideline 3)

quote: http://www.w3.org/TR/WAI-...gl-structure-presentation
Using markup improperly -- not according to specification -- hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it.

Het is zeker niet gemakkelijk om aan deze toegankelijkheids richtlijnen te voldoen. Een "Triple-A"-status behalen is ver van gemakkelijk. Maar als al je pagina's aan de "A"-status voldoen, maak je je mensen met een functiebeperking wel gelukkiger.

edit:
Ik heb de hele topic niet gelezen, maar gezocht op een aantal steekwoorden (blind, braille), omdat ik deze argumenten mistte in het begin van de topic (pagina 1-5). Hierdoor heb ik het over hoofd gezien dat Booster al een heel stuk over toegankelijkheid heeft geschreven. $_/-\o_$

[ Voor 13% gewijzigd door donderklik op 06-08-2009 16:17 . Reden: Dubbel post (?) ]

Northing.nl

donderdag 6 augustus 2009 16:47

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Ik had het ook al genoteerd maar dan had je moeten zoeken op 'voorleesbrowser'

Professionele website nodig?

donderdag 6 augustus 2009 16:51

Acties:

0 Henk 'm!

Soultaker

donderklik schreef op donderdag 06 augustus 2009 @ 16:02:
Waarom semantic web (dus divisions) vooral zo belangrijk is, is dat deze wordt gebruikt door spraakbrowsers en screenreaders. Die hebben niets te doen met mooie opmaak en css, maar gebruiken de semantic web voor de 'spraak/voel'-opmaak van de pagina's.

Nou heb ik hier persoonlijk niet heel veel ervaring mee, maar ik heb wel eens een slechtziende met een laptop zien werken, en die had dan gewoon een brailleregel met bijbehorende software die willekeurige tekst van het scherm kon kopiëren naar de brailleregel. Voor zover ik weet werkt voorleessoftware op dezelfde manier: als je tekst kunt selecteren, kan 't voorgelezen worden.

Die software doet dus helemaal niets op HTML niveau. Het werkt gewoon in combinatie met een normale browser, en als de tekst correct gerendert wordt en te selecteren is, dan kan 'ie voorgelezen worden. Niets semantisch web en W3C standaarden. Gelukkig ook maar, want als slechtzienden dáár van afhankelijk waren dan zou misschien 0,1% van het web voor ze beschikbaar zijn.

Ik denk dat usability dus voor een groot deel uit niet-technische aspecten bestaat: niet te kleine fontsizes gebruiken (of zorgen dat de browservoorkeur daarvoor gerespecteerd wordt), geen laag-contrast-kleuren bij elkaar, dat soort dingen.

[ Voor 9% gewijzigd door Soultaker op 06-08-2009 16:53 ]

donderdag 6 augustus 2009 16:56

Acties:

0 Henk 'm!

disjfa

be

Soultaker schreef op donderdag 06 augustus 2009 @ 16:51:
[...]
Nou heb ik hier persoonlijk niet heel veel ervaring mee, maar ik heb wel eens een slechtziende met een laptop zien werken, en die had dan gewoon een brailleregel met bijbehorende software die willekeurige tekst van het scherm kon kopiëren naar de brailleregel. Voor zover ik weet werkt voorleessoftware op dezelfde manier: als je tekst kunt selecteren, kan 't voorgelezen worden.

Jij zou blinde mensen laten kloten om text te selecteren (let op, blinde mensen zien echt helemaal niets

)

Dat is best onaardig van je

disjfa - disj·fa (meneer)
disjfa.nl

donderdag 6 augustus 2009 17:00

Acties:

0 Henk 'm!

Soultaker

disjfa schreef op donderdag 06 augustus 2009 @ 16:56:
Jij zou blinde mensen laten kloten om text te selecteren (let op, blinde mensen zien echt helemaal niets )

Nee, dat was een voorbeeld van een slechtziende (die dus wel kan zien dat ergens iets staat, maar niet lezen wat precies); ik weet niet hoe volledig blinden werken. De echte vraag was of tools voor blinden überhaupt op HTML niveau werken, want dat is niet vanzelfsprekend. Als die tools gewoon werken met tekst zoals die in de browser weergegeven wordt, dan werken ze dus prima met table-based layouts.