[RFC] (x)html & CSS reference *

[Verwijderd]

Ik heb een korte tutorial geschreven over verstandig xhtml en CSS gebruik.

Aan de orde komen onder andere
- een stukje geschiedenis
- xhtml syntax en dagelijks gebruik
- correct gebruik van de juiste tags
- korte inleiding CSS
- css syntax en verstandig gebruik; naamgeving
- eea over boxmodelverschillen
- het visual formatting model
- browserverschillen
- veel voorkomende praktijkproblemen

De tutorial staat online op www.rikkertkoppes.com/cursus dus ik ga niet alle inhoud hier weer herhalen uiteraard

Ik heb de hele boel geschreven aan de hand van w3c references, eigen kennis, discussies hier op GoT en verschillende online artikelen

Waarom ik dit topic open is jullie feedback. Wat vinden we ervan, is het duidelijk, staan er fouten in, zijn er dingen die nog missen?

Verder wilde ik de sectie met praktijkproblemen en -oplossingen nog wat uitbreiden met veel voorkomende problemen, dus suggesties zijn hierin welkom

[IschaGast]

Op deze pagina staat de volgende fout:

gebruik lijsten (<uk>, <ol>, <dl>) voor menu's en opsommingen

[Clay]

* Clay gaat het iig ff grondig bekijken zo

alvast 1 ding:

code:

 <script language="JavaScript" type="text/javascript">
<![cdata[
//javascript
]]>
</script>

het language attribuut was dacht ik deprecated/achterhaald, iig overbodig. En als je de CDATA zo begint krijg je js errors. Of het helemaal geldig is weet ik niet (ik vind van wel, maarja), maar xml parsers (en browsers) snappen het iig wel als je het zo doet:

code:

<script type="text/javascript">
// <![cdata[

// ]]>
</script>

[ Voor 11% gewijzigd door Clay op 12-02-2004 12:43 ]

[X-Lars]

- is nodig om HTML te laten voldoen aan de XML (en SGML) standaarden in plaats van alleen aan de SGML standaard

- attribuutnamen (aan elkaar)

- Voor XHTML documenten dient, zoals gezegd

- definiëren

- praktische

- De syntax om een bepaald element van opmaak is als in het volgende voorbeeld: (euh...)

- Ook er bestaan ook andere pseudoclasses

---

goed bezig
ik vind het wel een goede uitleg! kunnen we mooi mensen naar verwijzen.

[ Voor 55% gewijzigd door X-Lars op 12-02-2004 13:22 ]

[Willem]

1e Indruk: Ziet er goed uit.
Ga 'em op m'n gemak doorlezen vanavond.

[Verwijderd]

Clay schreef op 12 februari 2004 @ 12:43:
* Clay gaat het iig ff grondig bekijken zo

alvast 1 ding:

code:

 <script language="JavaScript" type="text/javascript">
<![cdata[
//javascript
]]>
</script>

het language attribuut was dacht ik deprecated/achterhaald, iig overbodig. En als je de CDATA zo begint krijg je js errors. Of het helemaal geldig is weet ik niet (ik vind van wel, maarja), maar xml parsers (en browsers) snappen het iig wel als je het zo doet:

code:

<script type="text/javascript">
// <![cdata[

// ]]>
</script>

het 2e punt van je: da's juist de reden waarom die cdata blocks worden weggelaten, omdat browsers er niet goed mee om kunnen gaan. Want als je dit door redeneert zou je voor stylesheets de cdata blocks helemaal eng in moeten pakken:

code:

/* <![cdata[ */

/* ]]> */

edit: texturele opmerkingen zijn uiteraard enorm welkom, maar daar ga ik niet allemaal op reageren, ik voer ze wel door natuurlijk

[ Voor 13% gewijzigd door Verwijderd op 12-02-2004 12:53 ]

[Verwijderd]

Waar ik heel erg mee zit is dat je geen achtergrondkleur hebt ingesteld.
voor mensen die een 1 of ander windows theme hebben aan staan is je site onleesbaar. Iets wat eigenlijk niet kan voor zo'n site.

Je moet er niet vanuit gaan dat hij overal standaard wit is.

[Verwijderd]

zit wat in, misschien dat ik de systeemkleuren wel overneem, moet kunnen volgens w3c, alleen ff kijken of iedereen dat ondersteunt

dit dus: http://www.w3.org/TR/REC-CSS2/ui.html#system-colors

[ Voor 20% gewijzigd door Verwijderd op 12-02-2004 13:21 ]

[Pjottski]

