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/
