[whatwg] Interpretation issue: can <section> be used for "extended paragraphs"?

[Ian Hickson]

On Thu, 10 Mar 2011, Jukka K. Korpela wrote:
>
> The <p> element (ever since it became an element) has always allowed 
> inline (text-level) content only, and no change is planned to this in 
> HTML5.

Actually a change was planned, and executed, early on in the development 
of HTML5. It had to be reverted for various reasons, a long time before we 
dropped the "5", even. One of the reasons was that it wasn't necessary.


> Under these circumstances, what should we say to people to need to use 
> paragraphs that contain lists, for example?

That paragraphs don't contain lists; when a sentence has
 * this
 * structure,
...it is in fact two paragraphs and a bullet list.


> A paragraph, in the old typographic sense, may contain lists.

That is a somewhat debatable point, but luckily it is also somewhat 
orthogonal to the real issues you raise.


> A sentence in the text may continue with list items, displayed e.g. as a 
> bulleted list. So the list breaks the paragraph as a block of text but 
> not logically - the list items are part of the sentence just as they 
> would be if they were just mentioned in the text, for example using 1) 
> numbers in the text, 2) letters in the text, or 3) no special notation.

Indeed, but "block of text" is pretty much what a paragraph is -- it isn't 
a logical construct. It's quite possible, if rare, for a sentence to span 
paragraphs even without lists being involved... Take, for instance, the 
first...

...no, the second...

...no, the third, of these blocks of text. That sentence spans three 
paragraphs. That's not a problem, IMHO.


> The HTML(5) paragraph concept is different, so in HTML terms, such a paragraph
> would need to consist of a P element followed by a UL (or OL) element.

Indeed.


> There is an apparent need for indicating in markup that the two belong 
> to together,

We need more than an apparent need, we need a concrete real need, before 
we add a feature.


> a) for styling purposes (you need a container element so that you can 
> specify, without clumsily using classes on both the P and the UL, e.g. 
> that vertical spacing be reduced or zero)

<div> handles this case:

   <div>This sentence
    <ol>
     <li>contains
     <li>a list
    </ol>
   ...and is made of four paragraphs but can be styled as one since the 
   <div> element is used instead of <p>.</div>

Note that the semantics turn out the same as if you'd used <p>s in there 
as well, as in:

   <div><p>This sentence</p>
    <ol>
     <li><p>contains</p>
     <li><p>a list</p>
    </ol>
   <p>...and is made of four paragraphs but can be styled as one since the 
   <div> element is used instead of <p>.</p></div>

...because of the definition of "paragraph" in HTML now.


> b) to ease handling in scripts

Could you give a concrete example of why scripts would need to manipulate 
paragraphs in this way?


> c) to act as documentation in the source code, warning future editors of 
> the document that neither the P element nor the UL element should be 
> edited in isolation but only considering the other part as well.

Isn't that pretty obvious from the fact that the sentence spans multiple 
elements? I mean, if an editor is ignoring the very prose that they are 
editing, I don't think any amount of markup can really save them.


> There are less apparent needs, or possibilities, too - e.g.,
> 1) to communicate to any interested software that the elements are 
> coupled, treating occurrences of a word as occurring in the same 
> "extended paragraph" for the purposes of indexing, searching, etc.,

Can you give a concrete example of this?


> 2) to tell a grammar checker that the P element just _appears_ to end 
> abruptly),

A grammar checker, much like a human, would presumably operate on the text 
itself and could therefore easily detect that the sentence spanned 
multiple elements (or at least, as easily as if the sentence used 
phrasing elements in the same places).


> 3) to inform editing software that e.g. triple-clicking the paragraph, 
> for the purpose of moving it elsewhere, should also select the UL 
> element.

It's not clear that this is desireable, but if it is, then <div> with a 
class specific to the editor would be able to handle this case, as far as 
I can tell. It's hard to know without more specifics.


> I guess some of these needs, especially the most practical (in a sense) 
> styling issue, could be addressed by simply putting the P and UL 
> elements inside a SECTION element:

That would be abuse of <section> semantics, but it's the right idea. Just 
use <div> instead.


> Should this even be mentioned, descriptively, as a common use case, or 
> as an example of inappropriate use, depending on the position that will 
> be taken?

If it's something that's actually important, I'm happy to mention the 
<div> trick. Let me know if you think that would help.


On Thu, 10 Mar 2011, Andy Mabbett wrote:
>
> Consider a more complex scenario:
> 
> <p>I always like to eat these cheeses:</p>
> <ul>
>  <li>Cheddar
>  <li>Stilton
>  <li>Red Lester
> </ul>
> <p>but I enjoy them most with one of these biscuits:</p>
> <ul>
>  <li>wheat crackers
>  <li>rye crackers
>  <li>digestives
> </ul>
> <p>and some chutney.</p>
> 
> What I would like to be able to do is:
> 
> <p>I always like to eat these cheeses:
> <ul>
>  <li>Cheddar
>  <li>Stilton
>  <li>Red Lester
> </ul>
> but I enjoy them most with one of these biscuits:
> <ul>
>  <li>wheat crackers
>  <li>rye crackers
>  <li>digestives
> </ul>
> and some chutney.</p>
> 
> Now I'm hungry :-(

Just replace the <p></p> with <div></div> and it works today.


On Thu, 10 Mar 2011, Markus Ernst wrote:
> 
> I was annoyed by the exact same issue several times, too. Anyway it 
> looks to me that this problem raised by Jukka Korpela applies mainly to 
> the three list-type elements ol, ul and dl.
> 
> Would it cause serious issues to add the Phrasing Content category to 
> these three elements, thus allowing them inside the p element?

Yeah, it breaks the parsing in text/html.


On Fri, 11 Mar 2011, Markus Ernst wrote:
> 
> Instead of a new paragraph concept, there could also be a new concept 
> for inline (resp. Phrasing Content) lists. The concept is actually not 
> too new - for quotes, e.g., we've had both block level <blockquote> and 
> an inline level <q> elements for long. Why not the same for lists? 
> Consider this markup of Andy's use case:
> 
> <p>I always like to eat these cheeses:
> <il>
>  <ili>Cheddar</ili>,
>  <ili>Stilton</ili>, and
>  <ili>Red Lester</ili>,
> </il>
> but I enjoy them most with one of these biscuits:
> <il>
>  <ili>wheat crackers</ili>,
>  <ili>rye crackers</ili>,
>  <ili>digestives</ili>,
> </il>
> and some chutney.</p>
> 
> <il> stands for "inline list", <ili> for "inline list item" (it's a pity 
> we can't reuse <li> for BC reasons). Conforming UAs would be required to 
> ignore any content in an <il> element, except it is in an <ili> element. 
> Like that, the above example would be perfectly readable in legacy UAs, 
> but make sense in HTML5-capable UAs.
> 
> It would even be easy to stlye the output for legacy UAs supporting 
> display:list-item, as this example illustrates: 
> http://www.markusernst.ch/stuff_for_the_world/list-test.html

What problem does this solve?


On Tue, 15 Mar 2011, Martin Alterisio wrote:
> 
> The problem here lies not on the list elements but rather on the 
> paragraph. Consider the use cases where, instead of a list, the 
> paragraph is split by a <table>, <blockquote> or <pre>.
> 
> Semantically speaking, what is happening is that the paragraph is being 
> interrupted by some other kind of information. An UA that is smart 
> enough can imply this occurrence by the usage of the colon at the end of 
> the paragraph. Those UAs can take into account these use cases and build 
> a better outline for the document.
> 
> Even though in the semantic structure of the document the 
> list/table/quote/etc happens to be inside the paragraph, in the physical 
> structure of the document the list/table/quote/etc is not inside the 
> paragraph. Take into consideration how we write: we use the colon as a 
> full stop pause, introduce the in-between element leaving a space, then 
> resume the paragraph leaving another space after the in-between element.

Indeed.


> PS: This is my first message to the list

Welcome!

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