html5, article vs. div
Ik ben bezig met een pastebin, ontwerp is al af maar nu twijfel ik over de juiste elements.
Een screenshot voor wat duidelijkheid:
Kan ik de content (rood) beter in een article stoppen of in een div#content? En het groen, kan dit beter in een div of in een section?
Hoe kijken browsers hier precies tegenaan en hoe kijkt googlebot hier tegenaan?
Alvast bedankt,
David
Quote:
Hoe kijken browsers hier precies tegenaan en hoe kijkt googlebot hier tegenaan?
Dat heeft eigenlijk niet heel veel er mee te maken. Het is meer wat voor waarde/betekenis de specificatie aan deze elementen geven, de browsers/bots proberen zich dan hieraan te houden.
Een division element (<div>) heeft geen enkele betekenis, een element die wel een betekenis heeft moet altijd voorrang krijgen op de division.
We moeten een element hebben die de 2 groene blokken aan elkaar koppelt. Het heeft geen titel, dus we kunnen geen artikel gebruiken, de groene blokken zijn meer artikelen. Je hebt dus 2 keuzes: article of division voor het rode blok. Welke je gebruikt ligt aan hoe belangrijk je het rode blok vind: Is het meer dan een element om de groene blokken in het midden te houden (dus een section) of is styling zijn enige taak (dus een division).
Aangezien de beide blokken wel met elkaar te maken hebben, zou ik gaan voor <section>.
Wouter J heeft zeker een punt: als je géén volwaardige content hebt, maar alleen een blanco formulier, heeft het weinig zin het geheel te structureren als een artikel.
Ward, je kunt toch een section gebruiken? Surrogaat-divs lijkt me geen mooie oplossing. Er is een stukje javascript waardoor oudere browsers ook de html5 elementen herkennen.
En ik zat te denken dat dit misschien nog beter is:
De workaround met surrogaat-div's is inderdaad mede bedoeld om te voorkomen dat je JavaScript voor een andere workaround nodig hebt. Dat is dus kiezen uit twee kwaden en dat is per definitie nooit ideaal.
Wouter J op 19/11/2012 14:12:24:
... je hoeft alleen HTML5shiv in te laden. ...
Die ken ik niet.
Is dat enkel die .js file laden?
dit js'je inladen (meer informatie hier en hier).
Ward, je hebt inderdaad ook wel een punt. Dit kan ook een oplossing zijn:
Kris, ja dat klopt. Je moet Ward, je hebt inderdaad ook wel een punt. Dit kan ook een oplossing zijn:
Wat trouwens ook helpt, is de manier waarop HTML omgaat met syntax, vooral dan met syntax die de parser niet begrijpt.
talen zoals php of javascript gaan vlug een parse error gooien en weigeren verder te werken.
De HTML parser reageert meer volgens volgende principes:
- ofwel begrijp ik het ofwel negeer ik het
- als er iets ontbreekt, probeer ik het aan te vullen, met de default
Dat maakt HTML een ideale taal om organisch te evolueren, zonder dat daar speciaal een nieuwe software versie
voor nodig is.
voorbeeld: <input type="email">
Oude browsers kennen type="email" niet, maar dat zorgt niet voor problemen. Oude browsers negeren het attribute en maken er zelf een <input type="text"> van.
Ook nieuwe tags kunnen relatief gemakkelijk worden toegevoegd.
Ik heb vlug even een custom tag gemaakt <kris>; FF en Chrome geven het element weer zoals andere tags.
(Je hoort me niet zeggen dat het een goed idee is om custom elementen te maken, ik maak gewoon een punt over het parsen van HTML...)
The <kris> tag defines a reversed zig-zag division or section in an HTML document.
The <kris> tag is used to group reversed zig-zagged block-elements to format them with CSS.
Quote:
Ik heb vlug even een custom tag gemaakt <kris>; FF en Chrome geven het element weer zoals andere tags.
IE8 en lager gaan hier net iets anders mee om, ze halen het element gewoon weg uit de dom. Om dit te voorkomen gebruik je een hack die HTML5shiv in het groots toepast maakt: Je voegt hem toe aan de dom voordat hij gemaakt is:
Het enige waar je mee moet uitkijken is dat het geen User Agent Styles (default stijlen) meekrijgt. Hierdoor moet je zelf aangeven of het display: block; of inline is ect.
Hoe parser om moeten gaan met fouten is ooit eens helemaal uitgezocht en beschreven als een standaard door Hixie (Ian Hickson), erg droge stof maar misschien wel goed om eens te lezen: http://www.whatwg.org/specs/web-apps/current-work/#parsing
Leuke artikelen van Hixie waarin hij zijn bevindingen in het toen nog parser paradijs uitlegt: http://ln.hixie.ch/?start=1037910467&count=1 , http://ln.hixie.ch/?start=1138169545&count=1 en http://ln.hixie.ch/?start=1137740632&count=1
@ozzie, weet je dat zeker? Heb je misschien een bron? (hij wordt namelijk niet in de HTML5 specs beschreven)
Gewijzigd op 19/11/2012 17:51:10 door Wouter J
Wouter J op 19/11/2012 17:49:32:
@ozzie, weet je dat zeker? Heb je misschien een bron? (hij wordt namelijk niet in de HTML5 specs beschreven)
Het is het kris-kras element!! Whooeehahaha... sorry, het was een grapje :D
Neem me niet kwalijk...
Bedankt voor alle reacties. Had opeens 12 mailtjes in mijn mailbox :s (Van een gmail account... ? )
Html5Shiv kende ik al, gebruikte ik al ooit eens. Werkte erg goed.
Ik ga verder nog een beetje rondlezen bij de linkjes die gepost zijn en dan ga ik wel een keuze maken
Quote:
Het is het kris-kras element!! Whooeehahaha... sorry, het was een grapje :D
Neem me niet kwalijk...
Neem me niet kwalijk...
Haha...slik..ai... Ik dacht, het zou toch niet een grap zijn...
David, de meeste linkjes zijn dingen die half iets met dit te maken hebben, de discussie over hoe het moet (en de 3 à 4 ideeën die gegeven zijn) zijn waarschijnlijk interessanter om je vraag op te lossen.
Gewijzigd op 19/11/2012 21:37:25 door Wouter J
Ik had zelf ook helemaal niet aan fieldset gedacht, zat de nieuwe html5 elements te kijken en hier stond fieldset niet tussen omdat die natuurlijk niet nieuw was. Had mezelelf een beetje gelimiteerd tot "nieuw". Ik denk dat ik fieldset met een section neem!
Bedankt,
Quote:
Ik gaf het al op toen ik een scrollbar van minder dan 1 centimeter groot zag staan.. Mijn god. Ik ga dat toch niet allemaal lezen..
Oh je bedoelt de specificaties, nee die moet je niet helemaal willen lezen. Gewoon als je opzoek bent naar de betekenis van een element gaan zoeken op die pagina (Ctrl+f) naar dat element, die link aanklikken en de beschrijving voor dat element lezen.
Gewijzigd op 23/11/2012 23:00:00 door David Bekker
In tegenstelling tot wat http://www.w3schools.com/tags/tag_legend.asp geeft: doe het zo:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
<form>
<h2>Your information</h2>
<fieldset>
<legend>Personalia:</legend>
<label for="naam">Name</label><input name="naam" type="text" >
<label for="email">Email</label><input name="email" type="text">
<label for="dateofbirth">Date of birth</label><input name="dateofbirth type="date">
</fieldset>
<fieldset>
<legend>Submitting:</legend>
<label for="submitbutton">Send</label><input name="submitbutton" type="submit" >
</fieldset>
</form>
<h2>Your information</h2>
<fieldset>
<legend>Personalia:</legend>
<label for="naam">Name</label><input name="naam" type="text" >
<label for="email">Email</label><input name="email" type="text">
<label for="dateofbirth">Date of birth</label><input name="dateofbirth type="date">
</fieldset>
<fieldset>
<legend>Submitting:</legend>
<label for="submitbutton">Send</label><input name="submitbutton" type="submit" >
</fieldset>
</form>
W3C heeft vaak leuke dingen (zoals Google Ranking...) maar zit er nog wel eens naast.
Zo vragen ze gerust een datum in een type="text"-formaat ipv type="date".
Ook gebruiken ze dan opeens geen <label>.
Gewijzigd op 24/11/2012 10:12:11 door Eddy E