HTML handleiding feedback

[Jero]

Ik ben al enige tijd bezig met het maken van een Nederlandstalige HTML en CSS handleiding genaamd Modern Markup. Dit heb ik gedaan omdat ik de kwaliteit van de huidige Nederlandstalige handleidingen belabberd vind. In de meeste komt de term CSS niet eens voor of wordt het alleen maar voor de basis dingen gebruikt.

Ik heb nu voor mezelf het idee dat de handleiding voor 90% voltooid is. Alle content is eigenlijk al geschreven. De handleiding bestrijkt alle aspecten van de twee talen en probeert de lezer die geen kennis van HTML en/of CSS heeft op het niveau te brengen waarmee de lezer een fatsoenlijke layout in elkaar kan zetten.

Het zal mij echter niks verbazen als er een aantal onduidelijkheden in zitten (vandaar de 90%). Tijdens het schrijven ben ik erachter gekomen dat het aardig lastig is om constant op het niveau van de lezer te denken zodat alles begrijpelijk blijft. Mijn vraag aan jullie is dan ook of er gekeken kan worden naar de inhoud van de handleiding en de gammele stukken eruit te pikken zodat ik daar verbetering aan kan brengen.

Zoals je ziet is de referentie echter nog niet af. Een klein deel van de HTML elementen is wel gedaan, maar voor het grootste gedeelte moet hier nog aan begonnen worden. Indien je geïnsteresseert bent om te helpen met schrijven kan dat natuurlijk ook. Op de site is een contact formulier waarmee je me kan bereiken.

Alvast bedankt.

[funkwurm]

Ik vind dat je wel heel snel door het verhaal van HTML=>structuur && CSS=>opmaak schiet. Het is niet het W3C geweest dat heeft gezegd "goh, laten we eens fancy pants font-tags maken (of nog erger, blink of marquee)". Dat is allemaal een resultaat van de browserwar zoals die uitgevochten werd in de jaren 90 tussen met name Microsoft en Netscape. Zij hadden op dat moment zo'n grote invloed op de markt dat het niemand luisterde naar het W3C, dat op dat moment alleen maar onleesbaar lange documenten uitgaf waarin ze de ongein-tags en quirks die beide partijen bedachten om de ander voor te zijn wetenschappelijk poogden te verantwoorden.

Het woord browserwar komt in jou inleiding niet voor, en ook als je het hebt over de verschillende browsers die website's verschillend weergeven leg je niet uit hoe dit komt. Je begint meteen met zeggen dat die oliebollen van een microsoft (ok, dat zeg je niet letterlijk ) zoiets als Internet Explorer durven te publiceren, terwijl die niet eens een :hover op een element anders dan het anchor accepteert (en daar heb je helemaal gelijk in, maar welke browser wou er ook alweer geen onmouseover op een ander element dan het anchor hebben?).

Zonder gekkigheid, ik denk dat het zinnig is om uit te leggen waarom applicaties die door professionele software-multinationals worden gemaakt zulke fouten bevatten. Ik merk zelf al dat ik dat moeilijk verkoop aan een klant als ik een website moet maken, want hey, wie ga je geloven? Microsoft met al z'n jaren ervaring, al die producten en geld en weet ik wat, of die snotaap van een whizzkid die de schuld bij een ander neerlegt? (Ik kreeg ooit serieus de vraag "moest je microsoft niet es bellen dan, dat er een bug in hun programma zit?")
Begrijpelijk, maar niet terecht, als je dat niet uitlegt aan iemand die net komt kijken, heeft hij vanaf het begin al een scheef gezicht erover.

Hm, de rest van de tut heb ik nog niet eens bekeken en zie wat een post laat duidelijk zijn dat ik het met je eens ben dat je de eerste bent (zou zijn?) die dit verhaal goed uitlegt in het Nederlands.

[Anoniem: 9542]

