figure

figure/0.1

Specification

Editor

Toby Inkster (http://tobyinkster.co.uk/)

Author

Toby Inkster (affiliations above)

Acknowledgments

See acknowledgments.

Copyright and patents statements apply.

Introduction

Many HTML documents include supporting images, such as photographs, flow charts, graphs, blueprints or screen captures. These are usually incorporated using the HTML <img> element, however this offers no way of differentiating between such supplementary content and mere decorative images.

Authors often wish to annotate these images with captions or attributions. Currently there is no markup to explicitly associate such text with an image and readers must rely on the proximity of the image and text on the finished rendered page.

This specification aims to allow authors to mark up captions and credits, explicitly associating them with an image.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Format

Root Class

The root class name for a figure is "figure".

Properties

The properties of the figure are represented by elements within the figure. Elements with class names of the listed properties represent the values of those properties.

Required:

• image (exactly one occurance)

Optional:

• legend ? (zero or one occurances)
• credit * (zero or more occurances)
• subject * (zero or more occurances)

Additionally, an figure MAY contain zero or more links marked up with rel-tag and MAY contain zero or more links marked up with rel-license.

If an element with class "credit" also has class "vcard" then the element SHOULD be considered to be the hcard for a credited person or organisation. Otherwise it MUST be considered as a plain text credit.

If an element with class "subject" also has a class "vcard" then the element SHOULD be considered to be the hcard for the subject of the image - for example a person in a photograph or sketch. If an element with class "subject" also has a class "adr" or "geo" then the element should be considered to be the address or geographic location of the subject of the photo - for example the location of a landscape in a photo or the address of a the building shown in blueprints. If an element with class "subject" also has a class "vevent" then the element should be considered to be the vevent for the subject of a photo - for example a photograph of a sporting event, or a diagramme of a military operation.

The subject, credit, tags and licence may be children of the legend, in which case the text within them forms part of the legend as well as part of the child elements.

Example

<div class="figure">
  <img class="image" src="photo.jpeg" alt="">
  <p class="legend">
    <a rel="tag" href="http://en.wikipedia.org/wiki/Photography">Photo</a> of
    <span class="subject vcard">
      <a class="fn url" href="http://einstein.physics.invalid">Albert Einstein</a>
    </span> by
    <span class="credit">Paul Ehrenfest</span>
  </p>
</div>

Parsed as:

• Image: photo.jpeg
• Legend: Photo of Albert Einstein by Paul Ehrenfest
• Credit: Paul Ehrenfest
• Subject: Albert Einstein (hCard)
• Categories: Phtotography
• License: (unspecified)

Minimisation

To simplify markup, a number of shortcuts are explicitly allowed by this specification.

Inspiration and Acknowledgments

HTML 5 Draft Specification figure-examples (various authors)

Copyright

This specification is released into the public domain.

Public Domain Contribution Requirement. Since the author(s) released this work into the public domain, in order to maintain this work's public domain status, all contributors to this page agree to release their contributions to this page to the public domain as well. Contributors may indicate their agreement by adding the public domain release template to their user page per the Voluntary Public Domain Declarations instructions. Unreleased contributions may be reverted/removed.

Patents

This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.