[HTML] Height en W3 Valid

[Verwijderd]

Ik heb mij eens verdiept in de W3 standards, en nu ben ik erachter gekomen dat "height" niet als attribute bij de Table-tag mag worden gebruikt. Nu heb ik ook gelezen dat dit een veel voorkomend probleem is en dat de enige oplossing (die overigens niet eens in alle browsers werkt) is dat je CSS moet gebruiken.

Nu heb ik op www.bedrijfhandel.nl/test/test.html geprobeerd een W3 valid pagina te maken. Dat is gelukt, maar zoals jullie zien is in IE de pagina veel te lang en loopt het linker menu alsnog niet door tot onder. En dat terwijl ik al verschillende combinaties heb geprobeerd met styles.

Cascading Stylesheet:

html, body {height: 100%;}

HTML:

<table style="height: 100%;">

Als je naar beneden scrollt dan kan je zien dat in IE de pagina precies 84 pixels te hoog is, en dat is precies de hoogte van de header cell.

Kan iemand mij hierbij helpen? Hoe krijg ik het menu dus zo hoog als de browser is?

P.S.: Denk dat dit overigens een handig topic is om ergens aan toe te voegen want het is een veel vorkomend probleem...

[ Voor 11% gewijzigd door Verwijderd op 29-12-2005 21:47 ]

[JHS]

Als je je dan toch in standaarden aan het verdiepen bent: begrijp dat CSS niet een oplossing is om aan de standaard te voldoen, maar dat het met semantiek te maken heeft, en nog wat van die leuke dingen. Lees dan gelijk even dit en vooral dit

In Firefox is de table ook echt 100% hoog, en in míjn IE (6.0) is de pagina flink wat hoger dan 84px, op het oog 100% + wat er boven de table zit: de header. Dus volgens mij is 'ie in IE wel degelijk 100% hoog. Dus volgens mij is je probleem non-existent?

[ Voor 4% gewijzigd door JHS op 29-12-2005 21:59 ]

[MueR]

wat de TS bedoelt, is dat de pagina in zn totaal 100% moet zijn, en niet 100% + 84px.

[Borizz]

Wat je moet doen is je content cel geen hoogte geven (geen height: 100%) en je tabel op 100% hoogte laten staan. Je geeft dan alleen je header cel een hoogte en de rest wordt automatisch opgevuld door je content cel.

Maar je moet natuurlijk zowiezo geen tabellen voor layout gebruiken:

JHS schreef op donderdag 29 december 2005 @ 21:58:
Als je je dan toch in standaarden aan het verdiepen bent: begrijp dat CSS niet een oplossing is om aan de standaard te voldoen, maar dat het met semantiek te maken heeft, en nog wat van die leuke dingen. Lees dan gelijk even dit en vooral dit

[Verwijderd]

MueR schreef op donderdag 29 december 2005 @ 22:00:
wat de TS bedoelt, is dat de pagina in zn totaal 100% moet zijn, en niet 100% + 84px.

Dit bedoel ik inderdaad!

[Verwijderd]

Borizz schreef op donderdag 29 december 2005 @ 22:05:
Wat je moet doen is je content cel geen hoogte geven (geen height: 100%) en je tabel op 100% hoogte laten staan. Je geeft dan alleen je header cel een hoogte en de rest wordt automatisch opgevuld door je content cel.

Maar je moet natuurlijk zowiezo geen tabellen voor layout gebruiken:

[...]

Ik heb alle height="100%" weggehaald uit het bestand en nu werkt het nog niet, ondanks dat de tabel wel op height: 100% staat. Hij maakt de pagina iig niet meer veels te hoog. Nu het linker menu nog

[ Voor 8% gewijzigd door Verwijderd op 29-12-2005 22:16 ]

[JHS]

Verwijderd schreef op donderdag 29 december 2005 @ 22:12:
[...] Ik heb alle height="100%" weggehaald uit het bestand en nu werkt het nog niet, ondanks dat de tabel wel op height: 100% staat

Het kan niet op een eenvoudige manier, behalve dan door je design liquid te maken, volgens mij, of daar met javascript te vogelen. Zonder javascript kan je je header in een container doen met bijvoorbeeld height: 20%; en je table in een container met height: 80%;, waarna je de table binnen die container 100%; laat zijn. Als je 100%-84px wil bereiken moet je aan de slag met javascript .

[Verwijderd]

[rml][ CSS] Lange kolom duwt in FF footer niet naar beneden[/rml]

[Verwijderd]

JHS schreef op donderdag 29 december 2005 @ 22:18:
[...]
Het kan niet op een eenvoudige manier, behalve dan door je design liquid te maken, volgens mij, of daar met javascript te vogelen. Zonder javascript kan je je header in een container doen met bijvoorbeeld height: 20%; en je table in een container met height: 80%;, waarna je de table binnen die container 100%; laat zijn. Als je 100%-84px wil bereiken moet je aan de slag met javascript .

Ik had al zoiets gehoord ja, maar het lijkt mij toch te gek vol woorden dat HTML zoiets als dit niet goed kan

[Verwijderd]

http://www.bedrijfhandel.nl/test/test2.html
Hierbij een overzichtelijker HTML bestand. Het is dus mijn bedoeling om in Internet Explorer de zwarte balk tot aan de onderkant van de browser te laten lopen. Dit wordt namelijk mijn menu. Maar zoals te zien is wordt hij te groot. Dit komt weer doordat ik <td height="100%"> heb gebruikt maar als ik dat niet gebruik krijg ik het brakke resultaat zoals in:
http://www.bedrijfhandel.nl/test/test3.html

[crisp]

Verwijderd schreef op donderdag 29 december 2005 @ 22:21:
[...]


Ik had al zoiets gehoord ja, maar het lijkt mij toch te gek vol woorden dat HTML zoiets als dit niet goed kan

HTML is ook niet bedoelt voor styling en positioning, daar is CSS voor.
Probleem met CSS is dat de ontwikkeling en adoptie daarvan nogal danig vertraagd is en wordt door een niet nader te noemen softwarebedrijf uit Redmond die toevallig jaren geleden een browser op de markt hebben gebracht die op dit moment nog steeds een dominate positie inneemt op de browsermarkt maar waar al jaren geen verbeteringen in zijn aangebracht...

