[whatwg] [br] element should not be a line break

[Ian Hickson]

On Wed, 4 Aug 2010, Thomas Koetter wrote:
> 
> In the past, there has been a lot discussion about not using br just to 
> insert line breaks everywhere. I'm fully aware that we have lots of 
> elements that are often a better fit and that, of course, line breaks 
> can be achieved by "blocking" inline elements.
> 
> What strikes me though is that according to the spec "The br element 
> represents a line break". A *line* break is presentational in nature. 
> The break is structural, but restricting it to a certain presentation of 
> that break lacks the desired separation of structure and presentation.
> 
> Wouldn't it make more sense to consider the br element to be just a 
> minor logical break inside a paragraph? Just like hr represents a 
> thematic break on the paragraph-level. How the break would be rendered 
> is a different matter and should be left to the designer.

Calling it a "line break" doesn't say how it is rendered. It's just a 
conceptual description.

(A "minor logical break inside a paragraph" is not generally represented 
by a line break, at least not in any typographic conventions I've seen; 
usually, in my experience, those are denoted either using ellipses, 
em-dashes, or parentheses.)


> In addition, the appropriate uses (poems, addresses) and examples 
> currently given are not convincing.
> 
> Consider this:
> <p>P. Sherman<br>
> 42 Wallaby Way<br>
> Sydney</p>
> 
> There's no reason why line breaks should be part of an address. I've 
> seen many addresses on one line with their parts separated just by dots 
> or pipes.

Those are line breaks.


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

I don't know about that. When you look up the formal way to write an 
address, it's not a set of name-value pairs. It's a set of lines. For 
example, from the UK post office site:

   http://www.postoffice.co.uk/portal/po/content1?catId=19100182&mediaId=95100765


> <address>

(Note, by the by, that <address>, despite its name, is about page contact 
information, not about postal addresses.)


> 	<dl>
> 		<dt>Name</dt><dd>P. Sherman</dd>
> 		<dt>Street</dt><dd>42 Wallaby Way</dd>
> 		<dt>City</dt><dd>Sydney</dd>
> 	</dl>
> </address>

That would be fine, but isn't how you write an address.


> Or just:
> <address>
> 	<dl>
> 		<dd>P. Sherman</dd>
> 		<dd>42 Wallaby Way</dd>
> 		<dd>Sydney</dd>
> 	</dl>
> </address>

The latter is very wrong, there's no "name" part!


> Regarding poems, line breaks have conventionally been used in Western 
> literature to aid in manifesting the rhythm. And there surely are many 
> poems that use formatting for artistic effect.

Indeed, see the example under <pre>.


> But I think it would be hard to say that *line* breaks are an inherent 
> part of poems per se. I'd say that breaks are important means to 
> determine structure, but line breaks are just one of many possible 
> manifestations of such breaks.

I have spoken to poets who would strongly disagree with you, but that's 
academic -- there's nothing that says that <br> has to map to a physical 
new line. It's just a conceptual line break.


> Just like in a musical score where the bar is present in sheet music but 
> not in the actual music being played.

I don't know that those are equivalent to line breaks.


> Interestingly, the examples given for where not to use br look like 
> great examples to actually use a break element (not necessarily a line 
> break).
> 
> First example:
> <p><a ...>34 comments.</a><br>
> <a ...>Add a comment.</a></p>
> 
> There are two separate pieces of text that belong together (they are 
> both related to comments). So using one paragraph to group them is fine. 
> But they can benefit from a separation that is a bit stronger than just 
> punctuation since one of them is purely informational and the other is a 
> call to action. This is where a break element is perfect. One designer 
> might want a line break. So he should be able to set a line break 
> property on that break. Another designer doesn't like line breaks. So 
> let her set the break to be generated as a green, medium-sized dot.

I disagree. Here the break is purely presentational and has nothing to do 
with the semantic of the information.


> Second example:
> <p><label>Name: <input name="name"></label><br>
> <label>Address: <input name="address"></label></p>
> 
> Although I also prefer the version without the br element, I must say 
> that a form is the one element where presentational markup does make 
> sense.

But <br> is not presentational.


> By its very nature a form has an explicit design, otherwise it would be 
> called free-form. Granted, in web design there usually isn't and 
> probably shouldn't be such a strong form character as in paper-based 
> forms.

I do not agree with the premise of this argument.


> So, in summary, I suggest changing the br element to just be a logical 
> break element with the default rendition of a line break, but which 
> could be adjusted via a new style property.

That's already what it is. I've added a note to make this clearer.


On Thu, 5 Aug 2010, Thomas Koetter wrote:
> 
> 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."

That's what it represents, but it's still not legal.


On Thu, 5 Aug 2010, Kit Grose wrote:
>
> I do see an advantage to permitting the arbitrary styling of the BR 
> element.
> 
> Often a series of links shown inline are separated by a pipe (|) 
> character. In the past I've produced this effect using border-right and 
> other such malarky on the anchors or inline LIs with the same, but I 
> think semantically the symbol does indeed represent a break between the 
> links and that having the ability to style the break accordingly would 
> be terrific.

   br { content: '|'; }

...is the way to do that, once we've got CSS3 Generated Content done.


On Fri, 6 Aug 2010, Aryeh Gregor wrote:
> 
> The address
> 
> 123 Imaginary Place
> New York, NY 12345
> 
> is not the same as
> 
> 123 Imaginary Place New
> York, NY 12345

That's a good example of line breaks not being presentational!


On Mon, 9 Aug 2010, Thomas Koetter wrote:
>
> 123 Imaginary Place       New York, NY 12345
> 
> 123 Imaginary Place | New York, NY 12345
> 
> 123 Imaginary Place * New York, NY 12345

Indeed, those are all fine renderings of the same markup.


> Street number: 123
> Street: Imaginary Place
> City: New York
> State: NY
> Zip code: 12345

It's the same underlying data, but it's not the same content, IMHO.


On Thu, 5 Aug 2010, Ryosuke Niwa wrote:
> 
> That's totally incorrect in HTML5 as Thomas has pointed out.  Let me ask 
> you a question.  What do you suppose non-visual user agent should do 
> when they encounter br?  Simply ignore them because it only signifies a 
> line break? Or read out that there's a line break?  Neither seems user 
> friendly to me. If anything, a momentary pause will be appropriate 
> because what's what we usually do when reading a book and a line break 
> appears.  This clearly isn't *line break*.

Sounds like a line break to me. :-) Would you say a pause between runs of 
text is not a paragraph break, because there's no block of text when 
reading a book?


On Mon, 9 Aug 2010, Thomas Koetter wrote:
> 
> You're right that screen readers cannot convey line breaks in a manner 
> suitable to the medium. Line breaks do not exist in speech.

I don't know about _that_. It's easy to read poetry in a way that clearly 
has line breaks. (It's not necessarily a good way to read poetry, but 
that's besides the point.)


On Thu, 5 Aug 2010, Bryce Fields wrote:
>
> Why not just list <br> along with the other obsolete elements instead of 
> trying to rebrand it semantically?  Let's face it.  <br> is a pain to 
> try to rationalize as a purely semantic element and any use you have for 
> the element could probably easily be accomplished w/ other semantic 
> code.  Why not just call it obsolete and discourage authors and vendors 
> from using it?

Well, there are a few use cases (like addresses and some poems) where <br> 
is appropriate but where the underlying data is not preformatted text (so 
<pre> isn't suitable).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'