Revision as of 12:00, 4 September 2008 by JulianStahnke (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)

Jump to: navigation, search

value excerption pattern brainstorming


The value-excerption-pattern is derived from value-excerpting in hCard. The precise parsing behavior is not yet finalized, so the pattern should be used only with extreme caution.

This brainstorming page is for exploring ideas related to specifying the value-excerption-pattern in more detail and ideas for special case handling of the value-excerption-pattern in combination with specific semantic HTML elements per those elements' particular semantics.

These are merely explorations for now, and should NOT be used in actual content publishing, nor implemented in any production code.

Tantek Çelik

details for handling specific elements

object param handling

2008-08-23 Ben Ward and Tantek Çelik brainstormed the following possible special case markup handling for the use of the value-excerption-pattern with the <object> element. Modified 2008-08-26.

The following markup example documents one way the hCard tel property's type subproperty could be specified with the enumerated value of "cell" while providing the UK English "mobile" as the human visible object text contents:

<object class="type" lang="en-GB">
 <param name="value" value="cell" />



Note that the param element does not have a 'class' attribute and thus its 'name' attribute (which has a compatible semantic) is used instead to invoke the value excerption pattern.


to do

Browser Testing

Using the following simple, HTML4 hcard:


<title>&lt;object> value excerption pattern: hCard Telephone Type Test Case</title>

<body class="vcard">
    <h1 class="fn"><a class="url" href="">Ben Ward</a></h1>
    <p class="tel">
        <object class="type">
            <param name="value" value="cell">
        <span class="value">415-123-567</span>

A pass is to display a heading level one ‘Ben Ward’ with hyperlink, followed by a paragraph displaying the text ‘Mobile: 415-123-567’ Browsers selected based on YUI Graded Browser Support (August 2008), plus some others.

Safari 2 Tweak

The example is tweaked as follows to affect Safari 2 rendering:


<title>&lt;object> value excerption pattern: hCard Telephone Type Test Case</title>

<body class="vcard">
    <h1 class="fn"><a class="url" href="">Ben Ward</a></h1>
    <p class="tel">
        <object data="data://" class="type">
            <param name="value" value="cell">
        <span class="value">415-123-567</span>

A data="data://" URL attribute is added to the object element.

Safari 2 Result

† Safari 2 renders the object correctly on first page load, *however*, upon using the browser ‘Refresh’ function, the object element reverts to the broken rendering described in the original test.

Current Conclusion

--BenWard 20:17, 26 Aug 2008 (PDT)

--Tantek 03:07, 27 Aug 2008 (PDT)


misunderstanding of authoring unfriendliness

previous iterations

<object class="type" lang="en-GB">
 <param class="value" name="value" value="cell" />

details for handling specific property types

date and time separation


By specifying a more precise parsing of the use of "value" excerption inside all datetime properties (e.g. dtstart, dtend, published, updated etc.), dates and times can be marked up separately, thus reducing/minimizing (and potentially eliminating) the readability issues that come with compound ISO8601 datetimes.

introductory example

The sentence:

 The weekly dinner is tonight at 6:30pm.

would be marked up as:

 The weekly dinner is <span class="dtstart"><abbr class="value" title="2008-06-24">tonight</abbr> 
 at <abbr class="value" title="18:30">6:30pm</abbr></span>.



Some potential issues were raised in IRC, and it helps to document/resolve them so that they are not brought up repeatedly.

content requirements

Some requirements which enhance both human readability, and machine parsability (best of both) :


It's important to document the derivation/background of a brainstorm/proposal as it allows others to see some of the thinking that went into it, and avoid having to rediscuss alternatives already considered, and helps provide understanding as to why aspects of the design are as they are.

example with datetime

Here is a short code example:

 the weekly dinner is tonight at <span class="dtstart">2008-06-24T18:30</span>
example with abbr datetime

However that's not the easiest to read, nor do most people publish that as human visible text, so per the abbr-datetime pattern:

 the weekly dinner is tonight at <abbr class="dtstart" title="2008-06-24T18:30">6:30pm</abbr>

which has raised two issues:

  1. When "2008-06-24T18:30" is inspected by a human reading a tooltip, or spoken by a screen reader, it's not the most understandable thing (precise citation needed, perhaps an mp3 with screen reader used version info).
  2. There is a non-local violation of DRY (which IMHO is a worse problem, as it leads to worse data quality -Tantek). That is, the "date" information is now not only in the text twice (as it was before), but those two instances of the date information are not on the same element, which makes it worse. That is, "tonight" is in the prose, outside of the element with the precise date "2008-06-24".

In analysis of examples of event information on the web, the date and time are often published in separate elements, often for display purposes.

Thus it is this existing content publishing practice which leads to this brainstorm proposal, to essentially to introduce a date and time value excerption longhand.