ik mis vooral het hele mytheverhaal rond <div>, ik kom volgens mij ook helemaal niks tegen over dat element. Heel erg veel mensen hebben geen flauw idee wat eigenlijk het doel van dat element is, ik zou hem verwachten in je tekst structuur sectie. (je alinea voorbeeld met koppen enzo zou ik ook van div's voorzien)

Ook suggereer je dat id en class attributen zijn ten behouve van styling, dat is ook niet waar, deze attributen hebben helemaal niets te maken met styling, maar met het omschrijven van het doel van het element

iets over menu's navigatie (<map>) mis ik volgens mij ook nog

iets over xhtml, wat het is, waarom je er vrij weinig aan hebt en wat de verschillen zijn met html

wat is trouwens je redenatie achter die

HTML:

<pre><code>...</code></pre>

constructies?

[ Voor 70% gewijzigd door Anoniem: 9542 op 16-04-2006 22:34 ]

[Blaise]

Is het niet een beetje overmoedig om op een website waar je HTML leert, van de gebruikers te vragen of ze hun commentaar van HTML willen voorzien?

Daarnaast is het ook misschien handig om met kleuren elementen/attributen/waardes/code uniform te markeren, zodat je als beginner sneller doorhebt wat welk type is en je sneller een verband legt. Nu is alles zwart en dat vind ik vrij onoverzichtelijk.

Het is dus belangrijk dat je in alt altijd een goede, beknopte omschrijving geeft van de afbeelding voor het geval er probleem ontstaan met de afbeelding (iemand zou de afbeelding bijv. van de server kunnen verwijderen).

(http://modernmarkup.com/html-css/links-en-afbeeldingen/)

[ Voor 66% gewijzigd door Blaise op 16-04-2006 22:57 ]

[BasieP]

ik mis eigenlijk op de hele site voorbeeldjes
bij een heel aantal dingen (elementen/properties etc.) leg je in 1 a 2 zinnen uit wat het doet, maar dit is (Vooral voor een leek) niet altijd te snappen.
voorbeeldjes doen wonderen

(denk bijv. aan pseudo elementen in css, ik denk dat de beschrijving die bij bijv. :before en :after)
verder zou competabiliteit wel handig zijn, aangezien IE niet alles ondersteund. dus hovers op alle dingen die niet anchors zijn enzo

[Blaise]

Als je trouwens kijkt naar een site als http://www.handleidinghtml.nl (ken je waarschijnlijk al), dan zie je dat die veel grondiger is. Sommige informatie is verouderd, maar je steekt er ondanks dat enorm veel van op door alle voorbeelden en uitgebreide behandeling van elk aspect. Bovendien zit de structuur van de site heel goed/handig in elkaar.

[cyspoz]

Ik heb er zojuist snel overheen gekeken en ik denk dat er nog wel links en rechts één en ander bijgewerkt moet worden. O.a. de suggesties zoals hier boven. Maar ik denk dat je wel een heel mooi begin hebt gemaakt... Ik zou zeggen ga zo door.

[Jero]

Ik vind dat je wel heel snel door het verhaal van HTML=>structuur && CSS=>opmaak schiet. Het is niet het W3C geweest dat heeft gezegd "goh, laten we eens fancy pants font-tags maken (of nog erger, blink of marquee)". Dat is allemaal een resultaat van de browserwar zoals die uitgevochten werd in de jaren 90 tussen met name Microsoft en Netscape. Zij hadden op dat moment zo'n grote invloed op de markt dat het niemand luisterde naar het W3C, dat op dat moment alleen maar onleesbaar lange documenten uitgaf waarin ze de ongein-tags en quirks die beide partijen bedachten om de ander voor te zijn wetenschappelijk poogden te verantwoorden.

De bedoeling van de handleiding is om de lezer te leren hoe HTML en CSS gebruikt te kunnen worden, niet een hele geschiedenis te geven van HTML. Ik begrijp je punt en ik probeer ook hetzelfde te zeggen, maar dan met minder woorden.

Het woord browserwar komt in jou inleiding niet voor, en ook als je het hebt over de verschillende browsers die website's verschillend weergeven leg je niet uit hoe dit komt. Je begint meteen met zeggen dat die oliebollen van een microsoft (ok, dat zeg je niet letterlijk ) zoiets als Internet Explorer durven te publiceren, terwijl die niet eens een :hover op een element anders dan het anchor accepteert (en daar heb je helemaal gelijk in, maar welke browser wou er ook alweer geen onmouseover op een ander element dan het anchor hebben?).

Zoals ik al eerder zij is het niet mijn bedoeling om in deze handleiding een compleet overzicht van de evolutie van HTML te geven. Op dit moment is het gewoon zo dat IE bagger is. Hoe dit is gekomen is niet zo belangrijk, maar wat we ermee doen.

Zonder gekkigheid, ik denk dat het zinnig is om uit te leggen waarom applicaties die door professionele software-multinationals worden gemaakt zulke fouten bevatten. Ik merk zelf al dat ik dat moeilijk verkoop aan een klant als ik een website moet maken, want hey, wie ga je geloven? Microsoft met al z'n jaren ervaring, al die producten en geld en weet ik wat, of die snotaap van een whizzkid die de schuld bij een ander neerlegt? (Ik kreeg ooit serieus de vraag "moest je microsoft niet es bellen dan, dat er een bug in hun programma zit?")
Begrijpelijk, maar niet terecht, als je dat niet uitlegt aan iemand die net komt kijken, heeft hij vanaf het begin al een scheef gezicht erover.

Ik denk toch dat het grootste aantal bezoekers wel kan begrijpen (en accepteren) dat grote bedrijven niet automatisch het beste product kunnen produceren. Juist bij grote bedrijven kan je verwachten dat de producten minder worden omdat deze teveel uitgaan van hun imago waardoor de innovativiteit minder wordt. Maar zoals jij zei heb je inderdaad ook mensen die dat niet kunnen bevatten. Toch denk ik dat dit niet zo'n belangrijk punt is.

Hm, de rest van de tut heb ik nog niet eens bekeken en zie wat een post laat duidelijk zijn dat ik het met je eens ben dat je de eerste bent (zou zijn?) die dit verhaal goed uitlegt in het Nederlands.

Bedankt en jij ook bedankt voor je commentaar.

ik mis vooral het hele mytheverhaal rond <div>, ik kom volgens mij ook helemaal niks tegen over dat element. Heel erg veel mensen hebben geen flauw idee wat eigenlijk het doel van dat element is, ik zou hem verwachten in je tekst structuur sectie. (je alinea voorbeeld met koppen enzo zou ik ook van div's voorzien)

Hmmm, blijkbaar is de uitleg over dit element verloren gegaan tijdens het verhuizen van sommige paragraven naar andere hoofdstukken. Dit element had ik volgens mij bewaard tot het laatste hoodfdstuk. Ik heb dit gedaan om zo de lezer te laten zien dat <div> niet als een soort magisch element gezien moet worden wat eigenlijk ipv elk ander element gebruikt kan worden waardoor de code verzuipt in het aantal <div>s.

Ik zal het element uit m'n backups vissen zodat ik die in het Tekst Structuur hoofdstuk kan zetten aangezien dit misschien toch wel de beste plek is voor dit element omdat ik nu andere plannen heb voor het laatste hoofdstuk. Bedankt.

Ook suggereer je dat id en class attributen zijn ten behouve van styling, dat is ook niet waar, deze attributen hebben helemaal niets te maken met styling, maar met het omschrijven van het doel van het element

Ik heb de info over het id attribuut (en de mogelijke functies ervan) wat verduidelijkt. Ik ben het echter niet helemaal eens wat je zegt over "het omschrijven van het doel van het element". Natuurlijk is het wel zo makkelijk als je een goede omschrijvende waarde gebruikt, maar ken jij een functie van het class element wat echt kijkt naar de waarde van het class attribuut en niet wordt gebruikt als een token (zoals CSS en JavaScript dat doen)?

iets over menu's navigatie (<map>) mis ik volgens mij ook nog

Ik heb deze expres weggelaten omdat er meer nadelen dan voordelen aan zitten. Informatie over het element (en <area>) komt natuurlijk wel het elementen overzicht dat nog gemaakt moet worden.

iets over xhtml, wat het is, waarom je er vrij weinig aan hebt en wat de verschillen zijn met html

Dat komt in het laatste hoofdstuk.

wat is trouwens je redenatie achter die

HTML:

<pre><code>...</code></pre>

constructies?

HTML en CSS code zijn computer code, dus zitten deze vanzelfsprekend in het <code> element. Deze <code> elementen zijn vervolgens weer in een <pre> gedaan omdat het wat makkelijker leest als de linebreaks en whitespace in tact blijven.

Is het niet een beetje overmoedig om op een website waar je HTML leert, van de gebruikers te vragen of ze hun commentaar van HTML willen voorzien?

Hoe wil je anders naar een andere pagina linken? Of hoe wil je anders de de whitespace en linebreaks in tact houden? Met die vage BB code die op al die fora gebruikt wordt zeker? Beetje nutteloos want dan moeten ze alsnog een andere markup taal leren.

Daarnaast is het ook misschien handig om met kleuren elementen/attributen/waardes/code uniform te markeren, zodat je als beginner sneller doorhebt wat welk type is en je sneller een verband legt. Nu is alles zwart en dat vind ik vrij onoverzichtelijk.

Goed idee.

ik mis eigenlijk op de hele site voorbeeldjes
bij een heel aantal dingen (elementen/properties etc.) leg je in 1 a 2 zinnen uit wat het doet, maar dit is (Vooral voor een leek) niet altijd te snappen.
voorbeeldjes doen wonderen

(denk bijv. aan pseudo elementen in css, ik denk dat de beschrijving die bij bijv. :before en :after)
verder zou competabiliteit wel handig zijn, aangezien IE niet alles ondersteund. dus hovers op alle dingen die niet anchors zijn enzo

Je mist voorbeelden? Sommige hoofdstukken bestaan voor het grootste gedeelte uit voorbeelden. Je hebt wel gelijk dat die selectors misschien een voorbeeld mogen gebruiken.

Als je trouwens kijkt naar een site als http://www.handleidinghtml.nl (ken je waarschijnlijk al), dan zie je dat die veel grondiger is. Sommige informatie is verouderd, maar je steekt er ondanks dat enorm veel van op door alle voorbeelden en uitgebreide behandeling van elk aspect. Bovendien zit de structuur van de site heel goed/handig in elkaar.

Ja, het bepalen van de structuur van de handleiding bleek toch moeilijker te zijn dan dat ik voorheen dacht, maar ik vind dat ik het nog niet zo slecht heb gedaan. Als je kijkt naar handleidinghtml.nl dan zie je ook dat ze het zich makkelijk hebben gemaakt door CSS maar gewoon in 1 hoofdstuk er doorheen te jassen. Modern Markup doet dat echter niet waardoor de handleiding een stuk ingewikkelder wordt. Maar als je nog ideëen hebt wil ik die natuurlijk graag horen.

Ik heb er zojuist snel overheen gekeken en ik denk dat er nog wel links en rechts één en ander bijgewerkt moet worden. O.a. de suggesties zoals hier boven. Maar ik denk dat je wel een heel mooi begin hebt gemaakt... Ik zou zeggen ga zo door.

Bedankt

Excuses voor de nogal lange post, maar het moet nou eenmaal. Tips en commentaar zijn natuurlijk nog steeds welkom!!

[Anoniem: 9542]

<pre> suggereert al code, die <code> is dus overbodug, wat je nu doet is hetzelfde als <blockquote><p><q>...</q></p></blockquote>, een beetje overdreven.

er zijn geen andere toepassingen die expliciet van class gebruik maken anders dan css inderdaad, maar dat houdt niet in dat het class attribuut voor css bedoelt is: http://www.rikkertkoppes.com/thoughts/class-and-style/

[Zoefff]

Als ik er zo even snel doorheen scan vind ik het er netjes uit zien. Heb (nog) niet de tijd gehad om de inhoud volledig te bekijken, maar wat me wel direct opvalt is dat je in de uitleg alle HTML-tags met hoofdletters schrijft. Zie bijvoorbeeld het eerste lijstje op http://modernmarkup.com/html-css/basis-structuur/ . Aangezien je volgens de XHTML (en volgens mij ook HTML 4.01) specificatie alle tags lowercase hoort te schrijven (zoals je in de codevoorbeelden wél doet) is dit misschien een beetje verwarrend. Ik zou in de uitleg alle tags ook gewoon lowercase doen. Het groene kleurtje voor de duidelijkheid kan natuurlijk wel

[crisp]

HTML is case-insensitive itt XHTML, dus uppercase in HTML is op zich prima (maar wel lelijk ).
De HTML4.01 specificatie zelf gebruikt nog overal uppercase voor tagnames en an sich vind ik dat in tekst niet storend - misschien zelfs wel duidelijker dan lowercase.

maar dit:

Elk HTML document heeft 5 basis onderdelen die altijd aanwezig moeten zijn:

1. een DOCTYPE met daarin de HTML versie;
2. een HTML element;
3. een HEAD element;
4. een TITLE element;
5. en een BODY element.

klopt natuurlijk niet, aangezien HTML, HEAD en BODY optional zijn in HTML

ook kent HTML natuurlijk meer onderdelen qua syntax dan alleen elementen, attributen en commentaar. Denk bijvoorbeeld aan marked sections en processing instructions. En aangezien HTML een SGML-application is met bepaalde features is dit volledig valid HTML:

HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
            "http://www.w3.org/TR/html4/strict.dtd">
<title/foo/
<p<strong/this is valid html!/</>

(maar geen browser die er iets mee kan )

[ Voor 86% gewijzigd door crisp op 21-04-2006 17:50 ]

[Anoniem: 9542]

de elementen moeten wel altijd aanwezig zijn, dus wat er staat is correct (de browser moet er dus elementen voor maken), de tags (van html, head en body) kunnen weggelaten worden.

markes sections en pi's zijn overigens ook elementen. Jouw voorbeeldje zal in een correct werkende browser ook een html, head, title en body element hebben

(ok, ik miereneuk een beetje, magoe)

[ Voor 5% gewijzigd door Anoniem: 9542 op 21-04-2006 17:54 ]

[crisp]

Anoniem: 9542 schreef op vrijdag 21 april 2006 @ 17:54:
de elementen moeten wel altijd aanwezig zijn, dus wat er staat is correct (de browser moet er dus elementen voor maken), de tags (van html, head en body) kunnen weggelaten worden.

Nee, er staat dat ze in het document aanwezig moeten zijn, hetgeen dus niet zo is; subtiel verschil

markes sections en pi's zijn overigens ook elementen.

en attributen zijn onderdeel van elementen en niet iets op zichzelf staands. Comments zijn ook elementen
Dus de HTML syntax bestaat uit elementen en meer niet \o/

Jouw voorbeeldje zal in een correct werkende browser ook een html, head, title en body element hebben

In de parse-tree wel ja, maar dat is geen document

(ok, ik miereneuk een beetje, magoe)

ik ook

[Jero]

<pre> suggereert al code, die <code> is dus overbodug, wat je nu doet is hetzelfde als <blockquote><p><q>...</q></p></blockquote>, een beetje overdreven.

The PRE element tells visual user agents that the enclosed text is "preformatted". When handling preformatted text, visual user agents.
http://www.w3.org/TR/html4/struct/text.html#h-9.3.4

Ik zie nergens iets staan dat PRE aangeeft dat de inhoud ook daadwerkelijk computer code is.

er zijn geen andere toepassingen die expliciet van class gebruik maken anders dan css inderdaad, maar dat houdt niet in dat het class attribuut voor css bedoelt is: http://www.rikkertkoppes.com/thoughts/class-and-style/

Ja, hierin heb je eigenlijk toch wel gelijk. Ik zal de tekst aanpassen.

HTML is case-insensitive itt XHTML, dus uppercase in HTML is op zich prima (maar wel lelijk ).
De HTML4.01 specificatie zelf gebruikt nog overal uppercase voor tagnames en an sich vind ik dat in tekst niet storend - misschien zelfs wel duidelijker dan lowercase.

Ik heb uppercase genomen omdat het duidelijker was de elementen van de tekst te onderscheiden, maar aangezien ik nu ook een kleur heb toegevoegd is dit misschien overbodig en kan het inderdaad misschien verwarring veroorzaken. Ik kijk het nog ff aan...

klopt natuurlijk niet, aangezien HTML, HEAD en BODY optional zijn in HTML

Strict gezien klopt dat ook niet aangezien de tags niet aanwezig horen te zijn, wel de elementen Maar nu probeer ik té slim te doen >_> Ik heb er echter wel over nagedacht om dat ook uit te leggen, maar dat zou volgens mij alleen maar teveel verwarring veroorzaken.

ook kent HTML natuurlijk meer onderdelen qua syntax dan alleen elementen, attributen en commentaar. Denk bijvoorbeeld aan marked sections en processing instructions. En aangezien HTML een SGML-application is met bepaalde features is dit volledig valid HTML:

Wederom zou dit teveel verwarring veroorzaken en is het in dit geval geheel nutteloos omdat HTML, zoals je al zei, helemaal niet als SGML wordt behandeld. Als de handleiding en de gehele HTML en CSS referenties klaar zijn (maar dan denk ik al erg ver vooruit), dan wil ik misschien nog aparte artikelen toevoegen die in gaan op specifiekere onderwerpen zoals de relatie tussen HTML en SGML.

[JHS]

Met betrekking tot pre versus code: Ik zou toch vermijden twee elementen voor hetzelfde te gebruiken, aangezien het mij enigzins loos overkomt. Je kan dan denk ik beter, aangezien het code element relevanter is, met behulp van white-space: pre; de preformatting overbrengen .

[Anoniem: 9542]

wordt een leuk discussiepunt eigenlijk, ik vind op zich dat jvdm wel een punt heeft, las net ook de specs idd en hoewel we er allemaal redelijk vanuit gaan dat pre code is, staat dat helemaal nergens. Als voorbeelden staan ook enkel gedichten vermeld.

sterker nog, WA 1.0 zegt precies wat jvdm zegt: http://www.whatwg.org/specs/web-apps/current-work/#the-pre

ik denk dat ik er, bij nader inzien, wel behoorlijk in mee kan gaan, nog even goed rondzoeken naar alle argumenten, want tot nu toe had ik er eigenlijk geen gegronde

[CH4OS]

Heb net even op de site gekeken, ziet er erg goed uit moet ik zeggen alleen mis ik eigenlijk wel een stukje over semantiek; een tutorial of korte uitleg hierover zou dus niet verkeerd zijn.

Mocht je een artikel willen schrijven:
[google=HTML semantiek]
[google=HTML semantics]
Artikel over semantiek van Michiel van Parse

Als ik er de tijd voor had, had ik je graag geholpen aan een artikel hierover...

[ Voor 11% gewijzigd door CH4OS op 23-04-2006 21:04 ]

[CH4OS]

Heb trouwens een spelfoutje gevonden:

quote: http://modernmarkup.com/html-css/introductie/

Om maar gelijk ter zake te komen, HTML (HyperText Markup Language) is een taal om betekenis te geven aan de inhoud van een document. HTML is in 1991 ontwikkeld door Tim Berners-Lee.

Het vetgedrukte woordje mist...

[Jero]

Ik heb de laatste dagen weer wat gesleuteld aan de site. Zo heb ik het laatste hoofdstuk hernoemd naar "De evaluatie" en een stukje over semantiek toegevoegd (bedankt GJ-tje). Ook heb ik het hoofdstuk "Eerste website" aangepast door een paragraaf over het DIV element toe te voegen (bedankt mophor).

De grootste toevoeging is waarschijnlijk de stap-voor-stap uitleg hoe de layout van de site is gemaakt. Er zullen echter nog wel een aantal fouten in zitten want ik heb het nog niet helemaal achter elkaar doorgelezen.

Anyway, bij deze nog ff de status-update voor het geval er nog iemand geïnsteresseerd in was. Wat nu nog resteert is het maken van de referentie.

[ Voor 4% gewijzigd door Jero op 16-05-2006 21:10 ]

[Anoniem: 27577]

Waarom heb je gekozen voor <dl>, <dd> en <dt> voor je menu? Het is geen definition list imo, maar een lijst met links, waarvoor <ul> gebruikt zou moeten worden.

[Blaise]

Ik kan in de gauwigheid niks vinden over entities (die &blaat; dingen). Moet je daar niets iets over vertellen?

[Jero]

Anoniem: 27577 schreef op woensdag 17 mei 2006 @ 01:18:
Waarom heb je gekozen voor <dl>, <dd> en <dt> voor je menu? Het is geen definition list imo, maar een lijst met links, waarvoor <ul> gebruikt zou moeten worden.

I citeer de HTML 4.01 specificatie:

Definition lists, created using the DL element, generally consist of a series of term/definition pairs (although definition lists may have other applications). Thus, when advertising a product, one might use a definition list: ...

Blaise schreef op woensdag 17 mei 2006 @ 01:33:
Ik kan in de gauwigheid niks vinden over entities (die &blaat; dingen). Moet je daar niets iets over vertellen?

Wow, dat klopt. UTF-8 heeft me blijkbaar teveel verwend waardoor ik entiteiten ben vergeten. Thanks.

[ Voor 3% gewijzigd door Jero op 17-05-2006 07:41 ]

[crisp]

Jero schreef op woensdag 17 mei 2006 @ 07:41:
[...]
I citeer de HTML 4.01 specificatie:

Tsja, een hamer heeft ook andere toepassingen dan het inrammen van een spijker, maar dat wil niet zeggen dat een ander stuk gereedschap niet beter geschikt zou zijn

[Jero]

Klopt, voor een simpel menu hoort het UL element gebruikt te worden. Dat heb ik ook gedaan in het hoofdmenu bovenaan op de pagina. Het menu aan de zijkant is echter anders. Zoals je ziet zijn de links in de DDs subsecties van de links in de DTs. De DTs hebben dus ook de functie van "kopjes" en ouders van de links in de DDs. Om deze duidelijke relatie ook in de markup aanwezig te maken heb ik dus voor een DL gekozen ipv een UL waar deze relatie niet naar voren kan komen. Daar lijkt het namelijk of alle links op hetzelfde niveau zitten, maar de links in de DTs zijn zonder twijfel wel belangrijker.

[Anoniem: 27577]

Jero schreef op woensdag 17 mei 2006 @ 17:11:
Om deze duidelijke relatie ook in de markup aanwezig te maken heb ik dus voor een DL gekozen ipv een UL waar deze relatie niet naar voren kan komen. Daar lijkt het namelijk of alle links op hetzelfde niveau zitten, maar de links in de DTs zijn zonder twijfel wel belangrijker.

Wat dacht je van:

code:

<ul>
  <li>bla 1</li>
  <li>bla 2
    <ul>
      <li>sub 1</li>
    </ul>
  </li>
</ul>

En ja, dit is nog eens prima te stylen ook.

[ Voor 13% gewijzigd door Anoniem: 27577 op 17-05-2006 19:36 ]

[Dennis]

Anoniem: 27577 schreef op woensdag 17 mei 2006 @ 19:36:
En ja, dit is nog eens prima te stylen ook.

Ook de suckerfish dropdown menu's (puur html/css in compliant browsers) werken via deze constructie.

[Jero]

Anoniem: 27577 schreef op woensdag 17 mei 2006 @ 19:36:
En ja, dit is nog eens prima te stylen ook.

En toch heb ik voor het DL element gekozen omdat die IMO toch beter de relatie tussen de DTs en DDs laat zien. De DTs hoeven overigens niet altijd termen te bevatten die worden uitgelegd in de DDs. Kijk maar naar het voorbeeld in de HTML specificatie (helemaal onderaan paragraaf 10.1) waar je ziet dat het in dat voorbeeld ook niet het geval is.

Overigens ben ik benieuwd of iemand nog gekeken heeft naar mijn wijzigingen?

[Blaise]

Overigens ben ik benieuwd of iemand nog gekeken heeft naar mijn wijzigingen?

Ik vind dat je al vrij ingewikkeld begint. Ok, je hebt nog geen CSS gebruikt, maar de HTML is wel al vrij ingewikkeld.

Van allerlei elementen (doctype, waarom id="copyright", waarom een definition list) ga je al uit dat de bezoeker het snapt of heeft onthouden. Ik zou meer uitleggen en onderbouwen waarom je dingen doet zoals ze je doet, en eventueel verwijzen naar een uitleg elders op de website als het al eens is uitgelegd. Nu vind ik de leercurve nog veel te hoog.

[Jero]

Ok, dat is inderdaad wel een goed idee. Bedankt, Blaise.

[Jero]

Ik heb weer even wat gesleuteld aan de site. Zo heb ik een kleine toelichting gegeven over waarom ik de HTML elementen heb gekozen waarvoor ik heb gekozen in de layout van de site.

Ook heb ik een paragraaf toegevoegd over karakter referenties. Verder heb ik nog een groot aantal kleine wijzigen gemaakt.

Op dit moment ben ik bezig met de referentie van alle HTML elementen (ja, er moet nog veel aan gewerkt worden). Dus als iemand zin heeft om me daarin te helpen is hij/zij natuurlijk van harte welkom

Tips/kritiek is natuurlijk ook nog van harte welkom.

[crisp]

Dat stuk over karakterreferenties vind ik maar vaag. In mijn ogen zijn dit de twee redenen om karakterreferrenties te gebruiken:
1) wanneer het karakter niet voorkomt in de karakterset waarmee je je document verstuurd (it's all in the headers)
2) wanneer het een karakter betreft met speciale betekenis in de HTML syntax op plaatsen waar het niet ondubbelzinnig kan worden opgevat

verder noem je niet de mogelijkheid om numerieke entities te gebruiken: ' of &#x27; en het feit dat de puntkomma optioneel is

[crisp]

Note dat dit valid HTML is:

HTML:

<p>3 < 5 & 5 > 3</p>

[Jero]

In mijn ogen zijn dit de twee redenen om karakterreferrenties te gebruiken:
1) wanneer het karakter niet voorkomt in de karakterset waarmee je je document verstuurd (it's all in the headers)
2) wanneer het een karakter betreft met speciale betekenis in de HTML syntax op plaatsen waar het niet ondubbelzinnig kan worden opgevat

Hier ben ik het natuurlijk met je eens, maar ik probeer de lezer gewoon voor UTF-8 als karakter encodering te kiezen en die heeft maakt karakter referenties nogal nutteloos. Misschien moet ik dat maar wat duidelijker maken.

verder noem je niet de mogelijkheid om numerieke entities te gebruiken: &#039; of &#x27;...

Ik citeer de eerste zin onder het voorbeeld (code block met blauwe achtergrond):

Zoals je ziet begint een karakter referentie met een & en eindigt het met een ;. Daar tussenin staat een naam of een getal dat een bepaald karakter voorstelt.

Overigens is dat ook op de lijst met alle karakter referenties te zien.

en het feit dat de puntkomma optioneel is

Klopt, maar dat is vragen om verwarring. De HTML 4.01 specificatie raadt dan ook aan om altijd ; te gebruiken (laatste Note van de paragraaf).

Note dat dit valid HTML is: ...

De HTML 4.01 spec zegt toch echt iets anders:

Authors wishing to put the "<" character in text should use "&lt;" (ASCII decimal 60) to avoid possible confusion with the beginning of a tag (start tag open delimiter). Similarly, authors should use "&gt;" (ASCII decimal 62) in text instead of ">" to avoid problems with older user agents that incorrectly perceive this as the end of a tag (tag close delimiter) when it appears in quoted attribute values.

Authors should use "&amp;" (ASCII decimal 38) instead of "&" to avoid confusion with the beginning of a character reference (entity reference open delimiter). Authors should also use "&amp;" in attribute values since character references are allowed within CDATA attribute values.

- http://www.w3.org/TR/html4/charset.html#h-5.3.2

Ik zie nergens iets staan dat het alleen voor situaties geldt waar het voor verwarring kan veroorzaken omdat de UA zou kunnen denken dat het een tag is. Volgens deze paragraaf is het namelijk altijd een probleem als je <, > en & niet escapet omdat oudere UA's deze altijd verkeerd kunnen opvatten (realiteit is gelukkig anders, maar het blijft invalid).

[ Voor 4% gewijzigd door Jero op 24-05-2006 20:31 ]

[crisp]

Jero schreef op woensdag 24 mei 2006 @ 20:31:
[...]
Ik citeer de eerste zin onder het voorbeeld (code block met blauwe achtergrond):

Maar je legt daar niet uit hoe zo'n numerieke reference er dan uitziet

Klopt, maar dat is vragen om verwarring. De HTML 4.01 specificatie raadt dan ook aan om altijd ; te gebruiken (laatste Note van de paragraaf).

Dat is helemaal waar, maar ik prefereer altijd volledigheid zelfs als het gaat om dingen die je eigenlijk niet zou moeten doen (dat moet dan uiteraard ook vermeld worden)

De HTML 4.01 spec zegt toch echt iets anders:
[...]

Lees dat nog eens; er staat daar nergens dat het in alle gevallen tot invalid syntax leidt. Die paragraaf zegt enkel dat je het beste voor deze karakters altijd een reference kan gebruiken omdat het mogelijk voor problemen kan zorgen - hetzij door brakke parsers hetzij omdat het tot ambiguiteiten kan leiden ('should' is geen 'must').
mijn voorgaande voorbeeld valideerd wel degelijk

[ Voor 7% gewijzigd door crisp op 24-05-2006 21:44 ]

[crisp]

Over commentaar in HTML:

HTML:

dit is content
<!-- Dit is commentaar -- Dit is geen commentaar --> Dit is weer wel commentaar -->
en dit is weer content

[Anoniem: 53174]

Het lijkt mij een goed idee om de handleiding in miereneukmodus te kunnen zien en dus alles over punt-comma's die mogen missen en het weglaten van de html-tag. Maar misschien is het handiger om het standaard onzichtbaar te hebben voor mensen die net beginnen met html.

[Jero]

Maar je legt daar niet uit hoe zo'n numerieke reference er dan uitziet

Ja, daar heb je eigenlijk toch wel gelijk in.

Dat is helemaal waar, maar ik prefereer altijd volledigheid zelfs als het gaat om dingen die je eigenlijk niet zou moeten doen (dat moet dan uiteraard ook vermeld worden)

Daar ben ik het mee eens. Het grote probleem is dan echter dat de handleiding veel te lang wordt en voor de meeste zullen die details niet zo heel erg veel uitmaken.

Het idee wat ik in m'n hoofd heb (misschien heb ik dat al een keer gepost), is om als de handleiding en referentie helemaal af zijn, om dan misschien een aantal "in-depth" artikelen te schrijven over bijvoorbeeld de rol van SGML, karakter encodering, enz zodat Modern Markup op een overzichtelijke toch HTML in zijn compleetheid omschrijft.

Maar de handleiding en referentie gaan dus op dit moment nog even voor. De referentie ben ik nog mee bezig en zal ik deze het begin van online zetten. De handleiding is natuurlijk nog steeds te bekijken en in dit topic te becommentarizeren. Dus als je denkt "ik mis nog iets!!" of "wtf, dit is niet duidelijk!!", rant erop los

Zo vind ik zelf nog dat het fenomeen "positioneren" wel wat aandacht verdient. Ik merk namelijk op verschillende fora dat het grootste aantal mensen positioneren verkiezen boven floaten (dat veel beter werkt als je het eenmaal door hebt). Daarvoor moet ik nog even kijken wat de beste plek is in de handleiding om daarover iets te schrijven.

Lees dat nog eens; er staat daar nergens dat het in alle gevallen tot invalid syntax leidt. Die paragraaf zegt enkel dat je het beste voor deze karakters altijd een reference kan gebruiken omdat het mogelijk voor problemen kan zorgen - hetzij door brakke parsers hetzij omdat het tot ambiguiteiten kan leiden ('should' is geen 'must').
[small]mijn voorgaande voorbeeld valideerd wel degelijk

Ok ok, maak je geen zorgen, ik zal er heus voor zorgen dat het ooit in zo'n "in-depth" artikel duidelijk wordt gemaakt wat de "krachten" van het dode SGML zijn Als je zelf iets zou willen schrijven mag dat natuurlijk ook

[ Voor 4% gewijzigd door Jero op 31-05-2006 15:00 ]

[crisp]

Daar ben ik het mee eens. Het grote probleem is dan echter dat de handleiding veel te lang wordt en voor de meeste zullen die details niet zo heel erg veel uitmaken.

Ja, maar basis-handleidingen HTML zijn overal wel te vinden. Handleidingen die trachten formeel compleet en correct te zijn en dat ook nog eens duidelijk uitleggen des te minder (ik ken ze niet)

[Zoefff]

Een paar spelfoutjes die me net opvielen in het deel over formulieren, het zijn "symptomen" en "niezen" i.p.v. "symtomen" en "niesen"

[Jero]

crisp, want vind je dan van die zogenaamde "in-depth" artikelen?

En bedankt Zoefff. Ik heb ze gefixt.

[crisp]

Jero schreef op woensdag 31 mei 2006 @ 17:10:
crisp, want vind je dan van die zogenaamde "in-depth" artikelen?

Eerlijk gezegd enkel de officiele specificaties

[Jero]

Uhm, I don't get it >_>

[BalusC]

http://modernmarkup.com/html-css/html-syntax/

Hieronder staat een lijst met de 5 karakters die problemen veroorzaken ..

Ik tel er maar 4?

http://modernmarkup.com/v...karakter-referenties.html
Ik vind bij de gebruikte font de & vrij onduidelijk eruitzien. Ik stel voor om de twee kolommen naam/getal gewoon monospaced te weergeven, zoals je in de eerstgenoemde pagina hebt gedaan

Zomaar 2 dingen die mij opvielen, heb verder niet echt naar gekeken.

[Anoniem: 27577]

Niet inhoudelijk: qua toegankelijkheid is het misschien verstandiger om je logo in de CSS te zetten en binnen je h1 de titel van je site (modern markup) als tekst?

[Jero]

Typfout is gewijzigd en ik heb de lijst in monospace gezet. Bedankt.

[Jero]

Anoniem: 27577 schreef op vrijdag 02 juni 2006 @ 11:30:
Niet inhoudelijk: qua toegankelijkheid is het misschien verstandiger om je logo in de CSS te zetten en binnen je h1 de titel van je site (modern markup) als tekst?

Het logo van een website vind ik persoonlijk altijd wel belangrijk, zeker als het voor een bedrijf is (niet dat Modern Markup een bedrijf is ) omdat het deel uitmaakt van de marketing en het gezicht van het bedrijf (of enkel de website in dit geval). Daarom vind ik het logo net iets te belangrijk om in de CSS te doen. Ik moet alleen nog wel eens een goed logo verzinnen...

[Anoniem: 27577]

Jero schreef op vrijdag 02 juni 2006 @ 11:34:
[...]


Het logo van een website vind ik persoonlijk altijd wel belangrijk, zeker als het voor een bedrijf is (niet dat Modern Markup een bedrijf is ) omdat het deel uitmaakt van de marketing en het gezicht van het bedrijf (of enkel de website in dit geval). Daarom vind ik het logo net iets te belangrijk om in de CSS te doen. Ik moet alleen nog wel eens een goed logo verzinnen...

Tja, het ligt er natuurlijk aan hoe puristisch je het bekijkt Ik zet altijd afbeeldingen in de CSS die geen illustratieve waarde of direct verband met de content van een pagina hebben (en hier valt het logo wat mij betreft ook onder). Visueel verandert er niets natuurlijk, dus als 'gezicht van de website' blijft alles bij het oude. Alleen de markup wordt anders.

[crisp]

Jero schreef op donderdag 01 juni 2006 @ 17:17:
Uhm, I don't get it >_>

Ik las 'want' maar als 'waar' en zoals ik al zei: ik ken geen echte in-depth artikelen die echt ingaan op HTML/SGML features en de verschillen tussen specificaties en implementaties. Ik heb mijn kennis voornamelijk uit de specificaties zelf en mijn ervaringen met implementaties daarvan. Verder veel uit discussies en blogs van mensen die ook verstand van zaken hebben zoals bijvoorbeeld Anne van Kesteren (dat zijn dus meestal mensen die zelf bij browservendors werken en zich dagelijks met deze materie bezighouden)

[Jero]

crisp schreef op vrijdag 02 juni 2006 @ 11:46:
[...]

Ik las 'want' maar als 'waar' en zoals ik al zei: ik ken geen echte in-depth artikelen die echt ingaan op HTML/SGML features en de verschillen tussen specificaties en implementaties. Ik heb mijn kennis voornamelijk uit de specificaties zelf en mijn ervaringen met implementaties daarvan. Verder veel uit discussies en blogs van mensen die ook verstand van zaken hebben zoals bijvoorbeeld Anne van Kesteren (dat zijn dus meestal mensen die zelf bij browservendors werken en zich dagelijks met deze materie bezighouden)

Ik ken die in-depth artikelen ook niet, dus leek het me wel een goed idee om later dat soort artikelen te maken waarin alle specifieke onderwerpen worden besproken.

Anyway, ik heb wat klachten gekregen over het hoofdstuk HTML Syntax, dus heb ik het anders aangepakt. Een verbetering?

[-Lars-]

Ik heb er slechts even doorgebladerd, dus inhoudelijk heb ik niets aan te merken. Qua stijl echter wel. Pas op voor de Engelse ziekte. Nu zijn developers natuurlijk gewend veel in Engels te lezen, maar probeer Nederlands Nederlands te laten

"HTML Syntax" wordt "HTML-syntaxis"
"Basis structuur" wordt "Basisstructuur"
"Karakter referenties" wordt "Karakterreferenties"
et cetera

[funkwurm]

Ik vind het zeker een verbetering, al zou ik ook meteen het <p>-element introduceren voor de alinea's onder de <hx>'jes.

Ik denk dat het heel goed is dat je hier aangeeft waarom die tags er zijn, een kleine geschiedenis eigenlijk. Er was ooit een brakke internet-verbinding, en toen heeft men ervoor gekozen om een taaltje te bedenken waarmee UserAgents tekst-opmaak client-side kunnen renderen en het allemaal minder bandbreedte kost.

Vandaag de dag is de bandbreedte niet meer het grootste probleem, maar de client-side rendering van elementen geeft de UserAgent wel de mogelijkheid deze rendering aan te passen aan zijn eigen wensen (of eigenlijk die van de gebruiker). Hiermee wordt een HTML-pagina geschikt voor bijvoorbeeld blinde of slechtziende mensen, of mensen met een computer die geen GUI aankan (er zijn mensen die nog steeds met 5.25" floppy's werken). Op die manier is internet dus een theoretisch oneindig grote informatiebron die wereld wijd door iedereen (met of zonder handicap) gebruikt kan worden.

Als je je dat vanaf het begin realizeert ga je volgens mij heel anders naar je HTML-pagina's kijken.

[ Voor 3% gewijzigd door funkwurm op 09-06-2006 22:28 ]

[Blaise]

Op deze pagina klopt de beschrijving van <br> niet: http://modernmarkup.com/html-css/referentie/elementen/ . De <br> slaat geen regel over, maar begint op de volgende. Ook <style> is raar geformuleerd met het werkwoord "laden". Zo zitten er nog veel meer foutjes en slordigheden in die pagina.

Ik mis ook een vermelding van (o.a.) niet-W3C en deprecated elementen op die pagina, zoals <marquee>, <embed>, <b>, <small>, etc.

Ik weet alleen niet in hoeverre je je alleen op modern markup wil richten en de rest buiten beschouwing wil laten. Dan wordt het de kunst van het weglaten. Ga je frames bijvoorbeeld wel of niet behandelen? Want die kunnen erg handig zijn bij sommige types websites. Mijn mening is dat je de bezoeker volledig moet informeren, ook al informeer je ze over dat er een bepaald element bestaat, wat die doet en waarom je die niet zou moeten gebruiken. Misschien niet al die informatie tegelijk, maar in verwijzingen naar aparte pagina's/secties die een beginner kan overslaan.

[Jero]

-Larz- schreef op vrijdag 09 juni 2006 @ 21:22:
Ik heb er slechts even doorgebladerd, dus inhoudelijk heb ik niets aan te merken. Qua stijl echter wel. Pas op voor de Engelse ziekte. Nu zijn developers natuurlijk gewend veel in Engels te lezen, maar probeer Nederlands Nederlands te laten

Bedankt. M'n Nederlands is niet altijd op hoogstaand niveau, dus dit soort verbeteringen zijn natuurlijk ook altijd welkom zodat ook het taalgebruik naar behoren wordt. Voorheen was ik altijd tamelijk voorzichtig met het vertalen van die algemeen geaccepteerde Engelse termen zoals syntax. Je ziet ze hier op Tweakers immers ook voorbij komen ipv de Nederlandse vertaling ervan waardoor ik er vanuit ging dat de Engelse variant misschien beter gebruikt kon worden. Toch lijkt het me inderdaad beter om de Nederlandse termen te gebruiken.

funkwurm schreef op vrijdag 09 juni 2006 @ 22:27:
Ik vind het zeker een verbetering, al zou ik ook meteen het <p>-element introduceren voor de alinea's onder de <hx>'jes.

...

Vandaag de dag is de bandbreedte niet meer het grootste probleem, maar de client-side rendering van elementen geeft de UserAgent wel de mogelijkheid deze rendering aan te passen aan zijn eigen wensen (of eigenlijk die van de gebruiker). Hiermee wordt een HTML-pagina geschikt voor bijvoorbeeld blinde of slechtziende mensen, of mensen met een computer die geen GUI aankan (er zijn mensen die nog steeds met 5.25" floppy's werken). Op die manier is internet dus een theoretisch oneindig grote informatiebron die wereld wijd door iedereen (met of zonder handicap) gebruikt kan worden.

Als je je dat vanaf het begin realizeert ga je volgens mij heel anders naar je HTML-pagina's kijken.

Het P element zal ik er in verwerken. Ook zal ik er nog iets van de voordelen van markup in verwerken. Thanks.

Blaise schreef op zaterdag 10 juni 2006 @ 13:20:
Op deze pagina klopt de beschrijving van <br> niet: http://modernmarkup.com/html-css/referentie/elementen/ . De <br> slaat geen regel over, maar begint op de volgende. Ook <style> is raar geformuleerd met het werkwoord "laden". Zo zitten er nog veel meer foutjes en slordigheden in die pagina.

Ik mis ook een vermelding van (o.a.) niet-W3C en deprecated elementen op die pagina, zoals <marquee>, <embed>, <b>, <small>, etc.

De omschrijvingen van alle elementen heb ik inderdaad een beetje slordig en gehaast gedaan, dus daar zal ik nog de nodige verbeteringen aan brengen. De deprecated elementen die jij noemde zijn per ongeluk verloren gegaan dus die zal ik er weer aan toe moeten voegen.

Blaise schreef op zaterdag 10 juni 2006 @ 13:20:
Ik weet alleen niet in hoeverre je je alleen op modern markup wil richten en de rest buiten beschouwing wil laten. Dan wordt het de kunst van het weglaten. Ga je frames bijvoorbeeld wel of niet behandelen? Want die kunnen erg handig zijn bij sommige types websites. Mijn mening is dat je de bezoeker volledig moet informeren, ook al informeer je ze over dat er een bepaald element bestaat, wat die doet en waarom je die niet zou moeten gebruiken. Misschien niet al die informatie tegelijk, maar in verwijzingen naar aparte pagina's/secties die een beginner kan overslaan.

Zoals ik al eerder in dit topic heb gezegd wil ik in de toekomst ervoor zorgen dat alle informatie omtrend HTML en CSS te vinden is op Modern Markup. Dat is echter een ding voor de toekomst. Nu probeer ik me te richten op de handleiding (en natuurlijk de referentie) die, zoals je zelf al opmerkte, niet HTML in de volledigheid bespreekt. Later wil ik daar echter nog een aantal losstaande "in-depth" artikelen (moet nog wel een betere naam verzinnen ) schrijven over bijv. SGML, karakter encodering en het gebruik van frames.

[plakbandrol]

Vind dit een beetje vreemd

Voordat we beginnen hebben we eerst een aantal dingen nodig:

minimaal de laatste versies van de drie meest gebruikte browsers om je werk in te testen;

minimaal de laatste is een beetje dubbel, daarnaast lijkt me het beter om de meestgebruikte versies te gebruiken ipv de laatste (ik zou bijvoorbeeld niet die IE7 beta gaan proberen)

[Jero]

"minimaal de laatste" is niet dubbel, het is gewoon onmogelijk Eigenlijk heb ik de zin verkeerd geconstructueerd. Het woord "minimaal" had op het getal "drie" moeten slaan.

Bedankt voor het melden van de fout.

[Toolskyn]

Mag ik nog even opmerken: ik zou graag zien dat het logo klikbaar wordt om weer terug te gaan naar de hoofdpagina. Ik zoek (en met mij vele anderen heb ik het gevoel) altijd naar een Home knop of een logo om op te klikken om weer naar de hoofdpagina te gaan. Nou staat de hoofdpagina wel onder 'Nieuws', maar op de een of andere manier werkt dat niet echt fijn. (Het is verder niet echt belangrijk hoor )

[ Voor 8% gewijzigd door Toolskyn op 10-06-2006 22:18 ]

[BalusC]

Het Notepad++ linkje onderaan in http://www.modernmarkup.com/html-css/voorbereiding/ :

HTML:

<a href="http://notepad-plus.sourceforge.net/">Notepad </a>

Moet dat niet "Notepad++" zijn? Zo nee, dan moet die spatie in ieder geval weg

[Zoefff]

Wat betreft de content, ik ben het niet helemaal eens met een stukje op http://www.modernmarkup.com/html-css/je-eerste-website/. Of tenminste, ik zou het zelf anders uitleggen.

Je geeft een voorbeeld van het gebruik van #id en .class:

quote: http://www.modernmarkup.c...-eerste-website/#id-class

Om terug te komen op de pagina die we aan het maken zijn. We willen dus de P met daarin de bron opmaken zonder de andere twee Ps te beïnvloeden. We geven dus die P een id attribuut zodat we die apart kunnen opmaken. We hadden ook voor class kunnen kiezen, maar er is maar één P die we zo willen opmaken, dus is het een beetje nutteloos om class te gebruiken. Dat ziet er dan zo uit:

HTML:

<!-- De rest van de pagina -->

<p id="bron">Bron: <a href="http://nl.wikipedia.org/wiki/Tim_Berners-Lee">Wikipedia</a>.</p>
</body>
</html>

Ik begrijp dat je een ID neemt omdat dit maar 1 keer voorkomt op die pagina, maar tóch vind ik het een verkeerde keuze. Iets als een bron bij een tekst is nou juist iets wat vaker voor kan komen op een pagina, en over het algemeen altijd hetzelfde gestijld wordt. Ik zou daarom ook juist een class gebruiken, en geen ID.

Stel dat je in de toekomst nog een tweede artikel met bron aan dezelfde pagina toevoegt, dan moet je dus het ID van de vorige bron in een class veranderen, en ook de opmaak in de stylesheet veranderen. Allemaal extra werk toch?

[BalusC]

Inderdaad, de ID's zou ik alleen toewijzen aan unieke indeling/layout/input-elementen (linkerkolom, header, footer, main-content, wrapper-div's, datatabellen, specifieke invoervelden, etc) en niet aan de textuele content.

[ Voor 16% gewijzigd door BalusC op 21-06-2006 08:46 ]

[Anoniem: 9542]

bronvermelding is overigens typisch <address> (en de text in blockquote)

verder hebben class en id natuurlijk niks met css te maken, in eerste instantie. Je geeft een element een class omdat ie anders is (in functie) dan de rest en daardoor heeft ie vaak een andere opmaak (waar je dat class attribuut dan handig voor kan gebruiken), je geeft geen class attribuut mee omdat je iets in een bepaalde opmaak wil hebben. (dit is een ontzettend hardnekkig misverstand)

geldt ook een beetje voor je verhaal over div: p's (en andere "hoofdstuk" elementen) zou je altijd moeten groeperen met een div, niet toevallig omdat je ze wil floaten (wat hier denk ik een nietszeggende term is, aangezien mensen er op dit punt nog niet bekend mee zijn). Div is zeer zeker niet een nietszeggend element.

http://www.rikkertkoppes.com/thoughts/class-and-style
http://www.rikkertkoppes.com/thoughts/about-div

het uitleggen van float doe je overigens het beste met termen als text-wrap denk ik, da's ook precies waar het voor is. Daarom zitten mensen ook altijd te fucken met clear, aangezien het in eerste instantie niet bedoeld is om blokken naast elkaar te zetten (daarvoor zou display: inline-block veel geschikter zijn)


over <em> en <strong>. Ik heb ergens een stuk gelezen over global en local emphasis. Je kan hierover twisten, maar ik vind het wel een aardig onderscheid:
<em> gebruik je als je locaal in een zin nadruk wil leggen op een bepaald woord, dit zijn dan voornamelijk bijwoorden (bv niet, wel, deze etc). Aangezien ze schuin gedrukt zijn vallen ze ook pas op op het moment dat je eroverheen leest.
<strong> voor globale nadruk, woorden die opvallen op het moment dat je een artikel voor je neus krijgt. Dit zijn dan vaak -hoe noem je dat- woorden, in roddelbladen zie je het nogal: namen en woorden als "miljonair" etc. Woorden die dus belangrijk zijn voor heel de tekst.

bij citaten: blockquote is net zoiets als div (en map en fieldset), het is een paragraaf/hoofdstuk van iemand ander, terwijl het bij div een stuk van jezelf is

bij formulieren:
gebruik <p> om input en label te groeperen, niet <br> om ze te scheiden

[ Voor 99% gewijzigd door Anoniem: 9542 op 21-06-2006 10:38 ]

[Vinzzz243]

Hoe zou je dit volgende dan in de praktijk qua naamgeving doen?

een pagina die in het midden van de browser zweeft met 3 kolommen.

code:

<div id="container">

  <div id="container2">

    <div id="leftcolumn"></div>
    <div id="centercolumn"></div>
    <div id="rightcolumn"></div>

  </div>

</div>

Stel je hebt voor je layout minimaal deze div's nodig (fout beredeneert in dit topic i know )
Container2 zegt natuurlijk niet veel...

[Anoniem: 9542]

in dit geval boeit het geen zak, omdat die 2 omringende divs geen zak boeien voor je content, ze zitten er puur vanwege de layout. Niks mis mee verder, want dat is ook een toepassing van div (ik geef ze vaak een class="structural" mee om aan te geven dat ze voor structuur zijn en niet voor betekenis)

noem het container wrapper, handle, holder, box, wat dan ook.

(overigens vermoed ik dat je er al minstens 1 kan wegstrepen, je hebt je html en body elementen ook nog he)

[Blaise]

Je zou het innerwrapper / outerwrapper kunnen noemen. En leftcolumn moet je geen id geven, maar een class; wie weet maak je in je centercolumn op een bepaalde pagina opnieuw meerdere kolommen, dan heb je wéér een leftcolumn.

Wrappers een naam een naam geven op basis van functie is trouwens sowieso gevaarlijk. Straks kom je erachter dat je je body ook 750px breed kan maken en kan centreren en je hebt daarom geen outerwrapper meer nodig. Dan staat innerwrapper wel erg raar zonder een outer. Om maar iets te noemen.

...

Maar eerlijk gezegd vind ik dat allemaal enorm gemierenneuk. Zolang het enig doel heeft is het tot op zekere hoogte zinvol, maar elke idioot weet met 1 blik op de code wat de functie is van container en container2. Semantische namen bij CSS zijn natuurlijk goed en helpen voor het overzicht, maar je kan ook overdrijven.

Bovendien moet je bij een fikse update van je website altijd wel markup veranderen, zoals een extra spannetje hier, een divje dat weg kan daar, etc. Dan maken een paar aanpassingen in de class- en idnamen ook niet zoveel uit.


// en tijdens het typen zie ik al dat mophor me voor is.

[Zoefff]

Vinzzz schreef op woensdag 21 juni 2006 @ 11:17:
Hoe zou je dit volgende dan in de praktijk qua naamgeving doen?

een pagina die in het midden van de browser zweeft met 3 kolommen.

code:

<div id="container">

  <div id="container2">

    <div id="leftcolumn"></div>
    <div id="centercolumn"></div>
    <div id="rightcolumn"></div>

  </div>

</div>

Stel je hebt voor je layout minimaal deze div's nodig (fout beredeneert in dit topic i know )
Container2 zegt natuurlijk niet veel...

toon volledige bericht

Sowieso snap ik niet waar je container 1 en container 2 voor nodig hebt. Je kan het body element natuurlijk ook nog stylen, en met "margin:0px auto 0px auto; width:400px;" heb je dus al een pagina die in het midden zweeft. En met een beetje mazzel kan je dan voor 1 van de kolommen gewoon een ul gebruiken omdat je er bijvoorbeeld alleen navigatie in zet.

Ik zou in ieder geval geen benamingen gebruiken als left-, right- en centercolumn, maar meer iets als navigation, content, etc. Mierenneukerij misschien, maar het is wel duidelijker als je later de boel wilt omdraaien ofzo. Een kolom met id "menu" blijft nog steeds een menu, maar een kolom met id "rightcolumn" die nu ineens onderaan of links staat, is natuurlijk een beetje raar

[Jero]

BalusC schreef op woensdag 21 juni 2006 @ 08:30:
Moet dat niet "Notepad++" zijn? Zo nee, dan moet die spatie in ieder geval weg

Het moet inderdaad Notepad++ zijn, maar mijn JavaScript CMS haalt volgens alle + karakters weg. Daar moet ik nog wat aan doen.

Zoefff schreef op woensdag 21 juni 2006 @ 08:41:
Ik begrijp dat je een ID neemt omdat dit maar 1 keer voorkomt op die pagina, maar tóch vind ik het een verkeerde keuze. Iets als een bron bij een tekst is nou juist iets wat vaker voor kan komen op een pagina, en over het algemeen altijd hetzelfde gestijld wordt. Ik zou daarom ook juist een class gebruiken, en geen ID.

Daar heb je een punt. Ik denk dat ik dan maar iets anders moet verzinnen.

Anoniem: 9542 schreef op woensdag 21 juni 2006 @ 09:23:
bronvermelding is overigens typisch <address> (en de text in blockquote)

Het ADDRESS element moet contact informatie geven over de maker van de pagina. De bronvermelding geeft alleen aan wie de orginele tekst heeft gemaakt, niet de pagina zelf. En ik doe de tekst niet in een BLOCKQUOTE element omdat ik de tekst niet als citaat gebruik.

Anoniem: 9542 schreef op woensdag 21 juni 2006 @ 09:23:
verder hebben class en id natuurlijk niks met css te maken, in eerste instantie. Je geeft een element een class omdat ie anders is (in functie) dan de rest en daardoor heeft ie vaak een andere opmaak (waar je dat class attribuut dan handig voor kan gebruiken), je geeft geen class attribuut mee omdat je iets in een bepaalde opmaak wil hebben. (dit is een ontzettend hardnekkig misverstand)

Je geeft een element een class omdat ie anders is? Ik zou het erg op prijs stellen als jij mij vertelt waar ik dat in de HTML 4.01 specificatie kan vinden, want de enige functies voor het class attribuut die ik heb gevonden zijn:

• As a style sheet selector (when an author wishes to assign style information to a set of elements).
• For general purpose processing by user agents.

De eerste functie geeft duidelijk aan dat het attribuut erg op CSS is gericht. De tweede functie is nogal vaag. Het enige wat ik bij de tweede functie kan bedenken is JavaScript, verder niks. Ook vind ik het nogal nutteloos om een element een class attribuut te geven als deze een "anders is (in functie)". Dit heeft namelijk geen nut. De user agent begrijpt heus niet de inhoud van het class attribuut. Waar jij volgens mij aan denkt is XHTML 2.0's role attribuut. Het class attribuut is echter iets heel anders, dus waarom zouden we doen alsof dat niet zo is? Wat je ook verzint, het enige nut wat het class attribuut heeft is dat het gebruikt kan worden dmv CSS en JavaScript.

Anoniem: 9542 schreef op woensdag 21 juni 2006 @ 09:23:
geldt ook een beetje voor je verhaal over div: p's (en andere "hoofdstuk" elementen) zou je altijd moeten groeperen met een div, niet toevallig omdat je ze wil floaten (wat hier denk ik een nietszeggende term is, aangezien mensen er op dit punt nog niet bekend mee zijn). Div is zeer zeker niet een nietszeggend element.

http://www.rikkertkoppes.com/thoughts/class-and-style
http://www.rikkertkoppes.com/thoughts/about-div

het uitleggen van float doe je overigens het beste met termen als text-wrap denk ik, da's ook precies waar het voor is. Daarom zitten mensen ook altijd te fucken met clear, aangezien het in eerste instantie niet bedoeld is om blokken naast elkaar te zetten (daarvoor zou display: inline-block veel geschikter zijn)

Waarom zou je alle P's moeten groeperen in DIV elementen? Het voegt totaal geen waarde toe. DIV mag dan een groeperingselement zijn (zoals de HTML 4.01 specificatie ook aangeeft), maar als je verder niks met het DIV element doet, dan zie ik geen rede om het te gebruiken. Het DIV element op zichzelf is namelijk kansloos. Het heeft geen semantieke waarde en de user agent die de HTML leest kan er dus niks mee, tenzij het element wordt opgemaakt (of als het door JavaScript wordt gebruikt).

Wat je zegt over het float eigenlijk is waarschijnlijk wel waar. Ik denk dat ik dus het hele hoofdstuk van Je eerste website maar moet herschrijven.

Anoniem: 9542 schreef op woensdag 21 juni 2006 @ 09:23:
over <em> en <strong>. Ik heb ergens een stuk gelezen over global en local emphasis. Je kan hierover twisten, maar ik vind het wel een aardig onderscheid:
<em> gebruik je als je locaal in een zin nadruk wil leggen op een bepaald woord, dit zijn dan voornamelijk bijwoorden (bv niet, wel, deze etc). Aangezien ze schuin gedrukt zijn vallen ze ook pas op op het moment dat je eroverheen leest.
<strong> voor globale nadruk, woorden die opvallen op het moment dat je een artikel voor je neus krijgt. Dit zijn dan vaak -hoe noem je dat- woorden, in roddelbladen zie je het nogal: namen en woorden als "miljonair" etc. Woorden die dus belangrijk zijn voor heel de tekst.

Dit is aardig interessant, maar ik kan hier weinig over zeggen. Wat je hier bespreekt is namelijk niet iets wat direct met de HTML standaard te maken hebt, maar meer over de leesbaarheid van teksten. Aangezien ik geen expert ben ik toegankelijkheid van teksten kan ik dus niks doen dan aan jou vragen of je toevallig nog weet waar je dit gelezen hebt.

Anoniem: 9542 schreef op woensdag 21 juni 2006 @ 09:23:
bij citaten: blockquote is net zoiets als div (en map en fieldset), het is een paragraaf/hoofdstuk van iemand ander, terwijl het bij div een stuk van jezelf is

Zoals ik al eerder zei, ik zie niet zoveel in de waarde van het DIV element. Ondanks dat de spec zegt dat het een groeperingselement is, zegt het niet wat je moet groeperen, of hoe je de inhoud van DIVs moet benaderen. De spec zegt enkel dat je elementen kan groeperen.

Anoniem: 9542 schreef op woensdag 21 juni 2006 @ 09:23:
bij formulieren:
gebruik <p> om input en label te groeperen, niet <br> om ze te scheiden

Ik vind het overzichtelijker en logischer om elk onderdeel in een formulier (dus een LABEL met het bijbehorende INPUT, SELECT of TEXTAREA element) in een apart P element te doen. In het hoofdstuk over formulieren in de HTML 4.01 spec doen ze zelfs in twee voorbeelden het hele formulier in 1 P element. Maar heb je misschien een bron die argumenten voor jouw standpunt geeft.

Overigens erg bedankt voor je kritische feedback, mophor.

En Vinzzz z'n vraag is volgens mij voldoende beantwoord in de posts erna. Ik wil iig wel toevoegen dat je eerst moet kijken of die DIVs wel nodig zijn. Je ziet soms bijv. dat de enige child node van het BODY element een DIV is met bijvoorbeeld de id "container". Dit kan soms nodig zijn, maar 99,9% van de sites die dit gebruiken zijn vergeten dat het HTML element ook opgemaakt kan worden waardoor "container" overbodig wordt. Dus kijk eerst naar de elementen die je al tot je beschikking hebt voordat je DIVs gaat toevoegen.

[Blaise]

Ik kom wat zeggen over deze pagina.

In het begin zeg je dit: "Een INPUT element kan er als volgt uit zien:". Vervolgens krijg je een onherkenbaar input formulier omdat je de stijl hebt aangepast met 1px border. Ik denk dat je veel beter een door de browser gerenderde input zonder CSS-opmaak kan weergeven. Dit voor de duidelijkheid, zodat de vorm van de elementen herkenbaar zijn als iemand zelf de HTML gaat testen.

Vervolgens begin je over de verschillende types INPUT's. Ik zou daar alvast een voorbeeld van geven met een voorbeeldplaatje en/of in een HTML voorbeeld. Je uitleg van "type=radio" is trouwens nog wat wollig, dat kan compacter en duidelijker.

Bij je formulieren zeg je niet echt duidelijk iets over waardes, dat een input altijd een waarde heeft en dat een gesubmit formulier alle waardes tussen <form> en </form> verstuurt naar de ACTION.

En ik denk dat het ook handig is om alvast een artikel of pagina te maken waar je uitlegt wat javascript/PHP/ASP/MySQL zijn en waar je dat kan leren. Nu is het nog onduidelijk wat dat nou precies doet, terwijl je er bijna onvermijdelijk mee te maken gaat krijgen als je wat verder gevorderd bent met HTML. Is waarschijnlijk ook handig voor andere pagina's. Nu staat dat nog te onduidelijk in enkele regeltjes beschreven.

Verderop: "Zoals je misschien al had gemerkt kan je ook op de label klikken om de checkbox aan te vinken". Bij de embedde manier (voorbeeld 1) werkt het activeren van het inputveld (focus) niet in IE6. Dat is verwarrend. Daarom zou ik voorbeeld 2 gebruiken.

Dan kom ik het grote FORM voorbeeld tegen. Het is denk ik handig als je aangeeft waar het voorbeeld begint en eindigt, misschien met een gekleurde lijn om het voorbeeld heen, of het voorbeeld in een externe pagina. Nu integreert het teveel met de rest van de pagina (zoals ook eerder gezegd dat je voorbeelden beter CSS-loos kan laten).

In het voorbeeld is het niet correct dat je BUTTON gebruikt. Ok, het is makkelijk om te stylen, maar functionaliteit gaat voor vorm. Bovendien promoot je toegankelijkheid, en BUTTON kan een formulier niet versturen zonder javascript te gebruiken = ontoegankelijk.

[Anoniem: 9542]

over div en classes verwijs ik even voor het gemak naar mijn visie op m'n eigen site:
http://www.rikkertkoppes.com/thoughts/about-div
http://www.rikkertkoppes.com/thoughts/class-and-style

over div gebruik staat en de specs wel verstopt: http://www.w3.org/TR/html401/struct/global.html#h-7.5.5

over de <p> in forms, da's een discussie die met de whatwg uitvoerig is besproken en ook in de wa 1.0 draft terug komt: http://www.whatwg.org/specs/web-apps/current-work/#the-br

over blockquote en address: address kan ook over contact info van een deel van je pagina gaan, maar als je idd niet letterlijk quote heb je gelijk

over groeperings elementen: mijn visie: http://www.rikkertkoppes....s/general-html-structure/
zie hierover ook wa 1.0 over sectioning elements: http://www.whatwg.org/spe.../current-work/#sectioning

over <em> en <strong> dat staat ook wat uitgebreider in wa1.0 strong verandert de betekenis van de tekst niet, em wel.: http://www.whatwg.org/specs/web-apps/current-work/#the-em

voor het meeste geldt wel: het staat allemaal niet direct zo duidelijk in de specs, maar het is wel een beetje de heersende consensus, vandaar dat ik het ook propageer (en dat het in wa 1 terug komt)

[ Voor 14% gewijzigd door Anoniem: 9542 op 25-06-2006 21:07 ]

[crisp]

Blaise schreef op zondag 25 juni 2006 @ 19:55:
[...]
In het voorbeeld is het niet correct dat je BUTTON gebruikt. Ok, het is makkelijk om te stylen, maar functionaliteit gaat voor vorm. Bovendien promoot je toegankelijkheid, en BUTTON kan een formulier niet versturen zonder javascript te gebruiken = ontoegankelijk.

Een button-element heeft wel degelijk default een submit-actie; enkel de incorrecte implementatie van dit element in een bepaalde browser maakt het praktisch vaak nogal onbruikbaar

edit: pagina gelezen, maar met met type="button" is het uiteraard geen submit-element meer, dus de opmerking dat dat voorbeeld niet echt correct is klopt wel; dat staat daaronder wel uitgelegd maar dat schept eigenlijk alleen maar verwarring

[ Voor 19% gewijzigd door crisp op 25-06-2006 23:28 ]

[Blaise]

Een button-element heeft wel degelijk default een submit-actie

Dat verduidelijkt een hoop! Ik had laatst een formulier gemaakt waarin buttons stonden (voor insert UBB code dmv javascript). Als je erop klikte verstuurde het formulier zichzelf op magische wijze "vanzelf", maar alleen in Firefox. Ik dacht dat het een bug was

[djluc]

Wat ik een beetje mis is: Hoe maak je een formulier netjes op. Er zijn vele disussies over geweest: Met tabellen, met DT's e.d. of juist met een UL omdat het een lijst van formulier-onderdelen is.

[funkwurm]

crisp schreef op zondag 25 juni 2006 @ 23:25:
[...]

Een button-element heeft wel degelijk default een submit-actie; enkel de incorrecte implementatie van dit element in een bepaalde browser maakt het praktisch vaak nogal onbruikbaar

edit: pagina gelezen, maar met met type="button" is het uiteraard geen submit-element meer, dus de opmerking dat dat voorbeeld niet echt correct is klopt wel; dat staat daaronder wel uitgelegd maar dat schept eigenlijk alleen maar verwarring

Verander je voorbeeld dan even in <button type="submit">, dan werkt het in alle browsers als submit-button en zonder javascript.

[crisp]

funkwurm schreef op maandag 26 juni 2006 @ 21:03:
[...]

Verander je voorbeeld dan even in <button type="submit">, dan werkt het in alle browsers als submit-button en zonder javascript.

Maar dan ga je nog steeds voorbij aan de issues die IE heeft met dat element

[ Voor 3% gewijzigd door crisp op 26-06-2006 23:12 ]

[Vinzzz243]

crisp schreef op maandag 26 juni 2006 @ 23:12:
Maar dan ga je nog steeds voorbij aan de issues die IE heeft met dat element

zoals?

[Jero]

Vanmiddag heb ik niet bepaald veel te doen (niks eigenlijk), dus ik ga vanmiddag weer even aan de slag. Hieronder een to-do lijstje als geheugensteuntje voor mezelf:

• Engelse ziekte fixen.
• Omschrijving EM en STRONG elementen verbeteren.
• Beter voorbeeld maken voor het id attribuut.
• Voorbeelden maken voor de verschillende INPUT types.
• Verder gaan aan de HTML elementen referentie.

Blaise schreef op zondag 25 juni 2006 @ 19:55:
In het begin zeg je dit: "Een INPUT element kan er als volgt uit zien:". Vervolgens krijg je een onherkenbaar input formulier omdat je de stijl hebt aangepast met 1px border. Ik denk dat je veel beter een door de browser gerenderde input zonder CSS-opmaak kan weergeven. Dit voor de duidelijkheid, zodat de vorm van de elementen herkenbaar zijn als iemand zelf de HTML gaat testen.

Daar zit wel wat in, maar het wordt nu wel lastig om in de CSS aan te geven dat alle INPUT elementen opgemaakt moeten worden behalve dat INPUT. Misschien moet ik de opmaak dan maar verwijderen.

Blaise schreef op zondag 25 juni 2006 @ 19:55:
Vervolgens begin je over de verschillende types INPUT's. Ik zou daar alvast een voorbeeld van geven met een voorbeeldplaatje en/of in een HTML voorbeeld. Je uitleg van "type=radio" is trouwens nog wat wollig, dat kan compacter en duidelijker.

Voorbeelden zijn inderdaad wel een goed idee.

Blaise schreef op zondag 25 juni 2006 @ 19:55:
Bij je formulieren zeg je niet echt duidelijk iets over waardes, dat een input altijd een waarde heeft en dat een gesubmit formulier alle waardes tussen <form> en </form> verstuurt naar de ACTION.

Ik zal nog wel een keer kijken naar dat stuk.

Blaise schreef op zondag 25 juni 2006 @ 19:55:
En ik denk dat het ook handig is om alvast een artikel of pagina te maken waar je uitlegt wat javascript/PHP/ASP/MySQL zijn en waar je dat kan leren. Nu is het nog onduidelijk wat dat nou precies doet, terwijl je er bijna onvermijdelijk mee te maken gaat krijgen als je wat verder gevorderd bent met HTML. Is waarschijnlijk ook handig voor andere pagina's. Nu staat dat nog te onduidelijk in enkele regeltjes beschreven.

Daar ben ik het met je eens, maar ik wil eerst de handleiding en de referentie af hebben voordat ik met iets nieuws begin, maar een artikel zoals dat zou inderdaad niet verkeerd zijn.

Blaise schreef op zondag 25 juni 2006 @ 19:55:
Verderop: "Zoals je misschien al had gemerkt kan je ook op de label klikken om de checkbox aan te vinken". Bij de embedde manier (voorbeeld 1) werkt het activeren van het inputveld (focus) niet in IE6. Dat is verwarrend. Daarom zou ik voorbeeld 2 gebruiken.

Oew, dat wist ik niet. Goed dat je dat zegt. Ik zal het veranderen.

Bedankt voor je feedback, Blaise!

Anoniem: 9542 schreef op zondag 25 juni 2006 @ 21:01:
over div en classes verwijs ik even voor het gemak naar mijn visie op m'n eigen site:
http://www.rikkertkoppes.com/thoughts/about-div
http://www.rikkertkoppes.com/thoughts/class-and-style

over div gebruik staat en de specs wel verstopt: http://www.w3.org/TR/html401/struct/global.html#h-7.5.5

Op zich wel interessant, maar zoals ik het zie is het een voorbeeld dat laat zien dat je dmv DIVs sections kan aangeven en die vervolgens kan opmaken met CSS. Ik zie dus niet staan dat DIVs gebruikt moeten worden om zo sections aan te geven. Ook zie je dat de tweede zin aangeeft dat het eigenlijk alleen handig is om zo deze sections op te maken. Misschien lees ik het verkeerd, dus zeg het maar als je zo denkt (wat waarschijnlijk wel het geval zal zijn ).

Anoniem: 9542 schreef op zondag 25 juni 2006 @ 21:01:
over de <p> in forms, da's een discussie die met de whatwg uitvoerig is besproken en ook in de wa 1.0 draft terug komt: http://www.whatwg.org/specs/web-apps/current-work/#the-br

Volgens mij een verkeerde link? Of zie ik iets over het hoofd?

Anoniem: 9542 schreef op zondag 25 juni 2006 @ 21:01:
over blockquote en address: address kan ook over contact info van een deel van je pagina gaan, maar als je idd niet letterlijk quote heb je gelijk

Over ADDRESS heb je inderdaad gelijk, maar de link naar de pagina van Wikipedia is volgens mij geen contact informatie. En vooral voor Wikipedia is het lastig omdat de inhoud van de pagina waarschijnlijk door meedere mensen is gemaakt.

Anoniem: 9542 schreef op zondag 25 juni 2006 @ 21:01:
over <em> en <strong> dat staat ook wat uitgebreider in wa1.0 strong verandert de betekenis van de tekst niet, em wel.: http://www.whatwg.org/specs/web-apps/current-work/#the-em

Dit is misschien wel handig. Thanks.

funkwurm schreef op maandag 26 juni 2006 @ 21:03:
Verander je voorbeeld dan even in <button type="submit">, dan werkt het in alle browsers als submit-button en zonder javascript.

Ja, dat is toch wel beter.

[ Voor 3% gewijzigd door Jero op 27-06-2006 16:23 ]

[crisp]

Vinzzz schreef op dinsdag 27 juni 2006 @ 11:03:
[...]

zoals?

Naast de bekende styling issues het feit dat IE bij een button-element met een name- en value-attribuut niet de value meestuurd maar de content tussen <button> en </button>

[Anoniem: 9542]

goede link, zie het tweede gedeelte van beide voorbeelden over hoe je <br> niet moet gebruiken

over div: <div> == element om sections aan te geven. Het is semantisch rijker en correcter om het gewoon te doen. True, als je ze weglaat en je had er geen stijl op toegepast zie je het verschil niet, maar dat is niet de issue, er zijn meer elementen die de opmaak niet wijzigen, maar semantisch veelzeggend zijn.

<div> groepeert je blockelementen tot hoofdstukken en paragrafen (in de zin van deelhoofdstukken, niet alinea's). Dat is een veel over het hoofd geziene functie. Of je er vervolgens wel of niet iets mee doet qua opmaak is irrelevant

hier ook weer: het staat niet erg duidelijk in de html 4.01 spec en in de wa1 spec zijn er nieuwe elementen als <section> waar dit soort overwegingen wel vermeld staat. In de tussentijd adviseert men (whatwg) div als sectioning element in te zetten, zoals eigenlijk ook al in html 3 gespecificeerd stond

[ Voor 22% gewijzigd door Anoniem: 9542 op 27-06-2006 16:34 ]

[Jero]

Okay, de afgelopen dagen heb ik weer wat geknutselt aan de site. Zo heb ik de dingen uit m'n to-do list gedaan.

Zo heb ik dus het hoofdstuk Je eerst website op de schop genomen. Een nieuwe voorbeeldpagina is er voor de pagina over Tim Berners-Lee in de plaats gekomen. Dit keer met een zelfgeschreven stukje tekst en een copyrightregel (is dit een woord?) toegevoegd. Ook heb ik de uitleg van het float eigenschap aangepast zodat deze (hopelijk) beter te begrijpen is. Zo niet, bekritiseer er dan lekker op los. In andere woorden: feedback gewenst.

En dan blijft er op dit moment de referentie over. Jammer genoeg is dat nogal een irritant werkje maar ook vooral erg veel... Het vervelende is ook dat ik over een week op vakantie/werk ben voor 7 weken, dus ligt het project in die weken compleet stil. Dat is nogal zonde, dus zou het fijn zijn als de referentie voor het grootste gedeelte over een week af is, maar dat lijkt me nogal een lastige opgave (tenzij iemand natuurlijk bereidt is om mee te werken ).

[Jero]

Nog even voordat ik op vakantie ga. Ik heb Modern Markup in soort van bèta stage gedaan. Stelt niks voor maar hopelijk stimuleert dit de bezoekers om fouten wat sneller te melden tijdens mijn afwezigheid. Ook heb ik het hoofdstuk wat voorheen links en afbeeldingen veranderd naar links en mediaobjecten. Aan dit hoofdstuk heb ik dus, vanzelfsprekend, het OBJECT element toegevoegd. Wat vinden we ervan?

[BalusC]

Zo heb ik dus het hoofdstuk Je eerst website op de schop genomen.

<p>Copyright © 2006 Jouw website.</p>

Gebruik ©

[ Voor 44% gewijzigd door BalusC op 08-07-2006 06:36 ]

[Anoniem: 9542]

nergens voor nodig als je utf-8 gebruikt

[Anoniem: 26306]

Zoals je misschien al begrijpt wordt het href attribuut gebruikt om aan te geven naar welke pagina de link moet gaan als je erop klikt.

Een zoekmachine klikt niet. In een browser als Lynx klik je ook niet. Beschrijf niet de handeling, maar het proces of het gevolg.

Een link moet dus altijd een href attribuut hebben, anders is het namelijk geen link.

Wat is een link zonder href attribuut dan? Dan is het gewoon een anchor, dat kun je eventueel wel vertellen. En ook dat anchors overbodig zijn geworden nu zo ongeveer elk element een id attribuut kan hebben.

Verder dan dit kwam ik niet. Ik vind de tekst niet prettig leesbaar. De tekst zit vol met stijlfouten, en hier en daar zelfs een verdwaalde spelfout. Het is echt weer de zoveelste website waarop het wordt uitgelegd door iemand die het zelf ook niet helemaal bevat. Een hogere mate van abstractie is echt noodzakelijk om dit lastige onderwerp (markup) goed te behandelen. Nog één voorbeeld dan:

Het alt attribuut wordt gebruikt om een beknopte omschrijving van de afbeelding te geven. Indien de afbeelding niet geladen kan worden, dan wordt de omschrijving van het alt attribuut gebruikt.

Misschien kan een afbeelding prima geladen worden, maar is de user agent niet in staat om afbeeldingen te tonen. Misschien wil de bezoeker helemaal geen afbeeldingen zien. Juist daarom is het ook goed om hier uit te leggen dat het gaat om afbeeldingen die deel uitmaken van de inhoud van een pagina, en dat voor lay-outtechnische doeleinden het gebruik van het img element zoveel mogelijk voorkomen moet worden. Afbeeldingen kunnen namelijk ook achtergrondafbeeldingen zijn. Als voorbeeld geef je de alt-tekst: "Een afbeelding van een gans.".

Taak: bel iemand op, en lees een pagina voor. Zou het uitmaken of de alt-tekst "Een gans" bevat , of "Een afbeelding van een gans"? Is het niet zo dat een screen reader nog wel van het HTML element dat het een afbeelding is? Zou een screenreader niet vertellen dat het een afbeelding is van een afbeelding van een gans? Het is allemaal niet zó simpel.

Het is dus belangrijk dat je in alt altijd een goede, beknopte omschrijving geeft van de afbeelding voor het geval er probleem ontstaan met de afbeelding (iemand zou de afbeelding bijv. van de server kunnen verwijderen).

alt=""

Het is leuk dat je iets probeert bij te dragen aan het web, maar het gevaar is zoals altijd dat je alleen maar bestaande slechte gewoonten stimuleert. Ik ben bang dat je wel 2 of 3 volledige revisies verder bent voor je echt een goede tekst hebt.

[Anoniem: 9542]

om even op links in te gaan

een <a> is geen link, het is een anchor. Links bestaan er in 4 soorten:

1. van anchor naar pagina: <a href="www.tweakers.net">tweakers</a>
2. van anchor naar anchor binnen een pagina: <a href="www.tweakers.net#foep">de anchor #foep op tweakers</a>
3. van pagina naar pagina: <link rel="alternate" href="rss.something.com" type="text/xml" title="rss feed">
4. van pagina naar anchor binnen een pagina: <link rel="author" href="www.something.com/author#me">

een anchor binnen een pagina werd vroegah alleen aan gegeven met een <a> met een name attribuut, tegenwoordig ook door elk element met een id attribuut.

dus je zit wel in de richting, maar je verwoord het slecht: een <a> (anchor) vormt alleen een link als ie een href attribuut heeft. (of als ie target is van een andere link, alleen in de praktijk weet je dat vrijwel nooit. Hiervoor heb je overigens nog het rev attribuut)

het href attribuut is niet verpicht dus, dus je "moet" is veel te sterk

[ Voor 14% gewijzigd door Anoniem: 9542 op 08-07-2006 13:50 ]