Hoe moeten de mensen bij 'Het even lange kolommen probleem' (http://www.rikkertkoppes.com/cursus/praktijk3.htm) komen, op de pagina http://www.rikkertkoppes.com/cursus/praktijk2.htm is geen navigatie meer aanwezig

Voor de rest is het een mooie en duidelijke tutorial geworden.

[Bosmonster]

Ik las dit:

elementen moeten altijd afgesloten worden, dus geen enkele <br> maar <br></br> of <br/>

Maar volgens mij zijn dingen als <br></br> fout toch? Het moet gewoon <br/> zijn.

Net als <img src="..."></img>, moet gewoon <img src="..." /> zijn.

[ Voor 22% gewijzigd door Bosmonster op 12-02-2004 15:03 ]

[crisp]

Bosmonster schreef op 12 februari 2004 @ 15:02:
Ik las dit:


[...]


Maar volgens mij zijn dingen als <br></br> fout toch? Het moet gewoon <br/> zijn.

Net als <img src="..."></img>, moet gewoon <img src="..." /> zijn.

Niet fout, maar levert mogelijkerwijs wel problemen op omdat een sluittag voor deze elementen in HTML verboden is.

[Kwai_gon_jinn]

in XHTML moet je het sluiten; dus:

single tags:

code:

<br /> 
[img]"plaatje.jpg"[/img]

andere tags:

code:

<a href="www.tweakers.net" title="tweakers.net">tweaker</a> 
<strong>dik gedrukt</strong>

[edwinistrator]

Ik vind het een goeie overzichtelijke 'cursus', klasse

[Verwijderd]

crisp schreef op 12 februari 2004 @ 15:07:
[...]

Niet fout, maar levert mogelijkerwijs wel problemen op omdat een sluittag voor deze elementen in HTML verboden is.

daarom ook die extra spatie, die is ook niet per se nodig volgens XML

Peedjeeh schreef op 12 februari 2004 @ 13:26:
Hoe moeten de mensen bij 'Het even lange kolommen probleem' (http://www.rikkertkoppes.com/cursus/praktijk3.htm) komen, op de pagina http://www.rikkertkoppes.com/cursus/praktijk2.htm is geen navigatie meer aanwezig

Voor de rest is het een mooie en duidelijke tutorial geworden.

jij hebt 't ook gevonden (pijltjes toetsen dus) maar ik zal het nog even toevoegen, de navigatie wordt door m'n js erbij gekwakt en die valt in dit geval achter die kolommen, vandaar dat ik 'm effe heb uitgezet

@allen: thx voor alle comment, ik wil dit overzicht zo correct mogelijk maken, handig voor iedereen lijkt me

[ Voor 55% gewijzigd door Verwijderd op 12-02-2004 15:47 ]

[Verwijderd]

Wat dacht je van media="projecten" gebruiken, zodat het een _echte_ presentatie wordt (in Opera tenminste, zie ook log van Ian Hickson, Opera forums etc.).

XHTML is middels scripts te benaderen volgens het HTML object model, alsmede het XML object model (HTML-DOM en XML-DOM)

document.write e.d. zal niet werken in XHTML (_echt_ XHTML -> application/xhtml+xml).

In een echte XHTML document wordt ook het gebruik van het META element (iig degene in het voorbeeld) afgeraden.

In het voorbeeld heb je binnen het BODY element geen BLOCK-Level element gezet -> invalid in XHTML1.0 Strict (is wellicht wel handig om daar op te letten), daarnaast moet je de tags die je daarbinnen gebruikt dubbelescapen, anders klopt de code niet meer.

de server moet worden ingesteld om xhtml/xml te verzenden ipv text/html

application/xhtml+xml*

attributen moeten een waarde hebben

Waarom? /class=""/ is volgens mij goed hoor.

elementen mogen niet overlappen, dus niet <h1><b></h1></b> maar <h1><b></b></h1>

Zeer slecht voorbeeld, met name omdat het H1 element standaard al dikgedrukt gestijld heeft en als het bedoelt is voor _extra_ nadruk wordt duidelijk het verkeerde element gebruikt.

elementnamen en attribuut namen moeten in lowercase geschreven worden

Is in strijd met wat erboven staat: "de XML syntax stelt de volgende extra eisen aan de SGML syntax:".

er moet een XHTML doctype gedeclareerd worden

Waar staat dat?

XHTML is XML, dus er moet een xml declaratie boven

Eveneens fout.

Voor XHTML zijn de volgende 3 doctypes gedefinieerd:

Voor XHTML1*. Misschien ook handig om te vermelden dat een DTD niet volledig genoeg definieert hoe de syntax in elkaar zit? Dus <a><strong><a/></strong></a> is valid volgens het DTD, maar niet volgens de spec.

In het voorbeeld bij XHTML namespaces kun je die twee namespace beter ook in het root element zetten, zo zou je net zo goed alle f'jes kunnen weghalen, of je moet er weer XHTML binnen in gaan gebruiken, het voorbeeld slaat nu nergens op.

Wordt vervolgd...

[drm]

[nohtml]

Anne:
Voor XHTML1*. Misschien ook handig om te vermelden dat een DTD niet volledig genoeg definieert hoe de syntax in elkaar zit? Dus is valid volgens het DTD, maar niet volgens de spec.

Voorop gesteld dat ik denk dat het wel nuttig is om het te melden, heb je niet helemaal gelijk; het volgende staat in de strict DTD:

code:

<!-- a elements use %Inline; excluding a -->

<!ENTITY % a.content
   "(#PCDATA | %special; | %fontstyle; | %phrase; | %inline.forms; | %misc.inline;)*">

<!-- *snip* -->

<!ELEMENT a %a.content;>

Maar goed, da's flauw

[Verwijderd]

Je hebt het wel fout DRM

Want ik gebruikte een %phrase; element binnen A en die mag weer alles van %inline; bevatten.

[tomato]

Maar voor je ook maar begint te valideren tegen een DTD kijk je natuurlijk of je document well-formed is (en dat is dat stukje dus niet)

[Verwijderd]

O nee? Het is zeker well-formed.

Root element is A, daar is er maar 1 van. Voor de rest klopt de nesting ook prima. (morgen oid kijk ik de rest wel door btw).

Misschien moet je is nakijken wat well-formed is en wat valid is, in dit geval is het well-formed en als je er wat XHTML elementjes omheen zou doen (plus een DOCTYPE uiteraard) is het ook valid.

[BetuweKees]

zou ook wel lekker zijn als je link tags in je header opneemt (prev, next, top, etc) naar gerelateerde pagina's..

[drm]

Anne:
Je hebt het wel fout drm

Want ik gebruikte een %phrase; element binnen A en die mag weer alles van %inline; bevatten.

Dat lijkt me vreemd. Is het dan zo dat een geneste %phrase de beperkingen van een %a.content mogen overriden Kan wel, hoor, maar dat zou me echt enorm verbazen, dat druist volledig tegen mijn gevoel van een documenttree in...

edit:

Anne:
Misschien moet je is nakijken wat well-formed is en wat valid is, in dit geval is het well-formed en als je er wat XHTML elementjes omheen zou doen (plus een DOCTYPE uiteraard) is het ook valid.

Ik zou het trouwens wel op prijs stellen als je eerst even nagaat tegen wie je het hebt voordat je begint te steigeren. 't Getuigt niet erg van sociale vaardigheden dat je iemand, die toch zijn sporen al wel verdiend heeft hier op het forum, meteen zo af begint te blaffen.

[ Voor 40% gewijzigd door drm op 12-02-2004 17:16 ]

[ludo]

Het afsluiten van elementen is ook aan te raden, maar in verband met backwards compatibiliteit alleen in de verkorte vorm (<br />) en met een extra spatie voor de afsluitende /.

Waarom is het eigenlijk verstandig om die extra spatie voor die slash toe te voegen Ik deed dit vroeger ook steeds, maar tegenwoordig niet meer, omdat PHP/Sablotron dit niet doet bij tags zonder sluittag.

[Verwijderd]

Nou kijk. Je hebt %a.content; . Daarin mag je dus %phrase; gebruiken, zie je eigen quote. En als je nu %phrase; gaat opzoeken staat daar weer dat er %inline; in mag, waar A onder valt.

Zie ook m'n gebrabbel hierover: http://annevankesteren.nl...9/invalid-after-validated

edit:
nested bb tags werken niet helemaal, een edit:

Ik zou het trouwens wel op prijs stellen als je eerst even nagaat tegen wie je het hebt voordat je begint te steigeren. 't Getuigt niet erg van sociale vaardigheden dat je iemand, die toch zijn sporen al wel verdiend heeft hier op het forum, meteen zo af begint te blaffen.

Is helemaal niet zo bedoelt hoor ;-), ik probeer meestal zo kort mogelijk neer te zetten hoe het in elkaar zit en ik heb nooit de bedoeling iemand anders daarmee af te blaffen, tenzij er een sarcastische of een andere toepasselijke smiley bijstaat).

Waarom is het eigenlijk verstandig om die extra spatie voor die slash toe te voegen Ik deed dit vroeger ook steeds, maar tegenwoordig niet meer, omdat PHP/Sablotron dit niet doet bij tags zonder sluittag.

Er bestaan browsers die erover struikelen.

[ Voor 66% gewijzigd door Verwijderd op 12-02-2004 17:22 ]

[drm]

Anne:
Nou kijk. Je hebt %a.content; . Daarin mag je dus %phrase; gebruiken, zie je eigen quote. En als je nu %phrase; gaat opzoeken staat daar weer dat er %inline; in mag, waar A onder valt.

Ja, ik begrijp het wel, maar ik vind het vreemd dat dat kan. Je zou zeggen dat de buitenste elementen juist ook de ascendant elementen beperken, anders slaat die beperking helemaal nergens op. Ik bedoel: dat is toch echt dikke vette crap dat als je zegt (in je DTD) een 'a' element mag geen 'a' elementen bevatten, maar dat wordt genegeerd zodra een ascendant daarvan opeens wel weer 'a' elementen mag bevatten

Dat slaat echt nergens op _{Ik geloof wel dat je gelijk hebt, daar niet van, maar dan moeten we toch eens een briefje gaan schrijven naar de lui die dat bedacht hebben.}

Is helemaal niet zo bedoelt hoor ;-), ik probeer meestal zo kort mogelijk neer te zetten hoe het in elkaar zit en ik heb nooit de bedoeling iemand anders daarmee af te blaffen, tenzij er een sarcastische of een andere toepasselijke smiley bijstaat).

offtopic:
Je zou het misschien anders kunnen doen: smileys neerzetten als je het niet vervelend bedoelt . Maar goed, genoeg daarover

[tomato]

Verwijderd schreef op 12 februari 2004 @ 16:46:
O nee? Het is zeker well-formed.

Je hebt gelijk, en zeker als ik je verkeerd 'verbeter' mag je dat gerust duidelijk zeggen

(Ik weet overigens wel wat well-formedness inhoudt, maar ik las over een slash heen in je stukje. Als je iemand wilt verbeteren is het natuurlijk extra belangrijk dat je alles even goed leest... )

[ Voor 4% gewijzigd door tomato op 12-02-2004 17:40 ]

[Verwijderd]

Anne: volgens dit stukje w3c heb je toch niet gelijk met die nested a:
ik lees verkeerd, dit is precies wat jij bedoelt. volgens de specs mag het niet, volgens de DTD wel, dus de DTD is sloppy

The following elements have prohibitions on which elements they can contain (see SGML Exclusions). This prohibition applies to all depths of nesting, i.e. it contains all the descendant elements.

a
must not contain other a elements.

