Gathering of Tweakers

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:

1 2 3 4 5

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

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.

BalusC wijzigde dit bericht 21-06-2006 08:46 (16%)

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

mophor wijzigde dit bericht 21-06-2006 10:38 (99%)

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:

1 2 3 4 5 6 7 8 9 10

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

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)

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.

quote:

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:

1 2 3 4 5 6 7 8 9 10

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

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

quote:

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.

quote:

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.

quote:

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

quote:

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

quote:

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

quote:

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

quote:

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

quote:

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

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.

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)

mophor wijzigde dit bericht 25-06-2006 21:07 (14%)

quote:

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

crisp wijzigde dit bericht 25-06-2006 23:28 (19%)

quote:

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

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.

quote:

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.

quote:

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

crisp wijzigde dit bericht 26-06-2006 23:12 (3%)

quote:

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?

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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!

quote:

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

quote:

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

quote:

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

quote:

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

quote:

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.

Jeroen vd Meer wijzigde dit bericht 27-06-2006 16:23 (3%)

quote:

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>

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

mophor wijzigde dit bericht 27-06-2006 16:34 (22%)

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

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?

quote:

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

quote:

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

Gebruik ©

BalusC wijzigde dit bericht 08-07-2006 06:36 (44%)

nergens voor nodig als je utf-8 gebruikt

quote:

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.

quote:

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:

quote:

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.

quote:

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.

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

mophor wijzigde dit bericht 08-07-2006 13:50 (14%)