W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Should a <figure> element require a reference? (was: use cases for <figure> without <figcaption>?)

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Mon, 24 Jun 2013 10:17:37 +0100
Message-ID: <CA+ri+VksYZHawTEWrFjEOM8adSxHpEPOvR+hCMZkEu7r6oqovA@mail.gmail.com>
To: Xaxio Brandish <xaxiobrandish@gmail.com>
Cc: whatwg <whatwg@lists.whatwg.org>
Hi Xaxio


On 21 June 2013 15:59, Xaxio Brandish <xaxiobrandish@gmail.com> wrote:
>
Steve,
>
> Please permit me to change the subject line since the topic no longer
> answers the subject question?
>

>


thanks!


>
> The next sentence in the WHATWG spec [1] states
>
> The element can thus be used to annotate illustrations, diagrams, photos,
>> code listings, etc, that are *referred to from the main content of the
>> document*
>>
> (italics mine)
>
> It's true that there is no text saying that the <figure> element MUST be
> used a certain way, but there are two sentences saying how it "typically"
> or "can" be used, both implying a reference from a document.
>

>

OK so 'typically' infers that <figure> is used in this way, from a recent
review of data (June 2013 data set from http://webdevdata.org) on usage of
<figure> it appears that it is typically not used in this way by authors.
There are typically no explicit references to figure content.

 Here are some examples of pages using figure/figcaption. (also appears
that figure is often used without figcaption: figcaption instances in
sample of 53000 pages = 4603 , figure usage = 14609, indicating approx 1 in
3 uses of figure includes a figcaption)


   - Mirror Online <http://www.mirror.co.uk/news/>
   - Christian News on Christian Today <http://www.christiantoday.com/>
   - Infonews <http://www.infonews.com/>
   - Peru.com,  <http://peru.com/>
   - Computer Arts magazine <http://www.computerarts.co.uk/>
   -  Elle <http://www.elle.it/>
   - NASCAR.com <http://www.nascar.com/en_us/sprint-cup-series.html>
   - Indiatimes: <http://www.indiatimes.com/>
   - Bollywood Mantra <http://www.bollywoodmantra.com/>
   - Teen Vogue <http://teenvogue.com/>
   - Irish Independent <http://www.independent.ie/>
   - bitbucket <https://bitbucket.org/>
   - HELLO! Online <http://www.hellomagazine.com/>
   - Mobile App Tracking <http://mobileapptracking.com/>
   - Consumer Complaint
Database<http://www.consumerfinance.gov/complaintdatabase/>
   - AS.com <http://as.com/>



> One part of the ambiguity in the WHATWG spec comes from the examples given:
>
> 1) The first example uses <figure> as referenced from a document.
> 2) The second example is not referenced from a document.
> 3) The third example shows an image that is not a figure, followed by two
> pieces of media content that are within <figure> tags.  The non-figure
> image could not be removed from its position in the document flow without
> changing the meaning of the document, so it is not used as a <figure>
> element.
> 4) The fourth example is not referenced from a document.
> 5) The final two examples are implied to be referenced from a document,
> and are semantically equivalent.
>
> Since we cannot know the surrounding document for examples 2 and 4, it
> seems that those examples take advantage of the open-ended adaptability of
> the unreferenced version of the <figure> element.
>

agree that current examples are lacking and do not serve to illustrate
intended use of figure/figcaption


>
> Part of the semantics of HTML come from *author intent* and *reasonable
> expectation*.  If we see a <table> element, we can expect tabular data.
> If we see an <li> element, we can expect that it is one of multiple.
>

>

see stats above, author intent in real world use does not appear to match
expectations. for the majority of users the use of figure/figcaption makes
not difference they don't even know its there. For users of assistive
technology in combination with browser that actually map the figure and
figcaption elements to something useful they are aware that the the content
of the figure is a distinct group and hat the caption for the group is (if
provided), the theoretical capability of figure to be moved away from its
current position is just that.


