Re: current definition of <figure> in HTML is problematic

Hi Bruce,

agree and agree that it would be useful to have normative keywords
styled differently, note in most W3C specs they are capitlaized

"MUST" "MAY" while this may be a bit visually jarring, for some, it
does make it clearer, but a less shouty style MAY also work.

After reading your recent comment on the HTML5 doctor article I cited
in the original email on this thread, in a subsequent comment I found
a link to another doctor article [1] on fat footers in which the use
of <figure> was also discussed and the same misinterpretations arose:

for example, Jeremy Keith wrote [2]:

"The whole point of the figure element is that it could potentially
appear *anywhere* in the document: the top, the bottom, the middle.
Taking any one of those pieces of content and putting them anywhere
else in the page makes little sense. They are at the end of the
document for a reason. They are not referenced from the main content
of the document."

The question I keep asking myself, is what practical or imagined
advantage does this constraint bring to the use of figure/figcaption?

I keep drawing a blank.



On 28 January 2013 15:51, Bruce Lawson <> wrote:
> On Thu, 24 Jan 2013 20:21:38 -0000, Michael[tm] Smith <> wrote:
>> Steve Faulkner <>, 2013-01-24 09:44 +0000:
>>> I think the current definition [4] of  the figure element leads to
>>> developers thinking that they cannot use it to caption an image or images
>>> that are ket parts of the content:
>>> "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, 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."
>> I agree that statement seems to be confusing people, and so maybe some
>> language should be added around there to make it more clear that the
>> figure
>> element is not necessarily restricted to being used only for the purpose
>> described there.
> I agree. Perhaps changing ""The element can thus be used to annotate
> illustrations .. " to "The element may also be used .." thereby emphasising
> that it's a different use ("also").
> Mike Smith said:
>> to anybody who's
>> taken time to get familiar with the editorial style the spec consistently
>> uses, it would be clear that sentence states no normative requirements.
>> For context about what I mean, it's worth also quoting what the spec says
>> just before that statement you quote above. What it says is:
>>   The figure element represents some flow content, optionally with a
>>   caption, that is self-contained and is typically referenced as a single
>>   unit from the main flow of the document.
>> As far as I can see, that sentence is the only statement in the spec that
>> normatively defines the meaning of the figure element.
> [snip]
>> The spec very consistently uses a particular style to clearly distinguish
>> between parts that are normative and parts that are just informative or
>> illustrative.
> I'm not convinced that it's at all clear. It currently hangs on
> understanding the word "can" in "can thus.." means possibility rather than
> requirement, and a deeper familiarity with the style of the spec than most
> web developers can be expected to have.
> I suggest that normative statements be visually stronger, and sylistically
> differentiated from non-normative glosses. Perhaps if the normative
> statement "The figure element represents some flow content, optionally with
> a caption, that is self-contained and is typically referenced as a single
> unit from the main flow of the document." were surrounded by <strong>, in a
> div class="normative" that is styled to be  surrounded by a box, it would
> indicate its importance more?
> bruce
> --
> Bruce Lawson
> Open standards evangelist
> Developer Relations Team
> Opera

with regards

Steve Faulkner
Technical Director - TPG | |
HTML5: Techniques for providing useful text alternatives -
Web Accessibility Toolbar -

Received on Monday, 28 January 2013 17:37:22 UTC