Voor de rest kan ik dit topic ook maar in 1 zin samenvatten: tables zijn niet voor layout bedoelt. Er zijn op het web zat voorbeelden van goed gebruik van HTML en CSS waarin een dergelijke opzet als die jij voor ogen hebt eenvoudig crossbrowser te realiseren is...

[TheBorg]

crisp schreef op donderdag 29 december 2005 @ 22:31:
tables zijn niet voor layout bedoelt.

Daarom is de frontpage van tweakers.net ook zonder tabellen opgebouwd.

[Verwijderd]

Ik begrijp dat HTML niet voor stylen is maar toch vind ik het allemaal maar raar.

Er zijn op het web zat voorbeelden van goed gebruik van HTML en CSS waarin een dergelijke opzet als die jij voor ogen hebt eenvoudig crossbrowser te realiseren is...

Zou je een voorbeeld kunnen geven want ik heb tervergeefs gezocht, en kreeg alleen maar websites die niet door de W3 Validator kwamen, helaas...

[Verwijderd]

En zoals je ziet ben ik met een website bezig die op een breed publiek is gericht, dus om nu layers te gebruiken voor de layout zie ik niet zo zitten. Dit ivm de ondersteuning van browsers, of valt dit mee?

[crisp]

TheBorg schreef op donderdag 29 december 2005 @ 22:37:
[...]

Daarom is de frontpage van tweakers.net ook zonder tabellen opgebouwd.

De Tnet frontpage is code gemaakt ver voor mijn tijd. Delen zijn al aangepast (de updatetrackers en het menu bijvoorbeeld), maar de rest kan pas met een volledige overhaul echt goed aangepakt worden.
Kijk liever naar bijvoorbeeld de markup van dit forum welke een jaar geleden volledig op de schop is gegaan.

[crisp]

Verwijderd schreef op donderdag 29 december 2005 @ 22:39:
En zoals je ziet ben ik met een website bezig die op een breed publiek is gericht, dus om nu layers te gebruiken voor de layout zie ik niet zo zitten. Dit ivm de ondersteuning van browsers, of valt dit mee?

Ten eerste vind ik het woord 'layers' misleidend. De meeste mensen gebruiken het als een soort synoniem voor div-elementen (wat m.i. weer iets anders is dan het layer-element uit het NS4 tijdperk), maar een layer impliceerd iets als werken met lagen wat in de meeste gevallen gewoonweg niet zo is als je het over HTML/CSS-layout hebt.

Je hebt wel een punt mbt browser-ondersteuning (en dan specifiek als het gaat om 1 bepaalde, door mij eerder gerefereerde browser) - browser-quirks, bugs, en tekortkomingen maken de leercurve wel wat stijler als je af wilt stappen van de 20e-eeuwse manier van het opmaken van web-pagina's

[TheBorg]

Het is niet om te flamen hoor. Maar iedereen roept altijd keihard 'CSS, semantiek, bla, bla' terwijl een pixel perfecte layout (en dat in elke browser) m.b.v. tables heel wat minder hoofdpijn kost. En dat ligt niet aan CSS maar aan de browsers.

Just my opinion.

[Verwijderd]

TheBorg schreef op donderdag 29 december 2005 @ 22:49:
Het is niet om te flamen hoor. Maar iedereen roept altijd keihard 'CSS, semantiek, bla, bla' terwijl een pixel perfecte layout (en dat in elke browser) m.b.v. tables heel wat minder hoofdpijn kost. En dat ligt niet aan CSS maar aan de browsers.

Just my opinion.

Niks kost hoofdpijn als je het meteen goed aanleert.

*Je moet proberen om met vragen te komen voordat je aan iets begint. Hierdoor begin je met een goede basis waardoor je niet met lastige problemen komt te zitten. Daarbij is je code zo schoon mogelijk houden daar ook heel handig bij.

[ Voor 23% gewijzigd door Verwijderd op 29-12-2005 22:53 ]

[Verwijderd]

Verwijderd schreef op donderdag 29 december 2005 @ 22:38:

Zou je een voorbeeld kunnen geven want ik heb tervergeefs gezocht, en kreeg alleen maar websites die niet door de W3 Validator kwamen, helaas...

Een voorbeeld:
http://www.w3.org/TR/WCAG10/
http://www.w3.org/TR/html401/
http://www.w3.org/TR/CSS21/

Ja, veel leesvoor dus. Van het kijken naar andere websites zul je in dit geval weinig leren. Je zult eerst de achterliggende gedachten en principes moeten begrijpen. Er zijn behalve mensen ook nog mensen met bepaalde handicaps (blind, slechtziend, woordblind, kleurenblind, doof, verlamd, ouderdom) en zoekmachines.

Het gaat voornamelijk om begrip en presentatie. Voor machines is het begrip het probleem, voor mensen is het de presentatie.

Jouw site moet zo goed mogelijk "werken", en dat betekent dat in gevallen die je wellicht niet helemaal kon voorzien, machines moeten proberen om er toch nog wat van te maken. En dat kunnen ze beter als je de juiste markup (HTML in dit geval) gebruikt.

[Sappie]

Verwijderd schreef op donderdag 29 december 2005 @ 22:39:
En zoals je ziet ben ik met een website bezig die op een breed publiek is gericht, dus om nu layers te gebruiken voor de layout zie ik niet zo zitten. Dit ivm de ondersteuning van browsers, of valt dit mee?

De ondersteuning van CSS is in alle browsers tegenwoordig van dusdanig niveau dat het realiseren van zowat elke layout wel cross-browser mogelijk is (zij het soms met wat omwegen in bepaalde browsers). Sommige layouts echter zijn misschien (iets) eenvoudiger te bewerkstelligen door gebruik van tables voor de layout, maar dit blijft hoe dan ook fout.

Je zou denk ik het beste eens kunnen beginnen met wat te lezen over CSS en (semantische) HTML (en daarover is genoeg te vinden), want aan je site te zien ben je een tijdje in de website wereld stil blijven staan (nofi).

wat enigszins nuttige links die ik zo snel gevonden heb:

http://www.naarvoren.nl/artikel/structuur/
http://home.parse.nl/~michiel/semantiek.html (reeds eerder genoemd)
http://www.brainjar.com/css/positioning/
http://www.richinstyle.com/guides/css2.html

[Verwijderd]