(http://www.w3.org/TR/xhtml1/#prohibitions)

Voor je andere opmerkingen:

[...]
document.write e.d. zal niet werken in XHTML (_echt_ XHTML -> application/xhtml+xml).

nooit getest, maar waarom is dat? (heb dit stukje van w3c)

In het voorbeeld heb je binnen het BODY element geen BLOCK-Level element gezet -> invalid in XHTML1.0 Strict (is wellicht wel handig om daar op te letten), daarnaast moet je de tags die je daarbinnen gebruikt dubbelescapen, anders klopt de code niet meer.

dat voorbeeld is transitional, daar mag het volgens mij wel, maar je hebt gelijk dat het netter kan

[...]
application/xhtml+xml*

of text/xml of application/xml, zal ik veranderen

[...]
Waarom? /class=""/ is volgens mij goed hoor.

die heeft wel een waarde, maar die is leeg, dit sloeg op bv <input type="checkbox" checked />, kan misschien duidelijker

[...]
Zeer slecht voorbeeld, met name omdat het H1 element standaard al dikgedrukt gestijld heeft en als het bedoelt is voor _extra_ nadruk wordt duidelijk het verkeerde element gebruikt.

mee eens, zal wel iets als <strong><em></strong></em> doen

[...]
Is in strijd met wat erboven staat: "de XML syntax stelt de volgende extra eisen aan de SGML syntax:".

die snap ik niet

[...]
Waar staat dat?
[...]
Eveneens fout.

ok, niet noodzakelijk wel aan te raden dan

[ Voor 30% gewijzigd door Verwijderd op 13-02-2004 11:42 ]

[Verwijderd]

[...]
nooit getest, maar waarom is dat? (heb dit stukje van w3c)

Hier kun je daar wel wat over lezen.

http://bugzilla.mozilla.org/show_bug.cgi?id=68193
http://bugzilla.mozilla.org/show_bug.cgi?id=192367

Het zit dus niet in de xml dom, omdat het w3c het expliciet uit de spec heeft gegooid en het zou erg moeilijk te krijgen om dit werkend te krijgen in xml.

Hier kun je eventueel nog lezen over cookie ellende in xhtml en dergelijke:
http://bugzilla.mozilla.org/show_bug.cgi?id=111514

Ik heb (alleen maar vluchtig) gekeken naar je tutorial, maar ik moet zeggen dat ik persoonlijk liever alle tekst op een pagina heb en niet dat ik de hele tijd moet klikken om nog een stukje tekst te kunnen lezen.

[Verwijderd]

dat voorbeeld is transitional, daar mag het volgens mij wel, maar je hebt gelijk dat het netter kan

Het klopt dat je in transitional direct #PCDATA binnen BODY mag gebruiken, maar jouw voorbeeld gaat niet valideren ;-).

die heeft wel een waarde, maar die is leeg, dit sloeg op bv <input type="checkbox" checked />, kan misschien duidelijker

Inderdaad, niet iedereen zal dat snappen zonder voorbeeld

die snap ik niet

In de _XML_ syntax (waar dus XHTML moet staan ;-)) ligt helemaal niet vast dat elementen in kleine letters e.d. moeten staan.

ok, niet noodzakelijk wel aan te raden dan

DOCTYPE wel, XML Prolog is _af_ te raden: http://www.plasticlab.nl/index.php?p=68&more=1&c=1

Kris
IE4.x/Mac will render a blank page when it encounters the XML-prologue at the top. A HTML comment instead does fine to put IE6 into quirks mode.

[Verwijderd]

xml prolog hoort wel boven een true xhtml document (omdat het xml is) in de praktijk is het idd af te raden, zoals ik een pagina verder vertel. Dat alles voor de DTD ie in quirks gooit wist ik niet, maar dat gaat er zeker in, want dan zou ik dus helemaal die prolog weglaten (ook omdat het geen xml meer is door het weglaten van cdata blokken om je script en style)

[Rickets]

Verwijderd schreef op 13 februari 2004 @ 16:12:
xml prolog hoort wel boven een true xhtml document (omdat het xml is) in de praktijk is het idd af te raden, zoals ik een pagina verder vertel.

Een xml-document hoeft ook geen prolog te hebben

quote: http://www.w3.org/TR/2000/REC-xml-20001006#sec-prolog-dtd

XML documents should begin with an XML declaration which specifies the version of XML being used

[Verwijderd]

(ook omdat het geen xml meer is door het weglaten van cdata blokken om je script en style)

Dat hangt er maar net vanaf _wat_ de inhoud is van deze elementen.

Daarnaast maakt het voor SCRIPT en STYLE eigenlijk niet uit als het een goede user agent is, want ze bevatten #CDATA volgens de DTD en geen #PCDATA en als een user agent zich daar aan houdt is er niks aan de hand. Sommige dingen veranderen blijkbaar bij XHTML1.0 daar is het wel #PCDATA... Maar dan nog verwijs ik terug naar m'n reactie op de quote, aangezien je bijvoorbeeld > en & etc. niet zou kunnen gebruiken, waardoor het wel well-formed blijft (daarnaast behandelt elke UA het nog als #CDATA AFAIK). En als laatste puntje zou ik nog willen zeggen dat je dit geen van allen moet gebruiken, maar alleen met externe bestanden (wat trouwens inhoud dat je <?xml-stylesheet?> gebruikt ipv <link/> (volgens een W3C-NOTE).

[Verwijderd]

Nog een paar dingen

code:

<f:table xmlns:f="http://www.rikkertkoppes.com">
  <f:type>eikenhouten keukentafel</f:type>
