hcard-implied: Difference between revisions
AndyMabbett (talk | contribs) (make status (i.e.. this is a proposal) clear) |
m (Replace <entry-title> with {{DISPLAYTITLE:}}) |
||
| (7 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE:Implied hCard}} | |||
It is proposed to extend the hCard specification to include Implied [[hcard|hCards]], in order | It is proposed to extend the hCard specification to include "Implied [[hcard|hCards]]", in order to streamline creation and mark-up for simple hCards by assuming information from common design patterns. | ||
== Why? == | == Why? == | ||
As microformats grow and emerge, the barrier to entry for writing them increases. Already, compound microformats such as hAtom, hResume and hReview are comprised of data from hCard, hCal, and rel-tag, and writing to the former requires knowledge of the latter even if the constructs used are quite simple. In addition, adding microformats to a Web page often requires adding a significant amount of tags to code, which often have to be added (time-consumingly) by hand. For example: | As microformats grow and emerge, the barrier to entry for writing them increases. Already, compound microformats such as hAtom, hResume and hReview are comprised of data from hCard, hCal, and rel-tag, and writing to the former requires knowledge of the latter even if the constructs used are quite simple. In addition, adding microformats to a Web page often requires adding a significant amount of tags to code, which often have to be added (time-consumingly) by hand. For example, a simple name: | ||
<pre><nowiki> | <pre><nowiki> | ||
John Doe | |||
</nowiki></pre> | </nowiki></pre> | ||
can become: | |||
<pre><nowiki> | <pre><nowiki> | ||
<span class="vcard"> | <span class="vcard"><span class="fn">John Doe</span></span> | ||
< | |||
</span> | |||
</nowiki></pre> | </nowiki></pre> | ||
with 52 extra characters: | |||
== Proposal == | |||
To find a way that the above transformation can be achieved (or "implied") with a single span and a single class. This ''might'' be: | |||
<pre><nowiki> | |||
<span class="vcard-fn">John Doe</span> | |||
</nowiki></pre> | |||
although other patterns are also being discussed. | |||
== Original Proposer == | |||
* [http://ryancannon.com/ Ryan Cannon] | |||
== See also == | |||
* For more examples, see [[hcard-implied-examples]] | * For more examples, see [[hcard-implied-examples]] | ||
* For ideas refer to [[hcard-implied-brainstorming]] | * For ideas refer to [[hcard-implied-brainstorming]] | ||
Latest revision as of 16:26, 18 July 2020
It is proposed to extend the hCard specification to include "Implied hCards", in order to streamline creation and mark-up for simple hCards by assuming information from common design patterns.
Why?
As microformats grow and emerge, the barrier to entry for writing them increases. Already, compound microformats such as hAtom, hResume and hReview are comprised of data from hCard, hCal, and rel-tag, and writing to the former requires knowledge of the latter even if the constructs used are quite simple. In addition, adding microformats to a Web page often requires adding a significant amount of tags to code, which often have to be added (time-consumingly) by hand. For example, a simple name:
John Doe
can become:
<span class="vcard"><span class="fn">John Doe</span></span>
with 52 extra characters:
Proposal
To find a way that the above transformation can be achieved (or "implied") with a single span and a single class. This might be:
<span class="vcard-fn">John Doe</span>
although other patterns are also being discussed.
Original Proposer
See also
- For more examples, see hcard-implied-examples
- For ideas refer to hcard-implied-brainstorming