[whatwg] [br] element should not be a line break
thomas.koetter at id-script.de
Thu Aug 5 02:24:42 PDT 2010
>> 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.
>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?
>> <dt>Name</dt><dd>P. Sherman</dd>
>> <dt>Street</dt><dd>42 Wallaby Way</dd>
> 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.
>> <dd>P. Sherman</dd>
>> <dd>42 Wallaby Way</dd>
>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
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."
>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.
>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.
>Look at it this way: <br> is just a workaround for the fact that HTML
>ignores newlines in markup. It could have just been
>alternate history. It's presentational, yes, but so are periods and
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.
More information about the whatwg