</f:table>

Je zou het XMLNS attribuut beter op het root element kunnen zetten, zo heeft het voorbeeld weinig nut (dit had ik eerder gezegd, maar ik ga het nu iets meer toelichten hoop ik). Aangezien je nu net zo goed dit in het document had kunnen zetten, wat (1) korter is en (2) duidelijker om te begrijpen:

code:

 <table xmlns="http://www.rikkertkoppes.com">
  <type>eikenhouten keukentafel<type>
<table>

gebruik <div> alleen als je echt geen ander element weet te vinden

Voeg toe: "maar ga hier niet te ver in" (doe ik zelf heel vaak, maar vanuit semantisch oogpunt klopt er niks van).

vermijdt <i> en <b>, dergelijks elementen leggen ook iets van opmaak vast, gebruik liever <em> en <strong>

Meer toelichten. <i> != <em> en <b> != <strong>. <i> zou bijvoorbeeld gebruikt kunnen worden voor bootnamen e.d. heb ik me ooit laten vertellen en nog veel meer dingen. Als je wil kan ik wel wat oude posts opzoeken hierover.

gebruik headers in de juiste volgorde

Voorbeeldje erachter zou handig zijn.

Dat voorbeeld eronder leent zich trouwens meer voor een DL dan een TABLE en daarnaast ziet het er nogal raar uit aangezien je de ene keer <element>... </element> de andere keer <element> en af en toe <element /> gebruikt...

Misschien is het handig om bij het CSS gedeelte ook iets _aan_ te raden, zoals bijvoorbeeld het alleen gebruiken van externe style sheets en het vermijden van het STYLE attribuut.

de laatste 2 selectors zijn wel een onderdeel van de CSS 2.0 specificatie (uit 1998), alleen worden deze nog niet door MSIE ondersteund, dus zijn ze praktisch onbruikbaar.

Vooral de child selector wordt erg vaak voor hacks gebruikt, wellicht handig om toe te voegen?

De dingen tussen de {} heten declaraties die weer bestaan uit eigenschappen en waarden (vrij vertaald).

Ik kan me herinneren dat IE http://www.w3.org/TR/CSS2/selector.html#first-letter ondersteund (in quirks mode weet ik niet zeker).

"CSS media selectors" -> niet ondersteund door MacIE. Het lijkt me beter om mensen aan te raden het MEDIA attribuut te gebruiken op het LINK element.

"* {font-family: arial}" -> generieke font-family opgeven -> sans-serif. Dit komt meerdere keren voor!

" color: darkblue; " -> ook achtergrondkleur opgeven -> background:transparent; ! En andersom uiteraard -> color:inherit;

Ga aub niet '-moz-box-sizing' promoten! Ten eerste is het W3C box model beter, ten tweede is dat geen W3C property, maar een Mozilla property die eruit geknikkerd wordt zodra er geen toekomst meer voor is (of de property is uit de drafts, of de property is standaard en -moz- ervoor is niet nodig).
(Merk trouwens op dat Opera wel de W3C property ondersteund zonder prefix)

Het is een veel betere manier om IE6 in quirks mode te zetten en dan d.m.v. een child-selector de width en height voor andere browsers goed te zetten.

het wordt dus gescheiden van andere elementen door line breaks

?! Ik hoop dat je bedoelde 'margin' op te schrijven. Laten we niet terugkeren naar het <br> tijdperk.

'display:run-in;' en display:compact;' worden ook niet ondersteund door Mozilla. Lijkt me een beetje raar om maar gewoon overal MSIE neer te knallen (het is misschien ook handig om onderscheid te maken tussen WinIE en MacIE).

Let bij MSIE op met welk boxmodel gewerkt wordt. Pas het boxmodel van Mozilla hierop aan.

Zoals eerder gezegd, dat is niet echt forward-compatible. Een beetje domme uitspraak imo.

Let op dat niet alle pseudoclasses te gebruiken zijn (E:hover werkt niet op andere elementen dan <a> in MSIE) hier zijn fixes voor

Deze zin loopt niet lekker.

MSIE neemt al snel genoegen met gebrekkige code, maar andere browsers hoeven dit niet per definitie te doen

->Test daarom in een andere browser, die je code sowieso op een 'standard-compliant' manier behandelen, waardoor het makkelijker wordt cross-browser te werken.

Er zijn waarschijnlijk nog wel wat dingen, maar ik heb niet alle tijd

[JeromeB]

Leuke tutorial, maar u zegt:

Voor XHTML zijn de volgende 3 doctypes gedefinieerd:

Strict Doctype
Transitional Doctype
Frameset Doctype

Misschien hebt u het met opzet weggelaten, maar er is ook nog een XHTML 1.1 doctype en er wordt verder niet echt duidelijk bij gemeld dat men ook een eigen DTD kan maken.

Daarnaast zijn er ook nog XHTML-Print doctypes. Ik kwam er toevallig vandaag achter: http://www.w3c.org/TR/2004/CR-xhtml-print-20040120/

[Verwijderd]

die print doctype is nog maar 4 weken oud, ik zit te twijfelen of het wel verstandig is om die erbij te doen.

Dat je er zelf 1 kan bouwen moet er idd voor de volledigheid bij, ik denk niet dat ik er heel diep op in ga.

Het XHTML 1.1 doctype ga ik er bij zetten, zodra ik gevonden heb waar w3c hem verstopt heeft