> This leaves us with the question at hand: if we see a <figure> element,
> can we expect to find a part of the document from which it is referenced?
> Consider the following scenario:
>
> One is reading an online newspaper article.  The article references Figure
> 1, located at the end of the article (and near the bottom of the page) due
> to readability constraints.  We look at the end of the article, and see a
> figure with a caption "Figure 1".  The article then references "Figure 2",
> so we look at the end of the article and see a figure with a caption,
> "Figure 2".  We arrive at the end of the article and see another figure
> with a caption, "Figure 3".
>
> In the above scenario, Figure 3 is unreferenced.  The first instinct when
> looking at an unreferenced figure (as used in the scenario) is to examine
> the figure to attempt to establish a context for it.  Whether or not
> context is established, the second instinct is almost invariably to go back
> to the part of the article after Figure 2 was referenced in order to find
> out where we missed the reference to Figure 3.  A third, slightly lesser
> instinct may even prompt a review of the entire article in an effort to
> find the missing reference.
>
> It is possible that the author of the fabled online newspaper article
> needed to use a visible caption, and could not find a better element for
> the job than <figure> and <figcaption>.  It is not obvious whether the
> article was edited incorrectly, whether there was a printing error, or
> whether the unreferenced figure was intended to stand alone.
>
> I propose that unreferenced figures set unreasonable expectation, as just
> described, and that either
>

>

from looking at real world data (see above) i couldn't actually find any
uses of figure/figcaption as you describe.


>
> 1) more generic grouping content should be used to group unreferenced data
> with captions, or
> 2) a new element be created similar to <label> with an attribute similar
> to the "for" attribute that is not required to be located within a user
> interface such as form, or
> 3) a new set of elements similar to <figure> and <figcaption> be created
> to group unreferenced data.
>
>
I don't think there is any need to add new features, but do think that
figure/figcaption definitions and explanations of use need to be modified
to take into account cow paths already trodden.


