Difference between revisions of "microformats2-implied-properties"

From Microformats Wiki
microformats2-implied-properties
Jump to navigation Jump to search
(promote a few more root class with one child element markup patterns from consideration to inclusion based on real-world uses)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<entry-title>microformats 2 implied properties</entry-title>
+
{{DISPLAYTITLE:microformats2 implied properties}}
 
== summary ==
 
== summary ==
 
As part of the further simplifications in [[microformats-2]], the following generic properties are automatically implied by microformats with only a root class name with certain common semantic markup patterns.
 
As part of the further simplifications in [[microformats-2]], the following generic properties are automatically implied by microformats with only a root class name with certain common semantic markup patterns.
Line 36: Line 36:
 
* every single proper noun on any web page.
 
* every single proper noun on any web page.
  
issues:
+
related FAQ:
* may not work for all microformats, e.g. how would [[adr]] or [[geo]] work with this?
+
* [[microformats2-faq#how_do_h-adr_and_h-geo_work_with_an_implied_name_property|how do instances of h-adr and h-geo work with implied names]]? short answer: (implied) names are useful for labeling them when in lists.
  
 
=== aside name vs fn ===
 
=== aside name vs fn ===
Line 98: Line 98:
 
}
 
}
 
</source>
 
</source>
 +
 +
An object element with a data attribute works the same way as the img element with its src attribute.
  
 
to-do:  
 
to-do:  
Line 108: Line 110:
 
Often proper noun references on web pages are a representative image of the proper noun that is hyperlinked to a page about that proper noun.
 
Often proper noun references on web pages are a representative image of the proper noun that is hyperlinked to a page about that proper noun.
  
Thus if a microformat is on a hyperlink element with only a root class name and no properties, and that element has but one child element that is an image, then in addition to implying the the URL from its <code>href</code>, the <code>src</code> of the child image element is parsed as the '''<code>u-photo</code>''' property of the microformat, and if present, its <code>alt</code> attribute is parsed as the '''<code>p-name</code> property of the microformat.
+
Thus if a microformat is on a hyperlink element with only a root class name and no properties, and that element has a single child element and that element is an image, then in addition to implying the the URL from its <code>href</code>, the <code>src</code> of the child image element is parsed as the '''<code>u-photo</code>''' property of the microformat, and if present, its <code>alt</code> attribute is parsed as the '''<code>p-name</code> property of the microformat.
  
 
Markup example:
 
Markup example:
Line 129: Line 131:
 
}
 
}
 
</source>
 
</source>
 +
 +
An object element with a data attribute works the same way as the img element with its src attribute. E.g. '''<code>&lt;a class="h-card" href>&lt;object type="image/..." data="..."></code>''' in addition to implying '''<code>u-url</code>''' from the <code>href</code>, implies '''<code>u-photo</code>''' from the object element's <code>data</code>, as well as '''<code>p-name</code>''' from the text contents of the object as with elements in general.
  
 
use-cases:
 
use-cases:
Line 144: Line 148:
 
** minimal markup example with real values: http://krijnhoetmer.nl/irc-logs/microformats/20120901#l-150 from aaronpk
 
** minimal markup example with real values: http://krijnhoetmer.nl/irc-logs/microformats/20120901#l-150 from aaronpk
 
*** similar: https://gist.github.com/3585643 - has an explicit span around the text after the image, but is otherwise similar. If there is an actual use case for having the second child span around the visible text, then we should consider expanding to allow implied properties for that too (general pattern of image and then something else which has the name, e.g. span/b etc.).
 
*** similar: https://gist.github.com/3585643 - has an explicit span around the text after the image, but is otherwise similar. If there is an actual use case for having the second child span around the visible text, then we should consider expanding to allow implied properties for that too (general pattern of image and then something else which has the name, e.g. span/b etc.).
 +
 +
== parsing ==
 +
See: http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties
  
 
== to do ==
 
== to do ==
Line 156: Line 163:
 
=== root class on one element ===
 
=== root class on one element ===
 
Let's consider root class only on:
 
Let's consider root class only on:
* '''<code>&lt;abbr class="h-card" title&gt;</code>''' - imply '''<code>p-name</code>''' from <code>title</code>
+
* '''<code>&lt;abbr class="h-card" title&gt;</code>''' - imply '''<code>p-name</code>''' from <code>title</code>. Example(s)/use-case(s):
 +
** <code>(&lt;abbr class="h-card" title="Richard Posner"&gt;Posner&lt;/abbr&gt; 2010)</code>
 +
*** from [[citation-formats#TCMOS_permalink|citation format styles TCMOS permalink]] (note abbreviated parenthetical style at end of that subsection). Longer form including surrounding [[citation-brainstorming#web_citations|h-cite]] markup:
 +
<source lang=html4strict>
 +
<cite class="p-author h-cite">
 +
(<abbr class="h-card" title="Richard Posner">Posner</abbr>
 +
  <time class="dt-published">2010</time>)
 +
</cite>
 +
</source>
 +
Note the problem of lacking an explicit "name" for the work being cited. Perhaps such an abbreviated citation reference could hyperlink to a full citation, and either:
 +
<div class="discussion">
 +
* incorporate the name of the work being cited by reference from that full citation, or
 +
* perhaps create a new, smaller microformat as a subset of h-cite like abbreviated cite, or a cite reference. Try to pick a name according to what TCMOS calls those parenthetical references.
 +
</div>
 +
 
 
* '''<code>&lt;object class="h-card" type="image/..." data="..."></code>''' - imply '''<code>u-photo</code>''' from <code>data</code> and '''<code>p-name</code>''' from text contents as with elements in general.
 
* '''<code>&lt;object class="h-card" type="image/..." data="..."></code>''' - imply '''<code>u-photo</code>''' from <code>data</code> and '''<code>p-name</code>''' from text contents as with elements in general.
 
* ...
 
* ...
Line 168: Line 189:
  
 
=== root element and one child ===
 
=== root element and one child ===
* '''<code>&lt;a class="h-card" href>&lt;object type="image/..." data="..."></code>''' - imply '''<code>u-url</code>''' from <code>href</code> and imply '''<code>u-photo</code>''' from the object element's <code>data</code> and '''<code>p-name</code>''' from text contents as with elements in general.
+
* '''<code>&lt;a class="h-card" href>&lt;abbr title&gt;</code>''' - imply '''<code>u-url</code>''' from <code>href</code> and imply '''<code>p-name</code>''' from the abbr element's <code>title</code>. Similar to the abbr root element case above (if that's allowed, we should strongly consider allowing this too).
* '''<code>&lt;a class="h-card" href>&lt;abbr title&gt;</code>''' - imply '''<code>u-url</code>''' from <code>href</code> and imply '''<code>p-name</code>''' from the abbr element's <code>title</code>
 
  
 
== see also ==
 
== see also ==
* [[microformats-2]]
+
* [[microformats2]]
* [[microformats-2-brainstorming]]
+
* [[microformats2-brainstorming]]
* [[microformats-2-prefixes]]
+
* [[microformats2-experimental-properties]]
* [[microformats-2-implied-properties]]
+
* [[microformats2-prefixes]]
* [[microformats-2-faq]]
+
* [[microformats2-implied-properties]]
 +
* [[microformats2-parsing]]
 +
* [[microformats2-faq]]

Latest revision as of 16:29, 18 July 2020

summary

As part of the further simplifications in microformats2, the following generic properties are automatically implied by microformats with only a root class name with certain common semantic markup patterns.

  • p-name on elements in general
  • u-url on hyperlinks (<a href>) elements
  • u-photo on images (<img src>) elements

and combinations thereof.

root class only and name property

Web pages with microformats nearly always markup proper nouns, which have a primary label of some sort, commonly known as a name.

Thus if a microformat only has a root class name and no properties, then the entire text contents of the element is parsed as the p-name property of the microformat.

Markup example:

Simple person reference:

<span class="h-card">Frances Berriman</span>

Parsed JSON with implied name property:

{
  "type": ["h-card"],
  "properties": {
    "name": ["Frances Berriman"] 
  }
}

to-do:

  • try examples with organizations, events, products (however note that those are almost always capitalized thus implying proper noun / name semantics)

use-cases:

  • every single proper noun on any web page.

related FAQ:

aside name vs fn

In short, why use 'name' instead of the well established 'fn' from existing microformats? (per Naming Principles etc.) Per feedback:

  • from microformats mailing-lists over the years
    • numerous individuals preferring 'name'
    • asking why 'fn' repeatedly despite FAQ
  • Google Rich Snippets renaming 'fn' as 'name' in RDFa and microdata variants of vocabularies
  • ...

Choosing to use 'name' as the generic term moving forward instead of 'fn' - the benefits outweigh costs.

hyperlink and url property

A significant proportion of proper noun references on web pages are a hyperlink to a page about that proper noun, AKA a URL for a proper noun.

Thus if a microformat is on a hyperlink element with only a root class name and no properties, then in addition to implying the name from its text contents, the href of the element is parsed as the u-url property of the microformat.

Markup example:

Simple hyperlinked person reference

<a class="h-card" href="http://benward.me">Ben Ward</a>

Parsed JSON:

{ 
  "type": ["h-card"],
  "properties": {
    "name": ["Ben Ward"],
    "url": ["http://benward.me"]
  }
}

to-do:

  • try examples with organizations, events, products

use-cases:

image and name photo properties

Many proper noun references on web pages are simply an embedded image of that proper noun, typically a representative photo of the proper noun, often with its name as alt text.

Thus if a microformat is on an image element (<img src>) with only a root class name and no properties, then the src of the element is parsed as the u-photo property of the microformat, and if present, the alt of the element is parsed as the p-name property of the microformat.

Markup example:

<img class="h-card" src="http://example.org/pic.jpg" alt="Chris Messina" />

Parsed JSON:

{ 
  "type": ["h-card"],
  "properties": {
    "name": ["Chris Messina"],
    "photo": ["http://example.org/pic.jpg"]
  }
}

An object element with a data attribute works the same way as the img element with its src attribute.

to-do:

  • try examples with organizations, events, products

use-cases:

  • nearly every social networking site that shows a grid of people without text already does so with img tags and their names in the alt attribute. Most of those are linked too, which brings us to the next markup structure which implies properties:

hyperlinked image and name photo url properties

Often proper noun references on web pages are a representative image of the proper noun that is hyperlinked to a page about that proper noun.

Thus if a microformat is on a hyperlink element with only a root class name and no properties, and that element has a single child element and that element is an image, then in addition to implying the the URL from its href, the src of the child image element is parsed as the u-photo property of the microformat, and if present, its alt attribute is parsed as the p-name property of the microformat.

Markup example:

<a class="h-card" href="http://rohit.khare.org/">
 <img alt="Rohit Khare"
      src="https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg" />
</a>

Parsed JSON:

{ 
  "type": ["h-card"],
  "properties": {
    "name": ["Rohit Khare"],
    "url": ["http://rohit.khare.org"],
    "photo": ["https://s3.amazonaws.com/twitter_production/profile_images/53307499/180px-Rohit-sq_bigger.jpg"]
  }
}

An object element with a data attribute works the same way as the img element with its src attribute. E.g. <a class="h-card" href><object type="image/..." data="..."> in addition to implying u-url from the href, implies u-photo from the object element's data, as well as p-name from the text contents of the object as with elements in general.

use-cases:

  • nearly every social networking site that shows a grid of people without text already does so with hyperlinked img tags and their names in the alt attribute.

root class with one child hyperlink

  • <span class="h-card"><a href="http://example.com">Ace Brown</a></span> - treat single hyperlink child as existing single hyperlink case. I.e. imply u-url from its href. This markup is generated in MediaWiki installs (e.g. Wikipedia) when you surround a MediaWiki link like [URL label] or [[Wiki page name]] with a <span> with a microformats root class name. Real world examples:
  • <span class="h-card"><a href="http://example.com"><img src alt="Ace Brown"/></a></span> ...similarly with single hyperlink child itself with single img child etc.

root class with one child element and text

  • <a class="h-card" href><img alt="" src/> Ace Brown</a> - a variant of the hyperlink with image pattern, this is an example where the alt text is provided as actual visible text rather than an alternative, and therefore an explicitly empty alt="" is provided to avoid duplicate/redundant information in non-visual renderings (e.g. speech). Imply u-url from href, u-photo from src, and p-name from the text content of the root element, with leading/trailing white-space removed. Real world examples:

parsing

See: http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties

to do

to-do:

  • try examples with organizations, events, products

additional markup patterns to consider

Document more use-cases from actual publishing examples in the wild of simple items, e.g. from Wikipedia.

And some per the principle of least surprise - fleshing out some of the patterns to consider additional different combinations of elements, but in the same basic pattern(s).

root class on one element

Let's consider root class only on:

  • <abbr class="h-card" title> - imply p-name from title. Example(s)/use-case(s):
    • (<abbr class="h-card" title="Richard Posner">Posner</abbr> 2010)
<cite class="p-author h-cite">
 (<abbr class="h-card" title="Richard Posner">Posner</abbr> 
  <time class="dt-published">2010</time>)
</cite>

Note the problem of lacking an explicit "name" for the work being cited. Perhaps such an abbreviated citation reference could hyperlink to a full citation, and either:

  • incorporate the name of the work being cited by reference from that full citation, or
  • perhaps create a new, smaller microformat as a subset of h-cite like abbreviated cite, or a cite reference. Try to pick a name according to what TCMOS calls those parenthetical references.
  • <object class="h-card" type="image/..." data="..."> - imply u-photo from data and p-name from text contents as with elements in general.
  • ...

rejected root only markup patterns

Is there anything that should be implied semantically from root class only on:

  • <audio src> - no, because there is no common practice of simple audio element usage for proper nouns, it's nearly always nested in a broader context.
  • <time datetime> - no, because there are no microformats that are just a datetime
  • <video src> - no, because there is no common practice of simple video element usage, it's nearly always nested in a broader context.

Use-case counter-examples welcome.

root element and one child

  • <a class="h-card" href><abbr title> - imply u-url from href and imply p-name from the abbr element's title. Similar to the abbr root element case above (if that's allowed, we should strongly consider allowing this too).

see also