W3C home > Mailing lists > Public > public-html-comments@w3.org > May 2013

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

From: Xaxio Brandish <xaxiobrandish@gmail.com>
Date: Wed, 8 May 2013 03:41:46 -0700
Message-ID: <CABAoKZkyS45ixWd1zpk3=L01Znko4HGR2r-KL1K5-cy3DxZBTA@mail.gmail.com>
To: Ian Yang <ian@invigoreight.com>
Cc: public-html-comments@w3.org
Ian,

In your example, the text after the *input* element could simply exist
without the surrounding paragraph tags.  However, I agree that using
paragraph elements to thematically group form controls and sections is an
odd decision.  Let's try to trace it back.

HTML 5.1 [1] states that:

Each part of a form is considered a
paragraph<http://www.w3.org/html/wg/drafts/html/master/dom.html#paragraph>,
> and is typically separated from other parts using p<http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-p-element>elements.
>

Note that "part" in the above statement is not well-defined.  The section
is non-normative, but it is the only guide we have for why <p> would be
used to separate "parts" of a form.  Fieldsets are often part of a form,
but since fieldsets are not considered "phrasing content", they cannot be
paragraphs -- they can only contain paragraphs.  A paragraph is defined as
a "run" of phrasing content, but at no point is there a clear definition of
what "run" means in this case.  If a run is a continuous section of
phrasing content, meaning content that is not broken up by content other
than phrasing content, then "each part" in the above statement could *only*
refer to the entire form if it does not contain one of the following
elements (the list of flow content minus the list of phrasing content):

address
article
aside
blockquote
details
dialog
div
dl
fieldset
figure
footer
form
h1
h2
h3
h4
h5
h6
header
hr
main
menu
nav
ol
p
pre
section
style (if the scoped attribute is present)
table
ul

In HTML 4.01 [2], the examples given have the entire form content wrapped
in a paragraph element, which would seem to jive with the above
postulation.  Note that the *p* element is NOT allowed to contain flow
content in HTML 5.1, so it cannot contain a fieldset as some examples in
HTML 4.01 do.

HTML 3.0 [3] states that:

Forms are created by placing input fields within paragraphs, preformatted
> text, lists and tables. This gives considerable flexibility in designing
> the layout of forms.
>

Ah ha! We can infer from this that the original purpose of using the
paragraph element in a form is for layout purposes, which is now in the
domain of CSS.

HTML 2.0 [4] states that:

...a *FORM* element<http://www.w3.org/MarkUp/html-spec/html-spec_2.html#GLOSS13>
> may <http://www.w3.org/MarkUp/html-spec/html-spec_2.html#GLOSS21> contain
> lists which contain *INPUT* elements. This gives considerable flexibility
> in designing the layout of forms.
>

Verified.  An example given in HTML 2.0 [5] uses both paragraph elements
and list elements to help with form design.

So there you have it.  The reason paragraph elements are used in forms goes
back to being a design element.  However, we now have CSS that clearly
specifies how design applies to content, so it is no longer necessary to
use explicit *p* elements around related parts of a form when a
*label*element will suffice.  Over time, the paragraph element has
taken on a
different meaning.  This means that the *p* elements in the examples
located at the link you gave [6] serve no purpose as they are used in those
examples.  The *label* element alone would suffice.  The *p* tags do not
serve to group thematically related content in the examples -- in fact,
they actually separate it.

Knowing what we do, using the *p* tag for a paragraph element will only
break up runs of phrasing content into separate paragraphs.  It *may* not
be the best element to use for styling when it is necessary to contain
certain other elements, as is often the case with forms.  There is no way
to know what a form "part" is; the author must decide what a form "part" is
for his or herself.  To solve the dilemma of wanting to use a paragraph tag
as a textual semantic instead of a structural element, you can use one of
the tags in the list above that accept flow content as a grouping mechanism
for related fields and form data instead, such as *fieldset*, *div*, or *
section*; each of these can contain *p* elements.

References:
[1]
http://www.w3.org/html/wg/drafts/html/master/forms.html#writing-a-form%27s-user-interface
[2] http://www.w3.org/TR/html401/interact/forms.html#idx-label
[3] http://www.w3.org/MarkUp/html3/forms.html
[4] http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8
[5] http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.3
[6] http://www.w3.org/TR/html5/forms.html#the-fieldset-element

--Xaxio


On Tue, May 7, 2013 at 4:16 AM, Ian Yang <ian@invigoreight.com> wrote:

> There is another concern which makes me rethink whether <p> element is
> really an ideal choice for thematically grouping form controls.
>
> Sometimes we may want to put a paragraph of text after an <input>
> element to describe something. However, using <p> element to group
> form controls doesn't allow us to do that because <p> elements cannot
> wrap <p> elements. Like the following invalid example.
>
> <p>
>     <label for="name">
>     <input id="name" type="text">
>     <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
> Maecenas laoreet imperdiet diam, in sodales velit porta eget. Ut
> tellus urna, vestibulum vel facilisis eu, blandit sed est.</p>
> </p>
>
> And it's possible that form validation javascript functions insert
> error messages (<p>) after form controls. If <p> elements is the
> container, CSS issues might occur because the <p> element (container)
> contains <p> element (error messages).
>
> Base on the above considerations, it's worth rethinking if using <p>
> element for thematically grouping for form controls is a correct
> approach.
>
>
> Kind Regards,
> Ian Yang
>
>
Received on Wednesday, 8 May 2013 10:42:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:23 UTC