(Initially Tantek's idea that he bounced off Jeremy Keith (similar idea conceived by Drew independently) was to introduce new classes "datevalue", "timevalue" and "tzvalue" for this purpose, but Bob Jonkman pointed out that HTML5's time parsing algorithm enables a single <time> element to contain dates or times (with or without timezone) without having to explicitly say whether the value contains dates or times (with or without timezone). Bob then proposed that thus all was needed was a single new "datetime" class name. This was the key realization that allowed minimal invention. Tantek pointed out that since from the type of property we already know it is a datetime, there was no need for even one new class name, that we could simply re-use "value" excerption, and simply more precisely specify the semantics/parsing in the case of datetime properties.)

example with new date and time value excerpts

Thus we markup the date and time separately, as value excerpts, using the abbr-date-pattern and an implied parallel abbr-time-pattern:

 The weekly dinner is <span class="dtstart"><abbr class="value" title="2008-06-24">tonight</abbr> 
 at <abbr class="value" title="18:30">6:30pm</abbr></span>.
separate subtrees

The proposal also allows setting the date and time in separate element subtrees as well, which may be necessary for some document structures:

 the weekly dinner is <span class="dtstart"><abbr class="value" title="2008-06-24">tonight</abbr></span> 
 at <span class="dtstart"><abbr class="value" title="18:30">6:30pm</abbr></span>.

Note the two instances of dtstart, one of which sets the date for the dtstart, and the other of which sets the time.

The idea being, when a parser sees a datetime property (e.g. dtstart) with a value excerpt, that it only "set" the component of its full value that is specified by the value excerpt (e.g. the date), and that if lacking a complete datetime, it continue to parse additional instances of that datetime property for the remaining component(s) (e.g. the time).

Of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so this works.

reusing date data for multiple datetime properties

This also provides a *very* convenient way to re-use the same date information for start and end, e.g. expanding the example:

 the weekly dinner is <span class="dtstart dtend"><abbr class="value" title="2008-06-24">tonight</abbr></span> 
 from <span class="dtstart"><abbr class="value" title="18:30">6:30</abbr></span> - 
 <span class="dtend"><abbr class="value" title="20:30">8:30pm</abbr></span>.

Note what just happened. we just eliminated another duplication of date information by reusing the start *date* information for the end *date* information and *only* specifying the end *time* information separately for the two properties.

Reducing the duplication (or triplication) of such data helps to reduce the chances of (even inadvertent) data corruption/drift/divergence among any duplicates.

time zones

There are a few choices for timezones.

  1. Simply include the time zone information as part of the time "value".
    E.g. <abbr class="value" title="18:30-0700">6:30pm</abbr>
  2. Or use another value excerpt for the timezone (was: introduce the class name "tzvalue")
    E.g. <abbr class="value" title="18:30">6:30pm</abbr> <abbr class="value" title="-0700">PDT</abbr>
  3. Or allow both and let web authors decide. This is the current leaning.
    • if web authors want to specify timezone as part of the time (first example above), they can,
    • or if web authors visibly publish the timezone separately (second example above), then they can mark that up.
    • or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.

(more to come, documenting from IRC logs)


Opening up a discussion section even though documentation from IRC logs is still in progress. :)

enabling more use of title attributes


Numerous proposals over the years have advocated expanding the use of the title attribute beyond the abbr tag for storing microformat property values. One simple mechanism for doing so would be to introduce a new value excerption class name and rule.

valuetitle: before "normal" value excerption handling, first look (in the same manner as value-excerption) for the class name "valuetitle", if it is found, use the value of the title attribute on that element and do no further value excerption or other parsing for that property value.


<span class="type"> <span class="valuetitle" title="cell">mobile</span> </span>

In addition to first looking for "valuetitle" where a parser would look for "value", it seems reasonable to also allow "valuetitle" on the property element itself in order to minimize the markup necessary, e.g.:

<span class="type" class="valuetitle" title="cell">mobile</span>

Naming reasoning/methodology: by using the prefix "value-" it is clear that this is part of the value excerption pattern. By using the suffix "-title", it is clear that the "title" attribute is involved. Thus the name "valuetitle" is a good mnemonic for its functionality. See related naming-principles.

"valuetitle" was suggested on 2008-08-30 by Tantek in a discussion with Ben Ward.

previous similar proposals

I believe there may have been a proposal for "usetitle"(link+citation needed) in the past that would function similarly. I think "valuetitle" is better than "usetitle" as "valuetitle" is more *descriptive*, i.e. meaning "the title is the value", as opposed to "usetitle", which is more *prescriptive*, i.e. "use the title". Tantek 08:13, 1 Sep 2008 (PDT)

related pages

value-class-pattern-brainstorming was last modified: Wednesday, December 31st, 1969