Disclaimer: I'm new to this discussion list, so please excuse me if this topic 
has been discussed before. A quick search didn't turn up anything though.


Currently, I'm writing a book on web programming and I stumbled over the 
specification of the br element for HTML5.
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-br-element
 

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.


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

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

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

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. 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. Just like in a musical score where 
the bar is present in sheet music but not in the actual music being played.

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.

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


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.

I would love to hear your thoughts.

-- 
Thomas Koetter



Reply via email to