W3C home > Mailing lists > Public > public-html@w3.org > October 2010

Re: ISSUE-128 (figure-in-p): Chairs Solicit Proposals

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 5 Oct 2010 16:30:07 +0000 (UTC)
To: Henri Sivonen <hsivonen@iki.fi>
cc: Sam Ruby <rubys@intertwingly.net>, HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1010051617220.8618@ps20323.dreamhostps.com>
On Tue, 5 Oct 2010, Henri Sivonen wrote:
> 
> The current draft of the Change Proposal is at
> http://www.w3.org/html/wg/wiki/ChangeProposals/FigureInP

I volunteer to write a counter-proposal, the first draft of which is 
below. I welcome feedback both from people who agree with this position, 
and wish to make the arguments presented below stronger, and from people 
who disagree with this position, and who can explain why I am wrong.


SUMMARY
=======

It is argued that <figure> is equivalent to <p> or <aside> and should
be treated as such, including being consistent in parsing.


RATIONALE
=========

It is important to separate the issue of the content model of <figure>
from its parsing rules and from desired renderings. They are related
only insofar as the parsing rules are a function of the content model;
allowing desires regarding the parsing rules to affect the content
model can lead to nonsensical content model rules, and insofar as the
rendering languages should evolve to take care of common content
models.


CONTENT MODEL

With that in mind, let's examine the content model of <figure>.

Here is a typical use of <figure>:

   <p>The <img src="logos/intel.png" alt="Intel"> quarterly results
   were announced today, showing fantastic growth in the chip
   market:</p>
   <figure>
    <img src="reports/intel-q3.png" alt="Q3 chip sales this year were
    double the figures for Q3 and were four times the same figures
    from a year ago.">
    <figcaption>
     Sales figures for Intel showing chip sales in Q3 last year and Q2
     and Q3 this year.
    </figcaption>
   </figure>
   <p>Competitor <img src="logos/amd.png" alt="AMD"> will announce
   their results tomorrow.</p>

Without <figure>, one would write this as follows:

   <p>The <img src="logos/intel.png" alt="Intel"> quarterly results
   were announced today, showing fantastic growth in the chip
   market:</p>
   <div class="figure">
    <img src="reports/intel-q3.png" alt="Q3 chip sales this year were
    double the figures for Q3 and were four times the same figures
    from a year ago.">
    <p>
     Sales figures for Intel showing chip sales in Q3 last year and Q2
     and Q3 this year.
    </p>
   </div>
   <p>Competitor <img src="logos/amd.png" alt="AMD"> will announce
   their results tomorrow.</p>

This is the style used, for instance, on [1].


Here is another example:

   <p>The table in Figure 1 shows the tensile strength of materials as
   found in this experiment.</p>
   <figure>
    <figcaption> Table 1. </figcaption>
    <table>
     ...
    </table>
   </figure>
   <p>In general, we found that iron was the strongest of the tested
   materials.</p>

Here are some other ways to mark this up:

   <p>The table in Figure 1 shows the tensile strength of materials as
   found in this experiment.</p>
   <table>
    <caption> Table 1. </caption>
    ...
   </table>
   <p>In general, we found that iron was the strongest of the tested
   materials.</p>

   <p>The table in Figure 1 shows the tensile strength of materials as
   found in this experiment.</p>
   <aside>
    <h1> Table 1. </h1>
    <table>
     ...
    </table>
   </aside>
   <p>In general, we found that iron was the strongest of the tested
   materials.</p>


Here's a third example of <figure>, showing a figure explicitly taken
out of the flow of the page (text of this example from Wikinews):

   <h1>China launches Chang'e 2 lunar probe</h1>
   <figure>
    <img src="Chang%27e_2_satellite.jpg" alt="Change'e 2 has the
    appearance of a gold cube covered with white panels and antennas,
    with two rectangular flat blue wings extending to either side.">
    <figcaption>
     <p>China's second unmanned lunar orbiter (pictured) launched on
     Friday from the Sichuan province.</p>
     <p>Image: Spacebabe.</p>
    </figcaption>
   </figure>
   <p>China launched its second unmanned lunar exploration probe,
   Chang'e 2, on Friday from the province of Sichuan.</p>
   <p>Chang'e 2 is part of a Chinese initiative to test skills and
   technology that could lead to unmanned landings in the future. The
   head of the orbiter's design team was quoted by Xinhua as saying:
   "Chang'e 2 lays foundation for the soft-landing on the moon and
   further exploration of outer space. It (will) travel faster and
   closer to the moon, and it will capture clear pictures."</p>


These examples are representative of how <figure> is used: as an
element on par with <aside>, <p>, <div>, and other flow content
elements that are not phrasing content elements. <figure> is a
paragraph-like concept; people take it out of the flow, they have it
between paragraphs, and so forth.

What people do _not_ do with figures is put them in the middle of
sentences. That's the kind of thing that elements of phrasing content
(and embedded content, a subset of phrasing content) are for. 