TheBorg schreef op donderdag 29 december 2005 @ 22:49:
Het is niet om te flamen hoor. Maar iedereen roept altijd keihard 'CSS, semantiek, bla, bla' terwijl een pixel perfecte layout (en dat in elke browser) m.b.v. tables heel wat minder hoofdpijn kost. En dat ligt niet aan CSS maar aan de browsers.

Ligt dat niet meer aan gebrek aan begrip en ervaring van de persoon die zich ermee bezig houdt?

Overigens is het natuurlijk ook de truc om websites te maken die niet per se pixel perfect hoeven te zijn. Sterker nog, de jaren 90 technieken maken dat juist ingewikkeld, en zorgen er meestal voor dat onderhoud plegen aan een website een hel is.

[Verwijderd]

Ik wil me wel verdiepen in CSS maar ik vraag me sterk af of dit wel handig is voor mijn website, ivm met de compatibility dus.
Wat raden jullie aan voor een website die door een breed publiek wordt bezocht.
Is het bijvoorbeeld ook handig om XHTML te gaan gebruiken? Niet alleen met het oog op de toekomst maar juist op dit moment, is het nu ook al handig om te gebruiken?

[ Voor 29% gewijzigd door Verwijderd op 29-12-2005 23:00 ]

[crisp]

TheBorg schreef op donderdag 29 december 2005 @ 22:49:
Het is niet om te flamen hoor. Maar iedereen roept altijd keihard 'CSS, semantiek, bla, bla' terwijl een pixel perfecte layout (en dat in elke browser) m.b.v. tables heel wat minder hoofdpijn kost. En dat ligt niet aan CSS maar aan de browsers.

Just my opinion.

Ik sluit me aan bij Cheatah: misschien kan jij met je beperkte CSS-kennis sneller een layout in elkaar flansen met tabellen, maar ik weet uit ervaring dat latere aanpassingen van dergelijke code minstens 2x zoveel tijd kost dan wanneer het een layout is gebaseerd op CSS.
Daarbij, met de nodige ervaring (ja, ervaring opbouwen kost tijd), is het opzetten van een layout met CSS meestal niet eens tijdrovender dan met tabellen.

Het ligt niet aan de browsers, het ligt imho aan 1 specifieke browser. Als die browser vlak na de recommendation status van CSS2 (in 1998) deze recommendation had overgenomen als implementatie waren we hedentendage al veel verder geweest. De CSS3 recommendations en drafts pakken al veel issues aan waar designers tegenaanlopen doordat bepaalde zaken in CSS2 niet handig of makkelijk te realiseren zijn, maar dankzij eerdergenoemde browser kunnen we nu nog minstens 5 jaar wachten totdat dergelijke vernieuwingen gemeengoed worden...

[Sappie]

Verwijderd schreef op donderdag 29 december 2005 @ 22:58:
Ik wil me wel verdiepen in CSS maar ik vraag me sterk af of dit wel handig is voor mijn website, ivm met de compatibility dus.
Wat raden jullie aan voor een website die door een breed publiek wordt bezocht.
Is het bijvoorbeeld ook handig om XHTML te gaan gebruiken? Niet alleen met het oog op de toekomst maar juist op dit moment, is het nu ook al handig om te gebruiken?

check cheatah's eerste post

en lees dit eens: http://home.parse.nl/~michiel/semantiek.html

dus dit is denk ik wat iedereen tegenwoordig aanraadt:

HTML voor de structuur
CSS voor de presentatie
en js voor evt gedrag

Verder gebruik je beter gewoon HTML4 ipv XHTML, zoek maar eens op google: http://www.google.nl/sear...&btnG=Google+zoeken&meta=

[ Voor 41% gewijzigd door Sappie op 29-12-2005 23:05 ]

[crisp]

XHTML is geen opvolger van HTML zoals veel mensen denken. XHTML is een XML-application van HTML (HTML is een SGML-application) bedoelt om het te kunnen gebruiken samen met andere XML-applications zoals SVG en MathML. Als je het niet als zodanig gebruikt kan je beter gewoon HTML gebruiken aangezien er nogal wat addertjes onder het gras zitten als je XHTML op een goede manier wilt toepassen (95% van de websites die XHTML gebruiken doen het verkeerd).

Er is trouwens een workgroup bezig met HTML5 (veel browser ondersteunen daar al gedeeltjes van zoals canvas - IE niet offcourse...)

[Verwijderd]

crisp schreef op donderdag 29 december 2005 @ 23:10:
XHTML is geen opvolger van HTML zoals veel mensen denken. XHTML is een XML-application van HTML (HTML is een SGML-application) bedoelt om het te kunnen gebruiken samen met andere XML-applications zoals SVG en MathML. Als je het niet als zodanig gebruikt kan je beter gewoon HTML gebruiken aangezien er nogal wat addertjes onder het gras zitten als je XHTML op een goede manier wilt toepassen (95% van de websites die XHTML gebruiken doen het verkeerd).

Er is trouwens een workgroup bezig met HTML5 (veel browser ondersteunen daar al gedeeltjes van zoals canvas - IE niet offcourse...)

Ik dacht dat XHTML eigenlijk meer een vorm is van HTML maar dan met een etiquette, om zodoende de taal duidelijker te maken..
Maar wat bedoel jij dan met addertjes en wat doen die 95% dan verkeerd?

[Sappie]

De meeste sites die pretenderen XHTML valid te zijn versturen het met het verkeerde MIME-type, waardoor browsers het dus niet als zijnde XML parsen. IE kan met dit MIME-type sowieso niet overweg (verrassing). Maar hier is verder genoeg over te vinden.

Het enige praktische (afgezien van andere XML shit zoals MathML) aan XHTML is in mijn ogen dat het (wanneer dus met het juiste MIME type verzonden) well-formedness afdwingt en zodoende de kwaliteit van websites in het algemeen zou kunnen verbeteren.

[Verwijderd]

Verwijderd schreef op donderdag 29 december 2005 @ 23:13:

Ik dacht dat XHTML eigenlijk meer een vorm is van HTML maar dan met een etiquette, om zodoende de taal duidelijker te maken..
Maar wat bedoel jij dan met addertjes en wat doen die 95% dan verkeerd?

