[HTML / Semantiek] Geen dl in een address

[xilent_xage]

Hoi,

Laat ik beginnen toe te geven dat ik een mierenneuker ben. Ik zit met een footer met daarin mijn contactgegevens. DIe probeer ik zo semantisch-correct mogelijk weer te geven.

HTML:

<address class="footer-box vcard">
    <p class="copyright">&copy; 2010 <a href='/contact.vcard' class='fn'>Mijn naam</a></p>
    <dl>
        <dt>Telefoon:</dt>
        <dd class='tel'>061234567890</dd>
        <dt>E-Mail:</dt>
        <dd class='email'><a href="mailto:[e-mail];">[e-mail];</a></dd>
    </dl>
</address>

Probleem is dat deze code niet valideert (XHTML 1.0 strict), omdat <address> geen blocklevel-elementen mag bevatten. Das irritant, want ik vond de <dl> juist zo geschikt.

Nou kan ik verschillende oplossingen bedenken die mij geen van allen aanstaan:

1. We gooien de contactgegevens (evt voorzien van wat spans voor de vcard) gewoon ongestructureerd in de <address>.
2. Ik stap af van het gebruij van <address> en gebruik gewoon een <div>

Ik ben met geen van beide oplossingen erg happy. Is er een andere manier die ik over het hoofd zie? Wat zouden jullie doen?

[Bosmonster]

Wat ik zou doen is geen xhtml gebruiken. In html5 valideert dit gewoon.

Maar daarnaast hoef je voor een address geen extra semantiek toe te voegen. Het gaat om de inhoud van het element en die kun je in dit geval gewoon zien als een paragraph. De inhoud kun je dus gewoon scheiden met regeleinden (br's). Jouw toevoeging van de dl werkt eigenlijk een beetje tegenstrijdig met het idee achter semantiek.

Probeer dus niet teveel door te denken en semantiek te forceren.

Overigens, als je zo'n mierenneuker bent, zorg dan dat je in ieder geval altijd dubbele quotes gebruikt ipv enkel en dubbel door elkaar

[ Voor 95% gewijzigd door Bosmonster op 12-07-2010 23:59 ]

[CH4OS]

Bosmonster schreef op maandag 12 juli 2010 @ 23:53:
Wat ik zou doen is geen xhtml gebruiken. In html5 valideert dit gewoon.

Maar HTML5 is nog geen standaard, laat staan ondersteund in de grootste browsers, dus aan de andere kant zegt het (nog) niets lijkt me.

@TS, volgens Michiel van Parse.nl is een DL een termenlijst, al zou je er wel N:N-relaties mee kunnen leggen. Maar is met contact gegevens denk ik niet wat de bedoeling is aangezien 'straat' geen term is.

[ Voor 4% gewijzigd door CH4OS op 13-07-2010 00:18 ]

[NMe]

CptChaos schreef op dinsdag 13 juli 2010 @ 00:04:
[...]
Maar HTML5 is nog geen standaard, laat staan ondersteund in de grootste browsers, dus aan de andere kant zegt het (nog) niets lijkt me.

HTML4 staat het ook gewoon toe.

Daarnaast is met de ondersteuning van IE9 binnenkort wel te zeggen dat HTML5 bijna niet meer gaat veranderen aangezien de grootste spelers op de browsermarkt allemaal een werkende implementatie hebben van de meest recente spec.

CptChaos schreef op dinsdag 13 juli 2010 @ 00:04:
[...]

@TS, volgens Michiel van Parse.nl is een DL een termenlijst, al zou je er wel N:N-relaties kunnen leggen. Maar is met contact gegevens denk ik niet wat de bedoeling is aangezien 'straat' geen term is.

In het Engels is het gewoon een "definition list". En semantisch gezien is het dat wel degelijk. Ik gebruik dl's zelf trouwens ook regelmatig om formulieren in op te maken: label in een dt, input in een dd en vervolgens netjes naast elkaar stylen. Zo heb je het mooi opgemaakt én de verhouding tussen label en input vastgelegd.

[ Voor 40% gewijzigd door NMe op 13-07-2010 00:09 ]

[RobIII]

CptChaos schreef op dinsdag 13 juli 2010 @ 00:04:
[...]
Maar HTML5 is nog geen standaard, laat staan ondersteund in de grootste browsers, dus aan de andere kant zegt het (nog) niets lijkt me.

HTML5 verwacht men pas in 2022 ofzo tot "recommendation" te verheffen; wil je daar op gaan wachten dan wens ik je veel plezier. Daarbij ondersteunen juist de grootste browsers steeds meer-en-meer "HTML5" zaken en begint acceptatie onder developers behoorlijk op te lopen.

NMe schreef op dinsdag 13 juli 2010 @ 00:07:

Daarnaast is met de ondersteuning van IE9 binnenkort wel te zeggen dat HTML5 bijna niet meer gaat veranderen aangezien de grootste spelers op de browsermarkt allemaal een werkende implementatie hebben van de meest recente spec.

Ik verwacht nog zat veranderingen/aanpassingen* in "HTML5"; maar dat wil niet zeggen dat er nu niet (al) mee gewerkt kan worden; de grote browsers zijn allemaal relatief "bij".

* Ik verwacht eigenlijk meer "toevoegingen" aan de huidige spec welke de (nu) stabiele delen niet of nauwelijks zullen impacten.

[ Voor 47% gewijzigd door RobIII op 13-07-2010 00:16 ]

[NMe]

RobIII schreef op dinsdag 13 juli 2010 @ 00:08:
[...]

* Ik verwacht eigenlijk meer "toevoegingen" aan de huidige spec welke de (nu) stabiele delen niet of nauwelijks zullen impacten.

offtopic:
Dat bedoelde ik ook met "niet meer veranderen" al ben ik daar wat vaag in. De spec wijzigt inderdaad vast nog wel een beetje maar de kans dat er grote wijzigingen gaan gebeuren in de nieuwe features die al door zoveel browsers ondersteund worden acht ik vrij klein.

[R4gnax]

xilent_xage schreef op maandag 12 juli 2010 @ 23:06:
Ik ben met geen van beide oplossingen erg happy. Is er een andere manier die ik over het hoofd zie? Wat zouden jullie doen?

Copyright hoort sowieso niet in je <address> element. Dat element hoort alleen de direct relevante contact-, dan wel persoonsgegevens voor de auteur van de site te bevatten. Het <address> element lijkt in HTML / XHTML revisies voor HTML5 slechts gericht te zijn op gebruik voor een korte inline opsomming van auteursnamen en instanties / instituten in de vorm van een wetenschappelijke publicatie.

Wil je het element toch zinnig gebruiken met gestructureerde data, zou ik het zo doen:

HTML:

<dl role="contentinfo">
  <dt role="license">&copy; 2010</dt>
    <dd><address><a href='/contact.vcard' rel="author">Mijn naam</a></address></dd>
  <dt>Telefoon</dt>
    <dd>06-123456890</dd>
  <dt>Email</dt>
    <dd><a href="mailto:[e-mail];" rel="author">[e-mail]</a></dd>
</dd>

Je associeert op die manier je copyright / license statement (wat een onderdeel van de contentinfo van je document is) met jouw naam, die via een <a> met de relatie 'author' doorlinkt naar een complete set relevante auteursinformatie in de vorm van een vCard. Je contact e-mail adres draagt daarnaast nogmaals de author relatie voor accessibility, maar het zijn niet je primaire contactgegevens. Die rol wordt vervuld door de vCard link.

(Overigens zie ik de dubbele punt achter jouw <dt> elementen eerder als een :after CSS pseudo class dan als content. Feitelijk is het slechts een puur visuele separator die een <dt> tag met de daarop volgende reeks <dd> tags verbindt. Het is niet een leesteken in een stuk tekst.)

Bosmonster schreef op maandag 12 juli 2010 @ 23:53:
Wat ik zou doen is geen xhtml gebruiken. In html5 valideert dit gewoon.

Inderdaad. HTML5's fijnere onderverdeling in flow/heading/sectioning/phrasing/etc. content zet een aantal zaken recht, waaronder het feit dat het address element eindelijk block elementen kan bevatten, zolang het maar niet heading of sectioning elementen zijn. Al gebruik je de nieuwe HTML5 tags nog niet, alleen deze verbeterde onderverdeling zou al een goede reden zijn om het HTML5 doctype te gebruiken. (Geldt wel nog steeds dat je het copyright niet in de adresgegevens dient te stoppen.)

[xilent_xage]

Heerlijk die warme douche, om te weten dat ik niet de enige ben die van dit soort dingen wakker kan liggen bedankt voor alle feedback!

Die role kan ik helaas ook niet gebruiken in XHTML 1.0 strict, waar ik nog even bij blijf. HTML5 wacht ik liever nog even mee. Die rel's zijn inderdaad mooi en heb ik toegepast, net als de : als after middels css toevoegen.

O en de verschillen tussen ' en " worden verderop in de parser opgeschoond, waarna er een tidy (inclusief accessibility-check en sort-attributes) overheen gaat, en daarna nog een minifier.

[ Voor 60% gewijzigd door xilent_xage op 13-07-2010 08:26 ]

[Bosmonster]

CptChaos schreef op dinsdag 13 juli 2010 @ 00:04:
[...]
Maar HTML5 is nog geen standaard, laat staan ondersteund in de grootste browsers, dus aan de andere kant zegt het (nog) niets lijkt me.

Het gaat ook niet om het toepassen van de volledige standaard, maar om het toepassen van de doctype. Deze doctype wordt ondersteund door alle gebruikte browsers, zelfs IE6 en veel constructies valideren in html5 wel.

Het is redelijk zinloos jezelf opzettelijk onnodige beperkingen op te leggen met een doctype zoals xhtml strict.

[NMe]

Als je gewoon XHTML schrijft met HTML5 doctype is je probleem opgelost terwijl er voor geen enkele browser verder iets verandert kwa weergave. Waarom zou je bij XHTML (dat IE zelfs alleen maar bij gratie van een vergevingsgezinde renderengine kan renderen) willen blijven?

Overigens vind ik het nogal loos om inconsistent te zijn met quotegebruik alleen omdat het toch door een beautifier heen gaat. Je moet je code ook gewoon kunnen lezen en desnoods uitbreiden zonder steeds extra goed op de gebruikte quotes te moeten letten.

[R4gnax]

xilent_xage schreef op dinsdag 13 juli 2010 @ 08:16:
Die role kan ik helaas ook niet gebruiken in XHTML 1.0 strict, waar ik nog even bij blijf.

DTD extenden met de XHTML Role module?

[geert1]

Voor velen is het even wennen dat overstappen op de HTML5 doctype gewoon veilig is. Er zijn geen render-problemen of nadelen, zelfs niet in IE6. Tegelijk maak je je site wel alvast klaar voor de toekomt, want hoewel HTML5 nog een draft is, zal er in grote lijnen niet enorm veel meer veranderen.

Of je alle nieuwe tags van HTML5 nu al moet gebruiken, daar valt over te discussieren, maar de doctype is een prima ding om nu al mee te werken. En het lost het originele probleem van de topicstarter op zonder compromissen en work-arounds. Wat wil je nog meer?

[Bosmonster]

Voor veel developers is vernieuwing een eng iets. Die zitten met frontend development in het verkeerde vak. Het landschap van standaarden, aanbevelingen en clients is daarvoor veel te dynamisch. Je kunt hierin niet vasthouden aan één werkwijze, maar zult die bijna dagelijks moeten herzien en bijstellen.

[ Voor 47% gewijzigd door Bosmonster op 16-07-2010 10:35 ]

[posttoast]

Sorry voor deze schop, maar ik kwam dit topic toevallig tegen en vind het interessant genoeg om op te reageren. Allereerst mijn duit in het zakje over het gebruik van HTML5: er is mijns inziens geen enkele reden om niet met de HTML5 doctype te werken. Gewoon doen dus.

Maar goed, na zo'n tijd zit de topicstarter niet meer op mijn mening te wachten denk ik. Deze reactie gaat vooral even over het volgende:

NMe schreef op dinsdag 13 juli 2010 @ 00:07:
[...]
In het Engels is het gewoon een "definition list". En semantisch gezien is het dat wel degelijk. Ik gebruik dl's zelf trouwens ook regelmatig om formulieren in op te maken: label in een dt, input in een dd en vervolgens netjes naast elkaar stylen. Zo heb je het mooi opgemaakt én de verhouding tussen label en input vastgelegd.

Waarom zou je een definition list gebruiken om de verhouding tussen label en input aan te geven? Die relatie is er toch per definitie (middels het for attribuut óf door het label-element om de input te wrappen)? Ik snap de semantische waarde hier niet van, maar ben (zelfs na zo'n lange tijd) wel benieuwd naar jouw gedachte hierover.

[Bosmonster]

DL's zijn een klein drama om goed te stylen en daarnaast zie ik voor een formulier de toegevoegde waarde ook niet, zoals je zelf al zegt.

Ik gebruik eigenlijk altijd een OL met daarin label/velden per LI. Styled een stuk makkelijker ook.

Wat belangrijker is om niet te vergeten bij formulieren is je fieldset/legend. Die kun je met CSS gewoon onzichtbaar maken, maar belangrijk is dat ze iig gedefinieerd zijn.

[posttoast]

Bosmonster schreef op dinsdag 11 januari 2011 @ 11:24:
DL's zijn een klein drama om goed te stylen en daarnaast zie ik voor een formulier de toegevoegde waarde ook niet, zoals je zelf al zegt.

Ik gebruik eigenlijk altijd een OL met daarin label/velden per LI. Styled een stuk makkelijker ook.

Wat belangrijker is om niet te vergeten bij formulieren is je fieldset/legend. Die kun je met CSS gewoon onzichtbaar maken, maar belangrijk is dat ze iig gedefinieerd zijn.

Is een fieldset ook relevant als je slechts één formulierdeel hebt? Bijvoorbeeld username/password?

[Bosmonster]

Ja. Altijd. Zelfs een enkele searchbox.

Je mag inputs niet direct in een form plaatsen, die horen altijd in een fieldset (al accepteert de validator ieder element)

Maar de styling daarvan kun je standaard gewoon uitzetten:

Cascading Stylesheet:

form fieldset {
   margin: 0;
   padding: 0;
   border: 0;
}
form fieldset legend {
   display: none;
}

Dan zie je er niks van.

Een login form html zou er bij mij zo uitzien:

HTML:

<form method="post" action="">
   <fieldset>
      <legend>Login</legend>
      <ol>
          <li>
              <label for="username">Username</label>
              <input type="text" name="username" id="username">
          </li>
          <li>
              <label for="password">Password</label>
              <input type="password" name="password" id="password">
          </li>
          <li>
              <input type="submit" value="Login">
          </li>
      </ol>
   </fieldset>
</form>

Een interessante vraag vind ik nog wel het belang van een label bij buttons.

[ Voor 150% gewijzigd door Bosmonster op 11-01-2011 11:51 ]

[Kiphaas7]

Uit een minimalistisch oogpunt, meestal heb je boven je form in een of andere tag (header meestal?) al "Login" staan. Wat is dan de meerwaarde om dit ook nog eens in de legend te defineren?

Of andersom, waarom zou je dit nog erboven defineren als je het al in de legend hebt staan.

[Bosmonster]

Een header en een legend hebben een hele andere functie. De header is je titel boven de content eronder. Bijvoorbeeld je form, paragraphs's, lists, etc.

De legend is de beschrijving van die fieldset in je formulier.

Dat die hetzelfde kunnen zijn wil niet zeggen dat je zomaar 1 van de 2 weg kan laten.

Je kunt bijvoorbeeld best nog een paragraph of list met links als registreren, wachtwoord vergeten of voorwaarden onder je formulier hebben. De header slaat dan wel daarop, de legend niet.


Minimalisme en semantisch correcte html is sowieso niet compatible. Je zult aardig wat html schrijven vanuit semantisch oogpunt die verder niemand ziet.

[ Voor 14% gewijzigd door Bosmonster op 11-01-2011 12:02 ]

[RaZ]

Het valt me op dat de TS hier gewoon gebruikt maakt van een vCard in Microformat, met de juiste daarbij behorende classes. Wat dit dus machine-readable maakt. Iedere tip die gegeven wordt sloopt die hele microformat, en zal die inhoud dus niet meer machine-readable zijn.

Zolang je de microformat-vcard-classes gebruikt, blijft dat verders in tact. Het voorbeeld van R4gnax zal misshien er beter uitzien, maar de microformat is daarmee wel omzeep.


@hieronder: Uh, daar heb je natuurlijk wel helemaal gelijk in ja.

[ Voor 7% gewijzigd door RaZ op 11-01-2011 12:25 ]

[Bosmonster]

Iedere tip die gegeven wordt sloopt die hele microformat, en zal die inhoud dus niet meer machine-readable zijn.

Want met andere html kun je de microformat-classes niet meer toevoegen?

Het gaat hier om de semantiek van de html, niet om die paar classes voor microformats

[ Voor 18% gewijzigd door Bosmonster op 11-01-2011 12:10 ]

[NMe]

Bosmonster schreef op dinsdag 11 januari 2011 @ 11:24:
DL's zijn een klein drama om goed te stylen en daarnaast zie ik voor een formulier de toegevoegde waarde ook niet, zoals je zelf al zegt.

Hoezo een klein drama om goed te stylen? Deze gaat voor zover ik kan zien altijd goed, zelfs al is de styling een beetje smerig.

Cascading Stylesheet:

dl {
    width: 300px;
}
dt {
    clear: left;
    float: left;
    width: 100px;
    text-align: right;
}
dd {
    padding: 0 10px 2px 0;
    margin-left: 100px;
}

HTML:

<dl>
    <dt>Naam:</dt>
    <dd>Pietje</dd>
                
    <dt>Adres:</dt>
    <dd>Stationstraat 1</dd>

    <dt>Postcode:</dt>
    <dd>1234AB</dd>

    <dt>Plaats:</dt>
    <dd>Nergenshuizen</dd>
</dl>

Overigens heb je gelijk dat je ook een label kan stylen en je input daarnaast. Dat maakt echter deze methode niet fout, IMO. Semantisch gezien is het een definitielijst waarbij je de gebruiker zelf zijn definities in laat vullen voor de termen waar je om vraagt. Daarnaast heb je het voordeel dat je vrijwel dezelfde styling kan gebruiken aan het einde van een bestelproces (bijvoorbeeld), waar je nog even alle ingevoerde data afdrukt, deze keer zonder inputs. Als je alleen met labels en inputs werkt zul je alsnog iets vergelijkbaars moeten stylen als hierboven.

[Bosmonster]

Die styling faalt wanneer je label meer dan 1 regel nodig heeft. Ook is de afstand tussen de dt/dl's erg lastig goed te krijgen, aangezien ze geen wrapper element hebben.

Rendering (oa van bovenstaande issues) is tevens dermate verschillend tussen de verschillende browserversies, dat het idd een klein drama wordt om een DL goed te stylen

[ Voor 79% gewijzigd door Bosmonster op 11-01-2011 12:40 ]