- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 10 Jan 2012 23:49:14 +0000 (UTC)
On Tue, 14 Jun 2011, Markus Ernst wrote:
> Am 14.06.2011 09:32 schrieb Ian Hickson:
> > 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?
>
> It solves the first use case Jukka mentioned in his original post:
>
> Am 10.03.2011 09:20 schrieb Jukka K. Korpela:
> > 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. Under these circumstances, what should we say to people to need
> > to use paragraphs that contain lists, for example?
I would respectfully suggest that this isn't a real problem.
On Tue, 14 Jun 2011, Tab Atkins Jr. wrote:
> >
> > It solves the first use case Jukka mentioned in his original post:
>
> So does Hixie's answer of "Tell them to use two <p>s and a <ul>". His
> answer has the benefit of not requiring any changes to HTML, and not
> introducing a fourth type of list that is only very subtly different
> from <ul>.
Indeed.
On Wed, 15 Jun 2011, Markus Ernst wrote:
>
> This results in:
>
> <div class="p">
> <p>I always like to eat these cheeses:</p>
> <ul>
> <li>Cheddar</li>,
> <li>Stilton</li>, and
> <li>Red Lester</li>,
> </ul>
> <p>but I enjoy them most with one of these biscuits:</p>
> <ul>
> <li>wheat crackers</li>,
> <li>rye crackers</li>,
> <li>digestives</li>,
> </ul>
> <p>and some chutney.</p>
> </div>
>
> I don't like this, because it is a hackish workaround for a quite basic
> problem.
I don't understand what the hack is here. It looks fine to me.
> Lots of HTML is actually authored by non-programmers using online rich
> text editors - both the editor softwares and their users will be quite
> hard to teach about using such constructs. I strongly assume that the
> following kind of solution is more likely to occur:
>
> <p style="margin-bottom:0">I always like to eat these cheeses:</p>
> <ul style="margin:0">
> <li>Cheddar</li>,
> <li>Stilton</li>, and
> <li>Red Lester</li>,
> </ul>
> <p style="margin:0">but I enjoy them most with one of these biscuits:</p>
> <ul style="margin:0">
> <li>wheat crackers</li>,
> <li>rye crackers</li>,
> <li>digestives</li>,
> </ul>
> <p style="margin-top:0">and some chutney.</p>
I'd encourage classes rather than inline styles, but if the page really
does have lists like this that don't have margins while also having lists
that do have margins, then yes, that would be the way to do it. What's the
problem here?
> The main issue here is the fact that you can't just apply styling to the
> list element, but have to apply it to the surrounding <p>s, too. Inline
> lists would make this kind of things definitely easier and better.
I don't see why. Seems like semantic hair-splitting to me. You can do the
styling for this fine using just CSS today (and it'll be even easier in
the future with new forward-looking selectors), no need for complicated
markup with lists inside paragraphs, etc.
> Of course I understand the benefit of not requiring any changes to HTML,
> but actually the HTML5 process is about making changes to HTML.
Only for the changes that are worth it.
> I don't have a big problem with using this kind of markup either, but
> the same applies for using <div>s instead of <article>s and <section>s.
The difference is that there's real gains to using <section> and
<article>, far beyond just semantic purity. (e.g. automatic outlines,
easier document maintenance in the face of significant edits, enabling
automated syndication, etc.)
On Tue, 14 Jun 2011, Andy Mabbett wrote:
> On 14 June 2011 08:32, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 10 Mar 2011, Jukka K. Korpela wrote:
> >>
> >> 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.
>
> I think that's an opinion, not a fact.
It's a fact, given the definition of "paragraph" that the spec uses.
(Actually, I should have said that it's four paragraphs, two of which are
part of a bulleted list.)
> > Indeed, but "block of text" is pretty much what a paragraph is -- it
> > isn't a logical construct.
>
> Cite?
http://www.whatwg.org/specs/web-apps/current-work/#paragraph
> The Oxford English Dictionary would seem to disagree with you:
>
> A distinct passage or section of a text, usually composed
> of several sentences, dealing with a particular point, a short
> episode in a narrative, a single piece of direct speech, etc.
The Oxford English Dictionary isn't normative here. The HTML spec is.
Other dictionaries give definitions closer to HTML's, by the way; e.g. the
New Oxford American Dictionary says:
paragraph. n. a distinct section of a piece of writing, usually dealing
with a single theme and indicated by a new line, indentation, or
numbering.
Note the explicit reference to the presentational aspect.
I didn't use this definition in the spec because of its use of the word
"section" which I felt would confuse matters further.
> > 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.
>
> My view is that that's one paragraph, with line breaks.
It's three paragraphs by the definition in the spec.
> Consider:
>
> I like apples, pears, grapes, but not bananas. Nor do I like peaches.
>
> and:
>
> I like
> * apples
> * pears
> * grapes
> but not bananas. Nor do I like peaches.
>
> The difference between those two is presentational, not semantic. Each
> is a single paragraph.
Consider the same information conveyed in French, or using pictograms on
etched into a cathedral ceiling, or by a mime's dance, or by telepathic
thought exchange. The different is again merely presentational, but I
assume you wouldn't argue that, say, a mime's dance is a paragraph, or
that a cathedral ceiling is a paragraph.
The concept of a paragraph, at least as the word is used in defining the
<p> element, is inherently about how the semantic is structured. It's not
a medium-specific presentational element, in that the structure can be
conveyed in different media (e.g. with each bullet in the bulleted list
above rendered with an audio icon "bing"), but it is also not "semantic"
in the sense of just being about the conceptual meaning.
On Wed, 15 Jun 2011, Jukka K. Korpela wrote:
>
> The word "paragraph" is ambiguous, as he current wording says indirectly
> but clearly: It defines "The p element represents a paragraph", but the
> word "paragraph" links to the following:
>
> "The term paragraph as defined in this section is distinct from (though
> related to) the p element defined later. The paragraph concept defined
> here is used to describe how to interpret documents.
Right, a <p> element is one way to mark up a paragraph, but not the only
way. For example, there are three paragraphs here, not one:
<div>
<p> first </p>
second
<div> third </div>
</div>
> So it says that p is a paragraph, linking to an explanation that says
> paragraph is different from p. The explanation mentions "the term
> paragraph as defined in this section", but it does not give a definition
> - a sentence that begins with "A paragraph is typically" is a prelude to
> a definition, not a definition.
The definition is several more paragraphs down from where you were
reading.
> I gather that "The p element represents a paragraph" more or less means "the p
> element denotes a block of text". Can you make this more explicit, please?
I don't understand what you want to have made more explicit. What
implementation question does the spec not answer here?
> The p element represents a block of text so that consecutive p elements are
> regarded as topically distinct.
I don't understand what you mean by "topically distinct".
> > > 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>
>
> But if this follows, for example, a table, then extra measures would be needed
> to create vertical spacing.
That's what "can be styled as one" is all about, yes. You'd put your
margins on <div>s instead of <p>s.
> Using the p element would make the spacing the default.
Given how few people use the default at this point, I don't think that's
much of an issue. But yes, that is a historical advantage of <p> (at least
for those who want spacing between paragraphs).
> Similarly for spacing after this construct. So it would be more robust
> to use <p>...</p> markup here.
It wouldn't be any more robust, no. It would have a trivial difference in
presentation in very old legacy browsers or when CSS is disabled. But
there's not much we can do about that; even if we introduced some new way
of marking this us, we'd still not handle legacy UAs since they would
still not have the new defaults.
> I don't think anonymous blocks of text are a good idea. There was a reason why
> they were frowned upon in HTML 4.01.
What is the reason?
I would definitely not asume that decisions made for HTML4 still apply.
> So I hope an example like the above but with <p>...</p> markup can be
> added, to answer the common question (which is often formulated in terms
> of a "list header", but it's really about something that starts as a
> paragraph and then moves to listing things down as a bulleted list).
I've added a note to the spec regarding lists in paragraphs.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 January 2012 15:49:14 UTC