Als je "echte" XHTML aanbiedt, dus tegen de browser vertelt dat het XML is, zal een browser er niets mee kunnen/mogen doen als het document niet valideert. Aangezien er nogal wat websites worden gevoed door onderhoudssystemen die niet uitgaan van XML, zal dit de nodige ellende opleveren. Uiteindelijk betere markup, en betere ontwikkeltools, maar initieel veel ellende.

Wat veel websites nu doen, is XHTML aanbieden als zijnde HTML 4.01 compatible XHTML, dus de browser mag wel foutcorrectie toepassen indien nodig. Gevolg hiervan is dat je eigenlijk net zo goed meteen een HTML 4.01 document had kunnen aanleveren, maar in praktijk gaat het XHTML versturen als HTML eigenlijk altijd goed.

[crisp]

Sappie schreef op donderdag 29 december 2005 @ 23:19:
De meeste sites die pretenderen XHTML valid te zijn versturen het met het verkeerde MIME-type, waardoor browsers het dus niet als zijnde XML parsen. IE kan met dit MIME-type sowieso niet overweg (verrassing). Maar hier is verder genoeg over te vinden.

De W3C recommendation zegt erover dat XHTML 1.0 Transitional met een XHTML-mimetype verstuurd zou moeten worden (SHOULD) - zeker als de UA aangeeft dat te prefereren middels accept-headers, en dat andere smaken XHTML (1.0 Strict en 1.1 en hoger) met een XHTML-mimetype verstuurd moet worden (MUST).
Als je echter besluit XHTML als text/html te serveren dien je wel te voldoen aan de guidelines zoals vermeld in appendix C - en daar schort het nogal eens aan bij sites die XHTML (pretenderen te) gebruiken. Het verschil met HTML houdt namelijk niet op bij de syntax; ook CSS, scripting en andere zaken kennen verschillen mbt een HTML-omgeving.
Daarbij doet een browser weinig met een DTD; als jij een document als text/html verstuurd zal de browser het gewoon als HTML behandelen ondanks die mooie XHTML DTD. Voor de browser is het gewoon HTML, dus had je er net zo goed een HTML DTD boven kunnen zetten.

Het enige praktische (afgezien van andere XML shit zoals MathML) aan XHTML is in mijn ogen dat het (wanneer dus met het juiste MIME type verzonden) well-formedness afdwingt en zodoende de kwaliteit van websites in het algemeen zou kunnen verbeteren.

Juist de error-correction van HTML maken het zo'n prettige markup-language. Een foutje is immers zo gemaakt, en als je daarbij ook nog eens input van buitenaf verwerkt in je site dan loop je zonder XML-based backend al gauw tegen parse-errors aan als je XHTML met XHTML-mimetype zou serveren.

Qua strictheid wijkt XHTML(1.0) niet af van HTML(4.01) (door bepaalde beperkingen is XHTML1.0 in sommige gevallen zelfs minder strict dan HTML4.01).

[crisp]

Verwijderd schreef op donderdag 29 december 2005 @ 23:24:
[...]
... maar in praktijk gaat het XHTML versturen als HTML eigenlijk altijd goed.

Omdat de browser niet naar DTD's kijkt maar naar de mimetype en het dus ook als HTML behandeld en ook als zodanig error-correction toepast (wat maar goed ook is omdat het eigenlijk mallformed HTML is)

Waar het wmb op neerkomt is: als je XHTML document met XHTML-mimetype niet werkt in browsers die dat aankunnen dan heb je dus een invalid XHTML document (je gebruikt dus technieken die enkel werken in een HTML-omgeving of je XHTML is niet well-formed*). In de praktijk is HTML dus meestal een logischere keuze dan XHTML.

* +/- 50% van de sites met een XHTML DTD zijn niet well-formed en zouden dus met XHTML-mimetype niet eens renderen, van de overige 50% zou 90% stuklopen op zaken die specifiek zijn voor een HTML-omgeving maar anders werken in een XML-omgeving (appendix C dus niet gevolgd). Sommige mensen noemen XHTML dan ook met recht een business failure

[ Voor 50% gewijzigd door crisp op 29-12-2005 23:54 ]

[Sappie]

Je verhaal is ff completer inderdaad crisp was XHTML 1.0 Transitional helemaal vergeten en de dingen in Appendix C wist ik ook zeker niet allemaal.

Verder is het zeker waar dat de error-correction van HTML het tot een fijne markup language maakt. Echter is het m.i. toch het streven van elke webdevver om well-formed HTML te produceren (en zodoende de error-correction overbodig te maken). En juist de verplichte well-formedness van XHTML zou ertoe bijdragen dat meer webdevvers well-formed markup produceren. (en dat zou alleen maar positief zijn, toch?)

Niet dat ik dus pleit voor het gebruik van XHTML; integendeel zelfs. Naast het feit dat niet alle browsers overweg kunnen met XHTML MIME-type, zie ik er het voordeel boven HTML4.01 niet van in.

[ Voor 7% gewijzigd door Sappie op 29-12-2005 23:58 ]

[crisp]

Sappie schreef op donderdag 29 december 2005 @ 23:55:
Je verhaal is ff completer inderdaad crisp was XHTML 1.0 Transitional helemaal vergeten en de dingen in Appendix C wist ik ook zeker niet allemaal.

Verder is het zeker waar dat de error-correction van HTML het tot een fijne markup language maakt. Echter is het m.i. toch het streven van elke webdevver om well-formed HTML te produceren (en zodoende de error-correction overbodig te maken). En juist de verplichte well-formedness van XHTML zou ertoe bijdragen dat meer webdevvers well-formed markup produceren. (en dat zou alleen maar positief zijn, toch?)

Niet dat ik dus pleit voor het gebruik van XHTML; integendeel zelfs. Naast het feit dat niet alle browsers overweg kunnen met XHTML MIME-type, zie ik er het voordeel boven HTML4.01 niet van in.

Het probleem in de praktijk is vaak de back-ends die niet XML-based zijn, en derhalve well-formedness nooit kunnen garanderen...

Tel daarbij op ingeburgerde technieken van 3rd parties (bannerboeren, google's adsense) die vertrouwen op technieken die wel in HTML beschikbaar zijn (javascript's document.write() bijvoorbeeld) maar niet in XHTML.

[ Voor 11% gewijzigd door crisp op 30-12-2005 00:03 ]

[Sappie]

