Difference between revisions of "value-excerption-dt-separation-test"
(drafted based on Value Excerption Pattern: Parsing 'value' from an empty element)
(add link to * Value Excerption Pattern: Parsing 'value' from an empty element)
|Line 307:||Line 307:|
Revision as of 05:29, 23 January 2009
<entry-title>Value Excerption Pattern: special parsing 'value' in date-time properties</entry-title> This page is targetted at those already experienced with microformats.
Just like the Value Excerption Pattern: Parsing 'value' from an empty element page:
Please carefully note, this page is about a pre-draft, experimental and unfinished microformats proposal. You cannot use this pattern on your live pages, it is not supported by any stable parser and you should not assume that this pattern will be finalized as-is! We're just asking for help in testing this thoroughly. Thank you.
- 1 The proposed parsing rules
- 2 Example Tests
- 3 Evil Tests
- 4 Response
- 5 Related Pages
This is a special page to introduce and gather results to widespread testing of a proposed extension to the value-excerption pattern. See value excerption pattern brainstorming: date and time separation for the specific proposal.
This pattern can be used to resolve some long standing issues with including machine-data in microformats; it's imperative we test thoroughly before adding it to any pattern specification. Following are a number of example tests. Please try them out.
The pattern we're testing looks a little something like this. Those experienced with microformats should immediately see what we're trying to do:
<p class='dtstart'> <abbr class='value' title='2009-01-06'>January 6th</abbr>, in <abbr class='value' title='22:54'>the evening</abbr> </p>
It allows you to include machine-form date and time data alongside the human form equivalents, without polluting visible formatted content with the harder to read/understand fully expanded ISO8601 datetime, and also with bringing the ISO8601 date equivalent and ISO8601 time equivalents closer to the localized language specific versions.
This covers only cases where a microformat property takes a date-time fixed format of data that is may be challenging for visible inclusion in a page (such as a full date-time and timezone string).
This pattern is based on being able to deterministically parse date vs time values differently and compositing the different pieces of a full date-time value into a single ISO8601 datetime. This allows separately marking up the date and the time (which reflects common publishing practice of separating those two pieces of content in their context), and therefore reducing the DRY violation impact (by keeping the duplicate alternates closer), and providing more readable/understandable alternates as well. The semi-visibility advantage of being able to verify date or time alternate values via tooltip is enhanced by the greater readability/understandability of the individual components over full ISO8601 datetime.
Additionally the special parsing rules could also be applied to
value-title as well; whatever makes most sense to your publishing scenario.
Based on everything we know up to this point, we believe this pattern will work. But, it's wide ranging and the web is broad, and we want to be sure. Please, help us out testing this pattern proposal. Examples tests are below, please push them or your own variants into publishing systems, content management systems, editor applications and tools. Check that it comes out the other side with the data intact, and exposed (or hidden) as expected: Render it in desktop browsers, mobile browers, screen readers, in braille… anything you can test, we want to know about! We need to see any quirks, oddities and so on.
Also, by all means provide thoughts on the publishing flow for this.
Note that valid HTML is a cornerstone of microformats. Inventing new attributes, depending on unstable drafts of HTML5, using non-standard DOCTYPEs or XML extensions is not an applicable option. We're trying to achieve something as gracefully as we can within the limitations of HTML4, and without harming user experience.
The proposed parsing rules
The current, likely incomplete, parsing rules and restrictions for this pattern are as follows:
- When parsing "value" excerption values for a datetime property, rather than simply appending multiple "value" children they should be parsed for the following, in order, and the first occurrence of a date and/or time component must be used:
- ISO8601 datetime. For backward compatibility, if a ISO8601 date AND time value is found in a "value" element then there is no need to look for additional "value" elements.
- ISO8601 date with hyphens.
- ISO8601 time with timezone.
- ISO8601 time without timezone.
- ISO8601 timezone.
- The "value" excerption data must represent the same data as the visible text of the property; the parent property must not contain arbitrary data. Validator tools will be encouraged to verify this where possible (for example, some programming languages have access to powerful date parsing algorithms that can compare human dates and times to the ISO forms).
- value-title option: Additionally, while parsing for "value" elements, parse for
value-titleelements as well, and consider their values as well for the above.
- If an element specifies both "value" and "value-title" class names, treat it as a "value" element, as the more visible data must be preferred.
- Empty elements used with "value-title" can be any element, but a generic
spanis most appropriate. You could use
bif you want to save bytes, or an
input type=hiddenif it makes sense to you. That choice will not matter to parsers. You are in complete control of that publishing decision. As per usual microformats documentation,
spanwill be used for generic examples.
value-titleproperty does not have to be empty. If you do want a tool-tip to expose a useful data-form, you can. e.g.
<span class='value-title' title='2008'>last year</span>is valid too.
The following snippets are example tests for the new pattern. You can use them as is, or use them as a base for your own tests with your own content. If you write your own tests, please document them under ‘additional test cases’ so that any failing tests can be checked for validity.
hAtom#1: An hAtom
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <title>Value Excerption Pattern Test hAtom#1dt</title> </head> <body> <div class="hentry"> <h1 class="entry-title">An introduction to Microformats</h1> <p> Published on <span class="published updated"> <abbr class="value" title="2009-01-09">January 9th</abbr>, <abbr class="value" title="11:33:00-0800">around lunchtime</abbr> </span> by <span class="author vcard"> <a class="url fn" href="http://example.com"> Joe Blogger</a></span>. </p> <p class="entry-content">Wow, microformats are really useful! You can learn loads about them on the <a href="http://microformats.org/wiki">microformats wiki</a>. </p> </div> </body> </html>
hCal#1: An hCalendar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <title>Value Excerption Pattern Test hCal#1dt</title> </head> <body> <div class="vevent"> <h1 class="summary">Value Exception Test Day!</h1> <p class="description">Come help <span class="organizer vcard"> <a class="fn url org" href="http://microformats.org">microformats.org</a> </span> test a new value-excerption pattern for sanity and robustness! </p> <p>Help out by running some tests at <span class="dtstart"> <abbr class="value" title="12:00">midday</abbr> on <abbr class="value" title="2009-01-12">Monday January 12th</abbr>. </span> </p> <p>See <a class="url" href="http://microformats.org/wiki/value-excerption-dt-separation-test">the wiki</a> for more details! </p> </div> </body> </html>
hCard#1: An hCard
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <title>Value Excerption Pattern Test hCard#1dt</title> </head> <body> <!-- Behind Test --> <div class="vcard"> <h1 class="fn">Ben Ward</h1> <p>Ben Ward's birthday is <span class="bday"> <abbr class="value" title="1984-02-09">February 9th</abbr>. </span> You should throw him a party! </p> </div> <!-- End Test --> </body> </html>
If you believe there is an error in any of these tests, or in any others that people contribute, please post on the mailing list.
If you want to give existing microformat parsers a good run out, construct ‘evil’ tests using nesting, combination and interpolation of different microformats.
hAtom + hCalendar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <title>Value Excerption Pattern Test hAtomhCalEvil#1dt</title> </head> <body> <div class="hentry vevent"> <h1 class="entry-title summary">An introduction to Microformats</h1> <p> Published on <span class="published updated"> <abbr class="value" title="2009-01-09"> January 11th</abbr>, <abbr class="value" title="11:33:00-0800">late afternoon</abbr> </span> by <span class="author organizer vcard"> <a class="url fn" href="http://example.com"> Joe Blogger</a></span>. </p> <p class="entry-content description"> <span class="dtstart"> <abbr class="value" title="2009-01-14">this coming Wednesday</abbr> at <abbr class="value" title="19:00:00">7</abbr> </span> is not the date of a completely fictional microformats event. If it existed, it would promise to be informative and get you up to speed on microformats.org for 2009! Now you've learned to work with microformats a little, why not attend and get involved! Why not? Because this event is a test case, not for real. </p> </div> </body> </html>
- Don't like the ISO8601 dates? Don't like ISO8601 times? Don't like the use of the multiple "value" elements? Please file general issues concerning the proposed pattern on the main value excerption brainstorming page, or discuss them on the mailing list.
- Add results of tests and responses to these tests themselves on this page.
Misplaced responses will be moved, and having to do so will make [[User:Tantek|Tantek (and possibly Ben) growly, so, y'know, please try to keep the wiki tidy.
List successfully tested environments here. Add new environments as new list items, and expand existing list items with your name and platform variants to indicate verified successes.
|MediaWiki/Linux||Publishing||Safari 3.2.1 (Mac OSX 10.5)|
|Safari 2.0.4||Consuming||Mac OSX 10.5|
|Safari 3.2.1||Consuming||Mac OSX 10.5,|
|Firefox 2.0||Consuming||Mac OSX 10.5|
|Firefox 3.0||Consuming||Mac OSX 10.5,|
|Firefox 3.1ß1||Consuming||Mac OSX 10.5,|
|Opera 9.62||Consuming||Mac OSX 10.5,|
|Internet Explorer 5.2||Consuming||Mac OSX 10.5,|
|Internet Explorer 6.0||Consuming||Windows XP (SP3)|
|Internet Explorer 7.0||Consuming||Windows XP (SP3)|
|Internet Explorer 8.0 beta 2||Consuming||Windows XP (SP3)|
For failures, please provide as much information as you can. The precise impact of the error, whether the behavior could be regarded as a bug in the software you're testing, whether it works in subsequent releases, whether you changed any settings in the software to produce the result, and if so, whether enabling/disabling that setting should be regarded a showstopper if this pattern were certified.
Since we want more detail, please expand failures into headed sections rather than cramming into a table.
For example, take this entirely plausible scenario as a template:
Example: Fake Publisher 3.1ß
- Windows Vista
- Test By
- When trying to enter an abbr in my HTML editor, which I wrote myself whilst I was high, the application immediately crashes, performs
rm -rf /on all UNIX boxes connected to my local network (which also appears to cause Android phones within Bluetooth range to do the same…), and then causes all attached peripherals to combust. I was not able to reproduce, as my house was now on fire.
- This is a beta release, and a bug has been filed.
- This product has a known history of flammability bugs.
- The user must explicitly enable the ‘Endanger My Life’ checkbox under the ‘Advanced Mislabelled Checkboxes’ tab of the ‘Complicated Preferences’ preferences pane.
- You get the idea.