@Anne: weer een hoop wijsheid, muchos gracias, ik zal overal even kritisch naar kijken en controleren, bedankt voor je input, zo komen we tot een document waar iedereen wat aan heeft en kan ie wat mij betreft de faq wel in

[Verwijderd]

Complete migratie naar XHTML heeft echter op dit moment als groot praktisch nadeel dat browsers (nog) niet goed overweg kunnen met puur xhtml documenten

Mij overtuig je hier niet mee. En als er geen concrete voorbeelden bij staan moet ik dit wel afdoen als grote onzin.

Bovendien heb je het nergens over accessibility, wat toch wel een enorm grote rol speelt als je fatsoenlijke HTML en CSS wilt schrijven.

Helaas is je site atm even offline, want ik heb vast nog wel veel meer kritiek. Het is bijvoorbeeld een onsamenhangend geheel.

Ik wil je niet beledigen, maar zorg dat je verdomd goed weet waar je mee bezig bent als je een tutorial schrijft. Ik het verleden zijn er al veel te veel baggertutorials geschreven door prutsers die net HTML kenden, en dachten dat ze alles wisten omdat het toch zo makkelijk is allemaal. Er staan nog steeds duizenden waardeloze tutorials online.

[Verwijderd]

no offence taken, da's de reden dat ik de boel hier overleg, het lijkt me nuttig als er uiteindelijk een goede reference uitrolt. Ik weet dus niet verdomd goed waar ik mee bezig ben, zoals wel blijkt uit allerlei dingen die ik over het hoofd heb gezien, maar ik denk dat we dat met z'n allen samen hier wel een bijdrage aan kunnen leveren.

Je bent overigens de eerste van wie ik hoor dat het onsamenhangend is (het verbaasde me al dat een hoop mensen het zo duidelijk vonden), maar zeg dan ook aub op welke punten.

Ik zeg niet dat dit een fantastische tutorial is atm, maar ik hoop dat het wel een fatsoenlijk (en samenhangend) geheel kan worden. Dan heeft iedereen er iets aan imho

[Johnny]

Ik zou het wel handig vinden dat er op de homepage direct staat wat het doel is van de cursus en voor wie hij geschikt is (welk kennisniveau moet de lezer hebben).

Verer zou het ook handig zijn als je gebruikt maakt van de site navigation toolbar van Mozilla en Opera, dat doe je met <link> tags in de <head>.

Hier een voorbeeld:

code:

<link rel="top" href="index.php" title="Terug naar de homepage" />
<link rel="search" href="search.php" title="Zoeken" />
<link rel="help" href="help.php" title="Help en uitleg over de website" />
<link rel="author" href="contact.php" title="Neem contact op met de maker" />
<link rel="index" href="index.php" title="Inhoudsopgave" />

<link rel="first" href="pagina.php" title="Eerste pagina" />
<link rel="last" href="pagina.php" title="Laatste pagina" />

<link rel="prev" href="pagina.php" title="Vorige pagina" />
<link rel="next" href="pagina.php" title="Volgende pagina" />

<link rel="chapter" href="help_about.php" title="Over deze website" />
<link rel="chapter" href="help_general.php" title="Algemeen" />
<link rel="chapter" href="help_profiles.php" title="Profielen" />

Edit:
De tag list is niet erg veelzeggend, hij is Engels, er staat niet bij of een tag leeg/gevuld is, welke attributen er kunnen worden gebruikt, en geen voorbeelden.

[ Voor 28% gewijzigd door Johnny op 14-02-2004 17:34 ]

[Switch]

In mijn mozilla en internet explorer doet je site het niet, hij blijft maar laden en er komt niks uit Ik kon die andere links wel zien die hier gegeven waren.

[coubertin119]

http://www.rikkertkoppes.com/cursus/xhtml6.asp : "practisch" als "praktisch" staat veel netter, het kan zijn dat er op andere pagina's dit ook nog voorvalt.

http://www.rikkertkoppes.com/cursus/css2.asp : "element" en "type" mag wel aan mekaar voor zover ik weet, elementtype dus.

http://www.rikkertkoppes.com/cursus/css3.asp : 1 topic != forum . Pseudo-elementen is trouwens ook correcter dan pseudo elementen.

http://www.rikkertkoppes.com/cursus/css5.asp : Je kan uitleg geven over het hoe en waarom van je declaraties, voor iemand die het topic over whatever:hover niet heeft bekeken, is die declaratie in de body erg raar .

---

In het overzicht, zouden de subpagina's per categorie erg geweldig zijn, nu moet je een paar keer klikken om op de correcte pagina te komen.

That's it for so far .

edit:
http://www.rikkertkoppes.com/cursus/praktijk2.htm heeft geen navigatie, je moet dus op de hoogte zijn van het 4-pijltjesklavier om nog verder te kunnen navigeren, op de pagina erna kan je niet gewoon op Next rammen om naar het volgende hoofdstukje te gaan. Ook een aanduiding dat het einde van een hoofdstukje is bereikt zou leuk zijn en hoofdstukje 3 -> 7 hoort toch gewoon geheel onder CSS ipv een apart onderdeel te zijn?

[ Voor 25% gewijzigd door coubertin119 op 15-02-2004 10:07 ]

[Verwijderd]