> --Xaxio
>
> References:
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-figure-element
>
> On Fri, Jun 21, 2013 at 3:00 AM, Steve Faulkner <faulkner.steve@gmail.com>wrote:
>
>> Hi Xaxio, (and martin)
>>
>> i get why figure on its own is OK.
>>
>> I think that it's OK to use the figure/figcaption pattern on any image
>> (for example) that the author wants to provide a caption for.
>>
>> The use case being: I want to provide some text as a caption for some
>> other content.
>>
>> It is unclear to me (at least) whether the whatwg spec says that is OK or
>> not.
>>
>> the latest (single page) whatwg spec says:
>>
>> "The figure element represents some flow content, optionally with a
>> caption, that is self-contained (like a complete sentence) and is typically
>> referenced as a single unit from the main flow of the document."
>>
>> There is no normative text that says it MUST be referenced, only a non
>> normative phrase "typically referenced"
>>
>> so that suggests to me that it is OK to use figure/figcaption for the use
>> case i described and the one you described, but then the there is a lot of
>> other descriptive text about figure that serves to befuddle my
>> understanding.
>>
>> note: the whatwg spec and the w3c html spec which you referenced
>> currently differ on figure, the proposed changes in the whatwg spec are
>> under discussion in the html wg.
>>
>> --
>>
>> Regards
>>
>> SteveF
>> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>>
>>
>> On 21 June 2013 08:38, Xaxio Brandish <xaxiobrandish@gmail.com> wrote:
>>
>>> Steve,
>>>
>>> One *could* use <div> elements in place of the <figure> elements; but
>>> then again, one could use <div> elements in place of many elements in order
>>> to remove their semantical meaning and send us back into the dark ages ;)
>>>
>>> I believe that <figure> is possibly the best element for the job, in
>>> agreement what Martin said regarding the spec specifying a figure being
>>> something that is *typically* referenced in the document [1].  I also
>>> believe that <figcaption> is necessary for exact specification (such as in
>>> medical documents or legal documents), but may be completely unnecessary
>>> for certain other documents (such as the font document example we are
>>> discussing).
>>>
>>> The reason I brought up placement and relevance of the figures in the
>>> first place is because of this sentence in the specification:
>>>
>>>>  This includes, but is not restricted to, content referred to from the
>>>> main part of the document, but that could, without affecting the flow of
>>>> the document, be moved away from that primary content, e.g. to the side of
>>>> the page, to dedicated pages, or to an appendix.
>>>>
>>> However, all of this does leave me wondering about an instance of fluff
>>> in an HTML document and how to appropriately define it.
>>>
>>> Consider a web page that is devoid of color or motion, and is thus less
>>> interesting to people who *must* read it.  An example of this can be an
>>> online driving education course.  Now imagine that the author of the page
>>> wanted to seem less boring, and so adds a piece of barely related clip art
>>> to the page, and said clip art is not referenced anywhere in the main
>>> document material.  The author wants to add a humorous comment to the image
>>> to lighten the mood of the page, and considers using <figure> and
>>> <figcaption>.
>>>
>>> Would it be appropriate to caption the aforementioned clip art using
>>> <figcaption> if it is contained in an <aside> element, claiming that the
>>> figure is self-referential yet only tangentially related to the document?
>>> If not, is there an element better suited to this purpose, or we can we
>>> redefine the <figcaption> element to encompass a purpose such as this?
>>>
>>> --Xaxio
>>>
>>> References:
>>> [1] http://www.w3.org/TR/html51/single-page.html#the-figure-element
>>>
>>>
>>> On Thu, Jun 20, 2013 at 3:34 PM, Martin Janecke <whatwg.org@prlbr.com>wrote:
>>>
>>>> Hi Steve,
>>>>
>>>>
>>>> >> The fact that they are enclosed in the <figure> elements means that
>>>> they
>>>> > are referenced somewhere, I believe.
>>>> >
>>>> > so if not referenced somewhere, they should not be in a figure?
>>>>
>>>>
>>>> Probably they should not, as figures are "typically referenced as a
>>>> single unit from the main flow of the document"^[1]. I'd like to add that
>>>> the reference can be implicit, though. A short car magazine article about a
>>>> particular model might be a good example. Readers who are likely to have
>>>> seen some cars in their lives will identify a car's front section on a
>>>> photograph by themselves and make the connection to what the articles
>>>> writes about it.
>>>>
>>>> Here is such an article:
>>>> http://www.caranddriver.com/news/2014-bmw-4-series-photos-and-info-news
>>>> Although the webpage does not actually use figure elements, it would be
>>>> appropriate for the photographs that are embedded in the main article. The
>>>> photographs illustrate and enhance the article's content by providing more
>>>> design details than the text, are self-contained, not part of the main flow
>>>> and implicitly referenced from it. (The photos should have alt-texts
>>>> though.)
>>>>
>>>> Regards
>>>> Martin
>>>>
>>>> [1]: WHATWG HTML spec 4.5.11 The figure element
>>>>
>>>> Am 20.06.2013 um 23:27 schrieb Steve Faulkner:
>>>>
>>>>
>>>> > Hi Xaxio,
>>>> >
>>>> > <p>Fonts come in many different varieties. The Arial font, for
>>>> example,
>>>> > does not have serifs.</p> <div>arial</div>
>>>> > <p>However, font varieties go beyond simple serif and sans-serif
>>>> > distinctions. The Old English font is neither of these, instead being
>>>> > considered a "decorative" font.</p><div>Old English</div>
>>>> >
>>>> > The above example has meaning with or without the divs, and the
>>>> placement
>>>> > of the divs doesn't matter. They could be in a font index at the end
>>>> of the
>>>> > document, as long as the data consumer knows to look there if example
>>>> are
>>>> > needed.  right?
>>>> >
>>>> >> The fact that they are enclosed in the <figure> elements means that
>>>> they
>>>> > are referenced somewhere, I believe.
>>>> >
>>>> > so if not referenced somewhere, they should not be in a figure?
>>>> >
>>>> > --
>>>> >
>>>> > Regards
>>>> >
>>>> > SteveF
>>>> > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>>>>
>>>> >
>>>> >
>>>> > On 20 June 2013 20:46, Xaxio Brandish <xaxiobrandish@gmail.com>
>>>> wrote:
>>>> >
>>>> >> <p>Fonts come in many different varieties. The Arial font, for
>>>> example,
>>>> >> does not have serifs.</p> <figure>arial</figure>
>>>> >> <p>However, font varieties go beyond simple serif and sans-serif
>>>> >> distinctions. The Old English font is neither of these, instead being
>>>> >> considered a "decorative" font.</p><figure>Old English</figure>
>>>> >>
>>>> >> The above example has meaning with or without the figures, and the
>>>> >> placement of the figures doesn't matter. They could be in a font
>>>> index at
>>>> >> the end of the document, as long as the data consumer knows to look
>>>> there
>>>> >> if example are needed.  The fact that they are enclosed in the
>>>> <figure>
>>>> >> elements means that they are referenced somewhere, I believe.
>>>> >>
>>>> >> When referring to multiple figures containing graphs or tables with
>>>> really
>>>> >> long names such as "Number of Children With Orange Dreadlocks With
>>>> Respect
>>>> >> to Decade" and "Periods of Time During Which Dreadlocks Are Popular,
>>>> Where
>>>> >> Orange Is Popular, and Where They Overlap", it's so much easier just
>>>> to
>>>> >> give them a <figcaption> and refer to "Table 1" and "Table 2" in the
>>>> >> document.
>>>> >>
>>>> >> --Xaxio
>>>> >> On Jun 20, 2013 12:20 PM, "Steve Faulkner" <faulkner.steve@gmail.com
>>>> >
>>>> >> wrote:
>>>> >>
>>>> >>> OK so how do you reference
>>>> >>>
>>>> >>> <figure>
>>>> >>> arial
>>>> >>> </figure>
>>>> >>>
>>>> >>> for example?
>>>> >>>
>>>> >>> --
>>>> >>>
>>>> >>> Regards
>>>> >>>
>>>> >>> SteveF
>>>> >>> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>>>>
>>>> >>>
>>>> >>>
>>>> >>> On 20 June 2013 20:16, Xaxio Brandish <xaxiobrandish@gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>>> The figures could be in a document talking about fonts, yet easily
>>>> moved
>>>> >>>> to the side of the page and still maintain relevance if referenced
>>>> within
>>>> >>>> the document.  I think something important about figures is
>>>> placement
>>>> >>>> irrelevance as long as they can be referenced, whereas paragraphs
>>>> don't
>>>> >>>> have the added semantic of "this will be referenced at some point."
>>>> >>>>
>>>> >>>> --Xaxio
>>>> >>>> On Jun 20, 2013 12:10 PM, "Steve Faulkner" <
>>>> faulkner.steve@gmail.com>
>>>> >>>> wrote:
>>>> >>>>
>>>> >>>>>> An illustration of a font name, in its respective font?
>>>> >>>>>
>>>> >>>>> why is <figure> better in this case than <p> (for example) ?
>>>> >>>>>
>>>> >>>>> --
>>>> >>>>>
>>>> >>>>> Regards
>>>> >>>>>
>>>> >>>>> SteveF
>>>> >>>>> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On 20 June 2013 19:27, Xaxio Brandish <xaxiobrandish@gmail.com>
>>>> wrote:
>>>> >>>>>
>>>> >>>>>> An illustration of a font name, in its respective font?
>>>> >>>>>>
>>>> >>>>>> --Xaxio
>>>> >>>>>> On Jun 20, 2013 11:24 AM, "Steve Faulkner" <
>>>> faulkner.steve@gmail.com>
>>>> >>>>>> wrote:
>>>> >>>>>>
>>>> >>>>>>> What are the use cases for a <figure> without a <figcaption> ?
>>>> >>>>>>> --
>>>> >>>>>>>
>>>> >>>>>>> Regards
>>>> >>>>>>>
>>>> >>>>>>> SteveF
>>>> >>>>>>> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>>
>>>>
>>>>
>>>
>>
>
Received on Monday, 24 June 2013 09:18:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC