<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title><![CDATA[Content with Style - Comments on Figure microformats]]></title>
    <link>http://www.contentwithstyle.co.uk/feeds/rss/comments/161</link>
    <description><![CDATA[]]></description>
    <pubDate>Fri, 12 Mar 2010 13:03:35 +0000</pubDate>
    <generator>Zend_Feed</generator>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <item>
      <title><![CDATA[Content with Style - Comment #1 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2382</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2382</guid>
      <description><![CDATA[Interesting approach. And thanks for the write up. Images and figures have been one issue I&#8217;ve been having trouble with as well.<br />
<br />
A related issue is what you do when you develop a website for a client. There&#8217;s no WYSIWYG editor in the universe which spits out this kind of microformatisch markup :) So the only alternative is developing something like this and making them use that markup. Ussually I end up having a simple div box for the image and the caption.]]></description>
      <content:encoded><![CDATA[Interesting approach. And thanks for the write up. Images and figures have been one issue I&#8217;ve been having trouble with as well.<br />
<br />
A related issue is what you do when you develop a website for a client. There&#8217;s no WYSIWYG editor in the universe which spits out this kind of microformatisch markup :) So the only alternative is developing something like this and making them use that markup. Ussually I end up having a simple div box for the image and the caption.]]></content:encoded>
      <pubDate>Thu, 22 Nov 2007 10:12:48 +0000</pubDate>
    </item>
    <item>
      <title><![CDATA[Content with Style - Comment #2 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2384</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2384</guid>
      <description><![CDATA[well, I can&#8217;t think of one right now either, but you could build little wordpress plugins that give you some sort of dialog to add addresses hCard style into a post (similar to these flash video plugins).<br />
Because figure markup does (so far) not have that many options, it would be even easier, but using uploaded images within a plugin context is a bit tricky.]]></description>
      <content:encoded><![CDATA[well, I can&#8217;t think of one right now either, but you could build little wordpress plugins that give you some sort of dialog to add addresses hCard style into a post (similar to these flash video plugins).<br />
Because figure markup does (so far) not have that many options, it would be even easier, but using uploaded images within a plugin context is a bit tricky.]]></content:encoded>
      <pubDate>Thu, 22 Nov 2007 19:30:33 +0000</pubDate>
    </item>
    <item>
      <title><![CDATA[Content with Style - Comment #3 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2391</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2391</guid>
      <description><![CDATA[Interesting&#8212;glad to see this topic continue to be fleshed out! I noticed that you didn&#8217;t cite my piece on this subject? Just wanted to make sure you read my take (and the interesting discussion that followed):<br />
<br />
<a href="http://factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment/">factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment</a><br />
<br />
As for your approach, let&#8217;s get it on the wiki!<br />
<br />
From your later example, this is what I see as your figure DOM:<br />
<br />
figure<br />
figure.image<br />
figure.image.img<br />
figure.legend<br />
  figure.legend.caption<br />
  figure.legend.credit<br />
  figure.legend.credit.type<br />
  figure.legend.credit.cite<br />
<br />
That seems somewhat restrictive and not altogether based on existing behavior (remember, that&#8217;s a core aspect of the microformats process). I admit that I haven&#8217;t followed process perfectly myself, and intend to do better&#8212;and your example actually serves quite well to illustrative and example in the wild, however, going beyond images, I think &#8220;illustrative&#8221; figures in general needs to be considered&#8230; how does your approach apply to tables, video, or audio? I&#8217;d like to see examples marked up if you&#8217;d be willing&#8230;<br />
<br />
Oh, and I do worry about the &lt;p class=image&gt; thing&#8230;. why not just make the .figure img have the style of display:block?]]></description>
      <content:encoded><![CDATA[Interesting&#8212;glad to see this topic continue to be fleshed out! I noticed that you didn&#8217;t cite my piece on this subject? Just wanted to make sure you read my take (and the interesting discussion that followed):<br />
<br />
<a href="http://factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment/">factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment</a><br />
<br />
As for your approach, let&#8217;s get it on the wiki!<br />
<br />
From your later example, this is what I see as your figure DOM:<br />
<br />
figure<br />
figure.image<br />
figure.image.img<br />
figure.legend<br />
  figure.legend.caption<br />
  figure.legend.credit<br />
  figure.legend.credit.type<br />
  figure.legend.credit.cite<br />
<br />
That seems somewhat restrictive and not altogether based on existing behavior (remember, that&#8217;s a core aspect of the microformats process). I admit that I haven&#8217;t followed process perfectly myself, and intend to do better&#8212;and your example actually serves quite well to illustrative and example in the wild, however, going beyond images, I think &#8220;illustrative&#8221; figures in general needs to be considered&#8230; how does your approach apply to tables, video, or audio? I&#8217;d like to see examples marked up if you&#8217;d be willing&#8230;<br />
<br />
Oh, and I do worry about the &lt;p class=image&gt; thing&#8230;. why not just make the .figure img have the style of display:block?]]></content:encoded>
      <pubDate>Sun, 25 Nov 2007 17:30:16 +0000</pubDate>
    </item>
    <item>
      <title><![CDATA[Content with Style - Comment #4 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2394</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2394</guid>
      <description><![CDATA[Hi Chris,<br />
<br />
First of all thanks for your comment. And now I&#8217;m going to punish you with this retaliation!<br />
<br />
I&#8217;ve followed Edward&#8217;s/Anne&#8217;s reasoning behind the p.image, which is that you shouldn&#8217;t mix block and inline elements on one level. Changing the behaviour of an element in css (display:block) doesn&#8217;t solve it on an html level.<br />
Where I agree with you is that it&#8217;s, hmmm, possibly over the top? If it was down to me before I read Anne&#8217;s concept (and the way I used it in the project was before I took on this issue), I wouldn&#8217;t have bothered. <br />
The DTD allows this kind of html structure, the code validates. Yet it seems wrong for some. So what would be the better way: taking it out, and thereby having less than perfect html (and, actually, one container less for different kinds of media, such as the mentioned tables, video or audio) for the sake of more people getting their heads around it; or leaving it in, risking that a lot of people don&#8217;t understand the issue behind it, and it&#8217;s consequently  accepted and adopted less.<br />
<br />
About other-than-image content: I don&#8217;t see an issue at all with video or audio, given that both usually run in their own kind of player. The point of using other media would actually be one for the block container around the img. About tables, well, there&#8217;s already a   lot of ways of describing a table, it would be great indeed to see a fully annotated table, that would then be dropped in the currently named p.image. I&#8217;m not a native english speaker, so I&#8217;m getting a bit weak around the terminology here. Of course it shouldn&#8217;t be called p.image if there&#8217;s other content in it. If you&#8217;re talking images, audio, video, you&#8217;d get away with p.media, but as you say it needs to be able to allow for any content, really.<br />
What&#8217;s a good general word for the to-be-described content?<br />
<br />
This is getting the longest comment ever&#8230; finally about why I didn&#8217;t quote your article (I just re-read it): There&#8217;s a strong case for not muddling up presentation and code structure. I want to get to the <em>right</em> way (if only right in the things that I personally do) of marking up figures first, and then I&#8217;ll worry about where it&#8217;s sitting. As you wrote, I wouldn&#8217;t add alignleft, alignright and center in general use; as I&#8217;d prefer neutral classnames (although, in the real world, case-to-case, there&#8217;s good reason for doing exactly that; and that&#8217;s what I read out of your comments as well).<br />
But what I don&#8217;t understand is why the presentation of a figure block (or an image or whatever) even needs unifying? Isn&#8217;t the idea of microformats that you create machine-readable tags that, once parsed, could be displayed in any way? And, again, <a href="http://factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment/#comment-56385">reading from your comments</a>, if the positioning of an image is important for the context, then why not use natural language &#8220;left&#8221;, &#8220;right&#8221; or &#8220;center&#8221;?]]></description>
      <content:encoded><![CDATA[Hi Chris,<br />
<br />
First of all thanks for your comment. And now I&#8217;m going to punish you with this retaliation!<br />
<br />
I&#8217;ve followed Edward&#8217;s/Anne&#8217;s reasoning behind the p.image, which is that you shouldn&#8217;t mix block and inline elements on one level. Changing the behaviour of an element in css (display:block) doesn&#8217;t solve it on an html level.<br />
Where I agree with you is that it&#8217;s, hmmm, possibly over the top? If it was down to me before I read Anne&#8217;s concept (and the way I used it in the project was before I took on this issue), I wouldn&#8217;t have bothered. <br />
The DTD allows this kind of html structure, the code validates. Yet it seems wrong for some. So what would be the better way: taking it out, and thereby having less than perfect html (and, actually, one container less for different kinds of media, such as the mentioned tables, video or audio) for the sake of more people getting their heads around it; or leaving it in, risking that a lot of people don&#8217;t understand the issue behind it, and it&#8217;s consequently  accepted and adopted less.<br />
<br />
About other-than-image content: I don&#8217;t see an issue at all with video or audio, given that both usually run in their own kind of player. The point of using other media would actually be one for the block container around the img. About tables, well, there&#8217;s already a   lot of ways of describing a table, it would be great indeed to see a fully annotated table, that would then be dropped in the currently named p.image. I&#8217;m not a native english speaker, so I&#8217;m getting a bit weak around the terminology here. Of course it shouldn&#8217;t be called p.image if there&#8217;s other content in it. If you&#8217;re talking images, audio, video, you&#8217;d get away with p.media, but as you say it needs to be able to allow for any content, really.<br />
What&#8217;s a good general word for the to-be-described content?<br />
<br />
This is getting the longest comment ever&#8230; finally about why I didn&#8217;t quote your article (I just re-read it): There&#8217;s a strong case for not muddling up presentation and code structure. I want to get to the <em>right</em> way (if only right in the things that I personally do) of marking up figures first, and then I&#8217;ll worry about where it&#8217;s sitting. As you wrote, I wouldn&#8217;t add alignleft, alignright and center in general use; as I&#8217;d prefer neutral classnames (although, in the real world, case-to-case, there&#8217;s good reason for doing exactly that; and that&#8217;s what I read out of your comments as well).<br />
But what I don&#8217;t understand is why the presentation of a figure block (or an image or whatever) even needs unifying? Isn&#8217;t the idea of microformats that you create machine-readable tags that, once parsed, could be displayed in any way? And, again, <a href="http://factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment/#comment-56385">reading from your comments</a>, if the positioning of an image is important for the context, then why not use natural language &#8220;left&#8221;, &#8220;right&#8221; or &#8220;center&#8221;?]]></content:encoded>
      <pubDate>Mon, 26 Nov 2007 07:26:12 +0000</pubDate>
    </item>
    <item>
      <title><![CDATA[Content with Style - Comment #5 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2396</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2396</guid>
      <description><![CDATA[I&#8217;ve tried to find a <a href="http://www.usability.com.au/resources/tables.cfm#complex">nice accessible table</a> example, and of course, table comes with a caption element; mmm, now how would that work?]]></description>
      <content:encoded><![CDATA[I&#8217;ve tried to find a <a href="http://www.usability.com.au/resources/tables.cfm#complex">nice accessible table</a> example, and of course, table comes with a caption element; mmm, now how would that work?]]></content:encoded>
      <pubDate>Tue, 27 Nov 2007 05:03:46 +0000</pubDate>
    </item>
    <item>
      <title><![CDATA[Content with Style - Comment #6 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2397</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2397</guid>
      <description><![CDATA[I think the class that indicates the microformat should be seperate from any layout classes, i.e. class=&#8221;figure layout-a&#8221; ... on a personal note I couldn&#8217;t be bothered to be fuzzed about block and inline elements mixed &#8230; if the DTD allows it and you save an element, then it&#8217;s legitimate. But that&#8217;s just my 5 p.]]></description>
      <content:encoded><![CDATA[I think the class that indicates the microformat should be seperate from any layout classes, i.e. class=&#8221;figure layout-a&#8221; ... on a personal note I couldn&#8217;t be bothered to be fuzzed about block and inline elements mixed &#8230; if the DTD allows it and you save an element, then it&#8217;s legitimate. But that&#8217;s just my 5 p.]]></content:encoded>
      <pubDate>Tue, 27 Nov 2007 06:07:28 +0000</pubDate>
    </item>
    <item>
      <title><![CDATA[Content with Style - Comment #7 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2409</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-2409</guid>
      <description><![CDATA[Since I cant edit at microformats.org (and dont want to register) I suggest you to consider license information using rel=&#8221;license&#8221; from Atom [1]. Check Mark Pilgrim&#8217;s blog to see how he makes clear the license for each picture he takes from Flickr [2].<br />
<br />
[1] http://www.ietf.org/rfc/rfc4946.txt<br />
[2] http://diveintomark.org/archives/2003/01/19/influences]]></description>
      <content:encoded><![CDATA[Since I cant edit at microformats.org (and dont want to register) I suggest you to consider license information using rel=&#8221;license&#8221; from Atom [1]. Check Mark Pilgrim&#8217;s blog to see how he makes clear the license for each picture he takes from Flickr [2].<br />
<br />
[1] http://www.ietf.org/rfc/rfc4946.txt<br />
[2] http://diveintomark.org/archives/2003/01/19/influences]]></content:encoded>
      <pubDate>Tue, 11 Dec 2007 23:20:59 +0000</pubDate>
    </item>
    <item>
      <title><![CDATA[Content with Style - Comment #8 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-5505</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-5505</guid>
      <description><![CDATA[I've just had a look at what has been happening on the Microformats-Wiki, and it seems that Toby Inkster has taken on the subject and done some nice consolidation work over the last year, pretty much incorporating my suggestions. Leaves him and me and <a href="http://microformats.org/discuss/mail/microformats-new/2008-September/001810.html">the rest of the world</a> with making it more generic, incorporating other forms of content such as (but not limited to) tables or code listings, to make it more conform with the HTML 5 figure element scope. 

Watch out for a new post about this soon, feel free to suggest improvements or examples in the meantime.]]></description>
      <content:encoded><![CDATA[I've just had a look at what has been happening on the Microformats-Wiki, and it seems that Toby Inkster has taken on the subject and done some nice consolidation work over the last year, pretty much incorporating my suggestions. Leaves him and me and <a href="http://microformats.org/discuss/mail/microformats-new/2008-September/001810.html">the rest of the world</a> with making it more generic, incorporating other forms of content such as (but not limited to) tables or code listings, to make it more conform with the HTML 5 figure element scope. 

Watch out for a new post about this soon, feel free to suggest improvements or examples in the meantime.]]></content:encoded>
      <pubDate>Sun, 15 Feb 2009 21:23:12 +0000</pubDate>
    </item>
    <item>
      <title><![CDATA[Content with Style - Comment #9 on Figure microformats]]></title>
      <link>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-5759</link>
      <guid>http://www.contentwithstyle.co.uk/content/figure-microformats/#comment-5759</guid>
      <description><![CDATA[I think the class that indicates the microformat should be seperate from any layout classes, i.e. class=”figure layout-a” ... on a personal note I couldn’t be bothered to be fuzzed about block and inline elements mixed …]]></description>
      <content:encoded><![CDATA[I think the class that indicates the microformat should be seperate from any layout classes, i.e. class=”figure layout-a” ... on a personal note I couldn’t be bothered to be fuzzed about block and inline elements mixed …]]></content:encoded>
      <pubDate>Tue, 24 Mar 2009 15:44:21 +0000</pubDate>
    </item>
  </channel>
</rss>
