I wrote: >> Given the inherent structure of an address, a definition list with >> name/value pairs would also be more semantically fitting than a paragraph of >> text with line breaks.
Aryeh wrote; >That would either be incorrect use of <dl>, or would not display as >desired, or would require hiding some elements arbitrarily. That's not correct. Actually, I shouldn't have used the term "definition list" as such a list type does not exist in HTML5. The meaning of the dl element has been changed to that of an association list (name/value pairs). So, it can and should be used for addresses. I maintain that it is the most semantically rich HTML5 element for addresses. If you take a look at most forms where you enter an address, you'll see that there's an association between a label and an input field for the different parts of the address. It's rare that you have just a textarea to enter the entire address (which would be the equivalent of the <p>Name<br>Street<br>City</p> example). So why should the semantics change from input to output? >> <address> >> <dl> >> <dt>Name</dt><dd>P. Sherman</dd> >> <dt>Street</dt><dd>42 Wallaby Way</dd> >> <dt>City</dt><dd>Sydney</dd> >> </dl> >> </address> Aryeh wrote: > That requires hiding all the <dt> elements to achieve the same > display, which is kind of ridiculous. The first example was meant to underline the association. You're right that it would be ridiculous to insert the dt elements only to hide them (unless there was some accessibility advantage). And as Adam pointed out, following the spec the address element would not be appropriate in many cases. >> <address> >> <dl> >> <dd>P. Sherman</dd> >> <dd>42 Wallaby Way</dd> >> <dd>Sydney</dd> >> </dl> >> </address> Aryeh wrote: >That's invalid markup. The first child of a <dl> (if any) must be a ><dt>. I don't know what the semantics of <dl> are supposed to be with >no <dt>. According to the spec it is perfectly acceptable to leave out all dt elements: "If a dl element contains only dd elements, then it consists of one group with values but no names." Aryeh wrote: >It should already be adjustable using existing style properties, so no >change is needed except possibly saying it represents a logical break >instead of a line break. That's all I'm suggesting. Make it a logical/thematic not a presentational break in the spec. The default rendering should still be a line break to support existing content. Aryeh wrote: >This is basically wrong, though, since there >are lots of ways to mark up minor logical breaks, and <br> refers to >one particular way, no other. Which elements currently let me logically break up a paragraph? I can't think of any. There are only a handful of empty elements (like br, wbr, hr, img, input, param, embed). Except br none of them would be appropriate in such a case. Aryeh wrote: >Look at it this way: <br> is just a workaround for the fact that HTML >ignores newlines in markup. It could have just been in an >alternate history. It's presentational, yes, but so are periods and >commas. I would disagree here because I don't consider punctuation to be presentational. I'd say it's content because leaving punctuation out can change the meaning.