Zou XHTML dus verplichte kost zijn, dan zou dat dus tot gevolg hebben dat er gauw genoeg dusdanige back-ends zouden bestaan maargoed.. de praktijk leert ons dat dat niet zo mag zijn (en nu weet ik niet of ik "gelukkig maar" moet tikken ).

offtopic:
zijn wel een beetje offtopic geraakt

[ Voor 11% gewijzigd door Sappie op 30-12-2005 00:09 ]

[Boelie-Boelie]

Ik denk dat in het volgende artikel wel een hoop aan bod komt, namelijk webstandaarden, (X)HTML, CSS, toegankelijkheid:
www.456bereastreet.com/lab/developing_with_web_standards/

Helaas wordt daar nog wel XHTML aangeraden (twee jaar geleden nog 'in'), maar in een ander artikel van dezeflde auteur kun je lezen wat voor gedoe dat kan opleveren en er zijn inmiddels een hoop artikelen verschenen waarin wordt uitgelegd waarom je beter geen XHTML kunt gebruiken.

En nogmaals, er is tegenwoordig echt niemand meer die serieus met een browser surft die geen CSS ondersteunt (mensen als visueel gehandicapten uitgezonderd natuurlijk).
Om je een idee te geven: The Counter.com: statistieken van november 2005 (alles nieuwer dan IE4.x en NS4.x ondersteunt CSS.)
Dus qua ondersteuning zit het zeker wel goed.

Op de diverse bugs in IE na, maar da's meer een kleine irritatie, geenszins een reden om het te laten!

[Jaap-Jan]

Ik heb eens een nachtje (en ochtend) gestoeid met jouw ontwerp en heb een ontwerpje gemaakt in HTML en CSS, een beetje voor mij als vingeroefening .

Eerst heb ik eens gedacht hoe je pagina er over het algemeen uitziet. Ik zie een kop, een menu, content en een footer. Die heb ik allemaal in divjes gegooid, zodat ik die makkelijk kan opmaken.

Vervolgens heb ik de header (kop) gepositioneerd en opgemaakt. Je hebt bijvoorbeeld een lijntje onderaan de kop, die zie je terug (door de border).

Wat daaronder zit noem ik de body.Eigenlijk heb ik dat idee van markieman: [rml]Markieman in "[ CSS] div's positioneren en mee laten rekken"[/rml], hier stuitte ik op omdat ik wat meer wilde weten over het verschil tussen absolute en relative positioning en toen kwam ik dat voorbeeld tegen. Dat is ook bruikbaar voor deze site.

Vervolgens heb ik de opmaak van het menu goed gezet. Ik zag dat het menu koppen had met een andere achtergrondkleur, dus dat heb ik ingesteld in de paragrafen. Ook zag ik dat de content van het menu (één onder elke menukop) een lijntje boven, links en onder had, dus die heb ik ingesteld. Dat kon ik het makkelijkst doen door de menu- inhoud in een divje (menucontent) te gooien en die op te maken.

Ook zag ik dat het menu aan de linkerkant een gekleurde lijn had van 5px, dus ook dat heb ik toegevoegd. Het menu heeft een float: left en een breedte van 210px, het menu float dus ten opzichte van de div 'body' waarin het menu zich bevindt.

Vervolgens de rubrieken. Dit zijn simpele list- items, die een list-style-image hebben meegekregen, dus in plaats van die saaie discs die er standaard staan, krijg je die images die jezelf had gemaakt.

Daarna de content. De content wordt breder gemaakt naarmate het scherm breder wordt en met margin-left op 230px houdt deze div afstand van het menu aan de linkerkant. Tekst die onder het menu uitkomt, blijft in lijn met de tekst boven het menu. Als je de tekst om het menu heen wilde laten lopen, dan haal je die margin-left weg en stel je een margin-right en margin-bottom in op het menu, dan loopt de tekst daar netjes omheen.

Nu de footer. De tekst daarin is eigenlijk ook een opsomming. In plaats van die tekst onder elkaar te zetten, kun je die tekst achter elkaar krijgen met display: inline (gevonden op internet). De footer is ook afwijkend van kleur, dus dat divje krijgt ook een andere achtergrondkleur. Om ervoor te zorgen dat de footer niet tegen de linkerkant van het scherm zit, stellen we margin-left in op 225px. Op deze manier lijkt deze div gecentreerd, maar als het scherm kleiner zou worden, zou de margin aan de rechterkant kleiner worden. Maar eigenlijk valt dat nauwelijks op.

Tot slot moest de tekst in de footer nog gecentreerd worden, dat kan simpel met text-align: center. Ditzelfde heb ik gedaan met de afbeeldingen onder ::Mijn bedrijfhandel.nl, die zitten in een paragraaf die gecentreerd is.

Dus in plaats van tabellen kun je op deze manier ook een site bouwen. En dan te bedenken dat ik geeneens een webdesigner ben , maar gewoon iemand die het wel leuk vind om af en toe websites te bouwen .

Het resultaat is te zien op: http://members.home.nl/jjvdveen/got/bedrijfhandel.

[Verwijderd]

Hardstikke bedankt voor deze informatie.
Ik was zelf ook al de hele dag bezig met CSS maar snapte nog niet veel van de positionering van de DIV's. De ene keer stond ie onder iets en dan opeens naast iets. Kon er nog niet veel wijs uit worden...
Snap nu het belang van semantiek en het maakt het onderhoud ook wel een stuk makkelijker.
Hardstikek bedankt, en als ie af is dan lezen jullei het wel in dit topic...

[JHS]

Japie_17: In je voorbeeld zet je 2 maal een ul binnen een div, met verder niks erin. Dat is natuurlijk totaal onzinnig, en voor een eventuele interpreter zelfs eerder verwarrend. Sloop die divs eruit zou ik zeggen. Div's en span's zijn semantiekloze elementen (m.u.v. microformats, maar dat gaat hier niet voor op), dus die moet je in mijn ogen zoveel mogelijk zien te vermijden, en alleen gebruiken als groeperingselement, waar ze voor bedoelt zijn...

[Jaap-Jan]

JHS schreef op vrijdag 30 december 2005 @ 17:33:
Japie_17: In je voorbeeld zet je 2 maal een ul binnen een div, met verder niks erin. Dat is natuurlijk totaal onzinnig, en voor een eventuele interpreter zelfs eerder verwarrend. Sloop die divs eruit zou ik zeggen. Div's en span's zijn semantiekloze elementen (m.u.v. microformats, maar dat gaat hier niet voor op), dus die moet je in mijn ogen zoveel mogelijk zien te vermijden, en alleen gebruiken als groeperingselement, waar ze voor bedoelt zijn...

Gedaan. Dat ziet er inderdaad beter uit en qua opmaak maakt het niet zoveel uit .

[Verwijderd]

http://www.bedrijfhandel.nl/test/
Hier is mijn nieuwe update aan de layout. Is dit de bedoeling zoals ik het nu aanpak of zijn er nog punten ter verbetering? Oja, nu heb ik wel weer het probleem zoals aan het begin van de topic, hoe krijg ik het menu in de volledige hoogte? En weet iemand waarom in Firefox de underline van links niet werkt en in IE wel?

Ook liep ik tegen een ander probleem op, namelijk het gebruiken van before and after met betrekking tot de footer en de menuheaders. Het leek mij beter om de :: ook door de CSS te laten genereren aangezien dit ook een style-element is. Maar nu lijkt het erop dat IE dit niet ondersteund, klopt dit?

[JHS]

Verwijderd schreef op vrijdag 30 december 2005 @ 18:50:
Hier is mijn nieuwe update aan de layout. Is dit de bedoeling zoals ik het nu aanpak of zijn er nog punten ter verbetering?

Een enorme verbetering, maar er zijn nog wel wat puntjes . Zo doe je, zoals ik net al bij Japie aangaf, een div om een ul heen, zie hierboven waarom dat zinloos is. "<p class="center">" Center is semantiekloos, je classes / html horen inhoud te benoemen / structuren, en zich niet met opmaak bezig te houden. Daarnaast denk ik dat ook dit in een list hoort. Maar er is vast nog iets wat ik over het hoofd zie .

Oja, nu heb ik wel weer het probleem zoals aan het begin van de topic, hoe krijg ik het menu in de volledige hoogte?

Vaak zat voorgekomen: faux columns .

En weet iemand waarom in Firefox de underline van links niet werkt en in IE wel?

De a:link override je a:hover nu, omdat deze later komt. Draai de volgorde dus om .

Ook liep ik tegen een ander probleem op, namelijk het gebruiken van before and after met betrekking tot de footer en de menuheaders. Het leek mij beter om de :: ook door de CSS te laten genereren aangezien dit ook een style-element is. Maar nu lijkt het erop dat IE dit niet ondersteund, klopt dit?

::after en ::before horen idd niet in je HTML voor te komen, maar afaik ondersteund IE dit inderdaad niet.

[Verwijderd]

::after en ::before horen idd niet in je HTML voor te komen, maar afaik ondersteund IE dit inderdaad niet.

Is er een goed alternatief om de :: en - uit de HTML te halen, dat zowel in IE als Firefox werkt?

"<p class="center">" Center is semantiekloos, je classes / html horen inhoud te benoemen / structuren, en zich niet met opmaak bezig te houden.

Het is geen align-attribute maar een class-attribute, dus zoals ik het nu heb mag het toch? Center is namelijk een selector in mijn CSS-bestand en niet zoals het nu lijkt dat het de tekst direct centreert.

De links werken nu inderdaad ook in Firefox, je moet het maar net weten zoiets ! Bedankt!

[ Voor 14% gewijzigd door Verwijderd op 30-12-2005 20:14 ]

[Verwijderd]

::after en ::before horen idd niet in je HTML voor te komen, maar afaik ondersteund IE dit inderdaad niet.

Hij heeft het over de letterlijke "::" in de titeltjes van de 2 onderdelen in zijn balk aan de zijkant. Typisch een gevalletje van 5 jaar achter lopen, want het is al tijden "uit", en het is altijd al compleet zinloos geweest.

In dit geval kun je - áls je echt zo'n friemeltje voor je menutiteltje wilt - beter die oranje "C" daar zetten als achtergrondplaatje (bijvoorbeeld in het zwart of wit). Maar dergelijke versiersels zijn géén content, en horen dan ook niet in de content thuis. :before zou een goede oplossing zijn als het niet belangrijk is of er wel wat staat. Als je dat wel belangrijk vind, is een achtergrondplaatje de beste oplossing, zoals heel vaak het geval is.

[ Voor 12% gewijzigd door Verwijderd op 30-12-2005 20:15 ]

[Verwijderd]

Verwijderd schreef op vrijdag 30 december 2005 @ 20:14:
[...]

Hij heeft het over de letterlijke "::" in de titeltjes van de 2 onderdelen in zijn balk aan de zijkant. Typisch een gevalletje van 5 jaar achter lopen, want het is al tijden "uit", en het is altijd al compleet zinloos geweest.

In dit geval kun je - áls je echt zo'n friemeltje voor je menutiteltje wilt - beter die oranje "C" daar zetten als achtergrondplaatje (bijvoorbeeld in het zwart of wit). Maar dergelijke versiersels zijn géén content, en horen dan ook niet in de content thuis. :before zou een goede oplossing zijn als het niet belangrijk is of er wel wat staat. Als je dat wel belangrijk vind, is een achtergrondplaatje de beste oplossing, zoals heel vaak het geval is.

Ik heb besloten dat die :: inderdaad niet zo heel belangrijk is, en ze komen nu dus alleen inzicht bij Firefox, wat ik voldoende vind. Maar hoe los ik het probleem van de footer op. Die - zijn toch zeker belangrijke onderdelen van de layout, maar zoals ik ze nu heb staan ze gewoon in de HTML terwijl het toch een style-effect is.

Trouwens, ik vind die faux-collums toch maar een nep oplossing eigelijk... (werkt wel)

[ Voor 6% gewijzigd door Verwijderd op 30-12-2005 20:39 ]

[André]

Verwijderd schreef op vrijdag 30 december 2005 @ 20:14:
[...]

Hij heeft het over de letterlijke "::" in de titeltjes van de 2 onderdelen in zijn balk aan de zijkant. Typisch een gevalletje van 5 jaar achter lopen, want het is al tijden "uit", en het is altijd al compleet zinloos geweest.

Helemaal zinloos is het ook weer niet, vooral niet in de title tag. Ik heb er leuke resultaten mee gehaald qua CTR omdat mensen de titel in de SERPS op vinden vallen

Maar dat zijn uitzonderingen natuurlijk, ik snap je punt wel