For instance, take the first paragraph of the first example above:

   <p>The <img src="logos/intel.png" alt="Intel"> quarterly results
   were announced today, showing fantastic growth in the chip
   market:</p>

Here we see a phrasing content (and embedded content) element, <img>,
being used in a sentence. It would make no sense to replace this with
a figure -- it's part of the sentence.

If we made <figure> a phrasing-content element, then it would imply
that it makes sense to wrap <figure> in other phrasing-content
elements, such as <em>, <dfn>, or <b>. However, in practice such cases
would almost certainly be unintended authoring errors. One does not
put stress emphasis on a whole figure; one does not have a defining
instance of a figure, a figure is not as a whole a keyword.

On the contrary, we should use the content model rules to make
conformance checkers flag these mistakes to the author, by only
allowing <figure> where it makes sense: as a paragraph-like construct,
not as a text-like construct.


PARSING

Having established that <figure> is a flow-level element, not a
phrasing-level element, it remains only to see whether it makes sense
to require the </p> between a paragraph and a figure. Look at the
first of the examples above again:

   <p>The <img src="logos/intel.png" alt="Intel"> quarterly results
   were announced today, showing fantastic growth in the chip
   market:</p>
   <figure>
    <img src="reports/intel-q3.png" alt="Q3 chip sales this year were
    [...]

The <p> element is said to have an optional end tag, but if we omitted
the </p> in this case and yet did not have <figure> imply </p>, we
would be making the author write non-conforming content:

   <p>The <img src="logos/intel.png" alt="Intel"> quarterly results
   were announced today, showing fantastic growth in the chip
   market:<figure><img src="reports/intel-q3.png" alt="Q3 chip [...]

Instead we should clearly here have the <figure> imply the </p>:

   <p>The <img src="logos/intel.png" alt="Intel"> quarterly results
   were announced today, showing fantastic growth in the chip
   market:
   <figure>
    <img src="reports/intel-q3.png" alt="Q3 chip sales this year were
    [...]

This is just like how <table> and <aside> imply </p>:

   <p>The table in Figure 1 shows the tensile strength of materials as
   found in this experiment.
   <figure>
    <figcaption> Table 1. </figcaption>
    [...]

   <p>The table in Figure 1 shows the tensile strength of materials as
   found in this experiment.
   <table>
    <caption> Table 1. </caption>
    [...]

   <p>The table in Figure 1 shows the tensile strength of materials as
   found in this experiment.
   <aside>
    <h1> Table 1. </h1>
    [...]

These should clearly all work the same, as they are semantically very
similar.


RENDERING

Having examined the content model and the parsing rules, one comes to
the final topic, rendering.

This is not usually something we should consider, but sometimes it is
worth looking at what rendering effects people want, just to make sure
things are possible even while we wait for CSS to catch up to the
latest needs of HTML.

In this particular case, the need that is most commonly mentioned is
the desire to align the top of a figure with the top of a paragraph.
For example, in the Wikinews example above:

   <h1>China launches Chang'e 2 lunar probe</h1>
   <figure>
    [...]
   </figure>
   <p>China launched its second unmanned lunar exploration probe,
   Chang'e 2, on Friday from the province of Sichuan.</p>
   [...]

If the effect we desire is this:

   China launches Chang'e 2 lunar probe

   +---------+  China launched its second
   |         |  unmanned lunar exploration probe,
   | [...]   |  Chang'e 2, on Friday from the
   |         |  province of Sichuan.
   +---------+  [...]

There are two margins of interest here; the margin-bottom of the <h1>
and the margin-top of the <p>. If they are equal, or indeed if the
<h1> margin is greater than the <p> margin, then the figure and the
paragraph will align without issue.

In the rare case where the paragraph's margin-top is intentionally
greater than the margin-bottom of the element before it, one runs
afoul of the margin-collapsing rules for self-collapsing blocks
implied by floats or positioned content between collapsing margins,
and a minor adjustment to the markup is needed to make the alignment
work again:

   <h1>China launches Chang'e 2 lunar probe</h1>
   <div>
    <figure>
     [...]
    </figure>
    <p>China launched its second unmanned lunar exploration probe,
    Chang'e 2, on Friday from the province of Sichuan.</p>
    [...]

Thus, one can conclude that styling of figures is already
well-supported.



DETAILS
=======

Change nothing.


POSITIVE EFFECTS
================

* <p>...<figure> will parse in a manner consistent with <p>...<div>,
  which is the markup used today for the same effect.

* Errors such as <em><figure>...</figure></em> will be caught and
  reported by conformance checkers.

* Already implemented in multiple browsers and a conformance checker.


NEGATIVE EFFECTS
================

None.


CONFORMANCE CLASS CHANGES
=========================

None.


RISKS
=====

None.


REFERENCES
==========

[1] http://hsivonen.iki.fi/cms/te/

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 5 October 2010 16:30:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:15 GMT