<![CDATA[..]]> moet bij mij met hoofdletters, net zoals <!ELEMENT ..> <!ENTITY ..> en <!ATTLIST ..> enzovoorts. Als je het over dit onderwerp hebt, dan is het 'leuk' om even gelijk wat meer achtergrondinformatie te geven. Commentaar in een DTD staat tussen -- en --, wat je ook terugvindt in HTML commentaar tags. Dat zijn natuurlijk <!-- en -->. Nu zie je gelijk beter wat er gebeurt. Door het uitroepteken wordt de tag gelijk herkend als niet-HTML, wel als SGML. En in SGML is alles tussen -- en -- commentaar. Het hoort dus helemaal genegeerd te worden. Eigenlijk is scripts tussen <!-- en --> zetten enorm raar.
Nu is het inderdaad zo dat bijvoorbeeld IE niet lekker met scripts in CDATA sections omgaat. Maar sowieso vind ik het al bad practice om javascript in het HTML document te zetten, als het net zo goed in een extern bestand kan. Idem voor CSS. Voor de developer is het wel fijn dat het even quick&dirty kan, maar verder is er niet veel reden om het niet in een los bestand te zetten.

Ik heb zelf nooit bewust de XHTML 1.0 Transitional doctype gebruikt. Geef eens concrete voorbeelden van gegronde redenen om niet XHTML 1.0 Strict te gebruiken. Het oudere browsers verhaal is sterk aan het veranderen omdat die groep al erg klein is geworden. Ik zie transitional meer als een excuus om een valid XHTML document te krijgen, omdat het dan valideert. Valideren is niks waard als je niet hebt begrepen hoe je HTML moet gebruiken.

Je legt niet uit wat nu echt het nut is van namespaces. Je haalt een stuk betekenis weg uit de markup code. Waar is dat goed voor? Hoe moet een user agent dat interpreteren? Die betekenis neem je niet weg als je elementen uit een andere standaard toevoegd, want die zou een user agent eventueel kunnen herkennen. Denk aan SVG, MathML, XSLT, dáár zijn namespaces nuttig en nodig. Met je eigen namespace zul je ook altijd de doctype declaration aan moeten passen.

Leg bij het CSS gedeelte ook uit dat er 3 soorten stylesheets zijn. Naast die stylesheets waar we allemaal aan denken, heb je ook de standaard stylesheet van de user agent, en de stylesheets van de eindgebruiker. Hier is het ook interessant om dan meteen even de !important regel uit te leggen, en te benadrukken dat deze zoveel mogelijk vermeden moet worden in verband met eventuele conflicten met de user stylesheets. Pseudo classes first-line en first-letter mag je van mij ook wel noemen. Noem ook ergens dat color en background-color het best altijd samen genoemd kunnen worden om voldoende contrast te kunnen garanderen.

Ik verander zelf nooit de boxmodel. Veel problemen kun je voorkomen door niet teveel dingen tegelijk op te geven voor een element, en goed met margins en paddings om te gaan.

Nog één ding over het maken van layout: een achtergrondplaatje gebruiken is geen zonde. Soms is het zelfs zo dat je voorkomt dat je je HTML aan moet passen. In die gevallen is het gebruik van achtergrondplaatjes voor bijvoorbeeld het maken van gekleurde kolommen een prima oplossing, als je het aan mij vraagt.

[Verwijderd]

Verwijderd schreef op 15 februari 2004 @ 13:46:
Commentaar in een DTD staat tussen -- en --, wat je ook terugvindt in HTML commentaar tags. Dat zijn natuurlijk <!-- en -->. Nu zie je gelijk beter wat er gebeurt. Door het uitroepteken wordt de tag gelijk herkend als niet-HTML, wel als SGML. En in SGML is alles tussen -- en -- commentaar.

