figure-examples: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (fix deadname)
 
(11 intermediate revisions by 6 users not shown)
Line 7: Line 7:


The goal of this effort is to document and reflect the real-world needs of such design patterns while paying close attention to the types of data that people are using in this supportive role and also paying close attention to the existing class names and presentational styles that go along with such formats.
The goal of this effort is to document and reflect the real-world needs of such design patterns while paying close attention to the types of data that people are using in this supportive role and also paying close attention to the existing class names and presentational styles that go along with such formats.
== The Draft ==
[[figure | A draft]] has been created that takes many of the suggestions of this discussion on board.


== Participants ==
== Participants ==
* [[User:Chris_Messina | Chris Messina]]
* [[User:Chris_Messina | Chris Messina]]
* [[User:EdwardOConnor | Edward O'Connor]]
* Theresa O'Connor
* [[User:AaronGustafson | Aaron Gustafson]]
* [[User:AaronGustafson | Aaron Gustafson]]
* ...
* ...
Line 41: Line 45:
== Existing Practices ==
== Existing Practices ==


In many cases, classes that are used exclusively for alignment and positioning are documented herein order to have an accurate sense for how people mark up this kind of content in practice.
In many cases, classes that are used exclusively for alignment and positioning are documented here in order to have an accurate sense for how people mark up this kind of content in practice.


=== [http://factoryjoe.com/blog FactoryCity Blog] ===
=== [http://factoryjoe.com/blog FactoryCity Blog] ===
Line 135: Line 139:
* includes the classes <code>float-left</code> or <code>float-right</code> for aligning figures
* includes the classes <code>float-left</code> or <code>float-right</code> for aligning figures


=== [http://edward.oconnor.cx/ Edward O'Connor's blog] ===
=== [http://theresa.oconnor.cx/ Theresa O'Connor's blog] ===


* POSH figure markup, based on several inputs:
* POSH figure markup, based on several inputs:
Line 141: Line 145:
** RFC 2629's figure element
** RFC 2629's figure element
** [http://microformats.org/discuss/mail/microformats-discuss/2007-August/010421.html Paul Wilkins' class names]
** [http://microformats.org/discuss/mail/microformats-discuss/2007-August/010421.html Paul Wilkins' class names]
* Documented in [http://edward.oconnor.cx/2007/04/marking-up-figures Marking up figures], [http://edward.oconnor.cx/2007/08/figure-markup-redux Figure markup redux], and described in [http://edward.oconnor.cx/profiles/figures XMDP]
* Documented in [http://theresa.oconnor.cx/2007/04/marking-up-figures Marking up figures], [http://theresa.oconnor.cx/2007/08/figure-markup-redux Figure markup redux], and described in [http://theresa.oconnor.cx/profiles/figures XMDP]


=== Revenue Watch Institute (website forthcoming) ===
=== Revenue Watch Institute (website forthcoming) ===


During the development of the new website for Revenue Watch, this was what we cam up with to handle figures:
During the development of the new website for Revenue Watch, this was what we came up with to handle figures:


<pre>
<pre>
Line 190: Line 194:
</pre>
</pre>


No presentational information is added to the figures. The presentation is determined via script as a progressive enhancement (ALA article forthcoming).
No presentational information is added to the figures. The presentation is determined via script as a progressive enhancement ([http://www.alistapart.com/articles/figurehandler ALA article]).


Tables receive no figure-related styles, but graphs, charts, and maps do.
Tables receive no figure-related styles, but graphs, charts, and maps do.
Line 196: Line 200:
====Comments====
====Comments====
Why is "credit" not an hCard? Also, for pictures of places any geo/ hcard microformat included in the caption should be understood to be associated with the figure. There is debate elsewhere, about whether coordinates should be for the camera position, or the object photographed; with consensus coming down on the side of the former [http://commons.wikimedia.org/wiki/Commons_talk:Geocoding#Geotagging_the_camera_or_the_Objekt], [http://commons.wikimedia.org/wiki/Commons_talk:Geocoding#Camera_vs_object_location]. That said, the whole "figure" div could be an hcard, with the picture being part of that; and a separate hCard for the photographer included. Complex... [[User:AndyMabbett|Andy Mabbett]] 16:52, 21 Aug 2007 (PDT)
Why is "credit" not an hCard? Also, for pictures of places any geo/ hcard microformat included in the caption should be understood to be associated with the figure. There is debate elsewhere, about whether coordinates should be for the camera position, or the object photographed; with consensus coming down on the side of the former [http://commons.wikimedia.org/wiki/Commons_talk:Geocoding#Geotagging_the_camera_or_the_Objekt], [http://commons.wikimedia.org/wiki/Commons_talk:Geocoding#Camera_vs_object_location]. That said, the whole "figure" div could be an hcard, with the picture being part of that; and a separate hCard for the photographer included. Complex... [[User:AndyMabbett|Andy Mabbett]] 16:52, 21 Aug 2007 (PDT)
:For tangible entities (people, orgs, locations) hCard seems appropriate to me as well, however, figures can be illustrations or be composed of fictional (has this been addressed in hCard?) parts. In this case, "credit" could be defined as "text | hCard". Regarding hCard, TITLE or NOTE may be sufficient to define "credit". [[User:Csarven|Sarven Capadisli]] 09:55, 22 Feb 2008 (PST)


I like the idea of the hCard <em>if</em> there is more information available other than just the name. If you are just putting the person's name, I still don't see the point of making that an hCard. Add some additional data (a link, email address, etc.) and I think you have an argument. Otherwise I think it's a waste of markup and simply clutters the results of whatever hCards might exist elsewhere on the page. As for geo-data, I think that sort of information may be useful, but I think I'd prefer to see that embedded within a <code>longdesc</code> page with more info on the image. Inside an article it seems superfluous to me. A <code>longdesc</code> page for an image could include much more data about where it was taken, by whom (possibly even a full hCard of the creator), etc.  
I like the idea of the hCard <em>if</em> there is more information available other than just the name. If you are just putting the person's name, I still don't see the point of making that an hCard. Add some additional data (a link, email address, etc.) and I think you have an argument. Otherwise I think it's a waste of markup and simply clutters the results of whatever hCards might exist elsewhere on the page. As for geo-data, I think that sort of information may be useful, but I think I'd prefer to see that embedded within a <code>longdesc</code> page with more info on the image. Inside an article it seems superfluous to me. A <code>longdesc</code> page for an image could include much more data about where it was taken, by whom (possibly even a full hCard of the creator), etc.  
[[User:AaronGustafson|Aaron Gustafson]] 18:24, 22 Aug 2007 (EDT)
[[User:AaronGustafson|Aaron Gustafson]] 18:24, 22 Aug 2007 (EDT)
I like this idea, it certainly seems neat. Can we also please add an "optimisation" to explicitly say that if the IMG element itself has class="caption" then the TITLE attribute is taken to be the caption for the image. That way, we can support very minimal figures like this:
<pre>
<img class="figure caption" title="Sales data for March" src="march_sales.png"
alt="We've experienced a huge growth in Widget sales this month!">
</pre>
Through to more verbose figures including credits with [[hcard]], and categories via [[rel-tag]]. [[User:TobyInk|TobyInk]] 06:46, 18 Feb 2008 (PST)
=== [http://www.contentwithstyle.co.uk/ Content with Style] ===
In an attempt to bring together some of the ideas suggested, an addition to the Revenue Watch example was made. [http://www.contentwithstyle.co.uk/content/figure-microformats This solution] is based on
* Theresa O'Connor's [http://theresa.oconnor.cx/2007/08/figure-markup-redux Figure markup redux]
* the [[#Revenue Watch Institute(website forthcoming)|Revenue Watch example]] and
* [[#HTML5|HTML5's figure element]] above
The idea was to group meta information about the image in a legend container, just like HTML5 does. This leads to more freedom when styling the figure block, as the information can be grouped or treated separately.
<pre>
<div class="figure">
  <p class="image"><img src="/path/to/img.jpg" width="400" height="602" alt="Lorem ipsum dolor sit amet" /></p>
  <div class="legend">
    <p class="caption">Lorem ipsum dolor sit amet.</p>
    <p class="credit">
      <abbr class="type" title="Photograph">Photo</abbr>
      &amp;copy; <cite>John Doe</cite>
    </p>
  </div>
</div>
</pre>
* The "legend" class is not semantically needed -- "caption" and "credit" suffice. IMHO, it should be left out of the microformat, though of course (as with other microformats) authors are free to add additional elements and classes to their data to assist with styling. [[User:TobyInk|TobyInk]] 06:39, 18 Feb 2008 (PST)


== Further discussion ==
== Further discussion ==
Line 205: Line 241:


* [http://factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment/ A design pattern for image and figure alignment]
* [http://factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment/ A design pattern for image and figure alignment]
* [http://edward.oconnor.cx/2007/04/marking-up-figures Marking up figures]
* [http://theresa.oconnor.cx/2007/04/marking-up-figures Marking up figures]
* [http://www.css3.info/styling-figures-with-css3/ Styling figures with CSS3]
* [http://www.css3.info/styling-figures-with-css3/ Styling figures with CSS3]
* [http://www.simplebits.com/notebook/2005/07/10/figures.html When Floated Figures Attack!]
* [http://www.simplebits.com/notebook/2005/07/10/figures.html When Floated Figures Attack!]
* [http://www.pearsonified.com/2007/06/how-to-format-images-for-feed-readers.php How to Format Images for Feed Readers]
* [http://www.pearsonified.com/2007/06/how-to-format-images-for-feed-readers.php How to Format Images for Feed Readers]
* [http://www.alistapart.com/articles/figurehandler If I Told You You Had a Beautiful Figure...] by AARON GUSTAFSON
* [http://www.contentwithstyle.co.uk/content/figure-microformats Figure Microformats]

Latest revision as of 00:51, 21 June 2018

Figure examples

This page documents examples of mark up for figures like images, captions and data tables in webpages and the class-names that they've used - Chris Messina

The Problem

There are no HTML tags for identifying or marking up supporting content like illustrative images (as in encyclopaedic references), photographs and their captions, credits or licenses (as in news articles) or data tables. Typically this content can be found in close proximity to the relevant information, but oftentimes mixed with other elements.

The goal of this effort is to document and reflect the real-world needs of such design patterns while paying close attention to the types of data that people are using in this supportive role and also paying close attention to the existing class names and presentational styles that go along with such formats.


The Draft

A draft has been created that takes many of the suggestions of this discussion on board.

Participants

Real-World Examples

These are examples and implementations in the wild of various efforts at marking up figures in web pages, blog posts and articles.

CNET

CNET uses cnet-image-div, float-left, cnet-image, image-credit and image-caption to mark up supporting photographs and artwork.

See this example: Why I recommend the iPhone -- and don't.

HTML5

HTML5 introduces a new tag called "figure", which represents a block-level image, along with a caption:

<figure id="fig2">
  <legend>Figure 2. Install Mozilla XForms dialog</legend>
  <img alt="A Web site is requesting permission to install the following item: 
    Mozilla XForms 0.7 Unsigned" 
    src="installdialog.jpg" border="0" height="317" hspace="5" vspace="5" width="331" />
</figure>

This is slightly different from the broader goal of this effort, but nevertheless points to current work on this topic.

Existing Practices

In many cases, classes that are used exclusively for alignment and positioning are documented here in order to have an accurate sense for how people mark up this kind of content in practice.

FactoryCity Blog

  • uses a series of figure classes to markup figures.
  • the approach used is to mark up block level figures with both figure and either figure-a or figure-c classes.
  • figure-b and figure-d are used for inline figures aligned right and left, respectively
  • the a, b, c, d pattern is modeled after the top, right, bottom, left order of CSS attribute values
  • Paul Wilkins suggested more semantic names for these classes on µf-discuss

K2 WordPress Theme

  • The K2 stylesheet includes the following figure-related CSS:
.center {
	text-align: center;
	}

.alignright {
	float: right;
	}
	
.alignleft {
	float: left
	}

img.center, img[align="center"] {
	display: block;
	margin-left: auto;
	margin-right: auto;
	}
	
img.alignright, img[align="right"] {
	padding: 4px;
	margin: 0 0 2px 7px;
	display: inline;
	}

img.alignleft, img[align="left"] {
	padding: 4px;
	margin: 0 7px 2px 0;
	display: inline;
	}
	
img.noborder {
	border: none !important;
	}

Habari K2 Theme

Similar to K2, the Habari K2 instance supports the following classes:

.center {
	text-align: center;
	}

.alignright {
	float: right;
	}
	
.alignleft {
	float: left
	}

img.center, img[align="center"] {
	display: block;
	margin-left: auto;
	margin-right: auto;
	}
	
img.alignright, img[align="right"] {
	padding: 4px;
	margin: 0 0 2px 7px;
	display: inline;
	}

img.alignleft, img[align="left"] {
	padding: 4px;
	margin: 0 7px 2px 0;
	display: inline;
	}
	
img.noborder {
	border: none !important;
	}

ColdBlue WordPress Theme

  • includes the classes float-left or float-right for aligning figures

Theresa O'Connor's blog

Revenue Watch Institute (website forthcoming)

During the development of the new website for Revenue Watch, this was what we came up with to handle figures:

<div class="figure">
  <img src="/path/to/img.jpg" alt="" />
  <p class="credit"><abbr class="type" title="Phtotograph">Photo</abbr> by <cite>Bob Johnson</cite></p>
  <p class="caption"><em class="title">Figure 1</em> Cras rutrum, enim at placerat varius, nisi massa consectetuer.</p>
</div>
  • Figures can be categorized as types using the "type" class (here type is embedded in the credit line, using the ABBR design pattern) - current recommendations: "photograph" or "illustration" (these could possibly be extended to include other options such as "chart," "line-art", etc.) (optional)
  • The "title" class can be added to any element within the figure (optional)
  • Credit for the figure is denoted with the "credit" class (optional)
  • A caption is also available (optional)

Default styles:

.figure {
  margin: 0 0 1.5em;
}
.figure p {
  margin: 0;
  width: auto;
}
.figure .credit {
  font-size: .8em;
  text-align: right;
}
.figure .credit cite {
  font-style: inherit;
}
.figure .caption {
  font-style: italic;
  font-size: 1.1em;
}
.figure .title {
  font-style: normal;
  font-weight: bold;
}
.figure .title:after {
  content: ":";
}

No presentational information is added to the figures. The presentation is determined via script as a progressive enhancement (ALA article).

Tables receive no figure-related styles, but graphs, charts, and maps do.

Comments

Why is "credit" not an hCard? Also, for pictures of places any geo/ hcard microformat included in the caption should be understood to be associated with the figure. There is debate elsewhere, about whether coordinates should be for the camera position, or the object photographed; with consensus coming down on the side of the former [1], [2]. That said, the whole "figure" div could be an hcard, with the picture being part of that; and a separate hCard for the photographer included. Complex... Andy Mabbett 16:52, 21 Aug 2007 (PDT)

For tangible entities (people, orgs, locations) hCard seems appropriate to me as well, however, figures can be illustrations or be composed of fictional (has this been addressed in hCard?) parts. In this case, "credit" could be defined as "text | hCard". Regarding hCard, TITLE or NOTE may be sufficient to define "credit". Sarven Capadisli 09:55, 22 Feb 2008 (PST)

I like the idea of the hCard if there is more information available other than just the name. If you are just putting the person's name, I still don't see the point of making that an hCard. Add some additional data (a link, email address, etc.) and I think you have an argument. Otherwise I think it's a waste of markup and simply clutters the results of whatever hCards might exist elsewhere on the page. As for geo-data, I think that sort of information may be useful, but I think I'd prefer to see that embedded within a longdesc page with more info on the image. Inside an article it seems superfluous to me. A longdesc page for an image could include much more data about where it was taken, by whom (possibly even a full hCard of the creator), etc. Aaron Gustafson 18:24, 22 Aug 2007 (EDT)

I like this idea, it certainly seems neat. Can we also please add an "optimisation" to explicitly say that if the IMG element itself has class="caption" then the TITLE attribute is taken to be the caption for the image. That way, we can support very minimal figures like this:

<img class="figure caption" title="Sales data for March" src="march_sales.png"
alt="We've experienced a huge growth in Widget sales this month!">

Through to more verbose figures including credits with hcard, and categories via rel-tag. TobyInk 06:46, 18 Feb 2008 (PST)

Content with Style

In an attempt to bring together some of the ideas suggested, an addition to the Revenue Watch example was made. This solution is based on

The idea was to group meta information about the image in a legend container, just like HTML5 does. This leads to more freedom when styling the figure block, as the information can be grouped or treated separately.

<div class="figure">
  <p class="image"><img src="/path/to/img.jpg" width="400" height="602" alt="Lorem ipsum dolor sit amet" /></p>
  <div class="legend">
    <p class="caption">Lorem ipsum dolor sit amet.</p>
    <p class="credit">
      <abbr class="type" title="Photograph">Photo</abbr>
      &copy; <cite>John Doe</cite>
    </p>
  </div>
</div>
  • The "legend" class is not semantically needed -- "caption" and "credit" suffice. IMHO, it should be left out of the microformat, though of course (as with other microformats) authors are free to add additional elements and classes to their data to assist with styling. TobyInk 06:39, 18 Feb 2008 (PST)

Further discussion

A few blog posts capture the essence of this discussion well: