[HTML] Height en W3 Valid

quote:

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?

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.

quote:

Mediaconsument 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.

quote:

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.

quote:

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).

quote:

Cheatah 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

crisp wijzigde dit bericht 29-12-2005 23:54 (50%)

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.

Sappie wijzigde dit bericht 29-12-2005 23:58 (7%)

quote:

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.

crisp wijzigde dit bericht 30-12-2005 00:03 (11%)

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

Sappie wijzigde dit bericht 30-12-2005 00:09 (11%)

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!

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: Markieman in "[CSS] div's positioneren en mee laten rekken", 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.

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...

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...

quote:

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 .

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?

quote:

vreeke1 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 .

quote:

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 .

quote:

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 .

quote:

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.

quote:

::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?

quote:

"<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!

vreeke1 wijzigde dit bericht 30-12-2005 20:14 (14%)

quote:

::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.

Cheatah wijzigde dit bericht 30-12-2005 20:15 (12%)

quote:

Cheatah 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)

vreeke1 wijzigde dit bericht 30-12-2005 20:39 (6%)

quote:

Cheatah 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

quote:

vreeke1 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 .

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

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

En zoals het wel hoort:
Cascading Stylesheet:

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

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.

quote:

vreeke1 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 .

Jaap-Jan wijzigde dit bericht 30-12-2005 23:04 (12%)

quote:

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.

vreeke1 wijzigde dit bericht 30-12-2005 23:08 (3%)

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?