[JHS]

Verwijderd schreef op vrijdag 30 december 2005 @ 20:10:
Het is geen align-attribute maar een class-attribute, dus zoals ik het nu heb mag het toch? Center is namelijk een selector in mijn CSS-bestand en niet zoals het nu lijkt dat het de tekst direct centreert.

Je snapt niet wat ik bedoel . Wat ik bedoel is dat je in je HTML alleen content-gerelateerde zaken moet hebben staan. Dus geen opmaak. Dus ook je classes moeten wat zeggen over de content, en dus niet over hoe het opgemaakt moet worden .

[André]

Wat JHS bedoeld is met een voorbeeld het beste te omschrijven, wat dus niet hoort:

Cascading Stylesheet:

.rooieLetters { color: #FF0000; }
.geelVlak { background-color: #FFFF00; }

En zoals het wel hoort:

Cascading Stylesheet:

.subContent { color: #FF0000; }
.bijSchrift { background-color: #FFFF00; }

[Verwijderd]

Ik snap jullie punt en heb het verandert in buttons. Maar zoals ik nu het menu aanmaak (met faux-collums) is dit zoals het hoort? En behalve die div's weghalen waarin de lists staan, hoort er nog wat anders? Begin het al aardig door te krijgen allemaal, en heb nogal wat tutorials gelezen de afgelopen 10 uur, hehehe.

[Jaap-Jan]

Verwijderd schreef op vrijdag 30 december 2005 @ 20:24:
[...]

Die - zijn toch zeker belangrijke onderdelen van de layout, maar zoals ik ze nu heb staan ze gewoon in de HTML terwijl het toch een style-effect is.

Ja, dat vond ik ook best ranzig, maar daar lijkt niets aan te doen. Een andere site die ik tegenkwam deed dat op dezelfde manier: http://www.isitebuild.com/css/css-layout.html. En weer een ander gebruikte stomweg een <p> met een aantal linkjes .

Je huidige site heeft trouwens een bug in Firefox 1.5. Aan de linkerkant komt het plaatje wat je gebruikt voor 'faux columns' uit boven de 'head' div.

edit:
Ik zie dat je steeds druk bezig bent . De site veranderd constant .

[ Voor 12% gewijzigd door Jaap-Jan op 30-12-2005 23:04 ]

[Verwijderd]

Ik zie dat je steeds druk bezig bent . De site veranderd constant .

Hehehe, heb mijn bug ook gespot en weggehaald. Nu nog ff stoeien met de plaatjes, die moeten natuurlijk ook als tekst in de HTML in het geval van de header en de knoppen.

[ Voor 3% gewijzigd door Verwijderd op 30-12-2005 23:08 ]

[Verwijderd]

Hoe zit het trouwens met een tabel, zoals je op www.bedrijfhandel.nl kan zien gebruik ik tabellen. Wat mag er precies wel en niet in een tabel staan? En mag je bijvoorbeeld achtergrond kleur opgegeven of is dit ook een taak van css, of de breedte van een tabel bijvoorbeeld?

[Jaap-Jan]

HTML:

<p><a href="index.php"><h1 id="logo"><strong>

Een <h1> in een <p> ? Je hebt genoeg aan

HTML:

<h1 id="logo"><a href="index.php">

Dan kun je de tekst verbergen met
[code=css]#logo a { display: none; }[/code]

Cascading Stylesheet:

div#head h1#logo a { display: none; }

Dan heb je die <strong> ook niet meer nodig om de tekst te verbergen. Een <h1> in een <p> is sowieso al niet semantisch, <h1> is een kop, en <p> is gewone tekst. Gewone tekst volgt normaal gesproken op een koptekst, maar zit daar nóóit ín .

Over tabellen, waar en hoe je die kunt gebruiken kun je vinden in dit topic: [rml][ Semantiek/HTML/CSS] ul/dl/table keuze[/rml]

Ik denk dat je hieruit de conclusie kunt trekken dat je dat gerust in tabellen kunt doen. Bedenk alleen wel dat het de bedoeling is dat je 1 onderdeel (bijvoorbeeld Inventarissen) beschrijft als tabel, maar dat je niet de hele aanbodsite als 1 tabel gaat beschrijven.

Kleurtjes en vormen zou ik wel in een extern css- bestand doen, het houdt de code schoner en je plaatst je opmaak weer op één plek (in het css- bestand). Het opmaken van de tabel is zeker de taak van css.

Dank je wel JHS .

[ Voor 105% gewijzigd door Jaap-Jan op 31-12-2005 10:56 ]

[JHS]

Japie_17 schreef op zaterdag 31 december 2005 @ 01:07:
Dan kun je de tekst verbergen met

Cascading Stylesheet:

#logo a { display: none; }

Codestijlkeuze: ik zou h1#logo gebruiken om aan te geven wat je selecteert, of liever nog: div#header h1#logo. Zo krijg je gelijk een overzicht van de hiërarchie in je css, en bovendien is het eenduidig .

Cascading Stylesheet:

div#header {
   color: red;
   width: 50%
}

div#header h1#logo {
   color: lime;
   height: 50px;
}

div#header h1#logo a:hover {
   color: purple;
}

Zegmaar .

[Verwijderd]

Cascading Stylesheet:

display: none;

Als ik die code gebruik is het plaatje geen hyperlink meer en kan men niet terugkeren naar de begin pagina door het logo aan te klikken...

[JHS]

Døh . Maar waarom niet gewoon vertrouwen op de alt tekst .

[Jaap-Jan]

Verwijderd schreef op zaterdag 31 december 2005 @ 12:30:

Cascading Stylesheet:

display: none;

Als ik die code gebruik is het plaatje geen hyperlink meer en kan men niet terugkeren naar de begin pagina door het logo aan te klikken...

Op de frontpage van tweakers.net doen ze dat op de volgende manier:

HTML:

<h1 id="logo"><a href="http://www.bedrijfhandel.nl/"><span>Bedrijfhandel.nl</span></a></h1>

Cascading Stylesheet:

div#head h1#logo a {
    display: block;
    width: 100%;
    height: 100%;
}

div#head h1#logo a span {
    display: none;
}

JHS schreef op zaterdag 31 december 2005 @ 13:01:
Døh . Maar waarom niet gewoon vertrouwen op de alt tekst .

