Re: Using <p> elements purely as containers of phrasing elements? Semantic or not?

2013-05-08 20:41, Xaxio Brandish wrote:
> Just to clarify -- the /p/ element is separating the phrasing content 
> in the *specific* example you pointed out, rather than grouping it.  
> After all, the radio buttons in the example are related.  Most of the 
> time, the /p/ element should be used for grouping, not separation.

All grouping means separation: by making something a group, you separate 
it from other groups and other content in general. But such issues are 
rather irrelevant here. No software used for processing HTML documents 
will try and read the author's mind, trying to distinguish between 
"grouping" and "separation". And it is really such software that we use 
tags for, not for ourselves, or even for our fellow humans directly, 
only via the processing, if any, made by software.

This example, at
http://www.w3.org/html/wg/drafts/html/master/forms.html#writing-a-form%27s-user-interface
is rather typical and common. For normal rendering, and for 
accessibility, you want each pair of a radio button and a label to 
appear on a line of its own. This is the real need, as opposite to 
pointless and endless arguments about "semantics".

There are many ways to achieve the goal. The simplest, in a sense, is 
<br>, but such usage is frowned upon in HTML5 drafts, and it isn't 
really a good approach because it does not make the pair an element (so 
you cannot conveniently refer to it as a unit in styling and scripting). 
Other options include <div>, <p>, <ul> with <li> (which some people 
might favor, as they see <ul> as a generic "list" construct that must be 
used for anything that could be seen as a list, as opposite to really 
being a bulleted list), and <table> (which is very suitable for some 
purposes, though you might need to make a complicated scholastic 
argument to prove that it is "tabular data" if your boss is an HTML 
Semanticist).

Among these, <p> is definitely possible, but inferior to <div>, since 
<p> implies empty lines (and possibly pauses in speech) in default 
rendering. We can make presentational suggestions in CSS, but why would 
we deliberately use markup that makes the non-CSS rendering awkward, 
when there is a simple alternative?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Thursday, 9 May 2013 04:31:17 UTC