HTML handleiding feedback

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.

funkwurm wijzigde dit bericht 09-06-2006 22:28 (3%)

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.

quote:

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

quote:

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.

quote:

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.

quote:

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.

Vind dit een beetje vreemd

quote:

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)

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

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 )

Toolskyn wijzigde dit bericht 10-06-2006 22:18 (8%)

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

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

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

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:

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

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