Hmm. als ik de HTML4.01 DTD open zie ik daar gewoon <!-- en --> gebruikt worden ( http://www.w3.org/TR/html401/strict.dtd ). Het verschil is volgens mij dat in een DTD <!-- -- --> correct is en in HTML niet.

Het hoort dus helemaal genegeerd te worden.

En dat wordt het ook met het juiste content-type (wist je waarschijnlijk al)

Eigenlijk is scripts tussen <!-- en --> zetten enorm raar.

Scripts inline zetten is m.i. raar (zoals je zelf ook al aangaf, niet gequote hier).

Ik heb zelf nooit bewust de XHTML 1.0 Transitional doctype gebruikt. Geef eens concrete voorbeelden van gegronde redenen om niet XHTML 1.0 Strict te gebruiken.

Frames.

Denk aan SVG, MathML, XSLT, dáár zijn namespaces nuttig en nodig.

SVG en XSLT zijn slechte voorbeelden, aangezien SVG puur presentatie is en XSLT puur transformeren.

Met je eigen namespace zul je ook altijd de doctype declaration aan moeten passen.

Geef mij een goede reden waarom ik een DOCTYPE nodig heb als ik een correct content-type gebruik (bij HTML heb je _altijd_ een DOCTYPE nodig).

[crisp]

Verwijderd schreef op 14 februari 2004 @ 14:00:
[...]
Ga aub niet '-moz-box-sizing' promoten! Ten eerste is het W3C box model beter, ten tweede is dat geen W3C property, maar een Mozilla property die eruit geknikkerd wordt zodra er geen toekomst meer voor is (of de property is uit de drafts, of de property is standaard en -moz- ervoor is niet nodig).
(Merk trouwens op dat Opera wel de W3C property ondersteund zonder prefix)

Het is een veel betere manier om IE6 in quirks mode te zetten en dan d.m.v. een child-selector de width en height voor andere browsers goed te zetten.
[...]

Ja, en wat nou als IE na de eerstvolgende update ineens wel child-selectors ondersteund, maar nog steeds niet het W3C box model in quirks?
Daarbij zou ik graag onderbouwing zien waarom het W3C model beter zou zijn; ikzelf en met mij waarschijnlijk vele anderen vinden het IE-model toch logischer...

[Verwijderd]

Ja, en wat nou als IE na de eerstvolgende update ineens wel child-selectors ondersteund, maar nog steeds niet het W3C box model in quirks?

Wie zegt dat de volgende IE nog steeds in quirks gaat vanwege een commentje erboven?

Daarbij zou ik graag onderbouwing zien waarom het W3C model beter zou zijn; ikzelf en met mij waarschijnlijk vele anderen vinden het IE-model toch logischer...

Simpel voorbeeld: IMG. Ander voorbeeld: 'input{height:1em;}'.

[crisp]

Verwijderd schreef op 15 februari 2004 @ 20:15:
[...]
Wie zegt dat de volgende IE nog steeds in quirks gaat vanwege een commentje erboven?

true; feit is dat het gewoon vervelend blijft dat je nooit van tevoren precies weet wat een UA wel en niet precies ondersteund; je design daarvan afhankelijk maken is dan natuurlijk nooit een goed idee (hacks in alle soorten en maten vind ik eigenlijk helemaal een no-go).
In feite wil dat dus zeggen dat je nooit meer pixel-precies zou kunen gaan ontwerpen, of in elk geval dusdanig ontwerpen dat het gebrek aan ondersteuning van bepaalde standaarden je site niet "breekt"; iets wat m.i. wel steeds lastiger wordt...

[...]
Simpel voorbeeld: IMG. Ander voorbeeld: 'input{height:1em;}'.

IMG vind ik een raar voorbeeld in dit aspect omdat het eigenlijk een inline element is... (input ook natuurlijk)

[Johnny]

Ik zeg dat er pas in 2007 een minor update van MSIE komt, versie 6.1 en ik verwacht niet dat daar een heel nieuwe render engine in zal zitten.

Tenzij een alternative browser "te" populair wordt, dan zal MS wel, net als vroeger ieder half jaar een groot aantal verbeteringen brengen.

Het W3C box-model is ook heel logisch, als je er vanuit gaat dat je in de virtuele wereld niet de beperkingen van de echte wereld hebt.

In het echt heb je een doos die heeft een vaste maat bij de rand en daar moet je al je spullen maar weten in te proppen.

In de virtuele wereld heb je zelf controle over alles, als jij iets hebt om in een doos te steken mag je zelf bepalen hoe groot die doos er omheen wordt.

[crisp]

Johnny schreef op 15 februari 2004 @ 21:20:
Ik zeg dat er pas in 2007 een minor update van MSIE komt, versie 6.1 en ik verwacht niet dat daar een heel nieuwe render engine in zal zitten.
[...]

Juist, en daarom ben ik gewoon bang dat alle nieuwe technieken, recommendations en usability-guides ten spijt er weinig anders op zit dan voorlopig gewoon op de oude voet door te gaan als het om main-stream webdevelopment gaat. Dat wil zeggen: toch tables gebruiken in sommige gevallen ipv andere elementen met tig CSS-hacks om het toonbaar te maken in bijvoorbeeld IE. De gebruiker maalt er klaarblijkelijk niet om (anders zou die wel een andere browser gebruiken), de opdrachtgever al helemaal niet (die heeft er toch geen verstand van meestal), en voor jezelf hoef je het meestal ook niet te doen

[Verwijderd]

IMG is een replaced element, net zoals INPUT en heeft momenteel inderdaad 'display:inline;', maar dat wordt 'display:inline-block;'.

en voor jezelf hoef je het meestal ook niet te doen

Ik vind het eerlijk gezegd wel een stuk makkelijker werken dan een beetje in het rond hacken met spacer gifs (het lijkt me trouwens raar, maar wel mogelijk, als IE niet iets meer CSS gaat ondersteunen. Het wordt ten slotte steeds meer gebruikt).

[We Are Borg]

Ik had je al een email gestuurd en bij deze nogmaals: erg leerzaam

[Savantas]

Goed initiatief!
Heb er al enkele kleine 'hoe zat het ook al weer' dingen uit gehaald.

Het viel me wel op dat enkele code blokken in FireFox niet mooi als box worden weergegeven
(zie bv. http://www.rikkertkoppes.com/cursus/styleattr.htm of http://www.rikkertkoppes.com/cursus/visual1.asp).
Zo te zien omdat er geen <p></p> om het code blok staat.

IE laat wel alles in een box zien, dus mogelijk had je dit tot nu toe gemist.
En waarom? ... Genoeg deskundigen hier, ga ik mijn vingers niet aan fikken!

[Verwijderd]

Nu deze toch een kickje heeft gekregen wil ik van de gelegenheid gebruik maken om mezelf te verbeteren. Per CSS 2.1 is het niet erg dat sommige elementen die 'display:inline' hebben wel 'height' en 'width' kunnen hebben. Dit geld voor "inline, replaced elements" (voorbeelden zijn: IMG, INPUT, TEXTAREA). Op "inline, non-replaced elements" mag zowel 'height' als 'width' geen effect hebben (en daar zit de bug bij Internet Explorer) (voorbeelden zijn: SPAN, EM, STRONG).

[Verwijderd]

http://www.rikkertkoppes.com/cursus/praktijk2.htm is 1 van de paginas die niet goed werkt in mozilla.