Ik denk omdat het een koptekst is .

[ Voor 35% gewijzigd door Jaap-Jan op 31-12-2005 14:17 ]

[JHS]

Japie_17 schreef op zaterdag 31 december 2005 @ 14:15:
[...] Ik denk omdat het een koptekst is .

Hoe bedoel je ? En je moet bedenken dat de image onderdeel is van de content van de pagina . En daarbij: headings moet je niet gebruikern om de titel van de volledige website in te zetten .

[Verwijderd]

Op de frontpage van tweakers.net doen ze dat op de volgende manier:

HTML:

<h1 id="logo"><a href="http://www.bedrijfhandel.nl/"><span>Bedrijfhandel.nl</span></a></h1>

Cascading Stylesheet:

div#head h1#logo a {
    display: block;
    width: 100%;
    height: 100%;
}

div#head h1#logo a span {
    display: none;
}

Dat had ik eerst maar ivm semantiek is die <span> natuurlijk van geen betekenis... Maar lijkt mij een situatie van kiezen of delen...

[Verwijderd]

als ie van weinig betekenis is wil niet zeggen dat je 'm niet kan gebruiken, juist hier is een element van weinig betekenis juist geschikt imho

[JHS]

Verwijderd schreef op zaterdag 31 december 2005 @ 18:12:
[...] Dat had ik eerst maar ivm semantiek is die <span> natuurlijk van geen betekenis... Maar lijkt mij een situatie van kiezen of delen...

En aangezien dat stukje tekst semantisch gezien volledig binnen die h1 valt, kan je het beste ook een semantiekloos element toevoegen . (Wat mophor zegt.) Overigens heb je nu nog steeds alléén een h1 binnen een div, met verder niks. Zelfde geval voor de ul#navigation binnen de div#footer, en de ul#leftnav binnen div.menucontent1 . En als laatste: volgens mij kan je een hele hoop classes vervangen door id's. Dat maakt je css en eventuele js eenduidiger in mijn ogen.

[Verwijderd]

JHS schreef op zondag 01 januari 2006 @ 11:39:
[...]
En aangezien dat stukje tekst semantisch gezien volledig binnen die h1 valt, kan je het beste ook een semantiekloos element toevoegen . (Wat mophor zegt.) Overigens heb je nu nog steeds alléén een h1 binnen een div, met verder niks. Zelfde geval voor de ul#navigation binnen de div#footer, en de ul#leftnav binnen div.menucontent1 . En als laatste: volgens mij kan je een hele hoop classes vervangen door id's. Dat maakt je css en eventuele js eenduidiger in mijn ogen.

Als ik hem uit de div haal dan werkt "display: none" niet meer...

[JHS]

vreeke1: Waar reageer je op ?

Waarom is die "Bedrijfhandel.nl" in vredesnaam strong . En overigens: zoals ik hierboven al meermaals heb uitgelegd hoort de titel van de gehele website niet in een hx. Daar is die voor Volgens mij kan je beter het volgende doen:

HTML:

<p id="website_title">
  <a href="index.php">
    <span id="website_title_text">Bedrijfshandel.nl</span>
  </a>
</p>

Cascading Stylesheet:

p#website_title a {
   display: block;
   background-image: url('image.gif');
}

p#website_title a span#website_title_text {
   text-indent: 9999px;
}

Overigens kan je #website_title_text zowel in de HTML als in de CSS op zich weglaten .

[ Voor 12% gewijzigd door JHS op 03-01-2006 20:32 ]

[Verwijderd]

Het is gelukt zoals je op www.bedrijfhandel.nl/test/ kan zien. Maar nu zit ik een beetje met de footer. Hij overlapt nu de content terwijl ik wil dat ie onderaan de pagina komt. Ook is de breedte van de footer niet meer goed. Hij hoort zoals op www.bedrijfhandel.nl.

Ik heb nu:

HTML:

    <div id="footer">
            <ul id="navigation">
                <li><a href="index.php" 

class="footerlink">Home</a> -</li>
                <li><a href="forum/index.php" 

class="footerlink">Forum</a> -</li>
                <li><a href="zoeken.php" 

class="footerlink">Zoeken</a> -</li>
                <li><a href="help.php" 

class="footerlink">Help</a> -</li>
                <li><a href="voorwaarden.php" 

class="footerlink">Voorwaarden</a> -</li>
                <li><a href="contactus.php" 

class="footerlink">Contact Us</a></li>
            </ul>
</div>

Cascading Stylesheet:

div#footer {
    position: absolute;
    background-color: #f6a800;
    left: 215px;
    text-align: center;
    height: 16px;
    font-size: 11px;
    padding-top: 2px;
    float: bottom;
}

ul#navigation li {
    display: inline;
}

[Verwijderd]

En ik zie net dat in 800x600 resolutie de website in IE heel vreemd gaat doen... maar in Firefox wel goed blijft...

[JHS]

vreeke1: float: bottom bestaat dan ook helemaal niet. In FireFox werkt het volgende:

Cascading Stylesheet:

div#footer {
position: relative;
float: left;
clear: both;
width: 100%;
}

[Jaap-Jan]

De browser doet precies wat je gevraagd wordt, maar wat vraagt klopt niet helemaal .

'position: absolute' geeft aan dat je zelf precies wilt zeggen waar iets op de pagina moet komen. Dit doe je met 'top:', 'bottom:', 'left:' en 'right:', maar dat zegt dus echt: zet dat neer op die pixel.

'float: bottom' bestaat niet. Je kunt alleen 'left', 'right' of 'none' kiezen.

Dit doet 't hem trouwens voor mij:

Cascading Stylesheet:

div#footer {
    background-color: #f6a800;
    margin-bottom: 1em;
    text-align: center;
    clear: both;
}

[Verwijderd]

Ik vraag me af hoe ik ooit float: bottom heb kunnen verzinnen . Maar begin css nu aardig door te krijgen, snapte eerst niet precies hoe je nu elementen op een bepaald eplaats kon zetten maar het wordt al aardig duidelijk. Net een tutorial over float en position gelezen die heel veel duidelijk maakte.

[Verwijderd]

Hebben jullie er ook last van dat bij 800x600 in IE de website heel raar doet? Er komt een hele witte ruimte boven de content te staan..

[JHS]

Ja, maar hoe het komt zou ik je zo snel niet kunnen zeggen .